热点概要：美国黑帽大会上披露Cisco Autonomic Networking漏洞、维基解密公布CIA开发的针对MacOS和linux系统的黑客工具、Black Hat USA 2017 议题PPT下载(部分)、CVE-2017-5698 (Intel AMT) exploit、看雪CTF2017学习记录整理系列5

资讯类：

维基解密公布CIA开发的针对MacOS和Linux系统的黑客工具

http://thehackernews.com/2017/07/linux-macos-hacking-tools.html

美国黑帽大会上披露Cisco Autonomic Networking漏洞

http://www.securityweek.com/unpatched-cisco-autonomic-networking-flaws-disclosed-black-hat

WiFi渗透测试电子书

https://rootsh3ll.com/product/kali-linux-wireless-pentesting-security-ebook/

Cracking the Lens：针对HTTP的隐藏攻击面

http://blog.portswigger.net/2017/07/cracking-lens-targeting-https-hidden.html

Awesome Web Security

https://github.com/qazbnm456/awesome-web-security

Black Hat USA 2017 议题PPT下载(部分)

https://www.blackhat.com/us-17/briefings.html

CVE-2017-8464：LNK Remote Code Execution Vulnerability，python exp

https://github.com/nixawk/labs/blob/master/CVE-2017-8464/exploit_CVE-2017-8464.py

Web cache deception Attack

https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack-wp.pdf

Morten Schenk在Black Hat 2017披露windows 10 内核利用

https://github.com/MortenSchenk/BHUSA2017/blob/master/us-17-Schenk-Taking-Windows-10-Kernel-Exploitation-To-The-Next-Level%E2%80%93Leveraging-Write-What-Where-Vulnerabilities-In-Creators-Update-wp.pdf

跨站点请求伪造（CSRF）你必须要知道的知识点

https://www.darknet.org.uk/2017/07/all-you-need-to-know-about-cross-site-request-forgery-csrf/

CLR-Injection

https://github.com/3gstudent/CLR-Injection

BlueSpoof：跨平台magstripe欺骗工具

https://salmg.net/2017/06/13/bluespoof/

A New Era of SSRF-Exploiting URL Parser in Trending Programming Languages!

https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

攻击用户Docker容器隐藏、权限维持、植入恶意软件

https://threatpost.com/attack-uses-docker-containers-to-hide-persist-plant-malware/126992/

CVE-2017-5698 (Intel AMT) exploit

https://github.com/embedi/amt_auth_bypass_poc

Supervisor Authenticated远程代码执行漏洞

https://blogs.securiteam.com/index.php/archives/3348

阿里云安骑士 webshell规则逆向

https://mp.weixin.qq.com/s?__biz=MzI4NjYwMTQ1Ng==&mid=2247483697&idx=1&sn=f36f1420fe39f51ca648e1de5b5431b2

腾讯云 webshell检测规则逆向

https://mp.weixin.qq.com/s?__biz=MzI4NjYwMTQ1Ng==&mid=2247483708&idx=1&sn=e8548a85d75584cc93fd2379f591c634

Docker Security最佳实践电子书

https://www.sqreen.io/resources/docker-security-best-practices

Metasploit for Machine Learning: Deep-Pwning

https://n0where.net/metasploit-for-machine-learning-deep-pwning/

看雪CTF2017学习记录整理系列5

https://weiyiling.cn/one/pediy_ctf2017-5

作者：myles007

预估稿费：300RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、利用过程

1.1 利用背景

我们在渗透的过程中常常会遇到这种场景：我们已经通过web渗透拿下一台内网服务器，为了进一步进行内网渗透，我们会利用“沦陷主机”作为跳板进行进一步的内网渗透，而内网渗透的思路和方法可能很多，但是使用起来并不是很方便，可能会需要很庞大的工具箱的支持，具体内容这里不做展开说明。

我们现在假设的场景是，此时我们已经拿下一台内网服务器的远程桌面环境，在进行内网渗透时，发现内网有大量存MS17-010的漏洞主机，如果我们想拿下这些主机，可能就要动用NSA工具箱，但是此工具箱的使用相当的麻烦，此时我们第一时间想起的一定是神器Metasploit，其是进行内网渗透的一把利器，且使用方便，但是我们同样不能将这么大的一个框架部署到“沦陷的主机”上吧。那么问题来了，我们有没有好的办法直接使用我们外网已经搭建好的MSF框架呢？这里提供大家一个思路，我们是不是可以利用“沦陷主机”作为跳板，来实现使用MSF框架直接对内网主机的直接渗透呢？答案是当然的，MSF框架为我们提供了一个很好功能跳板版能模块，此模块可以为我们添加一条转发路由去往内网，具体内容会在下面的文档中为大家揭晓。

1.2 利用场景拓扑

1.3 利用场景思路

本篇文档，我们使用的方法和思路，就是结合powershell ps1 攻击载荷来在“沦陷主机”上直接反弹回一个session会话，然后利用此session会话作为MSF访问内网的跳板（即路由的下一跳（nexthop）网关），从而来实现MSF直接对内网主机资源的直接访问。

利用条件：

(1)已经拿下的webshell 的 windows服务器；

(2)powershell ps1会话反弹

(3)MSF跳板路由添加

二、利用过程分析

如果想要利用MSF攻击平台直接对内网其他主机进行渗透攻击，那么我们的MSF平台需要要有去往“目标内网的路由”，但是我们知道“目标内网服务器”除了对外服务的服务器我们可以直接访问，其实内网其他主机都是私有IP,无法由互联网直接访问的，这时我就需要在MSF平台添加一条路由去往内网，而MSF平台就有这个“路由转发的功能”，而且这一去往内网路由的下一跳就是建立在MSF平台与“目标主机”之间session会话上的。所以，我们在使用MSF路由转发功能时，首先就是要先建立一个“MSF平台”与“目标主机”的session会话。

因为笔者前面已经说过直接产生dll 反弹shell的方法，这里就在学习与记录下反弹powershell ps1的shell反弹过程。

2.1.1 使用MSF生成一个反弹的 ps1的shell

反弹shell生成语句如下:

注：可能会有小伙伴会问，为什么不直接使用MSF生产一个反弹shell就好了，说的没错直接使用MSF生产一个反弹shell也是可以的，只是可能如果服务器上有相关的杀软的话，可能就会被干掉，我这里直接使用这一刚刚暴露出的漏洞其有很好的过杀软的作用，且其可用利用系统访问范围几乎是全覆盖的，同时本人是想把此漏洞的实战利用价值和思维也带给大家。

2.1.2 上传search.ps1到目标主机

生成完ps1 shell后，想办法将search.ps1上传到目标服务器，为下一步漏洞的触发调用做好准备，这里笔者就直上传了到服务器桌面。

注：可能有很多小伙伴看过网上的教程，对此有些疑问，网上给出的使用方法，一般是将这shell脚本通过web服务发布到网上，然后利用用户点击快捷方式的时候触发shell下载，然后执行shell获取一个shell反弹。

我这里的实际环境是，我们已经获取了目标站点的shell,可以直接上传这个shell，然后让然漏洞利用直接在本地执行，无需再去网络上下载。

2.1.3 本地生成一个powershell 本地快捷方式

首先，输入快捷方式调用的对象位置，具体的powershell 本地调用方式的语句如下：

随后，我将这个powershell快捷方式命名为poweshell.exe。

2.1.4 开启MSF本地监听

在LNK漏洞环境都准备完毕后，接下就是开启远端的监听了，等待漏洞触发反弹出一个shell出来，具体MSF开启端口监听的命令如下。

2.1.5 主动触发漏洞获取反弹shell

MSF监听已经开了，反弹shell也已经上传，现在我们只要主动触发shell反弹即可。即，我们只要双击桌面快捷方式，即可反弹出一个shell到远端的MSF监听，我很快就可以看到MSF的会话监听已经打开，shell已经反弹成功，成功获取一个MSF与目标主机的session会话。

再次解惑：

可能前面我们做了这么多工作，还是有小伙伴并不清楚我们要做什么，可能还回吐槽说我们都已经获取目标主机的控制权限了，还要创建个MSF的session会有啥意义呢？

其实我们回到文档的开头，回到标题我们可能就会知道我们为什么要获取一个“目标主机与MSF的session会话”了，我创建这个session就是为了能使用MSF这个框架对内网的其他主机做进一步的渗透了，有个这个session,我们的外网MSF攻击平台就能利用这个session帮助我们与内网主机的通信提供数据路由转发,下面一个节会详细给大家介绍有关MSF路由添加功能的实现。

2.2 MSF跳板功能

2.2.1 基本概念

MSF的跳板功能，其实是MSF框架中自带的一个路由转发功能，其实现过程就是MSF框架在已经获取的meterpreter shell的基础上添加一条去往“内网”的路由，此路由的下一跳转发，即网关是MSF攻击平台与被攻击目标建立的一个session会话，具体理解大家可以看见前面的1.2章节的拓扑图。

通过msf添加路由功能，可以直接使用msf去访问原本不能直接访问的内网资源，只要路由可达了那么我们使用msf的强大功能，想干什么就干什么了。

2.2.2 msf 跳板实现过程

2.2.2.1 基本过程

（1）需要有一个已经获取的meterpreter 会话；

（2）获取内网地址网段

（3）在MSF平台上添加去往“内网网段”的路由

2.2.2.2 实现过程

（1） 已经获取一个meterpreter shell

第1个条件，是我们要想办法获取一个MSF攻击平台与目标主机的shell会话（meterpreter）,然后利用此会话。具体获取meterpreter会话的方法很多，本演示案列中是以powershell ps1 反弹一个会话为演示，具体内容请见后面复现过程。

MSF 路由添加帮助查询命令如下：

（2）获取目标内网地址段

具体获取被攻击目标内网地址网段的命令如下所示：

由上可以获知，目标内网网段是“172.17.0.0./24”

（3）添加去往目标网段的转发路由

在meterpreter 会话上直接添加去往目标网段的路由，具体添加方法如下所示。

注：由以上内容，我们可以看到出添加了一条路由：

目标：172.17.0.0 掩码：255.255.25.0 下一跳网关：Session 3

这里的 Session 3，即当前被攻击目标主机与MSF平台建立的meterperter会话。

OK, MSF平台有了去往内网网段的路由，我们就可以直接使用MSF平台对内网的主机进行进一步的渗透利用了。

三、案列场景复现

3.0 复现场景拓扑

（1）MSF平台：192.168.10.109

（2）目标主机：10.48.8.234

（3）目标网段：10.48.8.0/24

具体复现的场景，就是1.2章节网络环境拓扑。

3.1 打开MSF本地监听

为了接受目标主机反弹回来的meterperter shell，我们需要首先打开一个MSF本地监听端口，等待会话的反弹，具体操作过程如下。

3.2 使用powershell ps1 获取一个meterpreter

3.2.1 生成 powershell ps1攻击载荷

此时我们已经获取了目标主机的windows控制权限，接下来我们直接使用MSF生成一个ps1反弹shell;

3.2.2 上传反弹shell到目标主机

在生成反弹shell后，我们就是直接上传search.ps1 攻击载荷到目标主机。

3.2.3 触发 powershell 反弹shell

利用上传的search.ps1 攻击payload,在目标主机上生成一个powershell 本地快捷方式，然后点击快捷方式触发powershell ps1利用，反弹一个shell会话到MSF平台。有关poershell ps1 快捷方式的语句如下所示（具体详细使用情况可参见章节：2.1.3）。

注：直接复制上面的语句到创建快捷方式的“请键入对象的位置”即可，但是各位自操作时，请注意serach.ps1的物理位置，不要搞错。

3.3 获取内网网段信息

在MSF平台监听端，我们获取反弹的shell后（即session），我们可以直接在meterpreter控制终端进行目标网段信息的查询，具体查询命令如下。

通过内网本地路由查询，可以获悉内网网段地址为：10.48.8.0/24

3.4 添加目标网段路由

我们在获知目标内网网段路由为10.48.8.0/24后，接下来就是添加去往目标内网网段（10.48.8.0/24）的静态路由，添加路由的具体命令执行如下。

我们将去往内网的路由打通后，接下来就可以使用MSF平台直接对内网主机扫描和进行各种高危漏洞的直接渗透利用了。

3.5.1 退到后台

首先我们需要退到MSF攻击平台的操作面，为后面调用其他攻击模块做好准备，具体操作如下。

通过目标主机，我们可以直接使用MSF下的扫描模块进行主机发现与扫描，这里我们直接使用最近流行的“永恒之蓝”漏洞扫描模块进行网络主机漏洞扫描。

通过主机漏洞扫描，我们发现10.48.8.236主机存在一个MS17-010漏洞。

3.5.3 调用攻击载荷

通过目标主机我们扫描发现内网有台主机存在MS17-010漏洞（10.48.8.236),我们现在直接使用使用MSF平台调通“永恒之蓝”漏洞攻击载荷，进行攻击获取主机控制权限，操作过程如下。

自此我们使用 "MSF 的跳转路由转发"，直接使用外网的MSF平台实现对内网私有主机的攻击演示结束，好了打完收工，各位看客有钱的捧个钱场，没钱的捧个人场，开个玩笑。

注：以上内容仅为个人学习所用，请勿用于非法攻击。

学习参考

http://www.metasploit.cn/thread-1644-1-1.html

http://www.91ri.org/9560.html

作者：興趣使然的小胃

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、简介

二、暴力破解子域名

传统意义上，在暴力破解子域名方面，大多数黑客会使用诸如Sublist3r、knockpy或者enumall之类的工具，配合字典来暴破目标域名。这种方法适用于大多数应用场景，然而，我认为我们可以适当改造这种方法，以发挥其全部潜能。最初的暴破过程结束后，一旦我们确定了公司的子域名信息，那么接下来我们应该递归暴破目标公司所使用的具体环境。比如，如果某个公司具有“dashboard.dev.hackme.tld”这个子域名，那么我们应该根据这个信息，继续查找隐藏在“dev”环境之后的更多子域名。通过这种方式，我们有可能绕过目标实际生产环境中的限制，获取目标其他属性信息。

如果目标公司的内部资产隐藏于企业或内部子域名后（如tools.corp.hackme.tld或tools.internal.hackme.tld），我们也可以通过这种方法来枚举公司的内部资产。对corp/internal.hacketwo.com进行暴破后，我们可以枚举出更多属性信息，以扩展我们的攻击面。

三、巧用Github

Github同时还是寻找凭证及私有API密钥的理想之地。在搜索不同密钥的过程中，最难的一点是我们必须具备创新精神。抛砖引玉，我在Github上通常会搜索如下关键词：

我们也可以在Github上搜索与子域名有关的更多信息及开放接口。我曾在Github上通过搜索“api.hackme.tld”，找到过目标企业过去遗留的API接口，而这个接口信息可以追溯到几年之前。我们可以借助大量工具，自动化完成这项工作，充分节省搜索时间。但通常情况下，我个人喜欢手动完成这个过程，因为即使直接搜索那些关键词所得到的结果没有价值，我们通过肉眼检查可能包含上述关键词的文件，也可能会发现其他一些“有趣”的信息。

在Github上挖掘情报听起来像是一个非常好的主意，但一不小心我们还是会犯一些错误，比如：

1、我们可能会被某个第三方app误导，最后得出的结果偏离预期目标，或者拿到的信息与目标应用无关。

2、我们拿到的密钥可能过于陈旧，不再可用，或者已不属于目标公司。当然这些密钥也有可能是假的密钥，被人故意放到Github上的。

找到信息后再次检查是必不可少的一个过程，以确保所得信息与预期目标相符。

四、巧用亚马逊云服务（AWS）

AWS（Amazon Web Service，亚马逊云服务）拥有海量资源，已经在为数以千计不同行业的公司提供服务。有些公司使用AWS s3存储桶（bucket）来托管公司内容，其他公司则用来部署及托管公司应用。与其他资源一样，AWS也可能被错误配置或被犯罪分子滥用。比如，我们经常会发现某些公司错误配置了s3存储桶，导致公司之外的用户能够读写属于该公司存储桶上的文件。

我们可以结合几种不同的方法来发现这些突破口：

1、在Google上搜索：site:s3.amazonaws.com + hackme.tld

2、在Github上搜索：“hackme.tld” + “s3”

3、我们可以暴破AWS，查找特定的s3存储桶，也可以通过自动化操作加速这一过程。

Lazys3正是基于第3种方法构建的一个工具。该工具使用了一个包含常见的s3存储桶列表的字典，通过不同的模式及排列组合，抓取目标服务器的响应头部，如果响应代码不是404错误代码，那么就会返回相应结果。比如，如果我们正在搜索hackme.tld名下的s3存储桶，该工具就会逐一测试字典中的每个条目，组合不同模式进行查找（比如：attachments-dev.hackme.tld、attachments.dev.hackme.tld、attachmentsdev.hackme.tld等），如果响应代码为200或403，就返回对应的信息。

如上图所示，我们使用lazys3查找dev环境下名为“assets”的存储桶。当前版本仅支持输出已存在的存储桶。

虽然暴破亚马逊云服务、查找其上托管的不同应用有助于拓宽我们的攻击面，但我们有可能会犯如下错误：

1、虽然s3存储桶可能暗示它属于某个公司，但实际上该公司并没有拥有或管理这个存储桶。

2、由于各种原因（比如第三方应用的存在），我们所得结果可能与预期效果不一致。我们可能拥有s3存储桶的读取权限，但存储桶上的文件并不包含敏感信息。

此外，我们要时刻提醒自己检查所得结果，在反馈问题的时候，如果这些问题属于上述类别问题，那么问题可能不会得到承认。

五、资产识别

我们还可以使用诸如Censys、Shodan或者archive.org等资产识别工具，用以补充前文提到的方法，进一步扩展我们的攻击面。

Censys.io

Censys在扫描IP地址、收集不同端口的指纹信息方面卓有成效。我们可以借助Censys，通过分析目标属性有关的SSL证书，找出目标的内部工具及资产信息。我们可以组合各种查询方法及语法来使用censys，但就我个人而言，我更喜欢根据目标的SSL证书梳理目标相关信息。比如，我们可以使用“443.https.tls.certificate.parsed.extensions.subject_alt_name.dns_names:Yahoo.com”这个查询语句，搜索指向Yahoo.com的任何子域名或者属性信息。

与其他工具类似，我们也可以进一步优化Censys上的搜索结果。创造力始终是目标侦察上的关键因素。我曾经通过随机组合查询语句（如“hackme.tld” + internal，或其他关键词），找到之前搜索时未发现的独特属性，这种情况已经出现过很多次。

Shodan.io

Shodan与censys类似，但不同的是Shodan可以搜索每个IP地址，查找该IP地址开放的任何端口，同时生成大量数据，允许用户指定地理位置、拥有该IP地址的组织、开放端口、产品服务（apache、tomcat、nginx等）、主机名及其他元素来过滤查询结果。

比如，如果我们想查找hackme.tld是否在默认端口上开放任何RabbitMQ服务，我们可以搜索“hostname:hackme.tld org:hackme ports:15672”。如果我们想查找特定产品（比如tomcat），我们也可以将查询语句中的端口关键词改为“product”关键词，此时查询语句变为：“hostname:hackme.tld org:hackme product:tomcat”。

