Tim Strazzere

November 19, 2014

The new NotCompatible: Sophisticated and evasive threat harbors the potential to compromise enterprise networks

Over the past two years, Lookout has tracked the evolution of NotCompatible. It was a compelling threat from the start, marking one of the first times hacked websites were used at a large scale to specifically target and infect mobile devices.

NotCompatible.C has set a new bar for mobile malware sophistication and operational complexity. The command infrastructure and communication perseveres and self-protects through redundancy and encryption, making it elusive and enduring. It’s an earthworm with its tail cut off that regenerates and thrives.

March 14, 2013

Still NotCompatible: A Resurgence Via Email Spam

Back in May 2012 we first reported on NotCompatible, a remote proxy threat distributed by hacked websites. Once installed, the NotCompatible malware acts as a proxy, thereby allowing its owner to transmit and receive network data through the infected device. The original threat marked the first time that hacked websites were used to specifically target and infect mobile devices. Since the initial detection, we’ve continued to actively monitor NotCompatible, and it showed relatively low activity levels with occasional moderate spikes. That’s all changed over the past few days, as we’ve seen a sudden surge in detection data across the Mobile Threat Network – peaking at almost 20,000 detections per day between Sunday and Monday this past weekend.

What’s Changed?

The technical capabilities and construction of the threat haven’t changed significantly since last May. Interestingly, in this resurgence, the distribution strategy has changed: it’s now being spread primarily via spam from hacked email accounts.

Security Alert: NotCompatible

Figure 1. A sample spam message distributing NotCompatible

Android-Specific Targeting

The original distribution campaigns for NotCompatible specifically targeted Android users by only triggering a download for browsers that reported a user-agent header that contains the word ‘Android.’ The spam links in question perform a similar targeting tactic.

Clicking a spammed link in a browser on Windows, iOS, and OSX simply directs to a fake Fox News weight loss article, as shown below.

Fake Fox News Weight Loss Article

Figure 2. Fake weight loss site that non-Android users are redirected to

When clicking the link on an Android device, the browser is redirected to an “Android Security site” for an update. Depending on the user’s Android OS Version and browser, they may be prompted about the download. Many stock browsers will transparently trigger a download to the device /Downloads folder whereas Chrome displays a confirmation dialog.

Figure 3. Fake Android Security site serving NotCompatible samples

Lookout user’s have been protected by the NotCompatible threat since May 2012, so even if a drive by download like this is successfully downloaded, Lookout’s File System Monitoring feature will detect the threat as soon as the download is complete.

Figure 4. Lookout Filesystem Monitoring actively protecting against downloaded malware

In fact, we’ve seen that this is the case for the overwhelming majority of our detections during the recent spike in activity, with only 2% of detections coming from actual installations.

How to Stay Safe

  • Avoid opening spam email. Unexpected emails from long lost friends with generic titles such as ‘hot news’ or ‘Last all Night’  or ‘You Won $1000”are normally a good indication that an email is spam.
  • Use common sense when clicking on links. If it’s not a website name that you recognize, err on the side of caution. Be especially careful when receiving links that have been ‘shortened’ (e.g. bit.ly/ABCD), as it adds an additional layer of obfuscation that is difficult to evaluate.
  • If your mobile device unexpectedly starts downloading a file that you weren’t expecting, don’t click on it – delete it!
  • Download a mobile security app like Lookout that scans for malware.
July 26, 2012

Black Hat 2012: Dex Education

Black Hat 2012 logoIt’s late July, which means I’m in Las Vegas this week for Black Hat and DEF CON conferences. Thousands of security leaders (and hackers) are gathered to share (and poke holes in) the latest security research.

If you’re at Black Hat today, come by my 2:15 talk “Dex Education: Practicing Safe Dex.”

October 20, 2011

Security Alert: Legacy Makes Another Appearance, Meet Legacy Native (LeNa)

The Threat

