Remote SMS Attack Can Force Mobile Phones to Send Premium-rate Text Messages
Attackers can force mobile phones to send premium-rate SMS messages or prevent them from receiving messages for long periods of time by leveraging a logic flaw in mobile telecommunication standards.
The flaw was discovered by independent security researcher Bogdan Alecu, who demonstrated how it can be exploited at the DefCamp security conference in Romania on Saturday.
Alecu exploited the way mobile devices process text messages intended for special applications called SIM Toolkits, which he said are preloaded on SIM cards by over 90 percent of mobile operators.
The applications can perform actions that include checking credit or voice mail, calling emergency numbers or customer support, and even performing mobile banking, and typically appear on the phones as a menu or application bearing the operator's name.
SIM Toolkits can receive commands through specially-formatted SMS messages, but in order for these commands to be executed successfully, the message headers must contain a valid digital signature.
The vast majority of mobile phones don't display any notification when they receive SIM Toolkit messages, he said. Some wake from their sleep state, but no message is visible in the inbox and there's no other indication that a message was received.
The encryption used to verify message authenticity is pretty solid and can't be cracked, Alecu said. Instead, his attacks rely on phones automatically returning error messages rather than executing legitimate commands.
Automatic Replies by Default
Error replies are sent automatically. Users of some phones might see a message is being sent, but they can't usually stop it.
Alecu tested his exploits on phones from various manufacturers. Only devices from Nokia have an option to ask phone owners to confirm sending a SIM Toolkit response. The option, "Confirm SIM Service Actions," is usually off by default, especially on phones configured by operators.
He tested phones from High Tech Computer (HTC) and Samsung Electronics running stock Android firmware, and an LG Optimus One with CyanogenMod, a community-built version of the popular mobile operating system. None of them displayed a notification when sending SIM Toolkit responses, and he found no option to block responses.
BlackBerry devices presented a similar behavior, he said.
Windows Mobile 6.x devices and iPhones notified users a message was being sent, but offered no way to stop it. Alecu hadn't yet tested a Windows Phone 7 device.
The sender of a SIM Toolkit service message can request that the phone reply via SMS either directly to the sender's number, or to the operator's message center, according to Alecu.
How Scammers Attack
Those two options give rise to two different attack scenarios, he said.
For the reply-to-sender option (SMS-SUBMIT), an attacker could force the sending of the error message to a premium-rate number using an SMS spoofing service. SMS spoofing is the practice of changing the originating number of a text message to anything the sender desires. This can have legitimate as well as malicious purposes, and there are many online services that provide the feature for a small fee.
Some mobile operators have strict rules on setting up premium-rate numbers. Applicants might be asked to prove that they are a registered business and provide information about how the number will be used.
Restrictions can also be placed on the text strings that a message must contain in order for the sender to be charged, which would limit this attack because the attacker can't control the content of the automatic response.
However, the number and diversity of existing SMS scams is proof that obtaining a premium-rate number is not that difficult.
If the second option (SMS-DELIVER-REPORT) is used, the error is sent to the operator's message center where it is interpreted as a message delivery failure.
When messages can't be delivered, because a phone is turned off or outside the service area, operators usually attempt to resend the undelivered message every few minutes for a predefined period of time. When this happens, all subsequent messages intended for that number are placed in a queue to be delivered when the phone re-joins the network.
Because receiving a bogus SIM Tookit message will always result in an error response, a loop is created between the message center and the phone, preventing the subscriber from receiving legitimate messages.
This denial-of-service (DoS) condition is not permanent and after a while, typically 24 hours, the undelivered message is automatically discarded. However, if an attacker were to send seven bogus SIM Toolkit messages one after the other, the message center would attempt to deliver each of them for 24 hours, resulting in a week of SMS DoS.
Alecu demonstrated the attacks on SIM cards from multiple operators in Romania, Bulgaria, Austria, Germany and France. However, since the attacks exploit a logic flaw in the GSM standard and later mobile standards, he believes that the majority of operators that use SIM Toolkits are affected.
Mitigating the attack is possible at both operator and device level. Operators can filter SIM Toolkit messages and restrict which numbers are allowed to send them. This would be an elegant solution, but Alecu has yet to find an operator that implemented it.
Phone manufacturers could enforce confirmation for SIM actions from their software. However, this fix will probably not be as effective as message filtering at operator level, Alecu said. Firmware updates are not always easy to install, especially on older phones. Performing a firmware upgrade in the wrong way can render devices unusable and many affected phones might not even be supported anymore.
The U.S. Computer Emergency Readiness Team (US-CERT) was notified of the problem in August 2010, and was asked to coordinate the disclosure process, Alecu said. He said Research In Motion (RIM) has contacted him and is working on a fix.
"We are aware of the claims and are investigating them," Nokia spokesman Tomi Kuuppelomäki said. Samsung, HTC, RIM and Apple did not return a request for comment.