Shodan创始人John Matherly写过名为“Shodan完整指南”的一篇文章，我们可以阅读这篇文章了解关于Shodan的更多信息。

Archive.org

Archive.org是另一个非常有用的参考来源，我们可以在上面找到网站之前的robots.txt文件，其中可能包含陈旧端点及其他敏感信息，也可以挖掘网站之前的版本信息，以分析站点源、收集更多信息，也可以找到被管理员遗忘的老的子域名及研发环境。只要访问Archive.org，搜索目标站点，选择过去的某个日期（可能是过去的一年或两年的某个日期），然后随便点击目标网站即可。

有些工具已经能够自动化完成这一工作了。我们可以使用waybackurl.py以及waybackrobots.txt这两个工具，找出我们想要的所有信息，静静等待输出结果即可。

我们也可以在Archive.org上找到网站之前的javascript文件，这些文件现在有可能还能访问。通过这种办法，我们可以找到与目标有关的已经过时的功能及端点。

搜集到一堆过去的以及新的JavaScript文件后，我们可以使用JSParser这个工具，从这些JavaScript文件中挖掘所有的端点信息。

六、总结

侦察过程不单单是简单地运行一堆工具、查找目标属性信息而已，更多情况下，侦察过程需要我们首先对目标有所了解，能够灵活利用这些工具，通过各种方式组合使用这些工具，同时发挥我们自己的创造力，这样才能找到更多结果。本文并没有覆盖侦察过程中涉及的所有可能的方法，然而，结合本文提到的这些方法，在运用工具的过程中善于思考，引入更有创意的其他方法总是一个不错的开头。

译者：WisFree

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

传送门

【技术分享】元数据：黑客最好的朋友（上）

映射数字足迹

在这篇文章中，我们假设自己是一名安全分析师，待分析的目标为whitehouse.gov和usa.gov，我们将对这两个域名所泄露的元数据进行数字足迹映射，并从中找出一些有价值的信息。

首先我们要从目标网站上下载感兴趣的文档，我们可以使用以下几种技术：

1.爬虫/网站镜像，下载所有的网站内容

2.使用Google/Bing来搜索公开文件

3.如果可能的话，直接向公司的响应团队所要公开文档

最简单的方法就是获取网站镜像，我们可以使用wget将网站中的所有内容下载到本地：

这种方法最明显的缺点就是我们还会下载HTML页面以及其他一些我们并不需要的东西，不过我们待会儿还可以使用bash脚本来过滤掉这些内容。

另一种方法就是使用Google或Bing语法来搜索网站中的索引文件：

注:使用filetype这种语法的话，Bing搜索出来的内容要比Google的多！

我们可以使用filetype语法来搜索office文档以及图片等内容，而且这种方法不仅可以帮助我们避免去下载那些没用的内容，而且还可以搜索子域名。从另一方面来看，它是依赖搜索引擎实现的，所以只有搜索引擎收录了的内容我们才能查找到，所以很可能会遗漏某些关键内容，具体还取决于网站的robots.txt文件。如果你想通过自动化的方式实现的话，你得自己动手写个脚本，而且依然会涉及到一些手动任务。如果你想使用工具的话，我推荐snitch。这款工具虽然很小巧，但功能已经可以满足你的需要了。你可以通过下列命令运行snitch并批量获取目标网站中的公开文件:

获取到文件之后，我们还要使用exiftool来提取其中的元数据。数据的输出格式为JSON(metadata.json)，之后我们可以将其发送到Splunk引擎来分析所有的数据。

Sweepatic提供的元数据处理脚本：【点我下载】

得到metadata.json文件之后，将其导入到Splunk（运行在Docker容器中）。首先，pull一个Docker Splunk镜像：

启动Splunk：

Splunk将会在本地运行，占用端口为8000。在浏览器中访问localhost:8000，然后完成初始化配置，最后导入需要分析的元数据：

1.点击仪表盘中的“Add Data”

2.点击“Upload”

3.接下来的配置也可以不用修改，保留默认即可，Splunk会自动检测并解析文件

4.来到下一步，在“Index”选项页中创建一个名叫document_metadata的新索引，其他设置不变，我们待会儿会用到这个索引。

5.在“Review”选项页中确认修改，然后完成数据的导入。

分析元数据

现在数据端的内容我们已经准备好了，接下来我们就要开始对这些数据进行分析了。

一般来说，软件在嵌入元数据时采用的是键值对的形式，不过具体的格式还得取决于文件格式。幸运的是，exiftool可以直接帮我们将元数据提取成JSON字典的形式，导入Splunk实例后它可以自动解析这些数据。这里的"键"为元数据名，"值"就是元数据的值，而我们就得通过元数据名来过滤出我们所感兴趣的内容。但是，元数据名并没有一定的标准，不同的软件使用的是不同的元数据名，而保存的内容却是差不多的。比如说“Creator”域中包含了创建这份文档的软件信息，但有些软件则用的是“Producer”。

先来看看你能从元数据中发现什么吧！将下列代码拷贝到Splunk的搜索栏中：

输出结果如下：

你可以看到，某些元数据名为公司或组织名称，这是一种非常好的实践方法。我们不仅可以利用正则表达式过滤出一些旧版本的软件，而且还可以搜索该组织所使用的打印机型号，例如关键字:xerox。

接下来，使用下列语句过滤出文档的创建用户：

在创建文档时，创建人通常会插入关键字，以此来帮助他人精准地搜索到该文件。不过这部分内容有时收集起来比较困难，因为有些软件在嵌入这些信息时使用的是数组，而有些则使用的是字符串（用逗号分隔开）。不过这些对于Splunk来说都不是事儿：

除了关键字之外，文档中还会包含创建人留下的一些注释信息，例如文档版本或其他的一些记录等等，有的时候创建人在发布这些文档之前很可能会忘记删除这些内容：

接下来，我们看看“杀伤力”最大的部分：文件路径。这些文件路径可能是本地磁盘路径，或者是网络服务器的共享文件路径，而且文件路径还会暴露Web服务器的文件结构。但这种内容为什么会存在在元数据里面呢?一般来说，导出文档或进行文档格式转换时这种情况才会出现。从元数据中提取文件路径会有一点点复杂，这里仍然需要使用正则表达式（查找路径/unix/style/paths或\\windows\file\share\paths）：

除了上面这些字符串或键值对形式的元数据之外，我们还可以用Splunk提取出文档创建的时间和日期等信息，并将其解析为图表格式：

提取文档的最后修改日期并以图表形式输出：

整合信息，制作我们的威胁仪表盘

在前面的章节中，我们介绍了一些可以从元数据中提取威胁情报的基本查询语句，但这些真的只是冰山一角而已。但是在一篇文章中，我们无法面面俱到地给大家介绍所有元数据的查询方法，不过你现在应该已经学会了如何去挖掘更多有价值的数据了。

我们建议各位同学用本文所介绍的技术来收集关于你公司或组织的文档元数据，然后将它们导入到Splunk中（点击下载仪表盘），Splunk会帮助你把这些数据解析成非常漂亮的图表形式，而它们将帮助你更加清楚地了解你的数字足迹，并让你意识到你当前的安全情况。

最佳的实践方式是定期使用Splunk更新你组织所生成的数据，如果你发现组织中的某个人仍然在使用Word 2007之类的旧版本软件来创建那些存储敏感信息的文档，那你一定要及时警告他，因为他会对整个组织的网络系统以及官方网站造成巨大的安全威胁。

注:如果你想了解更多关于应对方案的内容，请通过官网与Sweepatic团队取得联系，他们也许可以帮到你！

译者：WisFree

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

传送门

【技术分享】元数据：黑客最好的朋友（下）

在这个系列文章中，我们将给大家介绍文档的元数据到底是什么东西，以及它为何能够成为对黑客来说最有价值的资源。一份文档的元数据将允许我们从中收集到各种各样高度敏感的数据，例如用户名、企业所使用的软件、以及共享文件的存储位置等等。因此，从最佳安全实践角度出发，我们将告诉大家如何找出自家公司所泄露的元数据。收集到这些元数据之后，我们会使用机器数据引擎Splunk来对数据进行加工处理。需要注意的是，这些信息不仅能够给你提供一种全新类型的威胁情报，而且还可以帮助你在投入开销非常低的情况下了解到组织或公司的信息安全状况。

DEFCON更新

如果你想了解更多有关网络侦察或情报资源收集的Demo或演讲的话，请关注今年的DEFCON大会（时间:本周末，地点：美国拉斯维加斯的凯撒宫），我们的技术研究团队将会在此次大会上与大家见面。如果你想跟我们直接沟通交流，请发送邮件到support@sweepatic.com或直接来电骚扰（电话：+1(760)516-1384）。期待跟大家的见面！

安全客小百科:元数据

元数据（Metadata），又称中介数据或中继数据，即描述数据的数据。主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。元数据算是一种电子式目录，为了达到编制目录的目的，必须在描述并收藏数据的内容或特色，进而达到协助数据检索的目的。元数据是关于数据的组织、数据域及其关系的信息，简言之，元数据就是关于数据的数据。

文档的元数据到底是什么？

每一个组织每天都会产生大量的文件，这些文件中的内容可以是通知、办公文档，或者是审核过后等待发布的内容。不过需要注意的是，作为一家企业或组织，你每天发布出去的信息绝对要比你想象的多！每当一个文档被成功创建，那么创建这个文档所用的软件信息便会被插入到一种叫做元数据的东西里面，而元数据就是一种用来描述数据的数据。这是什么意思呢？元数据并非文件的内容，元数据描述的是：

1.创建这个文件时所使用的软件（例如Microsoft Word 2007）

2.创建这个文件的用户（例如John.doe或u12345）

3.创建这个文件所使用的计算机名（例如Super Secret Lab PC N203）

4.文件的创建日期

5.文件的最后修改日期

6.文件的打印日期

7.文件共享给外网访问的磁盘路径地址（例如\\DOC_SERVER\DOCS\PATENTS\Wormhole_travel_engine.docx）

8.以及。。。

文档元数据示例:

当你用某款软件创建或修改文档之后，这款软件便会自动将这些信息插入到文档中，插入信息的数量和种类取决于你所使用的软件以及配置。目前我们很少能够见到有哪个组织或企业会有意识地去限制这些元数据的传播，这些敏感信息的曝光和泄露将会吸引恶意攻击者的注意力，而你的竞争对手肯定也愿意花时间来分析这些元数据并从中了解你企业的内部情况。

元数据&网络侦察：黑客的宝藏

一般来说，一个组织或企业所遇到的攻击者主要有以下三种类型：

1.脚本小子

2.高级攻击者（APT）

3.内部攻击者

关于内部攻击者的问题已经超出了本文所要讨论的范围了，而前两种攻击者之间也有很大的区别。脚本小子与高级攻击者之间最大的一个区别就是他们在一次攻击活动中花在网络侦查阶段上的时间长短。

网络侦察通常是一次攻击活动中最重要的阶段，它甚至重要到可以决定这次攻击最终是否能够成功。攻击者在发动攻击之前需要寻找目标并提前制定“作战”计划，然后尽可能地收集到更多的信息来增加攻击的成功率。一般来说，攻击者要么会尝试寻找一种资产（例如未打补丁的联网服务器）或个人用户（例如财务部门的小张，他的电脑还运行着未更新的windows XP）。

攻击者可以通过子域名枚举来找出存在漏洞的服务器或暴露在外网的设备，然后用漏洞扫描工具来扫描漏洞。但如果你要攻击的是个人用户的话，那情况可能就会复杂一点了。因为此时将需要使用到LinkedIn之类的服务来收集公开情报资源，以此了解到目标所在组织的员工信息甚至完整的组织结构。那么攻击者如何才能直接找出目标组织中最有价值的那个用户呢？这就得看你的水平到底有多高了。

目标使用的是哪一款软件？如果使用的是LibreOffice而不是Microsoft Word的话，那么发送一个恶意VBA宏文件将没有任何意义。

目标使用的是什么操作系统？如果目标使用的是macOS，那我们发送一个针对Windows漏洞的Payload也是毫无意义的。

目标的用户名或电子邮箱地址呢？这些信息将在后渗透阶段给我们提供很大的帮助。

大多数组织会将共享文件存储在什么地方呢？当攻击者成功入侵该组织的网络系统之后，他可以选择进行横向渗透，或直接进行勒索软件攻击。

哪些承包商在为目标公司工作？有些情况下高级攻击者会选择目标组织的承包商或合作伙伴进行攻击，因为他们的安全措施也许并不牢固。

了解到这些东西之后，你还会直接将这些所有的数据直接发布到网络上任人随意下载和使用吗？应该不会了吧？很好...因为如果你在发布这些文件之前没有将元数据去除掉的话，你就非常危险了。文档的元数据中包含如此之多的信息(我们称这些信息为“Dark Data”)，我敢打赌你可能今天才知道吧？这些Dark Data不应该跟随文档一起发布出去，因为它将会成为一种巨大的安全威胁。你可能听说过GDPR（通用数据保护条例）吧?条例规定组织在发布文件或数据之后，要建立一个可维护的数据库或清单来存储这些文件数据。下图显示的是Sweepatic的敏感信息关系图（可通过Sweepatic的客户访问门户网站获取）：

这种类型的威胁情报信息是每一个组织和企业都应该收集的，虽然你也可以直接从厂商那里花钱购买威胁情报以及APT组织的IOC，但这样做成本太高了，而且买回来的绝大部分IOC估计都不适用于你的环境。因此我们建议你先了解自己会给攻击者暴露哪些东西，弄清楚自己公司的数字足迹（Digital Footprint），至少你要先搞清楚需要保护哪些东西。

后话

在了解到了这些关于元数据的相关知识之后，接下来要怎么做呢？请大家继续关注安全客，我们会在《元数据：黑客最好的朋友》的下集中给大家分享我们处理元数据的秘密方法。我们会告诉大家如何从文档中提取元数据，并将其作为威胁情报来对目标进行网络侦察，敬请期待！

作者：360天眼实验室

背景

继5月的WannaCry勒索蠕虫事件以后，2017年6月又出现了Petya变种勒索蠕虫，除了利用永恒之蓝漏洞和加密勒索以后，Petya变种与WannaCry有比较大的差别。WannaCry会加密机器上的文件，导致数据损毁，而Petya更为激进，它会加密系统的MBR直接导致机器无法启动，本文对其执行的MBR及文件系统的加密机制做详细的分析。

恶意代码分析

由于执行恶意操作的指令并不是以文件形式存在，我们使用WinHex工具提取受攻击机器的磁盘前23个扇区的数据进行分析，对应代码数据的Hash为 841e12729f200a5620859f2958e2d484。

相关数据结构

计算机启动时执行完BIOS的启动代码，检查各硬件设备正常后，JMP到MBR的引导代码进行执行；然后由MBR引导至活动分区的DBR，再由DBR引导操作系统。如：DBR调用NTLDR，再由NTLDR调用系统内核。

Petya病毒修改了系统的MBR，病毒在Bios加载后获得执行机会，病毒将加载存储在0x1扇区后的大小为0x20大小的病毒代码加载执行，这些代码会还原出真实的MBR，通过对还原出来的MBR解析，得到系统的DBR，通过DBR解析到系统的MFT结构，遍历所有的MFT，根据MFT找到文件内容所在的扇区后，读取该扇区加密内容后再写回到扇区中，从而实现对文件的加密。要完整的了解整个的加密过程，首先就是熟悉系统的MBR、DBR、MFT等结构的含义与功能。

MBR

Petya病毒修改了系统的MBR，病毒在Bios加载后获得执行机会，病毒将加载存储在0x1扇区后的大小为0x20大小的病毒代码加载执行，这些代码会还原出真实的MBR。在加密文件的过程中，Petya病毒会使用到MBR中。

MBR扇区由以下四部分组成：

引导代码：引导代码占MBR分区的前440字节，负责整个系统启动。如果引导代码被破坏，系统将无法启动。

windows磁盘签名：占引导代码后面的4字节，是Windows初始化磁盘写入的磁盘标签，如果此标签被破坏，则系统会提示“初始化磁盘”。

MBR分区表：占Windows磁盘标签后面的64个字节，是整个硬盘的分区表。

MBR结束标志：占MBR扇区最后2个字节，一直为“55 AA”。

MBR结构如下：

0x07 表示普通分区(Windows分区、数据分区。默认分区类型)。

0xEE 表示该分区表是PMBR，紧随其后的应该是GPT分区表头和GPT分区表，因此这是一块GPT硬盘。

0xEF 表示EFI系统分区

Petya在解密出原始的MBR后，解析MBR结构，得到起始扇区号，并根据起始扇区定位到DBR。

病毒解析MBR时，会对分区类型做判断，如果PMBR和EFI类型的系统分区，默认会不做处理。

在010editor工具中查看

判断分区类型，取了这两个字段：开始扇区与扇区大小：

在启动扇区（也就是63扇区）处，读一个扇区的内容，就是DBR结构

从MBR中可以定位到MBR分区表,根据分区表的属性就可以得到活动分区的扇区地址，也就得到了DBR结构地址。

DBR

DBR中存放着关于文件系统的重要参数信息以及系统引导代码。病毒解析到DBR后，只是为了取的DBR结构中的MftStartLcn字段(这个字段表明了MFT结构所在的扇区地址)，以便能进一步定位文件系统。

DBR的结构如下：

MFT

简介

MFT，即主文件表（Master File Table）的简称，它是NTFS文件系统的核心。MFT由一个个MFT项（也称为文件记录）组成。每个MFT项的前部为0x10字节的头结构，用来描述本MFT项的相关信息。后面节存放着属性。每个文件和目录的信息都包含在MFT中，每个文件和目录至少有一个MFT项。除了引导扇区外，访问其他任何一个文件前都需要先访问MFT，在MFT中找到该文件的MFT项，根据MFT项中记录的信息找到文件内容并对其进行访问。

MFT结构分为两种：元文件与普通文件。

元文件对于用户是不能直接访问的，MFT将开头的16个文件记录块保留用于这些元数据文件，除此之外的文件记录块才用于普通的用户文件和目录。

16个元文件

怎么解析这16个原文件的MFT结构呢？

换句话说，通过MBR定位到DBR,通过DBR定位到MFT，此时的MFT就对应着索引为MFT_IDX_MFT的MFT，向后偏移文件记录大小的地方，就存放着索引为MFT_IDX_MFT_MIRR的MFT。再向后偏移文件记录大小的地方，就存放着索引为MFT_IDX_LOG_FILE的MFT

解析这16个原文件的MFT结构有什么用？

如对于MFT_IDX_VOLUME 这个MFT结构，解析这个MFT结构中的ATTR_TYPE_VOLUME_INFORMATION（对应着0x70）就可以得到NTFS卷的版本信息,解析这个MFT结构中的ATTR_TYPE_VOLUME_NAME属性（对应着0x60）就可以得到NTFS卷名信息。

