请别揣着明白装糊涂 — 关于360手机助手回应虫洞漏洞“Dimension Door(异次元之门)”的回应

几天前,360手机助手被Google Play下架了:

Screen Shot 2015-11-18 at 12.01.45 AM

这就是说,Google Play认为,360手机助手存在违反规定的行为,比如安全问题,或者不按套路出牌的更新/加载代码等行为。这也意味着,除中国大陆外,安卓机基本不能从官方渠道下载360手机助手。

我们分析了Google Play下架前的版本以及相应的国内版本,进而发现了“DimensionDoor(异次元之门)”,一个和Wormhole危害相当的漏洞。

该漏洞在360手机助手3.4.70(10月15日发布)及以下版本均受影响。在漏洞被发现当天(美国西部时间11月18日晚)只有官网上能下载暂未发现受漏洞影响的3.5.0 beta版本。而直到现在(美西时间11月20日晚8点)360手机助手在部分手机上仍只能自动更新到3.4.70版。(见文后视频)

“异次元之门”漏洞是什么?

    1. 为了实现跨应用通信,360手机助手开启了一个自定制的http服务,该服务会监听手机的38517端口,并且允许远程IP连接
    2. 这个http服务会接受一些通过HTTP GET发送的指令并解析执行,但缺少对发送者的身份验证,因此本质如同一个后门。其中最可能构成安全隐患的指令有两项:
      a. 下载远程apk并自动安装,无需任何用户交互(会弹出应用界面)
      b. 通过包名查看某个应用是否已安装

Screen Shot 2015-11-20 at 4.54.59 PM

 

  1. a功能有对下载域名的白名单判断,但我们发现可以通过360的CDN域名shouji.360tpcdn.com作为下载url并绕过该限制。由于360应用市场(包括雷电手机搜索)使用了此CDN作为分发服务器,因此攻击者可以先将app传到360应用市场,获取下载url,再远程安装到受害者手机。
  2. 可能的安全威胁:

    a. 黑客可以把任意app伪装成流行应用或应用更新等有欺骗性的内容,大量扫描同3G/4G网段的IP并且远程自动安装
    b. 黑客可以远程扫描用户手机上的应用安装信息,造成隐私泄露。

