Re: sidestep

[Randy Taylor <gnu () charm net>]

Moderator: This is a re-post. The first one timed out on
your mailer.

At 12:20 PM 4/30/2003 +0100, Jill Tovey wrote:
> 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.

Dan didn't write a paper on his SNMP/Sidestep stuff. He did at least
some of the Dragon source code work for RPC, DNS, and SNMP evasions,
though. I just wanted to ensure Dan got props somewhere. 8) If you
ever get a chance to meet Judy you'll see right away why there can only
be one of her in the universe. (If there were two of her, the second would
consume all the remaining unused energy and space/time would grind to a
halt. 8)

Anyway, thanks for the credit - I'm still cheesed off at SANS, but that's
a recurrent condition for me - a long story I won't go into here. Check
the font I used for my GCIA submission. }->

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

I must have missed the email with the Snort alerts. Strange as it may
seem, I haven't used Snort for anything in...at least a year, and even
then not for more than an hour. And that's not a dig at Snort or its
team - at the time, I worked with Dragon pretty exclusively for obvious
reasons. Since I left Enterasys, I don't work in IDS internals at all. Sort
of a "been there, done that" thing.

> 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:

It's a standard portmapper/rpcbind dump request alright, at least at the
beginning. The evasion comes later in the dump. Your dump apparently
shows a misalignment, though, or I'm not seeing it right (don't have my
glasses on). The evasion starts at byte 51 (line 4, byte 3).

> 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?

Are you using tcpdump? I think bytes 49 and 50 (and maybe 45 to 50)
are junk stuff at the end of the first packet. Try Ethereal if you haven't 
already.
It'll show the frame start/end really well and do a nice protocol decode
during the frame - at least for standard RPC stuff.

Again, I hope this helps and that I haven't rambled on too much.

Best regards,

Randy



-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------