一 : 安全专家称微信漏洞危害性远高于360手机浏览器漏洞
【通信产业网讯】9月24日,中国互联网安全大会召开期间,安全专家云集北京,金山驱动之家论坛突然爆出“360手机浏览器存在漏洞,可能泄露用户密码”的新闻,随后百度新闻首页重点推荐,引起广泛社会关注。
记者采访与会的几位中外安全专家,专家表示,近期,移动应用方面曝出许多漏洞,其中最严重的一个漏洞是由乌云漏洞平台曝出的腾讯微信、QQ手机浏览器的挂马漏洞,包括百度手机浏览器也都存在此漏洞。
腾讯微信、QQ手机浏览器、百度手机浏览器存在的安卓挂马漏洞,很容易被触发,一旦被利用,用户手机有可能会被执行黑客指令,出现被安装恶意扣费软件、向好友发送欺诈短信、通讯录和短信被窃取等严重后果。因此,包括腾讯旗下安全宝、金山、360等所有安全软件都会向用户做风险提示,此为高危级漏洞,必须尽快修复。
而由金山驱动之家曝光的360浏览器存在的漏洞,但经安全大会专家分析,该漏洞是因为360手机浏览器、海豚手机浏览器等几家,采用安卓系统内核中存在的本地文件漏洞,只在Android4.0及以下版本中存在。
要利用此漏洞实现对用户手机的攻击并不容易,用户需要先中木马,被恶意软件带下一个恶意的html文件到用户手机本地,然后诱导用户用手机浏览器打开这个恶意文件,才会触发这个漏洞。
专家认为,驱动之家以及百度新闻的报道,有意回避了只有用户被下载了恶意文件到手机本地,这个漏洞才会被触发的前提,可能存在夸大的嫌疑。实际上,截止目前,360手机浏览器、海豚手机浏览器都已经修复Android系统中打开本地文件的漏洞,市场上也没有发现受到攻击的实际案例。
二 : Hacking Team安卓浏览器攻击过程中的漏洞分析Stage0(1)
一、漏洞简介
Hacking team今年爆出了针对android4.0.x-4.3.x android浏览器的漏洞攻击利用代码。该漏洞攻击代码,通过连续利用多个浏览器与内核漏洞,完成通过javascript向虚拟内存写数据,执行代码,提升至root权限,并最终达到向目标手机中植入恶意程序的目的。
该利用过程分为5个复杂的Stage,本文首先分析了第1个Stage,即Stage0。 攻击代码的Stage0阶段通过一个0Day地址泄露漏洞,为后续数据填充操作完成定位地址定位的任务。此漏洞位于android-src\external\libxslt模块中。
二、漏洞详细信息
概述
Stage0利用的0Day漏洞原理如下:
该漏洞属于未经正确性检查,就直接错误地进行强制类型转换,从而导致一个用于内存读(实际用于字符串比较)的指针可以被操控。漏洞利用的思路是:通过在JS分配的大片内存空间中,填充字符串:http://www/w3.org/1999/XSL/Transform,程序的后续逻辑会将该字符串会与那个可控内存指针所指向的字符串进行比较,一旦字符串对比不成功,则javascript的一个对象会记录下“Error”,由于指针所指向的地址是可控制的,一旦发现 “Error”,就重新调整地址,直到没有发生Error,这样就得到了javascript开辟的可控空间的内存地址信息。
1. 数据结构背景
图1展示了hacking team所使用的触发漏洞代码:
图1 漏洞触发代码与其内存结构
在浏览器中,我们可以使用javascript引用如图1所示的xsl文件,通过此文件,即可引发stage0所使用的漏洞。图1中的xsl语句,在libxml2解析后,会形成如图1中右图所示结构。其中,xsl描述的cdent节点,即为触发漏洞的ENTITY类型节点。
此漏洞发生在浏览器引擎对xsl文件的解析过程中。因此,我们先简述一下图1中代码,与右图节点的对应关系。右图的myDoc节点为虚的根节点,在左图xsl描述中并没有对应。xsl描述的最外层adoc和ata节点,同为根节点的下的一级子节点,由于adoc是第一个子节点,被myDoc的数据结构中得children指针指向,ata则被adoc的next指针指向。同理,x节点,cdent节点和y节点,同为adoc的子节点一级,形成如上图所示结构。
Hacking Team安卓浏览器攻击过程中的漏洞分析Stage0(1)_攻击类型转换
2. 漏洞成因
程序出现异常的根本原因是由于libxslt在对图1中的cdent(xmlEntity类型)节点进行操作时,并未对此节点的类型进行比较,导致对cdent节点进行了不正确的类型转换(转换为xmlNode类型),并对转换后的节点进行了非法操作。libxslt(android浏览器在对xsl进行解析时所使用的模块)在对xsl操作的过程中,会对大部分节点的namespace进行比较,判断节点是否为一个合法的xsl节点。
但当节点类型为xmlEntity类型时,由于xmlEntity没有ns(用来比较namespace信息的数据结构)字段,所以不对xmlEntity类型进行比较namespace操作(xmlEntity类型、xmlNode类型的详细信息请看图5)。而libxslt在判断节点类型是否为xmlEntity时,libxslt的判断并不完全,最终导致xmlEntity可被转换为xmlNode进行操作。从而引发程序崩溃。
图2 未对所有节点的类型进行判断
触发崩溃的第一步,是由于对节点类型的比较不完全导致的。libxslt在成功构建节点树(如图2中右图)后,会循环对myDoc的子节点进行namespace比较操作,图2中左侧代码,是在循环中当对当前节点的所有操作完成时,将循环操作中的节点指针指向下一个需要操作的节点的代码。根据图2中第4967行的代码,我们可以发现,libxslt是希望当目标节点子节点或next节点的类型不为xmlEntity类型时,将目标节点子节点或next节点赋值给cur指针,再由cur指针进入下一次循环。但是,libxslt只对cur指针的第一个子节点进行了数据类型的比较操作,并没有对cur指针的next节点进行数据类型的比较。而在我们构建的节点结构中,cdent(xmlEntity类型)节点,正是被x的next指针指向的,导致cdent节点不正确的进入了循环。
图3 对namespace进行比较的函数
触发崩溃的第二步,是xmlEntity节点被转换为xmlNode节点。图3为第一步中所说的循环的开始位置(图3代码的4893行),我们可以清晰的看到第一步所用的cur指针的数据类型为xmlNode类型。而第一步的xmlEntity类型被赋值给了xmlNode类型的指针,这就导致了类型转换的错误。
图4 IS_XSLT_ELEM宏的定义
触发崩溃的第三步,是对不正确的数据类型进行了非法操作。图4为图3中IS_XSLT_ELEM宏的展开。IS_XSLT_ELEM宏的操作是比较节点的namespace,判断xmlNode结构体中的ns字段(此字段指向一个xmlNs的数据类型)中的href字段所指向的地址是否存储了字符串“http://www.w3.org/1999/XSL/Transform”。
图5 相互转换的两种数据类型
当IS_XSLT_ELEM宏的输入参数为一个xmlEntity类型时,宏就会将orig字符串当作xmlNs类型的数据结构来操作。由于程序中的orig字符串存储的是xmlEntity节点内的字符串信息,所以在触发漏洞的代码这个例子中,此处存储的字符串为:
'XX';
toascii(addr); // ns->href
toascii(addr); // ns->prefix
'XXXX' // ns->_private
'XXXX' // ns->context
' xmlns:xsl=\'http://www.w3.org/1999/XSL/Transform\' terminate=\'yes\'/>
而在宏中,会把这串字符串当作xmlNs类型来操作。
图6 xmlNs的数据结构
因此可以通过此漏洞达到地址泄漏的目的。可以注意到,当宏将字符串当作xmlNs节点来处理时,代码中转换为ascii码的addr就可以被当作比较的字符串指针(href)来处理(详细信息见图4)所以我们可以将任何可以转化为ascii码的地址写入href指针,从而让这些指针所指向的字符串与“http://www.w3.org/1999/XSL/Transform”进行比较。
如果比较结果为真,则继续后续操作,否则,libxslt将返回一个可被javascript接收的error信息。攻击者通过接受的error信息,就可判定输入的地址是否有指定的字符串,再结合大量的数据填充,就可以打到地址泄漏的目的。(详见“三、利用方式”)
Hacking Team安卓浏览器攻击过程中的漏洞分析Stage0(1)_攻击类型转换
3. 调试过程
调试过程在nexus 7+android4.3上进行。
由于在webkit解析xsl文件时,如果标签为
图7 程序在xmlParseEntityDecl停下时的状态
myDoc节点:0x400d9768最终程序崩溃时,调用栈中会显示是由于处理这个对象而导致崩溃。
Input:0x59988c18通过查看input信息,可知对xsl对象所解析到那个节点。
查看input信息:
图8 Input中的信息
图9 程序的解析状态
如图9显示,正在解析!ENTITY节点。(base表示所解析的字符串,cur表示当前解析到的位置。)
函数entityDecl会创建引发错误的ENTITY对象:
图10 xmlEntity节点的创建(此时节点的数据类型为xmlNode)
如图10中所示,新生成的next节点,为通过entityDecl函数所得到的entity节点(type=0×11,0×11表示为entity节点,为图2中XML_ENTITY_DECL的实际值)。此时此节点的compression字段(在xmlEntity中此字段为orig字段)为0。
函数xmlParseEntityValue会将节点中的字符串存储于orig字符串指针中。
图11 获取xmlEntity节点中的字符串信息
如图11所示,程序将从!ENTITY节点中解析出的字符串传给了orig。(input中的cur(当前值)已向后移动,而之前的部分存入了orig中)
之后,函数会将orig赋值给xmlEntity对象的orig。
图12 将字符串存入xmlEntity的orig字段中
函数通过cur对目标xmlEntity节点的orig字段进行赋值。
图13 将之前出问题的节点转换为xmlEntity类型
如图13所示,被赋值的cur正是之前创建的xmlEntity节点。
而当程序运行到cur->orig=orig时,目标位置指针被重置:
图14 字符串的传入
如图14所示,此时的compission字段被置为orig指针,存储着可控的对象。而当对此节点进行namespace比较时,节点会类型转换为xmlNode类型,而xmlEntity->orig字符串字段则会被当成xmlNs类型来解释,最终达到任意地址比较的操作。
图15 程序崩溃时的状态
如图15所示,程序最终在字符串比较时发生段错误,此时的栈中xsltParseTemplateContext的第二个参数,正是为我们在xmlParseEntityDecl停下时,myDoc所指向的地址。
Hacking Team安卓浏览器攻击过程中的漏洞分析Stage0(1)_攻击类型转换
三、利用方式
1.向内存中填充330页的写有namespace信息的页。通过大量的数据填充,在触发漏洞时就有更大的可能匹配成功,只有匹配成功,才能进一步的地址泄漏。如果触发漏洞时的addr值指向未被分配的页,则会出现段错误导致程序崩溃。
图16 内存填充
图17 填充namespace信息
2.通过漏洞,可以在xsl对象生成时,修改href指针的值(详见图6),将地址改为一个在填充过程中,有很大几率会被填充到的地址。
图18 漏洞利用代码1
图19 漏洞利用代码2
3.函数内部会自动对xsl对象的namespace指针进行匹配,以确定xsl对象是否为一个合法的xsl元素。如果为非法元素,则会被javascript捕获到异常。
图20 javascript可获取的异常状态
4.若进入if,则字符串匹配成功,之后进入二分法查找具体页的过程,addr为触发漏洞时所写入的地址。若进入else,将猜测的地址addr进行变化,再次进行比较过程(此函数名即为find_spray_addr进入else后,则会迭代查找地址)。
5.二分法查找:
a.将填充的330页数据的前一半(165页)数据进行清空。
b.再次调用漏洞,判断是否发生异常,若异常,则addr所指向的地址在前一半填充的页中。否则,addr所指向的地址在后一半填充的页中。
c.继续对前一半或后一半进行a、b两步,直到仅剩一页时,则可判定addr指向的是此页中的地址。
图21 二分法查找addr所在页的代码1
图22 二分法查找addr所在页的代码2
6.通过获取页信息,即可得到一个泄露的内存地址addr以及周围4mb的可控内存,达到本阶段的漏洞利用目的。
三 : 哪款安卓手机浏览器最安全? 安卓手机存寄生兽漏洞
随着智能手机普及,用户在手机的操作越多来越多,上网、看视频、看小说,网购等……移动互联网在快速普及的同时,手机安全也成为大众最为关注问题。近日作为用户使用最频繁的应用之一,目前市面主流的手机浏览器哪款更安全?空口无凭,我们来对国内市场份额前三名的手机浏览器(UC手机浏览器(下载)、QQ手机浏览器(下载)、百度手机浏览器(下载))来一个综合测试大比拼。
测试项目一:寄生兽漏洞安全
最近安卓系统出现一个安全漏洞,影响市面上数以千万的安卓手机。利用该漏洞,攻击者可以通过解压缩zip文件进行文件替换,在直接在用户手机中植入木马,盗取用户的短信照片等个人隐私,盗取银行等账号密码等,该漏洞被命名为寄生兽。针对此漏洞,文章对UC浏览器、QQ浏览器和百度浏览器进行漏洞安全评测。
UC浏览器:在使用UC浏览器下载不安全的zip文件时,UC浏览器会进行检测,给出不安全提示,并停止解压,防止“寄生兽”漏洞被利用攻击。UC浏览器在此轮评测中表现安全。
QQ浏览器:当QQ浏览器下载并解压一个zip文件时,没有对zip文件中的文件名做安全性校验,zip文件可以被精心构造成可替换财付通支付SDK的文件名,截获用户财付通、微信等支付账号的账号与密码。在模拟攻击测试中,通过QQ浏览器购买某本在线小说,通过该漏洞能够在支付页面注入代码。QQ浏览器在此轮评测中危险系数极高。
百度浏览器:手机百度浏览器在下载并解压zip文件时遇到包含 “../../../”的文件名时会将非法的../去除掉,防止寄生兽漏洞被利用攻击,不会引起安全问题。手机百度浏览器在此轮评测中表现安全。
小结:在寄生兽的漏洞评测中,UC浏览器和百度浏览器在下载前均会对zip文件进行签名检测,能够防止寄生兽漏洞被利用和由此引发的攻击。QQ浏览器则没有对zip文件进行安全性校验,很容易被截获用户财付通、微信等支付账号的账号与密码。在本轮寄生兽漏洞测试中,QQ浏览器还需要尽快修复漏洞。
测试项目二:下载应用安全扫描
在上一轮评测中主要针对签名进行检测,如果没有对zip文件下载及解压进行签名检测,有可能导致寄生兽等漏洞被利用和攻击。除了zip文件外,应用安全下载也是手机浏览器非常关注的问题。接下来第二轮将对下载应用的安全性检测进行评测。
UC浏览器:在应用下载前, UC浏览器会对下载的应用进行安全性检测,并在下载框和下载管理中标注“安全”标签,其中绿色代表安全,如果存在安全隐患会直接用红色予以警示。
QQ浏览器:在下载测试中,QQ手机浏览器会提示该文件的是否安全,并且可以列出下载文件的检测详情,在文件下载安全性检测中的表现不错。不过QQ浏览器只是对应用进行安全监测,但没有对zip文件进行检测。
百度浏览器:和UC浏览器一样,百度手机浏览器同样在下载框和下载管理界面中标注安全性的检测,安全性也表现不错。
小结:在此轮评测中,三款手机浏览器都具有对下载文件安全性的检测功能,对用户来说绝对是好消息,本轮测试三者表现旗鼓相当。
对比结果:
通过对国内三款主流手机浏览器安全方面的对比,在日常应用下载安全监测上,三款主流手机浏览器表现接近。而在手机漏洞管理上,UC浏览器和手机百度浏览器比较安全,QQ浏览器还需尽快修复,以免更多用户被黑客攻击,造成用户信息以及经济损失。
本文标题:搜狗浏览器安全漏洞-安全专家称微信漏洞危害性远高于360手机浏览器漏洞61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1