On Tue, 3 Apr 2001, Martin Roesch wrote:
> Yeah, I'm here. Basically what was described was code that
> auto-generates a decoder and then encodes the shell code to work with
> the generated decoder. I haven't taken that close a look at it, but
> there are a number of ways that we can use to pick it up.
>

I had a close look at ADMutate 0.7 (March 7th) but I haven't seen the
version used at the conference, or any version released since. However,
from what I have seen it may be possible to match small strings from the
intel_morpheng, sparc_morpheng, and hppa_morpheng structs in ADMmuteng.h

However, this approach isn't remotely as effective as the other shellcode
detection methods previously discussed. I had written a little about
shellcode detection in a post to the other IDS list:
http://archives.neohapsis.com/archives/ids/2000-q2/0163.html
http://archives.neohapsis.com/archives/ids/2000-q2/0157.html

A quick summary of the topics covered in the Detecting shellcode email I
sent earlier:
 o timing; short-exchange protocols like dns, finger, httpd, etc should
   only last for a short period of time or short number of packets.
   If these protocols exceed certain thresholds it could be a sign of
   intrusion (process overflowed and turned into interactive shell?)
   This idea was proposed by Ron Gula.
 o length; abnormal amounts of data sent where not expected. This is
   best handled by a plugin that can parse the protocol. Otherwise we
   could have a signature for each plaintext protocol keyword to
   watch for an overflow. For SMTP, we could watch HELO, MAIL FROM,
   etc etc where the "length" (as measured by the stream assembler)
   exceeded a value we thought reasonable. I believe IDS such as
   BlackICE rely heavily on this type of detection, and although
   more generic, probably catches more attacks.
 o binary data; there are many cases where we should not see any binary
   data. SMTP, FTP (command sesion), POP3, etc
 o multiple NOPs (obsoleted by the mutation engine)
 o known shellcode (obsoleted by the mutation engine)

However, these techniques still leave us dry when dealing with things like
detecting attacks against custom CGI scripts. How can we detect a
buffer overflow against a web CGI that normally allows large amounts of
binary data to be sent, where the attacker uses the ADMutate engine, and
does not spawn an interactive shell (timing becomes irrelevant)? We would
have to either create a rule/plugin to monitor the custom CGI, create a
rule/plugin to detect ADMutate, or find another means of monitoring the
application (host IDS or a wrapper probably).

There are other problems that are very similar to the one posed by
polymorphic shellcode, such as encryption and compression. There are
engines that accomplish these manipulations for some arbitrary assembly
code, but these are serious issues on their own even when not applied to
hostile code. Even if we are going to monitor encrypted exchanges such as
HTTPS (using the server's key), there is still the uncomfortable situation
of having the keys to decrypting secure traffic sitting on the IDS server.

One thing that should be clarified about ADMutate is that it's not really
a kiddy toy - it is a sophisticated proof of concept. It isn't very
likely that we will see a marked increase in polymorphic shellcode in
exploits in the wild. Hoewever, if ADM can resist the dark shadow of the
"AntiSecurity" nondisclosure movement and they continue to release
exploits, we might see them use the engine in their own stuff. :)

Max

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]