It doesn’t happen that often altogether that mobile malware specifically come from France and propagate in France. It however seems to be the case this time for an Android malware named Foncy – not that there should be any national pride in creating malware.

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.

 

 

 

 

 

 

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

 

 

 

 

 

 

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

Mark Balanza has spotted a new Android malware, Android/CruseWin.A!tr, which acts as an SMS relay.

The malicious application is in contact with a remote C&C from which it gets an XML configuration file which contains the commands the C&C wishes the bot to perform.

In particular, the XML send tag makes the infected mobile phone send an SMS to a specified phone number with a specified body. Then, this phone number is added to a list of phone numbers for which the malicious application must act as a relay: when the specified phone number replies (by SMS), the answer is automatically forwarded to a URL mentioned in the XML insms tag.

Precisely, the malware does an HTTP POST to that URL with a serialized JSON object carrying an informative pair “insms” and the body of the SMS answer.

 

 

 

So, the infected phone acts a SMS relay between some phone numbers and the C&C. Mark Balanza suggests interesting motivations to do so. Read the “possible motive” section of his post.

Besides this SMS-relaying functionality, I would like to investigate other functionalities the malware exposes:

• url: when the malware starts, it sends an HTTP POST, with a JSON object containing the pair “sms”/”true”, to the specified URL.
• delete: the samples I analyzed do not seem to include the code to process this command (yet), but, from its syntax, we can easily assume this command removes the specified phone number from the list of phone numbers to do SMS relay for.
• listapp: the malware posts a list of all installed applications on the device. 
  

  Posting list of applications

• clean: additionally, the malware is able to uninstall a given application remotely. This is similar to Google’s remote Kill Switch, but controlled by attackers…
  
• update: automatically visits the specified URL if the current version of the malware is different from the one specified in the configuration file.
  

Are the listapp / clean features the early sign of mobile malware trying to remove AV software or competing bots (just like Bagle or MyDoom in 2004)?

Thanks to Trend Micro for sharing this sample.

– the Crypto Girl

Some time ago, I bumped into a few Android applications which use Airpush. Airpush is an advertisement SDK developers can add to their application to generate some revenue: for every thousand ads displayed via their application, the developers gets a few dollars in return. In the case of Airpush, the ads are pushed in the mobile phone’s system tray, i.e they do not appear in the application itself, but generally at system level. The ads stand higher chances of being read/clicked on, but many end-users complained this system was really too intrusive.

See the illustration on the left: this is a demo application for AirPush. An AirPush ad is displayed at the top, in the Android system tray. Click on the image to enlarge it.

As a consequence, Airpush decided to mandate opt-in for its ads: end-users explicitly need to agree to receive ads before any ad gets pushed to the device. At least, I like this.

But Airpush’s FAQ got me really angry:

Colleagues at work will have guessed I started at “IMEIs are encrypted [..] using MD5″. They know I hate MD5 ;)

1. MD5 is a hashing function. I might be touchy, but it does not “encrypt” anything. It digests or it hashes.
2. For a given IMEI, the hash is always the same. So, this does not ensure any privacy at all, as one can track my IMEI hash instead of my IMEI.
3. MD5 is broken, obsolete for years. How is this supposed to secure my IMEI? If Airpush was really taking my “privacy” seriously, they would not be using MD5.

Reversing the hashed IMEI is a matter of seconds if you are lucky on an online MD5 reversing engine. I reversed Android Emulator’s fake IMEI (000000000000000) within seconds.

With a real IMEI, it might be longer, but feasible as IMEI follow a strict format (15 or 16 digits, first few digits being the TAC Type Allocation Code with only a few valid possibilities).

Additionally, Airpush forgets to talk about another private data it uses: my location. Indeed, some airpush application request the ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permission. According to Airpush SDK installation instructions, those permission are “optional but highly recommended to enhance your revenue stream”. Shouldn’t that be mentioned in the FAQ as part of personally identifiable information Airpush stores?? Actually, Airpush memorizes plenty of information on my device (phone model, carrier, manufacturer, IMEI) and my location (longitude, latitude) in a file named dataPrefs.xml.

