I had already seen mobile malware SMS messages with a malicious URL inside (e.g SymbOS/Yxes), or MMS messages (e.g SymbOS/Album.A!tr, SymbOS/Beselo!worm…) with a malicious attachment. However I had never noticed a mobile malware piece sending a WAP Push SMS (special SMS messages typically used to send ringtones, wallpapers, OTA provisioning etc).

The recent SymbOS/NMPlugin.A!tr does all three ! It sends:

- an MMS, whose title is “Hello Skuller”, and contains an attachment named Sunset.jpg

- a SMS containing a short message and a malicious URL from which to download another Symbian malware. This message is written in Chinese (it uses the UCS2 character set) and says something about some of your friends having uploaded two videos to the malicious URL

- a WAP Push SMS message, using China Mobile’s cmwap access point, and sent to UDP port 2948. This port is typically used for WAP Push Service Indication messages (WAP 167).

WAP Push Service Indication messages are special SMS meant to notify the end-user that a new service is operational at a given URL. Unfortunately, so far, the body of the message hasn’t been identified, so we cannot be sure this is what the malware is actually sending. However, if this is the case, a WAP Push Service Indication would be particularly dangerous for at least two reasons:

First, WAP Push messages are usually considered as high priority SMS and hence often automatically displayed on the mobile phone (see ‘signal-high’ parameter in WAP 167). For an attacker, this is nice because there are higher chances the message will be read by the victim.

Second, on some phones, a vulnerability prevents the phone from correctly displaying the originator of the message,so the victim may think the URI is sent by his/her (trusted) operator (see Figure below). For attackers, the downside is that WAP Push messages are not supported by all mobile phones.

Figure 1. Example of WAP Push SI message that does not correctly display the originator. The victim may consequently think the URL comes from a trusted party (system administrator).

– the Crypto Girl.

The analysis of SymbOS/NMPlugin.A!tr shows that, once again, a mobile malware was signed using the Symbian’s Express Signed procedure. It is the fourth malware we notice doing so since 2009 (and it is likely I missed a couple). See the table below.

The more I analyze the SymbOS/Album malware, the more it scares me.

The main malicious executable, Album.exe, is actually capable of processing incoming commands included in SMS messages sent by the value-added service provider number 106650xxx. Typical commands are: download and install software, get phone information or update software. Now, that starts to look  like a botnet, even though it isn’t (yet?) a very scalable way to communicate with bots because the bot master must send an SMS to each bot it manages.

More in details, the Album executable creates a global message queue (RMsgQueueBase::CreateGlobal), named ‘my_pf_queue_1′. It is notified as soon as a message arrives in the queue (RMsgQueueBase::NotifyDataAvailable), retrieves the message (RMsgQueueBase::Receive) and processes its command.

Figure 1. Disassembly of the function reading a message from the message queue.

