Kemoge: Another Mobile Malicious Adware Infecting Over 20 Countries, Including Kenya
Following a
previous discovery, FireEye Labs mobile researchers discovered
another malicious adware family quickly spreading worldwide that
allows for complete takeover of a user’s Android device. This attack
might also originate from China. We named this family Kemoge due to
its command and control (CnC) domain: aps.kemoge.net.
Figure 1. World Infection Map
As shown in Figure 1, the infection range is wide with identified victims from more than 20 countries, including governments and large-scale industries. This malicious adware disguises itself as popular apps via repackaging, so it propagates widely. Some examples are shown in Figure 2.
Figure 2. Kemoge samples in the wild
Figure 3. An overview of Kemoge’s lifecycle
Figure 3 illustrates the lifecycle of Kemoge. The attacker uploads the apps to third-party app stores and promotes the download links via websites and in-app ads. Some aggressive ad networks gaining root privilege can also automatically install the samples. On the initial launch, Kemoge collects device information and uploads it to the ad server, then it pervasively serves ads from the background. Victims see ad banners periodically regardless of the current activity (ads even pop up when the user stays on the Android home screen).
Figure 4. Code snippet from Kemoge AndroidManifest.xml
Initially Kemoge is just annoying, but it soon turns evil. As shown in Figure 4, it registers MyReceiver in the AndroidManifest to automatically launch when the user unlocks the device screen or the network connectivity changes. MyReceiver then invokes MyService; both are disguised as Google’s code (prefixed with com.google.rp.confirm). Some other samples also use com.google.system.provider.confirm, com.google.ad.sprovider, com.android.ad.sprovider, etc. as the component prefix.
After launching, MyService looks for an asset called <name>.mp4, where <name> can be bg, info or hello. The mp4 extension conceals that the asset is actually a ZIP file with multiple levels of encryption. First of all, it uses ZIP inherent password-based encryption to protect the content. The protected ZIP file is then encrypted with DES. Finally, it encrypts the DES key (denoted as Key1) with another DES key (denoted as Key2) and disassembles Key2 as bytes in the code. At runtime Kemoge decrypts the ZIP file in the reversed order, as shown in Figure 5.
Figure
5. The decryption process of the ZIP file
Figure 6. Decompiled Java code snippet of DES key generation
For example, Figure 6 shows Kemoge’s decompiled Java code snippet to obtain Key2 and then generate Key1. The code snippet initializes DESKeySpec with bytes [0x73, 0x41, 0x26, 0x73, 0x32, 0x76, 0x24, 0x31] as Key2 to decrypt bytes [0x87, 0xAF, 0xF9, 0xE5, 0x93, 0xE1, 0x50, 0x5A, 0x12, 0x8B, 0x9F, 0x8C, 0x72, 0x86, 0x79, 0xE3]. Note that the code obfuscates the encrypted bytes by replacing actual bytes with the bytes of the actual bytes’ ASCII characters, for example 0x87 is replaced by 0x38 and 0x37 (“8” and “7”). The decryption uses Android Bouncy Castle’s default DES mode (DES/ECB/PKCS5Padding) without specifying the initial vector. The decrypted bytes are [0x35, 0x64, 0x26, 0x4c, 0x32, 0x2c, 0x54, 0x39, 0x77, 0x4f], which are used to derive Key1 (with DESKeySpec) to decrypt the encrypted ZIP file. Again the decryption algorithm is the default DES mode without initial vector.
Following the same process obtaining Key1 but with different encrypted bytes as input, Kemoge generates the ZIP protecting password. After unzipping the file, it extracts the following files:
- AndroidRTService.apk
- root.sh
- busybox
- su
- .root
- root_001, root_002, ..., root_008 (eight root exploit executables)
After gaining root, it executes root.sh to obtain persistency. Afterwards, it implants the AndroidRTService.apk into /system partition as Launcher0928.apk -- the filename imitates the legit launcher system service. Moreover, the package name of this apk also looks like authentic services, e.g., com.facebook.qdservice.rp.provider and com.android.provider.setting.
This malicious system service contacts aps.kemoge.net for commands. To evade detection, it does not constantly communicate to the server. Instead, it only asks for commands on the first launch or after 24 hours from its last command. In each communication, it first posts the IMEI, IMSI, storage info, and installed app info to the remote server. We intercepted the network traffic on a Nexus 7 with Android 4.3 and with the first sample listed in Appendix I installed. The corresponding traffic is shown in Figure 7. After uploading the device info, it asks commands from the server, as shown in Figure 8.
Figure 7. Kemoge uploads device information
Figure 8. Kemoge uploads further information and asks for commands
The server responds with a command out of three groups and the malicious system service executes it:
- Uninstall designated apps
- Launch designated apps
- Download and install apps from URLs given by server
Figure 9. Server responses for remote control
As of this writing the CnC channel is still running. During our experiment, we received the response shown in Figure 9. In this case, it is trying to uninstall AV apps and popular legit apps, possibly preparing for further attacks.
Appendix I lists a few examples of Kemoge. Appendix II lists some of the used signing certificates. We observed that all samples contain simplified Chinese characters in the code. Interestingly, one sample is also published on Google Play, with root exploits and CnC behaviors stripped.
Figure 10. Google Play screenshot for “ShareIt” [4]
The Kemoge sample with package name cc.taosha.toolbox.shareit and MD5 40b1dcbe5eca2d4cf3621059656aabb5 is signed using the first certificate listed in Appendix II. The same certificate signed a Google Play app with the same app/package name (shown in Figure 10) so it’s from the same developer. This Google Play app has 100K~500K downloads. Based on the developer’s name (“Zhang Long”) and the third-party libraries integrated in the app (cn.wap3, com.renren, com.tencent, etc.), it is possible the developer is from China.
Based on the user comments, ShareIt has the same characteristics as Kemoge (annoyingly serving ads, automatically propagating via other aggressive channels, etc.). Possibly to satisfy the vetting process, the Google Play version removes the root exploits and CnC behaviors, but it does contact adm.kemoge.net and ads.kemoge.net for advertisements. Also, it asks taosha.cc for updates and prompts for upgrade installation if the remote server sends back an apk file. In our experiment the server was running but only returned a 404 code, so the developer could serve the malicious version or other malware. We have notified Google about this threat and users should be cautious downloading this app.
Conclusion
This is another malicious adware family, possibly written by Chinese developers or controlled by Chinese hackers, spreading on a global scale that represents a significant threat. We suggest that you:- Never click on suspicious links from emails/SMS/websites/advertisements.
- Don’t install apps outside the official app store.
- Keep Android devices updated to avoid being rooted by public known bugs. (Upgrading to the latest version of OS will provide some security, but it does not guarantee that you will remain protected.)
References
[1] https://www.fireeye.com/blog/threat-research/2015/09/guaranteed_clicksm.html[2] https://github.com/trevd/android_root
[3] https://github.com/saurik/mempodroid
[4] https://play.google.com/store/apps/details?id=cc.taosha.toolbox.shareit
Appendix I. Examples of Kemoge
|
Package Name |
App Name |
MD5 |
| cc.taosha.beautify.easylocker | Easy Locker |
2701de69ea6b57bbc827830660711ea2 |
| cc.taosha.toolbox.shareit | ShareIt |
40b1dcbe5eca2d4cf3621059656aabb5 |
| com.cg.sexposition | Sex Cademy |
abaf6cb1972d55702b559725983e134a |
| com.cg.wifienhancer | WiFi Enhancer |
0c67d0919e574a6876c73118260368ee |
| com.change.unlock.zhiwenjiesuo | Fingerprint unlock |
1be29a6622543f6f5063eda1d83a4e49 |
| com.funme.assistivetouch |
Assistive Touch |
7cd86d83d916dbd9b04d0e7e4f9ff6e8 |
| com.funme.sexfree | Calculator |
bf6dc2f78baed212f6aa4268da086e09 |
| com.jrhw.pinkygirls | PinkyGirls |
6fc29ab75d87a5b1e0dd792c5c68d738 |
| com.kayaya.tao.tomcat |
Talking Tom 3 |
b36a751d72e2bdea80e7ff72b6fb3a41 |
| com.kiss.browser | Kiss Browser |
cec85188308644273332d00d633ab875 |
| com.leo.appmaster | Privacy Lock |
f1a16304e427b7f8657de8c3dfb1d33f |
| com.light.browser | Light Browser |
162cb09e2eebd595eae2617cd3af1d0d |
| com.magic.gmobiepay.clear | Magic Treasure |
aa31e77775f5ce3e85ebf3bdb09f590e |
| com.space.funhgames.september | 2048kg |
efb917cb0cf09fc38b98500af61d30dc |
| com.star.android.smartTouch | Smart Touch |
db563053762250a5cb4d0c10e0e3dbb0 |
Appendix II. Example Signing Certificates
Owner: CN=tao sha, OU=IT, O=taosha.cc, L=Shenzhen, ST=Guangdong, C=86SHA1: EF:A5:C2:18:9C:21:4B:A8:21:90:4C:10:6A:B5:77:53:0F:22:00:62
Owner: CN=hexy_root_009, OU=hexy_root_009, O=hexy_root_009, L=hexy_root_009, ST=hexy_root_009, C=hexy_root_009
SHA1: E3:BD:4B:4F:38:7C:1A:A8:C0:4C:98:B2:B2:B1:B0:CF:33:5E:71:BC
Owner: CN=keke_root_025, OU=keke_root_025, O=keke_root_025, L=keke_root_025, ST=keke_root_025, C=keke_root_025
SHA1: 41:F4:9B:14:E9:8A:7C:EF:5E:BF:D9:9C:8F:58:43:48:45:BE:12:B2
Owner: CN=kiss, OU=kiss, O=kiss, L=hangzhou, ST=zhejiang, C=86
SHA1: 72:62:C5:38:78:81:B1:10:51:B3:D3:B3:63:B5:AC:F9:B9:8F:6E:B9
Owner: CN=google, OU=google, O=android, C=CN
SHA1: E9:20:9A:53:9B:C7:41:22:1D:53:37:FE:FA:9E:26:59:6C:3D:08:96
Owner: CN=wilson, OU=land, O=land, L=hangzhou, ST=zhejiang, C=86
SHA1: E5:58:C9:BA:6A:A3:D1:AC:2A:12:5B:94:C6:F6:02:2F:EE:0D:19:39
Owner: CN=hzckgames, OU=hzckgames, O=hzckgames, L=hangzhou, ST=zhejiang, C=86
SHA1: 49:D2:51:A6:67:CC:9D:C2:9D:AB:FA:E8:D3:85:44:FF:B0:59:BC:90
Owner: CN=hong, OU=fjwy, O=fjwy, L=zhejiang, ST=zhejiang, C=CN
SHA1: 89:81:E2:B0:30:A9:A4:60:5D:B2:4B:E4:31:59:A3:01:73:1C:C6:53
Posted by Bill Mburu
Source: FireEye
No comments: