The Android malware DroidKungFu reports back to the following URLs:

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

As a “Crypto Girl” should, I wish to report that the latest Android malware, Android/DroidKungFu, uses AES encryption.

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 often have requests on mobile malware statistics and although statistics are only an imperfect representation of reality, this is what we can share. Those statistics only concern malware which run on mobile phones (hybrid malware which run on a PC and send SMS do not count for instance) and the results are for malware families, i.e a group of samples which are ‘similar’ and, yes,unfortunately, this is quite subjective. Reminder: a family is then divided in several variants. An each individual malicious package is called a sample.

• 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

In the September edition of Security Minute with Fortinet, researcher Derek Manky talks about the most prevalent threats and threat trends plaguing the internet over the last 30 days, including the latest Twitter worm, Zeus and Zitmo, various software vulnerabilities, and the “Here You Have” virus.

Since the Belarus vendor VirusBlokAda pulled the alarm last week on a new malware deemed “Stuxnet”, a whole lot of information has been released here and there on different portions of the threat. As a matter of fact, the Stuxnet case presents a certain level of multiplicity, as it consists in an “exploit” part, a “rootkit” part, involves specific infection vectors, targets a specific class of victims, and has unusual characteristics (for instance regarding software certificates). The subsequent fragmentation of information across the Web lead us to think some people may find a comprehensive FAQ – including our own bits, of course – somewhat useful.

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.