Confidential Data: You’re Giving Away Your Corporate Secrets!

A security review or security 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, determining 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 list 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, “tagging” 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 Firefox and the Live HTTP Headers extension.

Let me demonstrate how this process works by putting on my black hat for a minute. I decided to make the Firefox 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 https://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 PHP 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 Citrix’s site, I see that the current version of NetScaler is version 8.0. Knowing that caches are frequently a source of security problems and that Mozilla is running two major releases behind the current version, I look on Citrix’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 white 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 2007 OWASP Top Ten Vulnerabilities document has Information 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 responsible disclosure and almost never believe in exposing a site’s vulnerabilities publicly (Bruce Schneier’s blog has a nice discussion of the this subject).

Neil Smithline’s twenty-year career in software engineering has, for the past eight years, focused almost exclusively on application security in his role as BEA Security Architect. In this position Mr. Smithline co-designed the security framework for WebLogic Server that is now incorporated into most BEA products and becoming part of many Oracle products. During his tenure at BEA, he had the opportunity to interact with hundreds of customers; helping them develop their security architecture, processes, and strategies. He is currently a private application security consultant at his company, OneStopAppSecurity.com.