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.

  1. cyanogen says:

    CyanogenMod 7 users- we addressed this issue by disallowing these kinds of apps (signed with platform keys) on user-controlled storage. Be sure you have the latest release.

  2. Antoine says:

    Why not to say in section “How to stay Safe” to not use alternatives markets as this looks to be the source of this Trojan ?

    A list of affected alternatives markets might help people using these if they can’t do otherwise. I am pretty sure all alternatives markets are not affected by this Trojan.

    I feel lucky as I only use Android Market and even if I have a custom ROM I feel safe (althought I am not chinese either).

  3. comk4ver says:

    Thanks Cyanogen! We appreciate you looking out for the users!

  4. Marguerite says:

    Hi Tim, would you please give me the malware sample? And I use it for signature generation purposes for Kingsoft Anti-virus software.

    • Amy says:

      @Marguerite, thank you for your message. Tim will be reaching out to you directly to answer all your questions. Thanks again!

  5. Dave says:

    “publicly available private keys”. Sorta says it all for their security model really.

  6. John says:

    Does this mean my super awesome Premium Version of Lookout will detect this if I had a custom ROM that might have it? :-/

    • alicia says:

      @John we would detect the malware, but not necessarily if you had a vulnerable custom ROM. you should check with your ROM provider to see if they fixed this exploit and how they fixed it. We encouraged all the custom ROM developers to generate their own private keys to sign their system images.

  7. Brian Kemp says:

    Great, and I have the only two phones NOT supported by CM 7 but were by older releases. Thanks guys!

  8. cyanogen says:

    @dave If you checkout and compile Android from the public repository, your packages will be signed with a “test key”. These are really only useful for apps installed with the system- they grant extra privileges by just having a specific signature. In CM, we decided that it’s more important for developers and modders to easily rebuild and modify the system- the community is everything to our project. Using private keys would block anyone out from doing this, they would be forced to rebuild the entire system (and perform other things) if they wanted to make changes to CM. A build created by a vendor would be signed with a set of keys only known to them, as it’s not intended to be modified. This is an acceptable workaround for us, and we have other things in the works to improve security while still allowing the user to have full control over the device they paid for.

  9. Sage Prill says:

    Really informative article.Really thank you! Cool.

Leave a comment