Recently, Lookout identified a new Android Trojan, LeNa, which is an evolution of the Legacy variant discovered earlier this year (also known as DroidKungFu). Previous Legacy variants were spotted only in alternative app markets and forums in China, collecting various details about users’ Android devices.  More recently, we discovered a variant of Legacy, which we are calling LegacyNative (LeNa) that was predominately found in alternative Chinese Markets, but a couple instances were also found on the Android Market. LeNa has similar capabilities as its predecessors, but it uses new techniques to gain a foothold on mobile devices.

All Lookout users are already protected against LeNa.  We let Google know about the variants and all LeNa infected apps were promptly removed from the Android Market.

How it Works

Unlike its predecessors, LeNa does not come with an exploit to root the device, rather it requests privileged access on a pre-rooted device.  On un-rooted devices, it offers “helpful” instructions on how to root the phone.  In some samples, LeNa is re-packaged into apps (a VPN management tool, for instance) that could conceivably require root privileges to function properly.  Other samples attempt to convince the user that root access is required to update. Once the user grants LeNa with root privileges, it starts its infection process in the background, while performing the advertised application tasks in the foreground.

Once on a user’s device, the Trojan takes a different tactic than previously seen to infect and launch the malware. LeNa hides itself inside an application that is native to the device (an ELF Binary). This is the first time an Android Trojan has relied fully on a native ELF binary as opposed to a typical VM-based Android application. In essence LeNa trojanizes the phone’s system processes, latching itself onto an application that is native to the device and critical to making the phone function properly.

Our analysis shows it having a number of malicious capabilities after requesting root access:

  • Communicating with a command and control (C & C) server
  • Downloading, installing and opening applications
  • Initiating web browser activity
  • Updating installed binaries, and more.

While analyzing and watching LeNa, we’ve seen quite a few things that were pushed by the server. One of the applications being pushed by the C&C server was a DroidDream infected application. This may show a possible correlation between the creators of the DroidDream/DroidDreamLight variants of Android malware and the Legacy variants.

Click here for the complete technical teardown on LeNa.

Who is affected?

Though LeNa has primarily been distributed through third-party markets, a handful of samples were removed from the Android Market.  Among the infected apps are One Key VPN and Easy VPN. In total, LeNa was repackaged in over 40 applications, often utility applications (VPN app, a Reader app, security application, etc.).

How to Stay Safe

  • Only download apps from trusted sources, such as reputable app markets. Remember to look at the developer name, reviews, and star ratings.
  • Always check the permissions an app requests. Use common sense to ensure that the permissions an app requests match the features the app provides.
  • Be alert for unusual behavior on your phone. This behavior could be a sign that your phone is infected. These behaviors may include unusual SMS or network activity.
  • Download a mobile security app for your phone that scans every app you download to ensure it’s safe. Lookout users automatically receive protection against this Trojan.
August 31, 2011

For Rooted Android Device Users: Open Heart Surgery on Your Android CA Store

For Android power users, a rooted Android device can be a gateway to gain full access to the operating system. One thing you can do with rooted Android devices is maintain your Certificate Authorities store, which designates the parties who verify secure sites for your device. There is increasing scrutiny on Certificate Authorities as a weakness of SSL/TLS, and in the last year there have been two specific cases where fraudulent certificates have been traced to compromised CAs. Websites using compromised certificates can take the identity of official sites, even if you are connecting over HTTPS and your web browser will not warn you about the site’s fraudulent certificate. Most recently, an issue was discovered in Iran where people have claimed that the government is performing a Man in the Middle attack on gmail using a fraudulent certificate issued from a Certificate Authority called DigiNotar. DigiNotar has since issued a report on the security incident which can be found on Vasco.

What does all this mean for an Android users? Well, unless you’re on a rooted Android device, you can’t do anything at this point. If you are rooted and not afraid to play with some command line tools, you can remove the suspect Certificate Authority certificates and disallow them from being used on your device. As a warning, this is definitely not for the faint of heart or novice Android user and can be a bit time consuming. This process will require some command line knowledge using the java keytool, ensuring that Bouncy Castle is in your classpath and using adb.

