2016-08-24

appscan

 

0x01 背景

WebView是Android系统提供能显示网页的系统控件,它是一个特殊的View,同时它也是一个ViewGroup可以有很多其他子View。在Android 4.4以下(不包含4.4)系统WebView底层实现是采用WebKit(http://www.webkit.org/)内核,出于安全和性能的考虑,在Android 4.4及其以上Google 采用了chromium(http://www.chromium.org/)作为系统WebView的底层内核支持。

 

在这一变化中Android 提供的WebView相关API并没有发生大变化,在4.4上也兼容低版本的API并且引进了少部分API,在目前最新Android 系统版本5.0上基于chromium 37, Webkit JavaScript引起采用WebCore Javascript, 在Android 4.4上换成了V8能直接提升JavaScript性能,但是由于Android系统使用的webview组件远远落后于chromium官方版本,导致android系统默认的webview组件存在了大量Google chrome遗留的历史安全问题,比如各种形式的UXSS以及远程代码执行漏洞。

 

Google官方为了解决这样的问题,在Android 5.0 及其以后,Webview组件已经不再是内置不可更新的系统组件,可以直接通过Google play store下载Android System Webview安装包的形式进行更新,能在不更新Android系统的情况下,直接更新WebView内核。

 

Chromium编译包含了webview组件,如下图:

 

 

 

Chrome官方会不定期发布安全公告以及版本的安全更新,如下图:

 

我们随机选取了一部三星note 4手机升级到官方最新Android 5.1.1版本情况下,可以发现默认系统Android System Webview大版本是43,远远落后于官方最新版本。

0x02 Mobile Pwn2own 2015的 chrome远程代码执行漏洞

360手机卫士安全研究员龚广2015年Pwn2Own比赛使用的cve-2015-6764漏洞攻克了N6手机,这个漏洞是V8引擎的json序列化相关函数实现没有对数组类型进行安全的二次检查,造成了内存越界访问,龚广发表的exploit对该漏洞进行了完美的利用,可以直接通过网页javascript在内存中运行任意的so文件。

 

我们验证了一下cve-2015-6764漏洞,可以成功攻击一些使用了低版本chromium  webview组件的app,运行shellcode绑定端口。测试视频如下:

 0x03 国内自有内核手机浏览器漏洞

目前国内的主流浏览器APP大多数都没有使用系统的webview组件,而是使用了定制的chromium webview组件,俗称自有内核浏览器,比如QQ浏览器、UC浏览器、搜狗浏览器、百度浏览器、360浏览器。以及大规模使用了定制浏览器内核服务的APP,如微信等海量的主流APP使用了腾讯代号为X5的浏览服务。

使用了过低版本的chromium定制内核的APP会存在大量未知的UXSS漏洞

在UXSS方面,随机抽取几个自有内核手机浏览器测试发现会有大量的uxss漏洞尚未修复,如下图所示:

使用了过低版本的chromium定制内核的APP会存在未知的远程代码执行漏洞,如近日 “BadKernel”漏洞

近日,360手机卫士阿尔法团队再次发现Chrome V8引擎“BadKernel”漏洞。该漏洞存在于V8引擎的历史版本中,远程攻击者可利用该漏洞对使用受影响引擎的产品进行远程攻击。

 

通过此漏洞攻击者可实现微信远程代码执行,获取微信的完全控制权,危及用户朋友圈、好友信息、聊天记录甚至是微信钱包,可使上亿微信用户受到影响,危害巨大。由于腾讯浏览服务提供的X5 SDK中的X5 内核集成了Chrome V8引擎,该引擎受上述漏洞影响。根据腾讯浏览服务介绍,使用X5 SDK的微信、手机QQ、QQ空间、京东、58同城、搜狐视频、新浪新闻等Android手机APP均可能受该漏洞影响。利用该漏洞在微信 Android APP上实现反弹shell的视频如下:

http://weibo.com/p/2304445bee6e775e81ad8b0486eaa519ea223b

 

该问题影响的版本是使用V8引擎3.20至4.2版本的厂商。影响Android 4.4.4至5.1版本系统,以及使用相关组件和定制组件的APP。

 

Android 5.0受影响的V8代码位置:

https://android.googlesource.com/platform/external/chromium_org/v8/+/lollipop-cts-release/src/object-observe.js#318

https://android.googlesource.com/platform/external/chromium_org/v8/+/lollipop-cts-release/src/messages.js#75

漏洞代码分别为:

throw MakeTypeError(“observe_accept_invalid”);
observe_invalid_accept: [“Object.observe accept must be an array of strings.”]

 

在chromium浏览器v8内核4.4修复版本为:

https://chromium.googlesource.com/v8/v8.git/+/4.4.1/src/object-observe.js#274

https://chromium.googlesource.com/v8/v8.git/+/4.4.1/src/messages.js#87

修复后的代码分别为:

throw MakeTypeError(“observe_invalid_accept”);
observe_invalid_accept: [“Third argument to Object.observe must be an array of strings.”],

 

漏洞检测代码:

<script>

var kMessages;

Object.prototype.__defineGetter__(“observe_accept_invalid”,function()   {kMessages=this});

try{Object.observe({},function(){},1)}catch(e){}

delete Object.prototype[“observe_accept_invalid”];

alert(kMessages);

</script>

浏览器如果访问如下网页,若能取到kMessages对象,弹出object则存在漏洞,若弹出undefined则不存在漏洞。

可在微信任意聊天对话框中输入“//gettbs”(不含引号),如果tbsCoreVersion大于36555则说明该漏洞已经修复。

如受漏洞影响,请及时关注厂商发布的补丁。

在漏洞未修复前,建议用户不要点击不可信链接。

 

 

0x04 行业影响情况

通过对360显危镜数据中抽样调查,发现使用定制Chromium 自有内核的APP高达430款,其中不乏用户量过亿的主流APP,安全风险主要分布行业如下:

 

请使用定制Chromium自有内核的厂商注意排查和修复安全漏洞。使用了相关浏览服务的厂商关注官方的安全升级,避免产品出现安全隐患。

 

0x05 参考链接

  1. http://www.cnnvd.org.cn/vulnerability/show/cv_id/2016080414
  2. https://github.com/secmob/cansecwest2016
  3. http://www.androidcentral.com/android-webview-security
  4. https://developer.chrome.com/multidevice/webview/overview
  5. http://x5.tencent.com/guide?id=4000

 

2016-08-18

appscan

本月一共有105个安全漏洞,其中Critical 13个,High 79个,Moderate 13个,其中属于Aosp部分的有26个,驱动和kernel的有79个。

下面是与7月份的漏洞数量对比图:

 

 

漏洞分布情况对比图:

 

1、Aosp高风险安全漏洞

 

Aosp的漏洞主要集中在mediaserver模块中,这也是最近安全研究漏洞挖掘的热点模块。下图是这个月aosp漏洞的整理。

 

 

A)以下高风险安全漏洞在mediaserver组件中,可以被任意app触发。

 

