HeartBleeding An M2M Business Dry

HeartBleeding An M2M Business Dry

UPDATE 04/18/2014: The Nmap project has added support for HeartBleed detection. This will significantly increase the speed at which bad actors can detect and abuse this vulnerability. Conversely, it can also help administrators scan quickly for vulnerable systems!

UPDATE 04/18/2014: I've been alerted to the fact that several MVNOs are seeing a spike in network traffic on certain M2M APNs. They are attributing this to HeartBleed scanning. Please check your APN networks immediately!

In the Age of the Internet of Things, packets are king. By that, I am referring to the monetization of data in the IoT/M2M architecture. Most M2M service providers make money by charging for traffic. Each time an M2M end-point sends or receives data through the cellular network the MVNO makes money, which means the M2M technology company is charged. 

Unfortunately, in the M2M business model, this usually means that the charges trickle down to the user somehow. Do we stop and consider when an end-point or network is being attack, though? This scenario is largely considered an edge case and abnormal event. So, how would it be handled from a financial point of view? Well, that is dependent on the business model of the particular technology. Instead of speculating, let's figure out how a bad actor can use practical M2M attack models to forcibly drain money from the network while retrieving critical tokens using HeartBleed. 

The Lazy Bad Actor

The most obvious model is the unprotected M2M service. This deployment has servers directly accessible via the Internet. Attacking the M2M network in the fashion is simple. An attack against an Internet-accessible service requires no special equipment or code. Many software packages are readily accessible to perform this act, and I'm not going to bother getting into it here. 

The goal is simple. Penetration of the edge-servers allow access to the M2M deployment network. Particular interest would be access to the APN. If SSL/TLS services are active on the Internet-accessible servers, data could be exposed that may allow an attacker to impersonate users or M2M end-points. A simple example of this would be a model where mobile users can interact with their end-points through a smart-phone app. 

Figure 1. The Internet-based M2M Attack Model

If the App sends or receives credentials or session tokens, they could be leaked through abuse of HeartBleed. If this data is recovered through HeartBleed abuse, sessions can be created to impersonate these users. The result? Data will be routed through the M2M network and trickle-down through the APN to the end-points, causing the user or application owner to be charged for data transmissions.

A More Ambitious Attack

A more important model to evaluate is an APN-based attack against the M2M servers. This attack occurs over the cellular network, and typically involves a bad actor obtaining several pieces of necessary equipment: a cellular modem, a SIM or MIM card authorized for the APN. 

Obtaining a cellular modem is a non-issue, obviously. Unlocked GSM/UMTS/etc modems are easy to come by, and easy to use. Anyone can plug one of these devices into their laptop and have instant access to the cellular network. Which cellular network is the key, however. If the bad actor has the name of the APN and the right SIM or MIM, access is simple. 

However, obtaining a SIM or MIM is not as easy. A SIM card for a particular cellular APN must usually be obtained from sample or production equipment relevant to the device the attacker is interested in. For example, in my attack against the A-GPS device Zoombak, I was able to use the SIM card from an activated Zoombak to connect directly to their cellular network. 

Things get even more difficult when a MIM is involved. For those that aren't familiar with them, a Machine Identification Module (MIM) is the same device as a SIM, but in a different form factor. MIMs are designed to be soldered directly onto the PCB of a device. Therefore, to be abused they must be extracted from the PCB. They are typically quite small, and the adjusted form factor means that specialized hardware must be used to turn the MIM into a SIM. Because MIMs and SIMs have the same pins (just in a different form) they can easily be adapted using a bit of wire, solder, and patience. Regardless, this is a bit of an advanced attack as the attacker must have access to a heat rework station (or a hair dryer), a soldering station, and the know-how to rewire a MIM. Not an altogether simple feat. 

Once this is accomplished, however, direct access to the cellular network can be achieved. Because companies do not expect someone to go to these lengths to abuse their equipment or services, the networks are often wide open upon entry. Even if they aren't wide open, servers that are not accessible from the Internet must still be made available. Why? Simple. If you have a SIM or MIM, you are expected to be a piece of authorized equipment. Therefore, services for such equipment to function must be made available. 

Figure 2. The APN-based Server Attack

Now that the attacker has gained access to the APN, they can start to scan the network or flood servers with requests. In the case of HeartBleed, they may be flooding SSL/TLS servers with thousands of requests attempting to access the tokens of other end-points on the network. This is an extremely dangerous attack for several reasons. First, it will immediately cause a spike in network communication which will result in a high amount of charges being incurred. Second, if security tokens can be leaked, they can be used in the attack I will discuss in the next section. 

