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]

From: jfbauer at nfr.com (Jim Bauer)
Subject: Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

On Friday 28 May 2004 13:08, Oliver Friedrichs wrote:
> > 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). 

And I believe you have missed my point.  The target host _will_ recieve 
the packet if the MAC destination address in the broadcast address.  
Now some stacks may be configured to drop such packets, but certainly 
not all.  Also if the interface happens to be in promiscuous mode, the 
MAC address could be most anything.

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

agreed.

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

It is quite possible the IDS will favor the latter "retransmission" over 
the original and see the attack.  That of course is IDS specific.  It 
might even detect the difference in the two packets.

A successful reply to a DATA command is not 200 something.  I get 354.
Because DATA and DEBUG have different success responses, is why this 
won't (or shouldn't) work.

If you really want to make this interesting, start forging server 
replies. to the packets it never receives.