CVE-2016-3819、CVE-2016-3820、CVE-2016-3821是三个Critical级的远程代码执行漏洞。分别影响libstagefright_soft_h264dec.so、libnbaio.so、libstagefright_soft_avcdec.so三个so文件。

 

Mediaserver远程代码执行漏洞可能允许攻击者使用专门制作的媒体文件来攻击手机,在解析媒体文件时会发生内存崩溃。这个漏洞由于可能在Mediaserver进程中发生远程代码执行,所有被评为Critical。Mediaserver进程有权限访问音频和视频流,第三方应用程序不能。

 

CVE-2016-3819是一个h264编码的MPEG4文件能构造一个足够大的picSizeInMbs,导致在h264bsdInitDpb内分配一块足够大的内存,导致堆溢出。

 

CVE-2016-3820是libavcodec H.264的解码器在解析MPEG4文件时会导致堆溢出。

 

CVE-2016-3821是MediaPlayer中的一个use-after-free漏洞。

 

CVE-2016-3823、CVE-2016-3824、CVE-2016-3825、CVE-2016-3826是四个High级别的提权漏洞。分别影响libOmxVenc.so、libstagefright_omx.so、libaudioflinger.so三个so文件。

 

权限提升漏洞可以被本地的恶意应用用来执行恶意代码进行提权,mediaserver的漏洞,可以被用来提权到system。

 

