The MAPP program and zero-day protection is largely a scam. Vendors don’t use the provided PoCs to protect against the underlying vuln. Instead, vendors just write signatures that trigger on the PoC itself, but which are unlikely to detect exploits written by hackers that appear later in the wild.
In other words, MAPP’s PoCs are more likely to leak out and help hackers than they are to help IPS vendors.
Take, for example, the TippingPoint IPS. It is based on “pattern-matching” technology, which means most of their signatures trigger on known exploits rather than the underlying vuln. That means when they release “zero-day” protection, they are really just triggering on the MAPP PoC. Yet, they mislead there to customers about this. Their RDP advisory promises "TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 12138".
The truth is that the only zero-day protection they provide is against the MAPP PoC that was leaked to the Chinese hackers, not to the underlying vulnerability itself.
Not all vendors lie. Compare the TippingPoint inflated claims of protection with the equivalent Symantec RDP advisory which says "This signature detects attempts to exploit a remote code execution vulnerability in Microsoft RDP".
Sure, the language is a bit confusing, and can be interpreted as meaning “the vulnerability”. But the slight change in wording means that the only thing they are promising is protection against the one known exploit (the MAPP PoC).
To protect against the vulnerability, and not just known exploits, you have to write code that decodes the RDP protocol. The vulnerability is in the “maxChannelIds” field, which is encoded with “BER”. The typical encoding would look like “02 01 00”, but Luigi Auriemmia (the creator of the PoC) change the encoding to be “02 04 00 00 00 00”. This is how he knows it was his PoC – the packet used in the Chinese exploit contained all his changes.
Here is a list of some of the infinite number of encodings for this field:
02 04 00 00 00 00 02 01 00 02 02 00 00 02 81 03 00 00 00 02 84 00 00 00 08 00 00 00 00 00 00 00 00
Which of these encodings trigger the TippingPoint filter 12138? If only the first couple encodings trigger, then TippingPoint is lying about providing zero-day protection of the vulnerability. If all the above encodings trigger, then they are probably telling the truth.
Beware that you can’t actually use those 5 patterns I list above. The last time I made this criticism, TippingPoint simply added my patterns to their signature list, thus passing my test. So you have to use valid encodings of BER integers that aren’t already published. (You have no idea how irritating it is to reverse engineer a TippingPoint box only to find signatures that trigger only on a pattern discussed in a PowerPoint slide about how to change patterns to evade detection).
If somebody has a TippingPoint box (or any other IDS/IPS) that I can access remotely, I’d love to try this out. I’ll just grab the PoC, make some changes to the protocol, and see if the box triggers.
Full disclosure: I have worked with MAPP PoCs in the past. Back then, we struggled to create good "vulnerability" signatures that detected all possible variations. The process wasn't perfect, but we'd catch 0day exploits with different patterns about 2 times out of 3. This is far better than the crappy competing signatures that would trigger on the "AAAA" pattern designed to get EIP at 0x41414141 (i.e. hackers would have to change the pattern to something other than "AAAA" to get it to work -- which means by definition, the signature could never detect anything other than the PoC).
10 comments:
I totally agree with you from an IDS/IPS standpoint many vendors only write pattern matches for the known exploits at best they are playing catchup all the time. Decoding the protocol and adding real vulnerability detection algorithms is the only good way to add protection.
I do think POCs are useful for vulnerability scanners. If you don't have a POC or can't create on you have to do a patch check that relies on some credentials to access the target. This is not optimal for obvious reasons. A working POC allows a company to write a remote check that can determine the vulnerability of a host without credentials and use a non malicious payload.
Unfortunately the MAPP program is now only for products that do"ACTIVE software security protections" so that eliminates vulnerability scanners from receiving early info. I feel that products that could use the information for good have been unjustly excluded and the information is being used to provide a false sense of security form some IPS vendors.
I'm not sure that I follow how the Tipping Point IPS signature for ms12-020 has anything to do with MAPP. Tipping Point reported this vulnerability to Microsoft (via ZDI). I highly doubt that they waited for MS to turn around and release a MAPP update before building a signtaure. Furthermore, I would venture a guess that the Tipping Point signature triggers on more than a single POC. Idle speculation without even cursory levels of research is irresponsible.
Totally agree, although I wouldn't blame the MAPP program for this, but rather the vendors.
Instead of just copying and pasting the MAPP provided analysis into their signatures, they are expected to RESEARCH the vulnerability (which most times is almost spoon-fed to them by MAPP) and write appropriate protections (note that I'm not using the term "signatures").
But then again - It's like I would be saying that signatures are dead, and that's not news...
Poppycock. Have you actually spoken to anyone at TippingPoint about how their product or their signatures work?
Unlike the IPS products you have been involved in developing in the past, TippingPoint write the majority of their signatures based upon the vulnerability rather than simply a pattern match as you suggest. They do this to increase signature accuracy, deal with multiple versions of an exploit without having to update their signature set, and to reduce false positives. This is why you don't see them releasing multiple signatures for a single exploit every time a new variant comes out.
And I would love to hear more on how you claim to 'reverse engineer' a TippingPoint IPS....
As the previous poster notes, idle speculation is irresponsible.
And I would love to hear more on how you claim to 'reverse engineer' a TippingPoint IPS....
That would be my BlackHat 2007 speech, where I showed some of their signatures.
Unlike the IPS products you have been involved in developing in the past, TippingPoint write the majority of their signatures based upon the vulnerability rather than simply a pattern
That's a lie. The IPS I developed (BlcakICE, now sold by IBM as Proventia) had "vulnerability" signatures. When we marketed that fact, other companies like TippingPoint copied the marketing, but not the technology. When I reversed engineered their product and looked at their signatures, I found their story was full of lies.
Here's how you know Proventia has vulnerability-based signatures: it decodes the protocol and reports the vulnerability. If the issue is a buffer-overflow, Proventia triggers on the length of the buffer and not a pattern, AND THEN REPORTS THE BUFFER LENGTH. That's how you know it was a vulnerability signature and not a pattern-match. No other IPS does this.
"That would be my BlackHat 2007 speech, where I showed some of their signatures."
A lot has happened in 5 years.... TippingPoint now encrypt their signatures so that they can't be reverse engineered, according to people I have spoken to at HP....
bolding text makes me look louder.
That IPS is a scam does not mean MAPP is worthless. It's rather hard to write a signature, good or bad, without a sample to start from.
And -- much respect as I have for TippingPoint -- responding to "people are reverse engineering our signatures and finding out they're crap" with "well, now you can't reverse engineer them because they're Encrypted" says quite a bit. Anyway the encryption has to be worthless because at some point the execution engine needs to get them in plaintext. That means the key is sitting around on disk somewhere too.
In the information space, your job is to learn what your target is and comprehend it more than the person who set it up/developed it/etc. Like any number of mitigations, they're only designed to catch the attacker that doesn't know or assume their existence. Information Security as a whole is a complete scam, this is known. If it wasn't a scam, then when AV had evolved it'd have squandered the malicious software problem. Instead, through education and even third-party education (hi pentesting schools) we've made it even cheaper for someone to develop malicious software that cannot be defended against. We're training pentesters on how to avoid dealing with known defenses..this makes the world inherently more insecure.
Which leads to the secret of a good defense in an intangible world, is a better offense or better knowledge of other's capability. So, how to defend against a better offense? The only options are through misinformation and layered defenses. One reason being is that Layered defenses as well as misinformation is enough to increase the "costs" of your attacker. Every single high-profile intrusion was caught by misinformation. Lulzsec was caught because of misinformation, namely Sabu being trustworthy and discounting that he was contracted by the federal authority. Wikileaks was stopped by multiple defenses (sanctions?) that had been deployed.
Really, if you're interested in securing the world, stop flailing your arms wildly. The best thing to do would be to rewrite the rules the world has to abide by. This is what all the secure development initiatives are aiming to do. As an example, check out what browser developers have been doing for the new platforms. If you're not a developer then you're not doing anything to help your society, and instead you're pilfering off of it. See how Google's security team is securing the world? If you don't, you should pay attention to them. They've done more for the technology community than most consultants and they've done it by not talking, not selling, but by getting down discussing and rewriting the rules of our environment.
Rember, In the end..the one with all of the secrets wins. Welcome to a Marshall McLuhan prophecy.
Why is there no computer science injected into this debate? This is why the industry is so full of junk.
For a given vulnerability you're going to have a number of program states and inputs that can potentially reach the vulnerable code path. Unless your signature has taken each one of these into account then an attacker can probably bypass it. In order for your IDS/IPS signature to take each of these states/inputs into account you would have had to do some pretty in-depth research on the vulnerability and probably solved a static analysis problem along the way. The only party who has the time to research this for each vulnerability is your attacker, that is why defense is so hard. It should also be mentioned that fully decoding a protocol does not satisfy these requirements as your protocol decoding routines will not match that of the hosts you are trying to protect. It is impossible for an IDS/IPS to implement each protocol exactly the same way as each of its protected hosts.
That isn't to say IPS/IDS is worthless but its quite clear in 2012 that the '%100 zero day protection' claim just isn't accurate from *any* vendor.
Post a Comment