[Bro] Bro MITM Detection

[Jim Mellander]

A couple of thoughts:

It seems that you would want to be looking for ARP poisoning directly, with
the MAC address changing.  IIRC, I've seen that happening under normal
circumstances with Apple TV, when it puts both the MAC address for both
hardwired & wireless on the wire.... Either a bug, or a feature, you
decide.....

Although Bro can generate events for ARP traffic (see
Bro_ARP.events.bif.bro), there are no policies in the current distro - bro
1.5 has ARP policies but they haven't been ported.

So the other part of your question is in relation to spurious TCP acks
containing different payload.  I haven't examined the bro source code in
detail for that circumstance (although I suspect it would be a bookkeeping
problem to maintain acked packets in the off-chance that a valid ack packet
with different contents is received), but the end host should be silently
rejecting acks for packets that already have been accepted - the first
valid packet (with correct seq #s) should win.

Also, with the randomization of ISNs in all modern OSs, this attack would
be difficult to accomplish successfully anyway, unless the attacker had
access to the span port in order to sniff the actual ISNs from the
traffic.  Of interest, however, would be if an attacker could spoof the
router's IP via ARP poisoning, and convince a host to route its traffic
through the attacker's box which would allow for payload modifications.
The span port would probably see a bunch of ARP flooding at that point.

Hope this helps,

Jim





On Mon, Sep 25, 2017 at 6:55 AM, Patrick Copeland <ptcnop at gmail.com> wrote:

> Hello,
>
> I have a question about Bro MITM detection. Here's the general scenario
> I'm curious about:
>
> Bro sensor is fed off switch SPAN port. Adversary has MITM on LAN using
> ARP cache poisoning with the goal of modifying responses. From packet
> capture you see that for every request, there are two responses (1)
> server->adversary (good) and (2) adversary->host (bad). The modified packet
> is identical except that it has a different src mac addr and the
> application layer has been modified.
>
> Right now Bro is parsing the original response but is ignoring the
> modified response. I can’t find anything in weird.log / notice.log to know
> that it is processing the second packet at all.
>
> Questions:
> - Would you expect Bro to parse and log both good resp and the modified
> bad resp?
>   - Is it application layer dependent?
> - Any thoughts about how switch SPAN configuration might affect Bro output?
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20170925/a402274e/attachment.html