Re: Detecting exploits/shellcode

[rgula () network-defense com (Ron Gula)]

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

> Jonas Eriksson wrote:
> > Is it possible to detect buffer-overflow exploits beeing sent
> > over the network, execpt for having a database of shellcode?
>
> The straightforward way (looking for strings) is pretty
> limited, but it's not impossible to detect buffer overflows.
> For example, NFR does it. ;) The way we do it is by protocol
> analysis - we monitor the complete protocol under inspection,
> so we know when/where buffers of unusual sizes make sense.
> For example, large buffers make sense in SMTP DATA but not
> in RCPT To:.

This may identify an anomaly, possibly an attack, but it doesn't
tell you for sure what the problem is. Using a string to match a 
known attack is also useful, especially if you have a large 
database of attack signatures. Of course it is real trivial to
modify an attack to miss a pattern match. Modeling protocols and
maintaining a large database of signatures can also be CPU 
intensive on very fast network links. I like both approaches 
and these techniques are implemented in Dragon, although the focus
is still on pattern matching. Another area of thought is not to
look for the attack, but to look for the response. We've placed 
a lot of effort into detecting what hackers do *after* they get 
in with an attack, which is also effective, but after the fact.

> As far as I know, we've got the only IDS engine that allows
> detailed enough analysis to do this kind of detection. For
> sure, you can't do it just by looking for strings. ;) We
> knew that years ago but everyone else only just now seems
> to be figuring it out. ;)

N-Code is pretty powerful, but what about Axent Netprowler's
SDSI? Is it robust enough to detect generic buffer overflows?
Bro from Mr.Paxon also seems like it would be powerful enough
to do this. Dragon does not model protocols as NFR, but contains
many simple signature constructs such as looking for a signature
such as 'USER ' in an FTP command session followed by more than
'n' bytes of code. If you have a protocol such as FTP or Telnet,
you can set 'n' to a number like 32 and catch a variety of 
weird stuff. Not all of it is buffer overflows. 

Other techniques for finding buffer overflows:

[*] I'm real tempted to talk about looking for 'non-ASCII' data 
    in ASCII dominated protocols such as smtp, ftp and http -
    but this is way to simple.

[*] A simple way is to look for long strings of NOOPs for target
    systems. For example, if you look at almost every Linux remote
    overflow, you will see a large buffer of x86 NOOPs in the 
    attack payload. Be careful as this string is also very common
    in GIFs and JPGs. This of course can be defeated by replacing
    the NOOP with some innocuous command like 'shift AX'. And in
    some cases, this technique can be defeated by looking at the
    stack offsets (those 0xffffbef0 addresses) used in overflow
    attempts. What this means is that for some protocols, like DNS,
    search for NOOP strings may have amazingly low false positives,
    but very high false negatives. 

[*] 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.

[*] Looking in system logs. Many newer versions of services such as
    IMAP, HTTP and SSH will tell you that they may have received
    data which could have been from an attack. This is excellent data
    for a host based IDS to look at and may indicate a network
    attack of some sort.  

[*] 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. 

Ron Gula, CTO
Network Security Wizards