再如，对于MFT_IDX_MFT 这个MFT结构，解析这个MFT结构中的ATTR_TYPE_DATA（对应0x80）的属性RealSize，就表示整个卷所有的文件记录的大小信息。利用这个大小信息是以字节表示的，用这个大小信息除以每个文件记录所占用的字节就得到了卷占有的文件记录数量。计算出来的文件记录数量是将元文件也计算在内的。

依次遍历每个文件记录数量，读取这个文件记录的内容就是MFT结构，解析这个MFT的对应属性就可以解析出文件名、文件属性、文件内容等。

普通MFT

遍历文件时，从第16个文件记录开始向后遍历，才会得到普通的用户文件和目录信息及内容。

数据结构

MFT的直观结构如下，

// 文件记录体

// 属性1

// 属性2

// …………

每个MFT的结构如下：

根据FILE头部数据找到下面的一个个属性,接下来分析的就是一个个属性了，属性由属性头跟属性体组成,属性头的结构定义如下：

Petya中涉及到MFT的属性

对于0x30属性：

对于MFT中的0x30属性的直观认识，如下：

黄色部分对应着上表中的ATTRIBUTE结构，红色部分对应着上表中的NONRESIDENT_ATTRIBUTE结构。选中部分对应着FILENAME_ATTRIBUTE结构内容，这里面包含了文件的各种时间属性和文件名等内容。

Petya病毒在遍历MFT时，会通过判断当前MFT的AttributeFileName属性判断是否加密该MFT。

对于0x80属性：

对于MFT中的0x80属性的直观认识，如下：

黄色部分对应着上表中的ATTRIBUTE结构，红色部分对应着上表中的NONRESIDENT_ATTRIBUTE结构。绿色部分对应着RUN-LIST结构内容。

80H属性是文件数据属性，该属性容纳着文件的内容，文件的大小一般指的就是未命名数据流的大小。该属性没有最大最小限制，最小情况是该属性为常驻属性。常驻属性就不做多的解释了，如下是一个非常驻的80H属性。

该属性的“Run List”值为“32 0C 1B 00 00 0C”，其具体含义如下：

Petya病毒在加密文件内容时，会通过Run List定位到文件内容所在的真正扇区加密文件，如果文件内容大于2个扇区，则只加密前两个扇区。

恶意代码加载过程

1 加载代码到0x8000执行

从第一个扇区开始，读取0x20个扇区到0x8000地址处，随后跳到0x8000处执行

循环读取0x20个扇区代码片段：

在循环里使用int 13读取磁盘内容

2 调用函数读取硬盘参数

读取硬盘参数

比较“FA 31 C0 8E”硬编码，判断当前的第一个扇区的内容是不是病毒写入的内容。

3 判断加密标志

读取0x20扇区的内容（该扇区保存了病毒的配置信息），判断该扇区的第一个字节是不是1，如果是1，表示mbr已经被加过密，就来到显示勒索界面的流程;如果不为1，表示还未对MBR和MFT进行加密，进入加密流程。

加密过程

1 打印修复磁盘信息，设置加密标志

打印出虚假的“Repairing file system on C:”信息，读取0x20扇区中的配置信息到内存，并将读取到的配置信息的加密标志设置为1。随后，将修改过加密标志的内容写入到扇区中，为了保证写入成功，这里循环写了0x20次。

打印的磁盘修复信息如下：

2 加密验证扇区

加密验证扇区的方法为：读取0x21扇区的内容（这个扇区保存的全是0x07数据），使用从配置信息扇区读取的key与n做为加密参数，调用salsa加密该读到的0x07内容，并将加密后的内容写入到0x21扇区中

显示虚假的“CHKDSK is repairing sector”界面，实际在后台正在加密MFT数据。

3 加密操作

文件遍历的原理

Petya病毒通过解析MBR，DBR得到MFT地址。解析MFT索引为0的元文件，得到属性为DATA的属性内容，取出属性中的RUN-LIST结构中的簇数量与起始扇区，根据这两个字段遍历所有的MFT就得到了当前文件系统中所有的文件信息。

解析MBR

解析原始MBR数据的代码片段：

判断MBR中的分区类型：

判断从mbr中读取到的StartLBA字段不为空

从mbr中解析到StartLBA字段，并读取该字段对应的扇区，此扇区的内容就为DBR相关的内容：

读取到DBR后，解析出MftStartLcn字段，该字段就表示 MFT地址：

得到MFT地址后，该地址就是索引为0的MFT元文件地址,从该元文件结构中取出属性为0x80（DATA）的内容。

首先读取到$MFT的扇区内容：

解析属性，判断是不是0x80(DATA)属性类型

对$MFT属性0x80中的解析，得到下面信息：

run_data_cluster*sector/cluster + 0x20(0x20为元文件占用的扇区大小)+mbr. arg_StartLBA，作为普通 MFT扇区的起始扇区，这样是保证加密的过程中不会加密元文件扇区与mbr相关的扇区。

（run_data_num_clusters * sector/cluster）- 0x20(0x20为元文件占用的扇区大小)，做为普通MFT的扇区大小。

随后，就来到遍历用户MFT的函数：

遍历普通MFT结构

遍历普通MFT结构的函数在00008FA6处，该函数为病毒代码中最为主要的函数。

下面对这个函数进行详细分析:

在调试的过程中，parse_User_MFT函数的参数内容为：80 C6 5F 00 60 00 20 C6 00 00 3F 00 00 00 3F 00 60 00 08 C6 2C 67 4A 67 8B 77 52 9C 01,结合调试时传递的参数内容，对函数作出说明。

该函数主要功能为：对扇区中的MFT遍历，对不符合MFT头部标志(FILE)的扇区，会直接调用SALSA20算法进行加密该扇区，对符合MFT头部标志的扇区，判断0x30属性中的文件名判断是不是元文件，如果不是元文件名格式，则直接加密该扇区。其他情况下，判断MFT结构0x80属性中的常驻内存属性，如果是非常驻内存属性，就解析文件内容的前二个扇区，取出该扇区的内容后，使用salsa20算法进行加密。

1.先打印出“CHKDSK is repairing sector”，显示虚假的磁盘修复界面

2.对当前MFT头是不是“FILE”,如果不是”FILE”的话，则直接加密这个扇区

3.如果是FILE，接着遍历mft的各个属性：

如果属性为AttributeFileName（0x30），判断文件名字长度是不是1，如果长度为1，直接加密，如果长度不为1，则看文件名字是不是以$开头(以$开头的是NTFS文件系统的元文件)，如果是元文件，则加密当前MFT.

如果属性为AttributeData文件数据属性（0x80），则首先根据属性头判断是不是非常驻内存，如果是常驻内存属性就跳过，不进行加密。如果是非常驻内存属性，则通过RUNLIST结构遍历到存储数据的真正的扇区位置。

解析RUNLIST

根据RUNLIST中的起始簇乘以MBR中保存的每簇对应的扇区数，得到数据真正所在的扇区。

随后，判断上面计算出的文件内容对应扇区数量是不是大于2，如果大于2，只加密前2个扇区。

读取该MFT文件对应的文件内容的前两个分区，通过直接使用int 13中断从扇区读取到文件内容，使用salsa20加密后，将密文直接写入的扇区中文件中。

在动态调试时，可以看到加密了文件内容，加密文件内容前的数据

被加密后的文件内容：

加密函数

对文件的加密使用了SALSA20算法，该算法属于流加密，在知道key和iv的情况下，加密函数和解密函数可以为相同的函数代码。

加密函数

在密钥扩展的函数中，Petya将原始的常数“expand 16-byte k”更改成了“1nvald s3ct”

扩展密钥函数代码：

Salsa20加密时使用的key和iv来自于配置信息扇区（0x20扇区）

将明文与生成的keystream异或，实现加密

解密过程

在开机启动过程中，MBR引导后，加载扇区中的恶意代码后，恶意代码会判断配置信息第1个BYTE是不是1，1表示已经加密过，则进入相应的解密过程中

1 打印勒索信息

打印出勒索信息

也就是显示如下的内容

2 读取用户输入的key

清空内存，读取用户输入的key

3 验证用户的key

在验证KEY的过程中，首先比较输入的key的长度，必须大于0x20长度

将输入的key通过自定义算法的转换0x21次

使用转换过的key，使用salsa20算法解密0x21扇区的内容（这个扇区的内容为加密过的0x7内容），比较解密出来的内容是不是0x7，如果是则表明解密密码正确。

密码验证通过后，会使用这个key做为参数调用DecryptProc 函数(并非勒索软件作者定义的函数名)，

在DecryptProc函数中调用与加密时相同的函数进行对MFT结构进行遍历后解密，

在解密完成后，打印“Please reboot your computer!”信息

总结

本文对Petya变种勒索蠕虫的扇区启动代码进行了详细分析，分析显示Petya变种勒索蠕虫并不仅会加密MBR和MFT结构，也会将MFT对应的文件内容的前两个扇区进行加密。换句话说，Petya变种勒索蠕虫在系统启动时MBR中的代码执行时也会进行全盘文件的加密操作。结合RING3级别的勒索代码功能，Petya会对文件执行两次加密操作，第一次为Petya勒索蠕虫执行时，使用RSA与AES算法遍历文件系统对指定扩展名的文件加密，第二次为系统启动时，启动扇区的代码会通过遍历MFT结构定位文件内容并对文件使用salsa20算法进行加密。对于RING3级别的文件加密过程，解密密钥可以通过勒索蠕虫作者的RSA私钥进行解密获得，而启动扇区级别的文件加密过程使用了随机密码进行，启动扇区级别的文件加密无法解密。

参考

http://dengqi.blog.51cto.com/5685776/1351300

https://github.com/alexwebr/salsa20/blob/master/salsa20.c

http://blog.csdn.net/enjoy5512/article/details/50966009

http://bobao.360.cn/learning/detail/4039.html

作者：bit4@polaris-lab.com

前言

在我的域名收集知识体系中，利用爬虫来获取域名是其中的一部分（见文末思维导图，其他部分的实现请访问我的另外一个项目：https://github.com/bit4woo/Teemo ），由于使用频率，使用习惯等问题，而我最终决定使用BurpSuite的Spider来实现爬虫部分的自动化收集。所以有了这个BurpSuite插件：Domain Hunter。

原理

当使用了BurpSuite作为代理，或者使用它进行了安全测试，会就会记录相关的域名。其中，某个目标的子域名和相似域名很有价值，尤其是相似域名，往往有惊喜！插件的主要原理就是从BurpSuite的Sitemap中搜索出子域名和相似域名。也可以对已经发现的子域名进行主动爬取，以发现更多的相关域名，这个动作可以自己重复递归下去，直到没有新的域名发现为止。

项目地址

https://github.com/bit4woo/domain_hunter

截图

Change Log

2017-07-28: Add a function to crawl all known subdomains; fix some bug.

Xmind Of Domain Collection

热点概要：如何利用GitHub Enterprise的4个漏洞，从SSRF到远程代码执行、sThisLegit、Phinn：新型开源钓鱼工具、如何使用Burp Suite模糊测试SQL注入、XSS、命令执行漏洞、CVE-2016-6195：vBulletin插件forumrunner（默认开启）SQL注入漏洞exp、DEFCON25会议PPT下载、Breaking Bitcoin Hardware Wallets

