Post-Exploitation Techniques from Black Hat 2011
In many exploit scenarios, an attacker finds a target and, if possible, establishes remote control over the system through known or unknown exploits. Whether the attacker uses a buffer overflow, insecure configuration, phishing for credentials, or cookie-stealing, the goal is clear: get a remote shell and gain complete control. Then what?
It is this post-exploitation environment that has interested me at this year’s Black Hat 2011. Several talks and trainings discuss post-exploitation techniques, and I’d like to share them in the interest of research – and defense.
In the excellent training I attended given by a South African penetration testing company called SensePost, we wrapped up the course by discussing post-exploitation. In the past, attackers used to be happy with website defacement or setting up FTP servers to store warez, but as more money has entered the game, the pranks have stopped and the business has started. One current common practice is to set up a remote web shell and then sell the use of those servers to spammers who can serve fake websites for phishing, serving malicious software, or sales of semi-legal goods.
Ang Cui, a PhD student researcher at Columbia University, demonstrated at Black Hat the ability to introduce on a compromised device running Cisco IOS what is essentially a rootkit that could modify packets within the transmit queue and return commands from a remote server to control the compromised device. The challenges of both executing code to compromise a Cisco IOS device and issuing commands to a compromised device are difficult because the memory structures and processor architectures differ from device to device and between different versions of Cisco IOS, complicating the development of exploits that rely upon manipulating memory and executing shellcode.
To use the technique, first an attacker must compromise a host through a reliable exploit. The researcher did not use a previously unknown vulnerability and instead, for demonstration purposes, artificially introduced a vulnerability in a Cisco IOS utility. If an attacker can accomplish an exploit, the attacker can gather information about the system memory and configuration, essentially generating a system fingerprint. By fingerprinting memory structures on the device, the command-and-control system could return commands formatted correctly for each targeted device, ensuring the exploit works for any given combination of hardware device and Cisco IOS version. The researcher posed the possibility of building a database of fingerprints that could be used to determine the exact version and device configuration to identify a compromised host. These techniques could help an attacker overcome the difficulty presented by the complex combinations of Cisco IOS and the underlying memory structures that prevent the development of reliable exploits and subsequent remote command. However, without an actual vulnerability with a developed exploit, the demonstrated methods are useless.
Researchers from WhiteHat Security presented on post-exploit methods within the newly developed Google Chrome OS. The new operating system replaces a traditional user desktop with the Chrome browser. Instead of installing applications, a user can install extensions that add functionality to the system. Like an application that runs on a Windows or Unix system, each extension has permissions to access only those resources that a user allows. Extensions control access via web domain or Chrome OS API, and users must grant access to those resources before the extension can run. If an attacker can locate an insecure extension that grants access to wide-ranging permissions, such as an extension designed to run as an RSS reader that requires access to the entire Internet, an attacker can leverage the vulnerable extension to violate cross-domain origin and interact within other domains on the user’s system. It is important to note that this is not a vulnerability within the Chrome OS itself, but rather a potentially insecure configuration that a user grants to a poorly developed extension.
Given the existence of an insecure extension, an attacker could conduct exploits very similar to many browser attacks on traditional operating systems. By convincing the user to follow a URL that uses the vulnerable extension, the attacker could conduct cross-site scripting or cross-site request forgery exploits. When an exploit is successful, the attacker could retrieve user cookies, download contact information, send spam e-mail using the user’s account, or even turn the user’s system into an active proxy and send network requests from the user’s system to other systems on the user’s network, allowing the attacker to gather information about internal systems. The researchers even demonstrated the ability to retrieve key information from the LastPass.com service by executing script in that domain to send requests on the user’s behalf and return key information to the attacker. This is not a vulnerability in LastPass.com, but rather an example of browser behavior that uses stored cookie information to process requests that seem like they originated from a legitimate user request but instead come from a malicious extension. The lesson learned here is that, as when using all other operating systems, users must be very careful about installing untrusted applications or extensions, and only grant permissions to trusted extensions, even on a system that is “just a web browser.”
From forensic researcher and instructor Robert Wesley McGrew, an individual who I have consulted with before in my Lessons From an Insider Attack article, comes additional methods for information gathering on compromised systems, particularly when an attacker or penetration tester does not have physical access to a system and wishes to quietly investigate the contents of drive volumes. The techniques are a synthesis of forensic and exploit methods, using the Metasploit tool and a custom Metasploit package to remotely mount fileshares in read-only mode to run information-gathering forensics tools on remote filesystems. In this way, a researcher or attacker could do forensic investigation on a remote system and discover information – even previously-deleted files – from a remote system. The main lessons McGrew had is to ensure secure file deletion, use drive encryption, and don’t be vulnerable to remote exploitation anyway.
The list of post-exploitation possibilities continues to grow, as attackers attempt to do more with systems already compromised. The emphasis continues to be on stealthy compromise, as in Ang Cui’s hard-to-detect modification of packets within the transmit queue of a device or McGrew’s demonstration of silent read-only access to drive volumes, and exploits and the activities after an exploit grow more difficult to discover. As system defenders, we must continue to employ defense-in-depth, separating exposed systems in an effort to shield from potential compromise internal systems with more-valuable data, and patching applications quickly, and securely developing applications to prevent vulnerabilities at the outset.