The Armis research team has discovered novel methods to exploit a vulnerability in Ethernet cables, which was previously considered non-exploitable. Dubbed “EtherOops,” the attack vector includes methods to exploit packet-in-packet attacks in Ethernet cables. These methods can be used to bypass perimeter security devices such as firewalls and NATs. Bypassing these defenses can allow attackers to mount various attacks to:
Although this attack vector is complicated, and would likely be exploited by sophisticated attackers (such as nation-state actors), it targets the most basic element that is used in all networks – the Ethernet cable. In some ways, the Ethernet packet-in-packet attack may resemble some of the traits that are sometimes attributed to speculative execution vulnerabilities. On one hand — it is a very complicated attack that requires certain prerequisites to pull off. But on the other hand, an attack that targets a fundamental component which we fully trust in our digital lives — the CPU itself, in the case of speculative execution vulnerabilities, and the Ethernet cables used in our networks, in the case of EtherOops. Both attacks require some ingenuity to pull off, but if successful an attacker can leverage them to break through very powerful barriers.
Ethernet (a.k.a IEEE 802.3) is the underlying protocol used to transfer packets within internal networks, and it has been around since the 1980s. Not only is it the data link layer used by Ethernet cables (sounds about right :P), but it is also the basis for the MAC addressing scheme used by Wi-Fi. Wi-Fi access points connect to the network using Ethernet, and part of their role is to convert the Ethernet frames from the wired network to Wi-Fi frames over the air. So, both wired and wireless networks rely on Ethernet.
The design of corporate networks consists of layers of barriers (firewalls, NATs), relay stations (switches, routers), and endpoints. And the pipelines that connect these elements (in most cases) are Ethernet cables. A very basic underlying assumption that exists in this design is that an Ethernet packet that is sent from one point to another will either be received as is, or it will be dropped. Packet-in-Packet attacks challenge this underlying assumption, by abusing edge cases in which a packet may change en-route, and still be processed on the other end as a valid packet. When these edge cases occur, a packet may pass through a Firewall, for instance, as a legitimate, benign packet, and later on be re-interpreted as a new packet that might also be a malicious one.
Ultimately, if an attacker is able to send a fully controlled Ethernet packet within an internal network, he or she may have a great hazardous potential. This is due to the expectation that internal networks are considered a “safe-zone,” in various ways. But they are not always “safe.” For example, attackers may be able to abuse DNS and proxy configurations, that are by design distributed to endpoints via unauthenticated broadcast packets within the internal network, and thus gain a Man-in-the-Middle position on web traffic, and use it as a foot in the door to further their attack.
An Ethernet packet-in-packet attack works by relying on the fact that when bit-errors randomly occur in transmissions, an attacker can leverage and abuse them to inject fully controlled packets when they occur in a certain way.
How an Ethernet Packet-in-a-Packet Attack can work
The following is how such an attack could happen:
These three steps are the basis for Ethernet packet-in-packet attacks, and while there are quite a few prerequisites for this attack to work, it can enable an attacker to send fully controlled Ethernet packets within an internal network, bypassing it’s perimeter security devices (firewalls/NATs). Due to the fact this attack relies on random bit flips occurring in transmission, it’s reasonable to assume that an attacker that exploits this method would aim to gain a foothold in the network, using a single injected packet. This may be achieved by exploiting certain RCE vulnerabilities, that may be triggered by a single broadcast packet (such as CDPwn, and URGENT/11, but others exist as well). In addition, an attacker can exploit certain design flaws that are inherent to how networks work, and establish a Man-in-the-Middle position on DNS and HTTP requests of the various endpoints within the network. This can be established by abusing certain broadcast IPv6 packets, for instance (more on that in our technical white paper below).
But before an attacker is able to inject Ethernet packets using this attack, he needs to jump through several hoops that this attack relies on.
As described above, there are a few prerequisites that are needed for this type of attack to be successful, and this is why it is more likely to be exploited by sophisticated attackers. Some of these prerequisites were considered impossible to overcome in the past, and our research had discovered various ways in which they can be challenged.
1) Sending benign packets through the Firewall/NAT
The first step of this attack requires sending a stream of benign packets, through a firewall/NAT, in the hope that one (or more) of them will later be corrupted in a certain way that will trigger the packet-in-packet condition. To be able to send a stream of packets through the firewall/NAT an attacker can choose one of two attack scenarios:
2) Occurrence of bit-flips (or: Bad Cables)
For this attack to work, bit-flips need to randomly occur on target Ethernet cables. In fact, the belief that these are unlikely to occur in wired cables is what led researchers in the past to dismiss this type of attack. At a Black Hat talk back in 2013, titled “Fully arbitrary 802.3 packet injection”, the researcher deemed this attack impractical, due to the following reason:
“…the reliability and extremely low error rate of wired cables make it [the Ethernet packet-in-packet attack] unrealistic.”
We performed a survey on Ethernet cables throughout a wide variety of organizations in which Armis operates, to find out whether this common belief is true. We were surprised to discover that imperfections in Ethernet cables are actually much more prevalent. Leveraging data from about 500K switch ports used in enterprise networks, we found that about 3.7% of them experience a significant amount of bit-errors. According to the industry standard, the maximum allowed bit-error-rate (BER) in Gigabit Ethernet cables, for example, is one bit error in 10 billion bits. The high-error-rate cables identified in our survey are ones that experience a BER that is greater than this maximum BER, as defined by the industry standard. In these types of cables, a packet-in-packet attack can occur within a reasonable time (hours or less).
When imperfect cabling exists in a network, a fully remote attack can be executed, and rely on the fact that bit-flips would occur on such cables. Those bit flips would allow an attacker to gain entry past the firewall and NAT. Once on the network, the opportunities increase for device manipulation or data exfiltration.
When we looked across different segments of our install base, we noted that the rate of error varied between them:
High error cables increase the likelihood of exploitation by an EtherOops attack.
As defined above, high-error-cables experience more than one bit error every 10 billion bits.
In Gigabit Ethernet cables that experience a medium amount of errors, a bit can flip once every 10 seconds, and a packet-in-packet condition can then occur within hours. In Gigabit Ethernet cables that experience a high amount of errors, a packet-in-packet condition can occur within minutes!
One way for an attacker to overcome the prerequisite of bit-flips randomly occurring in Ethernet cables is to simply target an organization that might use imperfect cables, and hope the benign traffic that he sends to the network traverses through one of them. An alternative method that relies on an ability to induce bit-flips in non-faulty cables is also something that we’ve explored (more on this later).
3) Checksum manipulation (or: Finding out internal MAC Addresses)
When bit-flips do occur on an Ethernet transmission, a checksum mechanism exists in the framing headers of Ethernet, that is there to detect such bit-flips and drop corrupted packets. An attacker that attempts to exploit Ethernet packet-in-packet attacks can overcome this mechanism by causing both the inner packet (the one that will be re-interpreted as an entirely new packet) and the original packet to have the same checksum. This can be done, if the attacker knows the entire content of the Ethernet packet in advance, so he can anticipate the value of this checksum.
To achieve this, the MAC addresses of the target device and its nearest router must be identified. However, that is nowhere as impossible as it may sound. MACs are not a secret. Here are a few examples of how MAC addresses can be identified:
As detailed in the section above, one of the attack scenarios that leverages the Ethernet packet-in-packet attack is a 1-click attack scenario. This scenario starts with an attacker sending a malicious link to a user inside a target network that leads to an attacker-controlled website. The browser on the user machine will send packets outbound to the attacker’s server, which would allow the attacker to send a stream of benign packets back to the target that will traverse through the network.
The attacker in this scenario operates from the Internet, without needing to be in physical proximity to the target. However, it does require that the attacker has obtained knowledge of MAC addresses from the target, prior, and that one of the cables in which the benign packets traverse through experience enough bit-flips, so the packet-in-packet condition will occur.
In the demo presented below, the above scenario takes place. Once the attacker is able to inject an Ethernet packet to the internal network, he abuses the aforementioned IPv6 packet (IPv6 Router Advertisement) to create a Man-in-The-Middle position on all Windows devices in the LAN – by registering a fake Search Domain and abusing the Windows Proxy Auto Discovery (WPAD) feature. This can lead to more control over the network, and devices, by using the established MiTM position. It is important to note that both IPv6 and WPAD are enabled by default in Windows devices (even in an IPv4 network).
While our research showed that faulty cables are susceptible to normal, reasonable background electromagnetic interference (EMI) noise, we did ask the question, “But what about unreasonable noise?” We hypothesized that an unshielded cable, carrying an already attenuated signal, may become susceptible to higher levels of EMI. It is somewhat known that there are certain devices that emit an electromagnetic pulse which can cause this type of disruption – EMP weapons. These devices commonly use wideband pulses between 100MHz – 2GHz to interfere with any cabling longer than 5 centimeters or so.
By studying some public research available on EMP “simulations,” we were able to create our own, small scale EMP device, to conduct a controlled experiment. We needed to design it to do the following:
The result was something that resembles the spark gap radio – the earliest type of radio transmitter, invented in the late 19th century! It transmits wideband pulses at around 100MHz in very short pulses (5-10ns) at high power. The discharges happen at a rate of 1-2KHz or so. Warning: Don’t make this at home, it’s quite dangerous!
Proximity EMP device, active and emitting short pulses.
We were able to record the impact of this EMP device on an unshielded, but also non-faulty Ethernet cable, as seen in the figure below. The blue and yellow are the induced voltage in 2 wires of an Ethernet twisted pair, 10m long. Purple is the differential signal. Despite the use of a twisted pair, the strength and variance this pulse creates causes a significant voltage change on the differential signal, which leads to the introduction of bit errors.
Recorded impact of the EMP device on an Ethernet cable’s twisted pair
As described above, creating a zero-click attack scenario in which benign packets pass through a target network’s perimeter security defenses (firewall/NAT) is possible if the attacker is able to spoof a DNS reply from the IP address of a target’s DNS resolver. However, detecting that his attempt was successful requires a side channel — the solution for this problem is to combine a physical proximity element in the attack:
Example of a Controlled Experiment of a Proximity EMP Attack
The steps to perform this attack are as follows:
Lastly, once an attacker is able to inject a fully controlled Ethernet packet inside the network, he can carry out any of the single-packet attacks detailed earlier in this blog — either reaching RCE on a vulnerable device, by using a vulnerability that may be triggered with a single broadcast packet (such as URGENT/11, CDPwn, or others), or gain MiTM position on DNS and HTTP traffic by abusing certain broadcast IPv6 packets.
A successful demo of this attack was conducted in our lab:
In addition to this detailed blog, we are also releasing a whitepaper that dives deeper into the many technical aspects of this research.
As much of our research has shown, the internal network should not be considered a “safe zone.” There are multiple vectors attackers will use to bypass perimeter security defenses. Here we looked at the fundamental elements of the Ethernet cable, when faced with potential bit-flips that occur naturally, due to imperfect cabling, or due to a more sophisticated and targeted EMI attack. Although the concept of packet-in-packet in Ethernet was already identified in 2013, back then it was deemed an impossible attack. Our research reveals various ways in which it is a possible attack. Complicated? Yes, but not impossible.
The most surprising element of this research is that network performance issues, such as the number of bit-errors experienced on a network’s cables might also pose a security risk to the network itself. This requires us to develop mitigations in the network infrastructure that deal with this specific attack, but also offer better ways to detect any edge cases that might arise in Ethernet communications.
As always, further research is required. For instance, our controlled experiment, using an EMP device to induce bit errors on non-faulty Ethernet cables, was not tested to the extent of this capability. We do not yet know whether this capability can become a dangerous and effective weapon if perfected, and what is the maximum distance in which this attack can be successful. A better understanding of how EMI attacks can impact Ethernet cables is far from complete.
In the meantime, Armis customers can now identify switches that have active ports with significant error rates, and mark these ports with a risk factor, from a possible Packet-in-Packet attack:
EtherOops Risk Factor identified in the Armis Console
If you are interested in additional information about EtherOops, contact us at [email protected].
Sign up to receive the latest news