Hacking IoT vendors & smart cars via private APNs

Before we get into this, let’s be absolutely clear about what a private APN is:

A private Access Point Name (APN), which can be obtained from most mobile operators, is a service which can be used to capture all 3G/4G mobile data leaving a device, and route the traffic back to an IP endpoint at a corporate network (CESG).

Sometimes, the IoT devices and vehicles we test only do IP traffic over cellular networks. You’d think that using a private APN would add a useful layer of security, sadly, that’s not the case…

We found that private APN keys are often easy to compromise, or one can simply use the IoT device itself to access the APN without cracking the key. Once accessed, we could see sensitive data and other devices on that same APN. That included other IoT devices from the same vendor, other vehicles, and even allowed us to compromise internal systems on corporate networks.

Connecting to APNs

To connect to any cellular APN, the device needs three things. The AP name, a username and a password. You’ll be intimately familiar with these if, like me, you’re used to using over-the-counter SIM cards.

A provider might issue APN settings to your phone when you join the network. Or, more likely, they’ll provide the details online for you configure yourself. Different providers might use different APNs to provide services for tablets, desktops or phone traffic. Googling for “APN Settings” will net you a long list of public APNs for all kinds of cellular providers all over the world. You might also have found arrays of them in firmware dumps before. In any case, connecting to an APN allows a cellular device a route to communicate over IP, whether it’s to the wider Internet, or a private internal range.

And while sometimes the lack of a standard Ethernet interface on a smart device makes testing a bit more complicated, sometimes it can make it quite interesting.

Extracting the APN credentials

So, assuming a smart device that uses a private APN is otherwise physically secured, how do we get the APN creds out of it?

Most of the time, an embedded device will connect to any cellular network it can. That doesn’t mean a phone with a Vodafone SIM will connect to the O2 network. But it does mean that, if we can remove a SIM, we can swap out the stock SIM for our own and it’ll connect a network under our control.

Here at the office we’ve got a 3G femtocell, a “Network in a Box”, and some SIM cards. We got them from the good people of Sysmocom, who are doing the really cool work of open-sourcing 3G, as part of the Osmocom project. Thanks guys!

Once our femtocell and network are running, we can put a SIM card in the target device (being careful not to lose the stock SIM – we’ll need that later), and wait for it to connect to our network. This way, in lieu of a normal Ethernet interface, we can see everything the device tries to do over its cellular connection. We get to see useful things like:

1. What traffic the device creates, where it’s trying to connect to, and whether it’s encrypting its connections.
2. If it opens ports. Developers might assume a cellular-facing, private-APN-only interface is obscured enough to relax the security a bit. Telnet & a hard-coded root password, maybe?
3. Private APN authentication stuff.

The first two points don’t need to be covered here. There are plenty of resources online if you don’t know what to do.

APN authentication, however, isn’t talked about much. APN authentication over a 3G network takes place using the PPP CHAP protocol. CHAP was first proposed in 1996, was a precursor to MS-CHAP, and works using a three-way handshake: challenge, response, authenticate/reject.

Breaking down APN authentication

The Osmocom software running our mini 3G network currently ignores APN authentication requests insofar as it’ll just authenticate anything which tries to attach, with any APN name, username and password. But, the three-way handshake still happens.

If you tcpdump the authentication conversation, you can see it in action:

Here, we can see the relevant packets. In Wireshark, the authentication packet containing the actual meat is called (RUA) DirectTransfer (DTP) (SM) Activate PDP Context Request.

But where’s the password?

The APN name and the username can be found in cleartext, but not the password.

For a straight-ish answer, we’ve got to have a look at the CHAP RFC – RFC1994. It turns out, the CHAP Response Value is a slightly convoluted hash.

The Request Identifier octet (in this case, “0x01”), followed by the password, followed by the CHAP Authenticate Value (in this case “f3bcc7c0d43ff6a7dafcb4a7a388975d”), are concatenated and hashed using MD5.

Yes, it’s MD5

So, how do you recover plaintext? Hashcat!

Luckily, there’s an analogous mode in hashcat, designed for iSCSI CHAP hashes, which we can use to crack this. It’s mode number 4800, and it expects hashes in a format like this:

[ CHAP Response Value ]:[ CHAP Challenge Value ]:[ Response Identifier Octet ]

In our case, this turns out to be:

