Remote USSD Attack – Clarifications

September 26th, 2012 by Dylan Leave a reply »

I decided I should offer some clarifications about some of this USSD stuff as my blog posts and test page have become widely cited…

I didn’t discover this issue and I’m not a mobile security expert. The first place I saw details was in the YouTube clip featuring Ravi Borgaonkar (@raviborgaonkar). I recognised what was happening and set about testing it myself.

My test page uses the USSD code *#06# which is supposed to display the phone’s IMEI number. A phone is only really vulnerable if the 14- or 16-digit IMEI code is displayed with no specific user intervention.

Update: In some cases having the IMEI display doesn’t necessarily indicate a vulnerability to other (potentially more damaging) service codes. This is because it’s possible that some dialers may handled different codes differently (the IMEI code could be a special case, etc). While this is technically true it is hard to verify on a given device. In general I think that allowing the automatically handling of any special code taht wasn’t keyed in directly is a bad design and should treated with as much caution as possible.

While many Android phones are vulnerable in general to the injection of these USSD codes, only the Samsung phones are known (at this stage) to have a working “factory reset” USSD code. However, while this may mean other phones aren’t at risk of being wiped it doesn’t mean there aren’t still risks. There are a wide variety of USSD codes that can potentially do other damaging or annoying things, even interacting with a user’s carrier account.

Update: I’ve used the term USSD to describe the overall vulnerability. This is not strictly true. A USSD code is designed to communicate with the network. The other codes could more accurately be called device codes, service codes or engineering codes perhaps, as they are handled locally by the phone and have nothing to do with the network. However they do (usually) follow the same pattern, starting with * and ending with # – so I’m okay with calling them USSD codes, even if it’s not entirely accurate.

A factory reset may not be as damaging as some have suggest (to be honest, I haven’t been keen to see exactly what gets wiped) but it is, at the very least, incredibly inconvienient. It’s likely that app settings and other less obvious data will be lost even if things like images and files are retained.

Some browsers (most notably Opera) appear to offer some security by not handling the iframe injection code immediately. This is not much help as there are potentially other ways to inject the URI within the browser as well as other attack vectors (such as the QR code, SMS WAP Push and NFC methods detailed by Ravi.

While manufactuers may have issued (or be issuing) new firmware to address this issue, the frequently cited issues with Android fragmentation and carrier customisation both appear to hamper this. The best workaround for the majority of users, I believe, is to install an alternative dialer or one of the applications that has been designed to catch potentially harmful tel: URIs.

 

Advertisement