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).
