Don't Put All Your Eggs in One Carton
by Dennis CoxFirst, some quick definitions:
An Exploit is a working version of code that takes advantage of a vulnerability in a product. The exploit could crash the product, or it could make it open for remote access (for someone to get into your computer).
A Vulnerability is a flaw in a product. A well known flaw in programs is a buffer overflow. A buffer overflow is when a program tries to give more data then the program it's talking with can handle. In layman's terms, let's say you try to put 13 eggs in an egg carton, one's going to fall and crack. You overflowed the carton. The carton can only fit a dozen eggs and when you put too many eggs in bad things happen. Let's go with the egg analogy for a bit.
Now imagine you work at the market and your job is to check every carton of eggs. So you decide if you see 13 eggs then you will throw away the carton. This works okay - but you are checking for the exploit not the vulnerability. If I put in 14 eggs, you won't detect a problem, since you are only looking for 13 eggs. A true vulnerability detection would be "if there are more then 12 eggs".
Most security vendors say they are vulnerability-based not exploit-based, however it is a rare vendor that can do mostly vulnerability filters. Luckily there is an easy way for you to prove this fact. Look for filters that are enumerated (exploit.1, exploit.2, exploit.3, or exploit.A, exploit.B, exploit.C) or go social media on them and search their blogs.
After looking around for a bit you'll quickly find that vulnerability filters are a rare find. The reason vulnerability filters are rare is because they generally require intimate knowledge of how the program works internally (source code). On the other hand, exploit signatures are trivial to create. If I know what the packet looks like, then I just match on that packet. An exploit is generally a fixed packet(s), which makes signatures trivial to write. Since they are specific, they do not provide as effective security as a vulnerability filter.
Certain companies literally do not know how to write vulnerability filters. The two main reasons are either the product they develop can't do the complex matching needed for a vulnerability filter or they don't have the skillset to create them. For example, in late October W32.downadup was released (popular name Conficker), everybody released signatures for it fairly quickly. In December another variant of the exploit came out. It bypassed pretty much every antivirus and IPS system. Those vendors then released new filters, and by mid-March two more variants were found, which bypassed all the same vendors again. Variant E (number 5 if you are counting) came out in April followed by the subsequent release of filters from most of the vendors. What does this tell us? First and foremost, people are not writing vulnerability filters. And secondly, you are not getting good protection out of the exploit signatures. To write an exploit filter (signature) you need to have a copy of the exploit in the wild. That means the exploit is already out and you are doing damage control not prevention.
Let me pick on some vendors for a minute. I picked these three because to be honest, they have the BEST websites for finding out this information. If you are a customer of the below, be happy, your vendor isn't trying to hide anything from you and they each have great websites to boot.
| McAfee |
|
CA | |
|---|---|---|---|
For those not listed, don't think it's because you made a vulnerability filter, it's just I didn't need more then three examples. F-Secure, Cisco, 3Com and I'm sure others all have similar information online with multiple releases of the filters to block Conficker.
Why is this all important?
You want a vulnerability filter. Every vendor will tell you that the perfect solution is a filter that blocks the vulnerability. With a vulnerability filter, you remove the need to update every time a new variant comes out. You block the bad stuff every time, no matter what.
BreakingPoint has the tools to test vendor filters to see if they provide adequate protection against threats. We do this by using a pseudo random number generator (PRNG) which you initialize with a value. This value is generally referred to as a seed. The PRNG uses this seed to generate random data in the parts of the exploit that doesn't matter - for example the first 12 eggs. Instead of sending 13 eggs over and over again, it will generate 14, 16, 204, etc., eggs.
The PRNG however is not actually random - it's pseudo random. If you look up pseudo in the dictionary it will say "not genuine; sham". That's right, it's not random - and that's good. We want you to be able to pick a number and generate the attacks (or application data) the same way every time. Meaning, if I choose seed "4" it will generate [20, 21, 2045, 657,...]. If I choose "5", it will generate [516, 352, 6246, 2657, ...]. This way I'm generating all variants, but in the same way. If you want something repeatable - always use the same seed.
It's possible to write signatures that are exploit-based but are smart enough to block future variants, and BreakingPoint testing tools allow you to prove it during product bakeoffs. But more importantly you can find out if their engine can handle any vulnerability filters.