本来一个纯技术讨论的事情应该到此为止了。发现这个问题8小时内(美西时间11月17日晚),我们发布了一篇分析报告(
https://blog.trustlook.com/2015/11/18/yet-another-wormhole-vulnerability-meet-the-dimensiondoor/)。指出了漏洞原理,并附带了PoC视频。Trustlook并非针对任何软件厂商,我们只是做了一个安全公司该做的事情,就事论事罢了。
——————————————————————————————————
岂料风云突变。

北京时间11月19日

E安全团队翻译了上述Trustlook博客文章,并投稿在Freebuf上。随后Freebuf发布了360针对此分析报告的官方回应(http://www.freebuf.com/vuls/86222.html):

  1. 文中分析的3.1.55是360手机助手2014年的老版本,目前官方正式版和beta版均不存在远程端口安全风险。
  2. 360手机助手的APK下载会弹出助手下载页面,是具有界面交互的正常功能,整个过程用户有明确感知,与百度系产品被利用静默无提示安装任意应用的虫洞漏洞有本质区别。本文演示视频也证明了这一点,“dimensiondoor”的定义不妥。
  3. 文中提到打开任意网页的问题实际是不存在的。360手机助手对打开的url有着严格限制,只能打开360域名的网页。文中根据逆向分析猜测,与真实的产品功能逻辑相差甚远。

 

对此我们的回应如下(Freebuf并没有发布Trustlook的回应,只发布了360的回应):

    1. 3.1.55是我们经手的第一个样本,并被提及在第一版分析报告中。但绝非只有所谓“2014年版本”有漏洞。3.4.70及以前的版本,都受此漏洞影响。具体受影响的用户数未知,考虑到360应用商店上2.5亿、应用宝上1.1亿、豌豆荚1.6亿的下载量,很可能国内受影响用户达到亿级,总量超过Wormhole漏洞。
    2. “360手机助手的APK下载会弹出助手下载页面,是具有界面交互的正常功能,整个过程用户有明确感知”。一个安全大厂,面对几亿用户和产品漏洞的事实,说出这种话是不负责任的。我相信360一定知道这个http server(simpleHttpServer)是以后台service运行的,就算用户的手机处于待机状态,执行远程安装命令后手机都会远程安装并执行(见视频),待机状态用户根本不会关注到这个过程。另外攻击者也可以把恶意apk伪装成软件更新等有欺骗性的内容,并弹出自动安装。更有趣的是,app在下载栏的名称是可以由攻击者随意修改的。

请看以下demo视频:

http://static.video.qq.com/TPout.swf?vid=b0173kaeam9&auto=0

  1. 浏览器能开启的URL,以及下载安装的URL存在过滤,这些我们都分析到了并非猜测。而我们的分析中也已提及:360自己的CDN域名shouji.360tpcdn.com是在白名单里的。而360应用市场里的应用,都会通过这个域名来分发。所以任何应用只要上传到360应用市场,都可以利用这个漏洞远程安装到手机。
  2. 360手机助手被Google Play下架前的版本是2.2.012(国内外使用了两套版本计数),也是一个有漏洞的版本,并非360和Freebuf声称的“躺枪”。

——————————————————————————————————

随即,Freebuf上关于漏洞演示的视频被删掉(并非Freebuf团队所为)。Freebuf由于某种不可抗力也不再发布Trustlook的回应与回复。接下来,一些中心思想如“Trustlook一个海外小公司想通过“炒360冷饭”来博取眼球”的公关稿开始散布。

Trustlook并没有任何兴趣来“炒”360的“冷饭”,因为一点都不好吃,我们也不饿,不需要您的赏赐。反倒是坐在“国内安全头把交椅”上的360不惜通过一些渠道来黑我们这么一个小公司,揣着明白装糊涂,实在是不太好看。

最后,我们建议使用360手机助手的用户确保自己已升级到3.5.0或以上版本,你们的安全是我们这支小团队最终的诉求。

Google Play's Fallout of Paid App Protection Algorithm

 

Authors: Jinjian ZHAI, Yang SONG

The developers of paid apps in Google Play depend on a protection algorithm to prevent unauthorized installation and monetary losses of pirating and repackaging activities globally. During our research, we found that there is a loophole in the paid app protection algorithm on the Google Play store, in which crawlers can easily harvest many paid apps automatically, and distribute those apps at a lower price, or freely install them into other cell phones with a brand new Google account (without any credit card information registered).

According to Android Security Internals: An In-Depth Guide to Android’s Security Architecture

By Nikolay Elenkov, Page 82,  “Free apps are decrypted and the APKs end up in /data/app/, while an encrypted container in /data/app-asec/ is created and mounted under /mnt/asec/<package-name> for paid apps.” Yet the paid apps in the research do not behavior like that.

The sample being researched is the paid version of the popular app “Weather Live”. This paid version has more than 100,000 downloads, and the free version has more than 5,000,000 downloads. The price for the paid version is $0.99 per installation as shown in Fig. 1 .

weatherlive99cents

Fig. 1 The paid version of the Weather Live app costs $0.99.

As shown in Fig. 2-4, we set-up a valid credit card in the Google account to purchase the app. The app installed successfully. After the installation, the customer can choose to uninstall and refund the charge within a certain amount of time. The customer can also “OPEN” the app to play for a while before going back to the Google Play page to “REFUND”.

account1

Fig. 2. The first phone is equipped with a Google account which has a credit card registered.

downloading

Fig. 3. The purchasing and downloading process on the first phone is fast.

refund

Fig. 4. After installation, a “REFUND” button is shown in the first phone with valid credit card information for the Google account.

play1

Fig. 5. The functions of the paid app on the first phone with valid credit card information.

As shown in Fig. 5, the paid app that we purchased works well on the first phone that has valid credit card information in the Google account.

cmd

Fig. 6. The APK of the paid version of the Weather Live app can be pulled from the first phone that has the credit card information in Panel A.  Then it is installed on the second  phone with a brand new Google account that does not have credit card information in Panel B.

In order to test the validity of the paid app’s protection, we first tried to pull the APK from the first phone. As shown in Fig. 6, the pulling process is successful. The APK size matches the size on the Google Play page, and we can unzip it without any encrypting protection. Then the app is tested if it can be installed in another phone, which is also successful.

home2

Fig. 7 The paid version of the Weather Live app is installed on the phone of the Google account without valid credit card information by adb install.

As shown in Fig. 7, the APK of the paid app has been shown on the home screen of the second phone after adb installation. The second phone has a brand new Google account for which we have not input any credit card information yet, as shown in Fig. 8.

account2

Fig. 8. The Google account on the second phone is a brand new one without any credit card information.

As shown in Fig. 8, the Google account in the second phone is totally different with that of the first phone. And it should be noted we do not possess any purchasing capability on the second phone.

It’s interesting that when browsing the Google Play page of the paid version of the “Weather Live”, we found the app has been labeled as installed as shown in Fig. 9-10 . The only different button from the first phone ( as shown in Fig. 4 ) is the “UNINSTALL” button, as in Fig. 9  you are not capable of refunding the charge of the app. It’s our hypothesis that the Google service put it into another track of the logic without checking the validity of the payment. When they found the app can not be refunded due to null payment, they just show the uninstall button as any other free apps, instead of alerting the abnormal behaviour. In this sense, many users are capable of taking advantage of the paid APKs, which are possibly collected by any automatic crawler. This might cause potentially large monetary losses for Android developers.

uninstall2

Fig. 9. In the second phone without credit card information, the “REFUND” button is just replaced with the “UNINSTALL” button. The download counts (100,000) are still revealing that the app is the paid version.

installed2

Fig. 10 . In the app manager of the second phone without credit card information, the paid version, and only the paid version, is installed.

In order to fully understand if there is any difference between the app installed in the paid environment and the unpaid environment, we play with the “Weather Live” app and found the functions of the app on the two phones are exactly the same, as shown in Fig. 5 and 11.

play2

Fig. 11. Playing with the app in the second phone (without credit card information), we found the functions are the same as on the first phone.

Last but not the least, the paid APK which was pulled from the first phone does not have any encryption protection, and can be easily reversed engineered by apktools and JD-GUI, as shown in Fig. 12.

src

Fig. 12 . The pulled APK can be reversed engineered.

In general, the Google Play store should have provided a feasible protection algorithm for the paid apps of Android developers, otherwise their hard work can be easily fooled by a crawler and third party Android markets around the world, where the authentic apps might be sold at a lower price, or even distributed freely. Further, the paid apps risk the same level of repackaging activities from hackers as any free apps distributed inside and outside Google Play.  

The bug has been reported to Google Android Open Source Project and was accepted with bug tracking number 194525.

Screen Shot 2015-11-20 at 10.26.35 PM

The bug was considered “working as intended” in the reply of the developer, yet they failed to address the issue why the paid app of one Google account is not only considered free app of that specific Google account but also of any Google accounts. Such intended mechanism can be easily abused by pirating and repackaging activities.

Screen Shot 2015-11-20 at 8.50.16 PM

 

If you would like to know the list of affected MD5s or access to the detailed report, please contact  support@trustlook.com

Yet another Wormhole Vulnerability – Meet the "DimensionDoor"

3ef59741d4d54fba2d6f464fa7943002

 

Authors: Tianfang Guo, Mengmeng Li

Two weeks ago, the Wormhole vulnerability was in the wild, and affected more than 100M Android users. As you may already know, the Wormhole is triggered on a customized HTTP service used for cross-app communication, allowing a remote attacker to bypass the security check and issue a variety of remote commands such as installing arbitrary APKs.

Less than 2 weeks after the Wormhole vulnerability was fixed by Baidu, another incident happened with the 360 Mobile Assistant application, which is a popular app on the Android platform. The Trustlook research team found a similar issue inside this app, which causes a nearly identical remote code execution bug, called the “DimensionDoor”.

 

Screen Shot 2015-11-17 at 10.34.45 PM

 

The affected package is named “com.qihoo.appstore” in the Chinese market and “com.qihoo.secstore” on Google Play. The apps have a different version control, but use the same implementation. We used the Chinese version 3.1.55 as the example. When the app is launched, a service called “SimpleWebServer” will start listening to the TCP 0.0.0.0:38517 through a remote connection.

 

Screen Shot 2015-11-17 at 11.30.00 PM

 

Even though the app’s code is protected by ProGuard, it is still readable. Three of the functionalities from the code that we highlight are open URL, download/install APK and start activity.

 

Screen Shot 2015-11-17 at 11.37.52 PM

 

 

The commands could be issued remotely by sending an HTTP request to http://%5Bclient_ip%5D:38517/%5BAPI name]?[param], which will trigger any corresponding logic. However, there is a security check to prevent the service from being abused. For example, the remote URL will be filtered against a domain white list (only the domains owned by the vendor are allowed to access):

 

 

 

Screen Shot 2015-11-17 at 11.49.23 PM

 

We dug into the verification logic and found a few detours. For example, the 360 app’s cloud storage service uses the domain “yunpan.360.cn”. Anyone can upload APK files to it, and get a downloadable URL with the “360.cn” domain. Another approach is using the vendor’s CDN domain “shouji.360tpcdn.com”.

Below is a PoC video:

 

As of Nov 17, the 360 Mobile Assistant app has already been taken down from the Google Play store.

Screen Shot 2015-11-18 at 12.01.45 AM

Analysis of Repackaged Applications from over One Thousand QQDownloaders in Global Android Marketplaces

 

Authors: Jinjian ZHAI, Yang SONG, Mengmeng LI

100 miles north of San Francisco in the City of Ten Thousands Buddhas, a statue of Mercy Goddess with 1,000 hands has been worshipped since 1974. The 1,000 hands are used to save people separately. However, those hands are rooted from the same body.

A series of repackaged apps can be looked at in the same way as that statue with 1,000 hands. That is, thousands of individual apps with distinctive MD5 hash were indeed similar derivatives, classified by the unique package name with the same or a handful of developing groups.

Research of the individual APK samples can lead to the specific app version and developer information, and in turn reveal the developer’s reputation and network of repackaged apps within the global Android markets.

qqdownloadericon

Fig. 1 The popular QQDownloader app has over 1,600 derived APKs available on the internet.

As shown in Fig.1, we take the APKs which share the same package name “com.tencent.android.qqdownloader” as research samples in this blog. They are chosen because firstly, the app reflects a variety of APK downloading sources; secondly, the app itself is an Android marketplace, and thus is prone to the attack of hackers as a base app to deliver more  repackaged apps.

The market itself is an Android app, which needs to be downloaded from the internet directly. It recommends apps as well as provides downloading sources upon search / query.  

We have kept monitoring the malicious behaviors of this family, and have collected over 1,605 versions of this family. The 1,605 versions of QQDownloader consists of many authentic apps, as well as a few repackaged apps. Some of the repackaged apps are even malware.

The reason that such a large number of versions exist lies in the fact that firstly QQDownloader is the counterpart of Google Play in China, and has been updated frequently; secondly, QQDownloader is so popular that it has been the target of hackers for possibly monetary gains.

I. The Authentic Apps

The authentic apps of “com.tencent.android.qqdownloader” are marked with exactly the same developer signature.

authentic_cert

Fig. 2 The authentic developer certificate signature of QQDownloader.

As shown in Fig. 2, the authentic QQDownloader  is developed and maintained by the Android QZone Team in Beijing.

This authentic sub-series represents the majority of the 1,605 samples being researched. They consist of 1,583 samples signed by the developer’s certificate signature as shown in Fig. 2.

II. The Repackaged Apps

The remaining 22 apps are repackaged apps. Based on the authentic and repackaged apps’ discrepancy of the main-launcher activity name, which is concurrently registered as “android.intent.action.MAIN” and categorized as “android.intent.category.LAUNCHER” under the same android:name action in the AndroidManifest.xml, we found a few repackaged apps of interest.

We analyzed one APK for its dynamic behaviors, network traffic, and static code logic. The Metadata of the sample being researched is shown in Fig. 3.

fk_md5

Fig. 3 The Metadata of the Illegitimate and Repackaged Sample of the QQDownloader app.

manifest

Fig. 4. AndroidManifest.xml of the repackaged QQDownloader app. The main activity from the launcher is com.fk.bh.MyActivity

As shown in Fig. 4, the main activity which is linked to the launcher icon in the home page of the phone is com.fk.bh.MainActivity, while the main activity of the authentic QQDownloader app  – “com.tencent.assistant.activity.SplashActivity” is bypassed.

The sample passed most AV vendor scannings as benign, with Virustotal score of 1/55 when initially submitted, as shown in Fig. 5:

vt_fk

Fig. 5 VirusTotal scan of the repackaged sample when queried on 11/09/2015.

Yet further investigation of the main activity reveals some suspicious function calls.

fk.bn

Fig. 6. The main activity of the repackaged app redirects the onCreate() function to a stored string in AndroidManifest.xml.

Firstly, a service called YangService is started by the initializer YangInit.getM()  from the initSad() function of Fig. 6.

Secondly, as shown in jumpToOther() function of Fig. 6, a class name is read from the MyUtil.getRac() function, which in turn reads the activity name “com.tencent.assistant.activity.SplashActivity” from AndroidManifest.xml (as shown in Fig. 4)

A question of who and why they insert the extra service into the SplashActivity of the QQDownloader would be proposed naturally against the repackaged app. Bearing such questions, we examed the developer’s certificate signature of the app:

fk.bn.cert

Fig. 7. The developer’s certificate signature of the repackaged app.

As shown in Fig. 7. the Issuer’s Information is too brief to reveal the real developer’s information, which suggests his/her suspicious behavior.

A detailed scrutiny of the YangServer and YangReceiver class reveals that the injected service is used to load class methods dynamically :

dyn_class_loading

Fig. 8. The dynamic class loading source code called by the functions of the injected YangService class.

When monitoring the dynamic behaviors and sniffing the network traffic while the app is running in the Trustlook Mobile Sandbox environment, we found that the app slagged the initial activity of the main QQDownloader layout and covered the phone screen with a large ad window.

ad

Fig. 9 The ad window started by the repackaged QQDownloader app.

When following the network traffic packets, we found that customer’s privacy was collected and sent to the ad server in Aliyun, the public cloud service platform.

dl_config_file_from_server

Fig. 10. The network packet with customer’s privacy was sent to the ad server based on the Aliyun cloud service platform.

config_file_name

Fig. 11. The ad packet contains URL of APKs and ad pictures. The pictures are rotating and clickable in Fig. 9.

As shown in Fig. 10 and Fig. 11, the ad server collects the following private information and uses it to push ads in the injected ad window:

  1. customer’s gender and age
  2. phone number
  3. IP address
  4. MAC address
  5. location, longitude, and latitude
  6. IMEI and IMSI
  7. OS version
  8. ISP service

We see that the repackaged QQDownloader sample as being dangerous adware. When we continued to research other repackaged QQDownloader samples, we found a list of suspicious developer certificate signatures. As shown in Fig. 12, they either contain little information or purposely alter the initial QZone developing team’s information.

repackaged_cert

Fig. 12. Some suspicious developer certificate signatures of the repackaged apps of QQDownloader.

In general, the authentic apps are repackaged due to one or more of the following reasons:

  1. The developer would like to change the ad network
  2. The developer would like to inject malicious code
  3. The developer would like to republish the app in an Android market other than the one where the authentic app is published.

If you would like to know the list of malware MD5s or the detailed report, please contact support@trustlook.com

Baidu SDK Wormhole vulnerability analysis report. It's like leaving your house key in the front door.

This article is an update to our previous report “The WormHole Vulnerability: The Number of Affected Apps is Increasing”. We will introduce more technical details about this vulnerability going forward.

Apk version used: Baidu map 7.7.0 for Android

The cause of the vulnerability:

The Moplus SDK creates a local server for in- and cross- app communications. It links on special ports (6259 or 40310), but doesn’t need to match the request source correctly. It only checks the Host/remote-addr/Referer field of the arrived packet. If their specifications align, it will allow their connection and accept/execute many powerful commands in the url’s parameters, such as downloading files from the internet, installing Apps, running apps, uploading user’s phone information, etc. These packet headers can be easily forged, allowing an attacker to send specially made urls to the user’s phone remotely, and executing dangerous commands on the user’s phone. Moplus SDK is so useful that many third party apps contain Moplus SDK for search engine or map services. Therefore, this vulnerability can have a large impact on Android users. You only need to know the user’s ip to launch an attack. Yes, that’s all.

The conditions that the incoming packet header must adhere to if they want to connect the user’s phone:

  • The “Host” and “remote-addr” field’s value is “127.0.0.1”
  • The “referer” file contains one of the following: baidu.com/hao123.com/hiapk.com/91.apk

Then it will consider that this request is from inside the app, accept it, and execute the command contained in the request.

To any a hacker, setting the request’s header field to some value is as easy as drinking a cup of coffee. All you need to do is this (if using Python):

 

图片1_1

All commands that the Moplus SDK supports can be seen in the function com.baidu.android.nebula.cmd.i.

All commands the server supports

The correspondence between the command and the function are as follows:

The corresponding functions and the commands

All commands’ functionalities are as follows:

  • geolocation: get the user’s exact location, such as the longitude and latitude
  • getsearchboxinfo: check if the user has installed the Baidu Search App (package name:com.baidu.searchbox)
  • getapn: get the user’s APN, such as the Wifi/2G/3G
  • getserviceinfo: get the Moplus/Baidu push service version info
  • getpackageinfo: check if the user has installed apps whose package names are specified in the parameters of the url
  • sendintent: launch a specified Intent Uri (such as open some App/send sms/open URL in browser and so on)
  • getcuid: get the user’s phone IMEI /cid number
  • getlocstring: get the phone’s cid/area code/IMEI and then join them together for sending
  • scandownloadfile: scan the apks in the download directory
  • addcontactinfo: add contact to the user’s phone
  • getapplist: get all installed apps’ package name and version on the user’s phone
  • downloadfile: download a file from a specified url to the user’s phone
  • uploadfile: install or uninstall some apps silently
downloadfile command

For example,take the command “downloadfile”. Its code is as follows: The function gets the download url, the saved path, and the file size (in bytes) from the url. Then it will download the file to the user’s phone, and the file will be saved in the “savepath” directory under the sdcard directory, etc. in /sdcard/$savepath$.

The code pieces of the downloadfile function

The url format containing the parameter for downloading is as follows:

download_file_2

sendintent command

Another important command is “sendintent”. Anyone could specify the intent Uri, which will start the Uri intent directly, such as dialing the specified number, sending an sms, or running an application.

Get the intent Uri from the URL

Get an Intent Uri then start it:

Start other apps by sending Intent to the phone
Start the Intent by the Uri in the URL

If you want to dial a number you could make a url like this:

sendintent_1

We developed the exploit application in Python and Java several days ago and tested it successfully, but recently Baidu updated its SDK. The vulnerable port (6259/40310) has been closed (I have tried several Apps, with the same outcome). When the app containing Moplus SDK is newly installed, the 6259/40310 port will open for several seconds, but will close soon thereafter. So now the exploit cannot be used. When executed, it will return an error. However, we found another vulnerability: the 7777 port is always open, so by exploiting the same vulnerability, the attacker could get useful information of the phone remotely, such as the phone’s IMEI and the user’s location, but cannot execute dangerous actions such as installing apps or downloading files to the user’s phone. Regardless, this could still result in the leakage of the user’s private information.

The vulnerable port 6259 has been closed, but 7777 port is still open, light vulnerable

These commands are so powerful, like Doraemon’s key, and this SDK so widely used, especially in China. If used by attackers, this could have a widespread negative impact for Android users. Imagine if you use a 2G or 3G network. All users are on the same LAN, so the attacker can  just scan the net range then see if you opened the 6259/40310 port. If yes, then the attacker could launch the attack. It’s that easy. So big companies should pay more attention their SDK and app security, and protect the Android world for users. Remember: With great power, comes great responsibility.

 

 

The WormHole Vulnerability: The Number of Affected Apps is Increasing

The “WormHole” is a critical vulnerability on Moplus SDK on Android, which is used by major Baidu products, as well as some other apps.

In summary, this vulnerability is caused by “ImmortalService” – a customized HTTP service used for cross-app communication. Because “ImmortalService” uses an incorrect approach to filter requests from outside the phone, a remote attacker could use certain crafted HTTP requests to execute some pre-set functionalities of this SDK, such as to install an app from the Internet (needs root support), launch arbitrary intents, or manipulate phone contacts.

The details of this vulnerability can be found here.

It is entirely possible for an attacker to develop a worm , which can spreads itself using the WormHole vulnerability. To make matter worse if the worm spreads popular apps according to Wooyun.org, more than 100M users can become affected.

.

The Trustlook research team has searched our app database, and found the total number might be more than that. Here is the updated list of affected apps:

cn.jingling.motu.photowonder 50,000,000+
tv.pps.mobile 10,000,000+
com.baidu.baiducamera 5,000,000+
mobisocial.omlet 5,000,000+
xcxin.filexpert 5,000,000+
com.smart.softclient.music.baseline 1,000,000+
org.cocos2dx.FishGame 1,000,000+
com.smile.gifmaker 1,000,000+
com.qiyi.video.market 1,000,000+
com.baidu.input 1,000,000+
com.baidu.searchbox 1,000,000+
com.app.hero.ui 1,000,000+
com.nd.android.launcher91 1,000,000+
com.letv.android.client 1,000,000+
com.ubercab.driver 1,000,000+

Please note that the above list is a conservative estimation of the number of affected apps. The data only includes the Apps on Google Play, which has the lower bound of install numbers. Apps that were distributed via other channels are not calculated.

This blog will be updated by Nov 4 with more info about the WormHole vulnerability.

Hackers don’t need root exploits

Authors: Mengmeng Li, Tianfang Guo, Jinjian Zhai

lightsabers-clash-850x560

“Root as a Service”

RaaS – Root as a Service is a phrase used to describe the methodology of malware launching a root exploit with server side support, in which the client side will dynamically request exploits specified for its hardware and OS version from the server. This implementation gives more confidentiality and upgrade flexibility to the exploits.

In recent months, an increasing number of RaaS malwares have been reviewed, such as “GhostPush” and “Kemoge”. These malwares are capable of downloading root exploits from their command & control server, and rooting the victim’s phone. They then take advantage of the root privilege to install 3rd party apps, and remove antivirus apps which prevents them from being uninstalled.

image02
RaaS: the attack procedure

Using similar root exploits, the root tool (PC or Android based), on the other hand, becomes a necessity for some Android users who want to have total control of their phones. Driven by user demand, even the largest players in the industry have published their own root tools, which are designed to be used as easily as one-click ordering. Those vendors have certainly considered the safety of their root exploits, and have utilized protection mechanisms – such as anti-debugging and data-encryption, to protect their exploit binaries.

On the ACM-CCS conference, researchers from University of California, Riverside published a paper “Android Root and its Providers:A Double-Edged Sword” about the analysis of popular root tools. According to the paper, most of the exploits from rooting tools could be extracted and reverse engineered. And those tools are like double edged swords – once the exploits are leaked, no one can guarantee they will not be used for evil purposes.

After reading this paper, we decided to further explore a possibility: with the root vendors exposing their backend APIs, is it doable to forge the client side requests, abuse the vendors’ service, and root someone’s phone in the background (say, make a “root SDK” that can be integrated into malwares) without preparing a single root exploit?

Case study

We started with a popular root tool A. Because this tool has utilized strong code obfuscation, we did our analysis by dynamic execution in our sandbox, and analyzed the events after the large “Root” button was clicked.

Its RaaS implementation is quite clear:

  • Upload user’s device info to the server, such as phone type, OS build info, and kernel version.
  • The server will respond a JSON, containing the download link of a “root solution”, usually a native library
  • The app will then download the library file, load it, and let the root exploit do its job
  • Remove all the downloaded config files and exploits

Initial Request to the root server with phone info:

image03

The returned JSON file is encrypted by the AES algorithm. However, the decryption algorithm and key are all implemented locally. It cannot hide from our dynamic analysis:

image00

The decrypted JSON looks like this:

image07

Using the download link from the JSON file, the real exploit will be downloaded and renamed with an unpredictable number, and stored in the app’s private folder.

image05

The last step is to load the library and trigger the exploit:

image04

The exploit library file has been modified with some anti-debugging mechanisms, such as corrupting its Section Header Table and adding overlapping instructions. However, those efforts only added difficulties on static and dynamic analysis, not loading and execution. We can launch the exploit by loading this library, execute its entrance function and root the target phone.

image06
image08
Corrupted ELF header prevents static analysis. But can be easily repaired

Another rooting tool, B, used a similar architecture as A, and also proved vulnerable against forging requests. Its configure file downloaded from the server has not been encrypted:

image01

The jar file in the figure (…1111.jar) is a compressed file containing some tools for rooting as shown in the figure below:

image09

The root tool B will drop the corresponding root exploit and the related tools in a directory named by a three digit number. It is possible for an attacker to exhaust all the possible device info combinations to steal all the exploits from that vendor.

The dropped exploit is not protected and can be decompiled easily. We learned the way it works, how it exploits the Android system, and the corresponding CVE or non-CVE vulnerabilities involved. More detailed analysis will be included in a later blog post.

Conclusion

The root tool is a double edged sword. Although the vendors tried their best to prevent the exploits being abused, the nature of RaaS makes it difficult to detect whether the client request is forged, nor can the vendors protect their exploits from being abused by someone else. As long as their “root service” is enabled, the possibility of their backend being abused by hackers exists.

We have more research on rooting tools coming up. Stay tuned!