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.
