He was wrong. The major IDSs rarely trigger on shellcode. Snort relies more on shellcode than many, but if you look at its signatures, you'll find that only a couple percent trigger on shellcode. When you restrict you analysis to just those signatures for the major vulnerabilities, I think that 0% of Snort's signatures use shellcode. The same applies to McAfee, Cisco, 3com, Juniper, and of course the IDS I created, IBM/ISS Proventia. I have probably written more IDS signatures than anybody else on the planet, and I have never written one that triggers on shellcode.
If an IDS does not trigger on shellcode, then polymorphic shellcode will not evade it. (An obvious point, but humorously, many people miss this).
An example of a signature (written in Snort syntax) would be the following for the Slammer bug:
alert udp any any -> any 1434 (\
msg:"MS-SQL version overflow attempt"; \
dsize:>100; \
content:"|04|"; depth:1; \
)
This signature does not trigger on the shellcode, therefore ADMmutate will not evade it.
While the high-end IDS avoids triggering on shellcode, low-end products do something else. One off the most common signatures in low-end products is just triggering on strings like "AAAAAAAA" that appear in proof-of-concept (PoC) exploits. These are non-functional exploits that do little more than cause a crash demonstrating that the "got execution" when it tries to execute code at 0x41414141. They then claim "0-day protection" for the vulnerability, and IDS-reviewers confirm that by testing with the PoCs. Again, polymorphic-shellcode won't really help evade these crappy products, because ANY real shellcode would evade them.
The most common signature for exploits isn't shellcode at all, but triggering on the shellprompt. For example, the Windows cmd.exe shell prompt displays:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Fancy IDS evasion tools like Core Impact, Metasploit, and Canvas still get caught because of shellprompt signatures. We recently added what we humorously called "Advanced Shell Prompt Evasion" to Metasploit to get rid of this nonsense. The humor is derived from the fact that launching "cmd /k" instead of "cmd" gets rid of the prompt, so it's not really advanced. The irony is that it actually does a better job of evading IDSs than ADMmutate does. There was a time when ADMmutate was important, but it that was half a decade ago.
5 comments:
I am a bit surprised that polymorphic shellcodes aren't used more considering how available they are these days. But I suppose it is true, why bother if just regular shellcode (which may be less error prone depending on the vulnerability) works just fine.
The few snort shellcode rules that are out there -constantly- trigger on false positives. For example the rule that looks for 0x90. Polymorphic nop sleds, or even plain nop sleds of a different opcode easily bypass this stuff.
The idea of alerting on a long string of 'a' is very laughable.
While "cmd /k" does prevent the DOS header information from being presented back over the network, I'd be interested to see how many other IDS vendors match on "C:\Program Files\..." or "C:\WINDOWS\system32\.." for the simple reason that the shell will still send the present working directory over the network.
I'm stumped to think of a valid situation in which those strings would exist un-encoded on the wire, outside of a few proprietary protocols I've seen.
** I wouldn't advocate building you defenses reliant on picking out the shell traversing the network, as you've already got a major problem when it's at that stage. Also the advent of Meterpreter with on-the-fly SSL encryption of traffic to a custom shell bypasses such sigs.
"I'm stumped to think of a valid situation in which those strings would exist un-encoded on the wire, outside of a few proprietary protocols I've seen."
I guess it depends on where your sensor is. I've seen these strings (and more!) when applications are deployed over the wire and even by inventory management systems. Apps downloaded over ftp or http also tend to have this characteristic (isos especially).
While I agree that you shouldn't rely solely on detecting shells, you shouldn't ignore it either. A good defense is spread out, to detect exploit attempts, exploit success and post-exploit activity (i.e. shells, c2 channels, etc). All network activity leaves some kind of network artifact.
You make a good point about signatures that trigger on a shellprompt.
However, and even though I wouldn't position IMPACT as a fancy IDS evasion tool but a pen-testing one, we actually don't launch a shell unless the user wants to. Exploits use a syscall proxying payload which does not need a shell to do stuff, so I'm surprised you actually saw that. One of the benefits of syscall proxying is actually not having to run a shell on the target.
In fact, I believe this also applies to Metasploit's meterpreter and Canvas, but I can't really speak for them.
Hi, I was the presenter and I didn't make either of those comments :p
I made a statement that said that COMPUTER ATTACKS are polymorphic, meaning (as you admirably show) that they can be performed in many sintactically different, but semantically equivalent, ways.
ADMmutate was just a quick example that most people know, and that explains the point. I didn't claim that I did "a test with a different engine", either. Did you attend someone else's talk or I'm worse in my English skills than I believed ? :)
The rest of your post is so totally and glaringly obvious that only a fool would not agree. Luckily enough, it was born just of a misunderstanding - and therefore, if you look closely at the remainder of my presentation, it doesn't influence a word of what is in it.
Thanks for the comment, even if I would have been glad to receive it on my email as well, as a form of basic courtesy ;)
Post a Comment