Posted by & filed under malware, potentially unwanted app, vulnerability.

– By Trustlook Research Team

You thought you installed an accelarating tool, when in fact a backdoor has sneaked into your mobile phone.

Leidian OS was recently promoted by the Qihoo 360 security tool. It claimed that if you flash Leidian OS into your mobile phone, the phone will run 30% faster and will save more battery life.

We analyzed Leidian OS and its installation process, and found that the Leidian OS actually contains a backdoor function which flashes a customized recovery image into the mobile phone using the fastboot tool. It also uninstalls system updates from other security apps (most of which are pre-installed apps by mobile phone vendors) according to a predefined blacklist and whitelist. The uninstallation of these apps will expose the mobile phone to security vulnerabilities.

Leidian OS also installs the Leidian App market, Leidian browser, Leidian assistance, Leidian acceleration and the 360 security tool without the user’s consent. Moreover, it modifies the system’s certificate to install apps in the /system directory and to get the SYSTEM privilege. As a consequence, it can execute critical operations and hook important functions to monitor system activities. It also leverages Qihoo360’s root tool to get the root access. Last but not least, the Qihoo360 security tool doesn’t give a clear notification to users when the Leidian OS is being flashed. Instead, it just tells the user to “experience a much faster mobile phone” by making a simple click in Fig. 1. It doesn’t specify the risk to the user after the process. All these actions make the user more exposed to an unsecure environment.

After our analysis, we found that Leidian OS is developed by two companies called “KuRuiMeng” and “CHIMA”, which are subsidiaries of Qihoo360. Leidian OS has embedded several modules of the Qihoo360 mobile security tool as well.

Below is the detailed analysis, along with the steps to install the Leidian OS.

As shown in Fig. 1 and 2, by installing the latest Qihoo360 security tool in the Windows version and clicking “more” in the lower right corner to get more tools, you will find “Leidian OS” to open the installation window.

 

 

Fig.1 – The entrance to the Leidian OS in Qihoo360 security tool – Step 1. 

Fig.2 – The entrance to the Leidian OS in Qihoo360 security tool – Step 2. 

3

Fig.3 – The installation window of the Leidian OS in Qihoo360 security tool

 

When clicking the green “experience instantly” button in Fig. 3 above, the Qihoo360 security tool begins to download the related files and applications, which are saved in

 C:\Documents and Settings\Administrator\Application Data\CleanAndroid.

 

4

Fig.4 – Begin to install the Leidian OS to the mobile phone

By monitoring the downloading process, we found that these files were downloaded by the360CleanHelper.exe process.

We also found the related JSON file containing the downloading information as shown in Fig. 5 and the json file in Table 1.

5

Fig.5 –  360CleanHelper.exe drops the Leidian OS installation files

dl_info_json

 

Table.1 – The JSON file containing the downloading information.

6

Fig.6 – Downloading information of the Flash tool

7

Fig.7 – The flash tool package

8

Fig.8 – The flash tool package in the Cleandroid directory

9

Fig.9 – Files in “tools” directory of the “Cleandroid” directory

From the tools package info we see that the Leidian OS is installed by flashing the recovery.img into the

phone with the fastboot tool. Then it uses an “adb” tool to install apks into the phone. According to the

JSON file in Table 1 the download address is dl.so.keniub.com. By monitoring the ip (101.199.109.90)

and querying its DNS info we find that the download server is hosted by Qihoo360. From the

Leidian OS’s customer service webpage

