Blog: Internet Of Things
Compromising IoT vendors & connected vehicles by extracting & cracking private APN keys
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.
Sometimes, the IoT devices and vehicles we test only do IP traffic over cellular networks. A useful layer of security comes from using a private APN for that connectivity, you would think…
We found that private APNs are often hopelessly poorly configured, or one can simply use the device itself to compromise the APN, the data and then every other device on that APN. Yes, cars too.
Even on a private APN, you would expect to see client segregation, connection over a VPN to a single private IP or range, isolation from any internal corporate network and not giving access to the wider Internet.
The game changer for me is that it’s not just about corporate mobile phones using private APNs any more. One could just about trust the user not to leave their SIM lying around. Now, IoT and connected devices connecting to cellular APNs can be found just about anywhere. In your smart thing, in your connected vehicle, in industrial control systems for telemetry/remote management etc. All sorts of devices need IP connections over a cellular network and use private APNs.
Connecting to APNs
To connect to any cellular APN, the device needs three things:
- The AP name
- A username
- A password
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 bog-standard Ethernet interface on a smart device makes testing a bit more complicated, sometimes it can make it quite interesting.
Let the APN Credentials Extract Themselves
So, assuming a device is otherwise relatively tough to crack, how do we get the APN creds out of it?
Most of the time, an embedded device will connect to any 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 swap 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:
- What traffic the device creates, where it’s trying to connect to, and whether it’s encrypting its connections.
- 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?
- 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.
APN Authentication broken down
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.
So how do we get the password?
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:
Since it’s MD5, hashcat can blaze through it. 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!
But, who uses complex and long passwords these days anyway?
With this info, we can put the stock SIM card into a cellular modem, and connect to the APN with our cracked credentials. This hardware test just turned into an internal infrastructure assessment :)
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 remote outstations. They were physically exposed, so theft wasn’t difficult. Dismantle the device, extract the SIM, crack the APN key and we had access to the core network. That’s scary.
Another task we were working on is very large smart lighting system. Compromise of one device gave us access to the private APN, then every other device on the lighting network, then on the client network and then the IoT vendors network.
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 SRAM. Simply pull the keys from memory and compromise the network.
Exploiting private APNs in vehicles
Most modern vehicles have telematics control units. In Europe, the ‘e-call’ system makes these pretty much mandatory. 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 interested 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 potential from there on was enormous.
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. No dictionary words!
- Always ensure that whatever services your APN is allowing access to are suitably segregated from anything else important. Don’t, for example, attach it directly to your internal corporate network.
- Make sure access to your private APN is provisioned only to selected SIMs. You don’t want just anyone on that 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!