Much like Ninja Turtles, DroidKungFu now comes in different flavours (5 so far), discovered by Pr. Xuxian Jiang (and research team) and Lookout. If, like me, you are having difficulties keeping track of those variants, this post is for you :)

The similarities and differences between all 5 variants are depicted below. The various blocks represent each variant, and their intersection shows how many methods they share exactly*.

All variants share the same malicious commands (CMD box). They can download and install new package, start a program (called activity), open a given URL in the browser or delete a package**. To do so, they contact the same 3 remote web servers (URLs box), apart from variant A which uses a single one.

As for differences, mainly, they rely on whether the sample uses exploits or not (yellow and red knife), whether the malicious functionalities are implemented natively or not (brown circle or green box) and whether some payload is encrypted with AES or not (hatched rectangle) and the key it uses. Note that variant E has the particularity of encrypting a few strings to obfuscate its code (/system/bin/chmod 4755, WebView.db.init etc).

A few other similarities are not mentioned on the picture, such as the re-use of filenames and signing certificates. For instance, native code is typically in a file named WebView.db.init, and for certificates, variant A, B and C are signed by the same self-signed Google certificate, whereas variant D and E use a custom certificate.

References:

• Fortinet’s detailed virus descriptions, including details of native part inside version B.
• Lookout’s teardown on LeNa (aka DroidKungFu)

– the Crypto Girl

* Computed using androsim.py from Androguard.

** Actually, variant A features a fifth command, execHomepage, but implements it as “not supported”.

QR code with a link to Riskware/Jifake!Android

A long time ago, more than 2 years ago actually, I blogged about the dangers of QR codes:

“virus gangs could use this technology to have the end-user follow malicious links or send messages to premium numbers“

and, this is exactly what happened a few days ago, when Denis Maslennikov found a QR code leading to a mobile malware, named Jifake, that sends SMS messages to a premium number.

I told you so, and I couldn’t resist telling you ;)

QR codes are very handy, but they’re an incredible vector for attacks. Mainly, the issues are with the fact they are opaque (human eye can read what they contain) which leads to plenty of possibilities around phishing and social engineering.

But there are few other dark points we should be keep an eye such as QR code reader exploits and input validation. Could a specially crafted QR code crash the reader, lead to privilege escalation or unsecure input in another application of the phone (browser, SMS…)? Keep in mind that QR codes are not limited to URLs, they can also contain up to 2953 bytes of binary data. It is even possible to encrypt part of the contents of a QR code (see here).

If you feel like reading a research paper on this topic, have a look at this one: QR Code Security.

– the Crypto Girl

This is a short update to our prior post concerning Zitmo on Android.

Is this really Zitmo?

This fake Trusteer malware shows several differences with prior Symbian variants, but, for simplicity (and because it’s easy to remember), we call it Zitmo.

This does not mean this variant was written by the same authors (no proof on that account, one way or another)
nor that it has exactly the same technical functionalities or even, depending on naming policies, the same name among AV vendors, but what we mean is that this sample was propagated by ZeuS PC trojans – which is all that matters from an end-user perspective…

Denis Maslennikov proves it in his blog post where he shows Win32 ZeuS configuration files with modified Trusteer web pages. This is confirmed by our own research too: we decrypted a ZeuS configuration file and found the Trusteer-related injected pages.

Also, note that another Android Zitmo sample was discovered and fakes a Kaspersky anti-virus. We detect that sample as Android/Zitmo.D!tr.spy.

– the Crypto Girl

Kyle Yang and Alexandre Aumoine contributed to this research.

Zitmo has been used by the ZeuS gang to defeat SMS-based banking two-factor authentication on Symbian, BlackBerry and Windows Mobile for a several months (see my ShmooCon slides).

Lately, there’s been an active discussion on technical forums regarding ZeuS targetting Android users. We finally managed to get our hands on the mobile sample the ZeuS PC trojans are propagating.
Actually, it is not a new sample and has been detected under several names (Android.Trojan.SmsSpy.B, Trojan-Spy.AndroidOS.Smser.a, Andr/SMSRep-B), but it is far more scary when propagated by the ZeuS gang.

The malware poses as a banking activation application:

Zitmo trojan spyware for Android

In the background, it listens to all incoming SMS messages and forwards them to a remote web server. It’s simple, but just enough for the ZeuS gang to grab your banking mTANs…

Wireshark capture of Zitmo forwarding an incoming SMS (on the infected phone) to a remote web server

We’ll keep you posted on this one.

– the Crypto Girl

PS. F-Secure, s21sec and Kaspersky contributed to finding this sample. Thanks for their cooperation.

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.

Relaying SMS to a URL

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