7e1062f19af0b4ff4611206457de99e4:f3bcc7c0d43ff6a7dafcb4a7a388975d:01

Hashcat can blaze through MD5. Weak passwords will almost inevitably get cracked this way; even the RFC from August 1996 suggests you use a password at least 16 characters long!

Our multi-GPU cracking rig benchmarks Hashcat at 10GHs-1 against MD5, so 9 chars upper/lowercase+numeric would take only 20 minutes or so to crack. That’s simple brute force, with no optimisation or mangling that could speed things up.

Even better, RainbowTables are available for most of the MD5 keyspace to 9 characters, or lowercase+numeric to 10 characters, even a simple wordlist attack!

How long & complex is your private APN key? Do you even know?

With this info, we can put the stock SIM card into a cellular modem and connect to the APN with our cracked credentials. Straight in to the client’s back end environment. This hardware test just turned into an internal infrastructure assessment over cellular ?

We’ve carried out IoT pen tests where we’ve compromised an organisations entire internal network through a smart device that was supposed to be isolated somewhere. I recall one access controller that used GSM/LTE over a private APN in physical exposed remote locations where theft wouldn’t be difficult. We dismantled the device, extracted the SIM, cracked the APN key and we had access to the client’s core network: they hadn’t considered private APN compromise as an attack vector.

Who needs their own 3G network anyway? There’s another method

IoT devices will often store secret keys in memory. Memory that is almost always unencrypted.

Even if one can’t dump the firmware, readout is often possible direct from RAM. Simply pull the keys from memory and compromise the network.

Exploiting private APNs in vehicles

Most modern vehicles have telematics control units (TCUs) that contain SIMs for mobile data. In Europe, the ‘e-call’ system makes these pretty much mandatory. Private APNs are used for the cellular communications to add security. However, the TCU is a very interesting device; often easy to remove from the vehicle and reverse engineer.
There are often security flaws with the TCU that makes compromise fairly easy. Hardware reverse engineering techniques are described elsewhere in our blog, but you may not even need these.

The problem is that there is often an extended supply chain for telematics. The OEM, the TCU manufacturer, the telematics provider and the connectivity provider. Any one of these can make mistakes.

During one test for a vehicle manufacturer, we were looking at the TCU. With physical access to it, we didn’t even need to crack the private APN key, as it was a trusted device. A look at the network that the TCU had access to was interesting and scary:

It was clear that a large number of devices were connected to it. We didn’t have authorisation to go beyond the car manufacturer that we were working for.

So, we simply made a reverse DNS request…

…and got back a whole host of DNS entries, most relating to vehicle manufacturers that had nothing to do with our client. Mostly German car brands…

At that point we stopped. Clearly there was a complete lack of segregation between vehicles and brands. The telematics provider had not even implemented client segregation between vehicle brands, let alone between vehicles.

The potential from there on was enormous. One remotely exploitable vulnerability in a TCU and you could potentially compromise every vehicle of that brand and other brands remotely, concurrently. It’s happened previously too – a compromise of a Renesas V850 processor in the Uconnect telematics system was the core of the Miller & Valasek Jeep hack. That hack didn’t involve a private APN, though it did take advantage of missing client segregation on the Sprint network.

We think the potential of an attack via private APNs could be more serious and widespread, if similar mistakes have been made.

I use private APNs for my products and services, what should I do?

If you’re using APNs in your connected devices, make sure you set both the device and the APN up securely:

• Always use authentication (some people don’t!) with an extremely long and complex password.
• Think hard about how you store and use that secret password safely. Consider also how you would recover if you found it had been compromised. A vehicle recall to replace all TCU SIMs would be frighteningly expensive
• Embedded SIMs (eSIM) offer potential for easier provisioning and recovery in the event of compromised APN creds. They’re also a little harder to remove from the host device as they’re soldered in place.
• Always ensure that the services your APN is allowing access to are suitably segregated. Don’t, for example, attach it directly to your internal corporate network.
• Make sure only selected SIMs are allowed access to your private APN. You don’t want just anyone on that cellular network to be able to access your APN.
• If appropriate, ensure that client segregation is in place as well, so that a compromised device can’t end up compromising other devices.
• Make sure that you’re not giving wider outgoing Internet access. You don’t want someone using a stolen SIM card to get free 4G internet through your APN!
• While you might think it’s private, it’s probably better to treat your private APN like a public VPN. Anyone with access to the SIM, can get into your APN!