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

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.

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.

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

http://[REMOVED]fu-android.com:8511/search/rpty.php

http://[REMOVED]fu-android.com:8511/search/getty.php

http://[REMOVED]fu-android.com:8511/search/sayhi.php

A whois on the corresponding IP address replies with the following most peculiar information: it looks like the IP address belongs to a mobile device (either a phone, or a tablet, or a computer with a 2G/3G connection…) of a well-known Chinese operator. Of course, we have  immediately notified this operator. This is rather surprising since, usually, attacks on mobile phones (especially command & control servers) are conducted from a host on the Internet.

$ whois [REMOVED]6.37.93
 ...
 inetnum:      [REMOVED]4.0.0 - [REMOVED].255.255
 netname:      [REMOVED]NET-JS
 descr:        [REMOVED]NET jiangsu province network
 descr:        [REMOVED - Belongs to a Chinese operator] Telecom
 descr:        A12,Xin-Jie-Kou-Wai Street
 descr:        Beijing 100088
 country:      CN
 admin-c:      CH93-AP
 tech-c:       CJ186-AP
 mnt-by:       APNIC-HM
 mnt-lower:    MAINT-[REMOVED]NET-JS
 mnt-routes:   MAINT-[REMOVED]NET-JS
 ...
 status:       ALLOCATED PORTABLE
 source:       APNIC

We tried to fingerprint the operating system of the host at that IP address:

curl -F 'imei=12345899;managerid=yutian07' -A 'Mozilla/5.0 (Linux; U;
  Android 2.1-update1; en-us; ADR6300 Build/ERE27)
  AppleWebKit/530.17 (KHTML, like Gecko)
  Version/4.0 Mobile Safari/530.17'

http://[REMOVED]fu-android.com:8511/search/sayhi.php

OK

We can try a few other combinations, but they don’t tell much more about the OS it’s running on.

Let’s try a telnet:

So, it’s (likely) an Apache 2.2.3 on a CentOS. Another telnet on Port 22 tells us there’s an SSH 4.3 server too:

telnet [REMOVED]fu-android.com 22
Trying [REMOVED]7.93...
Connected to [REMOVED]fu-android.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

It is technically possible to run a web server and an SSH server on an Android phone, but they would probably offer poor performance. I would rather go for an Android tablet or a computer with a 2G/3G connection.
Any other assumption or comment on the motivation behind this Android malware?

Android/DroidKungFu was discovered by Pr. Xuxian Jiang and his team. Thanks for sharing samples.

– the Crypto Girl

It is certainly not the first time Android malware use cryptographic encryption – we have already seen use of DES in Android/Geinimi or Android/HongTouTou – but this would appear to be the first use of AES on Android (AES has already been reported in Symbian malware such as SymbOS/InSpirit).

In Android/DroidKungFu, the malware uses AES to encrypt the two exploits it uses:

• CVE-2009-1185: packaged as gjsvro. located in the malware’s assets
• CVE-2010-EASY (rage against the cage): named ratc,  in the malware’s assets

We can’t really figure out why the malware authors specifically used AES, as a simple XOR on the exploits would have bypassed hash-based AV-signatures (signatures based on a hash of those executables). Is it just because there’s an AES class available?

The malware decrypts the files using a hard-coded key in a malicious utility class (named Utils):

private static byte[] defPassword = { 70, 117, 99, 107, 95, 115, 69, 120,
  121, 45, 97, 76, 108, 33, 80, 119 };

To decrypt the exploits, we can write some Java source code that reads the encrypted assets, decrypts it with AES using the hard-coded key, and dumps the decrypted data.

The decryption routine can be copy-pasted from a disassembly of the malware:

public static byte[] decrypt(byte[] paramArrayOfByte)
throws Exception  {
 byte[] arrayOfByte = defPassword;
 SecretKeySpec localSecretKeySpec = new SecretKeySpec(arrayOfByte, "AES");
 Cipher localCipher = Cipher.getInstance("AES");
 localCipher.init(2, localSecretKeySpec);
 return localCipher.doFinal(paramArrayOfByte);
}

Then, reading the asset and dumping the output is just a matter of using the Java FileInput/OutputStream
and ByteArrayInput/OutputStream classes.

ByteArrayOutputStream bout = new ByteArrayOutputStream();
FileInputStream fin = new FileInputStream(filename);
int c;
while ((c = fin.read()) != -1) {
  bout.write(c);
}
bout.close();
fin.close();
byte [] decrypted = decrypt(bout.toByteArray());
ByteArrayInputStream bin = new ByteArrayInputStream(decrypted);
String outputfilename = filename + ".decrypt";
FileOutputStream fout = new FileOutputStream(outputfilename);
while ((c = bin.read()) != -1) {
  fout.write(c);
}
fout.close();
bin.close();

A quick look to the strings shows the assets are decrypted successfully:

