full-disclosure - Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OFB335DDC3.8936B259-ON88256EA2.0059BB06-88256EA2.005E21BF@symantec.com>
From: oliver_friedrichs at symantec.com (Oliver Friedrichs)
Subject: Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

> I don't see how a broacast MAC address would help the attacker.  The 
> target would still recieve it.

I think you're missing his point, which is that IDSs that do not track MAC 
level state (and only track IP / TCP level state) are vulnerable to an 
insertion attack.  It doesn't matter what the MAC address is, as long as 
it isn't the target hosts MAC address.  The real host will throw out the 
packet due to a mismatched MAC address, while the IDS may process it as 
valid.  This seems completely plausible, and is just another form of an 
insertion attack (just like invalid checksum insertion, etc).  To 
accomplish this however, someone needs to have physical access to the 
target network in order to forge valid IP packets destined to another MAC 
address, at which point I would argue you have worse problems.  Granted 
they may be on the oustide of the bridging device, trying to get inside..

> The IDS will see not see a valid response to the "DATA" command (that is 

> never received) so it will know it is still in SMTP command mode.  Even 
> if your not-so-smart IDS let this slip by, there is still the issue of 
> "DEBUG" not being in a valid format for a header.

I think that this is going to be IDS implementation specific.  It depends 
on too many factors that I dont think it can be answered unless someone 
tests each product.  For example, a given IDS may be vulnerable to the 
following:

Take an IDS that is checking for valid responses before changing 
application protocol level state. After you have forged your DATA command, 
send a legitimate command to the SMTP server (one that doesn't cause an 
application level state change in the IDS).  This legitimate command would 
have the same TCP sequence number as your previous forged request. 
Assuming that the IDS will drop it as redundant, and that the server will 
receive (since in this case it is to its valid MAC address) it this time. 
The server responds with some 200 code.  Is that enough?  I would argue 
for some IDSs it probably will be enough to change state, since the 
arguments to 200 codes vary so much, they are probably just looking for 
anything that is modulus 200.  So then the state engine would be in DATA 
mode, not detecting the DEBUG command.

Disclaimer: I do not work with Symantec's IDS products, so please dont ask 
me what we do!

Oliver Friedrichs
Sr. Manager - DeepSight
Symantec, Inc. - (650) 381-8045