Foncy has first been spotted by Denis Maslennikov. It is a dialer, i.e it sends SMS messages to premium numbers, without user’s consent. It does not spread by itself: victims are infected when they download and install the malware, likely from an alternate marketplace. They probably just wanted to try out an application, which happened to be the malware.

The application’s name (SuiConFo) – which is a French abbreviation for tracking mobile plans – immediately rang a bell in our French anti-virus labs. Since then, Karine de Ponteves and I, have been able to track information on this malware.

The malware looks like former versions of a legitimate application named Track Your Plan. The code and signing certificate bear however absolutely no similarity.

Contents of the legitimate plan tracking application

Contents of the malicious plan tracking application

In France, the malware sends 4 SMS to short number 81001, with body “STAR”. Each SMS costs 4.50 euros. The short number is a SMS+ number, rented to a French company, who in turn rents it to its customers and other intermediaries. Searching the web, we found several French users complaining about their bill and obviously infected by the malware.

Actually, the French short number 81001 seems to be involved in several scams. For example, an end-user below reports he received an e-mail telling him he had won an iPhone 4 and was being asked to send an SMS to 81001 with body “STAR”. The e-mail looks like it comes from a Fabrice Andre from Orange. Actually, a Fabrice Andre of Orange does exist, but certainly hasn’t sent this e-mail. The operator Orange is aware of this scam.

We also acknowledged a discussion on a French forum where a member was boasting about a new method to make easy money using 81001. He explained he opened a StarPass account (StarPass is a micro-payment system – via SMS), and then would ask his Facebook contacts to send a SMS to 81001.

WeeyWayne explains how he makes money out of 81001

For each 4.50 euro SMS received, StarPass pays back the author 2 euros.

For each SMS "A" (client cost 4.5 euros), you receive 2.00 euros (in French)

Additionally, Android/Foncy listens to incoming responses from 81001 and forwards the answers by SMS to a French mobile number 06xxxxxxxx. This mobile number belongs to SFR, who has been notified.

French mobile phone subscribers should be particulary wary of abnormal SMS bills, as the short number 81001 and the mobile line 06xxxxxxxx are still active at the time of writing this blog, and Android/Foncy is still in the wild. End-users should complain to their operator and/or report any unsollicited spam to the French service 33700.

To this date, we do not know the amount of French victims, and will keep you informed.

– the Crypto Girl

In the AV industry, one of the golden rules is to make sure that, during analysis, we do not in any way help the malware authors and/or propagate their offspring.

This requires special care in the case of malware for mobile phones, because, on the one hand, many of them won’t run if the phone is offline, but on the other hand, if the phone is online, the malware is free to call or send SMS messages in the wild without any way to block those actions. So, we thought building our own local GSM operator, using a USRP coupled with a Linux box running OpenBTS and Asterisk.

USRP connected to OpenBTS in our lab

Actually, this is what I presented at Virus Bulletin Conference [paper] [slides], in Barcelona, a few weeks ago. If you missed it, I also showed a video comparing how much we see when analyzing a Symbian sample of Zitmo on an offline phone and the same sample when the phone is registered to our OpenBTS-based jail. Without OpenBTS, there are quite a few details we could have missed, such as the use of UCS2 encoding for SMS messages…

– the Crypto Girl

If you are not familiar with Spitmo yet, it’s probably better you go and read Trusteer’s analysis first, as this post is focusing on a few details.

• How was the malware signed?
  It was signed using a test key publicly available from the CyanogenMod github repository. At least two other malware, Android/Netisend and Android/Pjapps use exactly the same certificate.
• Does it intercept all SMS?
  Like in Zitmo, Spitmo is capable of focusing only on some particular SMS messages it is interested in, for example those coming from your bank ;)
  This feature corresponds to a special entry in the malware’s XML configuration file: tels. Analysis I read don’t talk about this tag, but tels is designed to contain a list of originating phone numbers for which the malware should intercept SMS.
  The field is parsed by the code and each number is added to an array of numbers.
  If there are none (default situation), all SMS messages are intercepted.
• Intercepted SMS messages are sent via SMS or HTTP, huh?
  It’s the general idea, but more precisely the possibilities are:
  • 1: send via HTTP only
  • 2: send via HTTP then via SMS
  • otherwise: send via SMS only

  Most analysis say “2″ is for SMS but it also sends via HTTP, and forget to mention the third case. Not that it matters very much, but let’s just put it straight.

• Was the malware used for real?
  It’s always difficult to be sure, but my guess would be this is just an initial test. Indeed, the malware’s configuration file sets the phone number to send intercepted SMS to 123 (which obviously isn’t a real phone number). As there doesn’t seem to be any update mechanism for the malware yet, malware authors have no way to modify this default configuration. They probably intend to in future versions.
