RSS Feed
更好更安全的互联网
  • 如何打造自己的PoC框架-Pocsuite3-使用篇

    2019-04-25

    作者:w7ay@知道创宇404实验室
    Engilish version: https://paper.seebug.org/905/

    相比于无聊的用法介绍,我更想说一下Pocsuite3为什么会有这些功能以及是如何实现的。如果你也想制造一款类似的工具,Pocsuite3的一些思想或许能够帮助到你。本文同时也是记录Pocsuite3开发过程中的一些思考与理解。

    简介

    Pocsuite 是由知道创宇404实验室打造的一款开源的远程漏洞测试框架。它是知道创宇安全研究团队发展的基石,是团队发展至今一直维护的一个项目,保障了我们的 Web 安全研究能力的领先。

    你可以直接使用 Pocsuite 进行漏洞的验证与利用;你也可以基于 Pocsuite 进行 PoC/Exp 的开发,因为它也是一个 PoC 开发框架;同时,你还可以在你的漏洞测试工具里直接集成 Pocsuite,它也提供标准的调用类。

    Pocsuite3是完全由Python3编写,支持Windows/Linux/Mac OSX等系统,在原Pocsuite的基础上进行了整体的重写与升级,使整个框架更具有操作性和灵活性。

    巨人的肩膀

    Pocsuite3在编写时参考了很多市面上的开源框架以及流行成熟的框架,在代码工程结构上参考了Sqlmap,Pocsuite-console模式则参照了routersploit与metasploit,所以PoC的代码格式和以前有些差别(但是尽量克制了大的改动)。Pocsuite3也提供了非常简单的接口调用,可以集成到其他安全工具内部。

    下载

    Pip 安装

    安装有两种,pip和直接运行源码。

    将使用Pocsuite3最新版。

    执行

    检验安装效果。

    源码安装

    如果你自信能折腾的话,可以下载源码使用,这也是我们推荐的方式,因为pip的更新可能会慢于github,

    同时需要安装两个依赖

    如果同时也是Windows系统,除了上面的依赖还需要安装一个

    最后

    检验安装效果。

    另外需要注意的是,两种安装方式只可以取其一,不可同时安装。建议使用源码安装的方式。

    一般使用帮助

    大多数情况,-h可以帮助你了解Pocsuite支持的功能。

    一个简单的测试

    将使用ZoomEye搜索ecshop并使用ecshop_rce.py探测,指定线程数量为5

    Pocsuite的运行模式默认是verify验证模式,此时对目标影响最小,也有attackshell模式,对目标进行相关攻击与shell反弹(当然需要PoC的支持,Pocsuite的PoC编写格式预留了这三种模式的接口,并且有很多内置API帮助实现这三种接口)

    Shell模式

    Pocsuite3新增加了shell模式的设定,当你选择了此函数,Pocsuite3将会监听一个端口,并等待目标的反连。我们提供了各种语言用于反连的payload,以及用于生成在Windows/Linux平台下可执行的shellcode。

    从配置文件运行

    有时候命令行命令太多,有些参数的重用性比较高,Pocsuite也提供了从配置文件中运行的方法。

    我们以redis未授权访问漏洞为例,我们修改这个文件pocsuite.ini

    线程也调整一下,RUN!

    由于开启了comparsion参数,我们可以看到更多的信息

    1

    如果你同时还是Zoomeye VIP,搜集目标的同时也能够识别出蜜罐信息。目前只有通过Zoomeye接口获取的数据才能有蜜罐的标识。Shodan、Censys暂未开放相关API接口。

    插件系统

    Pocsuite支持了插件系统,按照加载目标(targets),加载PoC(pocs),结果处理(results)分为三种类型插件。

    Targets插件

    除了本身可以使用-u-f加载本地的目标之外,你可以编写一个targets类型插件从任何你想加载的地方加载目标(eg:Zoomeye、Shodan)甚至从网页上,redis,都可以。Pocsuite3内置了四种目标加载插件。

    从上文可以看出,如果使用了搜索dork—dork—dork_zoomeye—dork_shodan—dork_censys,相关插件将自动加载,无需手动指定。

    Pocs插件

    原来只能通过从seebug中调用插件,现在将这种方式抽离出来作为插件,将允许从任何能够访问的地方调用,甚至写一个插件在github上维护一个仓库调用都行。

    Demo:

    https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/plugins/poc_from_redis.py

    https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/plugins/poc_from_seebug.py

    Results-plugin

    Results插件允许对扫描的结果进行处理,可以参考内置的两个插件,保存结果为html与保存结果为txt。Results插件的结果是实时的,具体可以看plugins/file_record.py的实现方式。

    https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/plugins/html_report.py

    https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/plugins/file_record.py

    调用插件

    通过--plugins在后面指定插件名称,多个插件可以用,分割。例如--plugins html_report将会生成HTML报表格式文档。

    内置API

    基于我们漏洞应急的积累,基本上Pocsuite内置的API接口可以做到PoC编写的全覆盖了。很多API接口我们下一章再说,这里说两个比较有趣的案例。

    Shellcode生成支持

    在一些特殊的Linux和Windows环境下,想得到反弹shell条件比较困难。为此我们制作了用于在Windows/Linux x86 x64环境下的用于反弹的shellcode,并制作了接口支持,你在只需要拥有命令执行权限下便可以自动将shellcode写入到目标机器以及执行反弹shell命令。Demo Poc:https://github.com/knownsec/pocsuite3/blob/master/pocsuite3/pocs/thinkphp_rce2.py

    HTTP服务内置

    如果你们还对Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE! 有印象。多么完美的漏洞,但是在编写PoC的时候我们遇到了困难,verify模式我们可以轻松用Ceye来识别,但是attack模式与shell模式我们就必须要制作自己的Jar并将它上传到服务器上面!

    为此我们制作Jar格式打包的API以及HTTP服务API,在后面的众多越来越难以自动化的PoC编写中,会发现它是如此好用。

    附 Jenkins Abusing Meta Programming for Unauthenticated RCE(CVE-2019-1003000) with Pocsuite3 演示视频。

    https://www.youtube.com/watch?v=5P7WWlqYt4U

    自定义参数传递

    随着编程人员的安全意识逐渐提高,会发现以前一条链接就可以获取RCE的时代已经过去了。越来越多的漏洞转向需要一定"权限"才能触发。为此,我们需要在Pocsuite3预留参数接口。

    在尽量保持原有PoC格式的前提下,我们增加了一个_options方法,用于指定用户传递的参数。DemoPoc: https://github.com/knownsec/pocsuite3/blob/master/tests/login_demo.py

    我们定义了在Poc中需要传递usernamepassword两个参数,为了使用的方便,可以直接在命令行模式下如下

    是的,就是这么简单。可能你会问如果PoC中定义的参数与Pocsuite自带的参数名冲突了如何解决?我们的解决办法是不允许定义冲突的参数名,Pocsuite在启动时就会检查,如果有冲突的参数名会提示你修改PoC中的自定义参数名称。

    Console模式

    在某些情况下,我们也考虑到了可交互的命令模式(黑客的仪式感)。并且它完全能兼容命令行模式下的PoC,如果你在Linux或Mac下使用它,将得到更好的体验。

    一些Tips:

    • 在此模式下多用help可以明白更多
    • 加载PoC插件时,可以直接use + 数字,更简单方便,当然输入完整路径也可以,按下Tab会自动补全。
    • 有一些命令别名没有在help中显示,作为彩蛋等待使用者发现~image-20190424141427790

    API 通用集成

    我们鼓励也支持将Pocsuite3作为安全产品中的一部分。只需要将Pocsuite3作为模块导入到你的项目中就能轻松使用。后面我们也会详细说明Pocsuite3是如何做到这一点的。

    pocsuite3.api将Pocsuite中所有接口暴露出来,不管是写PoC还是集成到自己的环境,只需要使用这就可以。一个简单调用Demo。

     

    最后

    一个功能完备的框架并不只是一个可以批量处理任务的引擎,很多东西需要在实战中积累并以最好的方式实现出来(俗称踩坑)。在打造自己的PoC框架过程中,一定要清楚自己需要的是什么,以及用何种方式将它优雅的解决?下篇将具体谈谈Pocsuite3中的框架结构。


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/904/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • 【ZoomEye专题报告】DDoS 反射放大攻击全球探测分析

    2019-04-24

    作者:知道创宇404实验室
    ZoomEye专题:https://www.zoomeye.org/topic?id=Global-Detection-and-Analysis-of-Amplified-Reflection-DDoS-Attacks
    PDF 版本:下载
    English Version: https://paper.seebug.org/899/

    1.更新情况

    版本 时间 描述
    第一版 2017/08/07 完成第一轮数据统计,输出报告,完善文档格式
    第二版 2017/08/14 完成第二轮数据统计,输出报告,完善文档格式
    第三版 2017/11/15 完成第三轮数据统计,在第二轮的基础上增加对cldap的探测
    第四版 2018/03/05 完成第四轮数据统计,在第三轮的基础上增加对Memcached的探测

    2.概述

    DDos攻击是一种耗尽资源的网络攻击方式,攻击者通过大流量攻击,有针对性的漏洞攻击等耗尽目标主机的资源来达到拒绝服务的目的。

    反射放大攻击是一种具有巨大攻击力的DDoS攻击方式。攻击者只需要付出少量的代价,即可对需要攻击的目标产生巨大的流量,对网络带宽资源(网络层)、连接资源(传输层)和计算机资源(应用层)造成巨大的压力,2016年10月美国Dyn公司的DNS服务器遭受DDoS攻击,导致美国大范围断网。事后的攻击流量分析显示,DNS反射放大攻击与SYN洪水攻击是作为本次造成美国断网的拒绝服务攻击的主力。由于反射放大攻击危害大,成本低,溯源难,被黑色产业从业者所喜爱。

    在2017年8月3日到2017年8月6日期间ZoomEye网络空间探测引擎对全网进行第一轮的探测,统计可被利用进行DDoS反射放大攻击的主机数,发布了《DDoS反射放大攻击全球探测分析-第一版》,之后在2017年8月11日到2017年8月13日期间ZoomEye网络空间探测引擎再次对全网进行了探测,发布了《DDoS反射放大攻击全球探测分析-第二版》。之后在2017年11月13日到2017年11月15日期间,ZoomEye网络空间探测引擎探测到了另一个活动频繁的攻击——CLDAP DDoS反射放大攻击,随后对DDoS反射放大攻击进行了第三轮的探测,发布了《DDoS反射放大攻击全球探测分析-第三版》。

    随后在2018年3月1日,ZoomEye又探测到在网络空间中频繁活动Memcached DRDoS, 进行第四轮对DDoS反射放大攻击的探测。

    3.第四轮放大攻击数据分析

    [注:下面数据统计均基于第四轮 2018/03/05]

    第四轮探测,ZoomEye网络空间探测引擎在对前面两轮6种DDoS攻击的探测的基础上,增加了对Memcached攻击的探测。

    3.1.CHARGEN

    通过ZoomEye网络空间探测引擎获取到9万(95,010)台主机开放了19端口。然后对这9万主机进行放大倍率的探测,实际上只有1万(10,122)台主机开启了19点端口,占总数的10.65%。在开启了19端口的主机中,有6千(6,485)台主机的放大倍数能够达到10倍以上,占总数的64.07%,剩下的主机的放大倍数主要集中在2倍。相关数据如图3.1-1所示:

    对放大倍数达到10以上的主机流量进行统计,我们总共发送了870KB(891,693 byte)的请求流量,得到了71M(74,497,401 byte)响应流量,产生了83倍的放大流量。假设一台主机1分钟内可以成功响应100个请求数据包,计算得到攻击流量有947Mbits/s。本轮探测对最大放大倍数进行了统计,得到了Chargen协议单次请求响应最高能放大319倍流量。

    上面的数据和之前两次的的数据进行比较,Chargen DDoS攻击的危害并没有减小,反而有增大的趋势。

    根据ZoomEye网络空间探测引擎的探测结果,对可利用的Chargen主机进行全球分布统计,见图3.1-2:

    3.1-2 Chargen协议19端口可利用主机全球分布图从图中可以看出仍然是韩国具有最多数量的可被利用进行DDos反射放大攻击的主机,我国排在第二 。下面,对我国各省份的情况进行统计,如图3.1-3所示:

    3-1.3 Chargen协议19端口可利用主机全国分布图

    3.2.NTP

    通过ZoomEye网络空间探测引擎获取到14万(147,526)台开启了UDP 123端口的主机。利用这些数据进行放大倍率探测,实际上只有1千(1,723)台主机开启了UDP 123端口,占总数的1.17%,放大倍数大于10的主机只有4台,占有响应主机总数的0.23%,具体数量见图3.2-1所示:

    和上一次探测的结果相比,利用NTP进行反射DDoS攻击的隐患基本消除,不管是NTP服务器的总量还是可被利用服务器数量,都大幅度下降,尤其是本次探测中,只发现4台可被利用的NTP服务器,而且这4台皆位于日本。我国未被探测到可被利用的NTP服务器。

    3.3.DNS

    通过Zoomeye网络空间探测引擎获取到2千万(21,261,177)台UDP 53端口相关的主机,对这些主机进行放大倍率探测,实际上只有384万(3,847,687)台主机开启了53端口,占了扫描总数的18.1%。在开启了53端口的主机中,有3万(31,999)台主机放大倍数在10倍以上,只占总数的0.83%,而放大倍数为1的主机有277万(2,776,027)台,具体数据见图3.3-1:

    和上一版的数据相比,互联网上DNS服务器的和可被利用的DNS服务器数量均处于下降状态。

    下面,再来看看这3万台放大倍数大于10的主机全球分布情况,如图3.3-2所示,可以看到,和上一轮相比,数量排名没啥变化,仍然是美国排在第一位。我们又对可利用主机在我国的分布情况进行了统计,如图3.3-3所示,和上一轮相比,湖北省的DNS服务器数量有了明显的提高。

    3.3-2 DNS协议53端口可利用主机全球分布图

    3.3-3 DNS协议53端口可利用主机全国分布图

    3.4.SNMP

    通过Zoomeye网络空间探测引擎获取到1千万(11,681,422)台UDP 161端口相关的主机,对这些主机进行放大倍率探测,实际上有167万(1,677,616)台主机开启了161端口,占了扫描总数的14.36%。在开启了161端口的主机中,有61万(617,980)台主机放大倍数在10倍以上,占了总数的36.84%,具体数据见图3.4-1:

    本次探测得到的数据和前一轮的数据相比较,探测到的SNMP主机数增加,而可利用的主机数却呈下降状态。

    下面,再来看看这61万台放大倍数大于10的主机全球分布情况,如图3.4-2所示,可以看到,我国的主机量上升到了第二位。我们又对可利用主机在我国的分布情况进行了统计,如图3.4-3所示,台湾,北京,黑龙江仍然是受影响最深的几个省份之一。

    3.4-2 SNMP协议161端口可利用主机全球分布图

    3.4-3 SNMP协议161端口可利用主机全国分布图

    3.5.SSDP

    通过Zoomeye网络空间探测引擎获取到3千万(32,522,480)台UDP 1900端口相关的主机,对这些主机进行放大倍率探测,实际上有60万(609,014)台主机开启了1900端口,占了扫描总数的1.87%。在开启了1900端口的主机中,有57万(572,936)台主机放大倍数在10倍以上,占了总数的94.08%,具体数据见图3.5-1:

    下面,再来看看这57万台放大倍数大于10的主机全球分布情况,如图3.5-2所示,和上一轮探测的数据相比,没有明显的变化。 再对我国的数据进行统计,如图3.5-3所示,台湾仍是我国可被利用的主机数最多的省份,远远超过我国的其他省份。

    3.5-2 SSDP协议1900端口可利用主机全球分布图

    3.5-3 SSDP协议1900端口可利用主机全国分布图

    3.6.CLDAP

    通过Zoomeye网络空间探测引擎获取到40万(403,855)台UDP 389端口相关的主机,对这些主机进行放大倍率探测,实际上有1万(17,725)台主机开启了389端口,占了扫描总数的4.39%。在开启了389端口的主机中,有1万(17,645)台主机放大倍数在10倍以上,占了总数的99.55%,具体数据见图3.6-1:

    下面,再来看看这2万台放大倍数大于10的主机全球分布情况,如图3.5-2所示,可以看到,美国仍然是可被利用的CLDAP服务器数量最多的国家,我国依旧排第三位。我们又对可利用主机在我国的分布情况进行了统计,如图3.5-3所示,台湾依然是我国可被利用的主机数最多的省份,和香港一起远远超过我国的其他省份地区。

    3.6-2 LDAP协议389端口可利用主机全球分布图

    3.6-3 LDAP协议389端口可利用主机全国分布图

    3.7.Memcached

    Memcached是一个自由开源的,高性能,分布式内存对象缓存系统。Memcached是以LiveJournal旗下Danga Interactive公司的Brad Fitzpatric为首开发的一款软件。现在已成为mixi、hatena、Facebook、Vox、LiveJournal等众多服务中提高Web应用扩展性的重要因素。Memcached是一种基于内存的key-value存储,用来存储小块的任意数据(字符串、对象)。这些数据可以是数据库调用、API调用或者是页面渲染的结果。Memcached简洁而强大。它的简洁设计便于快速开发,减轻开发难度,解决了大数据量缓存的很多问题。它的API兼容大部分流行的开发语言。本质上,它是一个简洁的key-value存储系统。一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、提高可扩展性。

    Memcached Server在默认情况下同时开启了TCP/UDP 11211端口,并且无需认证既可使用Memcached的储存服务。2018年3月2日,ZoomEye对全网开启了UDP 11211端口,并且无需认证的Memcached进行探测,共得到14142个目标,并对这些目标进行全球分布统计,如图3.7-1所示:

    3.7-1 Memcached可被利用主机全球分布图从上图中可以明显的看出我国对安全问题的重视程度和国外仍然有较大的差距。在14142个有效目标中,有11368个目标的IP地址位于我国。下面再对我国的目标进行全国分布统计,如图3.7-2所示:

    3.7-2 Memcached可被利用主机全国分布图Memcached未开启认证的情况下,任何人都可以访问Memcached服务器,储存键值对,然后可以通过key来获取value。所以,为了摸清出全球Memcache可利用的情况,我们在Memcached储存一个key为1byte的,value为1kb的数据,然后我们再通过该key获取到value,这样就产生了将近1000倍的放大效果。Memcached在默认情况下还会开启UDP端口,所以这就导致了Memcached可以被利用来进行DDoS放射放大攻击。而Memcached能放大多少倍取决于:

    1. Memcached服务器带宽
    2. Memcached能储存的值的最大长度

    利用自己的服务器进行一个测试,首先让能利用的Memcached储存一个1kb长度的值,然后同时向所有目标获取值,能收到886Mbit/s的流量,如图3.7-3所示:

    3.7-3 流量统计图

    4.总结

    和前面三轮探测的数据相比,在第四轮的探测中,变化最大的是NTP服务,当前互联网的NTP服务器已经没办法造成大流量的DDoS反射放大攻击了。与之相比,其他协议也或多或少的降低了可被利用的主机数量 。DDoS反射放大攻击仍然危害巨大,DDoS防御仍然刻不容缓。 从这次ZoomEye探测到的数据中,再和公网上的Memcached服务进行对比:

    4-4 ZoomEye探测11211端口数量在ZoomEye的数据库中,开启11211端口的目标有54万,其中美国有23万,中国有13万的目标,但是开启了UDP 11211端口的数据中,总量只有14142,其中美国有1070的目标,中国有11368个目标主机。

    从这些数据对比中,可以看出美国对此类的安全事件有非常快的响应速度,中国和美国的差距还很大。

    从放大效果来看,虽然可利用的目标已经缩减到1万的量级,但是仍然能造成大流量的DDos攻击。

    对于Memcached的用户,我们建议关闭其UDP端口,并且启用SASL 认证,对于运营商,建议在路由器上增加的uRPF(Unicast Reverse Path Forwarding)机制,该机制是一种单播反向路由查找技术,用于防止基于源地址欺骗的网络攻击行为,利用该机制能使得UDP反射攻击失效。

    5.参考链接

    1.Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS.
    https://blog.cloudflare.com/ssdp-100gbps/
    2.基于SNMP的反射攻击的理论及其实现.
    http://drops.xmd5.com/static/drops/tips-2106.html
    3.基于Memcached分布式系统DRDoS拒绝服务攻击技术研究.
    https://paper.seebug.org/535/
    4.ZoomEye Chargen dork.
    https://www.zoomeye.org/searchResult?q=port%3A19
    5.ZoomEye NTP dork.
    https://www.zoomeye.org/searchResult?q=port%3A123
    6.ZoomEye DNS dork.
    https://www.zoomeye.org/searchResult?q=port%3A53
    7.ZoomEye SNMP dork.
    https://www.zoomeye.org/searchResult?q=port%3A161
    8.ZoomEye LDAP dork.
    https://www.zoomeye.org/searchResult?q=port%3A389
    9.ZoomEye SSDP dork.
    https://www.zoomeye.org/searchResult?q=port%3A1900
    10.ZoomEye Memcached dork.
    https://www.zoomeye.org/searchResult?q=port%3A11211

     

    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/898/

    作者:吴烦恼 | Categories:安全研究 | Tags:
  • Drupal 1-click to RCE 分析

    2019-04-22

    作者:LoRexxar'@知道创宇404实验室
    时间:2019年4月19日

    2019年4月11日,zdi博客公开了一篇A SERIES OF UNFORTUNATE IMAGES: DRUPAL 1-CLICK TO RCE EXPLOIT CHAIN DETAILED.

    整个漏洞的各个部分没什么特别的,巧妙的是,攻击者使用了3个漏洞+几个小trick,把所有的漏洞链接起来却成了一个还不错的利用链,现在我们就来一起看看整个漏洞.

    无后缀文件写入

    在Drupal的机制中,设定了这样一条规则。

    用户上传的图片文件名将会被保留,如果出现文件名相同的情况,那么文件名后面就会被跟上_0,_1依次递增。

    在Drupal中为了兼容各种编码,在处理上传文件名时,Drupal会对文件名对相应的处理,如果出现值小于0x20的字符,那么就会将其转化为_

    但如果文件名中,如果出现了\x80\xff的字符时,PHP就会抛出PREG_BAD_UTF8_ERROR,如果发生错误,那么preg_replace就会返回NULL,$basename就会被置为NULL。

    当basename为空时,后面的文件内容会被写入到形似_0的文件内

    在这个基础下,原本会被上传到

    则会被写入

    当服务端开启了评论头像上传,或者是拥有作者账号时

    攻击者可以通过上传一张恶意构造的gif图,然后再上传一张带有恶意字符的同一张图,那么就会将恶意图片的内容写入到相应目录的_0

    但如果我们直接访问这个文件时,该文件可能不会解析,这是因为

    1. 浏览器首先会根据服务端给出的content-type解析页面,而服务端一般不会给空后缀的文件设置content-type,或者设置为application/octet-stream
    2. 其次浏览器会根据文件内容做简单的判断,如果文件的开头为<html>,则部分浏览器会将其解析为html
    3. 部分浏览器还可能会设置默认的content-type,但大部分浏览器会选择不解析该文件。

    这时候我们就需要一个很特殊的小trick了,a标签可以设置打开文件的type(only not for chrome)

    当你访问该页面时,页面会被解析为html并执行相应的代码。

     

     

    当被攻击者访问该页面时,我们就可以执行任意的xss,这为后续的利用带来了很大的便利,我们有了一个同源环境下的任意js执行点,让我们继续看。

    phar反序列化RCE

    2018年BlackHat大会上的Sam Thomas分享的File Operation Induced Unserialization via the “phar://” Stream Wrapper议题,原文https://i.blackhat.com/us-18/Thu-August-9/us-18-Thomas-Its-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-Know-It-wp.pdf 

    在该议题中提到,在PHP中存在一个叫做Stream API,通过注册拓展可以注册相应的伪协议,而phar这个拓展就注册了phar://这个stream wrapper。

    在我们知道创宇404实验室安全研究员seaii曾经的研究(https://paper.seebug.org/680/)中表示,所有的文件函数都支持stream wrapper。

    也就是说,如果我们找到可控的文件操作函数,其参数可控为phar文件,那么我们就可以通过反序列化执行js。

    在Drupal中,存在file system功能,其中就有一个功能,会把传入的地址做一次is_dir的判断,这里就存在这个问题

    直接使用下面的payload生成文件

     

     

    修改后缀为png之后,传图片到服务端,并在file system中设置

    即可触发

    漏洞要求

    这个漏洞在Drual8.6.6的更新中被修复,所以漏洞要求为

    • <= Durpal 8.6.6
    • 服务端开启评论配图或者攻击者拥有author以上权限的账号
    • 被攻击者需要访问攻击者的url

    当上面三点同时成立时,这个攻击链就可以被成立

    漏洞补丁

    无后缀文件写入 SA-CORE-2019-004

    https://www.drupal.org/SA-CORE-2019-004

    如果出现该错误直接抛出,不继续写入

    https://github.com/drupal/drupal/commit/82307e02cf974d48335e723c93dfe343894e1a61#diff-5c54acb01b2253384cfbebdc696a60e7

    phar反序列化 SA-CORE-2019-002

    https://www.drupal.org/SA-CORE-2019-002

    写在最后

    回顾整个漏洞,不难发现其实整个漏洞都是由很多个不起眼的小漏洞构成的,Drupal的反序列化POP链已经被公开许久,phar漏洞也已经爆出一年,在2019年初,Drupal也更新修复了这个点,而preg_replace报错会抛出错误我相信也不是特别的特性,把这三个漏洞配合上一个很特别的a标签设置content-type的trick,就成了一个很漂亮的漏洞链。


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/897/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • Apache 提权漏洞(CVE-2019-0211)复现

    2019-04-12

    作者:Hcamael@知道创宇404实验室
    时间:2019年4月12日

    本月Apache被公布了一个提权的漏洞,并且前天在GitHub上公布出了利用脚本,这几天我负责漏洞应急这个漏洞。

    本篇文章没有叫:《Apache 提权漏洞分析》是因为我觉得CARPE (DIEM): CVE-2019-0211 Apache Root Privilege Escalation这篇文章的分析写的挺好的,所以我没必要再翻译一遍了,本篇文章主要叙述复现该漏洞的过程中踩过的坑。

    复现环境

    我使用的复现环境是:

    1. apache使用apt安装的版本属于已经修复的版本,所以需要指定一下版本: # apt install apache2=2.4.29-1ubuntu4 apache2-bin=2.4.29-1ubuntu4 apache2-utils=2.4.29-1ubuntu4 apache2-data=2.4.29-1ubuntu4
    2. php直接用apt安装就好了
    3. exp地址: https://github.com/cfreal/exploits/blob/master/CVE-2019-0211-apache/cfreal-carpediem.php
    4. 需要开启ssl模块:a2enmod ssl

    关于需要开始ssl模块说明:

    1. 就算不开ssl模块,漏洞也是存在的
    2. 就算不开启ssl模块,你自己修改apache配置,能开启其他端口,也是能利用的
    3. 如果只开了80端口,则需要另行找一条利用链,github上公布exp在只开启了一个端口的情况下是无效的
    4. @cfreal的文章中已经说了,我这里在多说句,相关代码可以看看12还有SAFE_ACCPET的宏定义:

    简单的来说,只有在apache开启多个端口的情况下,才会生成mutex互斥锁,而在github上公布的exp就是通过apache的mutex对象来进行利用的。

    跑exp中遇到的一些坑

    我试过了很多版本,没有一个版本是能直接使用Github上的exp的,在上述表面的版本中,经过调试研究发现了两个问题导致了利用失败:

    1. $all_buckets = $i - 0x10 计算出问题
    2. $bucket_index = $bucket_index_middle - (int) ($total_nb_buckets / 2); 计算出问题

    第一个计算all_buckets的地址,使用gdb进行调试,你会发现,这个值并没有算错,但是在执行apache2ctl graceful命令以后,all_buckets 生成了一个新的值,不过只和之前的all_buckets地址差0x38000,所以这个问题很好解决:

    第二个计算没必要这么复杂,而且在我测试的版本中还是算的错误的地址,直接改成:

    ubuntu中的一个坑

    我的payload是:curl "http://localhost/cfreal-carpediem.php?cmd=id>/tmp/2323232"

    表面上看是执行成功了,但是却并没有在/tmp目录下发现2323232文件,经过随后的研究发现,systemd重定向了apache的tmp目录,执行下$find /tmp -name "2323232"就找到文件了,不过只有root用户能访问。如果不想让systemd重定向tmp目录也简单:

    这项为false就好了,PrivateTmp=false,改完以后重启一下,再测试一遍就能在tmp目录下写文件了

    关于成功率的说法

    在exp的注释中看到了说该利用没法100%成功,有失败的概率,所以我写了个脚本进行测试:

    我测试的跑了20次的结果:

    并没有遇到失败的情况

    总结

    其他版本的还没有进行测试,但是在这里给一些建议。

    1. check all_buckets地址

      这个挺简单的,执行完exp以后,有输出对应的pid和all_buckets地址,可以使用gdb attach上去检查下该地址是否正确:p all_buckets

      PS:这里要注意下,需要安装dbg包,才有all_buckets符号 :apt install apache2-dbg=2.4.29-1ubuntu4

      如果有问题,就调试检查exp中搜索all_buckets地址的流程

      如果没问题,就使用gdb attach主进程(root权限的那个进程),然后断点下在make_child,然后执行apache2ctl graceful,执行完然后在gdb的流程跳到make_child函数的时候,再输出一次:p all_buckets,和exp获取的值对比一下,如果一样就没问题了

    2. check my_bucket地址

      前面的流程和上面一样,重点关注在make_child函数中的my_bucket赋值的代码:3

      这里注意下,因为上面有一个fork,所以在gdb里还要加一句:set follow-fork-mode child

      my_bucket的值是一个指针,指向堆喷的地址,如果my_bucket的值没问题,exp基本就没问题了,如果不对,就调整$bucket_index

    更新

    debian 9测试成功:

    参考

    1. https://github.com/apache/httpd/blob/23167945c17d5764820fdefdcab69295745a15a1/server/mpm/prefork/prefork.c#L433
    2. https://github.com/apache/httpd/blob/23167945c17d5764820fdefdcab69295745a15a1/server/mpm/prefork/prefork.c#L1223
    3. https://github.com/apache/httpd/blob/23167945c17d5764820fdefdcab69295745a15a1/server/mpm/prefork/prefork.c#L691

    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/889/

    作者:吴烦恼 | Categories:安全研究 | Tags:
  • Confluence 未授权 RCE (CVE-2019-3396) 漏洞分析

    2019-04-09

    作者:Badcode@知道创宇404实验室
    时间:2019年4月8日

    看到官方发布了预警,于是开始了漏洞应急。漏洞描述中指出Confluence Server与Confluence Data Center中的Widget Connector存在服务端模板注入漏洞,攻击者能利用此漏洞能够实现目录穿越与远程代码执行。

    确认漏洞点是Widget Connector,下载最新版的比对补丁,发现在com\atlassian\confluence\extra\widgetconnector\WidgetMacro.java里面多了一个过滤,这个应该就是这个漏洞最关键的地方。

    可以看到

    TEMPLATE_PARAM的值就是_template,所以这个补丁就是过滤了外部传入的_template参数。

    翻了一下Widget Connector里面的文件,发现TEMPLATE_PARAM就是模板文件的路径。

    加载外部的链接时,会调用相对的模板去渲染,如上,模板的路径一般是写死的,但是也有例外,补丁的作用也说明有人突破了限制,调用了意料之外的模板,从而造成了模板注入。

    在了解了补丁和有了一些大概的猜测之后,开始尝试。

    首先先找到这个功能,翻了一下官方的文档,找到了这个功能,可以在文档中嵌入一些视频,文档之类的。

    看到这个,有点激动了,因为在翻补丁的过程中,发现了几个参数,urlwidthheight正好对应着这里,那_template是不是也从这里传递进去的?

    随便找个Youtube视频插入试试,点击预览,抓包。

    params中尝试插入_template参数,好吧,没啥反应。。

    开始debug模式,因为测试插入的是Youtube视频,所以调用的是com/atlassian/confluence/extra/widgetconnector/video/YoutubeRenderer.class

     

     

     

    getEmbeddedHtml下断点,先会调用getEmbedUrl对用户传入的url进行正则匹配,因为我们传入的是个正常的Youtube视频,所以这里是没有问题的,然后调用setDefaultParam函数对传入的其他参数进行处理。

    取出widthheight来判断是否为空,为空则设置默认值。关键的_template参数来了,如果外部传入的参数没有_template,则设置默认的Youtube模板。如果传入了,就使用传入的,也就是说,aaaa是成功的传进来了。

    大概翻了一下Widget Connector里面的Renderer,大部分是不能设置_template的,是直接写死了,也有一些例外,如Youtube,Viddler,DailyMotion等,是可以从外部传入_template的。

    能传递_template了,接下来看下是如何取模板和渲染模板的。

    跟进this.velocityRenderService.render,也就是com/atlassian/confluence/extra/widgetconnector/services/DefaultVelocityRenderService.class里面的render方法。

    _template取出来赋值给template,其他传递进来的参数取出来经过判断之后放入到contextMap,调用getRenderedTemplate函数,也就是调用VelocityUtils.getRenderedTemplate

    一路调用,调用链如下图,最后来到/com/atlassian/confluence/util/velocity/ConfigurableResourceManager.classloadResource函数,来获取模板。

    这里调用了4个ResourceLoader去取模板。

    这里主要看下Velocity自带的FileResourceLoaderClasspathResourceLoader

    FileResourceLoader会对用户传入的模板路径使用normalizePath函数进行校验

    可以看到,过滤了/../,这样就导致没有办法跳目录了。

    路径过滤后调用findTemplate查找模板,可看到,会拼接一个固定的path,这是Confluence的安装路径。

    也就是说现在可以利用FileResourceLoader来读取Confluence目录下面的文件了。

    尝试读取/WEB-INF/web.xml文件,可以看到,是成功的加载到了该文件。

    但是这个无法跳出Confluence的目录,因为不能用/../

    再来看下ClasspathResourceLoader

    跟进ClassUtils.getResourceAsStream

    会跳到/org/apache/catalina/loader/WebappClassLoaderBase.class

    跟进,发现会拼接/WEB-INF/classes,而且其中也是调用了normalize对传入的路径进行过滤。。

    这里还是可以用../跳一级目录。

    尝试读取一下../web.xml,可以看到,也是可以读取成功的,但是仍然无法跳出目录。

    我这里测试用的版本是6.14.1,而后尝试了file://,http://https://都没有成功。后来我尝试把Cookie删掉,发现还是可以读取文件,确认了这个漏洞不需要权限,但是跳不出目录。应急就在这里卡住了。

    而后的几天,有大佬说用file://协议可以跳出目录限制,我惊了,我确定当时是已经试过了,没有成功的。看了大佬的截图,发现用的是6.9.0的版本,我下载了,尝试了一下,发现真的可以。

    问题还是在ClasspathResourceLoader上面,步骤和之前的是一样的,断到/org/apache/catalina/loader/WebappClassLoaderBase.classgetResourceAsStream方法

    前面拼接/WEB-INF/classes获取失败后,继续往下进行。

    跟进findResource,函数前面仍然获取失败

    关键的地方就在这里,会调用super.findResource(name),这里返回了URL,也就是能获取到对象。

    不仅如此,这里还可以使用其他协议(https,ftp等)获取远程的对象,意味着可以加载远程的对象。

    获取到URL对象之后,继续回到之前的getResourceAsStream,可以看到,当返回的url不为null时,

    会调用url.openStream()获取数据。

    最终获取到数据给Velocity渲染。

    尝试一下

    至于6.14.1为啥不行,赶着应急,后续会跟,如果有新的发现,会同步上来,目前只看到ClassLoader不一样。

    6.14.1

    6.9.0

    这两个loader的关系如下

    现在可以加载本地和远程模板了,可以尝试进行RCE。

    关于Velocity的RCE,基本上payload都来源于15年blackhat的服务端模板注入的议题,但是在Confluence上用不了,因为在调用方法的时候会经过velocity-htmlsafe-1.5.1.jar,里面多了一些过滤和限制。但是仍然可以利用反射来执行命令。

    python -m pyftpdlib -p 2121开启一个简单的ftp服务器,将payload保存成rce.vm,保存在当前目录。

    _template设置成ftp://localhost:2121/rce.vm,发送,成功执行命令。

    对于命令回显,同样可以使用反射构造出payload,执行ipconfig的结果。

    漏洞影响

    根据 ZoomEye 网络空间搜索引擎对关键字 "X-Confluence" 进行搜索,共得到 61,856 条结果,主要分布美国、德国、中国等国家。

    全球分布(非漏洞影响范围)

    中国分布(非漏洞影响范围)

    漏洞检测

    2019年4月4日,404实验室公布了该漏洞的检测PoC,可以利用这个PoC检测Confluence是否受该漏洞影响。

    参考链接


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/884/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • 重现 TP-Link SR20 本地网络远程代码执行漏洞

    2019-04-03

    作者:xax007@知道创宇404 ScanV 安全服务团队

    简述

    3月26号 Google 安全开发人员 Matthew Garrett在 Twitter 上公布了 TP-Link Smart Home Router (SR20) 的远程代码执行漏洞,公布的原因是他去年 12 月份将相关漏洞报告提交给 TP-Link后没有收到任何回复,于是就公开了,该漏洞截至目前官方修复,在最新固件中漏洞仍然存在,属于 0day 漏洞,当我看到漏洞证明代码(POC)后决定尝试重现此漏洞

    img

    TP-Link SR20 是一款支持 Zigbee 和 Z-Wave 物联网协议可以用来当控制中枢 Hub 的触屏 Wi-Fi 路由器,此远程代码执行漏洞允许用户在设备上以 root 权限执行任意命令,该漏洞存在于 TP-Link 设备调试协议(TP-Link Device Debug Protocol 英文简称 TDDP) 中,TDDP 是 TP-Link 申请了专利的调试协议,基于 UDP 运行在 1040 端口

    TP-Link SR20 设备运行了 V1 版本的 TDDP 协议,V1 版本无需认证,只需往 SR20 设备的 UDP 1040 端口发送数据,且数据的第二字节为 0x31 时,SR20 设备会连接发送该请求设备的 TFTP 服务下载相应的文件并使用 LUA 解释器以 root 权限来执行,这就导致存在远程代码执行漏洞

    img

    漏洞环境搭建

    以下所有操作都在 Ubuntu LTS 18.04 系统下进行

    源码编译 QEMU

    Qemu 是纯软件实现的虚拟化模拟器,几乎可以模拟任何硬件设备,我们最熟悉的就是能够模拟一台能够独立运行操作系统的虚拟机

    APT 仓库有 QEMU,本可以使用 APT apt install qemu 直接安装,但 APT 仓库中的版本通常都不是最新的,担心会有未知的 bug,因此选择从 QEMU 官网下载最新稳定版源码来编译安装

    如果 configure 时没有指定 target-list参数,make 会编译针对所有平台的 QEMU 导致会耗很长很长的时间,因此可以选择只编译 ARM 版的 QEMU 来加快编译速度,至于选择 ARM 版是因为 TP-Link SR20 存在漏洞的固件基于是 ARM 架构,下文中会看到。

    编译完成后安装 checkinstall 来生成 deb 包

    如果不使用 checkinstall,直接sudo make install的会把 qemu 安装在多个位置,如果发生错误不方便删除,所以使用 checkinstall 生成 deb 包方便安装和卸载。

    安装完成后可以看到安装的版本

    img

    安装 Binwalk

    Binwalk 是一款文件的分析工具,旨在协助研究人员对文件进行分析,提取及逆向工程

    更详细的安装方法可以查看 Binwalk 的 GitHub wiki

    PS: 本人在最后一步运行deps.sh安装依赖的时 cramfstools 编译出错导致安装失败,如果你也遇到这个问题,不必理会,因为针对本文讲述的漏洞,这个包并不需要安装

    从固件提取文件系统

    从 TP-Link SR20 设备官网下载固件, 下载下来是一个 zip 压缩包,解压以后进入解压后目录,可以看到一个名字很长的叫 tpra_sr20v1_us-up-ver1-2-1-P522_20180518-rel77140_2018-05-21_08.42.04.bin 的文件,这个就是该 SR20 设备的 firmware (固件)

    使用 binwalk 查看该固件

    img

    使用 binwalk 把 Squashfs filesystem 从固件中提取出来,在固件 bin 文件所在目录执行

    binwalk 会在当前目录的 _+bin文件名 目录下生成提取出来的固件里的所有内容,进入到该目录

    img

    squashfs-root 目录就是我们需要的固件文件系统

    img

    在该文件系统目录下查找存在漏洞的 tddp 文件并查看文件类型可以看到该文件是一个 ARM 架构的小端(Small-Endian)32 位 ELF 文件

    img

    最高有效位 MSB(Most Significant Bit) 对应大端 (Big-endian)
    最低有效位 LSB(Least Significant Bit) 对应小端 (Little-endian)
    详细介绍可阅读:大端小端与MSB和LSB

    这时可以使用 QEMU 来运行该文件

    PS: 不加 -L . 参数运行 qemu-arm 会报错, -L . 参数会把当前目录加入到 PATH 路径中

    img

    经过测试发现通过这种方式运行 TDDP 程序并不能触发该漏洞,因此需要搭建完整的 ARM QEMU 虚拟机环境

    搭建 ARM QEMU 虚拟机环境

    ARM CPU 有两个矢量浮点(软浮点和硬浮点)具体区别可以查看 Stackoverflow,本次选择使用硬浮点 armhf

    从 Debian 官网下载 QEMU 需要的 Debian ARM 系统的三个文件:

    • debian_wheezy_armhf_standard.qcow2 2013-12-17 00:04 229M
    • initrd.img-3.2.0-4-vexpress 2013-12-17 01:57 2.2M
    • vmlinuz-3.2.0-4-vexpress 2013-09-20 18:33 1.9M

    把以上三个文件放在同一个目录执行以下命令

    img

    img

    虚拟机启动成功后会提示登陆

    用户名和密码都为 root

    img

    配置网卡IP

    img

    此时 QEMU 虚拟机可以与宿主机进行网络通信

    现在需要把从固件中提取出的文件系统打包后上传到 QEMU 虚拟机中

    压缩固件文件系统目录下的整个文件

    使用 Python 搭建简易 HTTP Server

    在 QEMU 虚拟机中下载上面打包好的文件

    img

    使用 chroot 切换根目录固件文件系统

    PS: 使用 chroot 后,系统读取的是新根下的目录和文件,也就是固件的目录和文件 chroot 默认不会切换 /dev 和 /proc, 因此切换根目录前需要现挂载这两个目录

    img

    如果你有树莓派,可以直接拿来用,几年前买过一个树莓派2B+,经过我的测试,安装了 Raspbian 的树莓派完全可以拿做做 ARM 的测试环境

    img

    img

    搭建 TFTP Server

    在宿主机安装 atftpd 搭建 TFTP 服务

    • 编辑 /etc/default/atftpd 文件,USE_INETD=true 改为 USE_INETD=false
    • 修改 /srv/tftp 为 /tftpboot

    最终 /etc/default/atftpd 文件内容如下:

    如果执行命令 sudo systemctl status atftpd 查看 atftpd 服务状态时

    提示 atftpd: can't bind port :69/udp 无法绑定端口

    可以执行 sudo systemctl stop inetutils-inetd.service 停用 inetutils-inetd 服务后

    再执行 sudo systemctl restart atftpd 重新启动 atftpd 即可正常运行 atftpd

    img

    此时环境已搭建完毕

    重现漏洞

    在 atftp 的根目录 /tftpboot 下写入 payload 文件

    payload 文件内容为:

    img

    重现步骤为:

    1. QEMU 虚拟机中启动 tddp 程序
    2. 宿主机使用 NC 监听端口
    3. 执行 POC,获取命令执行结果

    漏洞证明代码(Proof of concept):

    最终成功重现此漏洞

    img

    img

    参考链接 4 中说到 TP-Link 的 TL-WA5210g 无线路由器的 TDDP 服务只能通过有线网络访问,连 Wi-Fi 也不能访问,由于手上没有 SR20设备,因此断定该 SR20 设备的 TDDP 端口可能也是这种情况,我想这应该就是官方未修复此漏洞的原因吧

    参考链接 4 中详细介绍 TDDP 协议以及该协议 V1 和 V 2版本的区别等知识点

    最后感谢知道创宇404实验室 @fenix 大佬的指点

    参考链接

    1. Remote code execution as root from the local network on TP-Link SR20 routers
    2. How to set up QEMU 3.0 on Ubuntu 18.04
    3. Vivotek 摄像头远程栈溢出漏洞分析及利用
    4. 一个针对TP-Link调试协议(TDDP)漏洞挖掘的故事

     

    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/879/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • ZoomEye 网络空间测绘——委内瑞拉停电事件对其网络关键基础设施和重要信息系统影响

    2019-03-27

    作者:知道创宇404实验室
    时间:2019年3月21日
    ZoomEye 专题:https://www.zoomeye.org/topic?id=ZoomEye-series-report
    PDF报告:下载

    一.前言

    委内瑞拉,是一个位于南美洲北部的热带国家,也是南美洲最重要的产油国。根据《2012年度世界能源统计数据报告》,委内瑞拉已探明石油储量为2965亿桶,占全球18%,石油出口也成为了该国主要的经济支柱。

    由于该国政策、国际形势等多方面因素的影响,近些年该国石油产量逐年下滑,国内局势动荡。2019年3月7日晚,委内瑞拉发生了大面积停电事件,全国大范围陷入黑暗。

    本文将从网络空间测绘的视角对该国的网络建设情况和停电事件进行一定的分析判断。

    二.委内瑞拉网络建设情况

    截止2019年3月15日,ZoomEye 一共收录了委内瑞拉 1637553 个 IP 的 3067202 条 banner 信息。

    2.1 设备类型统计

    已识别的设备组件约占该国总设备组件的三分之二,其中 ZTE ZXV10 W300 路由器的web管理界面约占总设备组件数的十分之一。

    值得一提的是,一共识别出 306444 台 ZTE ZXV10 W300 路由器,299250 个 Dropbear sshd服务,即是 ZTE ZXV10 W300路由器又存在 Dropbear sshd服务的IP数量高达 244111 个。依次可以做出判断:该路由器可能被广泛用作家庭路由器。这也就意味着,一旦该路由器存在漏洞被攻击,可能会导致委内瑞拉大范围的家庭网络瘫痪。

    2.2 开放端口统计

    端口分布情况如下:

    根据 1.1 已知的结论,该国已经识别出的banner主要是ZTE ZXV10 W300 路由器。80、443、22、7547端口占比较高也和该路由器占比较高有关。

    值得注意的是,5357端口出现在第十位,其中有 62139 个 banner 被识别为 Microsoft-HTTPAPI/2.0。经过判断,这些 IP 都属于 Movilnet公司。根据其官网介绍, Movilnet 是委内瑞拉移动通信的领先公司,属于委内瑞拉的国营电话和互联网服务提供商 CANTV 的子公司。

    2.3 ISP归属统计

    根据 IP 所属ISP(互联网服务供应商)统计结果如下:

    委内瑞拉的国营电话和互联网服务提供商 CANTV 占据了绝对的优势,百分之85的IP都属于该公司。

    注: CANTV 是委内瑞拉的国营电话和互联网服务提供商,是委内瑞拉最大的电信提供商。1991年私有化后,2007年重新国有化。细观该 ISP 下的路由器,也大多是 ZTE ZXV10 W300。 还有少量其它品牌的路由器,例如: D-Link、 TP-Link 等。部分路由器可能存在漏洞(例如D-Link DIR系列,该系列路由器历史上存在大量安全漏洞。而在该ISP下,存在三个D-Link DIR系列路由器 )

    ISP 为 CANTV 下识别的组件分布排名第二的 Corporación Telemic C.A. 为委内瑞拉电视广播公司和电信提供商。相比于 CANTV 中存在的组件而言,该 ISP 下并未存在大量民用路由器,取而代之的是存在 11219 台被识别为 Microsoft HTTPAPI httpd 的组件。经过验证,这部分 IP 背后对应着真实的 Windows 系统。

    2.4 HTTPS证书统计

    ZoomEye网络空间搜索引擎一共识别出 252144 个 HTTPS 证书信息,去除路由器的证书、自签名证书 等证书信息后,一共提取出 645 个域名信息,其中域名类型如下:

    政府和教育类网站占据了总网站数量的四分之一,邮件类网站占比为 12%,其它类型网站仅占比 62%。从 HTTPS 证书的角度来看,该国互联网发展较为落后,政府/教育类网站仍然是该国互联网发展的主要力量。

    2.5 安全响应能力

    2017年永恒之蓝漏洞泄露后,能否快速修复相关漏洞也从侧面反映出安全响应能力。

    可以看到,委内瑞拉在 2017年4月24日,漏洞刚爆发时,仅仅只有3个主机被植入 Doublepulsar 后门。这也从侧面反映出该国并非网络战争的首要目标。但是在漏洞已经爆发了三个星期后,该国存在漏洞的主机数量仍然有 132 台,仅仅比最开始的 179 台减少了 47 台,这也从侧面反映出该国安全应急响应能力十分欠缺。

    2.6 石油销售渠道

    在对该国背景的了解中,可以知道:该国主要依赖于石油出口。但在对已有的 banner进行搜索之后,我们仅仅发现了一家石油生产相关的公司(http://200.*.*.*)和一个出口各类物品(包括石油)的公司(http://201.*.*.*)。

    从侧面也反映出该国石油出口有固定的经销渠道,印证了石油开采被国有企业把控的事实。

    2.7 工控端口分布情况

    根据 ZoomEye 网络空间搜索引擎的数据,委内瑞拉少量工控设备暴露在公网。已知的工控设备或工控协议有(近一年内活跃过的):

    工控设备/协议 数量
    Siemens S7 PLC Device 1
    Modbus 6
    BACnet 1
    Crimson V3 1
    OMRON FINS 1

    三.停电事件所造成的影响

    ZoomEye 网络空间搜索引擎对外探测是具有一定周期性和规律性的。

    根据前文我们已知委内瑞拉公网上的设备有很大比例的家用路由器。

    上图是ZoomEye每日录入位于委内瑞拉的banner数量,在3月初,有明显的数据变化。我们认为这和委内瑞拉的停电事件有较强的关联。

    三月具体的数据如下:

    可以看到,3月8日开始,ZoomEye 录入 banner数量骤减,在3月11日录入数量有所回升。3月13日录入数量恢复到正常水平。这和已知的委内瑞拉停电事件信息基本吻合(3月7日傍晚开始停电)。这也从另一个层面说明从2019年3月13日开始,委内瑞拉的供电已经正常。

    统计 3月9日至3月12日 ZoomEye 网络空间搜索引擎收录的 banner 数据,委内瑞拉全国大范围停电期间,这些地区仍然存在部分能够联网的设备:

    地区 停电期间收录数量
    Capital(委内瑞拉首都加拉加斯) 250
    Carabobo(委内瑞拉卡拉沃沃州) 66
    Mérida(委内瑞拉梅里达) 52
    未知地区 16
    Anzoátegui 14
    Miranda 13
    Aragua 9
    Zulia 8
    Táchira 6
    Lara 6
    Vargas 5
    Portuguesa 2
    Guárico 2
    Falcón 2
    Bolívar 1
    Barinas 1
    Amazonas 1

    可以看到,在全国大范围停电期间,委内瑞拉首都加拉加斯、首都附近的卡拉沃沃州(该州有自己的发电厂)以及西边的梅里达仍然能有电力供应。

    注: ZoomEye 网络空间搜索引擎使用 GeoIP 提供的 IP 数据库获取 IP 地址对应的地理信息。理论上,IP 地址可以精确到市级。

    统计断电期间识别出的组件,主要包括路由器、摄像头、Windows系统等。在前文中已知的民众常用的路由器类型 ZTE ZXV10 W300 则没有出现。可见在全国大范围停电期间,有限的电力仅仅被用于国家机器的正常运转。

    四.结语

    有关此次停电事件,在没有实际有力的证据曝光之前,并不能从网络空间测绘的角度证明停电是由于网络攻击所造成的。

    本文从ZoomEye网络空间搜索引擎的角度去探讨委内瑞拉的互联网发展情况和停电事件的恢复情况。主要的结论如下:

    1. 该国互联网建设较为落后。
    2. 该国停电事件在 2019年3月13日 (停电后第六天)基本恢复。
    3. 如果说停电事件背后存在网络攻击,该国暴露在公网上的众多 ZTE 路由器、Movilnet公司的相关主机都可能会成为下一步的被攻击目标。

    网络安全建设并非一蹴而就,委内瑞拉在这方面要走的路还很长。


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/869/

    作者:吴烦恼 | Categories:安全研究 | Tags:
  • 聊聊 WordPress 5.1.1 CSRF to RCE 漏洞

    2019-03-15

    作者:LoRexxar'@知道创宇404实验室
    时间:2019年3月14日

    2019年3月13日, RIPS团队公开了一篇关于WordPress 5.1.1的XSS漏洞详情,标题起的很响亮,叫做wordpress csrf to rce, https://blog.ripstech.com/2019/wordpress-csrf-to-rce/

    下面我们就来详细聊聊这个漏洞。

    关于WordPress防护

    早在2017年10月25号,我曾经写过一篇关于WordPress安全机制的文章。

    https://lorexxar.cn/2017/10/25/wordpress/

    在其中,我着重描述了WordPress整体安全机制中的最核心机制,nonce安全机制

    出于防御CSRF攻击的目的,WordOress引入了Nonce安全机制,Nonce是通过用户id、token、操作属性来计算的。简单来说就是,Nonce值受限于用户以及操作属性两点,不同用户同一个操作Nonce值不同,同一个用户不同操作Nonce值不同,同一个用户同一个操作不同站Nonce不同。

    虽然是出于防御CSRF攻击的目的诞生,但却在WordPress薄弱的后台安全防御下,打上了最强的一节防御外壳。

    在WordPress Core开发团队的认知中,任何一个WordPress的超级管理员,都应该保管好自己的网站以及账号安全,超级管理员也应该能对自己的网站以及服务器负责。

    在这样的观点设计下,WordPress的超级管理员可以直接修改后台插件模板来getshell,超级管理员的评论不会有任何过滤。

    所以在WordPress的防御体系下,如何绕过Nonce、如何获取超级管理员权限、如果在非超级管理员权限下做任何可以威胁网站安全操作,就是WordPress安全漏洞的主要方向。

    关于 CSRF to RCE 漏洞

    在我们熟悉了WordPress的安全机制之后,我们再回到这个漏洞来。

    作者提到,在WordPress的评论处有一个比较神奇的机制。刚才提到,对于WP的超级管理员来说,文章的评论不会有任何过滤,但仍旧有Nonce值_wp_unfiltered_html_comment,而WordPress其中有一些特殊的功能例如trackbacks and pingbacks会受到该值的影响,所以在评论处,Nonce不会直接阻止请求,而是另外生成了一套逻辑来做处理

    /wp-includes/comment.php line 3245

    继续跟下去,我们简单的把逻辑写成伪代码

    而其中的区别就是,wp_filter_post_kses不会做任何过滤,会保留请求的完整评论,而wp_filter_kses将只允许白名单的标签存在,就比如a标签等。

    而问题的核心就在于,如何在wp_filter_kses的白名单中找到一个可以导致xss的输入点。这个点就在a标签的rel属性处理中。

    在/wp-includes/formatting.php line 3025

    这里对整个标签全部做了一次处理,而没有额外的转义,再加上这里是通过拼接双引号符号来完成,那么如果我们构造一个评论为

    原链接中的属性会被取出,然后被双引号包裹,就成了

    恶意链接就构造成功了,当管理员鼠标放在这条评论上时,则可以执行任意JS。

    最后就是在执行任意JS之后,我们可以通过JS直接修改后台的模板,来实现管理员权限下的恶意操作,在我曾经写过的文章《从瑞士军刀到变形金刚--XSS攻击面拓展》中,我就曾经以WordPress为例子来举了多个从XSS到进一步恶意操作的利用方式。

    https://lorexxar.cn/2017/08/23/xss-tuo/#Xss-to-Rce

    我们仔细回顾一下整个漏洞,攻击者需要诱骗超级管理员点击他的恶意链接,然后需要手动把鼠标放置到评论上,甚至还需要保留该页面一段时间,整个攻击才有可能成功。

    不难发现,如果我们把漏洞放在WordPress Core树立的安全标准下来说,该漏洞实际能算作是漏洞的部分只有一个,就是绕过Nonce机制实现的一个WordPress XSS漏洞。当我们抛开这个关键点之后,我们不难发现,这个漏洞看上次利用条件还不错,但实际上,在WordPress的安全机制中,插件安全一直是最严重的问题,一旦WordPress的高量级插件爆了一个后台的反射性XSS漏洞,利用难度反而甚至比这个漏洞更低,不是吗?

    漏洞要求

    漏洞复现

    搭建完成后使用admin账号登陆

    然后构造恶意页面

    使用登陆过超级管理员的浏览器点开该页面,然后就会提交评论,当鼠标移动到评论上是,则会执行相应的js

    从漏洞补丁看漏洞分析

    刚才我们说到了一个关键点,整个漏洞实际上可以看作是一个绕过Nonce机制实现的一个WordPress XSS漏洞。

    这里我们从漏洞补丁出发,重新分析下这个漏洞的几个关键点。这个漏洞到目前为止,一共有2个commit用来修复。

    第一个commit首先是修复了那个不该有的xss漏洞

    esc_attr是WordPress内置的过滤函数,专用来处理属性处的可能出现xss的位置。

    第二个commit就比较有趣了,在我看来这个commit更像是一个半成品,可能是由于修复比较匆忙,先把修复的patch更新了再说的感觉。

    这个commit我们需要跟进到函数wp_filter_kses才看得懂,我们跟着这个函数一路跟下去,一直到/wp-includes/kses.php line 1039

    这里的pre_comment_content大概像是请求的类型,要到wp_kses_allowed_html去获取允许的标签以及属性列表。

    /wp-includes/kses.php line 829

    由于还没有针对性的设置,所以在现在的版本中,如果没有设置nonce,享受的是和其他用户相同的评论过滤,也就从另一个角度修复了这个漏洞:>

    写在最后

    当我们一起分析完整个漏洞之后呢,不难发现RIPS为了pr不惜吹了个大牛,其实当我们把整个漏洞重新压缩之后,我们发现其实漏洞就相当于其他CMS爆了一个存储型XSS漏洞一样,之所以会有这样的利用链,反而是因为WordPress对其本身错误的安全认知导致的。

    在WordPress的安全认知中,Nonce机制的确是一个效果非常好的安全机制,但从一个安全从业者的观点来说,WordPress的超级管理员应不应该等同于服务器管理员仍然是一个需要考虑的问题,在安全的世界里来说,给每个用户他们应有的权限才是最安全的做法,不是吗?


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/854/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • 利用 Exchange SSRF 漏洞和 NTLM 中继沦陷域控

    2019-03-05

    作者:xax007@知道创宇404 ScanV安全服务团队
    作者博客:https://xax007.github.io/

    漏洞简述

    在群里看到一篇分享的利用 Exchange SSRF 漏洞获取域控 的文章(中文翻译),让我眼前一亮,后来又在微博看到有大佬复现了这个漏洞,于是我也决定试试。

    上文中的漏洞利用思路按照我的理解可以汇总成一句话就是:

    在Exchange 在域内具有高权限的前提下条件下,利用 Exchange 的跨站请求伪造漏洞进行 NTLM 中继攻击,修改域 ACL 使普通用户具有域管理员同等级别的权限

    这篇文章的利用手法和其他网上很多方法不同的点在于,对 SSRF 漏洞进一步利用达到了拿到域控的目的,其他文章里都仅仅是利用SSRF 漏洞查看管理的邮件或者修改管理员邮箱规则,如邮件自动转发等。

    不想拿到域控的黑阔不是一个好黑阔,利用多个普通漏洞,最大化利用漏洞拿到域控的骚姿势肯定要学一下的,于是有了这篇文章。

    此文记录了我对这个漏洞进行的所有工作和遇到的坑。

    漏洞环境搭建

    复现这个漏洞最费时间又麻烦的就是搭建环境,我在 MacOS上 使用 Vmware Fusion 搭建了此漏洞需要的域环境

    VMware Fusion 会在系统安装两个虚拟网卡,分别为 vmnet1 和 vmnet8

    vmnet8 为 NAT网卡,可以让虚拟机上网 vmnet1 为 HostOnly 仅主机网卡,用来搭建私有网络,我们需要对此网卡作出修改

    如果在Windows系统搭建环境时,也应该设置所有虚拟主机为 HostOnly 模式,方法大同小异

    配置 Vmware Fusion

    修改 /Library/Preferences/VMware\ Fusion/networking 文件

    关闭 vmnet1的 dhcp,否则虚拟主机之间无法通信

    可参考:MAC下VMware Fusion虚拟机配置网卡

    搭建域环境

    这里可以下载到能免费试用180天的正版 Windows Server 2012 系统

    我安装了一台 Windows Server 2012,装好以后克隆了一台,给虚拟分配多少硬件资源取决于自身电脑配置,这里我电脑的配置

    img

    因为是克隆的系统,两台的SID是一样的,会加入不了域, 所以克隆的这台要修改 SID

    修改 SID 的方法是,在克隆的那个系统里进入 c:\windows\system32\sysprep\ 执行

    按照提示操作,重启就修改好了。

    最终各种查资料、看不懂、迷惘、折腾后搭好了可用的域环境。

    域环境的搭建主要参考了几位大佬的以下几篇文章

    搭建渗透测试活动目录教程1

    搭建渗透测试活动目录教程2

    当然还有 l3mOn 大佬的:

    Microsoft Exchange漏洞记录(撸向域控) - CVE-2018-8581

    同步域内系统时间

    搭建小型域环境里大佬说同步时间很重要,我发现我两个系统的时间都不一样,所以在域控所在的服务器配置系统时间:

    打开 powershell 并执行

    其中

    /manualpeerlist 表示外部时间源服务器列表,多个服务器之间可用空格分隔,cn.pool.ntp.org 和 tw.pool.ntp.org是 NTP 时间服务器

    /syncfromflags:manual 表示与指定的外部时间源服务器列表中的服务器进行同步

    /reliable:yes 表示设置此计算机是一个可靠的时间源

    /update 表示向时间服务发出配置已更改的通知,使更改生效

    以上步骤参考了以下的文章

    Windows server 2012 部署NTP,实现成员服务器及客户端时间与域控制器时间同步

    我按照教程在域控所在的服务器执行到第三步,另一台服务器的时间自己就同步了

    最终搭好了可用的域环境:

    按照以上三个教程的步骤走,看不明白继续搜教程就可以搭好域环境

    攻击主机 Kali Linux 为了能访问域网络需要添加一个 HostOnly 网卡,我添加后的网卡名为 eth1

    然后进行以下配置

    安装 Exchange Server 2013

    首先需要在 Exchange 所在的服务器上使用域控 Administrator 账号登录,不然安装检查是会出现一大堆错误

    安装 Exchange 前要装依赖组件,可以参考上面 l3m0n 大佬的文章和 Windows Server 2012 安装 Exchange 2013 这两篇文章

    安装好 Exchange 以后访问 Exchange 页面,在我的环境里的地址是 https://10.10.10.3 ,需要添加一个普通域用户,然后用域控管理员账号登录 Exchange 为此用户分配 Exchange 账号,这一步网上有很多教程

    后续要用此普通用户来提权

    所有的环境搭建好以后要进入激动人心的漏洞利用环节了!!!

    漏洞利用

    准备工具

    漏洞利用需要下载两个工具:

    第二个 Impacket 是一个功能很强大的 Windows 网络(SMB, MSRPC)工具包

    Kali 自带 Impacket,是版本过时了,需要安装最新的

    git clone 下载下来后,进入到 Impacket 目录使用 pip 安装

    注意这个工具是 python2 写的,使用 python3会出错

    发起攻击

    首先在本机启动 NTLM 中继,进入到 Impacker 的 examples 目录执行

    其中

    evilcorp.local 是域的名称

    --escalate-user 的参数是 Exchange 的普通权限用户名,也就是之前添加的普通用户用户名

    然后执行提权脚本

    其中

    -ah 参数指定域控地址可以是域的名称或 IP 地址,在这里为 10.10.10.1 10.10.10.3 为 Exchange 服务器在域的名称或者IP地址 -u 指定需要提权的 Exchange 的普通权限用户名 -p指定 Exchange 的普通权限用户的密码 -d 指定域的名称

    如果攻击成功你会看到 privexchange.py 脚本的输出

    img

    至此在 evicorp.local 域内, Mr.robot 用户具有了高权限,下一步我们导出域内所有用户的哈希

    导出域内用户哈希

    进入 Impacket\examples 目录执行

    就导出了域内所有用户哈希

    img

    在截图中由于 Kali 的 Openssl 版本太新有 bug,没办法连接上 Exchange 服务器使用自签名证书的HTTPS服务,在本机的 MacOS 上测试的

    我再一次得到一个教训

    平时没事别瞎更新整个系统,要更新也只更新需要的部分

    利用用户哈希反弹 shell

    哈希都拿到了,尝试反弹shell,使用 Windows 帐户哈希反弹 shell 的工具很多,我使用 smbmap

    smbmap 已内置在Kali Linux

    nc 监听端口

    反弹 shell

    img

    代码中的 10.10.10.5 修改为攻击者IP,1337 修改为NC监听端口


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/833/

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags:
  • ES 文件浏览器安全漏洞分析(CVE-2019-6447)

    2019-02-28

    作者:0x7F@知道创宇404实验室
    时间:2019.02.27

    0x00 前言

    ES 文件浏览器(ES File Explorer File Manager application)是一款安卓系统上的文件管理器,它支持在手机上浏览、管理文件。有超过 1 亿次下载量,是目前安卓系统上使用得最广的文件管理器。

    2019年1月,由国外安全研究者公开一个关于 ES 文件浏览器的安全漏洞(CVE-2019-6447)。

    2月下旬,笔者浏览到该漏洞的相关文章,想借此机会学习 APK 逆向,随即对该漏洞进行了复现分析,结合已公开的分析文章,发现原理非常简单,下面就来一探究竟吧。

    0x01 漏洞概述

    ES 文件浏览器在运行时会创建一个绑定在 59777 端口的 HTTP 服务,在该服务提供了 10+ 个命令,用于访问用户手机的数据以及执行应用程序;但该服务并没有对请求进行校验,从而导致出现安全漏洞。

    影响范围
    <= ES 文件浏览器 v4.1.9.7.4

    修复方式
    前往应用商城下载最新版即可。修复该漏洞的版本为(v4.1.9.9)

    0x02 漏洞复现

    漏洞复现环境

    • Windows 7
    • OPPP R7
    • ES 文件浏览器v4.1.9.4
    • ADB (Android Debug Bridge)

    复现过程

    1. 通过 USB 连接手机与电脑,并打开 USB 调试。

    2. 通过 ADB 检查设备连接情况,并安装 ES 文件浏览器v4.1.9.4 到设备上。

    3. 在手机上可以看到 ES 文件浏览器已经安装成功,启动该应用;通过 ADB 查看当前网络端口情况,可以看到 59777 端口已经打开。

    4. 将手机和电脑配置到同一 WIFI 下,便于我们进行访问测试。

    5. 构造 HTTP 数据报文,将命令封装至 Json 数据中,请求 59777 端口;这里演示 getDeviceInfo命令,可以看到成功返回了设备的信息。

    0x03 漏洞分析

    反编译dex文件
    对 ES 文件浏览器v4.1.9.4 进行分析,首先将该 APK 进行解压,可以看到其中包含了三个 *.dex 文件。使用 dex2jar 工具分别这三个文件进行反编译,得到三个 *.jar 文件。

    使用 jd-gui 工具加载这三个 jar 文件,使用关键词搜索 59777commandgetDeviceInfo 以快速定位到漏洞逻辑部分,其位于 classes2-dex2jar.jar 下的 com.estrongs.android.f.a 路径下。

    ES HTTP支持的指令

    上图中,可以看到除了 getDeviceInfo 命令,该 HTTP 服务还支持不少的命令:

    command description
    listFiles 列出所有的文件
    listPics 列出所有的图片
    listVideos 列出所有的视频
    listAudios 列出所有的音频
    listApps 列出安装的应用
    listAppsSystem 列出系统自带的应用
    listAppsPhone 列出通信相关的应用
    listAppsSdcard 列出安装在sd卡上的应用
    listAppsAll 列出所有的应用
    getAppThumbnail 列出指定应用的图标
    appLaunch 启动制定的应用
    appPull 从设备上下载应用
    getDeviceInfo 获取系统信息

    除了以上列出的命令,还可以直接访问 url+系统文件路径,直接访问文件数据:

    命令执行示例(列出所有的文件):

    命令处理

    其命令处理部分逻辑大致就是进行相应的逻辑处理,并将执行的结果封装为 Json 数据格式,拼接为 HTTP 协议进行返回,下面是 getDeviceInfo 的处理逻辑:

    通过以上的功能逻辑可以看到,HTTP 服务是 ES 文件浏览器的一个内置功能,可能是用于不同设备之间的共享,但由于没有对请求进行校验,导致安全问题的出现。

    0x04 补丁分析

    下载已补丁的版本 v4.1.9.9.3,同样对 APK 进行解包,通过 dex2jar 反编译为 *.jar 文件,对文件进行分析。

    POST 请求校验

    v4.1.9.9.3 版本可能重新进行了代码混淆,其反编译后的机构和 v4.1.9.4 有很大的差别;我们仍然使用关键词搜索来快速定位到之前的漏洞逻辑部分。位于 classes3-dex2jar.jar 下的 es.qg 路径下。

    从上图可以看到,标注地方是新版本所添加的补丁,在处理请求时,首先进行检查,检查失败的情况下返回 400 错误。

    跟入 ap.d() 函数中,可以看到两个关键检查函数:

    1.检查函数1

    该函数获取了 UIModeManager 对象,当该对象的类型等于 4 时,返回 true,通过查阅官方文档,在该处数值 4 对应的类型为 UI_MODE_TYPE_TELEVISION,也就是安卓TV的类型。说明官方将该功能限制在安卓TV的设备上了。

    2.检查函数2

    检查函数2依然是对安卓TV的判断,在上一步函数获取了屏幕的尺寸并转换成了一个值,在该处判断值要大于 20,才能返回 true

    Andoird TV会受到威胁?

    根据以上补丁的情况来看,可以猜测到 Android TV 似乎受到该漏洞的威胁,但实际上并不会。因为 Android TV 处理流程和手机版的不同,本身也不受该漏洞的影响。

    将有漏洞的版本(v4.1.9.4)安装至 Android TV 上;经过测试可以发现,在 Android TV 下发起请求将直接返回 500 错误。

    原因是程序在判断设备是 TV 时,会首先提前做一次来源 IP 检查(判断是否由是本地发起的请求,检查失败也返回 500 错误),随后再检查可访问的路径,如下函数(classes3-dex2jar.jar/es.qj$a):

    但经过测试,发现该数组的值为 NULL,直接返回 false

    最终跳转至该语句,返回 500 错误。所以 Android TV 也不会受到该漏洞的影响。

    Get请求列目录修复

    在上文中还提到发送 GET 请求可以列文件,在新版本也进行了修复。

    当以 GET 方式发起请求时,将进入 ai.bK() 的函数判断,在该函数中检查了 HTTP 的数据必须以 http://127.0.0.1: 开头,才可以返回文件列表;HTTP 协议都是以 GET/POST/... 开头,肯定不会以这个方式开头,虽然不太理解这个检查,但还算是解决了列目录的问题。

    0x05 总结

    通过以上的分析,可以完整的了解到 ES 文件浏览器安全漏洞的触发过程以及补丁情况;整体看来就是,开发者在设计共享访问功能的时候忽略对请求的检查,从而导致的安全漏洞。

    References:


    Paper

    本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/831/

     

    作者:吴烦恼 | Categories:安全研究技术分享 | Tags: