Learning GSM: USSD fuzzing and attacking the network

Learning GSM: USSD fuzzing and attacking the network

01/06/10 | by zveriu | Categories: Hardware, Software, GSM

Learning GSM: USSD fuzzing and attacking the network

Prerequisites of attacks

Some points why USSD is a good choice:
- USSD and USSD replies are free compared to SMS (except special, VAS, etc. numbers)

- USSD and USSD replies interact with 3rd party USSD Gateways software which most probably can be attacked more easy compared to SMSC

- USSD Gateways (if not crashed by a border-case/not-tested/unusual/malformed USSD message or USSD reply), forward the messages to Applications. Most probably “Third party content and application providers” suffer from buffer overflow, script injection, SQL injection, etc.

According to http://www.truteq.com/tips/ussd/:
“The menus are served by applications. This may not be at the GSM network operator, but at a content provider connected to the USSD infrastructure. Applications or content can therefore be served from :
1. Standard supplementary services
2. GSM Network Operators value-added services
3. Third party content and application providers

- USSD sessions implementation mechanisms can be exploited in USSD Gateways (grow huge sessions, open huge number of sessions, etc.)

Means to practically implement attacks

Fuzzing requires a lot of messages/replies back and forth through TELCO’s equipment. Many may say that such activity may not go unnoticed, and this is true.


The possible solutions from TELCO would be:
- ban the SIM/IMSI from the network (can be overcome)

- ban the IMEI from the network (can be overcome)

- trace the GPS/area/triangulation location while attacker is fuzzing/exploiting (this is a little of a problem)

To overcome TELCO actions, the attacker theoretically can:
- have automated way to detect if IMEI is banned and then automatically overwrite with another IMEI (warning: ILLEGAL!) and continue fuzzing/exploiting (iPhone 2G with firmware 1.x is a good way to start for automatic IMEI detect ban-and-rewrite using Zibri tools - details in this post)

- have automated way to detect if IMSI is banned and then use another unbanned SIM card

- to avoid losing money, old pre-pay SIM cards with no credit (USSD is free most of the time) on account can be used until banned

- bulk-buy action can take place to gather many old/unused/credit-free SIM cards at once

- since the SIM card change involves mechanical actions (which are a little harder to properly, easy, fast, etc. to automate), a schematic can be imagined so that an array of SIMs are connected to a micro-controller, the phone’s SIM pinout is connected to the board’s/schematic’s controller, the controller is being controlled by a PC to decide which physical SIM pinout to be routed to the actual phone SIM pinout, suppose the schematic supports an array of 16/32 SIMs (with proper detection if SIM is connected to an array slot or not), while starting the attack just insert first batch of SIMs, then during the attack check the PC logs and check which SIMs/IMSIs were already blocked by TELCO, just replace those SIMs with the next batch of SIMs, repeat the process. All in all, it can be seen as an external multi-SIM-one-at-a-time device.

- however, if we target common exploit classes in “third party content and application providers", most probably these applications will have USSD applications which require credit/money on SIM/IMSI account - not very cheap to implement fuzzing, though can be effective in exploiting actual known exploitable vectors

USSD DoS attack on GSM Network Cell(s)

According to http://www.truteq.com/tips/ussd/:
“SMS and USSD both use the SDCCH (stand-alone dedicated control channel) when the handset is not in a call. When the handset is busy with a call, USSD will use the FACCH (fast associated control channel) with a significant improvement in transfer speed (1000 bits/second).

This use of the SDCCH channel leads to the one drawback with USSD. Because the SDCCH channel is also used by GSM for call-setup, many open USSD sessions may limit new call-setups in congested networks.

Read the above statement as cell(s)/SDCCH-channel(s) DoS/resource starvation attack.

The theoretical way to accomplish this practically:
- find a good device which is easily scriptable (iPhone is a good choice)

- find the proper PDU’s and AT commands to be sent to baseband in order to accomplish USSD (via /dev/tty.debug, /dev/tty.baseband, etc.)

