While too much process in software development, as was satirized in the movie Office Space with its infamous TPS reports, can cause a product to grind to a halt, insufficient process can be as bad, if not worse. While it might be hard to imagine how less process can be worse, Google was kind enough to provide a wonderful example when they released a beta version of their own branded browser, Google Chrome. Within two hours of being released a critical vulnerability that allows arbitrary code execution was discovered and publicized along with a proof of concept demonstrating the vulnerablity. It is expected that any major piece of software, especially a beta version, will have some vulnerabilities. But in this case, this vulnerability was code not written by Google and Apple, the original writer of the code, had widely publicized the vulnerability and a patch before Google released Chrome. Independent of the compentency of Google's engineering, inadequacies in their security processes for Chrome led to this faux pax, the ongoing shenanigans and likely a reduced rate of adoption for what is obviously a major software effort for Google.

The problem arose because some parts of Chrome are using code from on Apple's Safari browser. Google began with a current version of the browser but never updated to a newer version and, more importantly, did not track security advisories for Safari. This was certainly embarrassing but far from a complete failure of process. On September 5th, three days after the release of Chrome, Google released a patch for the browser. Even after the patch, questions remained about whether the patch was sufficient or not to prevent all possible exploits of the vulnerability. On October 21st, without making any statement about the vulnerability, Google released a revised patch for the same vulnerability. Ignoring the fact that there is serious doubt as to whether or not they have completely fixed the vulnerability, Google is only distributing the updated patch to people who are downloading the developer browser versions rather than the user browser versions (besides potentially having extra code for developers, the developer browser versions tend to be less stable than the user version).

While Chrome only seems to have about 1% of the browser market, the actual number of users affected by this is large. The browser market is estimated to be 1.5 billion users worldwide. That means that about 1.5 million users are at risk of having a successful exploit of this attack occur while using Chrome. A successful exploit allows arbitrary code execution and likely turns the users computer into zombie that is part of a botnet.

It is this author's opinion that there is absolutely no excuse for the negligence Google has demonstrated in the handling of their Chrome browser. The brief summary is, Google released a software product that had at least one highly publicized and severe bug, produced an quick but inadequate patch, and took about seven weeks to produce an upadated but developer-only patch. Google's "developer-only" patch strategy suggests that even they are uncomfortable to release the fix to the general public.

Possible explanations for this problem include extreme deadline pressure from upper-management, a project that was taken lightly by management and incorrectly or inadequately staffed, a security knowledge base that was insufficiently allocated insufficiently to the project, or a score of other reasons. The one thing that is clear is that Google spent lots of effort on Chrome and, at best, have dramatically reduced its adoption rate due to a series of missteps that could easily have been avoided prior to releasing the browser had they only had a process in place to track Safari vulnerabilities.

There seems to be no end to the news about Windows Vista and its slow adoption rate. The reasons often cited for the slow adoption rate include lack of new features, increased hardware requirements, reduced performance, early and positive marketing of Vista's successor, Windows 7, and, of course, cost. However, from the security viewpoint, the correctness of these reasons are irrelevent. All that matters is that Windows Vista is a new operating system that is not obtaining a large market share.

The problem is that Windows Vista is a complex system that contains a large amount of new code. Complexity and newness are always a security red flag. Figure 1 shows a typical pattern as how discovered vulnerabilities vary over the lifetime of a product. As a software product becomes popular, it becomes a bigger target for attacks. Continuing growth of the install base and success of previous attacks provides ongoing motivation for attackers to spend resources trying to find new attacks. Eventually, as the most obvious vulnerabilities are discovered and corrected, the rate of discovering new vulnerabilities slows to a point that the software can be patched faster than new vulnerabilities are discovered and the curve begins its downward swing.

But, if a system has an unusually slow adoption rate, the curve can become unpredictable. In particular, if a large percentage of users are delaying adoption, attackers can lose interest in searching for vulnerabilities and the curve can level off or even begin to drop. Then, as more users move to the new platform, it becomes a more attractive target and hence vulnerabilities are discovered at a faster rate and the curve begins its upward climb again.

Nothing in this analysis is specific to Vista, Microsoft, PCs, or operating systems. The security concern arises from the complexity of creating large systems and the market's desire for new functionality at the cost of security. At this time, it is impossible to predict when Vista will be relatively secure and ready for use in mission critical systems. In fact, if Vista does not see widespread adoption, it might not even be possible to retrospectively determine whether Vista ever reached a state of moderate security stability. Without the incentive of a widespread user base, there might never be enough motivation to attack Vista to be certain that it is secure.

While I cannot recommend for or against Vista in the long run, I think use of it in the immediate future should be for non-critical systems until it sees a longer and more serious adoption.

“In the hands of a skilled attacker, even the most innocuous piece of data can be used to attack the system and gain access to the crown jewels.”

A security review or 206security audit is a process that helps an organization determine if they have the appropriate security measures in place; that is, if the amount they are spending on each security countermeasure approximates the cost to the company of the expected loss. While there are many methodologies for performing a security audit, most include the following steps: identification of valuable assets, estimating their value to the company and their cost if they are somehow damaged, determining their current level of protection, 207determining the probability of a potential break-in (i.e., risk), deciding if an asset's current protection matches its estimated value and investigating what options are available to remedy any differences. At first glance, while perhaps time-consuming, this does not seem terribly complex. Ask several top executives what they consider to be the company's valuable assets; merge and prioritize the lists, and you are likely well on your way.

