[Snort-sigs] false negatives with SID 1882 (userid)

Jon Hart warchild at ...288...
Sun Sep 7 14:29:09 EDT 2003


Howdy,

I had some problems the end of last week and this weekend where certain
attacks (legitimate or otherwise) were going undetected by snort.  Part
of the "attacks" almost always involved someone running `id` and
returning the uid/gid information for the compromised user.

SID 1882 does go off every so often for me, but not as much as I'd
like.  For example, a compromised webserver which returned user nobody
didn't get detected, so I did some investigation.

The rule in its current state is this:

alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES id
check returned userid"; content:"uid=";
byte_test:5,<,65537,0,relative,string; content:" gid="; distance:0;
within:15; byte_test:5,<,65537,0,relative,string; classtype:bad-unknown;
sid:1882; rev:9;)

All this rule is doing is looking for the string "uid=XXXXX" followed by
" gid=" within 15 bytes followed by XXXXX, where XXXXX is a number
between 0 and 65536.  

The problem is that 15 bytes is too restrictive.  Because 5 bytes are
already taken up by " gid=" and another two are taken up by the
parentheses following uid=, that only leaves a total of 8 bytes for
both the uid and the username.  On many UNIX based operating systems,
uids range from 0 to 65535, which means that in the worst case, there
will be only 3 bytes for the username.  

This explains why this wasn't caught:

uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

And this was:

uid=65534(nob) gid=65534(nogroup) groups=65534(nogroup)

I'm not sure what the best fix is here, because if we crank up the width
too far there may be too many false positives.  Howerver, 15 is
definitely not enough.  I'm currently experimenting with 25 which leaves
18 bytes for the uid and username.  However, I might be cranking this up
even further to account for a maximum of 32-character usernames on most
systems.

-jon




More information about the Snort-sigs mailing list