|"rooting the box" : SC Magazine : Blog : Home|
"rooting the box"
First Published: SC Magazine
One of the most interesting phases of any penetration test (or pentest) is the actual exploitation of the discovered vulnerabilities. Exploitation is used to not only categorically verify that the vulnerability exists (and is thus not a false-positive), but is also used as a stepping stone to gaining visibility and potentially access to hosts or data not initially accessible.
When proposing to carry out a penetration test against a client’s environment, it is very important to correctly scope not only the extent of the environment under investigation, but to also address the bounds of any possible exploitation. The extent of exploitation possibilities is often driven by the technical understanding of the client’s nominated contact and their level of “ownership” of the environment. With this I mean how technically savvy they are, how great their understanding of the potential risks to exploitation, and how responsible they are for the environment should it all come crashing down around them.
Clients need to understand that exploitation is the single most dangerous part of a pentest and has the highest probability of either crashing or adversely affecting the performance of the host under investigation. Having said that - it’s all relative. One of the most common “unexpected” causes of systems being negatively impacted during a pentest prior to the exploitation phase is through standard port scanning procedures. It doesn’t happen very often (maybe only 1 in 200 remote hosts), but it can stop a service from operating or even crash the host or networking appliance. But then again – like I explain to my clients at the start of any pentest – while every precaution is taken by the consultants, not even the client can guarantee that their own laptop will start up each morning when they come into work.
Acknowledging that vulnerability exploitation is the most dangerous phase of a pentest, it is vital that appropriate procedures be established between the client and the pentesters to control when, where and what type of exploitation may take place. In most cases vulnerability exploitation would only be required against high or critical risk vulnerabilities. Having discovered such a vulnerability during earlier phases of the pentest (e.g. service enumeration or vulnerability probing), my standard procedure would be to immediately contact the client’s technical contact and inform them of the vulnerability. If exploit material is available for the vulnerability, the consultants would carefully explain to the client how exploitation would occur and detail the consequences of exploitation. In the majority of cases the clients usually give the consultants the OK to commence with exploitation – although this may be scheduled for out-of-hours work.
From experience, I have found it very important to carefully explain the method and the likely consequences of exploitation. For many classes of vulnerability, exploitation is a simple process of altering standard data submissions and gaining non-interactive access to host data (e.g. directory recursion of file paths and URLs to pull back copies of the password file). The impact on host stability is minimal and in the worst cases exploitation may create some a few temporary files on the host that must be removed by the system administrator at the end of the pentest.
There is however one class of vulnerability that exploitation quite often affects the stability of the host under study, but its existence also represents the greatest security threat to the host. These “buffer overflows” often enable attackers to inject their own code into the service and spawn off additional processes such as interactive command shells. Exploit code used by consultants is frequently designed to create an interactive command shell with administrator level permissions and is used to both investigate the file system of the compromised host and to also prepare the host as a jump point into other areas of the networked environment. Therefore, when explaining to the client, I inform them of the likely dangers to service integrity and carefully discuss any previously agreed limitations on the exploitation – in the majority of cases, exploitation is scheduled for out-of-hours or against test systems. Mutually agreed post exploitation limitations often include no installation of tools on the compromised host, no access to private and confidential client information on the host, and no creation of backdoors or additional user accounts.
It is unfortunate that many penetration testing teams (and even client security audit teams) place undue emphasis on the exploitation phase to the sacrifice of identifying other host vulnerabilities. While all pentesters enjoy “rooting the box”, care must be taken to identify all the other vectors that a malicious attacker could use to compromise the environments integrity. In the past I have see some pentesters spend days just trying to get one piece of exploit code to work against a particular host – totally neglecting all the other hosts within the scope of the engagement.
If the consultant is lucky they will compromise the host and dig up some interesting information that can be used to compromise additional hosts (e.g. gaining access to the password file and discovering accounts and passwords that can be used against the other hosts). Whether or not the consultant manages to successfully exploit the vulnerability, both the consultant and client should carefully evaluate the value of the time necessary to exploit a particular vulnerability versus enumerating additional attack vectors.
An additional word of advice for pentest clients – carefully evaluate the skills of the pentesters to understand and evaluate the exploit code they intend to use. For many consultants their primary hunting grounds for exploit material are popular hacking web sites or forums. It is not uncommon for these sources of material to contain hidden elements such as backdoors and Trojans. Too often pentest consultants lack the development experience and familiarity of assembler languages to identify safe “shell code” from malware.
Advice for organisations requiring exploitation of vulnerabilities during penetration testing: