SIM CARDS RUN JAVA?!
Is this some kind of a sick, twisted joke?
Somewhere in the concrete monolith housing the grey bureaucratic appratus of a technical standards authority, years ago, a technician cracked.
But rather than simply go postal like his fellow pocket-protected pencil-pushers were wont to do… this man had an idea. A brilliant… eeeeevil idea.
“Guys?” he queried plaintively, raising his hand from the corner of the twentieth sub-committee meeting in a steamy room packed with bored suits on a sunny Friday afternoon.
“If we have these cards run Java, implementing companies will be able to write their code once and deliver anywhere, ensuring optimal extensibility and bulletproof forward-future-proofing.
They’ll get maximum value, we’ll make our mark as a cutting-edge body — you all know Microsoft has been complaining about our ‘lack of vision’ — and I just had a chat with the Sun representative this morning, he’s interested in organizing an ‘implementation conference’ in Rio…”
Had they known he would be tendering his resignation the following Monday, they might have thought twice. But he had always been a solid engineer… nobody could remember him having an idea that didn’t work. Frankly, most couldn’t remember him ever speaking up at all, even if he did seem to grit his teeth a lot at meetings… but that was probably just a reaction to the coffee. Just like the way his face went red whenever management spoke.
Unfortunately, for the rest of us, we’re stuck with this crime against all that is good and holy.
SIM cards can be updated silently, over-the-air, through binary SMS messages. While these messages should be cryptographically secure, most SIM cards use the (thoroughly pwned) DES algorithm, particularly if you have rainbow tables not unlike the one Karsten Nohl & co released.
(Yes, this latest news is a Nohl escapade as well.)
To make matters worse, it’s easy to brute force the DES key — offline! — with no access to the target phone.
You send the phone a binary SMS, with an invalid signature. The phone, however, does you the favor of sending back an error code carrying a VALID signature.
Using your handy rainbow table, a standard computer computes the correct key in under two minutes.
Now you can send properly signed binary SMS messages… including Java applets that should run on the SIM. These applets can send SMSes, change your voicemail number, and QUERY THE PHONE LOCATION, among many other “predefined” functions.
Being that this is Java, no doubt there are plenty of other less predefined functions waiting to be created by any single-celled amoeba armed with a five-minute introduction to exploit hunting.
The researchers have already shown that two major SIM manufacturers’ Java sandbox implementations can be broken out of like Houdini in a paper bag.
Therefore, it’s possible to remotely clone SIM cards and payment credentials, and presumably even start attacking the phone.
Nohl proposes a number of defenses, starting with better SIM cards that use strong cryptography and don’t give attackers signed plaintexts. He also proposes better Java VMs, which — given Java’s sterling reputation for nearly infinte exploitability — seems like putting lipstick on a pig. A pig that’s covered in mud. Well, mud and manure. And charging towards a sewage holding pond at full tilt.
A handset SMS firewall, his second option, seems a much better idea. Instead of mindlessly passing on binary SMS messages to the SIM card, the phone ought to do some basic input-sanitation (c’mon, even the dumbest things seem to have developed protection against Little Bobby Tables, this isn’t too much to ask) and then ASK THE BLEEDING USER whether to “Accept, Retry, Ignore?”
Except with a little more clarity, like “Yo dawg, ur netwk’s wanting 2 upd ur fone. Fo shizzle’?”
The third idea is an in-network SMS filter, which drops binary SMS messages that don’t come from the Official Network Update Center. Despite this seeming like a forehead-bashingly obvious move, it seems this idea is actually novel. Nevertheless, I’m loathe to put the filter in the hands of a large company… we all know not to trust companies or organizations, right?
And a filter that “oops” happens to let though a silent SMS because it ignores packets with “0x666” in one field-header courtesy a —
Mysterious! But anyone could have made it! — coding error introduced by the nice fellow with the strangely vague employment history seems a little too tempting.
The better defense? B-U-R-N-E-R-S.
Regularly changed. Think of them as diapers, filling up with malware and requiring periodic disposal.
And here I thought a regular dumbphone was halfway safe! (Sure hope the Cryptophone guys filter binary SMSes, or there are some REALLY amused spies out there.)
(mostly summarized already)