First we need to pull our CA cert bundle which is located in /system/etc/security – I’ll be using the one pulled from a Asus Transformer for this example;

tstrazzere@m0ya:~$ adb pull /system/etc/security/cacerts.bks cacerts.bks
1255 KB/s (142331 bytes in 0.110s)
tstrazzere@m0ya:~$shasum cacerts.bks
47f4789b9d03f7f8b0ff8165fc079125be314eee  cacerts.bks

Before we use the keytool, we need to make sure we have a copy of BouncyCastle in our $JAVA_HOME/jre/lib/ext/ – I used Download http://bouncycastle.org/download/bcprov-jdk16-141.jar and put it in $JAVA_HOME/lib/ext. After this is all set we need to check out whether the cacert.bks has the CA’s we would like to remove. I personally was looking to remove both DigiNotar and Comodo and used the following commands to look for them;

tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -list | grep -A 7 -B 4 -i comodo
Alias name: 48
Creation date: Feb 8, 2011
Entry type: trustedCertEntry
Owner: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO Certification Authority
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO Certification Authority
Serial number: 4e812d8a8265e00b02ee3e350246e53d
Valid from: Fri Dec 01 00:00:00 UTC 2006 until: Mon Dec 31 23:59:59 UTC 2029
Certificate fingerprints:
MD5:  5C:48:DC:F7:42:72:EC:56:94:6D:1C:CC:71:35:80:75
SHA1: 66:31:BF:9E:F7:4F:9E:B6:C9:D5:A6:0C:BA:6A:BE:D1:F7:BD:EF:7B
Signature algorithm name: SHA1WithRSAEncryption
Version: 3
--
Alias name: 78
Creation date: Feb 8, 2011
Entry type: trustedCertEntry
Owner: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO ECC Certification Authority
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO ECC Certification Authority
Serial number: 1f47afaa62007050544c019e9b63992a
Valid from: Thu Mar 06 00:00:00 UTC 2008 until: Mon Jan 18 23:59:59 UTC 2038
Certificate fingerprints:
MD5:  7C:62:FF:74:9D:31:53:5E:68:4A:D5:78:AA:1E:BF:23
SHA1: 9F:74:4E:9F:2B:4D:BA:EC:0F:31:2C:50:B6:56:3B:8E:2D:93:C3:11
Signature algorithm name: SHA384WITHECDSA
Version: 3


Alias name: 62
Creation date: Feb 8, 2011
Entry type: trustedCertEntry

Owner: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=AAA Certificate Services
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=AAA Certificate Services
Serial number: 1
Valid from: Thu Jan 01 00:00:00 UTC 2004 until: Sun Dec 31 23:59:59 UTC 2028
Certificate fingerprints:
MD5:  49:79:04:B0:EB:87:19:AC:47:B0:BC:11:51:9B:74:D0
SHA1: D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
Signature algorithm name: SHA1WithRSAEncryption
Version: 3

Make sure the above certificates are in fact the ones you want to remove – then remove them by using the -delete -alias ALIAS_NAME command. After performing a delete on these, make sure you try to grep them again to ensure they are removed;

tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -delete -alias 48
[Storing cacerts.bks]
tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -delete -alias 78
[Storing cacerts.bks]
tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider             org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -delete -alias 62
[Storing cacerts.bks]
tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -list | grep -A 7 -B 4 -i comodo
tstrazzere@m0ya:~$

Next I wanted to remove the DigiNotar CA cert, so performing the same steps like above for similar results;

tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -list | grep -A 7 -B 4 -i diginotar
Alias name: 99
Creation date: Feb 8, 2011
Entry type: trustedCertEntry
Owner: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl
Issuer: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl
Serial number: c76da9c910c4e2c9efe15d058933c4c
Valid from: Wed May 16 17:19:36 UTC 2007 until: Mon Mar 31 18:19:21 UTC 2025
Certificate fingerprints:
MD5:  7A:79:54:4D:07:92:3B:5B:FF:41:F0:0E:C7:39:A2:98
SHA1: C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C
Signature algorithm name: SHA1WithRSAEncryption
Version: 3
tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -delete -alias 99
[Storing cacerts.bks]
tstrazzere@m0ya:~$ keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -v -list | grep -A 7 -B 4 -i diginotar
tstrazzere@m0ya:~$
tstrazzere@m0ya:~$ shasum cacerts.bks
0e2a3db5d4fc82688832d2b4433a7acdb4546772  cacerts.bks

Now the last thing to do is to push this new bundle to the Android device. To do this we must have root on the phone, which will allow us to remount the /system partition. If adb is privileged as root, you can do this by simply issuing a remount command;

tstrazzere@m0ya:~$ adb remount
remount succeeded

Otherwise you will need to manually remount inside adb after running ‘su’ with something like the following;

tstrazzere@m0ya:~$ adb shell
$ su
# mount -o remount,rw /dev/block/mmcblk0p25 /system

Once you’ve remounted the /system partition, you can now push the new cacert.bks to the device;

tstrazzere@m0ya:~$ adb push cacerts.bks /system/etc/security/
1255 KB/s (142331 bytes in 0.110s)

Now simply reboot your device and be happy that you no longer have to trust unwanted CA’s!

June 15, 2011

Security Alert: Malware Found Targeting Custom ROMs (jSMSHider)

The Threat

Recently we discovered a new Trojan in the wild, surfacing in alternative Android markets that predominately target Chinese Android users. This Trojan, which we’ve dubbed jSMSHider due to the name used inside the APK, predominantly affects devices with a custom ROM. Custom ROMs are custom built versions of Android, which have been released by third-party groups. The manufacturer or carrier do not traditionally endorse custom ROMs. (If you do not know what a custom ROM is, and do not think you’ve downloaded a custom ROM, you are probably not affected.)

Who is Affected

To date, we have identified eight separate instances of jSMSHider and because the distribution is limited to alternative app markets targeting Chinese Android users, the severity for this threat is low. This Trojan, jSMSHider, predominantly affects devices where the owner has downloaded a custom ROM or rooted phone.

Due to where the malware was found and the limited number of devices the malware could infect, we believe the impact to be limited.  All Lookout users are automatically protected from this malware.

How it works

The application follows the common pattern of masquerading as a legitimate application, though a few extra permissions have been added. At first glance, it appears like other recent Android Trojans that tries to take control over the mobile phone by rooting the phone (breaking out of the Android security container), but instead jSMSHider exploits a vulnerability found in the way most custom ROMs sign their system images. The issue arises since publicly available private keys in the Android Open Source Project (AOSP) are often used to sign the custom ROM builds.  In the Android security model, any application signed with the same platform signer as the system image can request permissions not available to normal applications, including the ability to install or uninstall applications without user intervention.

In the case of jSMSHider, it installs a secondary payload onto the ROM, giving it the ability to communicate with a remote server and receive commands. If a device is signed with a  same platform signer found in the AOSP, the malware can transparently install the second stage payload without user intervention.  If the signers do not match, then the application will request the root permission, which on most custom ROMs will prompt the user to grant permission to the application.

If jSMSHider successfully installs the second stage payload, we mapped the capabilities that the malware can perform, which include:

  • The ability to read, send and process incoming SMS messages (potentially for mTAN interception or fraudulent premium billing subscriptions)
  • Installing apps transparently on ROMs with a platform signer from the AOSP
  • Communication with a remote server using DES encryption and base64 encoding with a custom alphabet
  • Dynamic C&C server addresses and check-in frequency
  • Download an application from a URL and perform a silent install or update of the APK
  • Open a URL silently in the background (using the device’s default User-Agent)