$ strings ratc.decrypted
...
/system/lib/proc/%d/cmdline/sbin/adb
[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C
[*] checking NPROC limit ...
[-] getrlimit...

Android/DroidKungFu was discovered by Pr. Xuxian Jiang and his team. Thanks for sharing samples.

Stay tuned!

– the Crypto Girl

• we haven’t encountered any annoyware family coded after 2009. An annoyware is a malicious application that intentionally makes end-users lives difficult (reboots the phone in a loop, replaces all icons with dummy ones, changes the fonts etc). So that it is clear: 1/ yes, we did detect new annoyware samples or variants but not a new family, 2/ we did detect new annoyware families after 2009, but after close analysis, we believe they were coded before 2009 and only spread later. Finally, malware families we could not attribute to any specific year do not count and are omitted.
  NB. The figure below shows the increment of new families registered for each category each year. Of course, there are far more than 20 mobile malware families !

• it looks like most mobile malware families are implemented by Russian or Chinese coders. Note that the attribution of origin is nearly always uncertain. We usually attribute a given family to a country when we spot several indications leading to the same country: function names written in Russian, phone numbers with Russia’s international prefix etc. If the hints are too small, we do not attribute it to any country. In all, our statistics concerned (only) 105 different malware families.Yet, even ‘strong’ hints can be misleading. They could intentionally be left in the malware for example. Also, note that the people who develop a malware are different from the people who intentionally spread it. I am not saying (nor implying) Russia or China is attacking us, be warned.

• over 50% of mobile malware families Fortinet detects concern Symbian, approximately 15% are Java ME midlets. Don’t hastily jump to conclusions: this does not mean those platforms are less secure (nor does it deny it). Additionally, those are statistics per family, but they would probably be different per sample or per infected devices, because some families have many different variants and samples, some don’t, some families massively infected devices (CommWarrior, Yxes…) others did not. Also, we took into account all malware families even old ones. This is different from mobile malware currently in the wild.

So, please do only take those stats as hints.

– the Crypto Girl

Q: So, what is Stuxnet exactly?
A: Technically, Stuxnet is solely the name of the Trojan component of the threat. The Trojan component is split in two malicious drivers, mrxnet.sys and mrxcls.sys, both droped into System32\drivers\ during the attack.

Q: And what do these drivers do?
A: This is still under active investigation, and will be addressed in depth in an upcoming blog post. But essentially, they have rootkit features: attempting to hide themselves and to inject malicious code in key parts of the system to spy on it, and possibly act based on what it sees.

Q: Why is Stuxnet said to target SCADA systems?
A: Because in the aforementioned injected code were found strings suggesting monitoring of (and possibly interaction with) SIMATIC WinCC and SIMATIC Siemens STEP 7, two software pieces relevant to industrial processes.

Q: So, could the attack aim at shutting down the electricity grid or any other nation-wide catastrophe that terrorists would want to trigger?
A: It is too early to identify the precise aim of the attack (let alone to attribute it) but let’s consider the following: SIMATIC STEP 7 is an engineering software (i.e. it is used to design industrial controllers) and SIMATIC WinCC is mainly a monitoring software, used to visualize industrial processes. It is therefore permitted to think the Stuxnet attack is somewhat industrial espionage oriented, rather than armageddon-driven.

Q: Then if I don’t run an industrial facility, I’m safe, right?
A: Not necessarily. For starters, having a Trojan planted in your machines is never totally innocuous: the rootkit component can generate system instability due to conflicts in hooking APIs, and worse, the Trojan may be updated at some point to spy on something else than SCADA software. Furthermore, the exploit part used to “seed” the Trojan is independent from the Trojan itself. Some reports lead us to think it actually may have been used by cybercriminals as long as one month before the vulnerability was made public, possibly to seed other malware pieces. In any case, it will be used from now on.

Q: And what is this vulnerability about? How does it work?
A: The vulnerability, labeled ‘CVE-2010-2568’, is a design flaw in the way MS Windows handles .lnk and .pif files. Essentially, MS Windows has a feature allowing such files to load “control panel applets” dlls with an arbitrary path as soon as a folder containing such files is opened in Windows explorer. Apparently this is to allow for dynamic icon management on external/remote storage.

Q: OK, so opening a folder that contains a malicious .lnk file will result in a malicious dll being loaded in my system, right?
A: If the system has access to the malicious dll as defined by the path embedded in the .lnk file, yes.

Q: And what does the malicious dll do?
A: In the case of the Stuxnet attack, it drops the two drivers mentioned in the very first answer above.

Q: Why do people mention USB sticks as the infection vector, and “AutoPlay” as an infection catalyst?
A: Because with MS Windows AutoPlay, infection could be automatic upon connecting a USB stick to the system, assuming the default action is set to “open to view files”. But frankly, AutoPlay should not be the center of discussions: USB sticks primarily being storage media, a user inserting one is likely to open it at some point. Beyond that, USB sticks have two interesting properties for the attackers:
1. They can carry the malicious dll to be loaded, almost without any size restriction.
2. Being physical objects, they tend to pass through firewalls… Directly from the parking lot to the internal network.

Q: So are USB sticks the only possible infection vectors?
A: No, a remote attack could also be mounted either via Webdav or remote SMB shares, leading to the remote malicious dll being loaded into the local system. In addition, Microsoft has indicated that Office documents could be used to trigger the same design vulnerability.

Q: Ok, so how do I patch my system?
A: There is no patch available yet, however Microsoft has published some workarounds in an advisory.

UPDATE (2010-07-22): Microsoft released a tool that automates implementation of such a workaround.

Q: What is this I keep hearing about valid certificates in Stuxnet?
A: The malicious drivers mentioned above are signed by certificates issued to Realtek and JMicron, two legitimate companies. The private keys used to sign software with those certificates were likely stolen: ESET researcher PM Bureau noted that both companies have offices in Hsinchu Science Park, Taiwan.

Q: What is Fortinet doing about it?
A: We have released AntiVirus (Data/StuxnetLnk!tr) and IPS (MS.Windows.Shell.LNK.Code.Execution) detections for the malicious .lnk files, tackling the threats from different angles, in order to increase robustness of overall detection in FortiGates.
The malicious dll and drivers are taken care of by detections W32/Stuxnet!tr and W32/Stuxnet!tr.rkit, respectively.