If your executives did well, they will have included many types of assets including physical assets such as buildings, technological assets such as computers, intellectual property assets such as domain knowledge, etc. They might have thought to 212list risks such as fire, theft, computer break-ins, industrial espionage and even natural disasters.

If you add input from the IT team, you will likely get items added to the list involving security of employee passwords, firewall and other Internet-protection mechanisms, power and air-conditioning failures, etc.

Once complete, you will likely have a very comprehensive list of your company's assets that need protection. But one asset is nearly always forgotten. This is the internal configuration of a company's computer systems. "Internal configuration" includes:

• Internal network topology including firewalls, internal IP addresses, and other networking information and configuration that only need to be accessible from within an enterprise's private network.
• Hardware and software products, including their manufacturers, models and versions.
• Usernames, administrative accounts, privileged individuals.
• Internal or external services used by the company (e.g.: travel agency, office supply website, Active Directory services) and the means of connectivity to those services.
• Computer languages and software frameworks used for networked applications.
• Whole or partial source code—including stack traces.

These pieces of internal configuration, along with many others that have been omitted from this column for brevity, all share one thing in common: They are frequently thought of as non-confidential data, yet, in the hands of a skilled attacker, each might contribute to a break-in. With confidential data such as passwords or private keys, the threat from exposure is clear. But from these trivial configuration facts (e.g.: an IP address that is only accessible from within the enterprise network), the threats are less obvious.

To understand how this information could be dangerous, put yourself in the mind of an attacker. Start out by imagining an attacker who has their eye set on your site. Their goal could be a specific asset such as stealing computer resources or the design plans for the next Death Star. The attacker's goal might also be just a general search for anything of value. This can include confidential customer or employee records, passwords to your company's servers, "205tagging" your homepage, etc. Your company may have been chosen for any number of reasons, ranging from you being the only company who has the desired asset (e.g.: There is no competition in the Death Star market), they know your company, they have felt slighted by your company, etc. In reality it does not matter. They are attacking, you are defending; both sides want to win but only one can.

The attacker not only wants to succeed in obtaining the desired asset, but they wish not to get caught or go to jail. Even if they are residing in a country that does not enforce computer theft and will not imprison them, getting caught still means that a successful attack will be more difficult as the attacked site will almost certainly add new security measures or tighten the existing ones to prevent the attack from being reproduced.

So, to begin with, the attacker approaches your site as a typical user: pulling up the homepage, browsing and searching the site, perhaps even buying products from your site. But as the attacker does this, they will be recording every piece of data that is returned. In particular, as part of the HTTP protocol, there are descriptive pieces of a webpage that can be accessed by the Web browser but are not typically displayed. While there are many ways of viewing these headers, I usually use 206Firefox and the 207Live HTTP Headers extension.

Let me demonstrate how this process works by putting on my 208black hat for a minute. I decided to make the 209Firefox website my target (I chose this for no other reason than because it was on my screen browser from having created a link to it in the previous paragraph). Looking at the headers for 210http://www.mozilla.com/en-US/firefox/, I notice the following headers as interesting:

The Server header tells me that Apache 2.0.52 is being run on a machine running Red Hat Linux. The "X-Powered-By" header lets us know that the site's software, or at least this page is powered by 211PHP version 4.3.9. I have never seen the "Via" header before but a quick Google search and the second hit on "ns-cache cookie" tells me that the site is using the Citrix NetScaler Application Delivery Software 6.1 caching software. Searching around 212Citrix's site, I see that the current version of NetScaler is version 2138.0. Knowing that caches are frequently a source of security problems and that 214Mozilla is running two major releases behind the current version, I look on 215Citrix's site for any security bulletins for 6.1. My hope is that I will find a security bulletin that documents a vulnerability whose fix has not been applied to the site and use that to gain access to some protected information. Once I have done that, I will use whatever new information I have gained access to and try to get deeper into the system, proceeding patiently, one layer at a time, and changing tacks as I run into dead ends. And so the process goes. Each seemingly innocuous piece of information is used in combination with other information—information on hacking sites, etc.—to attempt the break-in.

Replacing my black hat with my more typical 205white hat, one can begin to see how each piece of information that is passed to the user, no matter how innocuous it may appear on its own, can be combined with other data to become a risk to the site's integrity. The 2062007 OWASP Top Ten Vulnerabilities document has 207Information Leakage and Improper Error Handling as the sixth most common Web vulnerability.

While any single, non-confidential piece of configuration data is probably not harmful to be leaked out by itself, in combination with other pieces of configuration data, even the most innocuous piece of data can be used to attack the system. With this in mind, the best strategy is to remove the easiest pieces of configuration data from leaking but not go crazy removing every piece. Odds are that some of the more difficult pieces of configuration data will take so much effort to remove that your efforts are better spent elsewhere.

I want to conclude that before writing the Firefox attack example, I searched both the Citrix website and other security websites and cannot find any vulnerabilities for NetScaler 6.1. That is, if I was actually trying to attack the Firefox site, I probably have run into a dead-end. More importantly, to the best of my knowledge, I have in no way exposed the Firefox website or written anything that exposes the Firefox site in any way. I am strongly in favor of 208responsible disclosure and almost never believe in exposing a site's vulnerabilities publicly (209Bruce Schneier's blog has a nice 210discussion of the this subject).