But, for the moment, lets focus on the money. Most M2M platforms allow you to identify if an end-user or end-point has a sudden spike in network communications. Some of these platforms even allow for disabling a user if a communications spike has gone over a certain threshold. These are great attributes of some popular M2M platforms, and they definitely help mitigate the risk of fraudulent charges due to network abuse. 

Thus, overall, in this model the attack can both be detected and mitigated. We can detect the network flood in real time, whether or not it is indicative of a HeartBleed attack is another story. If it is HeartBleed, the bad actor can be stopped by simply disabling the SIM or MIM's access to the network. Easy breezy, right? Close! 

The one gotcha is a slow and patient attacker. More and more end-points on M2M networks send and receive large payloads of metadata due to the devices, networks, or users they represent. These packets come in bursts, which is why network scans are so easy to detect. If the user mimics a device and leaks HeartBleed data slowly over a period of hours or days, they may be able to stay under the radar.

The Money Pit

The final attack model is the most devastating one. Depending on the M2M environment, HeartBleed can very well compromise the entire platform and cost a massive amount of money. How? It's actually pretty simple. Most M2M networks are centralized at the cellular link. What this means is, when you're connected to the APN, you're essentially in a private little cloud network. All end-points on the network will communicate through that APN. This means that potentially hundreds of thousands of devices all land on the exact same network at various times throughout the day. 

This was the case for both my Zoombak compromise and the compromise of the car security module in 2011. Both systems, per standard M2M architecture, resulted in every device in the United States landing on the exact same APN network. Why is this important? A set of servers on that APN will manage connectivity for every device. That means that if you are on the APN, you have direct access to these servers. What do they all use for communication? SSL/TLS, that's what. 

So if you know that hundreds of thousands of targets are going to land on the network at one time, you only need to compromise HeartBleed on one or more servers to slowly leak the communications tokens for a large percentage of devices on the network. 

Figure 3. Attacking M2M End-Point Devices

Sure, this is similar to the second attack presented above. It's about to get much more interesting. Why? The credentials captured via HeartBleed can often be used to speak to the end-point devices themselves. In other words, tokens captured through HeartBleed attacks can result in the impersonation of the server against the M2M end-points. Of course, this depends on the security of the actual devices. If the M2M architecture includes signed data for every application-level message, this attack wouldn't work. But, this architecture is not feasible (or necessary) for most deployments. It isn't reasonable to have small embedded devices performing CPU-intensive public-key operations on every message. Instead, a session token is most often used. Why? Because the communications link is secured by SSL/TLS, of course!

So now that people have proven that SSL private keys can indeed be leaked from a vulnerable web server, server-side verification in an isolated M2M environment is problematic. If the attacker can leak both the private key and session tokens, it's game over. Even if the MVNO can detect that an attack is in progress, it may be too late to do anything. 

In the above figure, we can see that messages can be sent from a laptop to end-devices through the APN. With the correct keys (private key and session token) the bad actor may be able to reconfigure devices, "upgrade" firmware, or simply gain remote code execution. Once this occurs, it's game over for the network. Why? You can no longer isolate the attacker. There is no way to know which devices are compromised without individual inspection and you cannot shut down the entire network. 

At this point, the operator is simply playing Whack-A-Mole against an attacker that has transparency and mobility throughout the entire APN. Game over. If desired, the attacker can flood the cellular APN from every compromised device, causing a massive spike in the amount of money charged to the M2M owner. Certainly the end-user cannot pay for the network's failure to contain a risk. Thus, the business deploying the M2M system will take on potentially damaging costs. Depending on the level of compromise, the MVNO/Carrier may even choose to reevaluate whether a device should continue to be allowed on the cellular network. This could be the critical one-two punch that takes down an entire business. 

 Mitigating Risk

Aside from the obvious audit to evaluate whether OpenSSL (or another vulnerable library/package) is being used on the M2M network, more must be done to ensure consistency on the network. An architecture review should be performed to identify how to contain a risk in the event of an edge-case such as HeartBleed. While many administrators and executives see HeartBleed as a rare scenario (and it is) it is absolutely not the only instance of this level of compromise. Although, in my opinion, it is the best example of widespread memory leak. That's a completely separate blog post, however. 

At Capitol Hill Consultants LLC, we specialize in architecture level security. We can quickly identify how to isolate or remove a critical risk in a core component such as OpenSSL, ensuring that the network, your end-users, and end-points, are not at risk. We can also help build simple metrics using existing data to determine whether an attack of this kind is being performed in real time. Scripts and apps can be integrated into existing alerting systems, or out-of-band security channels, improving the reaction time to critical threats. 

For more information, please reach out to our team via our website. 

Best,

D