• Which countries are involved or targeted?
  The malware is downloadable from a Spanish web server, the SpyEye drop zones were registered by someone in Poland, the code contains localized strings for Russia… As usual, cybercriminals are cautious to cover their tracks! Any of these countries could be concerned … or other countries! We have no better clue for now.

– the Crypto Girl

References:

• Descriptions of Spitmo on Symbian and Android
• Descriptions of Zitmo on Symbian, Windows Mobile, Android and BlackBerry
• Other blog posts on Spitmo: Trusteer, F-Secure, McAffee

Among the talks filling the tri-tracks program (Build it / Break it / Bring it on), we’re glad to find our Crypto Girl, Axelle, who will present a paper she co-wrote with Kyle Yang (another regular poster on this blog) on the infamous mobile phone malware Zitmo, that we discovered (simultaneously with Spanish company S21sec) and named last September.

Zitmo stands for “ZeuS in the Mobile”; this offspring of the gang behind the infamous banking credential theft kit named “ZeuS” has the interesting peculiarity of attacking so-called “mTAN” (mobile Transaction Authentication Number), which are sent as SMS messages by many banks to serve as a second authentication factor, when customers want to initiate a financial transaction online.

Axelle will elaborate on the details during the preso, so if you’re around, make sure you attend!

Basically, the ZeuS network initiated some social engineering operations (via injection of HTML forms in the victims’ browser) to get the phone number and phone model of its infected victims. Based on that info, it sends an SMS with a link to the appropriate version of the malicious package (a Symbian package for Symbian phones, a BlackBerry Jar for BlackBerry phones etc).

This malicious package is still under investigation, but given the context, it is logical to believe it is aimed at defeating SMS-based two-factor authentication that most banks implement today to confirm transfers of funds initiated online by their end users, and that currently impedes the plunging of infected users’ online accounts by Zeus masters (Note: although it was possible before, with man-in-the-middle attacks, it required the victim to initiate a financial transfer in the first place).

On the technical side, this malware is not altogether that much ‘unexpected’ because, since SymbOS/Yxes, we always said somebody would use web servers to distribute platform-specific malware to victims. Yet, it is the first time we acknowledge the technique to be used by a real gang.

So far, we have seen that:

• the Symbian version is correctly signed, using the Express Signed program, once more. Symbian has been notified, but meanwhile, please beware this certificate hasn’t been revoked yet:

Serial Number: 61:f1:00:01:00:23:5b:c2:79:43:80:40:5e:52
C=AZ, ST=Baku, L=Baku, O=Mobil Secway, OU=certificate  1.00,
OU=Symbian Signed ContentID, CN=Mobil Secway

• the malware creates its own malicious database on the phone, where it stores all information it steals (contact first and last names for instance, phone numbers) and needs. This database is named NumbersDB.db, and contains 3 tables:
  • tbl_contact with 4 columns: index, name, descr, pb_contact_id.
  • tbl_phone_number with 2 columns: contact_id, phone_number
  • and tbl_history with 6 columns: event_id, pn_id, date, description, contact_info, contact_id.

  The malware searches those tables using standard SQL queries.

• the malware sends SMS messages. In particular, it sends a message to a phone number located in the United Kingdom to notify that the malware has been successfully installed (“App installed ok”).

  "27/09/2010","12:09","Short message","Outgoing","App installed ok","+44778xxxxxxx"
  (NOT SENT - OFFLINE)

  Additionally, as explained by s21sec, the malware seems to be able to answer to a few commands such as ‘set admin’, which might be particularly dangerous: anyone sending a “set admin” SMS to your infected phone may be able to take control of it. We’re of course investigating this, as well as the rest.

Please stay tuned for more information.

– the Crypto Girl

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

1. SymbOS/Yxes will be back and stronger this year. Its authors have probably had time to debug it, and I would be surprised if they do not release a few versions in the wild.
2. The AppStore will be abused, unintentionally offering one (or more) malware to the iPhone community. My crystal ball tells me this malware is likely to be a spyware, i.e a malware particularly targeting our privacy.
3. Hackers will release a Proof of Concept malware for Android.
4. There will be at least 2 new major malware. I mean really new families, with new implementations, new tricks and extensive press coverage.
5. People will keep on thinking their mobile phones are not at threat, even though it’s nothing less than secured.
6. The amount of spyware, dialers and SMS-sending malware will keep on increasing. Those are areas where malware authors make money.
7. Social engineering malware such as Koobface will spread to smartphones from which one can blog or tweet on the go.
8. One of my papers on mobile malware and SymbOS/Yxes will be accepted in a research conference.
9. Mobile malware will start using cryptography more frequently to conceal their malicious deeds. Apart from encryption of some parts, most of the malware’s code will remain unobfuscated.
10. No mobile malware author will be caught, nor sued, sentenced or fined whatsoever.

I may turn out to be wrong on a couple of those, but it will be fun looking at this post end of 2010.