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

Abusing WiFi-Based A-GPS To Achieve Extreme Low-Cost Targeted Tracking

When security consultants and analysts consider the use of modern-day tracking techniques, they think of two things: tracking devices and mobile phones. And that's fair. GPS tracking devices, such as the Zoombak, are cheaper and more effective than ever before. However, as I demonstrated in 2011, tracking devices are often poorly designed, easy to reverse, and insecure. This means that they can not only be found remotely, but they can be hacked.

Mobile phones are always a significant vector for location tracking, as they commonly move with a target. But, what if the target is only exposed while using a burner? The MSISDN or software on the mobile endpoint may not persist beyond exposure, making the endpoint a less desirable resource.

Advances in technology, however, provide an interesting alternative to these solutions that has not yet been widely discussed by privacy advocates. Though, the pieces of the puzzle have been available for some time. A significant decrease in the cost of microcontrollers (uC) and wireless components, coupled with the increase in use of peripheral technology, provides an interesting vector for abuse.

What if, for a couple of dollars, a tiny device could be constructed that allows for targeted tracking? This article describes a simple example of how and why this is possible.

The Wireless Photograph

An interesting device crossed my path on Woot in the past few months: the Eye-Fi. This product is a simple SD memory card, like you would use with any digital camera. Models are offered that support flash storage of 4GB to 16GB, along with a more interesting storage option: wireless image delivery.

Eye-Fi 802.11 enabled SD Card

At 3.3V, the Eye-Fi product line integrates three chip components: a microcontroller, a flash chip for image and application/configuration storage, and a Marvell 802.11 wireless chip. The internal layout of the product can be seen in this FCC filing from 2010. From this information, it is easy to determine that the Eye-Fi is meant to act as a wireless client driven by the power of a digital camera.

When the camera saves an image to the Eye-Fi, the Eye-Fi SD card transparently uploads the image over a WiFi network to a laptop, phone, or other endpoint on the same network. While gimmicky as a SD card, this product is exceptionally inventive because of the way it exploits power from a host device.

Alternative Use Cases

While writing to the network is certainly an important feat, an aside to this article would be the use of this design for fuzzing/testing of devices that read from an SD card (such as a firmware update). Reads from the SD card could be cached from the network in order to test multiple variations of a firmware image without the chore of having to copy each new image to an SD card. I'm looking at you Travis Goodspeed.

Assisted GPS and WiFi

Regardless, the design of the Eye-Fi brings to mind another technology: Assisted GPS (A-GPS). A-GPS helps devices determine their approximate physical location even when a Global Positioning System (GPS) beacon is unavailable. As many technologists know, A-GPS has evolved beyond the analysis of cellular beacons for location derivation. Today, alternative signals can be used as location control as well, such as 802.11.

Google Street View Car in Action

I'm sure that everyone remembers Google's trouble with WiFi, Street View, and Privacy. Google, along with many other companies, use WiFi to ascertain the physical position of a mobile device when GPS is no longer available. This means that they were collecting a giant database of WiFi access points across several countries around the world. 

Samy Kamkar, a security researcher, came up with a brilliant application that abused Google's web API  and allowed anonymous users to query for 802.11 access points. Google responded by blocking Samy's application and restricting queries to only users that are known to be associated with particular access points.

The Access Point That Wasn't

So, let's presume users can't query devices that they aren't associated with. I'm sure this is hardly the case as even if Google has solidified this issue, custom databases like Zoombak's, Skyhook, and others, have had similar issues to Google's but are far less vetted by the security industry. Regardless, let's step back for a minute and presume this "hole" is patched. What does a researcher do? 

Well, systems like Skyhook and Google don't actually attempt to log on to random WiFi access points. Instead, they simply take note of the location of the beacon along with the access point name (SSID) and the address (MAC/BSSID). This means that the access point (AP) doesn't have to function. In fact, it doesn't have to do anything except emit a valid beacon. 

What if technology similar to the Eye-Fi could be designed to emit a fake AP beacon instead of acting as a client? The "Fake-Fi" could simply emit a beacon intended to be picked up by devices that would pass on the beacon name and MAC to another authority, such as a Google location database.

Selecting a WiFi network on Android

For example, Android and iPhone devices that see the beacon could upload data describing the Fake-Fi access point to a centralized database. This means that everyone in range of the Fake-Fi is helping tell the world where this beacon is located. This makes for an interesting tracking opportunity without having to use a large amount of power, cellular infrastructure, or other complicated technologies. The Fake-Fi can be driven with two simple chips (a uC and an 802.11 chip) off a 3.3V power source for the cost of dollars, just like the Eye-Fi.

The Result

Using this methodology, researchers can poison technologies that are more likely to stay present on an individual's person. A USB cable, USB dongle, mouse, mini-keyboard, laptop power adapter, wall wart, or another commonly trafficked device can now become a beacon.

This is an extremely hard to detect attack as the components used are small and thin enough to fit on a SD Card. There is a large amount of potential host technologies for this technique and few ways to effectively detect them. A user may notice the addition of a WiFi access point in their range, but will they presume it originates from their own equipment, or will they presume a neighbor is the source of the beacon? An attacker can diminish the potential for inspection by lowering the beacon strength of the wireless signal, making it look as if the source is farther away than it actually is.

A common Samsung microSD Card in an Android phone

The SD card in a user's Android phone can even be replaced with this technology, turning the phone into a proxy for the tracking beacon without the user's knowledge. How's that for parasitic technology?

Read and Store

An alternative and purely passive methodology would be to use almost the exact same formula as the Eye-Fi technology: WiFi client. Except, instead of connecting to WiFi networks, the software on the uC could simply log the access points and their frequency to the flash storage. Access points with higher frequency (occurrence) would identify a user's location and could be searched for using the same technologies: Google, Skyhook, etc. 

However, this purely passive tracking technique would require physical access to the target's devices at two exposure points in time, rather than one, significantly increasing the risk of the operation. 

The Take Away

At Capitol Hill, we believe that desktops, laptops, and even BYOD, are no longer the only risks a group or individual must monitor. Instead, security analysts must consider the applicability of each potential wireless endpoint as a source for malicious or parasitic behavior. And, analysts must consider that not all devices are known - or can be known - in a particular environment.

Discovering, cataloging, and isolating, the risks of the wireless world is a growing challenge. At Capitol Hill, we help organizations identify and mitigate the risks introduced by the Bring Your Own Radio world through our years of embedded engineering and security expertise. Our team will help define what practical threats mean to your organization, how they can be detected, and the most fiscally effective ways of removing these risks. Contact us today to determine if our services are right for your organization at: info at capitolhillconsultants dot com.

Best,
Don A. Bailey
Founder