Baseband processors will probably be the top future exploit target, now that mobile is exploding. These processors are the central interconnect between microphones, the GPS and a bunch of other periphery on a smartphone (any phone, really). They run propietary binary blobs on mostly lower end ARM-SoCs, and due to their nature, most any exploit will be <i>remote</i>, and you will have a high-bandwidth uplink to share the spoils.<p>The binary blobs are usually some variant of a homegrown RTOS system, written in <i>C</i>. Given the low end processors used, there is no isolation between processes (no MMU), and the complex 3G et al signalling has lots of nasty error paths and interrupt goodness.
This is a simple race condition exploiting the baroque way that GSM signalling works. When a call (or an SMS) comes in:<p>* the basestation will send an alert to the mobile phone ("contact me, I've got something for you")<p>* the mobile phone will request a channel ("hey, lets talk")<p>* the basestation will allocate a channel ("yo, talk here")<p>* the mobile phone will authenticate ("its me, TMSI:xxxxx")<p>* the basestation will lookup pending signalling ("oh, got something for ya")<p>That is the very rough outline of how GSM signalling works. My guess is that the basestation will clear the pending signalling for the mobile phone <i>even</i> <i>if</i> the authentication fails. So an attack can pre-allocate a bunch of channels and then send spoofed auth messages to the basestation. The attacker won't be able to actually authenticate because they don't have the Ki (the GSM keys stored on the SIM). This is just a race condition, and it seems like it would be noisy for the telcos' ops center which would receive a lot of alerts about failing authentication and call/sms delivery failures.<p>I haven't read the paper, but thats a guess as to how it works. There are loads of ways to DoS the basestation. This doesn't seem that exciting.
Someone more knowledgeable than me, please correct my presumptuous understanding, because this seems easily mitigated.<p>I would imagine that, like with your home network, cell phones have multiple addressing schemes in a network. So there's your phone number, but there's also some kind of network address that I have received from the carrier, and then probably some kind of address that refers to my connection with the tower.<p>I would assume that something similar to ARP goes on here. A message comes in for 415xxxxxxx, my phone. When AT&T gets it, they determine that phone number is network address 1234, and they have some system that says 1234 is currently in tower X. Tower X gets the message and broadcasts a request for the phone corresponding to device 1234. At this point, pirate device with tower address ABCD responds that it is, falsely, AT&T's 1234. The message is then sent to the the phone whose address in tower space is ABCD. My phone was actually DEFG but I couldn't reply fast enough.<p>So, if this pirate phone responds to multiple requests, for multiple AT&T subscriber addresses, claiming to have all those addresses, can't the tower just cap it at like 3 addresses? After that can't it be determined to be a pirate device and disconnected from the network? If one device claims messages intended for more than 3 addresses, isn't it safe to say it's faulty or spoofing?<p>Where am I wrong here? It seems like this level of ability should be built into a protocol that requires recipients to identify themselves? Like if I issue an ARP request on my Ethernet network, and the same MAC address always comes back, that would be a detectable attack (assuming it was not my gateway). Isn't this the same principle?
This talks about screwing around with the network by acting like another phone to do denial of service. Can't you achieve the same result just by transmitting noise on the same frequencies? If you're blasting out paging responses, won't that be just as "easy" to track down as transmitting noise?<p>Modifying them to intercept calls/SMS is more threatening, especially as GSM and SMS look like attractive protocols for doing mobile apps and payments in "developing" areas.
I am surprised that the baseband paging firmware code is closed and has not already been reverse engineered. And if so, it is surprising for me as to why have we never come across any attack like this in real life.
Does anyone know if CDMA is vulnerable to the same paging hijack?<p>I know that Verizon here in the US registers the ESN/MEID of the device itself for service provisioning (with a SIM only being used for GSM roaming and LTE).<p>I would guess that CDMA doesn't have to 'page' to find the right phone (though it might ping to see if it's still connected / in range) as the phone's ID is already associated with the number (no need to query a SIM).
This will be responsible for a few deaths if it ever becomes widespread. The obvious way is by preventing people from calling 911, but the other way, potentially just as deadly, is preventing people who are on-call from being called into hospitals where their services are required.<p>Someone who's on-call isn't always at the hospital. They might well be across town, within a certain range as dictated by maximum response time; that is, they can be anywhere within fifteen minutes' travel to the hospital once they've been called. Of course, if they don't get the call, or get the call late, that could mean someone's life.<p>There's an actual, articulable reason shit like this is illegal, and it isn't just arbitrary FCC bullshit. Being annoyed at cell phone calls isn't worth someone's life.