Re: sidestep

[Randy Taylor <gnu () charm net>]

I looked at the RPC part of Sidestep for the Dragon IDS
a couple of years ago. Sidestep uses null-byte encoding
of RPC requests against portmapper/rpcbind to demonstrate
IDS evasion.

The gist of null-byte encoding is pretty simple - the heart of
the evasion is contained in the first four bytes of the RPC portion of the
packet. The first two bytes are called "Last Fragment" (LF). The
next two are called "Fragment Length" (FL).

(1) If LF and FL are both null, the portmapper/rpcbind state machine cycles in
an infinite loop. In that state, portmapper/rpcbind will eventually lock 
up, reject
any other requests, or both. This state is unanticipated in the protocol
specification.

(2) If LF is null and FL is set non-null - say 01 - then an RPC request can
be encoded across a finite number of packets. This is also an unanticipated
set of states because all inbound RPC requests are expected to happen
in one packet. Unfortunately, the protocol spec doesn't specifically
demand that.

Finally, if you intersperse conditions (1) and (2) above correctly, you can
create a perfectly valid RPC request of infinite length. And again, the 
protocol
spec doesn't anticipate this condition either. In my experiments, I got
bored around the 400 million packet point. The target machine did respond
correctly, but it took awhile.

The implications for IDS evasion are:
If the RPC algorithm in the IDS follows the exact specification of the 
protocol,
the IDS will get caught in either an infinite loop (condition 1 above), or 
potential
resource starvation while waiting in conditions 1 or  2 - imagine
processing a large number of condition 1 or 2 requests and you'll
see what I mean.

The answer for Dragon back then was a pretty simple algorithm which
examines LF/FL pairs to avoid (1) and (2) above yet still identify an RPC
evasion. We also had signatures for target machine RPC replies, so we
could correlate an inbound evasion against the outbound reply. You'll see
something similar in Snort source code from around version 1.8 I think.

Judy Novak did the DNS research on Sidestep for Dragon. Dan Roelker
did the SNMP piece, if I recall correctly, before he became a member
of the Snort/Sourcefire crew.

RPC, DNS, and SNMP were the thornier pieces of Sidestep at the time.
The rest of the evasions are really easy to understand. Just use Ethereal
and capture the "normal" Sidestep, the "-evade" Sidestep, and compare
them.

Judy and I, respectively, wrote papers for DNS and RPC evasions which Ron
had posted on the Dragon web site at one time. I doubt they are still there
due to the completion of the Enterasys assimilation process. If you want to
read them, maybe a Google search will find 'em somewhere.

Oh and by the way. I just discovered that the SANS URL you reference is also
almost a verbatim condensation of my original paper for Dragon, but does not
credit me. I reused the paper I wrote for Ron Gula and the Dragon Team for 
my GCIA
cert with the permission of Ron. The GCIA version of the original paper is 
off this link:

http://www.giac.org/practical/joseph_taylor_gcia.zip

SANS - if you're going to use my words, you should at least credit me, the 
Dragon
Team, and Enterasys - ok, me and the Dragon Team anyway.

Best regards,

Randy

-----
Truth is the most valuable thing we have. Let us economize it.
  --Mark Twain


At 08:06 AM 4/25/2003 +0100, Jill Tovey wrote:
> Hi All,
>
> I have a snort box and I am testing it using a tool called sidestep.
>
> For those that don't know, the tool works by allowing you to chose which
> type of attack you want, for example RPC, DNS, FTP etc and then run it
> with a switch such as -evade, which will perform the attack on the box
> and attempt to "evade" the IDS. The URL is
> http://www.robertgraham.com/tmp/sidestep.html
>
> Now I have run the tool with all of the possible attacks and it has
> worked fine, but it doesn't always manage to evade snort.
>
> So I am writing up the results of this for a project I am doing at Uni
> however, when it comes explaining how this tool tries to evade the IDS,
> I can't because, I don't know, and there seems to be no documentation to
> explain how it is working, and I can't look at the source code.
>
> So I wondered if anyone here knew how it worked, or had some info on how
> it worked.
>
> I have managed to find one article on sans detailing how it works for
> the RPC attack, which is very helpful,
> (http://www.sans.org/resources/idfaq/rpc_evas.php ) but nothing to
> explain what it does for the other attacks.
>
> Any info would be much appreciated.



-------------------------------------------------------------------------------
Can you respond to attacks based on attack type, severity, source IP,
destination IP, number of times attacked, or the time of day an attack
occurs? No? 
No wonder why you're swamped with false positives! 
Download a free 15-day trial of Border Guard and watch your false
positives disappear.

http://www.securityfocus.com/StillSecure-focus-ids2
-------------------------------------------------------------------------------