To connect to its command and control server, the malware uses multiple subdomains, including:

  • xmstsv.com
  • namely srv.xmstsv.com
  • srv1.xmstsv.com
  • srv2.xmstsv.com.

In three of the samples found, we saw that if jSMSHider cannot successfully install the secondary payload, it can still send SMS messages and open a URL silently in the background. We  will update this post with a link to the full teardown.

How to Stay Safe

Lookout Free and Premium users are automatically protected from this threat and do not need to take further action.  If you have downloaded a custom ROM, you may be at risk to this threat or future threats that use this vulnerability to gain access to your phone.  We recommend that you update your custom ROM if an update is available. We contacted and have worked with developers of some prominent custom ROMs to help them patch this issue. Again, if you don’t know what a custom ROM is you probably don’t have one and are safe.

If you have any further concerns, please contact our support team at support@lookout[dot]com.

May 11, 2011

Security Alert: Zsone Trojan found in Android Market

The Threat

Recently Google removed a Trojan, Zsone, from the Android Market that has the ability to subscribe users in China to premium rate QQ codes via SMS without their knowledge. A QQ code is a form of short code that can subscribe users to SMS update or instant message services and are primarily used in China. This malware was embedded in 10 apps by the developer named Zsone available on the Android Market and alternative markets. Lookout free and Premium users are already protected.  The infected apps from Zsone are:

  • iMatch,
  • 3D Cube horror terrible
  • ShakeBanger
  • Shake Break
  • Sea Ball, iMine
  • iCalendar
  • LoveBaby
  • iCartoon
  • iBook

Once the user starts the app on their phone, the app will silently send an SMS message to subscribe the user to a premium-rate SMS service without their authorization or knowledge. We discovered one instance (iBook) that could subscribe a user to three different services via three silent SMS messages sent. For users in China, this may result in charges to the affected phone owner’s mobile accounts. We have also found instances of this malware on alternative markets targeting Chinese users.

Who is Affected

Currently this threat affects Chinese Android phone owners who downloaded the app from the Android Market. The total number of downloads attributed to this app in the Android Market appears to be under 10,000.  All instances of the threat have been removed from the market.

How to Stay Safe

Lookout Free and Premium users are automatically protected from this threat and do not need to take further action.

As the number of malware exploits on smartphones increase, it is more important than ever to pay attention to the apps you’re downloading. Here are a few tips to stay safe:

  • Only download apps from trusted sources, such as reputable app markets. Remember to look at the developer name, reviews, and star ratings.
  • Always check the permissions an app requests. Use common sense to ensure that the permissions an app requests match the features the app provides.
  • Be alert for unusual behavior on your phone. This behavior could be a sign that your phone is infected. These behaviors may include unusual SMS or network activity. Check your mobile phone statement for any unusual charges.
  • Download a mobile security app for your phone that scans every app you download to ensure it’s safe. Lookout users automatically receive protection against this threat


March 20, 2011

Security Alert: zHash, A Binary that can Root Android Phones, Found in Chinese App Markets and Android Market

The Threat

Earlier this week we discovered a Chinese language app available for download on alternative Chinese app markets that has the ability to root an Android device, leaving the device vulnerable to future threats. The app, which provides calling plan management capabilities, contains a binary called zHash that attempts to root a device using the exploid exploit to break out of the Android security container – one of the same exploits used by the author(s) of DroidDream. It then leaves a backdoor root shell with the file name “zHash”, in the /system/bin directory.

There was also a version of this app available in the Android Market (same application package). However, while that version did contain the same zHash exploit binary, it did not contain the code required to to invoke the exploit. However, the existence of the zHash binary leaves those phones vulnerable to future exploits. Google has removed the application from the Android Market, and has exercised the remote application removal feature to delete it from users’ phones. This only affects versions of the app downloaded through the Android market, and will not remove versions downloaded from alternative Chinese markets.

