近期, 360 企业安全集团代码卫士团队安全研究人员发现微软公司 Windows10 操作系统自带的 Edge 浏览器存在安全漏洞 ( CVE-2019-0648 ),并第一时间向微软公司报告,协助其修复漏洞。

Edge 浏览器是微软 Windows10 操作系统默认浏览器。北京时间2019年2月13日,微软公司发布了补丁更新公告以及致谢公告( https://portal.msrc.microsoft.com/en-us/security-guidance/acknowledgments ),公开致谢360企业安全集团代码卫士团队研究人员,并随后给予5000美元的漏洞奖励。

图 微软公司致谢及漏洞信息公告

Edge 浏览器的 ChakrCore 引擎由于缺乏对特殊字符的检查,进而绕过边界的结束处理,导致可以越界访问内存空间。在一定条件下,成功利用此漏洞的攻击者可以造成信息泄露。建议用户及时更新补丁进行修复。

参考链接

CVE-2019-0648|Scripting Engine Information Disclosure Vulnerability

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019-0648

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM

 

Semmle公司的安全研究员Kevin Backhouse在Facebook的开源TLS库Fizz中找到一个因证书溢出触发的拒绝服务漏洞。因该漏洞严重程度高,因此Facebook破例为原本不再奖励范围内的漏洞颁发1万美元的奖励。

如下是该研究员的博客文章节选:

Fizz 简介

该漏洞是一个无限循环,可被未验证的远程攻击者触发。Fizz是Facebook的TLS实现,也就是说它用于 https://facebook.com 中的“https:”部分。据Facebook公司在2018年8月6日发布的数据显示,“我们在全球范围内为移动应用、Proxygen、负载平衡器、内部服务甚至是OUIC库mvfst等中部署了Fizz。超过50%的内部流量目前受TLS 1.3的保护。”

鉴于Fizz是一个开源项目,因此其它项目和组织机构可能也在使用它。

漏洞严重性和缓解措施

漏洞(CVE-2019-3560)造成的影响是,攻击者能够通过TCP向任意使用Fizz库的服务器发送恶意信息并在该服务器上触发无限循环,从而导致服务器对其它客户端无法做出响应。该漏洞被归为拒绝服务(DoS)漏洞,因为它导致攻击者破坏服务而不是获取未授权访问权限。由于信息只有64KB大小,因此发动攻击的成本极其低廉,但对于服务器而言却具有重大风险。

具有异常民用级互联网连接(1Mbps的上传速度)的一台电脑就能每秒发送两条信息。由于每条信息针对的是一个CPU内核,因此只需要小型僵尸网络就能快速拿下整个数据中心。

我没有发现针对该漏洞的缓解措施,因此建议尽快更新到已打补丁的Fizz版本v2019.02.25.00。

PoC

我已经编写了触发该漏洞的PoC。它就是一个简单的C程序,打开服务器的TCP套接字并发送大小仅为64KB的恶意有效负载。该程序在发送完有效负载后就马上关闭套接字,但服务器由于陷入死循环因此无法注意到这一点。我并未在真实的网站上测试该有效负载,只是在包含在Fizz源代码的演示服务器应用中进行了测试。然而,该漏洞存在于Fizz库的核心,而非演示应用程序,因此我认为 https://facebook.com 在提交漏洞前是存在风险的。

Facebook已发布补丁,但我会在其它Fizz用户更新后发布完整详情。

简要技术分析

这个漏洞是因为PlaintextRecordLayer.cpp第42行中+=中存在一个整数溢出问题:

auto length = cursor.readBE<uint16_t >();if (buf.chainLength() < (cursor - buf.front()) + length) { return folly::none;}length += sizeof (ContentType) + sizeof (ProtocolVersion) + sizeof (uint16_t );buf.trimStart(length);continue ;

该代码从传入的网络数据包中读取一个uint16_t并将其分配给length。换句话说,length的长度是受攻击者控制的。第2行的if语句看似是bounds检查,但实际上只是检查已收到足够的数据以便继续解析。这就是利用代码为何需要发送64KB数据的原因:该代码在收到至少length字节之前并不会触发第5行的整数溢出。该利用通过设置length = 0XFFFB起作用。这意味着+=后,length的值为0。它说明调用第7行的trimStart并不会消耗任何数据,因此在循环下次迭代前并不会产生任何进展。

而修复该漏洞的方法也很简单:使用大于uint16_t的类型来计算该加法,从而避免整数溢出问题的产生。

但是,我并未有完全说明该利用起作用的全部内容。设置length = 0XFFFB这一步是容易的那部分,我发现搞清楚如何构建真正能触发这行代码的信息才是更难的部分。Fizz用户更新后,我会发布完整详情。

漏洞奖励

2019年3月13日,Facebook给我发了一份邮件,通知我获得1万美元的奖励。他们的解释如下:

“这个漏洞本可导致恶意攻击者引发针对Facebook基础设施的拒绝服务。虽然我们的漏洞奖励计划通常并不涵盖此类漏洞,但你提交的报告讨论了具有重大风险的场景。”

时间轴

2019-02-20:通过Facebook公司的白帽计划提交漏洞

2019-02-20:Facebook证实漏洞问题存在并转交给产品团队

2019-02-20:Facebook修复所有服务器

2019-02-25:Facebook在GitHub上推送修复方案

2019-03-13:Facebook确认漏洞奖励

2019-03-19:Semmle公司披露CVE-2019-3560

该研究员按照所在公司的政策,已将赏金全部捐献给慈善组织Techtonica。按照Facebook的规定,如果选择捐赠,则Facebook会捐赠同等款项,因此该慈善组织收到2万美元的捐赠。

*参考来源:lgtm,360代码卫士编译整理,转载请注明来自 FreeBuf.COM。

NSA发布了内部开源逆向工程工具Ghidra,可用于从应用程序中搜查安全漏洞和其它问题。

nsa-to-release-free-reverse-engineering-tool-ghidra-at-rsaconference-1.jpeg

剧透预警:

它受Apache 2.0许可,现在已可下载,并要求Java运行时。NSA保证称并未在其中安装任何后门。

著名的“圣诞节灯光黑客”兼NSA局长网络安全顾问Rob Joyce在RSA大会上发表演讲,披露了这款代码分析软件。NSA希望该开源代码助力安全软件研究工作,并向与会者确保其中并不暗藏任何不可告人的伎俩。

他宣布称,“Ghidra中并不存在任何后门。对于寻找拆解这些东西的人来说,这是你想要发布含有后门的东西的最后一个地方。”

然而,英国安全厂商Hacker House的研究员Matthew “HackerFantastic”Hickey表示,这个项目中存在一个奇怪的地方。当你以调试模式运行该代码时,它会向本地网络开放端口18001,从能够连接的机器上执行远程命令。调试模式默认并未激活,尽管这是已提供的功能。

不过不要失去理智。如果你打算改进或修正问题的话,要注意这一点,要在启动调试的情况下启动它。因此这个问题更像是一个bug,而不是后门,可通过更改启动程序shell脚本中断,这样该软件仅监听主机的调试连接,而不是通过网络监听任何计算机。

NSA的一名发言人表示,这个开放的端口允许团队进行协作并和共享信息以及同时在网络上互相提醒。然而,Hickey表示该功能是由另外一个网络端口提供的。

Hickey表示,“这个共享的项目使用了不同的端口13100,因此它并非同一个功能。他们犯了一个错误,在为Ghidra启用调试模式时使用了 * 而非本地主机。”

细节和关键功能

Joyce在演讲中表示,Ghidra是由NSA内部开发的,目的是为了拆解包括恶意软件在内的软件,并且找出潜伏在可执行二进制文件中的内容。网络间谍通过使用这类工具来查找产品中的安全弱点以攻击情报目标。

该项目由120万行代码组成,旨在逆向编译器进程、将可执行代码反编译为汇编列表,最后转换为近似的C代码。它还有助于通过函数绘制控制流,检查符号和引用,识别变量、数据和其它信息,等等。如果你习惯使用类似的逆向工程工具如IDA、Hopper、Radare、Capstone、Snowman等,那么你会对它非常熟悉。

该平台独立于处理器,能够分析x86、Arm、PowerPC、MIPS、Sparc32/64和其它处理器的代码,并且能够在Windows、macOS和Linux上运行。虽然是用Java构建的,但该代码也能处理基于Python的插件以及用Java编写的插件,Joyce表示这样做的原因是NSA分析师不喜欢Java因此添加了Python支持。

用户能够在具有或没有图形用户界面的情况下使用Ghidra,并可编写脚本。如上所述,用户不仅能够使用自己的注释来注释代码,还可以通过网络协作从其它团队成员那里获取注释。

对于新用户而言,NSA还提供了大量的帮助文档。Joyce表示他希望社区能够添加更多的功能和脚本并进行分享,因为NSA想要使其成为广泛使用的工具。

他表示,Ghidra开源了,但这并非结果。NSA已在GitHub上建立了存储库,并表示接受贡献。

NSA-ghidra.jpg

Joyce承诺将在未来发布一款集成的调试器、一款强大的仿真器以及改进后的分析工具。他表示这些工作花的是美国纳税人的钱,一旦纳税人能够赶上内部工具的速度,那么它可能能够帮助公民进入NSA。

不过,话说回来,一直想问个问题:NSA到底为什么会向全球所有人免费开放这款工具?或许NSA的对手具有更好的或类似的工具,也有可能NSA内部已经转向了更加复杂的工具集,正好是公开发布Ghidra工具集的好时机。

工具集下载地址:https://ghidra-sre.org/

GitHub:https://github.com/NationalSecurityAgency/ghidra

原文地址:https://www.theregister.co.uk/2019/03/06/nsa_ghidra_joyce/

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM

HackerOne 平台发布年报,内容主要包括:黑客从哪里来?为何挖漏洞?最喜欢的黑客目标和工具是什么?从哪里学习?为何要和他人协作等等。另外,还公布了首位获得百万赏金的黑客年仅19岁且自学成才。

weq.png

报告数据来自 HackerOne 调查数据以及2018年12月以及2019年1月的 Harris 调查数据,后者的数据来自100多个国家和地区超过3667名黑客。HackerOne 平台数据来自成功地在该平台上报告过一个及以上有效漏洞的黑客,以及该平台基于1200多个漏洞奖励计划和漏洞披露计划的专有数据。主要研究结论如下:

报告指出,HackerOne 平台的注册黑客人数已突破30万人,提交的有效漏洞总计超过10万个,支付的漏洞奖励金超过4200万美元。单在2018年,漏洞赏金总额即超过1900万美元,几乎是之前所有年份赏金的总和。

印度和美国仍然是最多的黑客聚集地,超过6个非洲国家在2018年首次参与该平台活动。

由黑客驱动的安全正在全球范围内创造机会。顶级赏金猎人能够赚取的年度赏金是其所在国软件工程师年薪中位数的40倍。

黑客培训活动发生在传统教室之外的地方。81%的黑客表示是通过博客以及学材料如公开披露的漏洞报告等学习技能的。仅有6%的黑客是通过传统教室或黑客证书入行的。

“黑客向善”正在逐渐为大众接受。Harris Poll 调查数据显示近三分之二的美国人(64%)认为并非所有的黑客都在使坏。

黑客从哪里来?

黑客几乎遍布全球每个角落。冰岛、加纳、斯洛伐克、阿鲁巴和厄瓜多尔的黑客和印度、美国、俄罗斯、巴基斯坦和英国的黑客一样意志坚定、技能娴熟、渴望成功,但后五个国家在黑客驱动安全领域的地位不可撼动。单是印度和美国的黑客数量就占据了总数的30%,2018年更是占比43%。在黑客全球化的时代,黑客拥有新型且大量机会施展拳脚,而他们所需的不过是互联网连接。

0.png

肯尼亚的黑客首次参与活动,阿尔及利亚的参与人数较上一年翻了一番。印度连续两年成为黑客的最多来源地,超过6个非洲国家首次参与活动。

哪个国家提供的赏金最多?拿到的赏金最多?

截止2018年,HackerOne 平台共支付4200多万美元的赏金,8个国家的组织机构贡献了超过一半的赏金。美国和加拿大的组织机构贡献金额最多,其次是英国、德国、俄罗斯和新加坡。拿到最多赏金的黑客依次来自美国、印度、俄罗斯、未知来源、德国、加拿大、英国、瑞典、荷兰和中国。

1.png

黑客赏金是普通程序员收入的多少倍?

报告提供了黑客赏金与软件工程师中位数年度收入对比数据。在阿根廷,黑客赏金收入是软件工程师的40.6倍、泰国是2.5倍、埃及是24.2倍、印度是17.6倍、中国香港是6.7倍、美国是6.4倍、瑞典是6.3倍、中国是6.2倍。

2.png

黑客人口统计状况

90%的黑客年龄低于35岁,而其中18-24年龄段的人略有增长。这群人占 HackerOne 平台黑客总数的47%,而且是唯一一个在数量方面逐年上涨的群体。但也不要小看年龄稍长的群体,35-49岁的群体数量在2018年占比超过9%,而50-64岁的人群数量在2018年几乎翻了一番。

3.png

80%的人是自学成才,越来越多的黑客来自技术以外的行业,让漏洞挖掘的领域充满活力。40%的人每周花费20多个小时寻找漏洞。

81%的黑客将网络资源和博客作为主要的学习途径,只有6%的黑客完成了正规课堂或证书培训。

4.png

为何从事黑客活动?或因兴趣而起或是全职工作所需。多数是因为感兴趣,很多人在全职工作结束或上完课后基本将时间和精力投入到挖漏洞中。四分之一的人将其当作职业,仅有不到40%的人是从事IT或技术行业,而在2017年,这个比例还是47%。

5.png

三分之一的黑客每周花10个小时或更少的时间,不过这一比例在2018年比2017年有所下降。越来越多(超过25%)的黑客每周花费30个小时或更多的时间。

6.png

区块链黑客趋势如何?

近70家区块链和密币公司使用 HackerOne 平台确保安全。2018年,这些公司收到的漏洞报告近3000份。2018年HackerOne平台上4%的赏金源自区块链和密币组织机构。提供基于区块链令牌的浏览器产品的公司 Brave 支付超过2.5万美元的赏金,解决了近100个漏洞报告。

黑客从区块链行业中获得的赏金更高。2018年,所有与区块链相关的公司支付的平均赏金是近1500美元,比平台的平均水平高出600美元左右。而区块链黑客所获得的赏金是其所在国家软件工程师的工资中位数的7倍。

7.png

近30%的 HackerOne 平台上的黑客具有6年或以上的经验。而年龄并非唯一衡量经验、技能或受教育水平。

最受欢迎的黑客工具是什么?

2018年,黑客使用第三方本地代理工具的比例增长了67%。Burp Suite 是使用最多的工具 (32.7%),而使用Fiddler (14.7%)、Webinspect (11.1%)、ChipWhisperer (9.8%) 的黑客人数也在不断增长。而使用网络扫描器和模糊测试工具的人数稳定。

8.png

黑客宠爱的目标是什么?

黑客最爱的目标是网站、API 和持有自己的数据的技术。他们仍然最爱从 web 应用中查找漏洞。70%的受访黑客表示最喜欢黑的产品或平台依次是网站 (72.8%)、API、存储自己数据的技术 (3.7%)、安卓应用 (3.7%)、操作系统 (3.5%) 和可下载软件 (2.3%)。

9.png

仅仅是因为钱才当黑客的吗?

经济收益无疑起着重要作用。然而,好奇心是永远不变的源动力。有些黑客只是为了“好玩”,而这个比例和只是为了赚钱的黑客比例几乎相当 (14.3%)。四分之一的黑客表示是为了帮助他人或做好事。

10.png

黑客选择某个公司的原因是为了挑战或学习 (59.5%)、喜欢某个公司 (40.4%)、该公司安全团队的响应 (36.4%)、为了获得最高赏金 (31.9%)、我用这种技术或里面有我的数据 (31%)等。

11.png

黑客最喜欢的攻击向量、技术或方法是什么?

超过38%的黑客的答案是 XSS 漏洞,其次是 SQL 注入、模糊测试、业务逻辑、信息收集、SSRF、RCE、枚举、逆向工程、IDOR、暴力攻击、注入、CSRF、验证、XXE、DDoS。

12.png

如何和平台上的其他黑客建立连接一起工作?

通过读他们的博客和公开披露的漏洞报告占比最大,为33%;而24.4%的黑客表示不喜欢协作而喜欢单干;14.7%的黑客表示在某些特殊项目或挑战时进行合作;9.9%的人表示是他人的导师或是受其他黑客的引导;一直和其他黑客协作的占据8.7%,而作为团队成员和他人一起提交漏洞报告的占比7.4%。

13.png

说到公司收到漏洞报告的反应,一定程度上态度比较开放 (36.5%)、非常开放 (32.2%)、一般 (17.6%)。

14.png

首个百万赏金富翁是谁?

现年19岁的 Santiago Lopez 是在 HackerOne 平台上获得100万美元赏金的第一人。他16岁时开始学习黑客技术,互联网即是他的黑客学校,他从中查看并阅读如何绕过或打破安全防御的材料。一年之后,他凭借一个 CSRF 漏洞获得50美元的奖励,而最大的奖励是因发现SSRF漏洞而获得的9000美元。他用获得的第一笔赏金买了一台新电脑,之后又买了一辆车。

635363-santiago-lopez.jpg

如今,他共发现了1676个唯一漏洞,将报告提交给了很多大公司,如 Verizon、Automattic、推特、HackerOne和一些私营企业、甚至还包括美国政府。目前他在 HackerOne 平台上排名第二。

一言以蔽之,这是属于黑客的时代。

HackerOne 黑客报告完整版:https://www.hackerone.com/sites/default/files/2019-03/the-2019-hacker-report.pdf

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM

近期,360企业安全集团代码卫士团队安全研究人员发现友讯(D-LINK)公司旗下产品系列DIR-619、DIR-605系列路由器的两个高危安全漏洞(CVE-2018-20056和CVE-2018-20057),并第一时间向友讯(D-LINK)公司汇报,协助其修复漏洞。

DIR-605及DIR-619系列是友讯公司旗下的家用路由器产品。北京时间2019年1月4日,友讯(DLINK)公司发布了安全更新公告(https://securityadvisories.dlink.com/announcement/publication.aspx?name=SAP10100),公开致谢360企业安全集团代码卫士团队,并且发布相应的补丁修复漏洞。

1.png2.png

图 致谢360代码卫士

本次友讯公司修复的漏洞中,CVE-2018-20056是一个缓冲区溢出漏洞,本文将针对该漏洞进行技术分析。

3.png

漏洞概述

CVE-2018-20056

该漏洞是一个无需授权的栈缓冲区溢出漏洞,影响D-LINK DIR-605L 300M wireless cloud routing和DIR-619L 300M wireless cloud routing型号。漏洞出现在 web 服务器中的一个功能接口中,可被未经验证的用户通过post请求进行调用。请求的URL为:http://[target_ip]/goform/formLanguageChange,其中POST数据的currtime参数未进行长度校验通过危险的内存拷贝函数写入栈上,导致精心构造的currtime参数可以触发缓冲区溢出漏洞,甚至直接获得设备的 rootshell。

技术分析

通过binwalk解包固件后分析系统文件目录,发现系统中存在boa程序。Boa程序是一个轻量级的web服务器程序。常见于嵌入式系统中。通过逆向分析发现此程序在boa开源代码的基础上新增了很多功能接口以实现路由器上的不同功能。

其中大部分功能接口都需要经过身份验证后才可以使用,但仍旧存在少部分功能接口如登录注销等可以使用。通过逆向分析boa程序定位至process_header_end函数,可以找到未验证用户可使用的部分功能。其中部分关键代码如下,其判断流程可简单总结为,若is_valid_user函数判断请求来自于未验证用户后, 会再次通过strstr函数判断url请求是否为此用户可使用的功能接口。 通过分析及实验发现,除了login功能外,未验证用户还可以使用formlanguagechange功能接口来改变web前台界面显示的语言。

4.png5.png

接下来通过定位分析分发函数websaspinit寻找进入此函数的方式,关键代码如下:

6.png

通过分析实验发现,在post请求访问http://[target_ip]/goform/formLanguageChange时会进入formLanguageChange函数流程,函数中通过websgetvar函数获取post请求中config.i18n_languagecurrtimenextpage参数的值。

websgetvar函数中,通过strlenmallocmemcpy函数将参数值保存至申请出的一块内存空间中,但并未对参数长度进行判断和限制。这种参数获取的方式在遇到危险的内存拷贝函数时极易产生问题,是后面产生漏洞的根源所在。

7.png

图 websgetvar函数

继续分析formLanguageChange函数,程序将获取到的currtime参数值直接通过危险函数sprintf写入栈上0x110-0xf8的位置导致了缓冲区溢出。

通过分析, 函数返回地址保存在0x110-0x4位置,即当参数长度大于0xf4时会直接覆盖函数返回地址,导致程序控制流被劫持。

8.png

图 formLanguageChange函数

结合路由器环境本身防护机制的不足,在攻击者控制程序流程后,可通过rop技术实现任意代码执行。

Rop流程为:1.赋值a0参数。

2.调用sleep函数。

3.赋值某寄存器为栈上地址。

4.通过寄存器跳转的方式跳入栈中shellcode的位置完成利用。

9.png

 图 利用结果

参考链接

https://securityadv.isories.dlink.com/announcement/publication.aspx?name=SAP10100

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20056

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM

微软Exchange似乎易受权限提升攻击影响,任何用户,只要有邮箱,就能变身为Domain Admin

荷兰Fox-IT公司研究员Dirk-jan Mollema在博客上发布了PoC,并详细解释了攻击细节。Mollema认为,主要的问题在于,Exchange默认在活动目录域名具有高权限。

他在博客文章中指出,“ExchangeWindowsPermissions组在活动目录的 Domain 对象上具有WriteDacl访问权限,使得该组成员均可修改域名权限,其中的一个权限是执行DCSync操作。”

这就导致攻击者能够通过Domain Controller操作同步活动目录用户的哈希密码。攻击者可通过访问这些哈希密码假冒用户并在使用NTLM(微软的认证协议)或该域名内的Kerberos认证的服务进行认证。

目前,Mollema尚未回应相关问题。他发布的博客文章题目是《滥用Exchange:你距离成为Domain Admin仅差一个API调用》。全文如下:

在多数使用活动目录和Exchange的组织机构中,Exchange服务器都具有一种高权限:成为Exchange服务器上的Administer就足以提升至Domain Admin。最近我在ZDI上偶然发现了一篇博客文章(见文末链接),他们详细说明了如何使用NTLM经由HTTP让Exchange进行认证。结合使用NTLM中继攻击,任何人只要拥有一个邮箱就能提升至Domain Admin权限,在我所知道的大概90%的使用Exchange组织机构中都是可行的。这种攻击可能是默认的,目前尚未有任何补丁,不过可以使用一些缓解措施来阻止此类权限提升问题。本文详细说明了这种攻击,而且PoC已发布,名为“PrivExchange”。

结合利用已知漏洞的新方法

这篇文章讲的是如何结合利用一些新漏洞以及已知的协议弱点,发动新攻击。结合使用3个组件,拥有邮箱的任何用户就能提升至Domain Admin访问权限:

Exchange Servers默认的权限太高

NTLM认证易受中继攻击

Exchange的某个功能使其能够认证到具有Exchange服务器计算机账户的攻击者

 Exchange和高权限

这里说的主要漏洞是,Exchange在活动目录域名中具有高权限。Exchange Windows Permissions组在活动目录的Domain对象中具有WriteDacl访问权限,导致该组的任何成员都能修改域名权限,其中一种权限是执行DCSync操作。任何具有这种权限的用户或计算机都能执行同步操作,而这种操作正常情况下是供Domain Controllers进行复制,这就导致攻击者能够同步活动目录中的所有用户的哈希密码。多名研究人员曾对此进行过阐述(见文末参考部分),而且我和同事Rindert也在去年写过。在那篇文章中我也发布了ntlmrelayx的更新,增加了在NTLM中继过程中执行这些访问控制清单(ACL)攻击的可能性。

NTLM 中继机器账户

NTLM中继已经存在有段时间了。之前,它的主要关注点是经由SMB中继NTLM,以便在其它主机上执行代码。虽然到目前为止,仍然很可能在很多未启用SMB签名进行安全加固的公司中实施这种攻击,但其它协议也易受中继攻击。我认为其中最有意思的协议就是LDAP,它可用于读取并修改活动目录中的对象。简单说一下NTLM中继,就是除非已经应用了缓解措施,否则在连接至攻击者机器上之后和网络中的其它机器进行连接时,很可能会绕过Windows自动执行的认证,如下图所示:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

当认证被中继到LDAP时,目录中的对象可被修改,给予攻击者权限,包括DCSync操作所需要的权限。因此,如果我们能够使Exchange通过NTLM认证和我们进行认证,那么我们就能执行ACL攻击。值得注意的是,只有在受害者通过HTTP而非SMB和我们进行认证时,中继到LDAP才奏效。

使 Exchange 进行认证

目前为止,唯一一个缺失的组件是使Exchange认证到我们的一种简单方法。ZDI的一名未透露姓名的研究员发现,使 Exchange 经由 Exchange PushSubscription功能通过 HTTP 向任意 URL 认证是很可能实现的。他们使用这个漏洞将NTLM认证中继回Exchange(即反射型攻击)并假冒其他用户。如果我们再结合Exchange默认具有的高权限并执行中继攻击而非反射型攻击,那么我们就能使用这些权限获得DCSync权限。这个推送通知服务允许用户在即使未发生任何事件的情况下每隔X分钟(X值由攻击者设定)发送一次信息。这就能确保Exchange即使在收件箱中没有任何活动的情况下和我们连接。

执行权限提升攻击

实施攻击,实现权限提升的流程如下图所示:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们需要使用两款工具执行该攻击:privexchange.pyntlmrelayx。这两款工具可从GitHub的PrivExchange和impacket库中获取。以中继模式启动ntlmrelayx,以Domain Controller上的LDAP作为目标,并通过如下代码使受攻击者控制的用户提升权限(这个案例中是ntu用户):

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们开始运行privexchange.py脚本:

1000.jpg

如果是以没有邮箱的用户运行的话,就会得到如上出错消息。再尝试一下通过具有关联邮箱的用户运行一下:

1001.jpg

一分钟之后(推送通知提供的值),我们可以看到连接进入ntlmrelayx,用户获得DCSync权限:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们确认DCSynx权限位于secretsdump位置:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

凭借所有活动目录用户的哈希密码,攻击者就相当于持有一张金卡,能够假冒任何用户或使用任何用户密码哈希认证到任何接受NTLM或Kerberos域名认证的服务。

技术细节:中继到 LDAP 并签名

上文提到从SMB中继到LDAP不起作用,这也是为何说这种攻击无法通过使用最近发布的SpoolService RPC滥用等实施(它通过SMB认证)的原因。由于关于这部分的问题很多,现在统一说一下。如果你不打算详细了解NTLM认证部分,可以跳过这部分。

在SMB和HTTP中的NTLM认证的不同之处在于默认协商的标记(flag)。有问题的部分是NTLMSSP_NEGOTIATE_SIGN标记(0x00000010),如MS-NLMP第2.2.2.5节所示。通过HTTP的NTLM认证并不会默认设置该标记,但如果是通过SMB认证,则会默认设置:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

当我们将它中继到LDAP时,认证成功,但LDAP的预期是所有通过衍生自密码的会话密钥签名的信息(中继攻击中不具备)。因此它会忽视任何不具备签名的信息,从而导致攻击失败。有人可能会想,是否可以在传输过程中修改这些标记,这样就不用协商签名了。由于Windows现代版本都默认包含一个MIC(信息完整性代码)即基于所有3 NTLM信息的签名,因此对其中任何信息的修改都会导致其不合法。

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

那我们能删除MIC吗?可以是可以,毕竟它并非受NTLM信息保护的部分,但问题是NTLM认证(NTLMv2)中的最后一道防护措施阻止这样做:在 NTLMv2 响应的底部(该响应本身以受害者密码签名)存在一个AV_PAIR 结构MsAvFlags。当该字段的值为0x0002 时,表明客户端发送了一个具有type 3信息的MIC。

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

修改NTLMv2响应将导致认证失效,因此我们不能删除这个flags字段。该字段说明MIC被计算且包含,将使目标服务器验证MIC,从而验证所有的3信息都不会在传输过程中遭修改,因此我们无法删除签名标记。

我认为,这种情况仅对微软对NTLM的实现有效。实现NTLM的自定义工具很可能并不受影响,只有添加MIC和AV_PAIR标记时,导致它们易受标记修改攻击,从而导致SMB -> LDAP中继成为可能。其中一个例子就是NTLM的Java实现,它可在传输过程中遭修改绕过安全措施。

攻击无需任何凭证

上一节中,我们使用受攻陷凭证执行了攻击的第一步。如果攻击者只是位于执行网络攻击的位置,但并不具备任何凭证,那么仍然很可能触发Exchange进行认证。如果我们执行SMB到HTTP(或HTTP到HTTP)中继攻击(使用LLMNR/NBNS/mitm6欺骗),那么我们就能将位于同样网络片段中的用户认证中继到Exchange EWS并使用他们的凭证触发回调。我给出了一小段修改后的httpattack.py,你可以结合ntlmrelayx从网络角度实施攻击,而无需任何凭证(你只需要修改攻击者主机即可,因为它在文件中是硬编码的):

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

缓解措施

攻击依靠多种组件才能实施。在此前的博客文章中我已经强调过多种针对NTLM中继攻击和中继到LDAP的防御措施。

适用于该攻击的最重要的缓解措施包括:

删除Exchange在Domain对象上的不必要的高权限。

启用LDAP签名以及LDAP信道绑定,分别阻止中继到LDAP和LDAPS。

阻止Exchange服务器和任意端口上的工作站进行连接。

启用IIS中Exchange端点上(并非Exchange Back End,否则会导致Exchange崩溃)的Extended Protection for Authnticaiton。它将验证NTLM认证中的信道绑定参数,它将NTLM认证关联到TLS连接中并阻止向Exchange web服务进行中继。

删除注册表项(registry key),从而能够中继回Exchange服务器,如微软对CVE-2018-8518缓解措施的讨论。

在Exchange服务器上执行SMB签名(偏好域名中的所有其它服务器和工作站)以阻止针对SMB的跨协议中继攻击。

如果不使用EWS的push/pull订阅服务,则可以通过使用限制策略将EWSMaxSubscriptions设置为0的方式禁用。这是@gentikiwi提供的方法,我还没有测试过合法应用程序使用它们的频率,因此推荐在小范围内进行测试。

工具以及受影响版本

PoC请参见 https://github.com/dirkjanm/PrivExchange,且已在如下Exchange/Windows版本上进行了测试:

将Server2012R2 上的Exchange 2013 (CU21)中继到Server 2016 DC(都是完全修复版本)

将Server 2016上的Exchange 2016 (CU11)中继到Server 2019 DC(都是完全修复版本)

将Server 2019上的Exchange 2019中继到Server 2019 DC(感谢@gentilkiwi进行测试)

如上的Exchange服务器都是使用共享权限模式安装的(默认),但有writeup指出,RBAC拆分权限部署也很容易受到攻击(我并未亲自测试过)。

Exchange 2010 SP3似乎并未受影响。在我的实验室中,这个版本按类似于以上提及的SMB协商签名,从而打破了这种中继攻击。版本14.3.435.0以及14.3.123.4均展现出这种行为。

资源/参考

可参见如下博客文章、白皮书和研究论文了解关于此类攻击的更多信息:

1. 缓解资源

https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1 

https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf 

ACL权限提升研究

https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors-wp.pdf

2. NTLM中继/签名讨论

NTLM反射型攻击回顾https://github.com/SecureAuthCorp/impacket/issues/451

NTLM SMB-> LDAP中继https://github.com/SecureAuthCorp/impacket/pull/500

中继凭证林总

https://www.secureauth.com/blog/playing-relayed-credentials

3.其它参考

MS-NLMP

https://msdn.microsoft.com/en-us/library/cc236621.aspx

讨论Exchange API的ZDI文章

https://www.zerodayinitiative.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange

通过meterpreter进行NTLM远程中继,讨论如何远程通过枢纽主机进行中继

https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/

ACL攻击相关

https://www.slideshare.net/DirkjanMollema/aclpwn-active-directory-acl-exploitation-with-bloodhound

原文链接

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

*本文作者:360代码卫士;转载请注明来自FreeBuf.COM

在第35届混沌通信大会上 (35C3),今年上大一的 Jonathan Jacobi 发表了题为《从0到 0day》讲述了自己如何从安全基础几乎为零的情况下,用了一年多点的时间在 Edge 浏览器中找到了自己的首个 0day 漏洞。他希望对有志于从事安全事业的新手带来一些帮助,同时希望对学习更多关于浏览器漏洞和利用知识的老手带来一些启发。以下是360代码卫士团队根据他的演讲视频整理的内容:

00.jpg

我是谁?

大家好,我叫 Jonathan,现在18岁,是一名计算机科学和数学专业的学生,对漏洞研究感兴趣,也是微软 MSRC-IL 的一名安全研究员。我也打 CTF 比赛,所在团队是 Perfect Blue。

我在去年才开始接触安全研究,这次演讲的第一部分主要说一下我在一年中都学了什么以及是如何学的;第二部分说一下我是如何从 ChakraCore 中找到第一个 0day 漏洞(JIT类型混淆漏洞)的。可能你刚刚接触安全领域,只知道一些基础的编程知识,但可能你也能听懂。虽然我会讲很多代码,但还好,不是太复杂。最后,我们看下演示。好的,我们开始吧。

知识和实践准备

我为什么要研究漏洞?对我而言,漏洞就像是一个谜,非常具有挑战性的东西。我们必须找到开发人员未考虑到的一些缺陷。至少对我而言这很具有挑战性,也非常有意思。我觉得挖漏洞是个很棒的事情。

那么,什么是漏洞呢?关于漏洞的定义很多。当你想了解某件事的时候,你就会去维基百科上搜索。上面有很多不同的解释,而且有一些看起来很古怪,比如有一个解释是这么说的,“某资产无法抵御威胁攻击动作的可能性”。我不懂它到底说的是什么。我的理解是,漏洞就是程序中出现的各种缺陷,你可以用来改变程序的控制流。这就是我对漏洞的理解,但定义没有告诉我如何找到一个漏洞。

那么,我们怎么才能找到漏洞呢?我当时开始找漏洞时有一些编程基础,我不是写程序最优秀的开发,也就是“还行”的水平,知道C语言、汇编语言,学了一些操作系统内部知识,了解操作系统是会如何运作的,能读一些 python 代码。所以我虽然并不是最优秀的开发,但我具备一些相关知识。比如,我从一本很不错的希伯来语书中了解了一些 C++ 语言的知识,以便我真正地开展漏洞研究。

下一步,我了解了一些漏洞的基础知识,如一些基础的漏洞类型像典型的堆缓冲溢出问题、整数溢出等。之后我就开始通过模拟演习开始实践自己所学的知识。模拟演习是可以在线下解决的安全挑战,这些挑战问题包括找到漏洞并利用它。最开始的时候我败得一塌糊涂,但随着时间的推移,我认为失败了也没关系,因为我看了解决方案、write-up,我知道了如何写解决方案,如何解决问题。所以最开始失败没关系,因为我们每个人都是这样过来的。之后我开始参加 CTF 比赛。

CTF 比赛要求团队作战,这就是我找到团队成员的方式,我们通过 CTF 相识,然后一起打比赛。有时候我们输得很惨,有时候我们打得不错进了决赛,还一起周游世界,因为有时候赛事主办方会支付差旅费,哈哈。我们去了很多很酷的地方,真的很爽。

我认为 CTF 比赛是进入安全领域的一个很好的方式。

之后我决定“潜入深水区”。一旦你了解了基础知识之后,不要在“浅水区”停留太长的时间,这一点很重要,我们要给自己一些挑战。刚开始我害怕失败,但是随着时间的流逝,我想明白了,失败也没什么可怕的。失败后我能找到解决问题的技术。所以我认为这一点很重要:不要害怕失败,即使失败了,我们也能从别人的解决方案中学到东西。

LiveOverflow 发的一条推文说得很好:学到基础后,尽快去做自己不懂的更难的事;不断地接触自己不懂的事情,然后重新来看自以为懂但实际上不懂的事情;然后从各种资源了解信息,学习从多个角度和方向一步步解决问题。

我认为这样做很重要。LiveOverFlow 也有 YouTube 频道,我也在看,讲的是漏洞和安全问题。推荐大家也可以关注他。

我具备一些知识后,通过 CTF 比赛、模拟演示等不断实践、实践、再实践。不断实践、自己解决问题很重要,因为这样你才能知道解决问题的技巧,然后再自己解决遇到的问题。一些漏洞是有特定模式的,要了解这些模式,你就需要多看几次。发现这些模式的一种好方法就是不断解决问题。这也是我为什么喜欢解决真实漏洞问题的原因,很多网站提供不少这样的途径,比如 Project Zero 的 0day 项目,你可以读取一些漏洞信息等。

我还发现CTF 和真实环境中的漏洞之间存在很大的关联,它们同时存在于 CTF 和真实世界中。漏洞实际上就是由 bug引起的。你在真正着手开始进行研究时遇到的最大问题就是代码库过于庞大(因此你可能会头大)。但实际上即使代码框架很庞大,但漏洞还是在具体某处。所以,不要发愁看代码库,因为漏洞很可能就恰好在你开始查看具体的某些代码时出现。之后你可以开始尝试解决问题,即开始了解真正的代码库。

经过一些实践后,我在想我们如何发现漏洞呢?当我们开始真正重复解决问题、实践的过程后,我发现漏洞研究就是关于找到 bug,而我们是通过读代码实现这个目标的。因此,审计代码很重要,因为我们想从中找到漏洞,对吧?而这需要我们真正审计代码,需要实践。因此实践在漏洞研究中起着非常重要的作用。因此我们搞砸了的时候可能就是更接近找到漏洞的时候。因此我认为实践很重要。

那我是如何发现漏洞的?我之前说过漏洞存在模式,而模式是通过时间的积累发现的。但我并没有研究很长的时间,只有短短的一年,那么我是如何发现漏洞的?实际上就是通过不断实践发现的。像我之前说过的那样,多实践能弥补开始晚的问题。我发现漏洞里面有一些模式,比如编程错误像整数溢出或类型混淆问题,这些问题实际上是存在的,因为人总是会犯错的。人类会犯错,我们并不是完美的。下面的代码就是一个很好的例子。

示例1.jpg

第3行有一个整数溢出漏洞。很多开发人员都了解这些漏洞,但仍然可能会犯错。就像我之前说过的,人总会犯错。所以不要惧怕在繁杂的代码框架中去审计代码。这种类型的漏洞实际上是真实的存在于代码框架中,而不仅仅局限于 CTF 比赛,所以,只要不惧怕找漏洞的难度,你就能发现这类简单的漏洞。

CTF 和真实环境中的漏洞之间存在一个很大的不同之处。在 CTF 比赛中,通常当你发现问题时,你就大概知道该怎么处理它、如何去利用它等。比如,遇到溢出问题时,你需要去覆写变量或返回地址等。所以当你在 CTF 比赛中遇到漏洞时,大多数时候你知道怎么处理它,而在真实环境中,你有的只是像 “state(状态)”这样的词,以及一些原语 (premitives),而原语是攻击者具备的一些能力,因此我们需要链接 (chain) 这些原语,做一些影响更大的事情,从而触发更大的漏洞。我在 Chakra 中找到的就是这种漏洞。这些就是我在开始查看 Chakra 之前所了解到的漏洞研究和安全研究知识。

Chakra 0day 相关背景知识

我们说说 JavaScript。先说 JavaScript 引擎。有人会说你之前没说你学过 JavaScript 啊。我确实没说,因为我真的没学过。JS 是一种非常可靠的语言,当你学会一些编程语言后,学习 JavaScript 的过程可能会更顺畅一些。因此,做到这一点应该不会太难。

JavaScript 引擎负责运行开发编写的 JS 代码。它由很多部分组成,对我们而言最重要的是 JIT 编译器,它的作用是当有些函数变得很热门被调用很多次时,它会把这个函数编译成机器代码来改进它的性能。JIT 编译器还负责优化代码。它具有很多针对代码的假设,它不希望这些假设崩溃。我们随后会讲讲 JIT 编译器中出现的相关漏洞问题。

来了解下 JavaScript 的基础知识,它是一种动态输入语言,可读性尚可。JS 对象具有“原型”,用于从其它对象中继承各种功能,它在漏洞发现过程中很重要。它可通过 _proto_ 属性更改对象的原型进行修改。 Proxy 是可用于重新定义基础操作的对象。我们可以通过这些基础操作,将调用限制在 gettersetter 等函数中。

示例2代理.jpg

来看下 ChakraCore。JavaScript 具有数组,而 ChakraCore 具有类型数组。我们来看看第一种类型 JavascriptNativeIntArray。它用于存储整数,每个元素具有四个字节。(举例: varint_arr=[1])另外一种类型是 JavascriptNativeFloatArray,它用于存储浮点数,和C语言不同,它的每个元素具有8个字节(举例 varfloat_arr=[13.37])。 JavascriptArray 用于存储对象(主要是指针),每个元素具有8个字节(举例: varobject_arr=[{}])。

我们来看下如何转换这些类型。

示例3.jpg

示例4.jpg

其中最后一种 (也就是 aray2._proto_=array1 中的 array1 直接转换为 JavascriptArray) 转换在 JavaScript 引擎很少见,但对于我们今天讲的主题很重要。当我们有两个数组,并将其中一个设置为另外一个的原型,那么充当原型的这个数组就会被直接转换为 JavascriptArray。这一点我们稍后再着重讲。

我们再来看看这些数组在内存中是什么样的。举个例子:

示例5.jpg

我们来看看实际在内存中,当调试如下样本代码时,可以看到我们刚才提到的字段状态 (vararr=[0xaaaaaa,0x31377];)。

示例6.jpg

红框部分是 JavascriptArray 属性,我们能看到数组的初始值,也就是 ArrayFlags 的值。绿框部分是实际的片段属性,它有长度、大小。蓝框是片段的内存布局(包括元素,下图的地址是 pArr->head)。图中右下角我们定义了两个片段。那么什么是 ArrayFlags ?它们是提示数组的某些东西的一些 flag。在这个案例中,它被定义为一个枚举类型。我们感兴趣的字段是 JavascriptArrayarrayFlags 字段 HasNoMissingValues(如下图)。

示例7.jpg

在我们的例子中,被我们定义为 ArrayFlagsInitialArrayValue 实际上由两个不同的 flag 组成:一个是 ObjectArrayFlagsTag flag,它和我们讲的内容不重要就不讲了;我们将重点看第二个 HasNoMissingValues flag,它说明数组并不存在缺失的值,也就是说数组中不存在任何洞 (holes)。那么,“洞”是什么意思?我们创建一个数组,元素之间有一些值。在 ChakraCore 案例中,它有三个元素,但中间的一个元素是缺失的。

示例8.jpg

放在这里的值,它们在内存中表示为这些常数。我举这个例子是因为这样我们更容易地能在内存布局中发现它们。

示例9.jpg

像这里(如上图)就存在一个“洞”,它并没有开启 HasNoMissingValues,也就是说数组中存在洞,数组中确实存在缺失的值。这看似很合理,但当我们查看内存布局时,我们会发现一些奇怪之处。我们来看下这些所谓的“缺失的值”是如何在内存中表示的。

示例10.jpg

这(上图)是片段的内存转储,红色部分是数组的元素。我们看到 deadbeef deadbeef ,但在中间即“缺失的值”(“洞”)的位置,我们看到了一些 Magic 常数。 0xfff80002fff80002是从哪里来的?这些常数代表的是“缺失的值”或者说数组中的“洞”似乎能说得通。但如之前所述,我们已经知道有一些东西能代表“缺失的值”,就是没有 HasNoMissingValues flag。而现在我们似乎发现了另外一种表示方法,就是数组的内容(上面提到的 Magic 常量)。

这很奇怪,也引发了很多问题:数组的 flag 和数组的内容不匹配怎么办? HasNoMissingValues 设为真,那么就意味着不存在任何“洞”;但是 数组中实际上存在一个“缺失的值”。另外,我们在某种程度上把“数据”和“元数据”混为一谈了,因为如果把常量当作控制流,那么我们如果能够伪造它的话就很有意思了。

示例11.jpg

事实证明,我们真的能够伪造这个“缺失的值”。这是由 @s0rryMybad 和 @lokihardt 发现的漏洞(如上图),获得了CVE 编号 CVE-2018-8505。他们就是把我们之前看到的常量转换为浮点数数组,从而伪造了“缺失的值”,进而发现了漏洞。缓解这个漏洞的方法有很多,可以通过不断更改这个Magic值常量或增加更多的检查加固安全性。

我们上面讲的是如何能将这些奇怪的状态转变为我们实际上能利用的漏洞。首先我们先来看看一些有意思的东西。之前@s0rryMybad 和 @lokihardt 发现的漏洞是原生的浮点数数组。显然,JavascriptArray 并不直接将浮点数组存储为真正的浮点数,而是这些值被 “boxed”,然后以常量进行 XORed (下图)。

示例12.jpg

那么问题就变成,我们能否在 JavascriptArray 中使用同样的“缺失的值”技巧?如果能的话,那么常数会改变吗?因为我们从上面的例子看到,我们更改了值的代表方式,我们才能表示新的值。从理论上来讲,引擎应当能改变常量,否则我们就可能表示它。

示例13.jpg

而事实上,常量并没有改变,因此我们就能表示它。首先对其进行 boxing,然后通过之前的常量值( 0xfff80002fff80002)对常量进行 XORed( xor(magic,FlatTag_Value))。这样,我们得到的常量还是原始值,因此值就是原始值。当你 XORed 三个元素,其中两个元素是相同的,这样做是不允许的,它会给你原始的值。但如果我们让其中的一个的值是 0xFFFcull<<48,那么我们就能返回 Magic 值表示值。

而正是在这里,我找到了漏洞。我们依靠的是 JavaScript 引擎的基础知识,而boxing 就是我们最先会学到的东西。我们使用 boxing 的想法,利用这种应该不会被利用的状态找到了漏洞。

那么我们是如何把这种奇怪的状态转变为漏洞的?先来看看什么是 JIT 类型混淆漏洞。我们现在常见的 JIT 漏洞是类型混淆。JIT 类型混淆实际上是两种类型的混淆,是指因 JIT 做出了错误的假设而发生的漏洞,最常见的是发生“Side-Effect”,也就是发生了一些 JIT 并未意识到的事情。例如,JITed 函数调用函数 foo(),更改了某些对象比如是数组的类型,而 JITed 函数并不知道转换已发生,使用了数组之前的类型,从而导致 JITed 代码中出现类型混淆情况,从而可能导致 RCE 漏洞的发生。举个例子:(如下图)

示例15.jpg

我如何发现 Chakra 0day?

Loki 和 S0rryMybad 发现 Array.prototype.concat 具有一个有意思的代码路径,它同时考虑了 HasNoMissingValues 和数组元素的值,而两人成功让 HasNoMissingValues 和数组值不匹配。他们成功在数组中伪造一个“缺失的值(以下称为 buggy)”后,以下代码就会触发一个有意思的流:

示例16.jpg

之后,我们看到如下 if 语句:

示例17.jpg

首先我们来看函数 ConcatArgs。这里的 aItem 就是伪造的数组,也就是 buggy。我们想让 isFillFromPrototypes 返回假值,如果 HasNoMissingVlues 已设置如下。

示例18.jpg

isFillFromPrototyps 检查数组只有一个片段,也就是通过检查下一个头部片段是否为空,没有“缺失的值”。它确保长度匹配,也就是数组的长度和片段的长度相等。因此这个片段就是数组中的唯一一个片段。这是它做的第一个检查。它做的第二个检查是 flag 将 HasNoMissingValues 设为真,这一点可被轻松绕过。这样我们就能让 isFillFromPrototypes() 返回假值,然后进入 if 语句。

通过 isFillFromPrototypes() 检查后,我们看到如下的 else 语句,因为我们的数组并非原生数组。

示例19.jpg

如下图, srcArray 就是我们创建的虚假的“缺失的值”数组(也就是我们说的 buggy)。首先让数组本身进行迭代,当且只当没有找到所有的元素时,才在数组的原型上进行迭代。 Enumerator 会枚举数组中的所有的元素。

示例20.jpg

我们看下它是如何实现的。
示例21.jpg

通过 ArrayElementEnumerator 迭代源数组,如果值是“缺失的值( ==0xfff80002fff80002)”,则会跳过该元素。这里发生了什么呢?就是我们每次进入 while 循环时,如果发现是“缺失的值”,则会跳过它。迭代器会跳过缺失的值,所以它的计数和数组中的元素数目不一致。

示例22.jpg

还有一个函数也很有意思。
示例23.jpg

它做的第一件事就是在原型 (prototype) 链之间循环。我们之前说过,原型可以是继承功能的对象。那么我们可以自己创建一个原型、另外一个原型,从而伪造一个原型链。这个函数首先进行循环原型链,然后调用带有 prototype 参数的这个具有很长名字的函数。这个原型是一个 JavaScriptArray,然后我们对其进行循环。

示例24.jpg

所以, ForEachOwnMissingArrayIndexOfObject 为原型链中的每个原型调用了 EnsureNonNativeArray

示例25.jpg

我们来快速回顾一下。如果我们创建一个带有伪造的 MissingValue 的数字,但设置了 HasNoMissingValue flag,那么我们就能得到来自 Array.prototype.concat() 的有意思的代码流。它会循环伪造数组的原型链,并保证这个链中的每个原型都是一个 Non-native 数组(也就是 JavascriptArray)。记住,如果某些对象是另外一个对象的直接原型,那么这个原型就被转换为一个 JavascriptArray。所以,从理论上来讲,如果我们的原型是一个原生数组,那么我们就能将其转换为 JavascriptArray,而 JIT 并不知道这一点,这和我们之前解释过的“平常的” Side-Effect JIT 漏洞类似。

幸运的是,已经存在造成这一后果的技术了!我们可以使用代理限制 GetPrototype() 调用,但如果我们编写函数的话,它会被检测为 side-effectObject.prototype.valueOf 不会产生 Side-Effect,这是 Lokihardt 使用的已知的技术。我们来看个例子。

示例26(1).jpg示例26(2).jpg示例26(3).jpg示例26(4).jpg示例26(5).jpg示例26(6).jpg示例26(7).jpg示例26(8).jpg

要利用这个漏洞,我们首先伪造了一个 DataView 对象,从而能让我们任意读/写。我们的利用代码基于 Pwn.js 库,这是一个很好的库,但我们需要修复一下才能使用。我们通过一种已知技术泄漏了一个栈地址,因而能够通过从 ThreadContext 读取一些数据而获取栈指针。之后,我们 ROP 并恢复我们的覆写,就能获得合法的进程继续。

我们本来打算在 Edge 浏览器上实际执行我们的代码,我们在沙箱环境下执行了代码,它不允许我们弹出计算器等东西。我们无法进行演示。于是我们编译了 Linux 版本的 Chakra,在 Linux 上进行了演示。在 Linux 上利用该漏洞也是类似的。

(注:最后, Jonathan 成功地在 Linux 版本的 Chakra 上进行了演示。接着掌声雷动。

希望我的演讲能给想进入安全领域的人带来一些帮助,同时也给只想听技术部分的观众带来一些帮助。

谢谢大家。

大家怎么说

大一的学生挖掘到价值颇大(天府杯8万美金奖励)的漏洞,我觉得这学生很厉害,膜拜之。从文章可以看出该同学基础扎实、功底深厚,对调试、内存布局、编译、C++、漏洞类型、代码审计等知识的掌握具有一定的深度,所以能够从0到0 day且成功利用漏洞只需要1年的时间。Chakra 的漏洞挖掘难点挺大,该同学的研究思路、研究方法对于漏洞挖掘的学习具有很好的帮助。

看到Magic Value其实算是很熟悉的,在5月份的时候最初看到lokihardt公开的第一个漏洞的时候,很惊讶!因为这个漏洞并不是传统的通过操作回调过程的方式造成的类型混淆,而是通过一个特殊的值。第一时间分析后,很明显的就是代码和数据没有区分。

此时想到三个问题

1.Magic Value是什么?

2.这是一个新的类型混淆漏洞的转化点。

3.为什么引擎中要定义一个Magic Value?

研究过patch之后,发现对StElem指令这块做了检查。也就是(作者提到的使用原生浮点数组)无法直接通过赋值的这种方式在Array中生成Magic Value。

Jacobi 的演讲中也是这样的思路,他举了一个例子说明Magic Value在内存中的样子。初步认识了Magic Value,然后通过其他的方式去伪造一个Magic Value绕过之前补丁的检查,作者通过concat的方式进行了一种实现,发现了一个新的0day。

但我大胆猜测concat是他多次尝试成功的一个方法,这个问题可以抽象成如何生成一个新的包含Magic Value的数组,且不通过直接赋值的方式。类似copywithin,concat,push…等等方法。作者在构造PoC时提到比较多的技巧,比如Object.prototype.valueOf 不会产生 Side-Effect。这都建立在他长期第一时间对这个领域知识的积累上。

这其中的严谨踏实的求真、勤于思考的积累、和清晰完善的思路,都值得去学习。

相比人家的大一,我大一在玩泥巴。

他从验证地方着手找漏洞蛮有借鉴意义的,只要验证少了就可以有问题。

相比找到程序中的缺陷,一步步突破限制将其转化为利用是更难的过程,关键是不轻易放弃。

文章中有一段话感触很深,学到基础后,尽快去做自己不懂的更难的事;不断地接触自己不懂的事情,然后重新来看自以为懂但实际上不懂的事情。从0到0day最重要的是鼓起勇气去挑战自己以为的不可能。梦想多晚都不算晚。

潜入深水区,脱离舒适区,保持初入的学习劲头,通过新的知识,重新审视与加强以往的知识,获得进步;不害怕发愁看代码框架,不断的实践,交流与学习;这种学习研究的思路,对于各个方向都是共通的,要学习实践这种精神,夯实基础,积极参与,努力提升。

死磕到底。

其实很多学习的方法都大同小异,大家都是知道的,Jonathan在一年的时间里能取得这样的成绩,我觉得他的执行力更值得我们学习,确定目标之后就尽情投入,这很让人钦佩。

从0到0day最重要的是鼓起勇气去挑战自己以为的不可能。在有了一定得基础后,不能固步自封,对更深层次的知识望而却步。要保持学习的热情和动力,不断进步,勇往直前。

即便只有基础知识,也敢于去迎接各种挑战,需要莫大的勇气,直面失败,善于利用失败,从失败中学到东西,这种心态和学习方法很值得我们初学者去学习借鉴。

安全涵盖的方面很广,在了解这个专业后,专注自己感兴趣的一方面往里钻。这个学生就是想办法把一件事做到极致,再加上自己本身牢固的基础功底,直到自己佩服自己的地步。对于Jonathan 从安全基础为0,到找到edge浏览器0day漏洞只使用了一年时间,对于我来说,是一种激励,向他学习。

欢迎在留言区分享你的看法~

原文链接

https://media.ccc.de/v/35c3-9657-from_zero_to_zero_day

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM

近日,CNCERT发布了《开源软件代码安全缺陷分析报告——物联网软件专题》。本期报告选取全球20款知名物联网软件进行源代码安全缺陷分析,结合缺陷分析工具和人工审计的结果,评估项目的安全性。360代码卫士团队为本期报告提供了技术支持。

以下是报告全文:

一、概述

随着软件技术飞速发展,开源软件已在全球范围内得到了广泛应用。数据显示,99%的组织在其IT系统中使用了开源软件。开源软件的代码一旦存在安全问题,必将造成广泛、严重的影响。为了解开源软件的安全情况,CNCERT持续对广泛使用的知名开源软件进行源代码安全缺陷分析,并发布季度安全缺陷分析报告。

自2005年国际电信联盟(ITU)正式提出“物联网(IoT)”这一概念以来,物联网在全球范围内迅速获得认可。随着物联网技术的发展创新,大量智能家居和可穿戴设备进入了人们的生活,“万物互联”成为全球网络未来发展的重要方向。根据Gartner报告预测,2020年全球物联网设备数量将高达260亿个。然而,由于安全标准滞后,以及智能设备制造商缺乏安全意识和投入,物联网已经埋下极大隐患,为个人隐私、企业信息安全甚至国家关键基础设施带来严重的安全威胁。

本期报告选取全球20款知名物联网软件进行源代码安全缺陷分析,结合缺陷分析工具和人工审计的结果,评估项目的安全性。从测评结果来看,与往期其他领域开源软件相比,物联网类软件的安全缺陷较多,潜在的安全问题不容忽视。同时,技术人员随机抽取安全缺陷进行人工利用,发现存在能够被证实的安全漏洞,通过漏洞能够获取物联网云端服务器权限,一旦该漏洞被黑客利用,则存在物联网设备被远程操纵的安全风险。

二、被测开源软件

综合考虑用户数量、受关注程度以及更新频率等情况,选取了20款具有代表性的物联网类开源软件。表1列出了本次被测的开源物联网软件项目的概况,项目按照Github上Star的数量降序排列。本次检测的软件涵盖了C、C++、Java、JavaScript(JS)等编程语言。这些开源软件项目都是国际知名的,拥有广泛用户的软件项目,其中不乏由知名软件公司开发的软件。由于这些软件大多具有巨大的用户群体,软件中的安全缺陷很可能会造成严重的后果。

表1 被测开源软件项目概览

项目名称 版本号 主要编程语言 功能说明 代码行数 Github star
Serverless master JS 使用无服务器架构构建Web、移动、物联网应用的框架 20,150 26,124
Node-RED master JS 用于连接物联网的可视化工具 100,840 6,447
JerryScript V1.0 C 用于物联网的超轻量级JavaScript引擎 97,559 3,223
ArduinoJson V5.13.4 C++ 物联网的JSON库 27,583 3,078
POCO V1.9.0 C++ 支持桌面、服务器、移动、物联网、嵌入式系统上的联网应用开发的跨平台的C++函数库 526,721 2,929
CrateDB master Java 一个分布式SQL数据库,可以轻松实时存储和分析大量机器数据 314,984 2,131
ThingsBoard master Java 一个用于数据收集、处理、可视化和设备管理的物联网平台 112,704 1,987
RIOT 2018.10 C 支持常见物联网设备的实时、多线程的操作系统 1,341,539 1,979
Blynk Library V0.5.4 C++ 嵌入式硬件的Blynk库。Blynk是一个物联网应用平台,旨在简化物联网的移动或者Web应用构建。 17,206 1,831
IoT.js master JS 使用JavaScript的物联网平台 42,910 1,826
OpenThread V2.0.0 C++ OpenThread是Thread网络协议的开源实现 661,696 1,713
Blynk Server V0.39.6 Java 基于Netty的Java Server,主要用于在Blynk移动应用和嵌入式设备之间传递消息。 75,555 1,097
Kaa master Java 开源中间件平台,用于构建、管理和集成联网的产品和设备 461,511 984
MySensors V2.3.0 C++ 专注于提供智能居家和物联网的DIY服务 17,788 871
SmartHome master Java 智能家居的灵活框架 801,053 745
OpenIoT develop Java 物联网中间件的基础架构,用于支撑联网设备的数据采集、流量清洗、事件处理算法的灵活配置和部署 269,387 369
Freedomotic V5.6.0 Java 开放物联网框架 259,708 258
Link Kit SDK V2.3.0 C 阿里云物联网套件 56,384 257
SiteWhere master Java 一个面向物联网的工业级开源应用支持平台 216,796 235
IotXmpp master Java 基于XMPP的安卓客户端,实现与物联网节点的交互 130,607 118

三、测试内容

3.1 安全缺陷种类

本次测试涵盖各类常见安全缺陷。根据缺陷形成的原因、被利用的可能性、造成的危害程度和解决的难度等因素进行综合考虑,可以将常见的安全缺陷分为八类:

1、输入验证

输入验证与表示问题通常是由特殊字符、编码和数字表示所引起的,这类问题的发生是由于对输入的信任所造成的。这些问题包括:缓冲区溢出、跨站脚本、SQL注入、命令注入等。

2、API使用

API是调用者与被调用者之间的一个约定,大多数的API误用是由于调用者没有理解约定的目的所造成的。当使用API不当时,也会引发安全问题。

3、安全特性

该类别主要包含认证、访问控制、机密性、密码使用和特权管理等方面的缺陷。

4、并行计算

线程和进程之间的交互及执行任务的时间顺序往往由共享的状态决定,如信号量、变量、文件系统等。与分布式计算相关的缺陷包括竞态条件、阻塞误用等。

5、错误和异常处理

这类缺陷与错误和异常处理有关,最常见的一种缺陷是没有恰当的处理错误(或者没有处理错误)从而导致程序运行意外终止,另一种缺陷是产生的错误给潜在的攻击者提供了过多信息。

6、代码质量

低劣的代码质量会导致不可预测的行为。对于攻击者而言,低劣的代码使他们可以以意想不到的方式威胁系统。常见的该类别缺陷包括死代码、空指针解引用、资源泄漏等。

7、封装和隐藏

合理的封装意味着区分校验过和未经检验的数据,区分不同用户的数据,或区分用户能看到和不能看到的数据等。常见的缺陷包括隐藏域、信息泄漏、跨站请求伪造等。

8、代码运行环境

该类缺陷是源代码之外的问题,例如运行环境配置问题、敏感信息管理问题等,它们对产品的安全仍然是至关重要的。

前七类缺陷与源代码中的安全缺陷相关,它们可以成为恶意攻击的目标,一旦被利用会造成信息泄露、权限提升、命令执行等严重后果。最后一类缺陷描述实际代码之外的安全问题,它们容易造成软件的运行异常、数据丢失等严重问题。

3.2 安全缺陷级别

我们将源代码的安全问题分为三种级别:高危(High)、中等(Medium)和低(Low)。衡量级别的标准包括两个维度,置信程度(confidence)和严重程度(severity)。置信程度是指发现的问题是否准确的可能性,比如将每个strcpy()调用都标记成缓冲区溢出缺陷的可信程度很低。严重程度是指假设测试技术真实可信的情况下检出问题的严重性,比如缓冲区溢出(buffer overflow)通常是比空指针引用(null pointer dereference)更严重的安全问题。将这两个因素综合起来可以准确的为安全问题划分级别,如图1所示。

IoT 报告图片1.png

图1 缺陷级别与严重程度、置信程度的关系

四、开源物联网软件项目的安全缺陷情况

本部分首先展示从被测项目中检出安全缺陷的数量,由此对被测项目的安全性进行大致的评估。然后进一步讨论被测项目中安全缺陷的分布情况,了解项目中出现较多的、容易被忽略的安全问题。

4.1 安全缺陷情况概览

本部分展示被测项目查出缺陷的数量,由此对被测项目的安全性进行大致的评估。图2分别展示了项目不同级别缺陷的数量,并按照高危缺陷数量对项目进行了排序,图中用蓝色折线图展示了每千行代码包含缺陷数,红色折线图为项目在Github上的star的数量。

IoT 2.jpg

图2 开源软件项目缺陷情况

从中可以看出,本次选取的物联网类开源软件都存在不同程度的安全问题。本次检测从这些项目中总计发现高危缺陷667个,中危缺陷3702个。缺陷数量排名靠前的项目处于极易被攻击者利用的状态,实际使用者需通过安装补丁或者更新版本的方式进行修复和升级。

在所有被测软件中,物联网应用平台Blynk的函数库Blynk Library的安全性最高(无高危缺陷,有3个中危缺陷)。物联网应用框架Serverless、物联网开发JS平台IoT.js、物联网实时操作系统RIOT的缺陷总数较少,总体安全性较高。

物联网中间件基础架构平台OpenIoT在本次被测的20款软件里高危缺陷居多,包含370个高危缺陷和669个中危缺陷。其中,包括556个输入验证类缺陷,其中283个缺陷为跨站脚本问题(高危),344处资源未释放问题(中危),提示该项目应加强对安全缺陷的管理,特别是加强对来自信任边界之外的用户输入的过滤和验证;同时,应进一步提升代码质量,避免攻击者利用资源泄露的问题发起拒绝服务攻击。

中高危缺陷总数最多的是联网应用开发函数库POCO,包含1个高危缺陷,和1380个中危缺陷。其中,项目被检测出748处“将比特位数不同的操作数进行位运算”、300处“使用了不安全的内存拷贝函数”、234处“在对字符类型比较时未明确其符号属性”问题。这些问题会降低程序的稳定性和可移植性,可能会导致程序发生非预期的行为,同时也增加了安全隐患。建议项目的开发者提升安全意识,可在开发过程中使用代码缺陷扫描工具提升代码质量和安全性。

考虑到项目的绝对缺陷数量可能与项目大小相关,因此本报告计算了每千行缺陷数,用该数据反映缺陷在项目中的分布密度。根据该数据,物联网实时操作系统RIOT每千行缺陷数仅为0.002,平均每10万行代码出现1个以下的中高危缺陷,为本次被测软件中安全缺陷密度最低的被测项目。此外,代码安全缺陷密度较低的项目有物联网应用框架Serverless、物联网开发JS平台IoT.js,这些项目平均每一万行代码出现1个以下的中高危缺陷。安全缺陷分布密度相对较高的项目是物联网DIY工具MySensors(6.97)、物联网中间件基础架构平台OpenIoT(3.79)、物联网的JS引擎JerryScript(3.53),这些项目平均每一千行代码中就会出现数个中高危缺陷。

4.2 高危安全缺陷分布情况

本部分对高危缺陷的分布情况进行分析说明。图3展示了被测项目高危缺陷大类的分布情况。数据表明,绝大多数缺陷为“输入验证”类缺陷,该类缺陷主要是由于对用户输入未做充分验证导致的,易造成缓冲区溢出、路径遍历、跨站脚本及各类注入缺陷,一旦攻击者构造恶意输入,可能造成任意命令执行、任意文件读取等严重安全问题。

IoT 3.jpg

图3 被测项目中高危安全缺陷的分布情况(按大类划分)

图4进一步展示了被测项目中各种具体的高危安全缺陷的分布情况。为方便展示,将出现不超过10次的缺陷统一归入“其他”,主要包括越界访问(9个)、硬编码密码(6个)等问题。在被测的20个项目中,出现较多的几类具体缺陷依次是跨站脚本(488个)、路径遍历(76个)和SQL注入(53个)。由于本期被测软件主要为物联网应用开发框架,提供物联网服务器端服务,这些缺陷将极大的提升服务器被攻击者获取控制权的风险,从而导致物联网设备被恶意操控、用户个人隐私泄露的风险。

IoT 4.png

图4 被测项目中高危安全缺陷的分布情况(按具体缺陷划分)

4.3 安全缺陷总体分布情况

上文针对被测项目中的高危缺陷的检出情况对项目的安全状况进行了分析。通常来说,与高危缺陷相比,中危缺陷在实际运行环境中的危害相对较小,但仍不容忽视,且能在一定程度上反映出项目的代码质量、开发人员对代码安全问题的重视程度等。为了更全面的了解被测项目的安全状况,本节进一步展示包括中危缺陷在内的安全缺陷的总体分布情况。

图5展示了被测项目中安全缺陷大类的分布情况。与高危级别的缺陷分布情况相比,代码质量类、API使用类缺陷占比大幅提升。项目中存在大量的“不当的位运算”、“不当的字符比较”、“资源未释放”、“使用不安全的函数”等问题,集中反映出开发者的不良编程习惯。与输入验证类问题相比,这类问题被攻击者利用的门槛相对较高,但一旦被利用,仍然会发生拒绝服务、执行任意命令等严重风险。

IoT 5.jpg

图5 被测项目中的中高危安全缺陷的分布情况(按大类划分)

表2进一步展示了被测项目中的各种具体的中高危安全缺陷的分布情况。由于本次被检测出的缺陷数量较大,共出现了85种中高危缺陷,为方便阅读,仅在表中列出出现50次以上的缺陷种类。

表2 被测项目中的中高危安全缺陷的分布情况

(按具体安全缺陷种类划分)

中高危缺陷种类 出现频次
将比特位数不同的操作数进行位运算 1,076
跨站脚本 571
资源未释放 562
不安全的内存拷贝函数 352
不当的字符类型比较 256
空指针解引用 157
不安全的字符串处理函数 132
路径遍历 98
SQL注入 97
Servlet的线程安全问题 90
XML外部实体注入 90
隐私泄漏 63
不当的格式化字符串 62
硬编码密码 53
未经检查的循环条件 52

五、本年度项目安全横向对比

本部分将本期被测的物联网类软件项目与本年度往期被测的人工智能类、开发框架类软件从平均每千行缺陷数的角度进行了横向对比。

IoT 6.jpg

图6 2018年度不同领域被测软件每千行缺陷数对比

如图6所示,物联网类的软件安全缺陷密度较高,从某种程度上反应出智能设备制造商的安全意识相对薄弱,提示物联网类开发者应加强对代码安全性的重视,并切实采取手段提升软件安全性。

六、缺陷验证情况

对于本次检测出的安全缺陷,报告编制组随机抽取缺陷进行人工利用,发现存在能够被证实的安全漏洞,本部分以Blynk Server路径遍历漏洞为例进行说明。Blynk Server是物联网服务器端组件,主要用于在Blynk移动应用和嵌入式设备之间传递消息。

IoT 7.jpg

图7 Blynk Server(版本0.39.6)路径遍历漏洞获取文件截图

图7展示了存在问题的代码片段,代码直接读取用户输入的URI(188行),未做任何验证和过滤就直接进行文件读取(210行),使得用户可通过“../”实现对服务器文件系统的路径遍历,从而可以获取任意文件内容。例如,如图8所示,通过URL“/static/js/../../../../../../../../etc/passwd”即可获得系统账户文件等敏感内容。由于Blynk Server主要用于在移动应用与物联网设备的微控制面板之间传递消息,因此一旦攻击者获取了服务器权限,将能够截获所有来自物联网设备的消息,从而导致物联网设备所有者的个人隐私泄露问题;此外,攻击者也能够通过篡改、操控发送至物联网设备的指令,实现对物联网设备的远程操控。

该漏洞得到了Blynk Server开发者确认,并获得了CVE确认(CVE-2018-17785),该漏洞在0.39.13及之后的版本中得到修复。建议软件的使用者尽快更新到最新版本,以避免不必要的安全风险。

IoT 8.jpg

图8 Blynk Server(版本0.39.6)路径遍历漏洞获取文件截图

七、关于本报告的说明

本报告仅从代码角度进行缺陷分析。本报告中统计的缺陷是指由于代码编写不规范导致的有可能被攻击者利用的安全隐患。在实际系统中,由于软件实际部署环境、安全设备等的限制,部分缺陷可能无法通过渗透测试得到验证。

本报告中的缺陷仅适用于表1中列出的特定软件版本。当软件版本有任何更新、修改和优化时,本报告不再适用。

本报告由360代码卫士团队提供部分技术支持。

*本文作者:360代码卫士,转载请注明来自 FreeBuf.COM

近期,360企业安全集团代码卫士团队安全研究人员发现 Oracle 公司旗下产品 Oracle WebLogic Server 的多个安全漏洞(CVE-2019-2398,CVE-2019-2452),并多次第一时间向Oracle公司报告,协助其修复漏洞。

Oracle WebLogic Server 是目前全球 J2EE 使用最广泛的商业应用中间件之一。北京时间2019年1月16日,Oracle 公司发布了关键补丁更新公告 (Oracle Critical Patch Update Advisory – January 2019),公开致谢360企业安全集团代码卫士团队,并授予团队研究人员“安全纵深防御计划贡献者 (Security-In-Depth Contributor)”的称号,且发布相应的补丁修复漏洞。

“安全纵深防御”计划是 Oracle 公司在2008年7月发布的“关键补丁更新”中推出的。如果研究人员提供的与安全漏洞相关的信息、意见或建议促使Oracle 代码或文档的未来版本进行重大修改但其严重程度尚不足以导致在“重要补丁更新”中发布这些修改,则会授予研究人员该称号。目前仅有为数不多的中国安全研究员获此殊荣。

Image16_01_2019_001.png

图 Oracle公司官方公告

ack1.png                                                               图 致谢360代码卫士

蓝信图片_0880c08b0110ddaa8e02.png

图 被授予 “安全纵深防御计划贡献者” 称号

本次Oracle公司本次修复的漏洞中,CVE-2019-2398 和 CVE-2019-2452影响多个WebLogic大版本(10.3.6.0、12.1.3.0、12.2.1.3等),由于系统在对文件操作校验存在缺陷。在一定条件下,成功利用此漏洞的攻击者可以达到目标系统的远程代码执行。建议用户及时更新补丁进行修复。

参考链接

Oracle Critical Patch Update Advisory – January 2019

(https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html)

关于 360 代码卫士

“360代码卫士”是360企业安全集团旗下专注于软件源代码安全的产品线,能力涵盖了源代码缺陷检测、源代码合规检测、源代码溯源检测三大方向,分别解决软件开发过程中的安全缺陷和漏洞问题、代码编写的合规性问题、开源代码安全管控问题。“360代码卫士”系列产品可支持Windows、Linux、Android、Apple iOS、IBM AIX等平台上的源代码安全分析,支持的编程语言涵盖C、C++、C#、Objective-C、Java、JSP、JavaScript、PHP、Python、Go、区块链智能合约Solidity等。目前360代码卫士已应用于上百家大型机构,帮助用户构建自身的代码安全保障体系,消减软件代码安全隐患。

福利

360代码安全实验室正在寻找漏洞挖掘安全研究员,针对常见操作系统、应用软件、网络设备、智能联网设备等进行安全研究、漏洞挖掘。

360代码安全实验室是360代码卫士的研究团队,专门从事源代码、二进制漏洞挖掘和分析的研究团队,主要研究方向包括:Windows/Linux/MacOS 操作系统、应用软件、开源软件、网络设备、IoT设备等。团队成员既有二进制漏洞挖掘高手,微软全球 TOP100 贡献白帽子,Pwn2Own 2017 冠军队员,又有开源软件安全大拿,人工智能安全专家。实验室安全团队的研究成果获得微软、Adobe、思科、Oracle、Linux 等各种开源组织等60多次致谢。

如果你:

  • 对从事漏洞研究工作充满热情

  • 熟悉操作系统原理,熟悉反汇编,逆向分析能力较强

  • 了解常见编程语言,具有一定的代码阅读能力

  • 熟悉 Fuzzing 技术及常见漏洞挖掘工具

  • 挖掘过系统软件、网络设备等漏洞者(有cve编号)优先

  • 具有漏洞挖掘工具开发经验者优先

那么,你将得到:

  • 白花花的银子——月薪20K-60K+年底双薪+项目奖,优秀者还有股票期权哦

  • 暖心的福利——六险一金+各种补贴+下午茶+节假日礼品

  • 重点重点重点——志同道合、暖心的我们

心动不如行动!无论你是经验丰富的大咖儿,还是志向从事安全研究的菜鸟儿,不要犹豫!

赶紧给 [email protected] 投简历吧!我会在3个工作日内找到你~


扫一扫,关注更多技术干货和热门资讯

qrcode_for_gh_bba053bd7494_1280.jpg

前言

代码审计是使用静态分析发现源代码中安全缺陷的方法,能够辅助开发或测试人员在软件上线前较为全面地了解其安全问题,防患于未然,因此一直以来都是学术界和产业界研究的热点,并且已经成为安全开发生命周期SDL和DevSecOps等保障体系的重要技术手段。

360代码卫士团队基于自主研发的国内首款源代码安全检测商用工具,以及十余年漏洞技术研究的积累,推出“缺陷周话”系列栏目。每周针对CWE、OWASP等标准中的一类缺陷,结合实例和工具使用进行详细介绍,旨在为广大开发和安全人员提供代码审计的基础性标准化教程。

阅读前7期【缺陷周话】:

《缺陷周话》第1期:空指针解引用:https://www.freebuf.com/articles/rookie/183889.html

《缺陷周话》第2期:SQL注入:https://www.freebuf.com/news/184732.html

《缺陷周话》第3期:内存泄漏:https://www.freebuf.com/articles/rookie/185356.html

《缺陷周话》第4期:XML外部实体注入:https://www.freebuf.com/vuls/186054.html

《缺陷周话》第5期:越界访问:https://www.freebuf.com/articles/rookie/186749.html

《缺陷周话》第6期:命令注入:http://www.freebuf.com/rookie/187316.html

《缺陷周话》第7期:缓冲区上溢:https://www.freebuf.com/articles/rookie/187891.html

一、路径遍历

路径遍历是指应用程序接收了未经合理校验的用户参数用于进行与文件读取查看相关操作,而该参数包含了特殊的字符(例如“..”和“/”),使用了这类特殊字符可以摆脱受保护的限制,越权访问一些受保护的文件、目录或者覆盖敏感数据。本文以JAVA 语言源代码为例,分析路径遍历缺陷及该缺陷产生的原因及修复方法。详见: CWE ID 22: Improper Limitation ofa Pathname to a Restricted Directory (‘Path Traversal’) (http://cwe.mitre.org/data/definitions/22.html)、CWEID 23: Relative Path Traversal (http://cwe.mitre.org/data/definitions/23.html)、CWEID 36: Absolute Path Traversal (http://cwe.mitre.org/data/definitions/36.html) 和 CWE ID 73: External Control of File Name or Path (http://cwe.mitre.org/data/definitions/73.html)。

二、 路径遍历的危害

路径遍历利用应用程序的特殊符号(“~/”,“../”)可以进行目录回溯,从而使攻击者越权访问或者覆盖敏感数据,如网站的配置文件、系统的核心文件等。从2018年1月至11月,CVE中共有388条漏洞信息与其相关。部分漏洞如下:

CVE 漏洞概述
CVE-2018-1656 IBM Java Runtime Environment 的 Java 诊断工具框架(DTFJ) (IBM SDK,Java Technology Edition 6.0,7.0和8.0)在提取压缩转储文件时不能防止路径遍历攻击。
CVE-2018-1999020 Open Networking Foundation(ONF)ONOS 版本 1.13.2 及更早版本包含 core / common / src / main / java / org / onosproject / common / app / ApplicationArchive.java 第35行中的 Directory Traversal 漏洞,可能导致任意文件删除(覆盖)。这种攻击似乎可以通过特制的 zip 文件进行上传。
CVE-2018-14371 在2.3.7之前的 Eclipse Mojarra 中的 ResourceManager.java 中的 getLocalePrefix 函数受 Directory Traversal 通过 loc 参数的影响。远程攻击者可以从应用程序下载配置文件或 Java 字节码。
CVE-2018-1000194 Jenkins 2.120 及更早版本,LTS 2.107.2 及更早版本的 FilePath.java 中存在路径遍历漏洞,SoloFilePathFilter.java 允许恶意代理在 Jenkins 主服务器上读写任意文件,绕过代理到主安全子系统保护。

三、示例代码

示例源于 Samate Juliet Test Suite for Java v1.3 https://samate.nist.gov/SARD/testsuite.php),源文件名:CWE23_Relative_Path_Traversal__Environment_41.java。

3.1 缺陷代码

缺陷代码

缺陷代码

上述示例代码在第112行获取了环境变量的值 data ,第44行创建了一个 File 对象,构造函数的参数是传入的环境变量的值 data ,接收参数后未对参数做合理校验,当环境变量的值为 “../file.bat” ,假定文件路径有效,则可能导致读取了 uploads 父目录下的 file.bat 文件。

使用360代码卫士对上述示例代码进行检测,可以检出“路径遍历”缺陷,显示等级为高。如图1所示:

图1:路径遍历检测示例

图1:路径遍历检测示例

3.2 修复代码

修复代码

在上述修复代码中,在调用 badSink() 函数之前,我们对传入的参数进行处理。在第112行中,获取到环境变量并赋值给 data,这时使用正则表达式过滤掉特殊字符 ”/\” : | * ? < >”,当再调用 badSinks() 函数时,即使 data 的值为 “../file.bat”,在经过过滤后则为 ”..file.bat”,始终保持了可以被访问的文件在 “C:\uploads\” 下,这样就避免了路径遍历的发生。

使用360代码卫士对修复后的代码进行检测,可以看到已不存在“路径遍历”缺陷。如图2:

图2:修复后检测结果

图2:修复后检测结果

四、如何避免路径遍历

要避免路径遍历,需要注意以下几点:

(1)程序对非受信的用户输入数据净化,对网站用户提交过来的文件名进行硬编码或者统一编码,过滤非法字符。

(2)对文件后缀进行白名单控制,对包含了恶意的符号或者空字节进行拒绝。

(3)合理配置 web 服务器的目录权限。

*本文作者:360代码卫士,转载请注明来自FreeBuf.COM