Exploiting Vulnerabilities
First Published: SC Magazine

One of the most common questions my clients ask me is what tools will I use to carry out the security assessment of their particular system or application. In some cases this question may be driven by a fear that, owing to the fact that my parent organisation is well known for producing vulnerability scanning products, I would restrict my investigation to only those tools. While in other more competitive cases the client has decided to focus upon the type and number of tools that will be utilised – the classic urinating contest of “So and so says they can detect 5,465 vulnerabilities against your 3,891”.

Tools are an important aspect of security assessment consulting. While a skilled and deeply knowledgeable consultant can probably do without the use of vulnerability scanners against a small number of computer hosts, they are still very valuable and efficient tools that remove the grunt work of vulnerability discovery. Used properly, and combined with other appropriate service (e.g. Database, Web Daemon, DCOM, etc.) specific tools, a consultant can focus upon delivering security expertise and interpretation of the findings to their paying client – instead of wasting time and money attempting to showing off their “elite” skills.

This is not to say that security assessment tools are always correct or conclusive in their discovery of vulnerabilities and security flaws. Using a combination of appropriate tools, experience and access to appropriate knowledge resources – a skilled consultant can identify and remove false positives from the many findings.

At the high end of technical security assessment, a lot of emphasis is placed upon the process of gaining administrative access through the exploitation of the discovered vulnerabilities. Obviously, by exploiting the vulnerability and obtaining interactive access to the host, the consultant has proved that a particular finding was not a false-positive. Unfortunately very few clients actually understand just how trivial the exercise can be once you have access to a large database of published or internally researched exploit code material, and place undue emphasis on actually exploiting the host – unaware of the full consequences.

I am always wary of gaining interactive access to a host through vulnerability exploitation. Firstly you have to be supremely confident that the exploit material will not have any secondary impact on the host - such as leaving services in a hung state (effectively causing a Denial of Service [DoS]) or affecting file integrity. Secondly, you must be fully aware of what actions will be necessary to “clean up” the host afterwards. And finally, you will most likely have to prove your success.

Having identified a vulnerability that represents a high risk to the client, and can probably be exploited safely, I always ensure that the client’s technical representative is fully appraised of the nature of the vulnerability and understands the consequences of either a successful or unsuccessful use of exploit code material. This ensures that appropriate permission is obtained and that the client can respond rapidly to any secondary effects should they grant permission. Most often a scheduled “window of opportunity” is agreed for when it is safe to attempt the exploitation.

Of all the consequences to actually exploiting a discovered vulnerability, it is the process of proving your success that can land you in the most hot water. With various country specific laws and regulations pertaining to data privacy, data protection, confidentiality and their classification of computer misuse activities – it is not as simple as just taking a copy of the database table containing customer details or credit card details and presenting that material back to the client.

Even less likely sources of proof can result in unexpected legal implications. One common method is to take a copy of a time stamped system log file. In an unfortunate example, a consultant that worked for me captured a copy of a proxy server’s web browsing logs. Upon verifying that the log contained enough information to prove a successful host compromise, it was discovered that some personnel of the client had been viewing and downloading illegal child pornography. Thus, the consultant was placed in the position of being legally obliged to report the incident to the police.

Not only were the client and consultant placed in an embarrassing situation, but the subsequent police investigation required detailed forensic activities and resulted in the impounding of both the clients proxy server and the consultants laptop.

Just as it is important to fully understand the consequences of using exploit code against discovered vulnerabilities, security consultants also need to fully understand the mechanisms that their suite of tools use to discover vulnerabilities. Many vulnerability scanning or service specific tools actually use common exploit code snippets to identify vulnerabilities. In too many cases I have seen other security consultants blindly incorporate the latest vulnerability checks into their tools, select the “run all but dangerous” checks, and proceed to DoS or affect file integrity of their clients systems.

My advice to other security consultants carrying out assessments is to always ensure that you know how each check in your suite of tools actually works, what the consequences of a check is likely to be, and fully explain the possible consequences to the client in advance. Furthermore, ensure you understand the legal implications of using exploit material and the consequences of accessing samples of the client’s data – even with the client’s written authorisation.

For the organisation employing the security consultants carrying out the assessment, ensure that the consultants can confidently explain and evaluate the consequences of using their selected suite of tools and exploit material. Before granting permission to the consultants to carry out any exploitation, ensure that you have the time and resources to deal with even the remotest consequences.
    Copyright 2001-2007 © Gunter Ollmann