The app’s use of the backdoor shell is extremely limited and not clearly malicious, however, zHash creates a hole in the security layer of the phone, leaving it vulnerable to other applications wanting to take advantage of the device. If the device was successfully rooted by this app, any other app on the device could gain root access without the user’s knowledge.

Who is Affected

Currently this threat mainly affects Chinese Android phone owners who either downloaded the app through the Chinese app markets or the official Android Market. We believe that the number of downloads attributed to this app in the Android Market is under 5,000. All instances of the threat have been removed from the Android Market.

How to Stay Safe

Lookout Free and Premium users are automatically protected from this threat and do not need to take further action.

As the number of malware exploits on smartphones increase, it is more important than ever to pay attention to the apps you’re downloading. Here are a few tips to stay safe:

  • Only download apps from trusted sources, such as reputable app markets. Remember to look at the developer name, reviews, and star ratings.
  • Always check the permissions an app requests. Use common sense to ensure that the permissions an app requests match the features the app provides.
  • Be alert for unusual behavior on your phone. This behavior could be a sign that your phone is infected. These behaviors may include unusual SMS or network activity.
  • Download a mobile security app for your phone that scans every app you download to ensure it’s safe. Lookout users automatically receive protection against this threat.
March 6, 2011

Do Androids Dream…?

As previously mentioned, Android Malware DroidDream works in two phases.  In the first phase DroidDream infects a device by breaking out of Android’s security container using two known exploits, exploid and rageagainstthecage, and then it installs a second application on the device. Once the second application is installed, it can send additional sensitive information to a remote server and silently download other applications onto the infected device. DroidDream is the first piece of Android malware we’ve seen that uses an exploit to gain root permissions, thereby giving it a substantial amount of control over an infected device.

The authors of DroidDream aptly set the package name to include the string “com.droiddream”, as the malware is configured to only run during the hours of 11 p.m. to 8 a.m.  – a time when the owner of an infected device would most likely be sleeping and not notice any strange behaviors on the phone.

DroidDream Phase II. How it works

Once DroidDream is successful in rooting a device, the malware is instructed to wait and silently install a second application, DownloadProviderManager.apk, as a system application.  Installing the second stage as a system application prevents a user from seeing or uninstalling the application without special permission.

Unlike the first stage “dropper”, where the user must start the host application to initiate the infection, the second phase was designed to be automatically triggered by certain end-user activities and check-in with its command and control server at specific times — it is also instructed to check-in with the command and control server at specific times. Once the malware is activated by the command and control server, it sends additional device information, including:

  • ProductID – Specific to the DroidDream variant
  • Partner – Specific to the DroidDream variant
  • IMSI
  • IMEI
  • Model & SDK value
  • Language
  • Country
  • UserID  (Though this does not appear to be fully implemented)

DroidDream then attempts to take an inventory of all the applications it has previously installed. Once DroidDream has communicated its current status to the command and control server, the malware accepts the following commands:

  • NextConnectTime – connect to the C&C server at a specified time
  • DownloadUrl –  download an app from a designated URL
  • PackageName – download a specific application package

Applications supplied by the command and control server can be silently downloaded to an infected device.  In the malware, there also appears to be a commands dealing with ratings, comments, assetIDs and install states, all of which relate to the Android Market. Though these appear incomplete, it’s possible the author(s) intended to listen to Android Market downloads and possibly to trigger downloads and comments on downloaded applications.

After analyzing the second phase of DroidDream, we’ve concluded that its purpose is to download additional applications and install them silently as system applications on the device. The first phase of the malware served to gain root access on the device while the second phase predominantly serves to maintain a connection to the C&C server to download and install other files. Because we have not seen the C&C server issue commands to download additional applications we cannot divine their exact purpose, however the possibilities are limitless. DroidDream could be considered a powerful zombie agent that can install any applications silently and execute code with root privileges at will.

For those that are interested, you can access the full DroidDream technical analysis here or download a PDF here.

What to do if your phone is infected