- automate the allocation of various USSD sessions by requesting multiple different USSD application strings (*123#, *124#, *123*9#, etc.) in a short amount of time and keep this running for some time (to make sure the first sessions have not yet expired due to timeout but yet new sessions are still requested)

Some vendors might already have addressed this - according to http://www.dafu.de/rechts/ussd.html:
“Since USSD uses the SDCCH control channel, it does draw on the resources of a network’s switching structure. However in the Nokia implementation there are safety margins how much USSD can take up the NSS resources to protect against resource problems, explains Nokia product management.”

But again, these are mostly vendor and/or operator specific settings and implementation and it seems like it can be really exploitable. Even operators (because of not very good knowledge) seems to screw their network cell(s) up. According to http://www.linkedin.com/answers/technology/information-technology/telecommunications/TCH_ITS_TCI/283790-7613196 :
“I have found one instance recently. An operator decided to send open USSD Phase 1 balance notifications which would close when a user cancels them. They hang open for a minute. Very soon three regions could not make calls.”

USSD Application Exploitation of USSD Gateways/3rd Party Applications

Classes of attacks possible:
- input validation (unexpected alphabet chars - example: expects number then send number is hex format, or just ASCII alphanumeric)

- session handling

- SQL injection

- script/code injection

- buffer overflows

The theoretical way to accomplish this practically:
- find a good device which is easily scriptable (iPhone is a good choice)

- find the proper PDU’s and AT commands to be sent to baseband in order to accomplish USSD (via /dev/tty.debug, /dev/tty.baseband, etc.)

- automate the fuzzing and results checking (can be based on Collin Mulliner/Chris Miller GSM phones SMS fuzzing paper/framework)

- identify each application structure/menu/reply-format/reply-length

- traverse all the menus in-order and out-of-order with step-by-step replies as well as one-string USSD application strings

- another test is to traverse the menu up and down without actually sending the replies - this might spot USSD session implementation problems

Real like example:
A very notorious example of USSD application failure was airtime/credit transfer on pre-pay cards. It was widely exploited in Romania and reached very high media and authorities attention. Similar exploits very probably took place all over the world.

The idea was simple and useful (if implemented correctly :) ). Some subscriber could transfer some credit (between let’s say 1 EUR and 20 EUR) to another pre-pay subscriber of the same network. This was implemented as USSD menu in steps. However, the same thing could be accomplished by sending the entire menu-path and application parameters/configuration (like amount of credit, destination number, final confirmation of transfer, etc.) as one short-cut USSD string (example: *123*4*9*7*0745123456*1#, where 123 is self service USSD application, 4->9 is the menu path for credit transfer, 7 is the amount of 7 EUR, 0745123456 is the destination subscriber number, 1 is YES as final confirmation).

Soon, a HUGE amount of mail/messenger/sms spam was flying around saying roughly:

“A former GSM technical employee was fired and he open a secret code as a revenge on GSM employer. The code let’s you top-up your account with unlimited calls. Just type *123*4*9*20*0745666666*1# and send on you phone and the code will be activated".

Here the scam was that the spammer’s number was 0745666666 and he was actually getting 20 EUR from the victim’s account (if the credit was there of course :) - that’s why a thoughtful scammer would choose a very probable to exist in victim’s account lower credit like 4 EUR or 5 EUR).

Lot’s of stupid-and-greedy people were caught on losing their own money. The scammers got a lot of credit. They can trade for real-money in a proportion of 1-to-2 let’s say. They can trade it using the same buggy USSD credit transfer application that got them the credit in the first place :) or just use the credit for calls. Also, the pre-pay cards are anonymous, so you don’t have an identity linked directly to it, so the complaints to authorities and to TELCOs by the victims have no way to punish the abusers.

So, the lesson was somehow learned and the TELCOs now offer the credit transfer application via step-by-step menu navigation - no more one shortcut USSD string.

And this is just one example of epic failure. The rabbit hole can go as deep as 3rd party and content providers, to some web-services/web-applications, internet linked applications and so on…


It is likely from the sparse reading, that USSD is an older technology/concept in GSM than SMS. However, SMS received more attention initially and been exposed to sufficient scrutiny over the years (however, seems like not enough scrutiny since new SMS attack framework emerge - check Collin Mulliner talk).

Being there as a feature for long time, but just recently receiving scrutiny and production implementation/deployment, implementation errors and unexpected features of network/phones/USSD gateways/USSD application can be revealed/found.

Also, compared to SMS, the USSD is mostly free and can be played with at no cost.

Another point would be to avoid phones GUI to enter USSD data/replies. I would rather suggest to send direct PDU data to the baseband modem/processor directly since it gives more flexibility and doesn’t have the constraints imposed by the GUI application (like limits on which characters can be input, the length of the reply, various bits and flags of the USSD messages headers, etc.)

I have been able to find some unexpected behavior on various self-care applications of pre-pay SIMs in Orange and Vodafone networks in some European country. However, it was just random playing and I was not inspired enough to note the tests and results down :(.

Till next time…

Comments, Pingbacks:

Comment from: Multiwp [Visitor] Email · http://www.multiwp.com
I will feed your RSS after this useful article. Thanks a lot.
PermalinkPermalink 01/16/10 @ 22:23
Comment from: Multiwp [Visitor] Email · http://www.multiwp.com
Great blog well done. Excellent content. Im subscribing to your blog.
PermalinkPermalink 01/16/10 @ 22:43
Comment from: 123 [Visitor] Email
wow....what useful article. I hope all telco could improve the security of their network. It will be scary mobile network vulnerable to exploitation.This because we are too dependent in using mobile network for connection nowadays.
PermalinkPermalink 02/25/10 @ 06:40
Comment from: Godwin Josh [Visitor] Email
Very informative!!!
PermalinkPermalink 07/30/10 @ 10:05

This post has 220 feedbacks awaiting moderation...

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))
This is a captcha-picture. It is used to prevent mass-access by robots.
Please enter the characters from the image above. (case insensitive)


Cognitive and Scientific Brainology

A deep dive into brain's curiosities

July 2017
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          



XML Feeds

What is RSS?

powered by b2evolution free blog software