Web2SMS Gateways, A Wide Open Target

The number of mobile payment users worldwide will total 73.4 million in 2009, up 70.4 percent from 2008 when there were 43.1 million users.

                                                                                                   Gartner, Inc.

Keeping in mind the above stats, it's pretty clear that these millions of mobile payment user's are an ideal target for mobile spam. Spam emails have already polluted the Internet experience for millions of PC users.  Here by mobile spam I don't mean the smaller number of cellular phones connected to the Internet using expensive GPRS or 3G networks receiving email messages (including spam) just like a normal PC via POP3, HTTP or IMAP etc. Instead I am talking about the millions of those cellular phones which are capable of receiving/sending simple text messages using Short Message Service communication (SMS). How can these spammers send spam to these millions of mobile users?

1. Would these guys be using a cellular service where sending these spam SMS messages might actually cost them a lot of money and may reveal their identity?

2. Would they need to infect millions of mobile phones to build a botnet for sending these spam SMS messages?

Unfortunately the answer is no. Web2SMS gateways have made it easier for an attacker to use the existing botnet infrastructure to send SMS spam. Web2SMS is a service provided by many cellular companies to facilitate sending SMS to a mobile phone via the Internet.  There are many types of Web2SMS interfaces being offered today.  Two of the most important ones are as follows:

1. SMTP (Mail2SMS)

Cellular companies like AT&T and Verizon Wireless offer this feature via email.  In the case of AT&T, an email to [PHONE NUMBER]@txt.att.net will result in an SMS to the specified phone number. This SMS will not have any built in identification about the sender. Any SMS  received via txt.att.net will probably cost the receiver some amount of money but the sender will not be charged at all. What ...!!

The same is true for Verizon wireless where an email to [PHONE NUMBER]@vtext.com will serve the same purpose.  It's easy isn't it?  Can we imagine an attacker with an Internet connection can actually clutter million of phones with a mass spam campaign causing real damage to user's monthly bills? Things look horrible when one starts thinking in terms of a botnet equipped with this payload. Some readers might start thinking that it can't be that easy. These service providers will have some kind of protection against such attacks.  I'll answer this question shortly.

2. Web Service (Web2SMS)

In many Asian countries like India and Pakistan, this service exists in the form of a web Service. Users will access the provider's corporate web site where they will be asked to log in via a java applet to send SMS to any number that is part of the service provider's network.  These web services have put many restrictions on the number and frequency of outgoing SMS to reduce the chances of massive scale SMS spam.

Now let's talk about the kind of protection these service providers offer to prevent mass mailing attacks. Beware user's of AT&T and Verizon Wireless, there is no real protection available to prevent such attacks. The Email2SMS services provided by these companies are by default enabled on all accounts unless a user explicitly requests to terminate it.  To prove that this is indeed the case , I developed a custom email client to send SMS to my own cell (I am an AT&T customer), it took me 10 minutes to write the code and I successfully sent bulk SMS messages to my own cell within a few minutes time.

Trying 66.102.165.114...
Connected to 66.102.165.114.
Escape character is '^]'.
220 atledge02.cingularme.com ESMTP server (InterMail vG.1.02.00.03 201-2136-104-103-20050318) ready Tue, 30 Jun 2009 21:52:10 -0400
helo atlsmtp.cingularme.net
250 atledge02.cingularme.com
mail from:<billing@att.net>
250 Sender <billing@att.net> Ok
rcpt to:<xxxxxxxxxx@txt.att.net>
250 Recipient <xxxxxxxxxx@txt.att.net> Ok
data
354 Ok Send data ending with <CRLF>.<CRLF>
Spam SMS number 1
.
250 Message received: 20090701015237.CLJX10839.atledge02.cingularme.com@atlsmtp.cingularme.net

500 Command unknown: ''
mail from:<billing@att.net>
250 Sender <billing@att.net> Ok
rcpt to:<xxxxxxxxxx@txt.att.net>
250 Recipient <xxxxxxxxxx@txt.att.net> Ok
data
354 Ok Send data ending with <CRLF>.<CRLF>
This is spam message 2
.
250 Message received: 20090701015337.CMUU10839.atledge02.cingularme.com@atlsmtp.cingularme.net
quite

Here is one snippet from my cell:

Let's talk about the Web2SMS gateways provided by some cellular companies in Asia.  Take for example Telenor. "Telenor Pakistan" is a GSM cellular service provider, and is a subsidiary of Telenor, Norway. It has a subscriber base of 19.98 million as of March 2009.  The Web2SMS interface provided by Telenor is certainly more secure against mass SMS attacks as compared to Mail2SMS service available here in USA. The java based SMS client provided by Telenor has lots of front end checks to prevent mass SMS attacks. However, the architect of this service simply forgot about replay attacks.  It's very easy to bypass all front end checks, all you need is to start a packet sniffer like wireshark and send a sample sms through their web interface.  Captured traffic can further be replayed using a custom SMS client bypassing all the front end checks.

Here is what I captured, a single TCP packet to a server 203.215.160.178 on port 12141.

INTRO_REQ^|^MYNICK.CHT_MSG^|^923451234567^|^hello.

A custom home grown protocol without any authentication and/or encryption. Items in bold were the fields entered by me.

MYNICK =  Is the nick chosen by me, which will be displayed as the sender's name.

923451234567 = A dummy  number.

hello = Sample text message.

203.215.160.178 has some protection in place at the OS level to drop an excessive number of tcp connections from the same IP but that doesn't matter in the case of a zombie network where each zombie has a different IP address. To further prove that it is indeed the case I tried to connect to this SMS gateway from behind a tor proxy, changing my identity every 30 seconds. It bypassed all the OS level protection.

Another important thing to note here is that the SMS client applet has some front end checks to relay SMS only to numbers within the Telenor network, but at back end no such restrictions apply.  One can specify any cellular number in the above mentioned packet and this gateway will relay it (if available).  Another important thing is that both Web2Sms and M2SMS (mobile to mobile SMS)  go though the same SMSC (Short Message Service Center) so a massive attack on this SMS gateway can actually result in a DDOS depriving M2SMS requests as well.

This is not the end. Another popular GSM carrier in Pakistan is Ufone who claim to have about 19.4 million user nationwide. Similar to Telenor, Ufone also provides a Web2SMS  service.

Almost like Telenor, this SMS client has all the front end checks but no real protection at the back end. Here is the TCP traffic generated by this SMS client.

ID 0 0 0 0 569ID_Received 0 0 0 0 569 testMessage MobileServer 9234362909 0 569 MYNICK:\nhello

where 9234362909 = a random number chosen by me.

MYNICK = Nick

hello = text message

where server:port is 202.125.152.246:5000

One can see that with a careful scheme to choose arbitrary valid mobile phone numbers an attacker can actually flood millions of mobile users with the messages of his choice.  It could be fake advertisements, phishing attacks, DDOS or any other media campaign.  How about an email from "billing@verizon.com" asking you to visit a link to confirm your recent service plan change?  Would you follow the link?  I leave the rest to the reader's imagination.

An unfortunate fact is that I notified these cellular companies with this vulnerability last summer. Sadly none of these companies took it seriously.

Please remember that the number of vulnerable SMS gateways as described above is just a small list. In a recent study conducted by me I found many other gateways wide open for such attacks. 

Atif Mushtaq @ FireEye Malware Intelligence Lab

Question/Comments : research SHIFT-2 fireeye DOT COM