(http://leidianos.com/privacy.html) we find that the company’s address is same with that of Qihoo360,

which further reveals the development and operational relationship of Leidian OS and Qihoo360.

10

Fig.10 – The download address of the Leidian OS

11

Fig.11 – The DNS query info of the download address

As shown in Fig. 9, the details of the files in the CleanAndroid directory are explained as follows:

  • ChiMaster.zip contains an apk file, which is used for auto-starting after the boot process and to start some important services.
  • com.chima.customizationassist contains a file called Hurricane.apk.
    • It’s used for uninstalling or disabling some apps according to a blacklist and a whitelist.
  • com.leidianos.osspecial.zip contains an App which realizes a custom App loader.
    • It uses this tool to automatically capture the WeChat bonus in WeChat chat groups.
    • This feature is popular and is used to attract more users to install Leidian OS.
    • But it will make the WeChat App unsecure, resulting in the possible disclosure of the WeChat username and password.
  • leidianLauncher.zip displays the UI of the Leidian OS and starts some apps.
  • leidianProvider.zip uninstalls some system apps according to a blacklist and a whitelist.
  • donghua.zip displays animation after the mobile phone is booted.
  • netd.zip is for network management and the firewall function.
  • update.zip contains a dexdump tool to parse the dex files.
  • UpdateCentre.zip is for rooting the mobile phone and hooking some important functions.

Here we explain the certificate of the attached files:

leidianLauncher.apk file’s certificate is shown in Fig. 12:

12

Fig.12 Certificate of the leidianLauncher.apk file

chima.apk file’s certificate is shown in Fig. 13:

13

Fig.13 Certificate of the chima.apk file

As shown in Fig. 12 and Fig. 13, they are developed by KuRuiMeng and CHIMA, which are subsidiaries of Qihoo360.

Below is the analysis to three important Apps (ChiMa.apk,updateCenter.apk,Hurricane.apk).

1. ChiMa.app

 

The package name is com.chima.vulcan. It is installed in the /system directory in the user’s phone and has the same

certificate with the OS so it can get the system privilege as shown in Fig. 14. Therefore, it will start after the mobile

phone starts. It collects user’s information, including IMEI/Serial Number/operator/gender/location/CPU info/running

processes list, etc.

14

Fig.14 – The SYSTEM uid owned by the Chima.apk

This App drops a file called libchimahelper.so in its assets directory, and it hooks three important functions:

bindService, startService, getContentProvider in dalvik layer (as shown in Fig. 15). This allows it to monitor

and control some communications between the components in the system.

15

Fig.15 – The hooking to bindService function in chima.apk

The App also implements many sensitive remote execution commands, such as installing Apps remotely,

disabling Components remotely, etc. The command list is shown in Fig. 16.

16

Fig.16 – Some remote execution commands in the Chima.apk

As shown in Fig. 17, we found that multiple function calls in this app are implemented by reflection.

The method is often used by malware for evasion purposes in anti-virus detection.

17

Fig. 17 – Reflection calling to some functions used in Chima.apk

2. updateCerter.apk 

 

The app is for rooting and hooking the system (as shown in Fig. 18). It allows for full control of the mobile phone.

18

Fig. 18 – The hooking to many functions in the updateCerter.apk file

The app also hooks the native functions, as shown in Fig. 19.

19

Fig.19 – The hooking to the native functions

Root module RootMan is located in com.qihoo.permmgr.RootMan package. After our verification we found that

this module is the same as that in Qihoo360’s root tool (in the name of “360 Root By One Click”).

By concatenating the strings of different mobile phone models and related info, we send them to Qihoo360’s

server as shown in Fig. 20. Then we got different root exploits to execute as shown in Fig. 21.

20

Fig.20 – Concatenation of a special URL for downloading respective root exploits using specific phone models

21

Fig.21 – Execution of the root exploit in updateCentre

3. Hurricane.apk 

 

The app is for uninstalling the apps in a user’s mobile phone according to a list, including most of the mobile

phone vendors’ updates and security applications. After this uninstallation process, a user’s mobile phone

will be less secure. The uninstallation App list is as follows:

com.aliyun.fota
com.tencent.nanji.updater
com.yulong.android.ota.client
com.facebook.katana
com.bbk.updater
com.android.guanli
com.lenovo.safecenter
com.dxkj.xsb
com.smartisanos.updater
com.android.ota
com.nokia.update
com.adups.fota
gn.com.android.update
com.lge.update
cn.nubia.systemupdate
com.android.update
com.android.GioneeSysUpdate
com.lenovo.safecenterpad
com.huawei.systemmanager
com.htc.UpgradeSetup
com.lenovo.ota
com.meizu.flyme.update
com.yulong.android.seccenter
com.icoolme.android.upgrade
com.zte.zdm
com.zxly.assist
com.mediatek.GoogleOta
com.tianqi2345
com.oppo.trafficmonitor
com.huawei.android.hwouc
com.android.jrdfota
com.yunos.securityagent
com.htc.updater
com.aurora.netmanage
com.hmct.updater
com.qualcomm.update
com.browser2345
com.android.activate
com.mgyun.shua.su
com.android.provision.system
com.newbee.datausage
com.oppo.safe
com.oppo.virusdetect
com.iqoo.secure
com.sec.android.fwupgrade
com.romjd.android
com.hisense.updater
com.oppo.ota
com.yulong.android.ota
com.wsdm
com.ahong.update
com.sec.android.fotaclient
com.policydm

com.lenovo.safecenter.plugin

Com.wssyncmldm

Suggestions: Go to your mobile phone vendor’s official website to find the correct recovery image file and reflash your mobile phone if Leidian OS has been installed.

Posted by & filed under vulnerability, zero-day.

 

“这不是bug,是功能。” -程序员常说

“这不是漏洞,是后门。” -黑客们常说

The door at the beach

 

Trustlook在之前的一篇Blog已经demo过360浏览器上的新“虫洞”漏洞,这次将公布一些细节。

360浏览器安卓版不用多介绍了,在360,腾讯和豌豆荚上的下载量加起来超过4.6亿。这次的“任意门”漏洞威力要大过百度“虫洞”及360手机助手“异次元之门”:攻击者并非受限于几个远程控制功能,而是可以执行任意指令。在root过的手机上,可以毫无问题的远程静默安装及卸载app。如果做成蠕虫,批量扫描3G/4G网络,并自动攻击传播,后果不堪设想。

Screen Shot 2015-11-24 at 1.21.44 AM

 
漏洞的演示视频如下:

受影响的安卓版360浏览器版本为6.9.9.70 beta及以下。在11月23日,有白帽子将漏洞发到了乌云(http://www.wooyun.org/bugs/wooyun-2015-0155003),24小时内Trustlook发布了漏洞的demo(http://blog.trustlook.com/2015/11/24/a-glance-at-the-wormhole-on-360-browser/)。360在同一天更新了修复漏洞的6.9.9.71 beta。鉴于此漏洞的巨大危害,我们没有马上公布漏洞利用细节,给了用户更多时间修补。

360浏览器在卸载的时候会弹出一个“用户调查”,询问用户卸载原因。这个功能是在一个叫um.3(UninstallManager的缩写)的so文件里实现的。这个库文件会开启一个独立进程,在收到卸载的消息后,会使用”am start”命令开启浏览器,显示“卸载调查”网页。

image3
um.3从asset中被释放出来

image2
um.3会占有一个独立进程

um.3的进程间通信机制是用一个自定义的HTTP server实现的。如同所有的虫洞漏洞一样,成了万恶之源。这个server会监听手机的6587端口,允许所有地址连接。但它支持的功能很简单:1. 查看版本 2. 开启浏览器

image1
um.3会在第一次启动后监听6587端口

比如,弹出那个“卸载调查”的时候,执行的命令如下:

/data/data/com.qihoo.browser/files/so_libs/um.3 com.qihoo.browser –execute am start -n com.android.browser/.BrowserActivity -a android.intent.action.VIEW -d http://serv.mse.360.cn/whyuninstall?Mid=95767669835b2b90bc459ee68d1ea6a7\\&Wid=81e188a23869a898d1343eaa20c11495
\\&Verc=6.9.9.14\\&Mdl=iPhone\\&Osver=4.2.1\\&Net=WIFI\\&Chl=h986596
–user 0

但程序员在这里犯了很要命的错误。

1. 命令使用system函数执行,对命令本身没有任何过滤。

2. 弹出网页的url是作为命令的一部分传进去的,而这个url是远程可控的,直接来自远程请求的GET参数。

只要攻击者利用分号将前一条命令分隔开,后面写的所有恶意指令都会被360浏览器忠实的执行。。。

为了搞清楚这个HTTP server的一些逻辑,我们用IDA Pro/HexRay把um.3逆向成了C代码,并加了注释。关键的函数有两个:sub_9018和sub_9078,分别用来解析URL参数,和实现HTTP server逻辑。有兴趣的读者可以点开大图看。

Untitled drawing (9)

 
简而言之,出现问题的命令是这样的:

am start -n com.qihoo.browser/.BrowserActivity -a android.intent.action.VIEW -d %s -e from %s

其中GET参数”u”的值会被带进第一个%s,而GET参数”t”必须为”1”。

只要一行代码,发送一条request,就可以在一台装了360浏览器的手机上远程执行任意代码:

curl -X http://[target IP]:6587/t=1&u=www.trustlook.com;echo 1>/sdcard/lol.txt;

执行,你会发现目标手机的sd卡下面多了一个lol.txt。更复杂的攻击功能,就靠你的想象力了;-)

Screen Shot 2015-12-10 at 6.23.14 PM
命令执行成功你会看到这条返回

对于非root手机,攻击者会有和360浏览器相同的权限。包括发送和访问短信,读取通话记录,访问浏览记录,监控摄像头和麦克风。。。
Screenshot_2015-11-24-00-36-15Screenshot_2015-11-24-00-36-22

对于root手机,攻击者就天高任鸟飞了,比如静默卸载和静默安装。即便用户装了”SuperSU”等root管理软件,请求root权限的进程也会显示为“360浏览器”,相信数字公司的用户也是见怪不怪啦,骗得信任很容易。

Screenshot_2015-11-24-00-34-29

 
最后,Trustlook建议广大用户确保自己已升级到了6.9.9.71及以上版本。

Posted by & filed under vulnerability, zero-day.

 

“It’s not a bug. It’s a feature.” – A developer’s quote

“It’s not a vulnerability. It’s a backdoor.” – A hacker’s quote

The door at the beach

 

We first introduced “Anywhere Door” (in Chinese: “任意门”) in this previous article. “Anywhere Door” is a new Wormhole vulnerability that affects versions of the 360 Browser prior to 6.9.9.70 beta. By sending a certain crafted HTTP request, a remote attacker can execute an arbitrary shell command on the target phone, with the privilege of the 360 Browser app. If the phone is rooted, the attacker can do anything on the root user’s device, such as install and remove apps.

In this article, we will disclose more details of this vulnerability.

Like all the Wormhole vulnerabilities that have come before it, “Anywhere Door” is triggered on a customized HTTP server, on the port 6587. The server is used for cross-process communications, and contains a few APIs, such as popping-up a browser window. The purpose of this API is to display an “uninstall survey” when the main app is being removed. And the server logic is implemented by a native library (.so file) called um.3 (UninstallManager we guess?)

image1

Port 6587 will be opened upon the first launch of the 360 browser

image2

The HTTP server in um.3 is running in an independent process

image3

The um.3 will be copied from the assets folder to so_libs folder

When handling the “launch browser” request, we found the um.3 directly executes a shell command to launch the browser process. For example, when popping up the “uninstall survey”, the command is goes like this:

/data/data/com.qihoo.browser/files/so_libs/um.3 com.qihoo.browser –execute am start -n com.android.browser/.BrowserActivity -a android.intent.action.VIEW -d http://serv.mse.360.cn/whyuninstall?Mid=95767669835b2b90bc459ee68d1ea6a7\\&Wid=81e188a23869a898d1343eaa20c11495
\\&Verc=6.9.9.14\\&Mdl=iPhone\\&Osver=4.2.1\\&Net=WIFI\\&Chl=h986596
–user 0

There is a critical vulnerability in this design: the url, which is part of the shell command, is controllable by a HTTP GET parameter. And the entire command is executed via system() without any filtering, causing a remote command injection vulnerability. A remote attacker could use “;” to close the original “am start” command, add any malicious commands after the “;”, and have those commands executed by the 360 browser on the target phone.

We reverse engineered the um.3 using IDA Pro/HexRay. The critical code is mainly in 2 functions: sub_9018 and sub_9078, which are used for handling HTTP server logic and GET parameter parsing. The code logic is explained in the comments in the following figure (click for enlarged image):

Untitled drawing (9)

From the reversed C code, we can see that the raw command to be executed is:

am start -n com.qihoo.browser/.BrowserActivity -a android.intent.action.VIEW -d %s -e from %s

And the value of GET parameter “u” will be filled in the first “%s” (while the “t” value must be set to “1”). To exploit it, all an attacker needs to do is simply send the following request:

curl -X http://[target IP]:6587/t=1&u=www.trustlook.com;echo 1>/sdcard/lol.txt;

After that, the attacker will find a lol.txt generated in the sdcard folder.

By default, the attacker could share the privileges of the 360 browser, such as sending and accessing SMS messages, reading the call logs, accessing browser history, and monitoring the camera and microphone.

If you are targeting a rooted phone, you can do almost anything. For instance, silently replacing the user’s banking app with a phishing app (as shown in the following video). Even if the user has installed a root management tool like SuperSU, the confirmation dialog will appear in the name of the 360 browser, which is likely to be trusted by the user.

Reference:
[1] http://www.wooyun.org/bugs/wooyun-2015-0155003

Posted by & filed under News, zero-day.

Screen Shot 2015-11-24 at 1.21.44 AM

 

The 360 browser is a popular browser on both the PC and mobile platforms in the Chinese market. It is known for its security, and has a total download number of more than 460 million on the 360 market, Tencent market and Wandoujia.com combined.

24 hours ago, a new vulnerability of the 360 browser was posted on Wooyun.org [1] (a popular vulnerability disclosure platform in China). After careful analysis of the 360 safe browser (com.qihoo.expressbrowser), another critical vulnerability “Anywhere Door” was found.

Like the “Wormhole” and “DimensionDoor”, the Anywhere Door is triggered on a customized HTTP service. We noticed that HTTP service will not be shutdown even after the app is patched. To stop this service, users need to manually disable it in the system settings, or reboot the phone.

Qihoo pushed the update 6.9.9.71 beta on Nov 23 to address this bug. According to our tests, the previous versions before Nov 23, such as 6.9.9.70 beta, are vulnerable. If you are using the 360 browser, and haven’t updated it after Nov 23, please make sure to update it to 6.9.9.71 beta or newer, then restart your phone.

What can this vulnerability do?

This vulnerability could lead to remote code execution on any Android phone with a 360 browser installed. Keywords: Remote, Silence, Flexible.

For rooted phones: the attacker can do pretty much everything, such as install APKs from the Internet in the background, access emails & SMS, monitor the camera and microphone. It is more flexible than the “DimensionDoor”. If the user has installed a root management tool such as SuperSU, the confirmation dialog will be popped up in the name of the 360 browser, which is likely to be trusted by users.

Screenshot_2015-11-24-00-34-29

For unrooted phones: the attacker could share the permissions of the 360 browser, such as sending and accessing SMS, reading the call logs, accessing browser history, and monitoring the camera and microphone.

Screenshot_2015-11-24-00-36-15Screenshot_2015-11-24-00-36-22

As of today, Nov 23, most of the users have not upgraded their 360 browser to the latest version. The detailed analysis and exploitation code will be released in a later blog, after users have had a chance to protect themselves.

We made a PoC video for this vulnerability. In this demo, we triggered it remotely on a rooted phone, and replaced the genuine banking app with an arbitrary app.

This blog will be updated soon with more details and exploitation simulations. Stay tuned!

Reference:
[1] http://www.wooyun.org/bugs/wooyun-2015-0155003

Posted by & filed under News.

几天前,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日晚),我们发布了一篇分析报告(
http://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视频:

  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或以上版本,你们的安全是我们这支小团队最终的诉求。

Posted by & filed under vulnerability.

 

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

Posted by & filed under vulnerability, zero-day.

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://[client_ip]:38517/[API 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

Posted by & filed under malware, potentially unwanted app, Virus.

 

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

Posted by & filed under Uncategorized, vulnerability.

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.

 

 

Posted by & filed under vulnerability, zero-day.

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.