Vulnerability Development mailing list archives
Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: Oliver Friedrichs <oliver_friedrichs () symantec com>
Date: Fri, 28 May 2004 10:08:10 -0700
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
Current thread:
- Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Oliver Friedrichs (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Bypassing "smart" IDSes with misdirected frames? (long and boring) Aaron Turner (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Mike Frantzen (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Srini (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)