Re: sidestep

[Jill Tovey <jill.tovey () bigbluedoor com>]

Hi,

Yes, I am not sure my last email with my tcp dumps made it to the list.
I have credited both you and Judy Novak on my paper, I can't find Dan
Roelkers though. Anyway, thanks for sending that info through.

My last email showed the alerts snort had created from using sidestep in
both normal and evade mode.

It differs from your paper because when I generate an RPC request in
evade mode, the alert appears in my snort log with the same first 40
bytes as when run in normal mode, which is why I am having trouble with
your explanation.

It makes sense for your paper because it produces a 00 00 00 01 00 00
etc and so cycles in an infinite loop, for me it shows 80 00 00 28 00
etc.

Here is the hex dump of the packets created by the rpc request in evade
mode:

80 00 00 28 00 00 00 00 00 00 00 00 00 00 00 02  ...(............
00 01 86 A0 00 00 00 02 00 00 00 04 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
01 00 00 00 00 01 00 00 00 00 01 02 00 00 00 01  ................
00 00 00 00 01 01 00 00 00 01 86 00 00 00 01 A0  ................
00 00 00 01 00 00 00 00 01 00 00 00 00 01 00 00  ................
00 00 01 02 00 00 00 01 00 00 00 00 01 00 00 00  ................
00 01 00 00 00 00 01 04 00 00 00 01 00 00 00 00  ................
01 00 00 00 00 01 00 00 00 00 01 00 00 00 00 01  ................
00 00 00 00 01 00 00 00 00 01 00 00 00 00 01 00  ................
00 00 00 01 00 00 00 00 01 00 00 00 00 01 00 00  ................
00 00 01 00 00 00 00 01 00 00 00 00 01 00 00 00  ................
00 01 00 80 00 00 01 00

Can anyone help explain this?


On Tue, 2003-04-29 at 19:17, Randy Taylor wrote:
> 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
-------------------------------------------------------------------------------