Computer attackers, both the evil ones and pro-penetration testers, increasingly rely on powerful exploitation...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
frameworks to launch their attacks. Free tools like Metasploit and commercial tools like CORE IMPACT and Immunity CANVAS have revolutionized the attackers' methodology.
In the old days, upon finding a vulnerability, the attacker either had to create custom exploit code from scratch or scour the Internet to find such code to exploit the hole. Today, instead of scraping together a bunch of individual exploits, these integrated exploit frameworks include around one hundred or more exploits to compromise target systems.
One of the nicest properties of the exploit tools from an attacker's perspective is the separation of the exploit from the payload. An exploit is the software that takes advantage of a flaw, letting the attacker load and execute machine language instructions [that is, a program] of the attacker's choosing. The code triggered by the exploit is known as the payload.
Old-fashioned attacks [from the era before exploitation frameworks] tightly bundled exploits and payloads together. You might have a buffer-overflow attack against a vulnerable FTP service, which would give the attacker command-shell access. Another attack might exploit a database buffer overflow with the purpose of adding a user for the attacker to the local administrators group. But, with this tight integration, the attackers were stuck with the given payload attached to the given exploit for the given vulnerability. Taking the payload from one attack and embedding it with another exploit required some serious machine-language fine tuning, and was often impossibly difficult.
To remedy this situation, today's exploit frameworks include an arsenal of different exploits and an arsenal of different payloads, each offering a different effect the attacker wants to have on the victim. So today, the attacker can use a tool likeMetasploit to choose an exploit [such as a buffer overflow in lsass.exe, originally used by the Sasser worm last year]. Then, the attacker can choose from more than a dozen different payloads. Metasploit packages the payload with the exploit, and then launches it at the target.
The real effect of these frameworks in separating the exploits and the payloads is now reverberating through our industry. Developers who create fresh exploits for new flaws don't have to reinvent the payload wheel every time. Thus, they can focus their time on perfecting their exploits and producing them much more quickly. What's more, those developers who don't focus on exploits can now zoom in on the production of really high-quality, massively functional payloads.
That's where we've seen the most dramatic evolution of quality -- the rise of extremely powerful payloads. While the "gimme-a-command-shell" and "add-a-user-to-the-admin-group" payloads are still out there, newer payloads bundled into exploit frameworks are better than ever.
The Metasploit framework includes several payloads worth mentioning. One of the flashiest is its Virtual Network Computing [VNC] DLL injection tool. This payload, which can be run against vulnerable Windows machines, inserts the remote GUI-control tool VNC inside of the vulnerable running process. The attacker can then remotely control the GUI across the network.
That's pretty darn powerful.
An even more interesting Metasploit payload is the Meterpreter. This little baby is a complete command shell environment which gets injected inside of a vulnerable running process. Attackers like to use this kind of payload for three reasons:
First, it's stealthy. Old-fashioned payloads started a new command shell process, such as a cmd.exe on Windows or a /bin/sh on Linux/Unix. But a diligent system administrator can discover such new processes by looking at the Windows Task Manager process list or running the Linux/Unix ps or lsof commands. By running a command shell inside of an existing process, no tell-tale phantom command shell process will reveal the attacker's presence.
Second, the Meterpreter lets an attacker stay entirely in memory if he or she wants. Instead of scrawling evil stuff on the hard drive for a later forensics analysis to turn up, the Meterpreter can run entirely in memory, making the tool much more subtle.
Third, some systems are configured to hide their command shell or to give it very limited capabilities. By injecting a complete command shell environment into a vulnerable process, the attacker will have all of the most useful commands available regardless of how the target machine is configured.
Another very promising Metasploit payload is called PassiveX. This one loads any ActiveX control of the attacker's choosing into the victim machine and runs it. When used by an attacker, the payload fires up Internet Explorer on the victim system, which could be a workstation or server system. The payload then makes IE fetch code in the form of an ActiveX control from the attacker's Web site, using normal, outbound HTTP. Once the ActiveX control gets loaded into the browser, it runs. This code then uses the browser to fetch other commands from the attacker and run them.
Why do this? Because most systems have a personal firewall configured to allow outbound connections by the browser itself. Thus, the PassiveX payload undermines the system from inside of its browser, giving the attacker inbound shell access via outbound HTTP requests.
That's pretty clever, and possibly very evil.
But all of the payloads we've discussed so far -- from simple command shells through the Meterpeter and PassiveX -- all suffer from one limitation: They have a predefined set of functions built into them when they are developed. What if the attacker wants something even more flexible, a magic payload that can do anything, even changing its function after it is loaded into a target system's memory? What could an attacker do with such a magic payload?
Such a magic payload does exist, and is included in the commercial tool CORE IMPACT. To understand this so-called "agent" payload, though, we need to quickly review how programs run on a local system.
When a program runs, it relies on user mode and kernel mode code. The user mode code is the program itself, doing what the program is supposed to do. But, when the program needs to access the hardware [e.g., to send a packet, read the hard drive, allocate memory, start other programs, etc.] it must make a call into kernel mode to invoke special software included in the operating system. These calls are named "system calls" and the magic payload relies heavily on this concept.
The CORE IMPACT agent payload injects a little software stub into the target machine. This stub receives system calls across the network. So in a sense, the victim machine has its kernel interface exposed, waiting for system calls sent from the attacker. The attacker can then run any program locally on the attacker's own machine. But all system calls made by this program are redirected, not executed in the attacker machine's kernel, but instead sent across the network to the victim.
When received by the agent payload in the victim machine, the system calls take place within the kernel of the victim system. Thus, the program runs [from a user-mode perspective] on the attacker's machine, but all of its interactions with the world around it happen on the victim machine.
Once loading the agent payload on a victim, the attacker can then run a sniffer [locally on the attacker's machine], and sniff packets going by on the victim's network. Or, the attacker could run a port or vulnerability scanner to look for other flawed systems, for the perspective of the current victim machine!
That's incredibly powerful, and lets the attacker take over one system and then pivot, using it as a base of operations to scan for and take over other systems. These new targets, then, provide a base to scan for and compromise even more victims. Best of all, the IMPACT agent runs only in memory, and can be transparently backed by the attacker without any evidence on the hard drive of the victim machines.
So the evolution of exploit frameworks is driving ever more powerful payloads.
What does this mean for you?
You need to be more diligent and quick about patching than ever before. With new vulnerabilities discovered almost daily in browsers, backup software, and services, you need a plan for quickly testing and pushing patches. Educate your system administrators about the urgent need to harden and patch their systems and make sure they have the knowledge and tools to do so.
If you perform your own vulnerability testing, you may want to consider incorporating an exploitation framework into your regimen. These tools can give you proof positive of a vulnerability's presence by actually exploiting it, eschewing the frequent false positives of traditional vulnerability scanners like Nessus. Be careful, however, when using these exploit framework tools. They often crash target services, so have someone standing by to restart them if things go awry.
About the author
Ed Skoudis is co-founder of Washington, D.C.-based security consultancy Intel Guardians and author of the books Malware: Fighting Malicious Code and Counter Hack: A Step-by-Step Guide to Computer Attacks and Effective Defenses.
Dig Deeper on Secure software development