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.

Dalvik Disassembly of SMS Delivery Receiver in Airpush

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

Android devices continue to be the target of malware authors with Android/Fake10086.A!tr. AegisLab spotted this malicious Trojan in the wild in China and posted an interesting write-up on the matter.

In brief, Android/Fake10086.A!tr looks like a handy hotel reservation application (e.g com.hotel apk), but in the background it communicates with a remote web server and blocks some incoming SMS messages. Most noticeably, Fake10086 blocks SMS messages coming from 10086, the customer service portal of a leading chinese telecom operator – presumably to prevent them from warning the victim. How does it do that? This is what we are going to focus on in this post.

The AndroidManifest.xml shows a class FakeLanucherActivity (misspelt as in the sample) is started:

Part of the trojan's AndroidManifest.xml

This calls the onCreate() method of FakeLanucherActivity, which, in turn, instantiates a SettingManager object via the getInstance() method:

SettingManager.getInstance(this).log("FakeLanucherActivity::onCreate");

The constructor of SettingManager creates a private settings file for the application (named setting.xml in the shared_prefs private directory of the application)

SettingManager constructor - creating the settings file (setting.xml)

Later (we skip all parts which do not relate to SMS blocking) this settings file is edited by calling setSMSTempBlockNumAndTimes() with
10086 as first parameter, and 1 as second parameter:

Default values for setting.xml

From the name of the method, we guess the first parameter is the SMS number to block and the second parameter is the number of times such messages should be blocked.
The setSMSTempBlockNumAndTimes method does no more than writing the configuration in a sms_temp_block_num_and_times XML tag of the setting.xml file:

Writting SMS Block Number and Times to setting.xml

A typical setting.xml file looks as follows:

Sample setting.xml file

Note a function to read sms_temp_block_num_and_times also exists, and is named getSMSTempBlockNumAndTimes().
The SettingManager class does not have anything more regarding blocking SMS. So, how are SMS blocked?

Each time an SMS message is received, it is processed by the onReceive() method in PrivilegedSmsReceiver class which is registered as an SMS receiver by the trojan. The relevant parts of this method are pasted below (smali disassembly output):

Smali disassembly for the onReceive() method of PrivilegedSmsReceiver

So, the onReceive() method retrieves the sms_temp_block_num_and_times (and logs it to an internal debug file), gets the phone number from which the incoming SMS comes (getDisplayOriginatingAddress()), checks whether it ends with the number to block (10086), decrements the “times” counter and checks it is positive. Probably due to a bug, it does not update the setting.xml file with the decremented value, so 10086 is blocked forever. See below the logs of the trojan when the device receives an SMS from 10086:

[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=48
  PrivilegedSmsReceiver::onReceive
[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=66
The temp block info = 10086;1
[[2011,Mar,08,12:59PM]]: com.mms.bg.transaction.PrivilegedSmsReceiver::onReceive::Line=78
block the sms because it contain the temp block num : 10086 for once

– the Crypto Girl

Update: Mario Bellano found the corresponding source code. You can download it and compare…

While wearing my eyes off on the assembly code of the Symbian malware Zitmo, I had been quite embarrassed not to find any clear link with stealing online banking credentials as the rest of the ZeuS attack seemed to indicate. This issue is now solved, I know how the cyber-criminals did it or intended to.

The Zitmo malware is actually a light version (or a cracked one) of the Russian SMS Monitor application. This borderline application is officially meant for “parental control” and “security audit”, but it looks like it ended upin the wrong hands…

We already know Zitmo responds to several simple commands such as “set admin”, “set sender”, “add sender” but their use wasn’t clear yet. There it is:

• ADD SENDER, followed by phone numbers, will set those phone numbers to be spied on. Any SMS sent by such a phone number will silently be forwarded to the spy (the “admin” phone number).
• REM SENDER will obviously stop spying a given phone number
• BLOCK ON/OFF will block incoming and outgoing phone calls
• ON/OFF turns the spy engine on or off

In the case of ZeuS and online bank credentials, the cyber criminals merely need to send a “add sender” command specifying the phone number of the bank, and then an “on” command. Any SMS credential sent to an unsuspecting victim will then be forwarded to the cyber-criminals who can use it and successfully log on the bank account. Bingo.

As a side note, we confirmed what we suspected in our previous post: anyone can send a SET ADMIN command to an infected phone, and start to spy on SMS messages it receives. A rather explicit example of  how malware can “lower your defenses” (in addition of  stealing your money).

– the Crypto Girl

PS. By the way, s21sec reports the certificate for Zitmo is now revoked. Be sure to enable OCSP on your phones to retrieve the latest CRL when you install applications.

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

Some time ago, we came across a new Windows Mobile Trojan dialer named WinCE/Terdial!tr.dial. Under the cover of a FPS game (Antiterrorist 3D) or a Windows Mobile codec package (codecpack.cab), this Trojan actually has the victim’s phone call international premium rate phone numbers (IPRN), i.e phone numbers for which a given service is provided and, of course, higher prices are charged ;). More information is available in our Virus Encyclopedia, or just search the web for numerous alerts on the matter.

On my side, I have been playing Sherlock Holmes trying to understand how the authors potentially made business out of it. I end up with at least one belief: tracking is so complex, the authors are close to impunity!

Part of the complexity comes from the way IPRNs are handled. As a matter of fact, IPRNs do not exist as such. They are virtually created from special ranges offered by large telecom carriers and for which they agree to share part of their revenue. The telecom carriers provide those numbers to big companies, who in turn resell them to medium-sized reseller, who resell it to small resellers etc down to people connected with the malware authors.  There are several consequences to this method of distribution:

1- Geographic (dis)location: Numbers are no longer attached to a given geographic location. For example, the number +17675033611 is located as originating from Dominica. This does not mean the authors of the malware live in Dominica or have connections there, but simply that this IPRN number is taken from an unused range of Dominican phones managed by Marpin Telecom.

Fig 1. +17675033611 is taken from an unused range of phone numbers in Dominica

2- Unlimited costs: there is no regulation for IPRNs (contrary to domestic numbers who must comply to national rules), so operators can charge customers nearly any (“reasonable”) price they wish to access those numbers. For the victim, the cost is all the more obscure, and depends on several parameters such as his operator, the roaming network he uses and how much benefit each reseller makes out of the call.  For example, numbers in the range of +88234 (used by the malware) have been known to be charged to the victim up to 5 euros per minute!

3- Accessibility: in theory, IPRN are accessible from anywhere. In practice, it is difficult to know which IPRN is accessible from where and at which time. Resellers are consequently used to providing a “test number” within each range they offer, for customers to try for their own if the number is accessible in their personal case. Accessibility issues happen for several reasons. First, because telecom carriers may chose to modify the IPRN ranges they provide at any time. Second, because it’s up to operators to decide whether a given range is accessible or not on his network. And finally, because resellers may actually re-assign numbers they sold to other customers. For example, a reseller manages a given range of numbers. All numbers in that range are assigned to customers. One day, a new customer asks for a number. As there are none left, the reseller parses his numbers and looks for those who are no longer used, takes them away and re-assigns them to the new customer.
The good point about those accessibility issues is that it makes it difficult for cyber-criminals to plan which numbers should actually show the highest profits. For example, in the case of WinCE/Terdial, the number +8823460777 (one of the 6 numbers the malware uses) generated a disappointing traffic of only 900 minutes, which would approximately mean a revenue of 180 euros. Had the number been more accessible, even with less payout per call, the revenue might have turned out to be more substantial. Note however that 6 times 180 euros (assuming the 5 other numbers ended up with approximately the same revenue) is still a nice salary for 44 lines of code ;).

4- Anonymity: there are so many resellers that the malware authors are close to a guaranteed anonymity (and impunity). This is emphasized by the fact that small resellers do not ask their customers for credentials. Sometimes, a bank account isn’t even necessary, because the resellers pays the customer via online services such as Western Union.

The map below tracks all entities involved in the use of IPRN number +8823460777.  The +88234 range is initially assigned by the ITU to a research station in Antarctica, and handled by a Swiss company named Global Networks. This company resells the number to a reseller located in Cyprus, who resells it to a customer in New Zealand, who resells it to an unknown reseller, who finally sold it to the malware author. Our intelligence research on the malware author seems to indicate he lives in Ukraine, aged 34, although this has yet to be confirmed.

- The Crypto Girl