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

I'm Hanging up! Prank Caller, Prank Caller!

People have been paranoid of telecommunications security in recent months. Why? Of course you know why. The news is overflowing with worldwide assertions of espionage, hacking, and the bitter taste of modern technological complexity. It's almost daunting, how our every day lives have become saturated by some absurd fear of a consuming, constant, ever-present eye.

And here we are again, faced with a vulnerability that exposes all of our most precious tokens to the massive potential for risk. Sad face yet again. Even Alyssa Milano has commented via Twitter on the importance of acknowledging this bug. Oh, HeartBleed. You've brought the world together in a concerted howl of paranoia.

But do we really fully understand the risk? Apparently not. What everyone (including me) had missed about this vulnerability is its less obvious usage: telecommunications.

The HeartBeat Extension isn't just used in TLS, it's also a part of the DTLS protocol. The DTLS protocol needs HeartBeat even more than TLS does. Why? It's connectionless. DTLS is designed to run over IP protocols such as UDP, SCTP, DCCP, and more.

Messages in DTLS are not guaranteed to arrive on the other end of the conversation. In other words, when Alice is on a phone call with her friend Bill and says "I'll hate your mother's cooking", Bill may actually hear "I hate your mother". In DTLS, this is normal, as opposed to TLS, which sits on top of protocols that protect against data loss during a session.

To protect against the potential for data loss, the HeartBeat extension can be used to ensure a peer in the conversation is still alive. This helps validate that when a message is sent over the network using DTLS, it isn't being sent to a dead host. HeartBeats verify that the peer is still alive and can receive messages. Whether that message will be processed is another story. Alice can at least guarantee that the other side of the conversation has received the data.

Why is this important? DTLS is very common in telecommunications equipment. In fact, the most common office phones on the market can use DTLS to secure phone calls. Cisco's SIP phone uses DTLS to ensure confidentiality and integrity of phone calls over a virtual private network to a VPN head. This means that any embedded telecommunications product that uses DTLS is potentially subject to the HeartBleed vulnerability.

This widens the applicability of HeartBleed to an entirely different infrastructure: worldwide telecommunications. The peering and internal infrastructures that route telecommunications messages, including voice calls, SMS, MMS, HLR, and more, often use SCTP for data transfer. To secure these messages? They use DTLS. This means that critical internal and externally accessible networks that route our most private telecom messages can be subject to HeartBleed.

This makes you think a bit differently about the vulnerability, doesn't it? From an architectural perspective, you can now compromise a high percentage of the two most important pieces of infrastructure in modern technology today: web/email services and telecommunications.

If you ask me, this makes the HeartBleed bug a much bigger threat than remote code execution against Apache or OpenSSH. With RCE you have to work to get the data you want. With HeartBleed? Just extract the session tokens or private keys you need, and let your automated tools do the rest of the work.

I mean, hey, if Alyssa Milano is tweeting about it? It must be legit ;-)

D

Blues for SSL

Blues for SSL

UPDATE 4/11/2014 @ 13:47 Mountain: Matrix has released version 3.6.1 to address the integer underflow bugs I found. Find the update here: http://www.matrixssl.org/news.html

UPDATE 4/09/2014 @ 20:51 Mountain: Matrix has acknowledged the bugs I've found and are formulating the appropriate patches. Stay tuned! These guys are quick! :-)

UPDATE 4/09/2014 @ 20:06 Mountain: Matrix and I are in contact. Quick response from them!

Even if you've been hiding under a rock for the past week, #HeartBleed has certainly found you. I had no intention to get involved, mostly because I have great respect for Neel Mehta that goes back years before his tenure at Google. Everything that needed to be said about this vulnerability was said. A lot. Too much, really. 

People have been flooding the TwitterFaceTumblerNets with screengrabs galore, rife with the champion hexadecimal dump, the solace of the SESSIONID mined from binary blobs. Ah, yes, it was a nightmare and a field day for techies everywhere. But, for guys like me, guys a lot lamer than they used to be, it was a pass-over. The necessary work had been done, and I had no business breaking any "cryptographically stone hearts" or wiping the blood of servers over their door. 

But, today, on my way to a finance meeting, it occurred to me that there was one thing left to prove. Embedded systems, to me, posed the greatest risk to Internet stability with respect to Heartbleed. As an Internet of Things enthusiast, I was concerned, and then relieved, by the architectural decisions of the engineers at various top-down IoT firms. It was likely that things were on the up-and-up. But, like I said, there was one thing left to prove. 

When I got home, I quickly audited the three most popular SSL implementations for embedded systems. Wolf/Cya, Polar, and MatrixSSL were all on the menu. The feast was short, unfortunately, because none of these implementations even bothered with the TLS Heartbeat extension. I had work to do, so I let these sleeping dogs lie. 

Then, I was shot with sudden inspiration: What if the bug had nothing to do with Heartbeat, itself? But, was - as we often see in information security - the larger issue of dealing with integers and memory buffers in the C language. Of course that was the problem! Why did I ever feed into the sensationalist bullshit that it was one single extension. 

So, I looked back at the MatrixSSL implementation. What did I see? Right off the bat, integer issues were indeed suspect. 

In the example below, the MatrixSSL source code correctly ensures that the size of the message buffer is suitable for the extension and its attribute size. There are two primary locations where this code comes into play. First, the entirety of the Extension buffer is checked at line 1969 in sslDecode.c. Feel free to follow along in the open version of MatrixSSL released earlier this week. 

                                extLen = *c << 8; c++; /* Total length of list */
                                extLen += *c; c++;
                                if ((uint32)(end - c) < extLen) {
                                        ssl->err = SSL_ALERT_DECODE_ERROR;
                                        psTraceInfo("Invalid extension header len\n");
                                        return MATRIXSSL_ERROR;
                                }
                                while (c != end) {
                                        extType = *c << 8; c++; /* Individual hello ext */
                                        extType += *c; c++;
                                        if (end - c < 2) {
                                                ssl->err = SSL_ALERT_DECODE_ERROR;
                                                psTraceInfo("Invalid extension header len\n");
                                                return MATRIXSSL_ERROR;
                                        }
                                        extLen = *c << 8; c++; /* length of one extension */
                                        extLen += *c; c++;
                                        if ((uint32)(end - c) < extLen) {
                                                ssl->err = SSL_ALERT_DECODE_ERROR;
                                                psTraceInfo("Invalid extension header len\n");
                                                return MATRIXSSL_ERROR;
                                        }

In the above code snippet, we can see the correct evaluation of the extension length. But, what's missing? Ah, yes. It's validating that the extension size doesn't exceed the boundary of the buffer, but it doesn't validate that the size is sensible. In other words, is the value large enough to hold information? That's also an issue that C coders often miss when dealing with buffers. 

As a result, the MatrixSSL code is indeed vulnerable to abuse. It is not even remotely similar to the level of importance attributed to the OpenSSL bug. But, this one deserves a high priority. I have reached out to the MatrixSSL support team and will provide them with the details of the attack as soon as they get back to me. When they provide a fix, I'll discuss on this blog exactly what the results of this issue would be.

NOTE FOR CLARITY: There is a lot more to the vulnerabilities I uncovered today than the code snippet above. My job isn't to leak that information, though anyone with a strong C auditing background can recreate what I've found based on the provided data in this post. I'm only publishing this because of the fast and positive communication I've had with the MatrixSSL team. I have no intention to expose the details of the bugs until they are patched. 

Best,

D