Re: Detecting exploits/shellcode

[vision () whitehats com (Max Vision)]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
On Thu, 15 Jun 2000, Ron Gula wrote:
> [*] Connection modeling. In some cases, connections to email or
>     web servers which last for several hours may be of concern.
>     This technique also has some false positives as a connection 
>     may be perceived as 'open' when the guy at the other end has
>     been kicked off. Looking for *active* sessions (transferring 
>     data) is still very interesting. This is an area of R&D for 
>     us at NSW, with the intent to see how useful it is to find 
>     "long" TCP sessions such as SSH.
This is really good stuff! Doesn't necessarily relate to buffer overflows
at all, but it's a good consideration. :) There are a few sessions that
are almost always short and would be very suspicious if they lasted over
more than a few packets... of course we are only talking about TCP since
that is the only place we can reasonably keep state and know it's a single
session.  We could take common "short exchange" protocols like dns,
finger, http, etc and get some statistics on large networks of how many
packets are typical in the exchange (from the client to the server).  
There are many protocols where this won't apply, like telnet, ssh, ftp,
rlogin, x11, pop3, imap, etc because lengthy sessions are pretty common
and vary widely.  There are others like smtp that have short sessions in
terms of time, because it's non-interactive, but lengthy in terms of
packets - some people send enormous emails resulting in hundreds of
packets.

This type of analysis requires an IDS with a robust tcp session reassembly
and tracking ability - I'm not aware of any free IDS that can do this,
althought it should be possible in post-processing of a tcpdump binary.

> [*] On some architectures, certain things in machine code may be
>     worth looking for all the time. For example, the command on
>     a sparc to setuid(0) in assembly may also be something you
>     want to look for in your DNS sessions, especially if you have
>     Sparc DNS servers. Looking for the same byte string in your
>     web served gifs, jpgs and zipped files is not a good thing. 
Full disclosure calls :)  I have gathered some information about common
sparc instructions that many exploit authors use to call setuid(0).  The
following intrusion signature will detect this traffic to a DNS server,
keeping with your example, for use with the free Snort IDS:

alert TCP any any -> any 53 (msg: "shellcode-sparc-setuid0"; content: "|82102017 91d02008|";)

I've done my share of virus research about a decade ago, and I'm all too
aware of how easy it is to get around this sort of detection.  Most single
instructions can be exchanged with other equivelents that accomplish the
same thing, and random "NOP"s can be added every other instruction to
throw off detection of any two instructions in a row.  Self-modification,
encryption, polymorphism, etc... but the idea isn't to catch everything,
just to detect known or very common attacks.

Here are some examples of sparc shellcode that accomplish setuid(0) -
taken from common published exploits in wide distribution and use.  Note
that these all share the common string shellcode signature that I've
created above.

from iss:
 "\x90\x08\x3f\xff"  /* and %g0, -1, %o0 - 0 in o0 */
 "\x82\x10\x20\x8d"  /* mov 0x8d, %g1 - 0x8d==141==SYS_seteuid in g1 */
 "\x91\xd0\x20\x08"  /* ta 8 - seteuid(0); */
 "\x90\x08\x3f\xff"  /* and %g0, -1, %o0 - 0 in o0 */
 "\x82\x10\x20\x17"  /* mov 0x17, %g1 - 0x17==23==SYS_setuid in g1 */
 "\x91\xd0\x20\x08"  /* ta 8 - setuid(0); */

cheez whiz/ADM:
 /* setuid:                                                 */
 /*  0 */ "\x90\x1b\xc0\x0f"  /* xor %o7,%o7,%o0            */
 /*  4 */ "\x82\x10\x20\x17"  /* mov 23,%g1                 */
 /*  8 */ "\x91\xd0\x20\x08"  /* ta 8                       */

unyun/shadowpenguin:
 "\x82\x10\x20\x17\x91\xd0\x20\x08"

horizon/humble:
 "\x90\x08\x3f\xff\x82\x10\x20\x8d\x91\xd0\x20\x08"
 "\x90\x08\x3f\xff\x82\x10\x20\x17\x91\xd0\x20\x08"

Job de Haas:
 "\x82\x10\x20\x17\x91\xd0\x20\x08"

Now, I keep using sparc examples, but this applies equally well to other
architectures.  I've just been spending a lot of time lately researching
and developing solaris exploits so it's on my mind.

Here are some x86 examples:

lamagra:
 "\xb0\x17\xcd\x80\xb0\x2e\xcd\x80"
 # setuid(0);
 movb $0x17,%al          # 0x17 = SYS_setuid
 int  $0x80
 # setgid(0);
 movb $0x2e,%al          # 0x2e = SYS_setgid
 int  $0x80

smiler:
 "\x31\xdb\x89\xd8\xb0\x17\xcd\x80" /* setuid(0) */
 xorl %ebx,%ebx /* zero the %ebx register, i.e. the 1st argument */
 movl %ebx,%eax /* zero out the %eax register */
 movb $0x17,%al /* set the syscall number */
 int $0x80 /* call the interrupt handler */

MayheM:
 "\x31\xC0" "\x50" "\x50" "\xB0\x17" "\xCD\x80"      // setuid
 "\x31\xC0" "\x50" "\x50" "\xB0\xB5" "\xCD\x80"      // setgid

So we have the following example signatures:

alert TCP any any -> any 53 (msg: "shellcode-x86-setuid0"; content: "|b017 cd80|";)
alert TCP any any -> any 53 (msg: "shellcode-x86-setgid0"; content: "|b0b5 cd80|";)

Those are so general and short that you aren't going to want to use them
to watch ports that often carry binary data.  However if you just watch
incoming traffic where plaintext printable characters are expected, this
will be effective: ftp/21, telnet/23, dns/53, http/80, pop3/110, etc...

There are a lot of things like this, but I feel I covered the core of
shellcode detection in my last post.  I think in almost every case where
you would see these setuid(0) shellcodes in an attack, you will also see
(1) abnormal data lenghth, (2) binary data where plaintext is expected,
(3) known shellcode, and (4) multiple NOPs.

Max

-- 
Max Vision Network Security        <vision () whitehats com>
Network Security Assessment         http://maxvision.net/
100% Success Rate : Penetration Testing & Risk Mitigation
Free Visibility Analysis and Price Quote for Your Network