The command parser looks for command strings such as [!@#] or [%@#] in the service provider’s SMS and triggers the corresponding command. 4 different commands have been identified:

• DoCmdSPOrder: sends a given number of SMS and logs the command in a file (c:\private\2002A22C\init_sp_order.txt)
• DoCmdDlAndInstall: downloads a given software package and installs it. We will discuss that one further.
• DoCmdGetPhoneInfo: gets phone’s model, IMEI and IMSI, and subsequently send 2 SMS.
• StartUpdatePolicy: modifies the update time and interval with the service provider. Information is logged in c:\private\2002A22C\frame_update_date.txt and c:\private\2002A22C\frame_update_interval.txt respectively.

Figure 2. Disassembly of the Base Command Parser DLL. Shows different types of commands.

In the case of the download and install command, the Base Command Parser DLL calls a function of the Frame HTTP DLL (FrameHttpEngine.dll). This module implements a web client with a download manager. The URI is added to a queue of URI to download, and the HTTP engine periodically checks this queue and downloads the requested URIs. The downloaded URI is dumped on the mobile phone in a file named c:\data\1.sisx. Then, as in SymbOS/Yxes, SymbOS/Album uses the SW Installer Launcher API to silently install the package on the mobile phone (RSWInstSilentLauncher::SilentInstall). The end-user sees no popup at all and cannot accept/decline this installation.

Figure 3. Once the URI is successfully downloaded, call the function that installs the package

Finally, for those with doubts, it is true a value-added service provider (VASP) might be expected to implement some kind of communication protocol between their server and the end-user’s mobile phone. But a legitimate VASP would make its activity and induced costs (SMS sending, WAP connections) explicit, and only install with user’s full consent. On the contrary, a Trojan would certainly use unexplicit names such as “Phone Framework” or “MMS Album” and care to hide its SMS and the installation of downloaded software.

– the Crypto Girl

Lately, I have been analyzing a sample of SymbOS/Album.A!tr, another advanced malware targeting mobile phones running Symbian OS 9 and greater.

First of all, once more, like SymbOS/Yxes, this malware was “legitimately” signed by Symbian’s Express Signed program. The certificate is now revoked:

Serial Number: c8:8e:00:01:00:23:db:45:38:bc:e7:2a:d3:03
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
Validity
    Not Before: Nov 20 05:00:02 2009 GMT
    Not After : Nov 21 05:00:02 2019 GMT
Subject: C=CN, ST=guangdong, L=shenzhen,
O=Shenzhen ZhongXunTianCheng Technology Co.,Ltd.,
OU=PF_V100  1.0.0,
OU=Symbian Signed ContentID,
CN=Shenzhen ZhongXunTianCheng Technology Co.,Ltd.

Like SymbOS/Yxes, SymbOS/Album has the capability to silently send SMS messages. It does not do it the same way though: Yxes uses the RSendAs class, whereas Album uses a non-official Symbian API named EasyDgm API (Easy Datagram API). This API sends SMS messages via sockets. Check out the API’s source code for more details, but basically, this is how it works:

1. open a socket (RSocket) and select the SMS protocol: iSocket.Open(iSocketServer, KSMSAddrFamily, KSockDatagram, KSMSDatagramProtocol);
2. create a stream to write over that socket: RSmsSocketWriteStream writeStream(iSocket);
3. dump the SMS message in the stream: writeStream << *smsMsg;
4. flush all remaining data in the stream: writeStream.CommitL();

SMS messages sent that way are not reported in the phone’s Sent message box, so they are ‘invisible’ to the user (but not to his/her future bill !). To see what’s happening, one must read the phone’s internal log file, c:\101f401d\logdbu.dat:

"28/06/2010","15:26","Short message","Outgoing","Not sent",
   "1*1#","10665xxx"...
"28/06/2010","15:24","Short message","Outgoing","Not sent",
   "@id=200@V1.2.0@YOUR IMSI@3","13410252xxx"...

The log shows the malware tried to send 2 SMS messages, one to the phone number 10665xxx with text “1*1#” and the other one to 13410252xxx with a string containing the IMSI. Those SMS messages had no chance to make it to their recipient because they are only valid in China and I am not ;) (and, of course, I had checked manually in the disassembly what numbers the malware was likely to dial before trying !). Unfortunately, several Chinese users have been less lucky and have reported abnormal bill growth (see Figures 1 and 2).

Figure 1. Chinese user complaining his phone dialed 13410252xxx (text translated from Chinese)	Figure 2. Chinese user complaining about unexpected SMS messages to 10665xxx (text translated from Chinese)

The number 10665xxx is special. It corresponds to a service provider number, i.e a special number allocated by the operator to so-called “service providers”. In that case, the number was allocated by China Mobile to “Interactive Technology Co., Ltd. Shenzhen Creation”.

As for the number 13410252xxx, it corresponds to a personal GSM located in Shenzhen, in the Guangdong Province, and it is operated by China Mobile.

Figure 3. Locating number 13410252xxx (translated from Chinese)

Does that ring a bell? Look at the certificate at the top of this post:

C=CN, ST=guangdong, L=shenzhen

Yes, the certificate also belongs to an individual/company located in Shenzhen. No proof, but looks likely both belong to the same person.
Note that the names “Interactive Technology Co” or “ZhongXunTianCheng” may be fake, or impersonated and hence may not correspond to the malware authors.

Thanks to NetQin for sharing this sample.

– the Crypto Girl