I am also uneasy with the different kinds of ads Airpush can deliver and would definitely recommend users to be cautious. Airpush implements several “delivery receivers”. It looks like delivery receivers are actions to perform when the end-user clicks on the ad. Airpush implements a web delivery receiver, a market delivery receiver, a phone delivery receiver and a SMS delivery receiver. Each delivery receiver is attached to a set of parameters, potentially used when you click on the ad.
For instance, with the web delivery receiver, ads are attached to a URL. When you click on the ad, the URL automatically opens. How secure is that with regards to phishing?
With the phone delivery receiver, will airpush automatically call a given phone number when we click on the ad? and for the SMS delivery receiver, is it automatically sending an SMS? I haven’t been able to confirm those actions as I did not receive such ads, but this would certainly be dangerous.

Finally, I really like the opt-in method for ads, but it does not seem to be fully out yet and I wonder how they intend to enforce its use. As a matter of fact, I spotted a file named dialogPref.xml which contains interesting parameters:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
 <boolean name="ShowAd" value="true" />
 <boolean name="ShowDialog" value="true" />
</map>

The ShowDialog parameter refers to the opt-in dialog, meant to ask the user for his/her permission to receive ads. As such, it seems so easy for an application to disable the opt-in dialog (ShowDialog to false) and push ads (ShowAs = true) without user’s consent…

– the Crypto Girl

Our analyst, Ruchna Nigam, had been analyzing a sample of SymbOS/InSpirit.A!tr.

A couple of months ago, this malware received some attention in China (for example see here – use translation if you do not speak Chinese) because it was phishing an area bank. The malware simply added a new SMS in the victim’s inbox, apparently coming from the bank’s service hotline phone number, and telling the victim he/she had entered a bad password and needed to follow a given (malicious) link to guarantee protection of his/her bank account. More details in our virus description. Unsuspectful victims would click on the link and enter their banking credentials… Simple scheme, but it works: in a chinese forum, an end-user reported losing 5000 Chinese Yuan (over 750 USD) on this fraud.

The malicious website is not registered any longer.

A close look at this malware showed that it was likely to be related to the infamous SymbOS/Yxes worm. We can’t be sure, of course, but there are at least two striking matches:

1. The malware was signed using the same X.509 Common Name “Xiamen Jindoucheng Tech Co. Ltd” as in SymbOS/Yxes.D!worm. Note the certificates are different, but they appear to belong to the same (probably fake or impersonated) entity. The certificates have been revoked by Symbian and are no longer valid (provided your phones are configured to check the revocation lists online).
   SymbOS/Yxes.D!worm:

   Serial Number: 2a:2f:00:01:00:23:37:98:0c:73:b2:c7:69:17
   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.

   SymbOS/InSpirit.A!tr:

   Serial Number: b0:ad:00:01:00:23:0b:b6:0a:f7:51:40:37:87
   Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
   Validity
       Not Before: Nov 30 14:50:48 2009 GMT
       Not After : Dec  1 14:50:48 2019 GMT
   Subject: C=CN, ST=Fujian, L=XiaMen,
   O=Xiamen Jindoucheng Tech Co. Ltd.,
   OU=InboxSpirit  1.5.0, OU=Symbian Signed ContentID,
   CN=Xiamen Jindoucheng Tech Co. Ltd.

2. The malware uses exactly the same Rijndael (“old” name for the AES algorithm) routines. This is a binary match. They don’t seem to be used in the case of InSpirit. Perhaps the malware authors linked against a common object file or re-used some code from Yxes and left it there.

We have noted a few other similarities, such as the name of the configuration file (Remote_Para.txt) or the use of Symbian’s undocumented class RFileLogger, but, to our opinion, those are less striking and might be used by tools unrelated to Yxes.

– the Crypto Girl

During the weekend, in our monitoring of the Zeus botnet, my colleague Kyle Yang stumbled upon an unexpected payload: a brand new mobile malware piece we named SymbOS/Zitmo.A!tr (Zitmo standing for “Zeus In The MObile”), likely aimed at intercepting confirmation SMS sent by banks to their customers. This also caught the eye of s21sec with a nice analysis you should read.

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