CVE-2016-3823是由于libOmxVenc.so中的omx_video::empty_this_buffer_proxy()会使用memcpy函数拷贝一块数据到0xdeadbeef,可以通过精心构造的数据控制0xdeadbeef来进行提权。

 

CVE-2016-3824是由于libOmxVenc.so中的omx_video::allocate_output_buffer()会分配一个固定的堆缓冲区,当OMXNodeInstance::emptyBuffer被用作一个输出缓冲区计数器,在调用CopyToOMX时会发生堆溢出。

 

CVE-2016-3825是omx_video::allocate_input_buffer()可以被通过精心构造的binder request分配一块错误大小的堆内存,导致堆溢出。

 

CVE-2016-3826是PreProcessing.cpp这个C++文件中的EFFECT_CMD_GET_PARAM会导致整形溢出,造成堆溢出。

 

B)以下高风险安全漏洞在libjhead组件中,可以被任意app触发。

 

CVE-2016-3822是High级的远程代码执行漏洞,影响libjhead.so。

libjhead.so的远程代码执行漏洞可以被攻击者用一个特殊构造的文件在当前环境下执行任意代码。

 

CVE-2016-3822是一个构造的Offsetval长度传递到libjhead中的ProcessExifDir方法后会导致越界写内存。

 

C)其他风险级别较低的受影响so文件

 

libstagefright_soft_hevcdec.so、libcrypto.so、libcamera_client.so、libstagefright.so、libsurfaceflinger.so、libwifi-service.so、bluetooth.default.so、libconscrypt_jni.so

 

2、kernel高风险安全漏洞

 

A)CVE-2015-2686、CVE-2016-3841、CVE-2016-3857是Critical级的提权漏洞。

CVE-2015-2686是在net/socket.c文件中,影响linux内核3.19.3之前版本。由于sendto和recvfrom系统调用没有验证数据范围,本地权限用户,可以利用iov_iter接口的copy_from_iter方法来进行提权。

 

CVE-2016-3841是特定的内核networking组件会导致的use-after-free漏洞。

 

CVE-2016-3857是sys_oabi_epoll_wait方法没有验证传递的参数。修复方法是直接禁用了OABI支持,删除了代码。

 

B) CVE-2015-1593、CVE-2016-3672、CVE-2016-2544、CVE-2016-2546、CVE-2014-9904、CVE-2012-6701、

 

CVE-2016-3845、CVE-2016-3843是High级的提权漏洞。

 

CVE-2015-1593是在linux内核3.19.1之前的版本,64位上栈随机特性在处理按位左移时返回值类型不正确,可以被攻击者利用绕过ASLR。

 

CVE-2016-3672是arch/x86/mm/mmap.c中的arch_pick_mmap_layout方法在随机化基地址时有错误,可以被用来绕过ASLR。

 

CVE-2016-2544是在sound/core/seq/seq_queue.c中的queue_delete方法,有一个race condition(正确性依靠于事件发生的相对时间)有use-after-free漏洞,可以被使用ioctl触发。

 

CVE-2016-2546是在sound/core/timer.c文件中(linux内核4.4.1之前),mutex类型不正确导致的use-after-free漏洞,可以被精心构造的ioctl触发。

 

CVE-2014-9904是在snd_compress_check_input方法中的整形溢出检查会被绕过。

 

CVE-2012-6701是在fs/aio.c文件中的整形溢出漏洞(在linux内核3.4.1之前),能够被本地用户触发的拒绝服务漏洞,或者其他未发现的影响。

 

CVE-2016-3845是传递到on_cmd_write方法的计数变量没有验证。

 

CVE-2016-3843是一些内核为开发者使用的子模块,在正常发行版中不应该存在。

 

3、高通和MTK的驱动漏洞

A) 高通Wi-Fi驱动中存在远程代码执行漏洞

 

