Bro MITM Detection

Zeek
1

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?
2

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