How to crack private APN keys with hashcat

You may have read my post on hacking IoT vendors & smart cars via private APNs, where we looked at an entire attack scenario. This post is a distillation of that- getting at the private APN keys.

Step 1. Extracting the APN credentials

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.

For this you’ll need a 3G femtocell, and a “Network in a Box”. We sourced ours from Sysmocom.
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.

Step 2. 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.

Step 3. Password retrieval: Run hashcat against the MD5’ed p/w to get the plaintext

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.

Because it’s hashed with MD5 we can use 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!