高通组件提权漏洞CVE-2014-9902是一个高通Wi-Fi驱动模块中的漏洞,可以被远程攻击者利用来在内核空间中远程执行代码,可能导致整个设备被完全控制,因此被定义为critial级别。找到patch信息,很容易就能判断是个整型溢出漏洞在源代码树中找到相关文件可以看到这个漏洞相关文件最终被编译进了设备相关的驱动文件prima_wlan.ko(msm8960)或者pronto_wlan.ko(msm 8974、msm8226、msm8610)。

 

 

高通组件包含了bootloader、camera driver、character Driver、networking、sound driver 和video driver等。下面这张表格中是8月的高通组件相关的漏洞。

 

CVE-2014-9863 这是一个存在于diag driver中的漏洞。在diag drive中存在一个整型下溢问题,这可能导致内存泄露,存在别利用提权风险,因此被定为critical级别。补丁中条件语句添加了边界检查来保证正确性。

 

CVE-2014-9864和CVE-2014-9865都是Qualcomm Secure Execution Communicator driver中的漏洞,Qualcomm Secure Execution Communicator driver为用户空间和QSEE(Qualcomm Secure Execution Environment)之间的通信提供接口。补丁对IOCTL中参数类型和合法性进行了校验。

 

CVE-2014-9866 是高通的csid driver中的一个漏洞,补丁对num_cid进行了上下边界的检查,从而保证从用户空间中传递进来的num_cid在合法的1到16这个区间。

 

CVE-2014-9870 是在ARM MPCore(Multi-Processor Core)多核心架构下添加了对每个thread寄存器的保护操作来代替之前的清除操作。即在上下文切换和fork()操作的时候保存用户读写寄存器TPIDRURW的值,来避免总是必须要在copy_thread函数中来进行TPIDRURW的读操作,这样做十分不安全,可能被攻击者利用来提升权限。

 

CVE-2014-9881 是Qualcomm IRIS FM support模块中的漏洞。其中将unsigned int转换为int以及将int 转换为unsigned int存在缓冲区溢出风险。补丁对此进行了修补。默认情况下这个模块是不会被编译进内核的,如果设备搭载了高通的FM芯片组(IRIS)则可能受影响。

 

CVE-2014-9882 是Qualcomm IRIS FM support模块中的漏洞,在从用户空间传递数据到driver的时候添加driver中接收这些数据的buffer大小检查操作,否则可能导致数组越界访问问题,存在权限提升风险。CVE-2014-9885是高通8974温度检测的AD转换驱动中的漏洞在一个snprintf函数中添加了格式模板,来避免引起安全问题。

 

CVE-2014-9887 是Qualcomm Secure Execution Communicator driver中的漏洞,Qualcomm Secure Execution Communicator driver为用户空间和QSEE(Qualcomm Secure Execution Environment)之间的通信提供接口。补丁检查了qseecom_send_modfy_cmd的cmd_req_buf pointer offset的有效性,并且 对cmd buffer 的地址是否在shared bufffer的范围内进行判断。

 

CVE-2014-9888  是搭载高通芯片组设备上的DMA驱动模块中的漏洞。 通过DMA 映射的内存被标记为可执行的,这不是我们希望的,patch对此进行了修补。

 

CVE-2015-8937 是diag模块中的漏洞,Diag driver持有socket进程的task structure甚至当进程已经退出了以后。这个漏洞的补丁就是,在进程退出时清理内部的task structure结构句柄。

 

CVE-2015-8939 是msm video driver中的漏洞,补丁进行了一些边界检查操作来防止出现一些未定义行为的发生。

 

CVE-2015-8941 这个漏洞是msm camera driver 中添加了一些数组越界检查操作。

 

CVE-2015-8942 存在于msm camera driver中,在使用CPP去操作iommu上下文时必须检查stream的状态。

 

CVE-2015-8943 漏洞位于高通的video驱动中,漏洞可能引发对未mapped的buffer的unmap操作问题,因此补丁在unmap操作前添加了是否mapped的校验代码。

 