1)      Download Lookout and run a security scan to see if your phone has been infected. You will see a Lookout alert if your device is infected with DroidDream.

2)      We recommend that you do not perform a factory reset— this may not rid your phone of all the DroidDream malware. Starting last night, Google started to remotely remove the malicious applications from affected devices — other have referred to this as the “kill switch”. For an additional layer of assurance, please contact our support team at droiddream@lookout.com and we will help you uninstall the remaining components of DroidDream.

As previously mentioned, unlike other instances of malware in the wild that were only available in geographically targeted alternative app markets, DroidDream was available not only in alternative markets but also in the official Android Market, indicating a growing need for mainstream Android users to use extra caution when downloading apps.  Stay tuned as we continue to provide more detail on DroidDream as it is available.

March 2, 2011

Update: Android Malware DroidDream: How it Works

Looking for more information on mobile threats like DroidDream? Check out Lookout’s Top Threats resource.

UPDATE: Includes a link to technical analysis for the first phase of DroidDream.

UPDATE: Previously we suggested that DroidDream might be primarily targeting devices in other markets. Upon further analysis we found that this may not be the case.  We are actively investigating this and will post additional details.

Yesterday, Google pulled more than 50 apps from the Android Market after they were found to contain the Android malware DroidDream.  Similar to previous instances of Android malware that have been found on alternative Android app markets, the authors of DroidDream hid the malware in seemingly legitimate applications to trick unsuspecting users into downloading the malware—a growing trend in mobile threats. We also discovered that these apps were placed in alternative app markets in addition to the Android Market.

The Lookout Security Team did a deep analysis of the DroidDream malware present in one of the infected applications, Bowling Time. Below we’ve included details on how the first phase of the malware works when installed on a phone. We are continuing to analyze DroidDream in more detail and will update this post with additional results.

How DroidDream Malware Works

In the DroidDream samples we have analyzed, the malware cannot start automatically: it requires the user to manually run the infected application. When the host application—Bowling Time, in this case—is launched by a user, DroidDream will start by sending sensitive data to a command and control server.  The sensitive data includes:

  • IMEI
  • IMSI
  • Device Model
  • SDK Version

DroidDream is configured to perform at least one successful check-in with the command and control server, at which point the command and control server will respond and acknowledge the presence of malware on the infected device. We found that the DroidDream authors have configured the malware to make sure the device is not already infected with another variant of DroidDream. If the device is already infected, the malware will not re-infect it.

When DroidDream attempts to infect a device, it uses two known exploits, exploid and rageagainstthecage, to break out of the Android security container. Both of the vulnerabilities being exploited were patched by Android 2.3 (Gingerbread). If exploid fails to root the device, the malware will attempt to use rageagainstthecage. Once the phone is rooted, DroidDream is configured to searched for a specific package named com.android.providers.downloadsmanager. If the malware does not find this package on the device, it will silently install a second malicious application without the user’s knowledge.  If DroidDream does find the downloadsmanager package, it will not continue infecting the device with the second malicious application.

At Lookout, we are currently in the process of confirming what this second application is capable of, but our initial analysis shows that it appears to be able to send additional sensitive information to a remote server.  The second malicious application also appears to have the capability to silently install other applications.

Lookout has identified instances of DroidDream apps residing in third-party markets.  It is possible that the apps were deployed to the official Android Market after the fact, though unclear whether the authors expected to succeed in fully infecting significant numbers of devices. We’ll be continuing to investigate this, and now a technical analysis of the DroidDream is available now. You can also download the technical analysis here. Please see update above.

Unlike previous instances of malware in the wild that were only available in targeted alternative app markets, DroidDream was available in the official Android Market in addition to alternative markets, indicating a growing need for Android users to take extra caution when downloading apps. To stay safe, users should always pay careful attention when downloading apps and ensure they only download apps from developers they trust, look at the ratings and read the reviews.

A technical analysis of the first phase of DroidDream is available now. A technical analysis of the first phase of DroidDream is available now.