国内热词(以下内容部分摘自http://www.solidot.org/)：

机器人半小时内破解保险箱密码

资讯类：

通过一个15美元的磁铁hacking价值1500美元的“智能手枪”

http://thehackernews.com/2017/07/smart-gun-hacking.html

Skype-Type：一款keyboard acoustic eavesdropping工具

https://github.com/SPRITZ-Research-Group/Skype-Type

如何使用Burp Suite模糊测试SQL注入、XSS、命令执行漏洞

http://www.hackingarticles.in/fuzzing-sqlxss-command-injection-using-burp-suite/

如何利用GitHub Enterprise的4个漏洞，从SSRF到远程代码执行

http://blog.orange.tw/2017/07/how-i-chained-4-vulnerabilities-on.html

Breaking the x86 ISA

https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf

sThisLegit、Phinn：新型开源钓鱼工具

https://duo.com/blog/new-open-source-phishing-tools-isthislegit-and-phinn

Brida:使用Frida进行移动应用渗透测试

https://techblog.mediaservice.net/2017/07/brida-advanced-mobile-application-penetration-testing-with-frida/

Augur REP Token严重漏洞披露

https://blog.zeppelin.solutions/augur-rep-token-critical-vulnerability-disclosure-3d8bdffd79d2

Email身份认证失败

https://www.grepular.com/Email_Authentication_Failure

Searching For Phrases in Base64-encoded Strings

https://michaelveenstra.com/2017/07/27/searching-for-phrases-in-base64-encoded-strings/

spacebin：a proof-of-concept malware that exfiltrates data (from No Direct Internet Access environments) via triggering AV on the endpoint and then communicating back from the AV's cloud component.

https://github.com/SafeBreach-Labs/spacebin

CVE-2016-6195：vBulletin插件forumrunner（默认开启）SQL注入漏洞exp

https://github.com/drewlong/vbully/blob/master/vbully

DEFCON25会议PPT下载

https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/

Petya 内网传播分析

http://purpleroc.com/MD/2017-06-28@How%20does%20Petya%20spread%20in%20LAN.html

如何使用Fuzzing挖掘ImageMagick的漏洞

https://github.com/lcatro/Fuzzing-ImageMagick/blob/master/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8Fuzzing%E6%8C%96%E6%8E%98ImageMagick%E7%9A%84%E6%BC%8F%E6%B4%9E.md

Man-in-the-middle wireless access point inside a docker container

https://github.com/brannondorsey/mitm-router

Breaking Bitcoin Hardware Wallets

https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Datko-and-Quartier-Breaking-Bitcoin-Hardware-Wallets.pdf

arm64汇编crash课程

https://github.com/Siguza/ios-resources/blob/master/bits/arm64.md

前言

服务器承担着业务运行及数据存储的重要作用，因此极易成为攻击者的首要目标。如何对业务服务器的安全进行防护，及时找出针对系统的攻击，并阻断攻击，最大程度地降低主机系统安全的风险程度，是企业安全从业人员面临的一个问题。

本篇原创文章主要通过介绍ngx_lua & fail2ban实现主动诱捕从而达到主机防护的效果。

ngx_lua & fail2ban实现主动诱捕

用过主机层WAF的朋友对ngx_lua_waf应该都不陌生，做过SSH防暴力破解的同学应该对fail2ban也有耳闻。

常见的开源主机WAF有 mod_security、naxsi、ngx_lua_waf 这三个，ngx_lua_waf 性能高和易用性较强，基本上零配置，只需要维护规则，常见的攻击类型就都能防御，相对来说是比较省心的选择。同时，基于lua脚本编写模块也很快捷，甚至可以实现一些复杂的业务层逻辑安全控制。当然，选择春哥的openresty也可以，如果选择openresty就不需要再单独安装lua相关的组件了。

这里我们简单介绍一下安装过程，用nginx或者tengine都可以，需要安装LuaJIT，操作系统需要安装zlib,zlib-devel,openssl,openssl-devel,pcre,pcre-devel。LuaJIT安装成功后，如下图所示。

Tengine编译参数如下：

下载ngx_lua_waf，下载地址为https://github.com/loveshell/ngx_lua_waf，解压后放在/usr/local/nginx/conf目录下，可重命名为指定名称如waf，修改ngx_lua_waf配置文件config.lua，路径根据实际安装情况定。

需要注意logdir指向的目录不存在，需要手工创建，创建后需要修改所属权限，否则防护日志无权限写入。

nginx主配置文件nginx.conf的http段中添加如下内容。

检查nginx配置/usr/local/nginx/sbin/nginx –t，如果没问题重启nginx既可生效。

Fail2ban安装我们就不做过多介绍了，安装配置都比较简单，不过fail2ban的经典用法基本都是用来做SSH防暴力破解的，那么fail2ban到底和ngx_lua_waf有什么关系呢？其实，看一下fail2ban的原理，通过正则匹配SSH日志中的关键字，根据达到定义的触发规则次数，调用iptables将攻击IP ban掉一定的时间。

相信大家也都想到了，既然能通过匹配SSH日志，web日志肯定也是能匹配到的，只不过是要定义相关匹配规则而已，fail2ban本身也支持apache和vsftp。针对其他的应用系统也一样，分析场景，编写好规则就可以了。

说了这么多，这里才是我们的重点，我们的目的是主动诱捕具有针对性的攻击行为，主动诱捕是相对于传统蜜罐，传统蜜罐是被动的诱使攻击者访问，再对其行为进行记录。主动诱捕是指将具有针对性的攻击行为主动转向蜜罐网络，对攻击者几乎是透明的，不知不觉就进入到了我们的蜜罐网络中。

为什么要采用主动诱捕的方式来进行防御呢，大家可能都有这个体会，我们的应用系统每天都会受到很多攻击，但99%可能都是盲目的扫描探测，只有不到1%可能才是具有针对性的攻击，而我们真正关心的其实就是这1%的针对性攻击，1%的有效数据被99%的垃圾数据覆盖，对分析造成了很大的干扰。

要让主动诱捕真正发挥作用，我们首先要梳理好业务场景，梳理出哪些场景下的攻击是真正具有威胁性的，根据实际情况编写好规则，当攻击行为触发规则，筛选出攻击IP并调用iptables转发到蜜罐网络中。根据不同需求，蜜罐网络中可以KILLCHAIN进行跟踪和分析，也可以根据业务进行攻击行为分析，进而调整整体安全策略，达到有效防御。

当然，蜜罐网络要做好隔离，否则会造成很大的安全隐患，技术也是一把双刃剑，iptables可以将攻击IP流量转发到蜜罐网络，相信大家也想到了利用iptables实现端口复用，绕过一些端口访问控制。因此，要想做到更好的防御，就要比攻击者更了解自己的系统。

以上为悬镜安全实验室原创文章，如需转载请标注：http://lab.xmirror.cn/atc/2017/07/19/xmirror-security.html

作者：興趣使然的小胃

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、前言

虚拟机指的是安装在正常宿主机操作系统内的一个完全隔离的客户机操作系统。虚拟机逃逸指的是突破虚拟机的限制，实现与宿主机操作系统交互的一个过程，攻击者可以通过虚拟机逃逸感染宿主机或者在宿主机上运行恶意软件。在最近举办的PwnFest黑客大会上（由Power of Community组织，在韩国首尔举办），研究人员成功实现了VMware的虚拟机逃逸，这也是VMware首次在公开场合被攻陷，我们对此很感兴趣，因此，McAfee IPS漏洞研究团队决定深入研究这个过程，加深对该漏洞的理解。

二、背景知识

VMware反应非常迅速，他们很快发布了一个安全补丁修复这些漏洞，同时公布了一份安全公告。根据我们在闭源软件安全问题方面的一贯做法，我们研究了一下这份公告。公告里面提到这样一段话：

“VMware Workstation和Fusion的拖放（drag-and-drop，DnD）功能中存在一个越界内存访问漏洞。在运行Workstation或Fusion的操作系统上，攻击者可以利用这个漏洞实现客户机逃逸，在宿主机上执行代码。在Workstation Pro和Fusion上，如果拖放功能和复制粘贴（copy-and-paste，C&P）功能都被禁用，那么这个漏洞就无法利用”。

这个漏洞存在于拖放和复制粘贴功能中。这两个功能都用到了VMware远程过程调用（remote procedure call，RPC）机制。VMware的RPC机制一直以来都是一个非常容易被攻破的点，容易实现客户机到宿主机的逃逸。

在我们深入分析VMSA-2016-0019（CVE-2016-7461）的补丁之前，我们必须先对VMware Workstation如何处理客户机到宿主机或者宿主机到客户机之间的复制粘贴操作有所了解。

下图从类的层次化角度描述了VMware的拖放和复制粘贴（DnDCP）模式（来源：VM Tools开源代码）：

为了无缝实现宿主机与客户机之间的拷贝粘贴操作，客户机操作系统需要安装VMware tools。VMware tools负责处理客户机到宿主机或者宿主机到客户机之间的通信。在我们研究过程中，我们使用的环境为windows客户机以及Windows宿主机。在Windows客户机中，tools的主进程为vmtoolsd.exe。

宿主机与客户机之间相互通信的一种方法是借助RPC接口。VMware使用了一种名为后门（Backdoor）的RPC接口。

2.1 客户机的RPC机制

让我们好好研究一下客户机与宿主机系统彼此如何通过RPC接口进行通信。为了理解客户机的RPC机制，我们参考了VMware tools的开源组件，即open-vm-tools，这个组件使用如下函数来处理客户机的RPC调用：

从理论上讲，任何用到RpcChannel_Send()或者RpcOut_send()函数的报文都可以使用rpctools.exe工具来发送，这个工具是VMWare Workstation内置的一个命令行工具。

RpcOut_Send()调用了Message_Send()，后者会调用Backdoor()函数。

Backdoor函数负责通过VMware专用的I/O端口来发送消息。

当调用Backdoor函数从客户机往宿主机发送消息时，通常情况下我们可以看到如下指令集：

安装完VMware tools后，我们可以在vmtools.dll中找到这个函数。如下图所示，我们可以看到Backdoor()正在调用sub_10050190函数：

深入研究后，我们发现这个函数会执行特权指令“in.”。

让我们回到漏洞上来。我们之所以对DnDCP RPC消息感兴趣，原因是根据安全公告，该漏洞位于DnDCP RPC中。在VM Tools源码中，我们可以找到DnDCP RPC消息的具体结构：

从源码中，我们可知该结构体的第一个成员为RPC命令。如果我们研究客户机中vmtoolsd.exe的vmtools!RpcOut_send(x,x,x,)函数，我们也会看到相同的信息。

2.2 客户机中RPC报文的处理过程

我们来看看宿主机操作系统如何处理RPC请求。在宿主机中，正在运行的每个虚拟机都有一个独立的进程，进程名为vmware-vmx.exe。

当客户机发起RPC请求时，vmware-vmx.exe内部的代码会搜索客户机的RPC处理表，找到与请求对应的处理程序。

如果我们使用IDA Pro反汇编vmware-vmx.exe，从中查找原始字符串信息，我们可以找到大部分处理程序。

三、漏洞分析

根据以上信息，我们可知vmware-vmx.exe是宿主机上的主要组件，负责处理存在漏洞的复制粘贴RPC组件。接下来，我们从二进制角度对比了已打补丁和未打补丁的程序。VMware Workstation从12.5.2版本起就打上了漏洞补丁，因此我们从二进制角度对比了12.5.2版和12.5.1版的vmware-vmx.exe之间的区别。

我们发现补丁修改了vmware-vmx.exe中的几个函数，如下图所示。

其中比较有趣的一个函数是vmware_vmx!sub_140621520。

这个函数之所以会引起我们的注意，原因在于该函数内部调用了memcpy()函数，这个地方是触发越界漏洞的完美场景。

经过一番调试及逆向分析后，我们确认vmware_vmx!sub_140621520函数负责处理RPC报文，并且我们在客户机系统中可以控制该函数的某个参数。该参数为指向某个结构体的一个指针，因此我们得以控制传入的结构体的具体内容。

具体情况如下图所示。左图表示的是客户虚拟机，右图表示我们已将windbg附加到vmware_vmx.exe进程上。

如上图所示，我们在vmtoolsd.exe进程运行期间修改了一个RPC报文，随后该报文被vmware-vmx.exe进程中的vmware_vmx!sub_140621520函数接收。

让我们反编译已打上补丁的函数，看看函数添加了哪些代码来解决这个问题。

为了能够发送一个有效的RPC报文，我们参考了VM Tools的源码，源码中定义了RPC报文的具体结构。RPC报文头部结构如下图所示，我们可知该报文头部大小为0x38。

binarySize以及payloadSize字段对应的是反汇编代码中的v6及v5变量。我们可以控制这两个字段的值，触发越界访问漏洞。为了能从客户机往宿主机发送任意RPC报文，我们开发了一个独立工具，该工具利用Backdoor函数，可以实现从客户机往宿主机发送RPC报文。经过完整的逆向分析后，我们发现利用存在漏洞的这个函数，可以实现vmware-vmx.exe进程中的越界读取及写入目标。

3.1 越界读取

根据前文分析，我们可以控制payloadSize字段。在发送报文时，如果我们使用了一个以非常大的payloadSize，同时又没有分配payload缓冲区，那么当程序执行到memcpy()时，就会越界读取其他一些内存数据。

如上图所示，程序会拷贝从0x36E4D96到0x378A0D0之间0x500个字节长度的数据。然而，我们自己的数据在0x36E4DB7处的0x4C那就已经结束了，0x36E4DB7之后的数据会导致越界读取漏洞。

3.2 越界写入

如果RPC消息中包含多个报文，那么sub_1406215F0就会被调用。

为了在这个函数中实现越界写入，我们需要在一个会话内发送多个RPC报文，然后vmware-vmx会创建一个新的缓冲区，将所有报文的载荷结合在一起。经过全面的逆向分析实验后，我们最终发现，我们可以从客户机往宿主机发送包含如下特征的RPC报文，实现越界写入目标。

首先，我们需要发送带有如下特征的一个拖放RPC报文：

1、packet->binarySize为0x10000。

2、packet->payloadOffset为0x0。

3、packet->payloadSize为0x500。

通过这些选项，我们就能通过前面所有的检查条件，这些条件包括：

1、packetSize大于DND_CP_MSG_HEADERSIZE_V4。

2、packet->payloadSize小于0xFF64。

3、packet->binarySize小于0x400000。

4、packet->payloadOffset + packet->payloadSize < packet->binarySize。

程序将会创建一个新的缓冲区，将我们所有的报文载荷复制到缓冲区中。

接下来，我们需要发送另一个报文，该报文使用相同的会话ID，具体特征为：

1、packet->binarySize为0x10100。

2、packet->payloadOffset为0x500。

3、packet->payloadSize为0xFC00。

这些选项依然满足过滤条件，这些条件包括：

1、packetSize大于DND_CP_MSG_HEADERSIZE_V4。

2、packet->payloadSize小于0xFF64。

3、packet->binarySize小于0x400000。

4、packet->payloadOffset + packet->payloadSize < packet->binarySize。

由于这个报文与第一个报文的会话ID相同，并且程序已经分配了一个新的缓冲区，因此程序会继续将载荷数据复制到当前缓冲区中（因为0x500 + 0xFC00的值等于0x10100，不等于0x10000）。这样就会导致程序越界写入0x100字节大小的数据。

上图显示了vmware-vmx.exe进程在越界写入之前的内存状态。

上图显示了vmware-vmx.exe进程在越界写入之后的内存状态，其中0x40E3070处的内存为新的缓冲区尾部（0x10000）之后的内存。我们发送完第二个报文后，成功实现将0x100字节大小的数据覆盖了位于0x40E3070处的内存数据。

四、总结

本文简要介绍了VMware Workstation中的RPC机制，也分析了如何利用RPC中的漏洞实现从客户机系统到宿主机系统的虚拟机逃逸。在之后的一系列文章中，我们将详细分析漏洞利用的每个步骤，并向大家演示如何组合这些漏洞，在VMware中实现完整的虚拟机逃逸。

作者：興趣使然的小胃

预估稿费：300RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

Web缓存欺骗（Web Cache Deception）是一种新的web攻击方法，包括web框架以及缓存机制等在内的许多技术都会受到这种攻击的影响。攻击者可以使用这种方法提取web用户的私人及敏感信息，在某些场景中，攻击者利用这种方法甚至可以完全接管用户账户。

Web应用框架涉及许多技术，这些技术存在缺省配置或脆弱性配置，这也是Web缓存欺骗攻击能够奏效的原因所在。

如果某个用户访问看上去人畜无害、实际上存在漏洞的一个URL，那么该Web应用所使用的缓存机制就会将用户访问的具体页面以及用户的私人信息存储在缓存中。

二、背景介绍

2.1 什么是Web缓存

很多网站都会使用web缓存功能来减少web服务器的延迟，以便更快地响应用户的内容请求。为了避免重复处理用户的请求，web服务器引入了缓存机制，将经常被请求的文件缓存起来，减少响应延迟。

通常被缓存的文件都是静态文件或者公共文件，如样式表（css）、脚本（js）、文本文件（txt）、图片（png、bmp、gif）等等。通常情况下，这些文件不会包含任何敏感信息。许多指导性文章在提及web缓存的配置时，会建议缓存所有公开型静态文件，并忽略掉这些文件的HTTP缓存头信息。

有多种方法能够实现缓存，比如，浏览器端也可以使用缓存机制：缓存文件后，一段时间内浏览器不会再次向web服务器请求已缓存的文件。这类缓存与web缓存欺骗攻击无关。

实现缓存的另一种方法就是将一台服务器部署在客户端和web服务器之间，充当缓存服务器角色，这种实现方法会受到web缓存欺骗攻击影响。这类缓存有各种表现形式，包括：

1、CDN（Content Delivery Network，内容分发网络）。CDN是一种分布式代理网络，目的是快速响应内容请求。每个客户端都有一组代理服务器为其服务，缓存机制会选择离客户端最近的一个节点来提供服务。

2、负载均衡（Load balancer）。负载均衡除了能够通过多台服务器平衡网络流量，也能缓存内容，以减少服务器的延迟。

3、反向代理（Reverse proxy）。反向代理服务器会代替用户向web服务器请求资源，然后缓存某些数据。

了解了这些缓存机制后，让我们来看看web缓存的实际工作过程。举个例子，“http://www.example.com”配置了一个反向代理服务器作为web缓存。与其他网站类似，这个网站使用了公共文件，如图片、css文件以及脚本文件。这些文件都是静态文件，该网站的所有或绝大部分用户都会用到这些文件，对每个用户来说，此类文件返回的内容没有差别。这些文件没有包含任何用户信息，因此从任何角度来看，它们都不属于敏感文件。

某个静态文件第一次被请求时，该请求会直接穿透代理服务器。缓存机制没见过这个文件，因此会向服务器请求这个文件，然后服务器会返回文件内容。现在，缓存机制需要识别所接收的文件的类型。不同缓存机制的处理流程有所不同，但在大多数情况下，代理服务器会根据URL的尾部信息提取文件的扩展名，然后再根据具体的缓存规则，决定是否缓存这个文件。

如果文件被缓存，下一次任何客户端请求这个文件时，缓存机制不需要向服务器发起请求，会直接向客户端返回这个文件。

2.2 服务器的响应

假设某个URL地址为“http://www.example.com/home.php/nonexistent.css”，其中home.php是一个真实页面，而nonexistent.css是个不存在的页面，那么当用户访问这个地址，会出现什么情况呢？

在这种情况下，浏览器会向该URL发送一个GET请求。我们比较感兴趣的是服务器的反应。取决于服务器的实现技术以及具体配置，web服务器可能会返回一个200 OK响应，同时返回home.php页面的内容，表明该URL与已有的页面一致。

服务器返回的HTTP响应头与home.php页面的响应头相同：即这两个响应头包含一样的缓存头部以及一样的内容类型（本例中内容类型为text/html），如下图所示：

三、Web缓存欺骗方法

未经授权的攻击者很容易就能利用这个漏洞，具体步骤如下：

1、攻击者诱使用户访问“https://www.bank.com/account.do/logo.png”。

2、受害者的浏览器会请求“https://www.bank.com/account.do/logo.png”。

3、请求到达代理服务器，代理服务器没有缓存过这个文件，因此会向web服务器发起请求。

4、Web服务器返回受害者的账户页面，响应代码为200 OK，表明该URL与已有页面一致。

5、代理机制收到文件内容，识别出该URL的结尾为静态文件扩展名（.png）。由于在代理服务器上已经设置了对所有静态文件进行缓存，并会忽略掉缓存头部，因此伪造的.png文件就会被缓存下来。与此同时，缓存目录中会创建名为“account.do”的一个新的目录，logo.png文件会缓存在这个目录中。

6、用户收到对应的账户页面。

7、攻击者访问“https://www.bank.com/account.do/logo.png”页面。请求到达代理服务器，代理服务器会将已缓存的受害者账户页面发给攻击者的浏览器。

四、攻击意义

如果攻击成功，那么包含用户私人信息的存在漏洞的页面就会被缓存下来，可以被公开访问。被缓存的文件是一个静态文件，攻击者无法冒充受害者的身份。该无文件无法被覆盖，直到过期之前仍然有效。

如果服务器的响应内容中包含用户的会话标识符（某些场景中会出现这种情况）、安全应答、CSRF令牌等信息，那么攻击造成的后果将会更加严重。这种情况下，攻击者可以借助其他攻击手段最终完全掌控受害者账户。

五、攻击条件

攻击者若想实施Web缓存欺骗攻击，必须满足如下3个条件：

1、当访问如“http://www.example.com/home.php/nonexistent.css”之类的页面时，服务器需要返回对应的home.php的内容。

2、Web应用启用了Web缓存功能，并且会根据文件的扩展名来缓存，同时会忽略掉任何缓存头部。

3、受害者在访问恶意URL地址时必须已经过认证。

六、现有的Web框架

此类攻击是否能奏效，其中一个因素涉及到Web应用对特定URL的处理过程，这类URL由一个合法的URL以及尾部一个不存在的文件构成，如“http://www.example.com/home.php/nonexistent.css”。

在这一部分内容中，我们会以具体的例子，向大家演示如何针对现有的几种web框架实施web缓存攻击，同时也会解释这些框架的具体配置及工作流程。

6.1 PHP

如果我们创建一个“纯净版”的PHP Web应用，没有使用任何框架，那么该应用会忽略掉URL尾部的任何附加载荷，返回真实页面的内容，并且响应代码为200 OK。

比如，当用户访问“http://www.example.com/login.php/nonexistent.gif”时，Web应用会返回login.php的内容，这意味着此时发起攻击的第1个条件已经得到满足。

6.2 Django

Django使用调度器（dispatcher）来处理Web请求，调度器使用urls文件来实现。在这些文件中，我们可以设置正则表达式来识别URI中具体请求的资源，然后返回对应的内容。

上图是Django的常见配置，根据这个配置，当客户端请求“http://www.sampleapp.com/inbox/”时，服务器会返回Inbox页面的内容。

如果将某个不存在的文件附加到该URL尾部（如“http://www.sampleapp.com/inbox/test.css”），这种正则表达式同样会匹配成功。因此，Django同样满足发起攻击的第1个条件。

此外，如果正则表达式忽略掉“Inbox”尾部的斜杠，那么这种表达式也存在漏洞。

这种正则表达式不仅会匹配正常的URL（即“http://www.sampleapp.com/inbox”），也会匹配不存在的URL（如“http://www.sampleapp.com/inbox.css”）。

如果正则表达式尾部使用了“$”符，那么就不会匹配这种恶意URL地址。

6.3 ASP.NET

ASP.NET框架中有个内置的功能，叫做FriendlyURLs，这个功能的主要目的是使URL看起来更加“整洁”同时也更加友好。当用户访问“https://www.example.com/home.aspx”时，服务器会删掉尾部的扩展名，将用户重定向至“https://www.example.com/home”。

我们可以在Route.config文件中配置这个功能，在ASP.NET应用中，这个功能默认情况下处于启用状态。

启用FriendlyURLs功能时，当用户通过“http://localhost:39790/Account/Manage.aspx”地址访问已有的Manage.aspx页面时，服务器会移除.aspx扩展名，显示页面内容。

在这种配置下，当用户访问“http://localhost:39790/Account/Manage.aspx/test.css”时，.aspx扩展名会被移除，用户会被重定向到“http://localhost:39790/Account/Manage/test.css”，此时服务器会返回404错误。这意味着当ASP.NET启用FriendlyURLs功能时，攻击条件无法满足。

虽然FriendlyURLs默认处于启用状态，但很多网站并没有使用这个功能。该功能可以在Route.config文件中关闭。

关闭该功能后，访问攻击URL地址时服务器会返回200 OK响应，并且会返回Manage.aspx页面的内容。

七、现有的缓存机制

攻击的第2个条件是web应用启用了Web缓存功能，并且会根据文件的扩展名来缓存，同时会忽略掉任何缓存头部。下面我们会以现有的某些缓存机制为例，介绍这些机制的缓存过程以及它们如何识别接收到的文件的类型。

7.1 Cloudflare

当来自web服务器的文件到达Cloudflare时，文件会经过两个阶段的处理过程。第一个阶段名为资格阶段（Eligibility Phase），此时Cloudflare会检查目标站点是否设置了缓存功能，也会检查文件来源目录是否设置了缓存功能。如果检查通过（检查基本都会通过，这也是为什么网站一开始就使用Cloudflare服务的原因所在），那么Cloudflare服务器就会检查具体的URL地址是否以如下静态扩展名结尾：

class, css, jar, js, jpg, jpeg, gif, ico, png, bmp, pict, csv, doc, docx, xls, xlsx, ps, pdf, pls, ppt, pptx, tif, tiff, ttf, otf, webp, woff, woff2, svg, svgz, eot, eps, ejs, swf, torrent, midi, mid

如果URL地址的确以上述扩展名结尾，那么文件就会到达第二阶段的处理过程，即失格阶段（Disqualification Phase），此时Cloudflare服务器会检查HTTP缓存头部是否存在。

不幸的是，当我们访问恶意URL地址时，web服务器会返回已有的动态页面的缓存头部，这意味着服务器很有可能会返回带有“no-cache”指令的文件。

幸运的是，Cloudflare存在一个名为“边缘缓存过期TTL（Edge cache expire TTL）”的功能，这个功能可以用来覆盖任何已有的头部信息。将该功能设置为启用（on）状态时，服务器返回的带有“no-cache”指令的文件仍会被缓存下来。出于各种原因，在Cloudflare的建议下，该功能通常会处于启用状态。

7.2 IIS ARR

应用程序请求路由（Application Request Routing，ARR）模块可以为IIS带来负载均衡功能。

ARR模块提供的一个功能就是缓存功能。Web服务器可以通过负载均衡器设置缓存规则，以便将文件保存到缓存目录中。在创建新的缓存规则时，我们使用通配符和目标扩展名来定义待缓存的文件类型。当文件经过ARR处理时，ARR会根据文件对应的URL来匹配缓存规则。实际上，ARR会根据URL尾部的扩展名来识别文件类型。

此外，IIS ARR中还包含一个选项，可以忽略掉文件的缓存头部，导致该规则在任何情况下都适用。

如下图这个例子中，IIS ARR与两个web服务器相连接，并且根据配置会缓存所有的样式表和javascript文件。

如果客户端访问恶意URL（http://www.sampleapp.com/welcome.php/test.css），那么缓存目录中就会生成一个新的目录，目录名为welcome.php，在该目录中，会生成名为test.css的一个新的文件，该文件的内容为用户访问的welcome.php页面的内容。

7.3 NGINX

作为负载均衡服务器，NGINX服务器也可以提供缓存功能，来缓存从web服务器返回的页面。

我们可以通过NGINX配置文件来配置缓存规则。如果使用下图所示的配置文件，那么NGINX就会缓存特定类型的静态文件，并且会忽略这些文件的缓存头部。

当来自于web服务器的某个页面到达NGINX时，NGINX会搜索URL尾部的扩展名，根据扩展名识别文件的类型。

首先，缓存目录中没有缓存任何文件。

当经过认证的用户访问恶意URL时（http://www.sampleapp.com/app/welcome.php/test.css），用户的页面就会被缓存到缓存目录中。

接下来，未经认证的攻击者会访问恶意URL，此时NGINX服务器会返回已缓存的文件，文件中包含用户的隐私数据。

八、缓解措施

可以使用以下几种方法缓解此类攻击。

1、配置缓存策略，只有当文件的HTTP缓存头部允许缓存时，才会缓存这些文件。

2、将所有的静态文件保存到某个指定目录，并且只缓存这个目录。

3、如果缓存组件允许的话，需要将其配置为根据文件的具体内容来缓存文件。

4、配置web服务器，使其在处理诸如“http://www.example.com/home.php/nonexistent.css”的页面时，不会返回home.php的内容，而会返回404或者302响应。

九、总结

Web缓存欺骗攻击实施起来没有那么容易，但依然可以造成严重的后果，包括泄露用户的隐私信息、攻击者可以完全控制用户的账户等等。此前我们发现一些知名的网站会受到此类攻击影响，并且这些网站中绝大部分由最为常见的CDN服务商来提供服务。我们有理由相信，此时此刻仍有许多网站会沦为此类攻击的受害者。

虽然这份白皮书中只提到了可以满足web缓存欺骗攻击条件的几种技术，但还有其他许多web框架以及缓存机制存在脆弱性，攻击者可以使用类似技术发起攻击。

如果Web框架以及缓存机制可以创造条件来满足漏洞场景，那么我们认为这些Web框架及缓存机制本身并没有存在这类漏洞，它们的主要问题是脆弱性配置问题。

为了防御web缓存欺骗攻击，技术人员首先应当了解此类攻击发起的条件。此外，厂商应该有所作为，避免他们的产品符合攻击条件。以上要求可以通过禁用特定功能、更改默认设置及行为、提供警报信息以增强技术人员的警觉意识来实现。

十、致谢

感谢Sagi Cohen、Bill Ben Haim、Sophie Lewin、Or Kliger、Gil Biton、Yakir Mordehay、Hagar Livne。

十一、参考资料

http://www.thespanner.co.uk/2014/03/21/rpo/

http://blog.innerht.ml/rpo-gadgets/

https://docs.djangoproject.com/en/1.11/topics/http/urls/

https://serversforhackers.com/c/nginx-caching

http://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html

https://www.youtube.com/watch?v=pLte7SomUB8

https://blog.cloudflare.com/understanding-our-cache-and-the-web-cachedeception-attack/

https://blogs.akamai.com/2017/03/on-web-cache-deception-attacks.html

译者：WisFree

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

写在前面的话

在过去的几个月里，我一直都在认真准备2017年美国Black Hat黑客大会以及DEF CON 25的演讲内容，而成为一个Black Hat以及DEFCON的演讲者一直都是我人生中的一个非常重要的目标。除此之外，这也是我第一次在如此正式的场合下进行英文演讲，这绝对是一个值得回忆并且能够得瑟一辈子的事情！

在这篇文章中，我将会给大家简单介绍我的演讲内容。这里所使用的技术虽然不是什么新技术，但是这些旧的技术依然非常的强大。如果你对我的演讲感兴趣的话，可以点击【这里】获取幻灯片。

注：幻灯片中介绍了很多关于SSRF(Server-Side Request Forgery:服务器端请求伪造)的功能强大的新方法。

直奔主题

在这篇文章中，我将会告诉大家如何将四个漏洞串联起来并且最终在GitHub上实现了远程代码执行。值得一提的是，这份漏洞报告也荣获了GitHub第三届漏洞奖励周年评选中的最佳漏洞报告。

在我上一篇文章中，我提到了一个新的目标- GitHubEnterprise服务（GitHub企业版），并且我还介绍了如何反混淆GitHub的Ruby代码以及如何找出其中存在的SQL注入漏洞。在此之后，我发现有很多赏金猎人也开始将注意力转移到了GitHubEnterprise服务的身上，并且还找到了很多有意思的安全漏洞【参考漏洞一】【参考漏洞二】。

看到了这些WriteUp之后，我就很烦躁了，为什么我当初就没发现这些漏洞呢？？因此，我自己暗下决心，我一定要找到一个高危漏洞!

漏洞描述

在我检查GitHub Enterprise服务的架构之前，我的直觉告诉我，GitHub Enterprise中还存在很多很多的内部服务。如果我可以利用这些内部服务的话，我相信我绝对可以找到很多有意思的东西。

接下来，所有的注意力我都会放在SSRF(Server-Side Request Forgery:服务器端请求伪造)漏洞的身上。

第一个漏洞-无害的SSRF

在寻找GitHub Enterprise漏洞的过程中，我发现了一个名叫WebHook的功能。这个功能非常有趣，当出现了特定的GIT命令时，它允许我们设置一个自定义的HTTP回调。

你可以使用下面给出的URL地址创建一个HTTP回调：

然后通过提交文件来触发回调。接下来，GitHub Enterprise将会通过一个HTTP请求来通知用户。下面给出的Payload和HTTP请求的样本：

Payload URL：

回调请求：

GitHub Enterprise使用了RubyGem faraday来获取外部资源，并防止用户通过Gem faraday-restrict-ip-addresses来请求内部服务。

在这里，Gem就像是一个黑名单一样，我们可以通过RFC 3986定义的稀有IP地址格式（Rare IP Address Formats）来绕过这个黑名单。在linux系统中，"0"代表的是"localhost"。PoC：

非常好，现在我们已经拿到了一个SSRF漏洞了。但是，我们仍然什么都做不了，这是为什么呢？

因为这个SSRF有以下几种限制：

1. 只支持POST方法；

2. 只运行HTTP和HTTPS模式；

3. 没有302重定向；

4. faraday中没有CR-LF命令注入；

5. 无法控制POST数据和HTTP头；

我们唯一能够控制的就是其中的Path部分。但值得一提的是，这个SSRF漏洞可以导致拒绝服务攻击（DoS）。

在GitHub Enterprise中，端口9200绑定了一个弹性搜索服务，在后台使用关机命令的时候，该服务并不会关心其中的POST数据到底是什么内容。因此，我们就可以随意对它的REST-ful API进行操作了！

拒绝服务攻击PoC：

Graphite采用Python语言开发，并且它本身也是一个开源项目，你可以点击【这里】获取Graphite项目的源代码。阅读了Graphite的源代码之后，我迅速地发现了另一个SSRF。第二个SSRF比较简单，这个漏洞存在于webapps/graphite/composer/views.py文件之中：

你可以看到，Graphite会接受用户输入的url地址，然后直接进行资源请求！所以，我们就可以利用第一个SSRF漏洞来触发第二个SSRF漏洞，并将它们两个漏洞组合成一个SSRF执行链。

SSRF执行链Payload：

第二个SSRF的请求：

现在我们已经成功地将这个基于POST的SSRF改成了基于GET的SSRF了。但是，我们还是没办法利用这个漏洞去做任何事情。所以我们还得继续努力...

第三个漏洞-Python中的CRLF注入

你可以从Graphite的源码中看到，Graphite使用了Python的httplib.HTTPConnection来获取资源。在进行了一番研究之后，我发现在httplib.HTTPConnection竟然存在一个CR-LF命令注入漏洞。因此，我们就可以在HTTP协议中嵌入恶意的Payload了。

CR-LF注入PoC：

虽然这看起来我们貌似只前进了一小步，但对于整个漏洞利用链来说却是非常大的进步。现在，我已经可以在这个SSRF漏洞执行链中引入其他的协议了。比如说，如果我想对其中的Redis动手，我们就可以尝试使用下列Payload：

注:Redis的slaveof命令可以允许我们使用带外数据，当你用户到某些Blind-SSRF时这种技巧是非常实用的。

不过，在可利用的协议方面还是存在有很多的限制：

1.像SSH、mysql和SSL这种需要进行握手的协议将会失效；

2.由于Python2的原因，我们在第二个SSRF中所使用的Payload只允许0x00到0x8F字节的数据。

顺便提一下，我们还有很多利用HTTP协议的方法。在我的演讲幻灯片中，我还演示了如何使用Linux Glibc来修改SSL协议。除此之外，你也可以参考漏洞CVE-2016-5699！如果你感兴趣的话...

第四个漏洞-不安全的反序列化

目前为止，我们已经能够在HTTP协议中利用其他的协议或嵌入Payload了，但是接下来的问题就是，我应该选择哪一个协议呢？如果我能够控制Redis或Memcached的话，我能够触发哪一个漏洞呢？

我花了很多时间来弄清楚上面这些问题，在检查相关源代码的过程中，我比较想知道GitHub为什么会在Memcached中存储Ruby对象。在研究了一阵子之后，我发现GitHub Enterprise使用RubyGem mecached来处理缓存，而缓存的封装是通过Marshal实现的。这就非常棒了，因为所有人都知道Marshal是非常危险的，所以我们接下来的目标就非常清晰了。

我准备使用之前的SSRF漏洞执行链在Memcached中存储恶意Ruby对象。当GitHub下一次获取缓存时，RubyGem memcached将会自动对数据进行反序列化操作，而结果就是...要爆炸！！因为我们在GitHub上实现了远程代码执行（RCE）。

Rails控制台中不安全的Marshal：

没错，就是这样。现在我们重新梳理一下整个过程：

1.第一个SSRF漏洞，可以绕过WebHook中现有的保护机制。

2.第二个SSRF漏洞，存在于Graphite服务之中。

3.结合第一个和第二个SSRF漏洞，组成SSRF漏洞执行链。

4.SSRF执行链中的CR-LF注入。

5.利用Memcached协议，注入恶意Marshal对象。

6.触发远程代码执行。

演示视频

漏洞利用代码

漏洞修复

GitHub采取了以下措施来防止相关问题再次发生，并提升了网站安全性：

1.增强了Gem faraday-restrict-ip-addresses；

2.采用了自定义的Django中间件来确保攻击者无法从外部访问http://127.0.0.1:8000/render/；

3.增强了iptables规则；

时间轴

2017年01月23日23:22：通过HackerOne将漏洞上报给GitHub，报告编号为200542；

2017年01月23日23:37：GitHub将报告状态修改为已分类；

2017年01月24日04:43：GitHub确认了漏洞，并表示正在修复相关问题；

2017年01月31日14:01：GitHub Enterprise 2.8.7发布；

2017年02月01日01:02：GitHub回复称漏洞已成功修复；

2017年02月01日01:02：GitHub提供了7500美刀的漏洞奖金；

2017年03月15日02:38：GitHub又提供了5000美金的年度最佳漏洞报告奖励；

作者：PegasusTeam && 天巡实验室

某个深夜，洗漱完毕正要入睡时，邮件提醒“滴”的一声。深夜邮件到，一般意味着事情比较紧急。打开邮件，明天需要去客户那边做一次黑盒的无线渗透测试。

1.信息收集

早上10点抵达邮件中给的地址。跟客户碰了下面，听取了他们的需求及要看到的结果。找了一个休息室，打开我那新买的闪闪发黑的Thinkpad x1 准备干活了。

观察了下附近的热点，有两个特殊的：一个是带企业英文前缀的802.1X认证热点，另一个是同样前缀的开放式Guest网络。根据经验来看，802.1X认证为企业内部人员使用的，而Guest网络提供给访客使用。先暂时不对这两热点下手，寻找下是否存在能通关捷径——员工私自建立的热点。

这类员工为了方便手机上网私接在内网热点，为了便于共享给周围其他同事用，往往都没有采用过于复杂的密码，同时还存在被同事分享密码的风险。

2.私建热点渗透

开着修改版的WiFite扫描整栋楼，收集所有的无线热点信息，并且回传到云端；与此同时手机打开WiFi万能钥匙APP，检测是否存在有被分享密码的热点。

在低楼层一直没发现有钥匙标识，有些办公室不好太大直接抱着电脑进去。功夫不负爬楼人，终于在顶楼5楼的某个办公室门口发现了可使用共享秘钥连入的热点。连上后，直接直奔路由器后台，默认admin密码直接登录。

很遗憾，是个4G路由器。虽然能对网络内的用户进行中间人攻击获取信息，不过不到万不得已一般不这么干，因为这种方式拿到的成果一般不会被客户所认可。

3.802.1x渗透

逛了半天回到休息室歇歇脚的同时，做下针对802.1X认证的钓鱼攻击吧。

利用hostapd建立同名802.1X钓鱼热点，同时用aireplay-ng发了些deauth包，这样周围连接过此热点的人都会尝试连接我的热点了。不一会便抓到了数条hash。安全意识好的企业一般会对员工密码有强度要求，密码规则复杂、较长的密码。如果是这样的密码，我们就很难用字典碰撞出密码了。但是这里运气很好，客户这边并没有实施较高的密码强度策略，使用JTR自带的字典就跑出来了。定睛一看，原来用户名与密码相同呀。

利用这组账号连接802.1X网络，成功进入了办公网络。

再仔细观察了下这组数字账号，带着怀疑试了试将数字加一进行登录测试，也成功了。好吧，默认密码跟用户名相同，同时用户名为数字编号可遍历。

4.Guest网渗透

通过802.1x热点已经能进入办公网了，算是已经完成任务了。不过现在时间还早，于是我继续对Guest网络进行渗透测试。连上Guest网络，自动弹出Portal认证页面。

Portal认证的网络一般会存在以下问题：

1. ACL配置不严格，未授权访问内网资源。

2. Portal存在致命漏洞，导致Portal认证服务器被黑。

3. Portal登录验证存在漏洞，可以穷举账户密码。知识点:CMCC扫号

此次办公网、管理网被渗透，就是因为Portal本身存在存在致命的漏洞，导致可以通过Guest网段跨入核心网络。

刚接入网络时，发现所有的扫描被重定向至网关机器，说明有ACL，未授权访问内网资源这条路行不通。接着准备穷举账户，再根据已知的账户来穷举密码。很多Portal都存在如下问题：

用户不存在返回页面

用户存在，密码不正确返回页面

但是在这个Portal，无论输入正确或者不正确的用户名都返回"用户或密码错误"(用户名是员工名字全拼，员工工牌挂身上，相信正确的用户名难不倒大家)，也就意味着我们无法穷举用户。此时我的思路是根据用户名规则生成常见的用户名，密码使用弱口令如“123456、1q2w3e、1qaz2wsx”等密码进行穷举。

在观察数据包时，突然发现登陆页面的后缀是.action，立马想到会不会存在Struts2漏洞呢？毕竟不是大型的互联网公司，无专业的安全人员，在内网中系统存在古老的漏洞也不奇怪(比如2014年在某单位做渗透测试，用08067打下了一批机器)。

操起基友给我struts的神器，输入网址，点击"验证"按钮，从古到今的所有struts2漏洞的一个一个在后台进行验证，当我看到输出栏输出"Struts-045漏洞存在"时，我在心理给自己鼓了掌，成了，root到手。

其中在这里发现一点小插曲，我当时要上传一个"jspspy"的shell，存在的问题是会如果上传的后缀是.jsp的文件，就会重定向login.action的页面，不管是静态文件目录还是脚本文件目录都是一样会重定向，由于对Java不熟悉，我给我大哥"Ninty"打了一个电话，大哥说上传图片目录试试或者过滤器规则写的不严谨，可以bypass。

挂完电话，按照大哥给我的思路，先上传jsp文件，之后后缀添加;.js（使用";"来bypass的过滤器）, 很好可以解析，看到了熟悉的"jspspy"页面。顺手把bypass截图发回给了Ninty大哥，毕竟这至高无上的荣誉是大哥给我的。根据国家法律规定传播黑客工具，导致网站被攻击，需要判刑。嗯，那么也就是说“我再多用几次jspspy，那我大哥离进去就不远了”。

这时候我们拥有了Portal机的服务器权限，同样可以挂马社工客户，再利用客户的机器在进一步的内网渗透。但这样的攻击手法存在很大的风险，修改前端页面轻则造成误伤其他访客，重则可能会整个Portal无法使用。

经过一番讨论后，决定询问客户的意见是否还需要深入渗透。客户答案是想要测试能漫游内网（访问办公网及管理网），目前这个效果不是很明显，而且客户信誓旦旦的告诉我说，Guest网络是隔离网段，不可能访问办公网及管理网，还问我有多大把握可以跨过去。我当时脑子一热，说百分之九十吧。说完就有点虚，毕竟客户比我更熟悉他们的网络环境，人家都说是隔离的，而我还说有90%的把握，越想越觉得我有点吹逼呢！！既然牛逼自己吹了，只能吭哧吭哧干活，就像老马说的"梦想还是要有的，万一实现了呢？"，经过沟通之后，客户可以让我们使用这台Portal作为跳板机进行渗透。

5.内网渗透

在得到了客户授权后，我们给跳板机新添加了一个账户，ssh上去拿到了一个tty shell，方便后续的渗透。使用banner-scan对内网机器http banner进行了扫描，除了有个H3C的交换机开着Webserver，其他机器并没有开放Webserver服务。从Web下手这条路是走不通了。

既然Web无法走通，那么只能寻找内网中其他的漏洞可以利用，假如存在域环境我还可以看看gpp，ms14068等漏洞，但是这次是工作组环境，比域环境还要复杂一些。目前想法是从服务下手，看看是否会存问题的服务。使用nmap进行扫描，结果发现存在MongoDB，Rsync，Redis等服务。经过测试，MongoDB虽然存在未授权访问，但是里面的数据没有什么用处，rsync不存在问题。只能寄希望于Redis。果然，Redis存在未授权访问，反弹Shell回来添加了一个账户。

拿到redis服务器权限后，netstat -antp 查看网络连接，并没有发现跟"办公网及管理网"网络有通信的建立，也无法ping通“办公网及管理网”网络。一时陷入僵局，难道今天真的要打脸了？无法跨过去这个网段了？革命尚未成功,同志仍需努力啊。其他的机器虽说存在mysql、oracle等服务，但是这两个服务并不存在能远程利用的漏洞，只能用爆破密码这种方式，爆破攻击在渗透中我个人很少用。爆破攻击存在以下缺陷：

1. 耗费时间过长

2. 会产生大量日志

3. 有可能造成账户锁定

为了不必要的麻烦，没有选择去爆破Mysql，Oracle等服务，而是从Redis机器进行收集信息，看看是否能有一些新的发现。在启动进程，端口，history，home目录中都没有发现有我想要的信息。使用find命令搜uname、user等信息时也没有很大的收获。结果在/etc/发现存在nginx的配置，Web Root目录指向\var\www\，原来此时nginx并没有启动。

进入到\var\www\目录之后，尝试能否在源码中找到邮件密码或者数据库密码之类的，提取关键信息后再扩大渗透范围。在网上找了个解密网站，对config.php文件解密，解密后的源码中发现数据库的IP地址是guest网络里另外一台机器，存储直接使用的是Elasticsearch。

Elasticsearch出过几次严重的代码执行漏洞，经过测试果然这台机器上发现存在CVE-2015-1427漏洞，通过netstat -an发现跟"管理网"有通信，跨网段任务完成了一半。顺手试了下，也可以Ping通“办公网”。很好，意味着通过Elasticsearch的机器我们完成了吹下的牛逼，打通了任督二脉，走向管理网及办公网。

总结

由于某些原因，内网渗透部分图片能提供较少，请大家关注文字部分。

WIFI默认属于不安全的网络，很多企业的防护措施都放在边界安全(Web、服务等漏洞)上，对WIFI网络不重视,导致出现第三方设备漏洞、或者ACL划分不严格的等问题，通过WIFI打破边界，进入内网的核心地带渗透事件层出不穷，希望企业能重视WIFI安全。

译者：興趣使然的小胃

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、前言

作为FLARE团队的一名逆向分析工程师，我需要使用定制的虚拟机（VM）来分析恶意软件。这种虚拟机使用的是Windows系统，里面内置了许多小工具，可以辅助恶意软件分析过程。不幸的是，为了维护这样一个定制版虚拟机我们需要付出许多精力：里面的工具经常会过期，并且我们很难改变或添加新的东西。还有一个问题，如果虚拟机不小心损坏了，想要完全复制我费尽多年心思调整的设置及收集的工具是一个非常烦人的过程。为了解决这些难题，我研发了一种标准化的（同时定制起来也非常简单的）、基于Windows的用于安全研究的虚拟机，即FLARE VM。

FLARE VM是一款以Windows为基础的免费开源的虚拟机，专为逆向分析工程师、恶意软件分析研究员、事件响应人员、安全取证人员以及渗透测试者设计。FLARE VM借鉴了基于linux的安全开源发行版的思想（如Kali Linux、REMnux以及其他Linux发行版），提供了经过全面配置的一个平台，全面集成了Windows安全工具，包括调试器、反汇编器、反编译器、静态及动态分析工具、网络分析及网络操作工具、Web资产评估工具、漏洞利用工具、漏洞评估等应用程序。

FLARE VM中还包含FLARE团队研发的公开版恶意软件分析工具，如FLOSS以及FakeNet-NG等。

二、如何获取

首先你需要安装Windows 7或更高版本的操作系统，这样你就能自己选择所需的Windows版本、补丁级别、系统架构以及虚拟化环境。

完成上述步骤后，你可以在IE浏览器中访问如下链接快速部署FLARE VM环境（不能使用其他浏览器）：

http://boxstarter.org/package/url?https://raw.githubusercontent.com/fireeye/flare-vm/master/flarevm_malware.ps1

在IE浏览器中访问该URL后，浏览器会弹出一个Boxstarter WebLauncher对话框。点击“Run”按钮，继续安装过程，如图1所示。

图1. 安装FLARE VM

成功安装完Boxstarter WebLauncher后，你会看到一个控制台窗口，提示你输入Windows密码，如图2所示。安装过程中会多次重启系统，为了实现自动登录，你需要在此提供Windows密码。

图2. Boxstarter密码提示窗口

接下来所有的安装过程是完全自动化的，你可以倒上一杯咖啡或茶，休息一下。初始安装大概需要30-40分钟，具体时间取决于你的网络连接速度。由于这个过程需要安装多种软件，因此系统会重启若干次。在部署过程中，你可以从安装日志中找到具体安装的软件包。

安装完成后，强烈建议你将虚拟机网络切换到仅主机（Host-Only）模式，防止恶意软件样本自动连接到互联网或本地网络。另外，我们也建议你将新安装的状态保存为虚拟机快照。FLARE VM安装完后的界面如图3所示。

图3. FLARE VM安装

注意：如果在安装过程中碰到大量错误信息，你可以尝试重新安装。重新安装时会保留已安装的软件包，安装新的软件包。

三、新手上路

虚拟机的配置以及内置工具的选择都经过FLARE团队的研发或精心挑选，团队成员在恶意软件逆向分析、漏洞分析及利用、恶意软件分析教学方面有十多年的资深经验。这些工具在本地磁盘中的目录结构如图4所示。

图4. FLARE VM工具集

我们尝试在FLARE文件夹中以快捷方式提供所有工具的使用接口，但某些工具只能通过命令行来使用。大家可以参考在线文档，了解最新的工具列表。

四、样本分析

为了向大家展示FLARE VM在恶意软件分析方面的优秀表现，我们可以利用它来分析某个示例样本，该样本也是我们在恶意软件分析课程中使用的一个示例样本。

首先，我们可以搜索样本文件中的字符串，提取一些基本信息。在本次实验中，我们准备使用FLARE自己研发的FLOSS工具来完成这一任务，该工具是一个字符串分析工具，大家可以访问该网址了解该工具的更多信息。你可以点击任务栏中的FLOSS图标运行此工具，使用它来分析样本，如图5所示。

图5. 运行FLOSS

不幸的是，工具的输出结果中只有一个字符串比较特别，并且我们现在还不知道该字符串的具体用途，如图6所示。

图6. 字符串分析

我们需要深入分析这个样本，打开CFF Explorer，分析样本的导入表、资源以及PE头部结构。我们可以从桌面或者开始菜单中找到FLARE文件夹，里面包含CFF Explorer以及其他许多工具，如图7所示。

图7. 可以使用的工具集

分析PE头部时，我们通过几条线索发现该样本文件中包含一个具有附加载荷的资源对象。比如，导入地址表（Import Address Table）中包含与资源对象有关的Windows API调用，如LoadResource、FindResource以及WinExec。不幸的是，样本内置的“BIN”载荷中包含垃圾数据，因此这些信息可能经过加密处理，如图8所示。

图8. PE资源

此时此刻，我们可以继续进行静态分析，或者我们可以使用稍微“骗人”的方法，也就是采用基本的动态分析技术。 我们可以尝试使用另一款FLARE工具——FakeNet-NG——来收集基本线索。FakeNet-NG是一款动态网络仿真工具，可以为恶意软件提供伪造的服务（如DNS、HTTP、FTP、IRC以及其他工具），欺骗恶意软件，使恶意软件暴露其网络功能。大家可以访问此网址了解该工具的更多信息。

此外，我们还需运行Sysinternals Suite中的Procmon工具，以便监控样本的文件、注册表以及Windows API行为。你可以在任务栏中找到这类常用工具，如图9所示。

图9. 动态分析

以管理员权限运行恶意软件样本后，我们很快就找到了样本的网络及主机特征。FakeNet-NG响应了恶意软件的请求，如图10所示，恶意软件试图使用HTTP协议与evil.mandiant.com通信。这里我们捕捉到一些有价值的特征，如完整的HTTP头部信息、URL以及可能是独一无二的User-Agent字符串。此外，FakeNet-NG识别出负责通信的具体进程为level1_payload.exe。这个进程名与我们在静态分析中提取到的独特字符串相符，当时我们还不知道这个字符串所代表的具体含义。

图10. FakeNet-NG

Procmon的输出结果如图11所示，将该结果与我们已掌握的信息进行对比，我们可以确定恶意软件的确会在system32目录中生成level1_payload.exe可执行程序。

图11. Procmon

作为恶意软件分析过程中的一个环节，我们可以继续深入分析，在反汇编器中加载恶意样本，然后在调试器中继续分析样本。然而，我不想在这里就把所有答案揭晓，这样就会失去恶意软件分析教学中的乐趣。能够完成此类分析任务的相关工具都已集成到该虚拟机中，如IDA Pro、Binary Ninja反汇编器、许多优秀的调试器以及插件，还有其他一些工具等，这些工具能够让我们的逆向分析任务事半功倍。

五、如何定制

FLARE VM是一个不断发展和改变的项目。虽然我们想尽可能覆盖所有使用场景，然而项目的内在特性决定了这是无法完成的任务。幸运的是，由于FLARE VM建立在Chocolatey项目的基础上，因此定制起来非常简单。Chocolatey是一个基于Windows的软件包管理系统，包含上千个软件包，你可以在该网页中找到项目支持的软件包列表。除了使用公开的Chocolatey仓库之外，FLARE VM也使用了自己的FLARE仓库，这个仓库的规模会随着时间的推进不断增长，目前已包含40个软件包。

这样一来，如果你想快速添加某些软件包（比如Firefox），你再也不需要去访问软件开发者的网站，只需要打开控制台，输入命令就能自动下载及安装任何软件包，如图12所示。

图12. 安装软件包

经过短暂的等待，无需用户交互，Firefox就会自动安装完毕，你可以在桌面上找到Firefox图标。

六、保持更新

我们在本文开头就提到过，非托管型虚拟机最大的一个难题就是如何保持所有工具处于最新版状态，FLARE VM完美解决了这个问题。通过一条命令，我们就能完全更新整个系统，如图13所示。

图13. 保持更新

如果已安装的软件包存在更新的版本，那么新版本就会被自动下载及安装。

注意：更新系统后别忘了做个纯净版的快照，同时将网络切换为仅主机模式。

七、总结

希望大家喜欢这个新的免费工具，信任这个工具，在逆向工程及恶意软件分析任务中充分发挥它的能力。下一次如果我们需要创建一个新的恶意软件分析环境，可以尝试FLARE VM。

受本文篇幅所限，我们只是稍微介绍了FLARE VM所具备的能力，如果大家在使用过程中有任何意见或建议，可以到Github页面或者相关页面进行反馈。

译者：WisFree

预估稿费：170RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

大概在八个星期之前，研究人员在Samba中发现了一个严重的安全漏洞，该漏洞提交之后不久便被成功修复，但值得一提的是，从2010年起的每一个Samba版本都存在这个漏洞。这个漏洞名叫“SambaCry”，在WannaCry席卷了全球的windows系统（永恒之蓝的SMB漏洞利用部分）之后，SambaCry也浮出了水面。这个漏洞属于逻辑漏洞，它将允许只拥有写入权限的攻击者加载恶意Samba模块并执行任意代码。

安全客小百科:Samba和SMB

Samba是在linux和UNIX系统上实现SMB协议的一个免费软件，它由服务器端及客户端程序构成。而SMB（Server Messages Block，即信息服务块）是一种在局域网上共享文件和打印机的一种通信协议，它可以为局域网内的不同计算机之间提供文件及打印机等资源的共享服务。SMB协议是客户机/服务器型协议，客户机通过该协议可以访问服务器上的共享文件系统、打印机及其他资源。用户可以通过对“NetBIOS over TCP/IP”进行配置来让Samba不但能与局域网内的主机分享资源，而且还能与整个互联网上的电脑分享资源。

就在针对该漏洞的POC代码首次发布之后，我立刻编写了一个可以匹配针对潜在Payload的Yara签名（规则），然后开始监测针对该漏洞的威胁信息。观察了一段时间之后，我们发现了无数的反向Shell以及恶意Payload Dropper，其中绝大多数都是Metasploit Payload或其他一些公开可用的恶意代码植入。

在今年的六月九号，卡巴斯基实验室发布了一篇关于“EternalMiner”的文章，这是一款以经济利益为目的的加密货币挖矿恶意软件，它可以将目标用户的设备变成一台矿机，并利用受感染设备来为攻击者挖比特币之类的加密货币。不到一个星期之后，我们还发现了很多模仿这种操作模式的网络犯罪分子在改进了漏洞利用代码之后，能够更好地控制目标设备进行挖矿了。根据这种攻击的性质，我们决定将这种威胁取名为“CopyMinner”!

1. 概述

正如我们之前所提到的那样，网络犯罪分子们正在改进原本的“EternalMiner”，并且使用更加高级的“CopyMinner”来实施攻击。这些攻击者会采用多种灵活的方法配合多台备份服务器来实现恶意软件的每日定期更新，这样不仅可以实现更加持久化的后门，而且还可以帮助攻击者更好地控制目标设备并充分利用目标用户的资源来为他们挖矿。这些网络犯罪分子们已经将原来的EternalMiner升级到了另一个境界，而且现在甚至还可以同时控制多台目标设备。在接下来的章节中，我们将会对下图中的每一个组件进行详细的分析，并分析CopyMiner和EternalMiner之间的区别。

2.CopyMinner Dropper

在今年的六月十四号，我们向VirusTotal提交了一个小型的Dropper样本。这个Dropper首先会执行其中的“samba_init_module”输出模块，然后尝试从攻击者所控制的后台服务器获取Payload，最后以root权限在目标设备的后台运行恶意代码。整个过程是通过一个经过混淆处理的硬编码bash代码完成的，具体如下图所示:

样本哈希：

444d0fae73e1221b81dc6c5d53cf087afa88248fc22ef36e756841ab04df24a

3.Payload

恶意Payload其实是一个非常短小精悍的Bash脚本，它需要依赖于目标设备的系统工具来完成以下三个主要任务：

（1）使用crontab命令完成恶意程序的每日定期更新，这个过程需要使用到三台不同的备份服务器：

http://update.sdgndsfajfsdf.info/upd

http://update.sdgsafdsf.pw/upd2

http://update.omfg.pw/upd3

（2）在后台下载并执行Tsunami后门以及CPUMiner。

（3）防止其他的攻击者攻击这台用户设备（修复smb.conf），目的是避免出现资源竞争的情况，因为挖矿需要消耗大量的计算资源。

我们还可以从其中一台在线服务器（http://update.sdgndsfajfsdf.info/upd）中获取到负责处理每日更新任务的脚本。但是看起来这个脚本是一个精简版本的Payload脚本，因为它缺少了每日更新补丁的安装功能：

4.CPUMiner

5.Tsunami后门

6.迅速上线

我们发现，这些用来托管Payload文件的后台主机和服务器所使用的域名都是在今年的六月十三号注册的，而第二天便有恶意CPUMiner以及Tsunami样本上传到了VirusTotal，也就是六月十四日，这也就意味着攻击者在原始的EternalMiner版本发布之后的四到五天时间里便开始了CopyMinner活动。

7.入侵威胁指标IoC

热点概要：渗透测试中的certutil、通向内网的另一条路：记一次无线渗透测试实战、hacking投票机DEFCON25（2017）、CVE-2017-0190：针对能导致代码执行的WMF漏洞分析、逆向工程一个javascript混淆Dropper

国内热词(以下内容部分摘自http://www.solidot.org/)：

WikiLeaks 公开 Macron 竞选团队的电子邮件

Tor 联合创始人称，暗网并不真正存在

资讯类：

美国Mandiant网络安全公司疑遭黑客入侵，部分文件可公开下载

http://bobao.360.cn/news/detail/4244.html

暗网新闻：

丝绸之路3恢复访问,官方称此前遭受DDOS攻击

http://silkroad7rn2puhj.onion/

暗网主机托管商被入侵91个暗网站点被黑

https://www.deepdotweb.com/2017/07/26/major-darknet-host-hacked-data-exfiltrated/

比特币btc-e运营商被逮捕，被指控洗钱40亿美元，或与Mt Gox黑客有关联

https://www.deepdotweb.com/2017/07/30/bitcoin-news-roundup-july-30-2017/

Koadic：一款类似Meterpreter和Powershell Empire的windows后渗透工具

https://github.com/zerosum0x0/koadic

在任何可能的地方测试XSS漏洞

https://bo0om.ru/xss-everywhere

渗透测试中的certutil

https://3gstudent.github.io/3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%B5%8B%E8%AF%95%E4%B8%AD%E7%9A%84certutil.exe/

hacking投票机DEFCON25（2017）

https://blog.horner.tj/post/hacking-voting-machines-def-con-25

通向内网的另一条路：记一次无线渗透测试实战

http://bobao.360.cn/learning/detail/4178.html

Volatility, my own cheatsheet (Part 6): Windows Registry

https://andreafortuna.org/volatility-my-own-cheatsheet-part-6-windows-registry-ddbea0e15ff5

linux堆漏洞利用系列：使用和滥用UAF漏洞

https://sensepost.com/blog/2017/linux-heap-exploitation-intro-series-used-and-abused-use-after-free/

社工库杂谈

https://bbs.ichunqiu.com/thread-20469-1-1.html

逆向工程一个JavaScript混淆Dropper

http://resources.infosecinstitute.com/reverse-engineering-javascript-obfuscated-dropper/

CookieCatcher：一款XSS平台

https://github.com/DisK0nn3cT/CookieCatcher

Many iOS/MacOS sandbox escapes/privescs due to unexpected shared memory-backed xpc_data objects

https://bugs.chromium.org/p/project-zero/issues/detail?id=1247

Windows Kernel Debugging livestreams

http://gynvael.coldwind.pl/?lang=en&id=656

RITA在威胁情报分析中的应用

http://www.darkreading.com/vulnerabilities---threats/introducing-rita-for-real-intelligence-threat-analysis/a/d-id/1323244

Eternalromance: 攻击Windows Server 2003

http://www.hackingtutorials.org/exploit-tutorials/eternalromance-exploiting-windows-server-2003/

攻击加密数据存储(DPAPI edition)

https://posts.specterops.io/offensive-encrypted-data-storage-dpapi-edition-adda90e212ab

不使用任何已知的C/C++ Hook Windows事件

https://blog.huntingmalware.com/notes/WMI

逆向工程恶意软件

https://r3mrum.wordpress.com/

CVE-2017-0190：针对能导致代码执行的WMF漏洞分析

https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2017-0190-wmf-flaws-can-lead-data-theft-code-execution/

译者：shan66

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

许多人可能会有一种错觉，那就是在Windows 10 S上执行非Microsoft代码是非常困难的。不过，就像您在前面的文章中看到的那样，事实并非如此，您需要的，无非就是安装Office，获取编写VBA宏脚本的权限，以及一个不含有MOTW的文件。事实上，Windows内核只是对加载可执行文件和DLL做了限制。但是，已经获取相应签名的应用程序将会畅行无阻，例如Office可以创建自己的可执行内容，而这些内容却可能被用户或攻击者所滥用。

因此，您可能还会认为，由于Windows默认安装了许多不同的脚本引擎，因此可以轻松运行任意代码。且慢，许多内置的脚本引擎（如运行JScript/ VBScript的Powershell和Windows Scripting Host（WSH））都是“开明的”。这意味着当它们检测到启用UMCI时，它们将进入锁定模式，例如PowerShell的约束语言模式。如果正在执行的脚本也使用了与二进制可执行内容相同的证书集进行的签名，则这些开明的主机将解锁脚本语言的全部功能。通常情况下，有许多办法可以绕过这些限制，但是，这里只是围绕Windows RT进行介绍。此外，如果有兴趣的话，您可以在这里找到关于BlueHat旁路技术的完整演示文稿。

但从Win10S开始下手也是一个不错的选择。绕过上述限制时，主要求助于脚本引擎，但是就像之前文章中提到的那样，DG策略也提供了相应的黑名单。还有一些其他知名的恶意软件，如MSBuild也被列入了黑名单。所以我想我们必须回到最初的设想：默认的Win10S系统还有很多可执行文件可以被滥用，我们只需要找到它们即可。

关于BinaryFormatter

对象序列化框架通常蕴含着丰富的代码执行漏洞，而.NET也不例外。 不久之前，我在.NET中发现了一个处理WMI类方面的RCE。 您可以在这篇博客文章中阅读更多详细信息，但是简单来说，就是可以将任意字节流传递给内置的BinaryFormatter类，并从内存中加载程序集进而执行任意代码。

虽然不太明显，实际上这也是一种DG旁路技术。尽管PowerShell允许您以约束语言模式来查询任意的WMI服务器和类，但是.NET运行时并不是“开明的”，所以它将从一个字节数组中加载程序集。从字节数组加载很重要，因为正常情况下，.NET将从需要映射到内存的可执行文件中加载程序集。将可执行文件映射到内存中的行为会触发内核中的CI模块来验证签名，根据配置的CI策略，将不允许加载任何代码。对于字节数组，内核不会将程序集视为.NET，所以会进行处理并从中执行任意的托管代码。然而，DCOM漏洞已经被修复了，PowerShell会被阻止，所以我们无法调用WMI方法。但是，如果我们可以找到另一个应用程序，它可以使用字节数组并将其传递给BinaryFormatter，那么，我们就可以重用我以前的漏洞利用中使用的反序列化漏洞链，并使用它来绕过内存中的DG保护。

这里考察的重点是在％SystemRoot％\ Microsoft.Net目录中的可执行文件，其中许多是用.NET编写的，因此很可能可以加以利用。首先引起我的兴趣的是AddInProcess.exe，这主要归功于它的名称。这是一个个可执行文件，实际上，之前我就从Partial Trust沙箱转义的角度对它进行过研究。

这个代码是.NET 4中引入的插件模式的一部分。插件模式提供了一个结构化框架，提供了某些功能，以便于第三方向现有应用程序添加附加功能。为此，开发者需要开发相应的接口，建立管道以及许多其他复杂的工作，但是我们并不关心这些。 有趣的是，这个模式支持Out-of-Process（OOP）插件，这在是AddInProcess的用途。为了托管这些OOP插件，需要启动一个可执行文件。而这个可执行文件的主函数其实很简单，如下所示：

这里要指出的是，它使用ChannelServices.RegisterChannel：这表明它正在使用.NET的远程处理技术进行通信。对了，之前我们还在哪里看到过.NET远程处理技术呢？ 哦，没错，是我最后一次破解.NET远程处理技术的时候。但是这里的重点在于，它不仅使用了可以被破解的.NET远程处理技术，而且还以Full TypeFilterLevel模式使用了BinaryFormatter，这意味着我们可以对任何数据进行反序列化，而不必担心各种安全限制。

我们需要使用--useser标志与ExploitRemotingService工具，这样就可以不借助于MS已经修复的旧漏洞了。这个useser标志可以发送序列化对象，并从服务器返回，从而允许执行文件操作，如列出目录以及上传/下载文件等。需要注意的是，只有在TypeFilterLevel设置为Full时才这样做才有效。这表明远程通道容易受到任何反序列化的影响。所以，您可以借助我的工具，从.NET DCOM漏洞利用代码中截取相应的字节，替换序列化的字节，这样就可以在AddInProcess的上下文中执行任意代码了。

需要注意的是：如果发送数据到这个IPC服务器的唯一方法是运行一个专门设计来与.NET远程服务通信的、我们可以运行任意代码的工具的话，那么我们就无需旁路了。由于这个通道是一个命名管道，那么，我们是否可以远程利用它呢？很可惜，.NET Framework在这个创建命名管道的时候，使用了一个阻止网络访问的显式安全描述符。

理论上，我们可以修改权限，但就算我们找到了这样的工具，也还是需要另外一台机器——太麻烦了。那么该怎么办？幸运的是，对于我们来说，.NET远程处理协议非常简单。在连接开始时，它没有进行协商，客户端只需将正确格式化的字节集（包括头文件和序列化消息）发送到服务器即可，如果正确，那么服务器将给予响应。我们可以提前创建一个包含序列化请求的二进制文件，并将其写入命名管道。如果我们利用ExploitRemotingService封装请求，并结合之前的.NET序列化漏洞，我们就可以生成一个攻击.NET AddInProcess服务器的二进制文件。

如果我们有一个名为request.bin的文件，则将其写入命名管道最简单的方法，就是使用CMD：

太好了，这的确很简单，不过......我们不能运行CMD。那么，我们还能用什么？ 当WSH被阻止时，我们仍然可以在regsvr32中运行scriptlet。 但是，脚本托管环境是开明的，在JScript / VBScript的情况下，意味着在创建的COM对象方面会受到严格的限制。 您可以创建的唯一对象是Scripting.FileSystemObject，它允许您打开任意文本文件并进行读/写操作。同时，它支持打开命名管道，并使用这一功能来处理进程输出。 因此，您可以通过下面的操作将任意数据写入命名管道。

不过，事情没有这么简单。请求数据是任意二进制的，所以我最初尝试使用一个Unicode文本文件，这使得二进制数据的写入变得容易起来。在创建构成请求的文件时，该类首先会写入一个字节顺序标记（BOM）。所以，我开始尝试ANSI模式，但是这会将UCS-2字符从JScript转换为当前的ANSI代码页。在英文Windows系统上，这通常是代码页1252，您可以在UCS-2字符和任意8位字符之间构建映射表。但是，如果您的系统被设置为另一个代码页，例如更复杂的多字节字符集之一，如Shift-JIS，这就难办了。无论如何，我敢肯定，将来可以设法让它在更多的平台上工作，使其可以加载任何任意的.NET代码，并通过DG Win10S强制策略执行这些代码。

我已将代码上传到我的github。您可以在另一台计算机上运行CreateAddInIpcData工具，只要提供IL-only .NET程序集的路径和输出scriptlet文件的名称即可。确保给scriptlet文件提供一个.sct扩展名。 .NET程序集必须包含单个具有空构造函数的公共类，以在反序列化期间充当入口点。类似下面代码的C#_也可以，只需编译成一个类库程序集即可。

将输出脚本文件复制到Win10S机器。使用前面的命令行启动AddInProcess（确保GUID与前面的相同，因为端点URI以序列化请求结尾），并指定PID（从任务管理器获取）。 确保AddInProcess可执行文件不会立即退出，因为这将在命令行中显示错误信息。 执行scriptlet时，可以通过在资源管理器中右键单击它，并选择“注销”，或从资源管理器的“运行”对话框中手动输入以下命令：

您现在应该会发现，任意.NET代码都可以在AddInProcess的上下文中执行了。这样，除了从磁盘上的文件加载未签名的.NET程序集外，您还可以随意编写自己喜欢的代码了。

好了，该说的都说了。应该清楚的是，现在UMCI和.NET搭配得还不太好，就像4年前当我用类似的技巧来攻击Windows RT时一样。当然，我不知道Microsoft未来是否会限制从内存中加载.NET程序集。

如果您担心这种安全漏洞，您可以在DG或Applocker策略中阻止AddInProcess。然而，除非Microsoft找到了.NET应用程序混淆代理绕过CI策略的解决方案，否则，肯定还会有其他的旁路技术。如果您打算将该二进制文件添加到自己的DG策略中的话，建议您按照这篇文章中的说明进行操作。此外，不要忘了同时将AddInProcess32加入黑名单。

在后面的文章中，我们将利用这个任意代码执行漏洞来运行一些其他的分析工具，甚至可以提供反向Powershell——从这里可以看出，.NET的确是个好东东，所以你应该始终使用.NET来编写自己的工具。;-)

作者：興趣使然的小胃

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、前言

恩智浦（NXP）半导体公司生产的i.MX系列应用处理器的安全启动特性中存在两个漏洞，这两个漏洞由Quarkslab的两名研究人员Guillaume Delugré和Kévin Szkudapski发现，本文对这两个漏洞的技术细节做了具体分析。

攻击者可以利用这两个漏洞破坏安全启动过程，从而绕过代码签名认证，实现在启用了HAB（High Assurance Boot）特性的i.MX应用处理器上加载并运行任意代码。有12款i.MX系列处理器受这些漏洞影响。

研究人员于2016年9月发现这些漏洞并将漏洞报告给厂商，在2017年5月19日的举办高通移动安全峰会上，Quarkslab与NXP联合公布了本文介绍的技术细节。2017年3月，我们向4个国家的计算机应急小组（CERTs）通报了相关漏洞信息。

NXP公布了一份工程简报以及两份勘误文件（分别为EB00854、ERR010872以及ERR0108873），对这两个漏洞做了简要的介绍，同时也介绍了受影响的处理器型号清单、相应的解决方案以及可能的缓解措施。

在下文中，我们会向大家介绍i.MX处理器的相关特性以及影响这些特性的具体漏洞细节。

二、背景介绍

NXP半导体公司生产的i.MX系列处理器是基于ARM的应用处理器，广泛应用于汽车、工业以及电子消费市场中的SoC（System on a Chip）系统。微控制器最早由飞思卡尔（Freescale）半导体公司研发，该公司在2015年被NXP收购，给NXP带来各种面向安全的特性，包括安全及加密启动特性、篡改检测特性、为各种加密算法设计的硬件加速特性、片上及片外安全存储特性、实时安全时钟特性以及基于硬件的随机数生成器特性。

在产品中使用i.MX处理器的厂商需要自己启动这些特性，某些情况下，处理器被设置为锁定状态，此时这些安全特性无法被禁用。

如果读者感兴趣的话，可以使用几种开发板来体验i.MX处理器的安全特性。我们使用基于i.MX6的SabreLite开发板发现了这些漏洞，开发板如下所示：

2.1 何为安全启动

当处于关机状态的系统被启动后，设备会通过安全启动（secure boot）过程将系统引导到一个已知的健康状态。安全启动过程通常会涉及许多原生代码的执行过程，这些原生代码被封装到多个二进制文件中，设备会加载这些二进制文件，验证文件的可靠性，保证文件未被篡改，然后按顺序运行这些文件，最终将系统引导至厂商或者用户预期的状态。通常情况下，设备会使用具有合法数字签名的二进制程序来完成这一任务，在执行过程中，设备会检查下一个运行的二进制程序的完整性以及真实性，如果验证通过，就会将控制权交给下一个二进制程序。

如果设备在已知健康状态下被启动，并且引导过程中执行的一系列程序都已通过有效签名认证，那么当最后一个程序执行后，设备会认为此时自身处于健康并且受信的状态中。然而，如果在安全启动执行链中，某一个程序无法验证下一个程序的有效性，那么最终得到的系统状态将不再被信任。

通常情况下，这条信任链的源头由核心加密密钥（签名及加密密钥）以及存储在片上只读内存（on-chip read only memory）中的原始可信固件（bootrom）这两类因素共同决定。

启用了安全启动特性的系统会以某种方式锁住这条信任链，使实际接触到设备的最终用户、下游厂商、集成商或者攻击者无法通过禁用安全启动特性来篡改设备安全性。这项特性通常用于数字版权管理（DRM）和知识产权保护中，也可以用来防止恶意代码或其他未授权软件在设备上运行。

2.2 High Assurance Boot（HAB）

HAB（High Assurance Boot）是NXP在i.MX处理器中实现的安全启动特性。这项特性内置于片上ROM中，负责加载初始程序镜像（通常为启动介质中第一阶段的bootloader）。

HAB使用公开密钥加密算法（具体来说是RSA算法）来对启动时执行的镜像进行验证。镜像厂商已经在离线状态下使用私钥对镜像数据进行签名，i.MX处理器会从该镜像的某个部位中提取签名信息，然后使用相应的公钥信息对签名进行验证。

这条信任链的根节点依赖于一组RSA密钥对，这组密钥对名为SRKs（Super Root Keys，超级根密钥），用于防止设备加载并使用由潜在攻击者提供的任意公钥来运行恶意镜像，恶意镜像使用了攻击者自己的私钥进行签名。此外，它也能优化紧缺的一次性可编程硬件资源。合法的私钥由证书颁发机构（CA）签发，用来对镜像进行签名，对应的公钥哈希表存储在一次性可编程硬件中。对于支持安全启动特性的i.MX处理器而言，这是一种隐藏的ROM以及电子可编程保险丝（electrically programmable fuses，eFuses）。

在启动时，HAB bootrom会从CSF（Command Sequence File）中加载SRK表，计算哈希值，将计算结果与存储在SRK fues中的值进行对比。如果哈希值匹配，那么安全启动过程就会继续检查镜像是否经过正确的私钥签名。启动过程失败或者出现任何错误，处理器就会进入恢复（recovery）模式，在这个模式下，设备可以使用串行下载协议（Serial Download Protocol，SDP）通过UART或者USB端口安全加载启动镜像。

供应商使用代码签名工具（Code Signing Tools，CST）以X.509证书形式提供公钥。HAB特性以API形式与启动镜像代码对接，CSF中的命令可以调用这些API。CSF中包含HAB在安全启动过程中执行的有所命令，也包含SRK表以及证书及签名，以验证待加载运行的那些镜像。

上图为HAB信任链，NXP在“使用HABv4的i.MX50、i.MX53及i.MX 6系列处理器中的安全启动”文档中（AN4581）详细介绍了整个过程。

2.3 串行下载协议（SDP）

bootrom支持一种名为串行下载协议（Serial Download Protocol，SDP）的恢复模式，在这种模式下，设备可以通过USB或者UART端口加载启动镜像。

为了实现这一功能，bootrom在HID的基础上实现了带有一些简单命令的小型USB协议：

1、从内存中读取1个单字（READ REGISTER）

2、往内存中写入1个单字（WRITE REGISTER）

3、将启动镜像写入内存（WRITE FILE）

4、写入并执行一组DCD命令（DCD WRITE）

5、执行内存中已加载的启动镜像（JUMP ADDRESS）

当设备被锁定在安全模式下时，会有一系列检查过程，以保证bootrom免受未经允许的内存访问以及未经签名的代码执行，这些检查过程包括：

1、使用白名单方式检查检查访问的内存是否位于许可的范围内。

2、以同一个白名单检查访问的DCD内存范围是否位于许可的范围内。

3、JUMP ADDRESS在执行启动镜像前会先检查启动镜像签名。

三、漏洞分析

我们对编译好的一个bootrom进行分析然后发现了这些漏洞。

我们对代码的功能进行了理解，在这个基础上修改了代码中函数的名称，这些名称可能与源代码中真实的函数名不一致。

用来描述函数位置的地址与bootrom镜像有关，这个镜像的MD5值为945cfc9f525a378102dd24b5eb1b41cf。

我们的实验设备是一个处于锁定状态下的Sabrelite开发板，我们通过一个功能型利用代码，绕过了开发板的HAB安全启动过程，从而证实了漏洞的有效性。

InversePath生产的USB Armory也受这些漏洞影响，该厂商研发了相应的PoC程序来演示这些漏洞。

3.1 X.509证书解析中的栈缓冲区溢出漏洞（CVE-2017-7932）

bootrom的X.509证书解析器中存在一个栈缓冲区溢出漏洞，当解析器加载攻击者构造的一个证书时就会触发这个漏洞。

安全启动中的控制流遵循如下步骤：

1、从存储设备中或者在恢复模式下通过USB接口获取中断向量表（Interrupt Vector Table，IVT）。

2、执行DCD命令。

3、执行CSF命令，这些命令负责安全启动的完整性。当设备处于信任模式下时，这一阶段所执行的CSF命令通常如下：

（1）安装SRK类型的RSA公钥，其SHA256哈希必须与SRK fuses中已写入的哈希值完全一致。

（2）使用经SRK签名的X.509证书安装CSFK公钥。

（3）使用CSFK认证CSF。

（4）安装公钥以验证启动镜像。

（5）使用之前安装的密钥验证启动镜像。

4、执行下一阶段的bootloader。

设备使用INSTALL_KEY这个CSF命令完成密钥安装过程。设备会加载并验证不同的密钥，每个密钥的验证由上一个已安装的密钥来完成（信任链的根节点为SRK fuses）。

当设备安装一个X.509类型的公钥时，hab_csf_cmd_install_key函数（其地址位于0xB5C0处）会找到负责导入X.509证书的插件，然后以下述方式调用：

因此，设备在验证证书签名之前就已经解析了整个证书。由于INSTALL_KEY命令可以先于任何验证命令执行，因此，攻击者无需篡改启动镜像或者将设备切换到恢复模式，就可以触发X.509解析器中存在的漏洞。

HAB bootrom使用了自定义的ASN.1以及X.509解析库，当解析X.509证书中的扩展属性时，HAB错误调用了某个ASN.1库函数，导致漏洞存在。

asn1_extract_bit_string函数（位于0xE796处）使用了内部函数asn1_deep_copy_element_data（位于0xEF20处）来拷贝一个位串（bit string）对象的内容。

HAB会递归调用这种方法，将ASN.1对象的内容复制到以参数形式传递进来的一个输出缓冲区中。这个函数的一个特殊之处在于，它没有使用任何一个输入参数来保存输出缓冲区的值。相反，当调用者将NULL指针作为输出缓冲区传递给该函数时，函数就会返回所需的缓冲区大小，这一点与windows API非常类似。

在使用asn1_extract_bit_string函数时，首先我们得先传入一个NULL参数，获得所需的缓冲区大小，再使用malloc分配所需的内存，然后使用新分配的缓冲区再次调用这个函数。

X.509规范将keyUsage扩展描述为一个位串对象，包含如下9个位：

当设备解析证书扩展属性时，如果证书中包含keyUsage字段，那么设备就会将一个指针指向栈上的一个32位整数，将其作为输出缓冲区，然后直接调用asn1_extract_bit_string函数。

然后keyUsage扩展属性中的一个大于4字节的位串对象就会导致栈缓冲区溢出。

当asn1_extract_bit_string函数返回时，bootrom代码发现返回的大小值没有大于4字节，但此时复制操作已经完成。之后调用函数返回，将其返回地址从栈中弹出，这样攻击者就可以重定向PC寄存器，执行任意代码。

攻击者可以控制写入栈中的数据的大小及内容（即证书所包含的位串的大小及内容）。

负责解析X.509证书扩展属性的存在漏洞的代码如下图所示：

3.2 SDP恢复模式中的缓冲区溢出漏洞（CVE-2017-7936）

WRITE FILE命令处理程序中的内存检查过程存在漏洞，攻击者可以利用该漏洞实现任意代码执行。

对于USB报文，串行下载协议（SDP）使用了如下几个字段：

1、type（命令类型）

2、address（读取或写入的内存地址）

3、format（用于READ REGISTER以及WRITE REGISTER，其大小以比特表示）

4、data_count（用于WRITE FILE以及DCD WRITE，其大小以字节表示）

5、data（WRITE REGISTER所使用的数据）

在信任模式下，当处理DCD WRITE以及WRITE FILE命令时，hab_check_target函数（位于0x753C处）会检查位于address以及address + data_count之间的内存区域。

这个函数有3个参数：

1、内存的类型（0x0F表示内存，0Xf0表示硬件寄存器，0x55表示其他类型的内存）。

2、待检查的内存的基址。

3、内存区域的大小（以字节表示）。

根据待检查的内存的不同类型，函数会使用一份包含安全内存区域的白名单来检查该内存区域。

然而，这个函数并没有被正确调用，原因在于内存大小参数（来自于data_count字段）会被除以8，设备认为这是一个以比特来表示的大小值，而实际上data_count字段是以字节来表示的，这样一来，该函数只会检查目标内存中的一小部分区域。

之所以存在这个问题，原因可能是设备在处理这些命令时，逻辑上与处理READ/WRITE REGISTER命令时混淆了，后者所使用的format字段恰好是用比特来表示的。

当主机通过USB发送数据时，这个错误就会导致缓冲区溢出。

存在漏洞的代码片段如下所示：

四、时间线

2016年9月1日：向NXP报告漏洞。

2016年9月2日：NXP表示已收到漏洞报告。

2016年9月8日：NXP请求X.509漏洞的PoC代码。

2016年9月9日：将i.MX6 bootrom X.509的漏洞利用代码发送给NXP。

2016年9月16日：NXP请求SDP漏洞的PoC代码。

2016年9月16日：将i.MX6 USB恢复模式的漏洞利用代码发送给NXP。

2017年2月20日：向高通移动安全峰会2017提交Quarkslab的演讲摘要文档。

2017年3月11日：高通询问Quarkslab是否愿意与NXP一起联合演讲，我们给出了肯定的答复。

2017年3月21日：在QMSS2017演讲摘要文档中简要提及了i.MX处理器安全启动特性中存在的漏洞。

2017年3月22日：InversePath向Quarkslab通告部分漏洞信息。

2017年3月22日：发邮件给NXP PSIRT、CERT-FR（法国）、CERT-NL（荷兰）、CERT-Bund（德国）以及ICS-CERT（美国），通告漏洞情况及部分细节。

2017年3月23日：InversePath确认i.MX53中存在x.509漏洞，并公布了一份安全公告草案。

2017年3月23日：QMSS 2017演讲摘要文档从网站上移除，进行细节上的修正。

2017年3月24日：InversePath撤销已发布的安全公告。

2017年3月23日：NXP向QMSS发送一份修正摘要文档，其中没有提及i.MX处理器。

2017年3月24日：QMSS 2017网站上公布了修正版的摘要文档。

2017年3月24日：Quarkslab向InversePath、CERTs以及NXP发送邮件，以协调后续的公告事宜。Quarkslab告知各方会在5月19日的QMSS演讲之后，将细节公布在博客中，但如果漏洞信息已公开，这个时间点有可能会提前。

2017年5月1日：ICS-CERT询问Quarkslab是否原因推迟60天发布公告，因为他们想通过国土安全信息网络发布NXP的安全公告，时间上希望协调一致。

2017年5月2日：Quarkslab认为，这些问题向上千个私人团体公告后再推迟60天向公众公告貌似没有任何好处。询问ICS-CERT推迟公告的具体目的。

2017年5月5日：ICS-CERT回复说NXP希望给客户更多的时间调整受影响的产品，同时漏洞的公布过程也会变得更加可控。

2017年5月10日：Quarkslab回复ICS-CERT，认为推迟60天公布对受影响的组织降低安全风险而言没有任何好处，计划于5月19日（QMSS 2017上发表联合演讲）后的1周内发布文章介绍漏洞细节。

2017年5月19日：Quarkslab与NXP在QMSS 2017发表联合演讲。

2017年5月19日：在QMSS 2017的面对面会议上，NXP要求Quarkslab推迟60天公布漏洞细节。NXP表示这是客户的请求，并告诉Quarkslab他们已经通告所有客户，通告中涉及所有受影响的i.MX产品。Quarkslab要求NXP提供通告文档以及他们通知客户的具体证据，以评估是否需要落实该请求。此外，Quarkslab要求NXP向其转发NXP客户延迟公告的请求。

2017年5月22日：NXP表示，他们于4月27日向客户发布了公告，于4月21日向Auto ISAC组织公布了一个安全公告，帮助ICS CERT制作用于国土安全信息网络的安全公告。NXP提供了通知客户的截图以及本文中提到过的工程简报以及勘误文档。

2017年5月30日：收到所有文档后，Quarkslab同意本文推迟到2017年7月18日再发表，并向所有组织（CERTs、NXP以及InversePath）通报了这一决定。

2017年6月5日：InversePath重新发布了之前于3月23日发布过的初步安全公告。

2017年6月6日：ICS-CERT为这些漏洞分配了CVE编号。

2017年7月19日：本文发表。

五、参考资料

译者：math1as

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

什么是SSRF

Structs2

Redis

Elastic

SSRF中的协议'走私'

本质上说,是利用原本的协议夹带信息,攻击到目标的应用

基于HTTP的各类协议=>Elastic,CouchDB,Mongodb,Docker

基于Text的各类协议=>FTP,SMTP,Redis,Memcached

一个有趣的例子

像这样的一个协议

我们来分析一下,各个不同的python库,分别请求到的是哪个域名呢？

可以看到,Python真是个矛盾的语言呢。

另一个有趣的例子

我们尝试构造CRLF注入,来进行如下的攻击

STMP '讨厌' HTTP协议

这似乎是不可利用的,可是,真的如此么?

我们在传统的SSRF利用中都使用gopher协议来进行相关攻击

可是事实上,如果真实的利用场景中不支持gopher协议呢?

利用HTTPS协议:SSL握手中,什么信息不会被加密?

允许客户端在服务器端向其发送证书之前请求服务器的域名。

https://tools.ietf.org/html/rfc4366RFC文档

简单的说,原本的访问,是将域名解析后,向目标ip直接发送client hello,不包含域名

而现在包含了域名,给我们的CRLF攻击提供了利用空间

我们尝试构造CRLF注入,来进行如下的攻击

监听25端口

分析发现,127.0.0.1被作为域名信息附加在了client hello之后

由此我们成功的向STMP'走私'了信息,实施了一次攻击

URL解析中的问题

1.在 RFC2396/RFC3986 中进行了说明,但是也只是停留在说明书的层面。

2.WHATWG(网页超文本应用技术工作小组)定义了一个基于RFC的具体实现

但是不同的编程语言仍然使用他们自己的实现

RFC 3986中定义的URL组成部分

大致用这张图片来说明

其中的协议部分,在真实场景中一般都为http或https

而查询字符串和fragment,也就是#号后的部分,我们实际上是不关心的,因为这和我们的利用无关

所以,我们着重看的也就是authority和path部分

那么,在这几个部分中,能不能进行CRLF注入?

各个语言以及他们对应的库的情况如下图所示

可以看到支持CRLF注入的部分还是很多的,但是除了在实际的请求中能利用CRLF注入外

还要能通过URL解析器的检查,而这个图也列出来了对应的情况。

关于URL解析器

在这段代码中,我们最后使用readfile函数来实施我们的SSRF攻击

但是,我们构造出的URL需要经过parse_url的相应检查

误用URL解析器的后果

当我们对上述的php脚本传入这样的一个URL

对于我们的请求函数readfile来说,它所请求的端口是11211

而相反的,对于parse_url来说,它则认为这个url的端口号是80,符合规定

这就产生了一个差异化的问题,从而造成了SSRF的成功利用

让我们来看看,在RFC3986中,相关的定义

那么,按照这个标准,当我们传入如下URL的时候,会发生什么呢

对比我们的两个函数

可以看到,parse_url最终得到的部分实际上是google.com

而readfile则忠实的执行了RFC的定义,将链接指向了evil.com

进行一下简单的分析

cURL,Python

在3.2小节中有如下的定义:authority(基础认证)部分应该由//作为开始而由接下来的一个/号,或者问号

以及 #号作为一个结束,当然,如果都没有,这个部分将延续到URL的结尾。

cURL的利用

参照我们刚才所得到的结论

对这样的一个URL进行分析和测试

可以发现,在cURL作为请求的实施者时,它最终将evil.com:80作为了目标

而其他的几种URL解析器则得到了不一样的结果,产生了不一致。

当他们被一起使用时,可以被利用的有如下的几种组合

于是我向cURL团队报告了这个问题,很快的我得到了一个补丁

但是这个补丁又可以被添加一个空格的方式绕过

但是,当我再次向cURL报告这个情况的时候,他们认为,cURL并不能100%的验证URL的合法性

它本来就是要让你来传给他正确的URL参数的

并且他们表示,这个漏洞不会修复,但是上一个补丁仍然在7.54.0版本中被使用了

NodeJS的Unicode解析问题

让我们来看如下的一段nodeJS代码

可以看到,阻止了我们使用..来读取上层目录的内容

当对其传入如下的URL时,会发生什么呢

注意,这里的N是 U+FF2E,也就是拉丁文中的N,其unicode编码为 /xFF/x2E

最终,由于nodeJS的处理问题 \xFF 被丢弃了,剩下的\x2E被解析为.

于是我们得到了如下的结论

在NodeJS的http模块中, NN/ 可以起到../ 的作用,绕过特定的过滤

那么,nodeJS对于之前我们所研究的CRLF注入,又能不能够加以防御呢?

很明显,这时候它并不会进行自动的解码操作

如何打破这个僵局呢? 使用U+FF0D和U+FF0A

我们成功的往请求中注入了新的一行

Glibc中的NSS特性

在Glibc的源代码文件 resolv/ns_name.c中,有一个叫ns_name_pton的函数

它遵循RFC1035标准,把一个ascii字符串转化成一个编码后的域名

这有什么可利用的呢?

让我们来看下面的代码

通过gethostbyname函数来解析一个域名

在字符串中,\代表转义符号,因此用\\097来代表ascii码为97,也就是字母a

成功的解析到了orange.tw的ip地址

那么我们看看python的gethostbyname

更让我们惊奇的是,它忽略了这些\号 而解析到了orange.tw

同样的,一些类似的特性存在于linux的getaddrinfo()函数中,它会自动过滤掉空格后的垃圾信息

python socket中的gethostbyname是依赖于getaddrinfo()函数的

因此出现了类似的问题,当传入CRLF时,后面的部分被丢弃了

说了这么多,这些特性有什么可以利用的地方呢?

让我们来看如下的几种payload

可以想到的是,如果利用Glibc的NSS特性,当检查URL时,gethostbyname将其识别为127.0.0.1

为什么%2509能够生效呢?部分的函数实现可能会解码两次,甚至循环解码到不含URL编码

那么接下来,实际发起访问时,我们就可以使用CRLF注入了

由此注入了一条redis语句

同样的,当HTTPS开启了之前我们提到的TLS SNI(Server Name Indication)时

它会把我们传入的域名放到握手包的client hello后面

这样我们就成功的注入了一条语句

而我们还可以进一步延伸,比如曾经的python CRLF注入漏洞,CVE-2016-5699

可以看到,这里其实允许CRLF后紧跟一个空格

由此绕过了_is_illegal_header_value()函数的正则表达式

但是,相应的应用会接受在行开头的空格么?

可以看到,redis和memcached都是允许的,也就产生了利用。

利用IDNA标准

IDNA是,Internationalizing Domain Names in Applications的缩写,也就是'让域名变得国际化'

上图是IDNA各个版本的标准,这个问题依赖于URL解析器和实际的请求器之间所用的IDNA标准不同

可以说,仍然是差异性的攻击。

比如,我们来看这个例子,将这个希腊字母转化为大写时,得到了SS

其实,这个技巧在之前的xss挑战赛 prompt 1 to win当中也有用到

这里我们面对的的是Wordpress

1.它其实很注重保护自己不被SSRF攻击

2.但是仍然被我们发现了3种不同的方法来绕过它的SSRF保护;

3.在2017年2月25日就已经向它报告了这几个漏洞,但是仍然没有被修复

4.为了遵守漏洞披露机制,我选择使用MyBB作为接下来的案例分析

实际上,我们仍然是追寻'差异性'来达到攻击的目的

这次要分析的,是URL解析器,dns检查器,以及URL请求器之间的差异性

上表列出了三种不同的web应用分别使用的URL解析器,dns检查器,以及URL请求器

其实就是之前大家所普遍了解的dns-rebinding攻击

在dns解析和最终请求之间有一个时间差,可以通过重新解析dns的方法进行绕过

1.gethostbyname()函数得到了ip地址1.2.3.4

2.检查发现,1.2.3.4不在黑名单列表中

3.用curl_init()来获得一个ip地址,这时候cURL会再次发出一次DNS请求

4.最终我们重新解析foo.orange.tw到127.0.0.1 产生了一个dns攻击

利用DNS解析器和URL请求器之间的差异性攻击

对于gethostbynamel()这个DNS解析器所用的函数来说

它没有使用IDNA标准的转换,但是cURL却使用了

于是最终产生的后果是,gethostbynamel()解析不到对应的ip,返回了false

也就绕过了这里的检查。

利用URL解析器和URL请求器之间的差异性攻击

这个漏洞已经在PHP 7.0.13中得到了修复

有趣的是,这里最终请求到的是127.0.0.1:11211

而下一个payload则显示了curl的问题,最终也被解析到本地ip

而这个漏洞也在cURL 7.54中被修复

可惜的是,ubuntu 17.04中自带的libcurl的版本仍然是7.52.1

但是,即使是这样进行了修复,参照之前的方法,添加空格仍然继续可以绕过

而且cURL明确表示不会修复

协议'走私' 案例分析

这次我们分析的是github企业版

它使用ruby on rails框架编写,而且代码已经被做了混淆处理

关于github企业版的远程代码执行漏洞

是github三周年报告的最好漏洞

它把4个漏洞结合为一个攻击链,实现了远程代码执行的攻击

webhooks是什么?

这就很明显了,它含有发送POST数据包的功能

而它是如何实现的呢?

请求器使用了rubygem-faraday是一个HTTP/REST 客户端库

而黑名单则由其内部的faraday-restrict-ip-addresses所定义

它过滤了localhost,127.0.0.1等地址

但是仅仅用一个简单的 0 就可以加以绕过,像这样

但是,这个漏洞里有好几个限制,比如

不允许302重定向

不允许http,https之外的协议

不允许CRLF注入

只允许POST方式发送数据包

这里也是存在SSRF的

Graphite是由python编写的

于是,分析可知,这第二个SSRF的实现是httplib.HTTPConnection

很明显的,httplib是存在CRLF注入问题的

于是,我们可以构造下面的URL,产生一个'走私'漏洞

Github企业版使用Memcached gem来作为它的缓存客户端

所有缓存的ruby对象都会被编排

最终的攻击链如下:

这个漏洞最终获得了12500美金的奖励

在github企业版<2.8.7中可以使用

缓解措施

使用唯一的ip地址和URL,而不是对输入的URL进行复用

简单的说,拒绝对输入的URL进行二次解析,只使用第一次的结果

使用防火墙或者协议来阻断内网的通行

由 @fin1te 编写的SafeCurl

它也被 @JordanMilne 所提倡

总结

SSRF中的新攻击面

协议'走私'中的新攻击向量

以及相关的具体案例分析

未来展望

以及.. 更多

热点概要：使用Frida从TeamViewer内存中提取密码、通过使用Burp和Sqlmap Tamper利用二次注入漏洞、Rooting the Amazon Echo、使用SSH反向隧道进行内网穿透、命令注入漏洞测试方法谈、OWASP移动安全测试指南、SQLMap Web GUI、高通声卡驱动中的条件竞争漏洞分析（CVE-2017-7368）

国内热词(以下内容部分摘自http://www.solidot.org/)：

黑客窃取 HBO 1.5 TB 数据，泄漏权力游戏剧本

Qubes OS 4.0-rc1 发布

资讯类：

Amazon Echo可成为攻击者的监听设备

http://www.securityweek.com/amazon-echo-could-become-attackers-listening-device

美国最大医保公司Anthem再遭数据泄露，1.8万用户受影响

https://threatpost.com/breach-at-third-party-contractor-affects-18000-anthem-members/127139/

【APT报告】Cobalt strikes回归：一个针对金融行业的APT组织

http://blog.ptsecurity.com/2017/08/cobalt-group-2017-cobalt-strikes-back.html

使用Frida从TeamViewer内存中提取密码

https://github.com/vah13/extractTVpasswords

通过使用Burp和Sqlmap Tamper利用二次注入漏洞

https://pentest.blog/exploiting-second-order-sqli-flaws-by-using-burp-custom-sqlmap-tamper/

Rooting the Amazon Echo

https://labs.mwrinfosecurity.com/blog/alexa-are-you-listening/

使用SSH反向隧道进行内网穿透

http://arondight.me/2016/02/17/%E4%BD%BF%E7%94%A8SSH%E5%8F%8D%E5%90%91%E9%9A%A7%E9%81%93%E8%BF%9B%E8%A1%8C%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F/

EXP-CVE-2016-3935

https://github.com/jiayy/android_vuln_poc-exp/tree/master/EXP-CVE-2016-3935

BlackHat 2017: The Shadow Brokers—Cyber Fear Game Changers

https://blog.comae.io/the-shadow-brokers-cyber-fear-game-changers-d143796f560f

对Clemency进行了额外的分析

https://blog.trailofbits.com/2017/07/30/an-extra-bit-of-analysis-for-clemency/

在WAGO PLC Ethernet中静默修复未授权命令注入漏洞

https://cbolat.blogspot.com.tr/2017/08/silently-fixed-unauthorizedcommand.html

命令注入漏洞测试方法谈

https://www.hackerone.com/blog/how-to-command-injections

CableTap White Paper - 26 CVEs for exploiting cable modems and set top boxes

https://github.com/BastilleResearch/CableTap/blob/master/doc/pdf/DEFCON-25-Marc-Newlin-CableTap-White-Paper.pdf

高通声卡驱动中的条件竞争漏洞分析（CVE-2017-7368）

http://paper.seebug.org/364/

SQLMap Web GUI

https://n0where.net/sqlmap-web-gui/

https://github.com/Hood3dRob1n/SQLMAP-Web-GUI

REMnux v6：逆向工程和恶意软件分析的linux工具包

https://n0where.net/reverse-engineering-malicious-software-remnux-distro/

WiFiBeat:将802.11 frames存储在Elasticsearch中，并通过Kibana可视化

https://www.wifibeat.org/#

WMIMon：windows平台监控WMI活动的命令行工具

https://github.com/luctalpe/WMIMon

破坏认证和会话管理 – Session Fixation

https://www.peerlyst.com/posts/broken-authentication-and-session-management-session-fixation-hari-charan

OWASP移动安全测试指南

https://b-mueller.gitbooks.io/the-owasp-mobile-security-testing-guide/content/