CVE-2014-9891 是Qualcomm Secure Execution Communicator driver中的漏洞,Qualcomm Secure Execution Communicator driver为用户空间和QSEE(Qualcomm Secure Execution Environment)之间的通信提供接口。ION memory是用来userspace的process之间或者内核中的模块之间进行内存共享的,也是Android上kernel的一些变化,在用户空间通过IOCTL操作时,data指向的location的合法性未进行检测,可能导致指向其他未分配的无效内存从而导致crash或者指向其它不合法内存引起不可预期的影响。

 

CVE-2014-9890 这个漏洞是I2C驱动中I2C command的长度问题,因为I2C command包含10 bytes的data和1 byte的WR command,因此为11字节,而未修补之前的定义是data[10],可能造成数组越界问题。

被攻击者合理利用可能获得权限提升。

 

B) MTK驱动中的漏洞

 

 

MTK Wi-Fi驱动中的本月被爆存在CVE-2016-3852漏洞,这是一个信息泄露漏洞。在驱动模块的priv_get_int函数中未对传递进来的prIwReqData变量进行校验,可通过传入非法值造成信息泄露问题,结合其他类型的漏洞可被用来作为权限提升的跳板,因此被定为High级别。补丁对传入参数的边界进行了校验。

 

4、受影响进程列表

 

 

 

 

 

2016-08-12

appscan

众所周知,在Android 4.4系统上 Google已经将系统默认的Webkit内核替换成自己的开源项目chromium,并在Issue 213693005(https://codereview.chromium.org/213693005)屏蔽 了webview的object.getClass,android在4.4.4版本上彻底从native层禁止了webview对getClass的调用,从而阻断了一条反射执行命令的道路。但是Context的getClassLoader().loadClass(“java.lang.Runtime”)却是没有被禁止的。

 

0x1 漏洞原理

同样是webview远程代码执行,原理也是通过反射的方法调用“java.lang.Runtime”来执行命令。不过不能使用getClass,但是可以使用getClassLoader,代码如下:

 

示例代码
var loader = window.local_obj.getClassLoader();

var runtimeClass = loader.loadClass("java.lang.Runtime");

var p=runtimeClass.getMethod("getRuntime",null).invoke(null,null).exec(["ls","/etc/hosts","-l"]);

 

0x2 漏洞限制

addJavascriptInterface绑定的对象必须为context的子类(一般都是activity),因为这样才能调用getClassLoader。

targetSDKversion <17,只有在targetsdk小于17的时候才能调用js对象的任意方法,targetsdk>=17的情况下只能调用加了@JavaScriptInterface注解的方法。

 

0x3 扫描方法

通过分析整个反编译后的smali文件,搜索addJavascriptInterface方法,如果当前类的父类为Context的子类则判定为有漏洞:代码如下:

扫描代码
if apkinfo['manifest_info'].is_internet:

        if int(apkinfo['manifest_info'].target_sdk) <= 16:

            rets = search_invokes("Landroid/webkit/WebView;","addJavascriptInterface")

            ret_ = []

            if len(rets) == 0:

                r_rets.update({'risk':0,'result':[{'vul_id':vul_id,'md5':apkinfo['md5']}]})

                return r_rets

            else:

                for r in rets:

                    r.update({'vul_id':vul_id})

                    r.update({'md5':apkinfo['md5']})

                    v_no = r['dst_params'].split(' ')[1][:-1]

                    if v_no == 'p0':

                        if get_superclass(r['src_class']) in target_superclass:

                            if r not in ret_:

                                ret_.append(r)

 

目前APPscan已支持对此新型webview远程代码执行的检测。

0x4 市场影响

因为无视google对getClass的屏蔽,所以与android版本无关,只与targetSDK版本有关,在android4.4,5.0,5.1,6.0上均能实现远程代码执行。

通过对APPscan大数据中的13万 app以及手其他数据来源的8万app扫描,得出以下结果:

Appscan数据 其他来源
App总量 133200 85574
符合条件(targetsdk<17,可上网,非加固) 18087 38179
漏洞数量 203 1144

       

 

2016-08-09

appscan

0x1 漏洞初现

FFmpeg SSRF与本地文件读取漏洞最初来源是国外的漏洞平台,去年已在CTF比赛中被使用。官方今年一月份发布修复版本并公布了漏洞。在今年blackhat也会有这个漏洞的相关议题,同时360产品线也收到了相关漏洞报告,目前已完成修复。

 

0x2 FFmpeg简介

FFmpeg的是一款全球领先的多媒体框架,支持解码,编码,转码,复用,解复用,流媒体,过滤器和播放几乎任何格式的多媒体文件。支持无数编码的格式,比如,HLS。

HLS(HTTP Live Streaming)是Apple公司开发的一种基于HTTP协议的流媒体通信协议。它的基本原理是把一个视频流分成很多个ts流文件,然后通过HTTP下载,每次下载一份文件。在一个开始一个新的流媒体会话时,客户端都会先下载一个m3u8(播放列表 Playlist)文件,里面包含了这次HLS会话的所有数据。

 

0x3 漏洞原理

问题就出在解析这个m3u8文件的时候,解析文件会得到ts流的http地址,我们并不一定非要得到一个视频文件流,可以是任意url地址,只要符合ffmpeg官方的协议头,所以造成了ssrf漏洞;并且不巧的是,官方还支持file协议,再再不巧的是,官方还有自己的concat协议,用来拼接url,所以出现了本地文件读取漏洞。下面是一个m3u8文件的格式:

然后构造一个媒体文件,去访问这个m3u8文件:

当我们本地打开这个文件,通过ffmpeg去解析的时候,将会触发漏洞:

 

0x4 漏洞危害

使用这个漏洞,可以通过上传漏洞视频,然后播放,或者在转码过程中,触发本地文件读取以获得服务器文件。漏洞刚爆出时,在服务器端影响较大,国内主流视频网站均受到波及。后经过跟进发现,安卓和苹果客户端如果使用了自己编译的有漏洞的ffmpeg库,同样能触发本地文件读取漏洞,这样使用一段视频,就能获得手机中的文件内容了。

 

0x5 漏洞修复

通过查看官方源码,在解析HLS编码时,ffmpeg禁止了所有协议除了http(s)和file协议,修改方法如下:

如果有使用ffmpeg的程序,请参照下面的版本进行升级:

FFmpeg 2.8.x系列升级至2.8.5或以上;

FFmpeg 2.7.x系列升级至2.7.5或以上;

FFmpeg 2.6.x系列升级至2.6.7或以上;

FFmpeg 2.5.x系列升级至2.5.10或以上;

或直接使用FFmpeg 3.0.x版本。

 

0x6 漏洞扫描方法

通过对比修复补丁我们发现,特征字符串为“file,”,在编译好的so文件中的rodata段中能搜索到字符串“file,”,证明此so版本为修复后的版本。具体的扫描代码如下:

test
command = '\.rodata'
cmd = "readelf -S %s | grep '\s%s'" % (file_path,command)
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
ret,err = process.communicate()                  
rets = ret.lstrip().split(' ')
if len(rets) == 0:
    continue
r = []
for _a in rets:
if _a != "":
        r.append(_a)
if '.rodata' not in r:
continue
rodata_type = 0
if r[1] == '.rodata':
    rodata_type = 3
if r[2] == '.rodata':
    rodata_type = 4
if rodata_type != 0:
with open(file_path,'rb') as f:
        f.seek(int(r[rodata_type],16))
        data = f.read(int(r[rodata_type+2],16)).replace('\0','\n')
        if 'detect bitstream' in data:
            rr = data.split('\n')
            if 'file,' in rr:
                print ‘not vul’
            else:
                print ‘vul’

目前APPScan已经支持对ffmpeg漏洞的扫描。

0x7 市场APP状况

通过对appscan大数据中的124371款app扫描,发现受此漏洞影响的产品数量为6314款,占总数的5%。并对其中受影响的app所使用的ffmepg库文件做了个top10统计。



其中使用率最高的libeasemod_jni.so属于环信sdk所带的库文件,libcyberplay-core.so是百度开放云播放器的Android SDK。

通过深入研究发现,即使使用了低版本有漏洞的FFmpeg库文件,如果app业务功能中未涉及到HLS功能,将不会触发漏洞逻辑,避免了危害的发生。环信sdk就是这样的一种情况。

上图是受影响app分类top10。