译者：興趣使然的小胃

预估稿费：120RMB

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

一、前言

受Casey Smith（@subtee）发表的一则推文的启发，我更新了几年前我与Andrew Chiles（@andrewchiles）共同开发的一款工具。

以红队身份参与渗透测试活动时，如果无法避免磁盘操作，那么你可以使用这款工具尽可能融入周围环境。在内存中操作是非常好的方法，然而许多情况下，我们不得不使用磁盘上的二进制文件。我使用的技术非常有效，那就是修改二进制文件的资源信息（元数据，metadata）。元数据包含许多字段，如文件图标、版本、描述、产品名称、版权等信息。许多威胁源经常会通过突破安全防御或者修改IOC特征来尝试欺骗或蒙蔽安全分析人员（可以参考我发布的关于修改IOC特征的系列视频）。

将文件融入周围环境可以使安全分析人员将恶意行为当成可信行为。特别是如果某个二进制文件看起来像是微软出品的，那么应该更加可信。

这正是MetaTwin发挥作用的场景。经过修改后，这款工具不仅能够修改二进制文件的元数据，也能添加最近由@subtee以及@mattifestation描述的数字签名信息。

二、MetaTwin工作原理

1、MetaTwin以经过合法签名的二进制文件作为源文件，如explorer.exe。

2、提取资源（利用ResourceHacker）以及数字签名信息（利用SigThief）。

3、将提取到的数据写入目标二进制文件中。

三、工具演示

在这个例子中，我选择使用默认的meterpreter reverse_tcp二进制文件。选择这个程序并没有什么特别含义，这里我们可以使用任意二进制文件（.exe或.dll文件）。就我个人而言，在实际环境中我是Cobalt Strike的忠实粉丝。

如你所见，经过处理的文件看起来非常有迷惑性。红方操作人员无需消耗太多精力，只需将其保存在类似c:\ProgramData之类的目录中，修改文件时间戳，就可以实现更长时间的驻留。

四、有趣的实验结果

4.1 反病毒软件

通常情况下，经过简单的修改，防御方工具的反应也会有所不同。当然反病毒软件通常不是个花架子，但我们还是很好奇它们会如何处理经过MetaTwin修改的Metasploit meterpreter程序。除了添加元数据及数字签名外，我们没有做其他的混淆处理。实验结果非常有趣。

未经处理的源文件检测结果如下图所示。

不出意外，VirusTotal上的检出率非常高。

具体检测结果为：https://www.virustotal.com/#/file/02d873881fef5b497503a48c221c4977e3a1a0d2cf9bfa78a8d6c567e63dca70/detection

添加元数据后的检测结果如下图所示。

有趣的是，仅添加元数据就能降低反病毒软件的检出率。

具体检测结果为：https://www.virustotal.com/#/file/cc96177e110d4413f918d9b7ef3650eab59bd7fa7a12afe37fde7ce3e6d63d1b/detection

添加元数据及数字签名后的检测结果如下图所示。

添加数字签名及元数据后，检出率从76%降到了58%。这一点非常重要，因为我们还没有真正尝试规避反病毒软件！

具体检测结果为：https://www.virustotal.com/#/file/e653b4d75cc02da5ea258be5b1c1eb6feed9586fa6b977eb570a188a38783e66/detection

4.2 SysInternals AutoRuns

除了反病毒软件外，我们还调查了SysInternals AutoRuns工具对这些修改的具体反应。

我们使用计划任务创建了与修改版二进制文件有关的任务，以此简单实现了本地持久化机制。AutoRuns可以用来检测这类windows持久化方法，然而，默认情况下，它并不会显示与修改版程序有关的任务。

默认设置下，AutoRuns会隐藏“微软”的计划任务，如下所示。

AutoRuns的默认设置如下：

修改默认配置后，我们就可以发现伪装的“微软”计划任务。

五、总结

根据以上观察结果，我们可以得出一个非常明显的结论，那就是某些防病毒软件以及端点检测和响应（EDR）工具容易受到元数据以及数字签名的欺骗，因此难以有效胜任蓝方角色。在无法避免磁盘操作的情况下，红方操作人员在未来对抗中可以充分利用这一点。

译者：_veritas501

预估稿费：150RMB

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

简介

传送门：

【技术分享】看我如何编写一个Linux 调试器（一）：准备工作

【技术分享】看我如何编写一个Linux 调试器（二）：断点

在上一篇文章中，我们给调试器添加了简单的断点功能。这一次，我们将添加对寄存器和内存的读写能力，这使得我们随意修改PC指针，观察当前的状态和改变程序的行为。

注册我们的寄存器

在我们开始读取寄存器值之前，我们需要告诉调试器一些关于我们目标的信息，这里是x86\_64平台。除了一系列通用和专用的寄存器外，x86\_64还拥有浮点寄存器和向量寄存器。为了简洁，我将跳过最后两种，但如果你喜欢你也可以选择对它们提供支持。x86\_64同样允许你像32,16,8位寄存器那样操作64位寄存器，但我只专注于64位。处于简化，对每一个寄存器我们只需要它的名称、他的DWARF寄存器编号以及它在ptrace返回的结构体中的储存位置。我选择使用范围枚举引用这些寄存器，然后我列出一个全局寄存器描述数组，其中元素的顺序和它在ptrace寄存器结构体的中顺序相同。

如果你想亲自查看，你可以在/usr/include/sys/user.h里找到这个寄存器数据结构体（user_regs_struct ）。DWARF寄存器编号来自System V x86_64 ABI。

现在我们可以编写一堆函数来与寄存器做交互。我们想要从寄存器中读取和写入值，根据DWARF寄存器编号获取值，以及通过名称查找寄存器，反之亦然。让我们先实现get_register_value：

ptrace再次使我们轻松地获取到了我们想得到的值。我们只需构造一个user_regs_struct的实例，并把它和PTRACE_GETREGS request传递给ptrace。

将regs转换成 uint64_t类型是安全的，因为user_regs_struct是一个标准的布局类型。但我认为指针运算在技术上是未定义的行为（UB）。当前没有一个编译器对此发出警告而且我很懒，如果你想保证代码严格正确，就写一个大的switch语句吧。

set_register_value非常类似，我们只需写入相应的地址并在最后写回寄存器中：

下一步是通过DWARF寄存器编号进行寻找。这一次我会进行一些错误检查以防得到一些奇怪的DWARF 信息。

即将完工，现在我们已经有了寄存器名称查找功能：

最后我会添加一个简单的帮助函数把所有寄存器的内容导出来：

这足够让我们在调试器的余下部分中轻松处理寄存器，因此我们现在可以加上UI界面了。

显示寄存器

我们所要做的就是为handle_command函数添加一个新的命令。通过下面的代码，用户就能输入诸如 register read rax, register write rax 0x42 的命令。

接下来干什么？

当我们设置断点的时候，我们已经读取并写入内存了。因此我们只需要添加一些函数来包装ptrace的这些功能即可。

你可能想实现一次读写多个字节，你可以通过每次递增地址来读取下一个字节。如果你喜欢，你也可以使用process_vm_readv和 process_vm_writev (link) 或 /proc/<pid>/mem 来代替 ptrace。

现在我们给UI添加一些命令：

给 continue_execution 做修补

在我们对测试更改前，我们现在可以实现一个更健全的continue_execution。由于我们可以获取PC指针，我们可以检查我们的断点表来判断我们是否在一个断点上。如果是，我们可以停用断点并在继续之前单步跳过。

首先为了阐明清晰，我们添加一些帮助函数：

然后我们可以写一个函数来步过断点：

首先我们检测当前PC所指代码时候已经被设置断点，如果是，我们先把PC改到断点前一句，禁用断点后再步过原来的指令，在重新启用它。

wait_for_signal 封装了我们常用的waitpid模式。

最后我们重写 continue_execution函数：

测试

现在我们可以读取和修改寄存器，我们可以对helloworld程序做些事情。第一个测试，尝试在一个call上再次设置断点并继续执行。你应该会看到程序打印出Hello world。有趣的部分，在输出的call后面设置断点，然后将rip改到call的参数设置处并继续，你应该会看到程序打印出Hello world。以防你不知道在哪里设置断点，这里是我上一篇中objdump的输出：

为正确设置esi和edi寄存器，你需要把PC指针设置到0x40093a。

在下一篇文章中，我们将第一次接触到DWARF信息并为我们的调试器增添一系列单步调试的功能。这样我们就有了一个能单步执行代码，在想要的地方设置断点，修改数据等等功能的调试器了。

和之前一样，如果你有任何问题欢迎在我博客下面评论！

你可以在这里找到本文的代码。

作者：myles007

预估稿费：300RMB

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

简介

我们在渗透测试的过程中经常会遇到linux主机环境，而在获取linux主机shell是我们经常需要做的是工作内容之一，其中经常会遇到以下几个场景。

一、场景一

我们已经拿下主机的一个webshell,我们想获取一个可以直接操作主机的虚拟终端，此时我们首先想到的是开启一个shell监听，这种场景比较简单，我们直接使用使用nc即可开启，如果没有nc我们也可以很轻松的直接下载安装一个，具体开启监听的命令如下。

1.1 安装netcat

这里需要注意一点默认的各个linux发行版本已经自带了netcat工具包，但是可能由于处于安全考虑原生版本的netcat带有可以直接发布与反弹本地shell的功能参数 -e这里都被阉割了，所以我们需要手动下载二进制安装包，自己动手丰衣足食了，具体过程如下。

原生版本netcat链接：https://nchc.dl.sourceforge.net/project/netcat/netcat/0.7.1/netcat-0.7.1.tar.gz

至此我们已经安装完成原生版本的 netcat工具，有了netcat -e参数，我们就可以将本地bash完整发布到外网了。

1.2 开启本地监听

1.3 直接连接目标主机

二、场景二

目标主机为一个内网主机，并没有公网IP地址，我们无法从外网发起对目标主机的远程连接，此时我们使用的方法是使用获取的webshell主动发起一个反弹的shell到外网，然后获取一个目标主机的shell终端控制环境，而有关shell反弹的方法有很多这里简单介绍几种比较常见的方法。

2.1 bash 直接反弹

bash一句话shell反弹：个人感觉最好用的用的方法就是使用的方法就是使用bash结合重定向方法的一句话，具体命令如下。

（1） bash反弹一句话

（2）bash一句话命令详解

以下针对常用的bash反弹一句话进行了拆分说明，具体内容如下。

其实以上bash反弹一句完整的解读过程就是：

bash产生了一个交互环境与本地主机主动发起与目标主机8080端口建立的连接（即TCP 8080 会话连接）相结合，然后在重定向个tcp 8080会话连接，最后将用户键盘输入与用户标准输出相结合再次重定向给一个标准的输出，即得到一个bash 反弹环境。

2.2 netcat 工具反弹

Netcat 一句话反弹：Netcat反弹也是非常常用的方法，只是这个方法需要我们手动去安装一个NC环境，前面已经介绍默认的linux发型版现在自带的NC都是被阉割过来，无法反弹一个bash给远端，所以相对上面的bash一句话反弹显得就繁琐很多，同时通过实际测试发现NC反弹的shell交互性也差很多，后面会具体说道，这里就不多说了。

（1）开启外网主机监听

（2） netcat安装

有关netcat的原生二进制安装包的编译安装内容请参考场景一中的具体说明；

（3）netcat 反弹一句话

（4）shell反弹成功

此时我们再回到外网主机，我们会发现tcp 8080监听已经接收到远端主机发起的连接，并成功获取shell虚拟终端控制环境。

2.3 socat 反弹一句话

Socat是Linux 下一个多功能的网络工具，名字来由是” Socket CAT”，因此可以看出它基于socket，能够折腾socket相关的无数事情 ，其功能与netcat类似，不过据说可以看做netcat的加强版,事实上的确也是如此，nc应急比较久没人维护了，确实显得有些陈旧了，我这里只简单的介绍下怎么使用它开启监听和反弹shell，其他详细内容可以参加见文末的参考学习。

有关socat二进制可执行文件，大家可以到这个链接下载：https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/socat

（1） 攻击机上开启监听

（2） 靶机上运行socat反弹shell

（3） shell 反弹成功

2.4 其他脚本一句话shell反弹

以下脚本反弹一句话的使用方法都是一样的，只要在攻击机在本地开启 TCP 8080监听，然后在远端靶机上运行以下任意一种脚本语句，即可把靶机的bash反弹给攻击主机的8080端口（当然前提条件是目标主机上要有响应的脚本解析环境支持，才可以使用，相信这点大家肯定都是明白的）。

2.4.1 python脚本反弹

2.4.2 php 脚本反弹

2.4.3 Java 脚本反弹

2.4.4 perl 脚本反弹

2.5 msfvenom 获取反弹一句话

学习过程中发现其实强大的MSF框架也为我们提供了生成一句话反弹shell的工具，即msfvenom。绝对的实用，当我们不记得前面说的所有反弹shell的反弹语句时，只要我们有Metasploit,随时我们都可以使用msfvenom -l 来查询生成我们所需要的各类命令行一句话，具体使用方法为各位看官老爷们收集如下。

2.5.1 查询 payload 具体路径

我们直接可以使用 msfvenom -l 结合关键字过滤（如cmd/unix/reverse），找出我们需要的各类反弹一句话payload的路径信息。

查看以上截图，我们可以看到msfvenom支持生成反弹shell一句话的类型非常丰富，这里几乎是应有尽有，大家可以依据渗透测试对象自行选择使用。

2.5.2 生成我们我们需要的命令行一句话

依照前面查找出的命令生成一句话payload路径，我们使用如下的命令生成反弹一句话，然后复制粘贴到靶机上运行即可。

bash 反弹一句话生成

阉割版nc反弹一句话生成

2.5.3 msfvenom 使用实例

（1） 开启攻击机监听

在攻击机上开启本地 TCP 12345 端口监听，准备监听机上的会话反弹，查看如下截图可以看到本地TCP 12345 端口监听已经开启。

（2） 获取python一句话

我们此时可以借助于MSF框架平台的msfvenom 工具自动生成一个python 反弹一句话，具体操作请参加如下截图。（当然这里的前提条件是靶机上安装有python环境，现在默认一般的linux发行版默认都安装有python环境。）

（3） 靶机上运行python一句话

直接将上面msfvenon 生成的 python 一句话复制到靶机webshell上运行即可，我这里为演示方便，直接贴了一张使用kali做为靶机运行的截图。

（4） 攻击监听接受反弹情况

三、场景三

场景三其实应该是在使用shell环境获取的过程中遇到的问题孕育出来的，大家如果经常使用前各种方法进行虚拟终端环境获取的话，会发现存在一个问题，就是我们即使获取了目标虚拟终端控制权限，但是往往会发现交互性非常的差，就是发现这个虚拟回显信息与可交互性非常的差和不稳定，具体见情况有以下几个种。

问题1： 获取的虚拟终端没有交互性，我们想给添加的账号设置密码，无法完成。

问题2：标准的错误输出无法显示，无法正常使用vim等文本编辑器等；

问题3： 获取的目标主机的虚拟终端使用非常不稳定，很容易断开连接。

针对以上问题个人学习和总结了以下的应对方法，请大家参考交流。

3.1 一句话添加账号

你不是不给我提供交互的界面吗，那我就是使用脚本式的方法，使用一句话完成账号密码的添加，有关一句话账号密码的添加，笔者收集了以下几种方式。

3.1.1 chpasswd 方法

（1）执行语句

（2）操作实例

3.1.2 useradd -p 方法

（1） 执行语句

（2） 操作实例

（3） 相同方法其他实现

相同方法不同实现一

3.1.3 echo -e 方法

（1）执行语句

（2） 操作实例

3.2 python 标准虚拟终端获取

我们通过各种方式获取的shell经常不稳定或者没有交互界面的原因，往往都是因为我们获取的shell不是标准的虚拟终端，此时我们其实可以借助于python来获取一个标准的虚拟终端环境。python在现在一般发行版Linux系统中都会自带，所以使用起来也较为方便，即使没有安装，我们手动安装也很方便。

3.2.1 python 一句话获取标准shell

使用python 一句话获取标准shell的具体命令如下：

命令详解：python 默认就包含有一个pty的标准库。

3.2.2 实例演示

具体（1）开启监听；（2）反弹shell；（3）会话建立的过程这里不在重复演示了，这里直接贴出笔者获取到反弹shell后的问题后，如何通过python获取标准shell的过程截图展现如下。

虽然到目前为止写的虚拟终端并没有原生终端那样好,但是花点时间去折腾然后不断的去完善.相信会做的更好. 大家可能在渗透测试的时候会发现有些时候系统的命令终端是不允许直接访问的,那么这个时候用Python虚拟化一个终端相信会让你眼前一亮.

四、写在最后

最后将上面学习的内容做一下小结，以方便日后可以直接复制粘贴使用，笔者贴心不，你就说贴心补贴（ou tu bu zhi ...）

4.1 nc开启本地监听发布bash服务

4.2 常用反弹shell一句话

（1） bash 反弹一句话

（2） nc 反弹一句话

（3） socat 反弹一句话

4.3 利用msfvenom获取反弹一句话

（1） 查询 reverse payload 反弹路径

（2） 生成相关反弹一句话

剩下的就是将生成的payload 反弹一句话直接复制到靶机上直接运行即反弹一个shell出来。

4.4 使用python获取标准shell

直接在获取的废标准shell上直接运行一下python 一句话即可获取一个标准的shell。

4.5 linux 一句话添加账户

（1）chpasswd 方法

（2）useradd -p 方法

（3）echo -e 方法

学习参考

https://github.com/smartFlash/pySecurity/blob/master/zh-cn/0x11.md

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

http://www.CodeSec.Net/news/142195.html

http://brieflyx.me/2015/linux-tools/socat-introduction/

译者：shan66

预估稿费：200RMB

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

前言

为了纪念国家网络安全意识月（NCSAM），我们发布了一篇新的系列文章，来重点介绍Azure Security Center是如何检测、追查和缓解现实世界所面临的各种网络攻击的。在这篇文章中，我们将向读者分析攻击者是如何使用PowerShell来运行恶意代码并收集用户凭据的。在详细介绍这一攻击手法之前，不妨先对本系列中其他文章进行一个回顾，其中Security Center能够检测到：

SQL暴力攻击

比特币采矿攻击

基于网络威胁情报的DDoS攻击

恶意使用正常的应用程序

在这篇文章中，我们将介绍Azure Security Center检测到的另一个有趣的真实世界的攻击场景，并且这次调查是由我们的团队负责的。需要注意的是，为了保护隐私，受影响公司的名称、所有计算机名称和所有用户名都已进行了更换。这种特殊攻击使用PowerShell来运行内存中的恶意代码，目的是通过密码窃取、按键记录、剪贴板抓取和屏幕捕获来收集凭据信息。该攻击首先会进行RDP Force攻击，最终将在注册表中实现设置和配置持久自动启动（ASEP）的目的。这个案例研究不仅介绍了该攻击的原理，并提供了如何在您的环境中检测和防止类似攻击的建议。

Azure安全中心的原始警报和详细信息

由于世界上存在许多远程管理的联网计算机，所以黑客们一直都在努力搜寻各种正在运行的远程管理服务，如远程桌面协议（RDP），以便通过暴力攻击破解密码。我们的案例是从一个大客户的Azure Security Center控制台开始的，该控制台提示存在RDP暴力攻击活动以及可疑的PowerShell活动。

在下面的Azure Security Center屏幕截图中，您可以按照从下到上的时间顺序进行查看，我们可以发现“Failed RDP Brute Force Attack”警报后面是一个“Failed RDP Brute Force Attack”警报——这表示有人通过RDP登录猜到了用户密码，在这种恶意的暴力登录警报后面，是几个异常PowerShell活动的警报。

当我们检查最初的Successful RDP Brute Force Attack警报时，可以看到攻击的时间、受到攻击的帐户、攻击源的IP地址（这里是意大利），以及Microsoft’s Threat Intel的“RDP Brute Forcing”报告的链接。

成功登录后，后面给出了一些高级严重性警报，并且Azure安全中心会按时间顺序显示攻击者登录成功后执行的每个命令行：

原始的攻击和攻击者活动的细节

根据上述警报提供的信息，我们的调查团队与客户一起审查了从攻击者最初登录时获取的帐户登录日志（事件ID 4624）和进程创建日志（事件ID 4688）。 根据原始的登录数据，我们看到攻击者使用了各种用户名和密码组合来进行持续的RDP暴力尝试。大多数失败的尝试最终会引发事件ID 4625（帐户登录失败）、状态码0xc000006d（尝试登录无效）和一个子代码0xc0000064（指定的帐号不存在）。

在09月06日上午10:13左右，我们看到Substatus码开始发生变化。从这里可以看出，使用用户名“ContosoAdmin”导致了不同的状态码：0xc000006a（密码错误）。 之后是使用“ContosoAdmin”帐户登录成功，类型分别为3和10（远程交互）。从IP地址（188.125.100.233）来看，这次是从意大利进行登录的。

下面，我们来检查一下登录后的进程创建活动。攻击者首先执行了“whoami”命令，来查看当前的登录用户。然后使用net group “Domain Admins” /domain命令查看了“Domain Admins”组的成员。之后，又执行了“qwinsta”命令，来显示所有Remote Desktop Services会话。然后启动Taskmgr（windows任务管理器）以查看或管理相应的进程和服务。

稍后，攻击者执行了另一个PowerShell命令。该命令用Base64编码的字符串进行了混淆处理，另外，还利用Deflate压缩算法进行了压缩处理。注意：在后文中，我们会对这些Base64编码的字符串进行解码，届时我们将进一步挖掘该命令的用法。

约3分钟后，攻击者从这台机器上面注销了。但是在注销之前，他们会通过清除所有事件日志来掩盖自己的踪迹。这是通过内置的wevtutil.exe（Windows事件命令行实用程序）来完成的。首先，使用"el"或"enum-logs"开关枚举所有事件日志。然后用“cl”或“清除日志”开关清除所有事件日志。以下是攻击者执行的部分事件清除命令。

深入考察Base64编码的PowerShell命令

我们对攻击者的原始命令的Base64编码的部分进行解码后，竟然出现了更多的Base64编码命令，这表明：

嵌套的Base64混淆处理。

所有级别的命令执行都进行了混淆处理。

创建一个仅使用注册表的ASEP（自动启动扩展点）作为持久性机制。

恶意代码参数存储在注册表中。

由于ASEP和参数仅出现系统注册表中，所以这些命令可以在不借助文件或NTFS组件的情况下以“in-memory”的方式执行。

这是攻击者执行的原始命令：

解码Base64后可以看到，许多注册表项和更多的Base64字符串有待解码……

解码这些嵌套的Base64值后，我们发现该命令执行了以下操作：

1.该命令首先把后面的命令用到的参数存储在HKLM\Software\Microsoft\Windows\CurrentVersion下的名为“SeCert”的注册表单元中。

3.然后，攻击者的命令通过“HKLM\Software\Microsoft\Windows\CurrentVersion\Run”中名为“SophosMSHTA”的注册表ASEP（自动启动扩展点）实现持久性机制。

5.注册表ASEP会启动Microsoft脚本引擎（mshta.exe）。

6.Mshta.exe将运行PowerShell.exe，然后，它将读取并解码HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion->“SeCert”的值。

恶意代码的下载和执行

操作

从剪贴板中抓取内容并将输出保存到以下位置：

将所有按键记录到以下位置：

捕获初始屏幕并以.jpg格式保存到以下位置：

当受害者输入某些金融或帐户凭据方面的关键词时，进行屏幕截图，并以.jpg格式保存到以下位置：

检查是否安装了Google Chrome浏览器。 如果已经安装的话，就从Chrome缓存中收集所有密码并保存到以下位置：

检查是否安装了Mozilla Firefox浏览器。如果已经安装的话，就从Firefox缓存中收集所有密码并保存到以下位置：

总结

下面，我们来总结一下到目前为止的调查结果：

1.首先，攻击者会通过RDP暴力攻击管理员帐户，如果爆破成功，入侵的第一步就成功了。

2.然后，攻击者将执行一个通过Base64混淆处理过的PowerShell命令，该命令的作用是设置开机时启动的注册表ASEP。

3.接着，攻击者通过使用以下命令删除所有事件日志来清除其活动的证据：wevtutil.exe -cl <eventlogname>。

4.当受影响的主机启动或重新启动时，它将启动位于HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run中的恶意注册表ASEP

5.注册表ASEP会启动Microsoft脚本引擎（mshta.exe）。

6.Mshta.exe会运行PowerShell.exe，然后它将读取并解码HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion -> ”SeCert”的值

1.将从剪贴板中抓取得内容保存到：％temp％\Applnsights_VisualStudio.txt

2.将所有按键记录到：％temp％\ key.log

3.抓取初始屏幕并以.jpg格式保存到：％temp％\39F28DD9-0677-4EAC-91B8-2112B1515341\yyyymmdd_hhmmss.jpg

4.当受害者输入某些财务或帐户凭据相关的关键字时，进行屏幕截图，并以.jpg格式保存到以下位置：％temp％\39F28DD9-0677-4EAC-91B8-2112B1515341\yyyymmdd_hhmmss.jpg

5.检查是否安装了Google Chrome浏览器。如果已经安装了的话，从Chrome缓存中收集所有密码，并保存到：％temp％\Chrome.log

6.检查是否安装了Mozilla Firefox浏览器。如果已经安装了的话，从Firefox缓存中收集所有密码，并保存到：％temp％\Firefox.log

该攻击的结果是信息窃取软件将从注册表自动启动，并在内存中运行，从而收集击键、浏览器密码、剪贴板数据和屏幕截图。

Azure Security Center如何捕获这一切的

很明显，攻击者试图通过各种非凡的手段来掩饰自己的活动；确保使用内置的Windows可执行文件（PowerShell.exe、Mshta.exe、Wevtutil.exe）执行所有进程，使用经过混淆处理并存储在注册表中的命令参数，以及删除所有事件日志以清除其踪迹。然而，这些努力并没有能够阻止Azure Security Center检测、收集和报告该恶意活动。

正如我们在本文开头部分所看到的，Azure Security Center检测到了这次攻击的完整过程，并提供了最初的RDP暴力攻击的详细信息，并揭示了攻击者执行所有命令。在警报中还可以看出，所有混淆过的命令行都会被解密、解码，并在攻击的每个阶段以明文形式呈现。这个可以节省时间的宝贵信息有助于安全响应调查员和系统管理员了解“发生了什么事”，“什么时候发生”，“他们是怎么进入的”，“他们进入什么” ，“他们从哪里来”的一系列问题。此外，调查人员还可以确定其组织中的其他主机是否可能受到这个被入侵的主机的横向渗透的影响。对这个攻击的全面了解也可以帮助回答诸如“他们之后的目标是什么”等问题。在我们的例子中，主要目的似乎是窃取财务或账户凭据。

在我们的所有调查中，Azure Security Center在帮助确定关键细节，如初始入侵方式、攻击源、可能的横向渗透和攻击范围方面发挥了关键作用。Azure Security Center还会详细描述将来由于文件系统覆盖或日志保留/存储限制而可能丢失的组件。Azure Security Center能够使用最新的机器学习和大数据分析技术，通过各种来源来获取、存储、分析和解密数据，这对于安全分析师、事件响应人员和取证人员来说是非常有价值的。

推荐的补救和缓解措施

我们可以看到，最初的攻击之所以得手是由于使用了容易猜到密码的用户帐户所导致的，之后，整个系统就被攻陷了。本例中，主机被植入了恶意的PowerShell代码，其主要目的是为了获得财务凭证或有价值得信息。 Microsoft建议通过审查可用的日志源、基于主机的分析以及取证析以帮助确定攻击过程中第一个沦陷的地方在哪里。Azure基础架构即服务（IaaS）和虚拟机（VM））提供了几个相关的功能以便于收集数据，包括将数据驱动器附加到正在运行的计算机和磁盘映像功能等。 Microsoft还建议使用恶意软件保护软件进行扫描，以帮助识别和删除主机上运行的恶意软件。如果已从被攻陷的主机识别出横向渗透，则补救措施应扩展到所有主机。

如果无法确定最初攻陷的地方在哪里的话，Microsoft建议备份关键数据并迁移到新的虚拟机。此外，新的或修复后的主机应该在连入网络之前进行安全加固，以防止重新感染。然而，如果这些无法立即执行的话，我们建议实施以下补救/预防措施：

1.密码策略：攻击者通常使用广泛流传的工具来发起暴力攻击，这些工具利用单词列表和智能规则集来智能地自动猜测用户密码。因此，第一步是确保为所有虚拟机使用复杂的密码。应使用强制频繁更改密码的复杂密码策略，并了解执行密码策略的最佳做法。

2.端点：端点允许从互联网与您的虚拟机进行通信。在Azure环境中创建虚拟机时，默认情况下会创建两个端点，以帮助管理虚拟机，它们分别是远程桌面和PowerShell。建议删除任何不需要的端点，只有在需要的时候才添加它们。如果您有端点处于打开状态，建议尽可能修改所用的公共端口。创建新的Windows VM时，默认情况下，远程桌面的公共端口设置为 “Auto” ，这意味着将为您自动生成随机的公共端口。要想获取有关如何在Azure中的经典Windows虚拟机上设置端点的更多信息，请访问这里。

3.启用网络安全组：Azure Security Center建议您启用网络安全组（NSG）（如果尚未启用的话）。NSG中包含了一个访问控制列表（ACL）规则列表，用来决定允许或拒绝虚拟网络中虚拟机实例的网络流量。端点ACL可以用来控制可以通过该管理协议访问的IP地址或CIDR地址子网。如果想要详细了解如何使用网络安全组过滤网络流量，并在Azure Security Center中启用网络安全组的话，可以访问这里。

4.使用VPN进行管理：VPN网关是一种虚拟网络网关，可以通过公共连接将加密流量发送到本地的位置。您还可以使用VPN网关通过Microsoft网络在Azure虚拟网络之间发送加密流量。为了在Azure虚拟网络和本地站点之间发送加密的网络流量，您必须为虚拟网络创建一个VPN网关。站点到站点和站点到站点网关的连接都允许我们完全删除公共端点，并通过安全VPN直接连接到虚拟机。

5.网络级身份验证（NLA）：可以在主机上使用NLA，从而只让通过了域验证的用户创建远程桌面会话。由于NLA要求发起连接的用户在验明自己的身份之前，需要与服务器建立会话，因此可以有效缓解暴力、字典攻击和密码猜测攻击带来的危害。

6.即时（JIT）网络访问：Azure Security Center中的虚拟机（VM）的即时访问技术，可用于帮助保护和锁定Azure VM的入站流量。 JIT网络访问可以通过限制端口开放的时间来缓解暴力破解攻击，同时在需要时又可以轻松为虚拟机提供相应的连接。

参考资源

PowerShell团队已经做了大量的工作，使PowerShell成为最安全透明的脚本语言和shell。 以下链接详细介绍了如何解决PowerShell的相关问题：

https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/

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

有关恶意脚本及其输出的更多信息，请参阅以下内容：

Windows Defender Malware Encyclopedia Entry: Spyware:PowerShell/Tripelog

热点概要：ShadowBrokers再一次回归，只要10万欧元（500 ZEC）就可以获得十月度的漏洞利用工具、Basics of Tracking WMI Activity、BlackBerry Workspaces服务器远程代码执行漏洞分析、Passionfruit：iOS应用黑盒评估工具、Exploiting on CVE-2016-6787、利用内存破坏实现python沙盒逃逸

国内热词（以下内容部分来自：http://www.solidot.org/）

KRACK 攻击能解密 Android 设备传输的数据，OpenBSD 提前释出补丁

世人不再嘲笑朝鲜的网络战力量

WPA2 协议漏洞让 Wi-Fi 流量能被攻击者监听

资讯类：

ShadowBrokers再一次回归，只要10万欧元（500 ZEC）就可以获得十月度的漏洞利用工具

https://steemit.com/shadowbrokers/@theshadowbrokers/october-price-adjustment

Basics of Tracking WMI Activity

https://www.darkoperator.com/blog/2017/10/14/basics-of-tracking-wmi-activity

利用内存破坏实现Python沙盒逃逸

https://mp.weixin.qq.com/s/s9fAskmp4Bb42OYsiQJFaw

BlackBerry Workspaces服务器远程代码执行漏洞分析

https://blog.gdssecurity.com/labs/2017/10/16/remote-code-execution-in-blackberry-workspaces-server.html

ROCA: Vulnerable RSA generation (CVE-2017-15361)

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

BlackOasis APT和利用0day的新目标攻击

https://securelist.com/blackoasis-apt-and-new-targeted-attacks-leveraging-zero-day-exploit/82732/

https://exchange.xforce.ibmcloud.com/collection/9ffcf4ce159e932cfe597695c1f44fe8?from=timeline

Vulnerability Patched in Democratic Donor Database

https://jlospinoso.github.io/responsible%20disclosure/abrade/hacking/2017/10/16/ngpvan-email-subscription.html

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

https://papers.mathyvanhoef.com/ccs2017.pdf

Call for WPA3 - what's wrong with WPA2 security and how to fix it

https://github.com/d33tah/call-for-wpa3/blob/master/README.md?t=1

Passionfruit：iOS应用黑盒评估工具

https://github.com/chaitin/passionfruit

windows Kernel pool memory disclosure in nt!RtlpCopyLegacyContextX86

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

Exploiting on CVE-2016-6787

https://hardenedlinux.github.io/system-security/2017/10/16/Exploiting-on-CVE-2016-6787.html

译者：興趣使然的小胃

预估稿费：110RMB

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

一、前言

在Burp上，我们可以使用多种方法来配置宏（macro），以绕过HTML表单上的CSRF tokens，这样一来，我们就可以使用Burp Active Scans、Burp Intruder、Burp Repeater，甚至也可以使用Burp Proxy进行渗透测试。我们也可以找到专为Intruder模块设计的Grep-Extract以及pitchfork攻击类型。当然，如果我们愿意的话，也可以开发自己的Burp Extension。Sqlmap上也有-csrf-token以及-csrf-url参数来应付类似场景，如果不使用这些命令，我们可以按照之前描述的方法来配置Burp，然后在sqlmap中通过-proxy参数与Burp配合使用。

在本文中，我们会介绍另一种办法，那就是使用python中的CGIHTTPServer来完成这一任务。

二、实验环境

我们构造了一个非常简单的php/mysql环境，登录后，你可以访问某个受限区域。你可以访问此链接获取实验所用的PHP代码，以便在其他场景做些修改或调整。不要在意代码细节，毕竟我并不是PHP专家，只是热衷于搭建满足需求的测试环境而已。实验环境有助于我们理解测试过程，在现实场景中寻找真正目标。

实验所用的CSRF tokens为一串随机生成的SHA256散列字符串，每个HTTP请求都对应一个不同的tokens。

三、面临的问题

不经过特殊配置时，Burp不会检测到这个问题。

同理，没有使用-csrf-token参数时，sqlmap也无能为力：

我使用了–technique、–dbms以及-p参数来加快扫描速度。由于这是一个简单的基于布尔值的SQL注入（boolean-based SQLi），我们只需要使用默认的-level 1参数即可。但我们需要将-risk设置为3，因为只有使用较高的风险数值，我们才能测试OR类型的SQL注入（OR boolean-based SQLi）场景。OR类型的SQL注入非常危险，因为这种语句可以使任何条件的结果为真。比如，在使用WHERE子句的UPDATE或DELETE语句中，使用这种注入方式，你很有可能会不小心更新数据库中所有用户的密码，或者导出用户的凭据表，而这正是你在渗透测试中应该尽力避免的结果。

在sqlmap中，我们可以使用–csrf-token=”mytoken”参数检测到OR类型的SQL注入：

由于这是一个登录验证表单，很明显会对应一条SELECT语句，这意味着使用最高的风险等级3不会带来任何风险。

当然，如果你有有效的凭据（实际渗透测试中你很难具备这个条件），此时该场景也会受AND类型的SQL注入（AND boolean-based SQLi）影响。然而，即使我拥有有效的凭据，我首先还是会使用另一个（有效的）用户名来寻找可用的OR类型SQLi，以免不小心锁定账户（如果存在账户锁定机制的话）。

在sqlmap中，我们可以使用–csrf-token=”mytoken”来检测AND类型的SQL注入：

四、使用CGIHTTPServer

创建如下CGI脚本：

我们将该脚本命名为mask.py，存放在xxx/cgi-bin/目录中，同时请确保.py文件为可执行文件。创建该文件后，我们需要在xxx目录中运行python -m CGIHTTPServer命令。默认情况下，服务器会在8000/tcp端口上监听。

首先，使用正确的密码测试这个服务器：

然后，测试一下错误的密码：

现在，无需特殊配置，我们就可以使用Burp以及sqlmap来检测SQL注入漏洞。

这就好像我们添加了一个中间层，可以简化CSRF tokens给我们测试过程所带来的复杂度，现在我们无需刻意去提交这个token信息了。

五、参考文献

译者：興趣使然的小胃

预估稿费：200RMB

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

一、前言

SMS Privacy是我创建的一个隐私短信服务，可以作为Tor隐藏服务来使用，事实上的确有约10%的用户以这种方式来使用该服务。然而，我发现有些人伪造了我的Tor隐藏服务来创建一个钓鱼网站，在本文中，我会与读者分享我发现的一些细节。

二、概述

某一天，Charlie正在网上随便逛逛，突然，他发现使用谷歌搜索“site:*.onion.to smsprivacy”会得到一些意想不到的结果。

smspriv6fynj23u6.onion是合法的隐藏服务名，然而，搜索页面中出现了另一个结果：smsprivyevs6xn6z.onion，对应的站点看起来一模一样。

经过简单调研后，我们发现这个网站是一个简单的代理网站，即：所有发往该钓鱼站点的页面请求都会被转发到真实的隐藏服务上，并会返回收到的响应数据，只有几个特殊之处除外：

1、头部中缺失Content-Length字段。

HTTP客户端可以根据Content-Length头了解待传输内容的字节数。如果代理服务器不对响应数据进行修改，那么它可以保持Content-Length头不变，直接传递这个字段，因为代理服务器知道如果内容不发生改变的话，其数据长度也不会发生变化。

然而，这个代理服务器认为响应内容会发生改变，这意味着服务器准备在某些情况下修改响应内容。

既然如此，它为什么不修改Content-Length字段，使其对应修改后的内容长度呢？

可能是代理服务器想减少页面加载时间：如果代理服务器不需要预先了解长度值，那么它就可以在收到响应内容后以数据流方式直接发送给客户端，在发送过程中修改数据。如果代理服务器需要读取所有内容，再进行修改，然后再发送所有数据，那么有可能会增加页面加载时间，引起用户怀疑。

可能代理服务器作者无法接受存储所有内容所需的高内存负载。如果同一个服务器正在代理数十个至数百个其他隐藏服务，那么采用这种方案也是可以理解的。

2、头部中Connection字段错误。

合法站点与钓鱼站点的响应头对比如下所示。

合法站点：

钓鱼站点：

3、代理服务器会缓存某些非预期的javascript文件（可能会有其他文件被缓存下来）。

我添加了一些Javascript，以检测页面是否运行在某个流氓域名上，如果的确如此，脚本会把document.referrer信息POST给我，以便后续分析。我发现使用合法网站时，浏览器会修改我使用的脚本，然而，使用钓鱼网站时，我会得到一个过时的版本，据此，我判断钓鱼站点使用了某些额外的缓存机制。这样做可能也是为了减少页面加载时间。

在写这篇文章时，我尝试着调查这种缓存机制，然后发现了更为有趣的一些信息。代理服务器会丢弃掉跟踪脚本获得的所有内容，因此我无法获取这些信息。重命名脚本并稍加修改内容后，我解决了这个问题，但我实在不想玩这种猫捉老鼠的游戏。这种情况至少意味着有人正在积极维护这个代理服务，及时采取措施保持服务正常运行。

4、隐藏服务地址被修改。

代理服务器似乎会重写smspriv6fynj23u6.onion的所有实例，将其改为smsprivyevs6xn6z.onion。尽管如此，它对大写的地址不会采用相同操作。

5、比特币地址被修改。

这是钓鱼站点的真正目的。通常情况下，钓鱼网站会窃取用户凭据，以便后续使用或者出售这些信息，但这个站点采用的方法更加直接，它将原始的比特币地址修改成攻击者可以控制的地址。

当首次重定向到支付页面时，在页面加载之前用户能感受到一段延迟，大概是因为代理服务器后台正在生成一个新的比特币地址（这个操作需要一段时间，意味着该地址正被插入一个缺少索引的规模巨大的数据库，或者该地址由速度较慢的机器生成而得，或者攻击者使用速度较慢的代码语言来生成这个地址。如果是后面这种情况，这有可能表明RNG（随机数生成器）本身也不安全）。所有以文本形式表示的比特币地址都会被重写为攻击者可控的地址，合法地址与伪造地址之间实现了一一映射关系。值得注意的是，二维码（QR）保持不变，仍然对应原始的合法地址。

我向伪造的地址（1GM6Awv28kSfzak2Y7Pj1NRdWiXshMwdGW）发起了一条支付请求，想看看会发生什么事情。这个信息并不会出现在网站上，更加确定了这是个静默代理站点。目前这笔钱还没被使用，但一旦被使用，我们可能会观察到一些有趣的信息。

三、伪造站点如何分发给用户

当用户在未知域上查看站点时，Javascript会把referrer信息POST到服务器上，我看到了一些不同的返回结果。大多数情况下，这些信息都源自于人们使用web代理（如onion.link）来查看隐藏服务，然而，我发现了两个比较特殊的隐藏服务：

7cbqhjnpcgixggts.onion：“The onion crate”：这是Tor隐藏服务的列表。与远古的“Web网站清单”类似，但专为Tor设计，其上钓鱼站点被突出标记为“钓鱼链接”（然而reddit上有人指出"The onion crate"这个服务本身就是钓鱼链接）

hss3uro2hsxfogfq.onion：“not Evil”：这是个搜索引擎服务，用来搜索Tor隐藏服务。搜索“sms privacy”时，合法站点排在第一位，钓鱼站点排在第二位。我点击了钓鱼站点旁的“滥用情况报告（report abuse）”按钮，然而目前搜索结果还没有将其删除。

这并没有给出我想要的结果。我希望找到某人仿造的推特、博客或者类似信息。“The onion crate”的后台负责人不太可能负责维护这个钓鱼站点。因为如果我希望人们使用我的钓鱼站点，那么该站点就不会被标记为“钓鱼链接”。负责维护“not Evil”搜索引擎的人有可能是肇事者，虽然这种情况也不大符合实际。如果我正在维护某个搜索引擎，目的是向用户推送钓鱼链接，那么我根本不会将正常链接包括在搜索结果中，更何况将其排在第一位。

很有可能真正的钓鱼攻击正准备实施，“The onion crate”于2017-05-17将钓鱼链接标记出来，表明这个钓鱼网站已经存活了一段时间。

四、谁是肇事者

最有可能的结果是，某个普普通通的网络犯罪分子写了个代理服务器，将比特币地址替换为自己的地址，为各种合法的隐藏服务生成了许多伪造的隐藏服务，然后坐等金钱滚滚流入他的钱包。

起初我认为是情报部门希望监控隐私短信用户，然而，如果是这种情况，他们不会修改比特币地址，导致站点失效，而是希望悄悄进行监视。我猜想情报部门会将该站点设计成只监听特定的用户子集，对其他人呈现普通的钓鱼站点，但我还是认为“普普通通的网络犯罪分子”这种可能性最大。

与传统网站的钓鱼相比，伪造隐藏服务进行钓鱼要容易得多，这是因为想要定位隐藏服务的服务器本身就不是件容易的事（这也是隐藏服务的设计理念），隐藏服务没有集中管控的命名系统，这意味着即便是合法的站点，其地址中也会包含随机字符。想要获得伪造的地址也比较容易。随后，即便伪造的钓鱼网站被发现，也没有人能够撤销攻击者的域名或者关闭掉托管的页面。这是完美的犯罪行为，唯一的缺点就是，与普通站点相比，隐藏服务站点的目标用户群体的技术水平往往更高，因此不是那么好欺骗。

五、用户如何保护自己

SMS Privacy的客户应该确保他们使用HTTPS方式浏览smsprivacy.org，如果使用Tor的话，请核实使用的隐藏服务名为唯一正确的smspriv6fynj23u6.onion。除此之外，其他访问方式几乎肯定会带来安全风险。

六、是否有用户受到影响

我尚未收到用户发来的电子邮件，抱怨他们的支付情况出现异常（当然实际情况并非如此，然而每种出错情况最终都归根于我自己犯的错误，与用户不小心浏览钓鱼网站无关）。因此，我想说的是目前没有用户受到影响，或者至少没有大量用户受到影响。

七、后续调查

我猜测运行这个代理的软件也同时正在代理其他许多隐藏服务。如果你想写些代码来代理隐藏服务，你只需要将域名改成自己的域名，将比特币地址改成自己的地址，整个过程差不多就搞定了。你可以将代理服务放置在许多上游隐藏服务的前端，这几乎不需要消耗额外的精力及资源，所以，如果攻击者没有这么做我反而会感到奇怪。

此外，如果我们探测该网站的漏洞，看看是否能找到所代理的隐藏服务的完整列表，那么也会非常有趣。攻击者很有可能在代理代码中实现主机名选择功能，也就是说请求不同的钓鱼站点可能会返回其他钓鱼站点的内容。如果出现这种结果，就可以更加确信这些代理站点运行在同一台主机上。

八、总结

发现有人正在积极从事这项活动是非常有趣的一件事情，只要稍作思考，我们可知大范围部署这种方案非常容易：只需一个周末的时间，攻击者就能搭建起基本的工作环境。如果未来有大量隐藏服务的钓鱼网站出现，我并不会感到惊讶。

九、2017-10-13更新

作者：360天马安全团队

360天马安全团队(PegasusTeam)点评：

本次的WPA2“密钥重装攻击”，基本原理为利用WPA协议层中的逻辑缺陷，多次重传握手过程中的消息3从而导致重放随机数和重播计数器，为攻击者提供了利用条件。

在协议中还存在一条危险的注释“一旦安装后，就可从内存中清除加密密钥”，若按此注释进行实现，在密钥重装攻击时会从内存中取回已经被0覆盖的key值，从而导致客户端安装了值全为零的秘钥。而使用了wpa_supplicant的linux及Android设备便因此遭受严重威胁。 整体来说，此次漏洞的危害程度弱于WEP漏洞的影响，但对于Linux及Android设备需额外注意要及时更新修补此漏洞，防止遭受嗅探、劫持等攻击。

需要注意的是：

此攻击无法破解WIFI密码，同时更改WiFi密码无法缓解此类攻击。

攻击主要面向客户端设备，路由器可能并不需要进行安装更新。

WPA/WPA2协议还是安全的，一些客户端的实现需要更改，可通过向下兼容的方式进行修复，无需更换设备。一旦修复更新发布，请立即为您的设备安装。

截止北京时间2017.10.17 14:00，官方并未公布该漏洞的POC/EXP。

1.概况

近日，安全研究员 Mathy Vanhoef 发现 WPA2 协议层中存在逻辑缺陷，几乎所有支持Wi-Fi的设备（包括但不限于Android, Linux, Apple, windows, OpenBSD, MediaTek, Linksys）都面临威胁，其传输的数据存在被嗅探、篡改的风险。攻击者可获取WiFi网络中的数据信息，如信用卡、邮件、账号、照片等，危害巨大。

这种攻击方式被命名为密钥重装攻击（Key Reinstallation Attacks）。漏洞成因在于802.11标准中没有定义在4次握手（和其他握手）中何时应该安装协商密钥，攻击者可通过诱使多次安装相同的密钥，从而重置由加密协议使用的随机数和重放计数器。

以下为此次漏洞相关的CVE编号：

CVE-2017-13077: 在四次握手中重装成对加密密钥（PTK-TK）

CVE-2017-13078: 在四次握手中重装组密钥（GTK）

CVE-2017-13079: 在四次握手中重装完整组密钥（IGTK）

CVE-2017-13080: 在组密钥握手中重装组密钥（GTK）

CVE-2017-13081: 在组密钥握手中重装完整组密钥（IGTK）

CVE-2017-13082: 接受重新传输的快速BSS切换（FT）重新关联请求，处理的同时重装成对加密密钥（PTK-TK）

CVE-2017-13084: 在PeerKey握手中重装STK密钥

CVE-2017-13086: 在TDLS（Tunneled Direct-Link Setup，通道直接链路建立）握手中重装TDLS PeerKey（TPK）

CVE-2017-13087: 处理无线网络管理（WNM）休眠模式响应帧时重装组密钥（GTK）

CVE-2017-13088: 处理无线网络管理（WNM）休眠响应帧时重装完整组密钥（IGTK）

以下为攻击Android设备的演示视频：

影响范围

由于漏洞缺陷存在于WiFi协议层，这意味着所有支持WPA2的客户端都将遭受影响。根据描述，此密钥重装攻击可用于:

WPA1及WPA2

个人及企业网络

Ciphers WPA-TKIP, AES-CCMP 和 GCMP

虽然Windows及iOS在实现“4次握手”时，不接受“消息3”的重传（未遵守802.11标准），在4次握手中不会遭到密钥重置攻击的影响，但在Group Key Handshake以及802.11r中的FT handshake中依然可被攻击。

2017年7月14日左右，Mathy Vanhoef - 便向所测产品的设备供应商发出了通知。在与多个供应商沟通后发现漏洞普遍存在于几乎所有设备上，实为协议的漏洞而非实现的问题。

2017年8月28日，CERT/CC向供应商发出了广泛的通知。

2017年10月6日，上线漏洞官网，及Paper上披露漏洞细节。

截止目前，利用工具暂未公布。

防护

及时更新无线路由器、手机，智能硬件等所有使用WPA2无线认证客户端的软件版本。（有补丁的前提下）

有条件的企业及个人请合理部署WIPS（无线入侵防御系统），及时监测合法WiFi区域内的恶意钓鱼WiFi，并加以阻断干扰，使其恶意WiFi无法正常工作。

无线通信连接使用VPN加密隧道及强制SSL规避流量劫持与中间人攻击造成的信息泄漏。

在不使用WiFi时关闭手机WiFi功能，公共WiFi下不要登录有关支付、财产等账号、密码。如需登录、支付，将手机切换至数据流量网络。

家用WiFi该怎么使用就怎么使用，WPA/WPA2本身是安全的，也不用修改WiFi密码。

修复情况

2017年10月2日，Linux的hostapd和wpa_supplicant 补丁已公布，详见 https://w1.fi/security/2017-1/。

2017年10月10日，微软在Windows 10 操作系统中发布补丁 KB4041676

苹果在最新的 beta 版本iOS、macOS、 tvOS和 watchOS中修复了无线网络安全漏洞

2.详情分析

本次攻击主要是针对WPA2协议的四次握手过程，使用了一种叫做Key重新安装攻击（KRACK）新的攻击技术。我们知道当客户端试图连接到一个受保护的WiFi网络时，AP将会发起四次握手，完成相互认证。

同时，在四次握手过程中将会协商好一个新的用于加密接下来通信数据的加密密钥。

在四次握手过程中，当客户端收到AP发来的Message 3后将会安装加密密钥key，用于加密正常的数据帧。因为message可能丢失或者被丢弃，如果AP没有收到响应AP将会重新传输message3，这样客户端可能会收到多次message3。客户端每次收到此message都会重新安装加密key，从而重置加密协议使用的增量发送数据包号nonce和接收重放计数器。而攻击者可以通过收集和重放重新发送四次握手中的message3强制重置nonce，从而成功攻击加密协议，解密客户端发送通信数据包，截获敏感信息。

另外，这一漏洞似乎是由WiFi标准中的一句话引起的。该标准建议，一旦首次安装，就可以从内存中清除加密密钥。当客户端收到四次握手的重传message3时，它将重新安装现已清除的加密密钥，有效地安装了一个全为零的密钥。

值得注意的是本次攻击没有获取到wifi网络的密码，也没有获取在四次握手过程中协商的新生的加密密钥。

演示视频分析

1、首先测试设备连接真实的TestNetWork网络：

2、开启WireShark并监听在稍后被设为钓鱼热点的网卡：

3、 攻击演示：

真实热点Real AP：

Ssid： testnetwork

MAC：bc:ae:c5:88:8c:20

Channel：6

被攻击客户端target：

MAC: 90:18:7c:6e:6b:20

伪造同名同MAC热点（Rouge AP）：

Ssid： testnetwork

MAC：bc:ae:c5:88:8c:20

Channel：1（信道不同）

注入CSA beacon pairs 将客户端信道变为1，也就是迫使客户端target与rouge AP通信。伪AP向目标target发送Disassociate数据包，使其解除关联。

4.利用网卡建立目标AP的伪造热点，迫使客户端连接到伪造热点上。此时设备经历重连，WiFI状态为正在认证。

当目标targe与真实AP完成认证过程，准备发起连接时，注入CSA beacon pairs，使信道切换到channel 1 实施中间人攻击，同时客户端状态保持在state 2，接下来开始发送四次握手中的message 3，实施密钥重新安装（Key Reinstallation Attack）攻击。

5、此时密钥重装攻击已经执行成功，客户端已连接上伪造热点：

6、在此伪造热点中，利用钓鱼网站获取用户的账号信息：

7、用户在此钓鱼网站提交的账号信息可被攻击者获取。

3.Q＆A

Q：我是否应该修改 Wi-Fi 密码？

A：家用WiFi该怎么使用就怎么使用，WPA/WPA2本身是安全的，也不用修改WiFi密码。

Q：我正在使用WPA2-CCMP。这是否仍然面临安全风险？

A：同样存在安全隐患，WPA/WPA2，PSK和Enterprise都存在风险。

Q：四次握手在理论上被证明是安全的，您的攻击为何能够实现？

A：这个攻击和之前对WPA2协议安全的证明并不矛盾。因为在证明的时候已经默认密钥只会被安装一次。

Q：是否已经有人开始对这一漏洞加以实际利用？

A：目前我们没有公布POC/EXP代码

Q：我是否应该暂时使用 WEP，直到我的设备完成补丁安装？

A：不需要，该怎么使用就怎么使用，WPA/WPA2本身是安全的

Q：与其它针对 WPA2 的攻击相比，这种攻击方式有何特点？

A：这是一种不需要依靠密码猜测的 WPA2 协议攻击手段。

0x00 事件描述

2017年10月16日, 名为KRACK的漏洞攻击方式被披露，针对WiFi+WPA2网络的攻击。

KRACK主要是利用802.11i中4次握手中的漏洞来最终实现解密和伪造加密的WiFi流量，该漏洞由来自imec-DistriNet的Mathy Vanhoef和 KU Leuven发现。本次漏洞事件有多种攻击型态，AP热点端，中继端，和客户端均受到影响。

根据krackattacks.com和部分厂商发布的安全公告综合分析，包括linux,Android, Cisco wireless products, OpenBSD, MacOS, windows, iOS等产品或平台, 影响面广泛。

360CERT建议客户端产品用户，IoT, 路由器厂商尽快进行相关漏洞评估调查。

附:技术翻译《密钥重载攻击：强制WPA2重用Nonce》一文。

0x01 事件影响面

影响面

KRACK漏洞的范围广泛，影响面大。

KRACK漏洞可造成WiFi+WPA2的加密网络流量可被攻击者解密或注入恶意攻击包，可能会泄露包括密码等在内的隐私信息，但是使用HTTPS等应用层加密层的流量不受影响。

360CERT综合分析，此次漏洞事件影响面大，漏洞等级重要，暂无规模性实际攻击案例发生，暂评定为较大网络安全事件。

漏洞信息

CVE-2017-13077: 4次握手时配对密钥(PTK-TK)重载漏洞

CVE-2017-13078: 4次握手时GTK重载漏洞

CVE-2017-13079: 4次握手时IGTK重载漏洞

CVE-2017-13080: group key握手时GTK重载漏洞

CVE-2017-13081: group key握手时IGTK重载漏洞

CVE-2017-13082: 接收FT重连请求，配对密钥(PTK-TK)重载漏洞

CVE-2017-13084: PeerKey握手时STK key重载漏洞

CVE-2017-13086: TDLS握手时TDLS,TPK重载漏洞

CVE-2017-13087: 处理WNM休眠模式响应帧GTK重载漏洞

CVE-2017-13088: 处理WNM休眠模式响应帧IGTK重载漏洞

影响版本

Arch Linux

Arista

Aruba

Broadcom

Cisco

DD-WRT

Debian

Extreme Networks

Fedora

FreeBSD

Lenovo

Juniper

Intel Corporation

LineageOS

LXDE

Marvell

Meraki

Microsoft

MikroTik

Mojo Networks

Synology

Turris Omnia

Ubiquiti

Ubuntu

UniFi

VMware

Watchguard Cloud

Windows 10

WPA_supplicant

0x02 部分技术信息

802.11i协议（即：WPA2协议）通过两种独立的机制来保证数据传输的机密性。第一个是在记录层通过加密WiFi帧的方式，保证无法被明文读取或嗅探。该加密机制通常是通过AES-CCM的方式，当然也有部分启动GCM模式，还有部分老的RC4-TKIP方式。

需要认真考虑的是AES-CCM(还包括GCM, TKIP)是一种流加密，这意味着在重用加密参数key和nonce(即:初始向量)的情况下是可以被攻击的。802.11i是基于包计数(packet number number)的方式，其在会话建立后的初始值为0，且会不停递增（当然到了2^48的时候，会触发更新key操作）。这样一来，假设在包计数不被重置的情况下，就可以成功防范key+nonce的重用攻击。

第二个机制是AP和客户端（supplicant）之间的4次握手流程，主要用于协商加密key。KRACK漏洞会直接利用到4次握手中的#3包，#3包可作用于客户端新key安装使用。

KRACK的主要漏洞在于 #3包 可以被恶意阻断。当这个情况发生时，AP端会重发这个消息，会导致同样的一个key在客户端中被重装。带来的副作用是也会导致包计数会被重置为0（部分客户端，如Android6，会把key重置为0)，最终，就会触发key+nonce的重用攻击了。攻击者可以利用它来全流量解密，TCP劫持等。

此外，还有如下2种攻击:

包括针对客户端的基于GTK的攻击；

针对AP端的802.11 RFT握手攻击；

更详细技术细节可参阅360CERT翻译的《密钥重载攻击：强制WPA2重用Nonce》一文。

Q & A

我需要更换WiFi密码吗？

更改WiFi密码并无助于防御和解决该漏洞，你不需要更改。相反的，你应该关注你使用的客户端（Android, IoT产品）是否更新，路由器固件是否更新了。当然如果你都这么做了，那你可以借此更新下你的WiFi密码了。

只支持AES套件的WPA2也受该漏洞影响吗？

是的，也受。

我的设备是否也受影响？

如果你的设备支持WiFi+WPA2连接的话(如手机，笔记本电脑等)，很可能也受到影响，请咨询相关厂商。

如果我的路由器没有发布更新怎么办？

虽然攻击者的利用可能是针对客户端的，但是路由器等也是有风险的。建议您首先联系下您的厂商确定下是否有安全更新，当然您也可以选择有安全更新的360安全路由器。

我应该暂时切换到WEP，直到我的设备被更新了？

别，这绝对不是个好选择。

这个攻击看起来很难吗？

其实实践起来并没有那么难，甚至挺普通简单的。千万别认为这个攻击很难。

0x03 安全建议

建议用户尽快评估自身的客户端,并安装对应安全更新

0x04 时间线

2017-10-16 事件披露

2017-10-17 360CERT发布预警通告

0x05 参考链接

Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse

https://www.krackattacks.com

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

https://papers.mathyvanhoef.com/ccs2017.pdf

KRACK: (K)ey (R)einstallation (A)tta(ck)

https://github.com/kristate/krackinfo

Falling through the KRACKs

https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/

Arch Linux: wpa_supplicant

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/wpa_supplicant&id=9c1bda00a846ff3b60e7c4b4f60b28ff4a8f7768

Arch Linux: hostapd

https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/hostapd&id=d31735a09b4c25eaa69fb13b1031910ca3c29ee5

DD-WRT

http://svn.dd-wrt.com/changeset/33525

MicroSoft

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080

Redhat:CVE-2017-13087

https://access.redhat.com/security/cve/cve-2017-13087

密钥重载攻击：强制WPA2重用Nonce

https://cert.360.cn/static/files/%E5%AF%86%E9%92%A5%E9%87%8D%E8%BD%BD%E6%94%BB%E5%87%BB%EF%BC%9A%E5%BC%BA%E5%88%B6WPA2%E9%87%8D%E7%94%A8Nonce.pdf

译者：Luojun, Xiaoxiong, Chenyuanhao @360CERT

0x00 摘要

本文我们将介绍密钥重载攻击，这种攻击滥用了加密协议的设计和实现来重装一个已经在使用的key。重置和key相关的参数，例如传输的nonces和重传计数器。一些加密的Wi-Fi握手包也会受到该攻击影响。

所有受保护的Wi-Fi网络使用四次握手来产生一个新的session key。目前为止，握手协议已经使用了14年，一度被认为很安全，可以免受攻击。但是，本文证明了在密钥重载攻击面前四次握手协议是脆弱的。攻击者通过操作和应答握手信息来欺骗受害者重新安装一个已经在使用的key。当密钥重载时，相关的参数例如传输包的增长序列（nonce）和重传计数器被重置为初始值。密钥重载攻击也能破坏PeerKey，组密钥和Fast BSS Transition（FT）握手协议。该影响取决于握手协议是否被攻击以及使用的数据加密协议。简单来说，针对AES-CCMP的攻击者可以应答和解密（不是伪造）握手包。这使得劫持TCP流并注入恶意数据变得有可能。而对于WPA-TKIP和GCMP允许应答、解密和伪造包影响是灾难性的。因为GCMP在传输的双方使用相同的key，影响尤为严重。

最后，我们在实践中验证了我们的观点，并发现每个Wi-Fi设备都有可能受到一些变种攻击的影响。值得注意的是，Android 6.0 强制客户端使用初始值全为零的加密key，使得我们的攻击对其影响是巨大的。

关键词：安全协议；网络安全；攻击；密钥重载；WAP2；nonce重用；握手包；包序列；初始向量

0x01 介绍

尽管历史证明它是安全的，但我们可以证明四次握手面对密钥重载攻击是脆弱的。此外，我们发现了其他Wi-Fi握手协议中有相似的缺陷。这意味着，我们也能攻击PeerKey握手，组密钥握手和Fast BSS Transition (FT) 握手。

我们攻击背后的原理在事后看来其实很简单。概括如下：

当客户端加入一个网络时，它会执行四次握手来协商得到一个新的会话key。在接收到握手的Message 3后，它会安装该key。一旦key被安装，它将被用于数据保密协议来加密正常的数据帧。但是因为消息可能丢失，如果没有收到合适的响应作为应答，接入点（AP）将重发Message 3。所以，于是客户端可能收到多次的Message 3。每次接收到该消息，客户端就会重新安装相同的会话密钥，从而重置不断增长的传输包的序列号（nonce）以及数据保密协议使用的重传计数器。我们证明了攻击者可以通过收集和重发Message 3来强制重置nonce。通过临时重置nonce，可以攻击数据保密协议。例如，数据包可以被重放，解密，或伪造，这样的技术也可以用来攻击组密钥，PeerKey，fast BSS Transition。

当四次握手或fastBSS 握手被攻击时，影响的大小取决于使用的数据保密协议。如果是使用CCMP，任意数据包都可以被解密，反之，这可以用来解密TCP SYN包来挟持TCP连接。例如，攻击者可以注入恶意内容到未加密的HTTP连接中。如果是使用TKIP或GCMP，攻击者可以解密并注入任意包。尽管GCMP是一个相对较新的Wi-Fi协议，预计在今后几年中会有很高的采用率。最后，当组密钥握手被攻击时，攻击者可以重放组寻址帧，即广播和多播帧。

有趣的是，我们的攻击并不违反四次握手和组密钥握手被证明的安全属性。特别值得一提的是，这些证明表明协商的会话密钥仍然是私有的，并且客户端和接入点（AP）的身份是被确认的。我们的攻击不会泄露会话密钥。（另外，虽然使用TKIP或GCMP可以导致正常的数据帧被伪造，但是攻击者不能伪造EAPOL消息，因此不能在握手期间伪装成客户端或AP，所以不能模拟key的安装。不同的是，当一个协商key应该被安装时，他们的模型不能阐述。）实际中，这意味着相同的key可以被安装多次，从而重置nonces和数据保密协议使用的重传计数器。

总之，本文的主要阐述如下：

（1）我们介绍了密钥重载攻击，攻击者强制重载一个已经使用过的key，从而重置任何相关的nonces或重传计数器。

（2）我们认为四次握手，PeerKey握手，组密钥握手和fast BSS transition握手容易受到密钥重载攻击。

（3）我们在实践中实施了我们的攻击，这表明所有的实现都易受某些变种的攻击。

（4）我们评估了所有802.11的数据保密协议重用nonce的影响。

本文的其余部分如下：

第二节将介绍802.11标准的相关方面。第三节主要阐述针对四次握手和PeerKey握手的密钥重载攻击。第四节则是针对组密钥的描述。第五节描述针对fast BSS transition握手的攻击。在第六节，我们将描述攻击的影响，提出对策，解释安全性失败的原因，并讨论吸取的教训。最后我们会在第七节介绍本文的相关工作，并在第八节进行总结。

0x02 背景

这个章节主要介绍802.11i修正协议，在连入WiFi网络时的各种消息和协议和802.11中使用的各种数据机密性完整性协议。

2.1 802.11i修正协议

在WEP安全性从根本上打破之后，IEEE提供了一个更加健壮的解决方式，使用802.11i作为802.11的修正协议。修正协议定义了四次握手和两个数据机密性、完整性协议WPA-TKIP和AES-CCMP。尽管802.11i修正案还在开发中，WiFi联盟开始根据802.11i D3.0版本的草案来验证设备。验证程序叫做WiFi Protected Access（WPA）。一旦802.11i 的D9.0最终版本被批准，WPA2的认证就建立在这个正式批准的版本上。因为WPA和WPA2都是基于802.11，所以在技术水平上两者几乎相同的。最主要的区别是WPA2要求支持更安全的CCMP，可选使用TKIP，而WPA是相反的。

因为功能需求，WPA和WPA2都采用四次握手保护WiFi网络。企业版网络也是依赖于四次握手。因此所有使用四次握手的WiFi网络都被这次攻击影响。

四次握手，组密钥握手和CCMP协议都正式被分析和证明是安全的

2.2 身份验证和连接

当客户端要连接WiFi网络，自动开始（互相）身份验证和连接。图2描述了连接阶段的握手。但是当第一次连接到网络时，是没有实际的身份验证。相反，使用了开放系统身份验证，对客户端进行身份验证。实际身份验证在四次握手中使用。但真正的身份认证仅在两个采用fast BSS transition握手协议的相同网络AP之间漫游时使用。

在开放式身份验证之后，客户端连接到网络中。通过客户端向AP发送一个连接请求完成。这条消息包含客户端希望使用的成对的密码组。AP回复一个连接响应，通知客户端连接是否被成功建立。

图1

图2

2.3 四次握手

四次握手提供相互身份验证，基于共享密钥技术，这种技术称为成对的主密钥Pairwise Master Key(PMK)，并协商一个新的会话秘钥PairWiseTransient Key（PTK）。在这次握手中，客户端称为supplicant，而AP称为authenticator，PMK由个人网络中的预共享密码生成，在企业网络中使用802.1x身份验证来进行协商。PTK由PMK，Authenticator Nonce (ANonce), Supplicant Nonce (SNonce)和supplicant和authenticator使用的MAC地址派生而来。一旦生成，PTK被分割成确认key(KCK),加密Key(KEK)，和临时Key(TK)，确认Key和加密Key使用来保护握手消息，TK和数据机密性协议是用来保护正常数据帧，如果使用了WPA2，四次握手协议也传输现在的Group Temporal Key组临时密钥（GTK）到supplicant。

四次握手中的每一条消息都是使用EAPOL帧格式。（如图1）对字段进行介绍

首先，消息的头部定义了所代表的消息类型，我们将使用message n和MsgN来代表四次握手中第n段消息。

Replay count（重放计数器）字段用于检测重放的数据帧：authenticator在发送一个帧之后会自增长，当supplicant对 authenticator发送的EAPOL帧做出应答时，它使用相同的replay count。

Nonce字段是一个随机的nones值，这个随机值是supplicant和authenticator在生成新的会话秘钥这一步骤产生的。

接下来，如果EAPOL帧传输一个组密钥，RSC（接受序列）包含了key起始包号。

组密钥是存储在Key Data字段，使用加密Key(KEK)加密。

最后，使用消息确认Key(KCK)来进行完整性校验. MIC（MessageIntegrity Check）

图2表示了四次握手时消息的传输格式。我们使用一下的符号标记

MsgN(r,Nonce; GTK)

表示：四次握手中的第N条消息，重放计数器 replay count 为r，给定的nonce,在’;’之后的参数都存储在数据域中，也就是说会使用KEK加密。

（1）Authenticator 通过发送message 1来初始化四次握手。包含ANonce，是唯一一个没有MIC(完整性校验) EAPOL 格式消息。

（2）当收到消息时，suplicant 生成一个 SNonce 而且导出PTK，suplicant发送message2给authenticator，message2包含了（SNonce）。

（3）authenticator收到SNonce，也会导出PTK。并且发送组密钥GTK给supplicant。

（4）supplicant在安装PTK和GTK 之后回复message4，

authenticator收到message4之后也会安装PTK，其中GTK在AP启动时就已经安装。

1,2条消息使用来传输nonces，最后两条消息是用来传输组密钥 而且使用抵御降级攻击

注意：在已经存在的连接中，PTK可以被刷新通过初始化新的四次握手。在密钥重载的过程中，所有的四次握手消息都是使用PTK完成数据机密性加密的。

2.4 机密性和完整性协议

802.11i修正协议定义了两个数据级机密性协议，第一个是TKIP（Temporal Key Integrity Protocol）暂时完整性协议。现在因为安全考虑TKIP被弃用。第二个是（AES-）CCMP，CCMP是目前最广泛使用来保证数据机密性的协议，在2012年，802.11修正协议中增加了新的数据机密性协议Galios/Count Mode Protocol（GCMP）。这个修正协议也增加了在60GHz带宽的short-range信息交互，这需要一个能够快速计算的密码（fast cipher），比如GCM。

现在802.11ad修正协议在WirelessGigabit（WiGig）中推广，而且预期在接下来几年被更快速广泛的采用。最后，802.11ac修正协议通过加入256位的key更佳的拓展了GCMP

当TKIP使用的时候，PTK的一部分：TK（暂时密钥）被分隔称为一个128位加密密钥，两个64位的MIC消息完整性检测key。第一个MIC使用在无线网热点对终端方向的消息发送，第二个则相反。这个加密使用了RC4，每个包密钥都是独特的，通过128位加密秘钥，发送者的MAC地址，和增长的48位nonce。Nonce每发送一个帧都会自动增长，用做重放计数器，当安装TK时会重置为1。通过Michael 算法来确认消息的权威性，但是Michael算法是可逆的，给一个明文和MIC值，就可以有效的恢复MIC密钥。

CCMP协议是基于AES在CCM模式下的加密方式（CBC-MAC的计数器模式）。这是一种身份验证加密，使用了Associated Data（AEAD）算法，只要特定的Key中没有重复的初始化向量就是安全的。在CCMP中，这个初始化向量是发送者MAC地址，48位nonce和一些传输帧中额外flags的组合。这个nonce也会被用作接受者的重传计数器，每次发送后都会增加1，再TK重新安装则会被初始化为0.这样可以保证初始化向量不会重复。另外的，这个构造允许TK可以被直接做为信道两个方向交互的key。

GCMP协议是基于AES-GCM，意味着使用了同样的加密计数器模式，得到的密文使用GHASH功能进行验证。和CCMP相同，是一个AEAD加密，只要在特定的key中初始化向量没有重复就可以保证安全，在GCMP中nonce作用也一样，在安装TK之后会被置为0.通常保证初始化向量只使用一次，TK可以作为交互双方的密钥，两个消息传递方向使用TK作为key。一旦nonce被重复了，就有可能重构GHASH功能使用的验证密钥。

为了表示数据帧是通过数据机密性协议加密而且验证的，使用下面的符号标记

n 表示nonce（也就是重放计数器）。参数k表示key，表示单播流量中的PTK。为了向组地址发送流量：比如广播和组播帧，使用GTK（组密钥）。最后使用两个标记符

Data(payload) 表示向单一地址发送

GroupData(payload) 向多个地址（组地址发送）

2.5 组密钥握手

Authenticator 周期性刷新组密钥，而且向所有的客户端发送组密钥，使用这些组密钥来进行握手。这些握手环节被证明是安全的，在图2的最后阶段。Authenticator 初始化所有的握手通过发送组消息 message1 给所有的客户端。Supplicant通过回复组message 2来确认收了了新的组密钥。取决于实现，Authenticator安装GTK可以在发送group Message1之后也可以在收到所有客户端的连接请求之后。最后group message 1 也包含了现有组密钥的收到重放计数器，这个字段是图1的RSC字段所有的组密钥握手消息都是使用EAPOL格式帧，使用Group1和Group2在图2中代表。注意组消息1存储了新的组密钥在数据字段中（使用KEK确认密钥加密）、所以只要PTK被安装之后，完整的EAPOL格式帧都被数据机密性协议保护。

最后，当客户端发送一个广播或者多播帧，她首先需要发送单播给AP，AP对这个数据帧使用组密钥加密，然后广播给所有的客户端。这保证了所有的在AP范围内的客户端都能收到消息。

0x03 攻击四次握手

3.1 请求状态机

802.11i的修订没有一个正式的描述Supplicant如何实现四次握手。相反，它只提供了如何实现的伪代码，并没有说明握手包将在何时被处理。幸运的是，802.11r略微扩展了四次握手，并详细描述了请求状态机该如何实现。图2包括了这个状态机的简单描述。

当第一次连接一个网络并且开始四次握手的时候，状态机会进入PTK_INIT状态。在这里，它将初始化PMK。当Supplicant接收到信息1的时候，会进入PTK-START阶段。这个经常在第一次连入一个网络的时候，或者是在前一个四次握手完成之后，会话密钥需要更新的时候。当进入PTK-START阶段，Supplicant会随机生成一个SNonce，计算一个临时PTK（TPTK），并且在信息2中将SNonce发送给Authenticator。Authenticator随后会回复Message 3，其将在MIC和重传计数器有效的时候被Supplicant所接受。如果成功，将进入PTK-NEGOTIATING状态，在这里若是TPTK和PTK相同时，Supplicant会发送Message 4给Authenticator。紧接着，就会进入PTK-DONE阶段，在这里PTK和GTK都会被装载，并且被用在数据保密协议以及密钥管理请求的完整性。最终，它会打开802.1x的端口，让Supplicant能够正常接收和发送数据包。注意，这个状态机会在Authenticator没接收到信息2和4的时候，分别重复发送信息1和3。

我们确认802.11r的状态机符合在802.11i的修订中通过文字描述的状态机。最重要的是，我们能够进行重装密钥攻击的两个要素。第一，802.11i的状态机中，AP会在没有接受到回复的时候重传消息1和3。因此，客户端必须接受这重传的信息1和3，来和802.11r的状态机相匹配。更多的，802.11i状态机要求客户端在接受并且回复Message 3之后要装载PTK。这点也和802.11r中提供的状态机相匹配。

3.2 密钥重载攻击

我们的密钥重载攻击现在很容易理解：因为Supplicant即使在PTK-Done阶段，依旧持续接受重传的Message3，我们就可以强制重载PTK。更确切地说，我们第一步在Supplicant和Authenticator中建立一个中间人（MitM）的身份。我们是用这个中间人的身份来进行Message 3的重放，并阻止Authenticator接受Message 4。这就导致了，当重放Message 3的时候，Supplicant就会重载一个已经被使用过的PTK。反过来说，这个会重置被用在数据保密协议中的Nonce。取决于不同协议的使用，这有可能造成数据包的重放、解密以及伪造。在6.1节中，我们会详细描述Nonce的重用会在不同协议中有什么实际的影响。

在攻击实践中，可能会遇到一些问题。首先，不是所有Wi-Fi设备都正确实现了状态机。特别是windows和iOS，它们不接受Message 3的重传。这和802.11标准是相违背的。总的来说，这些错误的实现并不会被我们的针对四次握手的密钥重载攻击所影响。不幸的是，从防御者的角度来说，iOS和Windows设备依旧会被我们针对组密钥的攻击所影响。另外，因为他们都支持802.11r，因此他们依旧有可能被针对AP的密钥重载攻击所影响。

第二个主要障碍是我们需要在AP和Client中获得一个中间人（MitM）的身份。这可能不能通过使用一个不同MAC地址的恶意AP在真实AP和Client间转发数据包来实现。在2.3节中提到，会话密钥（session key）是基于Client和AP的MAC地址来生成的，这意味着不同的MAC会生成不同的密钥。这会导致握手过程以及攻击过程的失败。为了解决这个问题，我们可以部署基于频段的中间人攻击，在不同频段部署和目标AP相同MAC的恶意AP来实现。这个保证了Client和AP能产生一样的会话密钥。

第三个障碍是某些实现在PTK已经被加载的时候，只接受被数据保密协议所保护的数据包。这对我们的攻击是一个问题，因为Authenticator会在不加密的情况下重传Message 3。这意味着这些重传信息会被Supplicant所忽略。即使这看起来会阻碍我们的攻击，但是我们发现了一个技术手段来绕过这个问题（3.4节）

在接下来的两节中，我们会描述如何使用我们的密钥重载攻击在不同情况下来攻击四次握手实现的细节。更确切地说，我们会先描述在Client（受害者）接受明文重传Message 3的情况。然后我们会演示对只接受加密重传Message 3的客户端的攻击。表1第6列里总结了哪些设备会在针对四次握手的不同的密钥重载攻击中受影响。不同设备的表现取决于操作系统以及被使用的无线网络设备。例如，即使Linux接受明文的重传Message 3，但是在某些Android设备里使用的网卡会拒绝它们。因此，使用不同无线芯片的Android设备事实上可能会接受明文的重传Message 3。

表1

3.3 明文重传Message 3

如果受害者在加载完会话密钥之后，依旧接受明文重传Message 3的话，我们的密钥重载攻击就很简单了。首先，攻击者会使用基于频段的中间人攻击，因此她可以控制握手包。然后她能够阻止Authenticator接受Message 4。这就是图4里的第一阶段。在发送Message 4之后很快，受害者就会装载PTK以及GTK密钥。在这种情况下，受害者依然会打开802.11x端口，并且开始传输正常数据。注意一点，在数据保密协议中的第一个数据包使用的Nonce是1。然后，在攻击的第三阶段，Authenticator会因为没有收到Message 4而重传Message 3。攻击者可以转发重传Message 3给受害者，导致它重新装载PTK和GTK。总的来说，这样会重置数据保密协议使用的Nonce和防重传计数器。注意一点，攻击者不能够重放旧的Message 3，因为EAPOL的重传计数器没有被刷新。我们现在暂时忽略攻击的阶段4。最后，当受害者传输它下一个数据帧时，数据保密协议就会使用旧的Nonce。这意味着攻击者可以在转发重传Message 3给受害者前等待任意的时间。因此，我们可以控制一定数量的会被重用的Nonce。更多的，攻击者可以一直对Client进行掉线攻击（deauthenticating），直至它重新连入网络并执行新的四次握手的过程。

图4

图4同样展示了我们的密钥重载攻击会在Message 4由于背景噪声而丢失的时候自发地出现。不同的是，接受明文重传Message 3的Client，可能会在没有攻击者的情况下重用Nonce。在这种情况下，一个攻击者可以选择性地阻塞Message 4，来区分攻击和随机背景噪声的干扰。

我们现在回到攻击的阶段4。这个阶段的目标是完成Authenticator部分的握手阶段。这不是很重要，因为受害者已经加载了PTK，这意味着它的下一个Message 4是被加密的。在Authenticator还未加载PTK时，它通常会拒绝已加密的Message 4。因此，802.11标准里揭示了Authenticator需要接受具有任意重传计数器的四次握手包，而不仅仅是最后一个。

接受Message 4的时候，Authenticator验证Key Replay Counter字段值在当前四次握手过程中使用的。

在实践中，我们发现一些AP确实接受具有旧的重传计数器的数据包。更确切的说，一些AP接受在被发送给Client数据包中使用，并且还未被Client发送回来的重传计数器。这些AP会接受旧的未加密的Message 4，就是图4里的重传计数器r+1。总的来说，这些AP会装载PTK，并且开始发送加密的单播数据帧给Client。

虽然图4只说明了Client发送的Nonce重用情况，我们的攻击同样允许我们重放数据帧。首先，在Client在阶段3中重载GTK之后，AP之后通过广播和多播的重传Message 3是可以被重放的。这是因为在重载密钥的时候，重传计数器也被重置了。第二，如果我们能够让AP装载PTK，我们同样能重放从AP单播给Client的数据帧。

我们确认，在图4中的攻击在MediaTek的Wi-Fi设备和特定版本的wpa_supplicant下是有效的。我们将在下一节解释我们攻击的另外一种实现。

3.4 加密重传Message 3

我们现在来解释我们是如何攻击那些一旦装载了PTK就只接受加密重传Message3的Client的。为了完成这个，我们利用一个使用了数据保密协议的实体在执行四次握手的时候的一个内在的竞争条件。

图5

就像先前说的，我们先来攻击Android上所实现的Supplicant。在这里，我们发现当明文重传Message 3被紧接着原始Message 3发送的时候，Android会接收这个重传信息。图5表明了为什么会发生这个情况，并且我们该如何利用它。注意一下就是，图5里并没有AP，因为AP的反应在上文中已经描述的很清楚了。在我们的攻击中，首先让Client和AP交换信息1,2。然后我们不将第一个Message 3转发给Client，而是等着AP重传第二个Message 3，在攻击的第二阶段，我们接连发送两个Message 3给Client。这时候，实现了数据保密协议的无线网卡还没有装载PTK，于是就将收到的两个包按顺序转发给CPU。这个实现了四次握手的CPU接受了第一个Message 3，并且让无线网卡装载PTK。在攻击的阶段4里，Client的CPU从接受序列里得到了第二个Message 3。及时它注意到了这个数据包并没有加密，但是Android和Linux例外允许未加密的EAPOL包，因此CPU会执行这个重传Message 3。因为网卡刚刚装载了PTK，因此这个回复会是在Nonce为1的情况下加密的。在这之后，CPU再次让无线网卡装载PTK。同时，无线网卡也会重置与PTK相关的Nonce和重传计数器，这意味着下一个数据帧会重用Nonce 1。

我们现在展示如何攻击OpenBSD，OS X和macOS。这些设备只接受加密的重传Message3。就像攻击Android设备一样，我们在无线网卡和CPU间进行一个条件竞争。然而，我们现在的目标是四次握手重载密钥的过程。就像2.3解说的，所有的信息在重载密钥的时候都会经过数据保密协议的加密。

图6

图6描述了这种攻击的细节。注意同样的AP并没有被展示在图里，因为从上文我们很清楚AP的反应会是怎么样。一样的，攻击者使用一个基于频段的中间人（MitM）身份。她让受害者和她自己进行一个初始的四次握手，并且在握手成功之后，初始化执行PTK的重载。及时她只能看到加密的数据帧，但是四次握手的信息能通过它们独特的长度和地址来探查。在这时候，攻击就像在Android那里一样，在攻击的第二阶段，攻击者没有立刻转发第一个Message 3，而是等待AP重传Message 3，然后将这两个Message 3按顺序一起发送给受害者。网卡会使用当前的PTK来解密这两个信息，然后将它们转发到CPU的接收序列。在第三阶段，CPU会执行第一个Message 3，让网卡装载新的PTK。在第四阶段，CPU会从接收序列取出第二个Message 3。当PTK被装载的时候，OpenBSD，OS X和macOS（在这里被称为CPU）会要求这个这个信息是加密的。然而，它们不会检查这个信息是使用哪个PTK密钥来加密的。因此，即使这个信息是通过旧的PTK来加密的，但是CPU依然会执行它。现在Message 4就会通过新的PTK和Nonce 1来加密并发送。在这之后，CPU会让网卡重载PTK，并且重置Nonce和重传计数器。最终，受害者发送的下一个数据帧就会使用新的PTK和Nonce 1来加密。我们确认这个攻击能在OpenBSD 6.1，OS X10.9.5和macOS Sierra 10.12里实现。

OpenBSD仅在无线网卡卸载加密的时候受影响。比如，iwn驱动和相关的设备支持硬件加密，因此他们就会收到攻击的影响。然而，rum驱动在四次握手中使用的是软件加密，那么就不会被影响。

这种攻击技术需要我们等待会话密钥被重载的那一刻。一些AP会在每个小时都重载一次会话密钥。在实践中，Client也会通过发送一个设置了Request和Pairwise位的EAPOL包给AP来请求重载会话密钥。很巧的是，Broadcom的路由器并不会验证这些数据帧的真伪（MIC），这就意味着攻击者可以强制Broadcom的AP开始重载密钥的握手。讲这些结合到一起，我们可以让重载密钥发生，这就意味着攻击者可以实施重载密钥攻击了。

3.5 攻击PeerKey握手

PeerKey握手和四次握手相关，被使用在当两个Client需要一个安全的方式来直接通信的时候。这由两个阶段组成。第一个阶段一个STSL和SMK的握手会被执行。它会在两个Client中协商密钥。而第二个阶段，一个新的会话密钥会通过主密钥产生，并且通过STK握手来传输。虽然这个协议没有被广泛的支持，但是它很好的展示了我们的密钥重载攻击良好适应性。

不出所料，SMK握手并不会被我们的攻击所影响。在这之后，主密钥的协商握手并没有被数据保密协议所保护，这就意味着它们没有Nonce和重传计数器来重置。然而，STK握手是基于四次握手的，它装载了用于数据保密协议的密钥。因此，他可以像四次握手那样被攻击。这种攻击在wpa_supplicant上通过了测试。为了实现这个测试，我们修改了一个wpa_supplicant实例，让它发送第二个（重传）Message 3。这个证实了未修改的wpa_supplicant会在STK握手中接收到重传Message 3时重载STK密钥。然而，我们没有发现其他支持PeerKey的设备。因此，我们针对PeerKey握手的攻击的影响范围很小。

0x04 攻破组密握手

在这一节，我们会在组密钥握手中，实现我们的重载密钥攻击。我们展示所有的Wi-Fi设备都会被这攻击所影响，让攻击者可以重放广播和组播的数据帧。

表2

4.1 组密钥握手的细节

网络会定期更新组密钥来保证只有近期认证的Client拥有这个密钥。在多数防御情况下，组密钥会在Client离开网络的时候进行更新。新的组密钥会通过组密钥握手进行分发，而这个握手过程已经被正式地证明是安全的。就像图2中展示的那样，握手过程由AP发送信息1给所有的Client开始。AP也会在没有收到回复的时候重传这个信息1。注意一下，EAPOL的重传计数器在这些重传信息中总是增加1。在我们的攻击中，我们的目标是收集一个重传的组信息1，阻止它到达Client，然后在一段时间后再转发给Client。这会让Client装载组密钥并重置重传计数器。

我们攻击的第一个条件是Client会在装载一个已经用过的组密钥的时候重置重传计数器。因为Client同样使用MLME-SETKEYS请求安装组密钥，这种情况就会发生。我们确定在实际中所有的Wi-Fi设备都会在装载一个用过的组密钥的时候重置重传计数器（表1列7）。因此，所有的Wi-Fi设备都会被我们随后的攻击所影响。

第二个攻击条件是我们必须能够收集一个仍然能被Client所接受的组信息1，然后这个信息中包含了已经被AP使用过的组密钥。如何去得到这个信息取决于AP何时开始使用新的组密钥。特别的事，AP将会在发送第一个组信息1之后立即使用新的组密钥，或者会延迟装载知道所有的Client都回复了组信息2表明收到了组信息1。表2第3列总结了一些AP的行为。注意根据标准，新的组密钥需要在收到所有Client的组信息2之后才能被装载。例如GTK会被延迟装载。当一个AP会立即装载新的组密钥的时候，我们的密钥重载攻击就很简单了。然而，如果AP延迟装载组密钥，我们的攻击就会更复杂。我们将会在4.2和4.3节中更详细地讨论这两种情况。

就像2.3节中所说，AP会广播和组播通过组密钥加密的数据帧。因为我们的密钥重载攻击目标是Client，这就意味着我们不能在加密的时候强制Client重用Nonce。然而，Client会在重载组密钥之后重置重传计数器，我们就可以重放这些数据帧给Client。

大多数AP每小时都会更新一次组密钥。一些网络会在每次有设备离开网络的时候更新组密钥。而且，Client可以通过发送一个设置了Request和Group位的EAPOL包来触发组密钥的握手。同样，Broadcom路由器并不会验证这些信息是否正确，这就意味着攻击者可以伪造它们来触发组密钥的更新。将这些结合起来，我们就可以假设大多数网络会进行组密钥的更新，然后我们就可以实行接下来所说的攻击。

4.2 攻击快速装载密钥的AP

图7

图7展示了当一个AP会在发送完给所有的Client的组信息1之后立即装载组密钥的情况下，我们的密钥重载攻击将会如何实现。注意组密钥的握手信息是通过当前PTK进行数据保密协议来加密的。作为组信息1的回复，Client会安装新的PTK然后返回组信息2。攻击者可以阻止AP接收这个组信息2，然后AP就会在攻击的第二阶段重传一个新的组信息1。我们现在等待一个广播数据帧的发送，然后将其转发给受害者。在这之后，我们转发阶段二中的重传组信息1。这样就会导致受害者会重载GTK，从而会重置相关的重传计数器。这就允许我们来重放广播的数据帧（阶段5）。Client会接收这个数据帧，因为它的重传计数器被重置了。

我们必须在一个广播数据帧之后再发送重传组信息1。这是因为组信息1包括了当前使用的组密钥的值以及重传计数器。因此，如果在广播帧之后发送，它就会包含一个更新过的重传计数器，那么我们就不能使受害者的重传计数器重置。

我们确定这种针对快速装载组密钥的AP在实践中是有效的。基于我们的实验，所有的Wi-Fi设备在连接这类AP之后，都会受到影响。

4.3 攻击延迟装载密钥的AP

通过组密钥握手来攻击延迟装载密钥的AP是比较复杂的。注意上一个攻击方式会因为图7中的第三阶段里那个广播数据包是由旧的组密钥加密而失败。因为在这种情况下，AP没有接收到从所有Client返回的组信息2，就不会装载新的组密钥，也就不能使旧的组密钥的重传计数器重置。

图8

图8展示了一个能够解决这个问题的方法。这种攻击的前两个阶段和上一个攻击类似。就是AP产生新的组密钥，然后将其传输给受害者，然后攻击者阻止AP接收Client发送的组信息2。这会导致AP重传组信息1，并且EAPOL的重传计数器为r + 1。在攻击的阶段三，我们转发旧的组信息2（重置计数器值为r）给AP。有趣的是，AP应该接受这个信息，及时它没有使用最新的重置计数器的值（r + 1）：

在接收组信息2的时候，AP需要验证重传计数器的值为曾经在组密钥握手过程中使用过的值。

这个标准不需要重传计数器的值和AP最新的值相匹配，而是需要和在组密钥握手过程用过的值中的一个相匹配即可，也就是任意的组信息1使用的重传计数器的值。在实践中我们发现，一些实现确实接受了这个旧的还未收到回复的重传计数器的值（表2列2）。因此，这个AP就会装载新的组密钥。在这种情况下，攻击就会想之前那个一样进行。直到第一个广播数据包被传输，我们就可以在攻击阶段5里进行重载组密钥的操作，然后在第6阶段中重放广播数据帧。

同样的，我们必须在一个广播数据帧之后再发送重传组信息1。不然我们的组信息1会包含一个更新过的重传计数器。

我们在一些延迟装载GTK的AP上进行了攻击测试，然后他们接受了先前在和Client发包时的还未收到回复的重传计数器（表2列2）。我们已经知道所有的Wi-Fi客户端会在重载GTK的时候重置重传计数器，因此他们都会被这种攻击所影响。最后，一个OpenBSD的AP并不会被影响，因为它是延迟装载GTK的，并且只接受最新的重传计数器而不是旧的。

0x05 针对802.11RFT握手的攻击

在这一节中，我们将介绍Fast BSS Transition（FT）握手并证明它的实现也受我们密钥重载攻击的影响。

5.1 Fast BSS Transition（FT）握手

一个标准的FT握手如图9的阶段1所示。

图9 针对Fast BSS Transiton（FT）的密钥重载攻击，注意它并不需要中间人，仅仅是能窃听和重放帧

图中可以观察到FT 握手不像四次握手，它由请求者初始化。前面两个消息是认证请求（AuthReq）和认证响应（AuthResp）。它们的功能相当于四次握手的Message 1和2，产生随机数来作为nonces（新的会话密钥）。在这之后，客户端发送一个重新连接请求（ReassoReq），AP回复一个重新连接响应（ReassoResp）。它们和四次握手的Message 3和4相似，用于完成FT握手和传送GTK给客户端。

5.2 针对AP的密钥重载攻击

由于AP是在响应一个重连请求后才安装PTK，所以我们的目标是重放该帧。我们注意到，在实际中，AP必须接受重连请求的重传。这是因为AP的重连响应可能由于背景噪声而丢失，所以需要客户端重新发送一个请求。

图9显示针对FT握手的密钥重载攻击。我们并不需要中间人，只需能够窃听和注入帧就行。在攻击的第一阶段，我们让客户机和AP执行一个正常的AP握手，然后等待AP传输一个或多个加密数据帧，之后我们重放对AP的重连请求包，因为FT握手不包含重传计数器和有效的MIC，所以AP将会接受并处理该重放帧。最后，AP将会在攻击的阶段3重装PTK，随之重置相关的nonce和重传计数器。因此，AP发送的下一个数据帧将会用已经用过的nonce进行加密。和之前的密钥重载攻击类似，它可以让攻击者重放之前客户端发给AP的数据包。我们认为该攻击对FT 握手的危害尤其大是因为FT的消息不包含重传计数器，这使得攻击者可以不停地重放重连请求，不停地重置AP使用的nonce和重传计数器。

我们测试了三个支持802.11r的AP。第一个是用开源的hostapd，第二个联发科设计用于家用路由器，运行在Linksys RE7000上的。第三个是一个专业的Aerohive AP。以上三个都受密钥重载攻击的影响。

由于背景噪声，重连响应包如果丢失，客户端将会自动重发重连请求包，这会导致AP密钥重载。也就是说，就算没有受到攻击，AP也已经重用nonces了。

5.3 滥用 BSS 传输请求

FT握手只有从一个站点AP漫游到另一个站点AP时才会被实现。所以攻击发生的场景是有限制的。然而我们可以强制受害者进行FT握手，具体方法如下：

0x06 评估和讨论

在这一节中我们评估nonce重用对于802.11数据机密性协议的影响，展示攻击场景，和明确漏洞实现，解释为什么安全证明错过了我们的攻击，并提出了对策。

6.1 802.11协议中重用nonce造成的影响

Nonce重用造成的影响取决于使用的数据机密性协议。对于TKIP，CCMP，GCMP。三个协议使用了流密钥来加密帧。因此，对nonce的重用总是意味着重用keystream。这可以用于解密数据包。在我们的攻击中受害者的重放计数器会被重置，因此，这三种协议都容易受到重放攻击的攻击。

当使用TKIP时，我们也可以像下面一样恢复MIC。

1.我们滥用nonce重用来解密一个完整的TKIP包，包括它的MIC字段。

2.攻击Michael算法，使用给出的明文帧和MIC密文，来恢复MIC明文。因为TKIP使用了不同的MICkey在每个不同的消息传输方向，我们可以再特定的方向上伪造数据帧。方向的源头是被重装密钥攻击的设备。表3在提到TKIP时总结了这一点

当使用CCMP时，实际的攻击被限制为对包的重放和解密。尽管有一些消息伪造攻击讨论，但这些攻击是理论上的，不能用于伪造消息。

当使用GCMP时，其影响是灾难性的。

1.可以对包进行重放和解密。

2.有可能恢复身份验证密钥，它在GCMP中用于交互双方两个方向上的通信，因此，与TKIP不同的是，攻击者可以在两个方向上伪造数据包，鉴于GCMP预计将在未来几年在以WiGig的名字广泛采用，这是一个令人担忧的情况。

一般来说，对手总是可以在特定的通信方向上重放、解密或伪造数据包。具体的方向取决于握手的方式。例如,通过四次握手攻击客户端，它可以用于

1.重放单播和广播/多播帧给客户端

2.将客户端发送给AP的帧的解密

3.伪造客户端发送给AP的帧

表3：密钥重载攻击对使用了四次握手，FT，组密钥握手数据机密性的协议影响。每一个小格都展示了在这个方向上的数据帧可以被替换、解密或者伪造。

然而，攻击FT握手行为中攻击了AP而不是客户端，意味着，攻击者可以在相反的方向重放，解密或者伪造数据包。表3在附录总结中，考虑了握手被攻击。

最后，在不同的情况下，我们可以从客户机向AP发送消息(参见表3)，有趣的是，AP通常不是数据帧的最终目的地，而是将数据帧转发。这意味着我们可以伪造数据包发视频发送到任何连接到网络的设备上。根据AP的不同，甚至可以发送一个数据帧反射回到客户机。

6.2 攻击场景

在其他方面，密钥重载攻击可以让攻击者解密TCP数据包，知道传输序号，挟持TCP数据流注入任意数据。对wifi网络最常见的攻击之一是:在未加密的HTTP连接中注入恶意数据。

重放广播和多播帧的能力。比如：组帧，也是一个明显的安全违规。为了说明这将如何影响实际系统，请考虑在广播模式下运行的网络时间协议(NTP)。在这种模式下，客户端首先通过一个初始化过程，然后通过监听身份验证的广播NTP数据包来同步它的时钟。Malhotra和Goldberg已经表明，如果这些广播包被重放，受害者将永久被困在一个特定的时刻。使用我们的组密钥攻击可以重放这些帧，即使它们是通过一个受保护的无线网络发送的。注：以这种方式操作时间会破坏安全性，例如TLS证书，DNSSEC 、Kerberos身份验证和比特币。另外一个例子是xAP和xPL家庭验证协议。这些使用UDP广播包给设备发送命令。我们推测，密钥重载攻击允许我们重放这些命令。所有这些例子都说明，重播广播或多播帧的影响不应被低估。

6.3 全零加密密钥漏洞

密钥重载攻击对于四次握手的攻击发现了wpa_supplicant的特殊行为

（1）2.3版本和更低的版本在很容易受到攻击，没有任何意外的副作用。

（2）我们发现当接收到重新传输的message3时，2.4和2.5版本安装了一个全零加密密钥(TK)。这个漏洞似乎是由802.11标准中的一句话引起的，该标准间接建议在安装了TK之后，从内存清除它。

（3）版本2.6修复了这个bug，只在第一次接收Message 3时安装了TK。

然而，在修补这个bug时，只考虑了一个良性的场景：message3被重新传输是因为message 4由于背景噪音丢失。他们没有考虑到一个活跃的攻击者可以滥用这个漏洞来强制安装一个全为零的密钥。

因此，补丁并没有被视为严重的安全问题，也没有被移植到较老的版本中。独立于这个bug，所有版本的wpa_supplicant在接收时重传的message3时重新安装组密钥，也容易受到第四章所说的组密钥攻击。

因为Android内部使用的是一个稍微修改过wpa_supplicant的版本，它也会受到这些攻击的影响。特别地，我们检查了Android wpa_supplicant 关键源代码，并发现所有的Android6.0版本都包含了全零加密密钥的漏洞。android wear 2.0也很容易受到这次攻击。尽管第三方厂商可能会在他们的Android版本中使用不同的wpa_supplicant版本，但这说明大多数Android 6.0版本都容易受到攻击。换句话说，31.2%的Android智能手机很容易受到全零加密密钥漏洞的影响。最后，我们还从经验上证实，Chromium很容易受到全零加密密钥漏洞的影响。

6.4 安全证明的限制

有趣的是，我们的攻击并没有违反对四次握手和组密钥握手的安全属性。

（1）他人证明了四次握手提供了密钥保密和会话认证。密钥保密表明只有authenticator和supplicant将会拥有PTK。因为我们没有恢复PTK，所以这个仍然正确。会话身份验证使用了匹配会话的标准概念。直观地说，协议时安全的除非攻击者能依赖消息参与到完成这个协议中。我们的攻击，包括我们使用的基于信道的中间人攻击，并不违反此属性:我们只能通过转发(转发)消息使端点完成握手。

（2）他人证实了组密钥握手中key的有序性和key保密性。密钥有序性确保supplicant不安装旧的GTK。这在我们的攻击中仍然是正确的，因为我们重新安装了新的的组密钥。另外，我们不知道组密钥，因此我们的攻击也不违反密钥保密。

然而，这些证明并没有对密钥安装进行建模。不同的是，它们不会声明密钥重载使用了数据机密性协议。在实践中，这意味着相同的密钥可以多次安装，重置为了保证数据机密性中使用的nonce和重放计数器。

6.5 对策

密钥重载攻击可以在两层上减轻。

（1）实现数据保密协议的实体应该检查是否已经安装了已经使用的密钥。如果是这样，它不应该重置相关的nonces和重放计数器。这可以防止我们的攻击，至少攻击者不能临时欺骗去实现在重新安装当前的key之前安装一个不同的(旧的)密钥。特别是，当使用这个对策时，接收组密钥的握手重放计数器只会增加。否则，攻击者可以使用旧的Group message1来临时安装一个旧的(不同的)密钥，然后使用现有的group message1重新安装新的组密钥。

（2）第二种解决方案是确保在握手过程中，在实现数据保密协议的实体中只安装一个特定的密钥。例如，在四次握手过程中生成的会话密钥应该只安装一次。当客户端接收到一个重新传输的message3时，它应该回复，但不能重新安装会话密钥。这可以通过在图3的状态机中添加一个布尔变量来实现。它被初始化为false，当在PKT-START时生成一个新的PTK时，它将被设置为true。如果在输入PTK-DONE且布尔值为true，则会安装PTK并将布尔值设置为false。如果在输入PTK-DONE时布尔值为false，则跳过PTK的安装。注：这正是2.6版本的wpa_supplicant实施的。

证明上述对策的正确性:我们NuSMV中对改进状态机进行了建模，并使用该模型证明了两个安装key总是被新的PTK分离。这意味着相同的密钥从未安装过两次。注：key保密性和会话身份验证已经在其他工作中得到了验证。

我们目前正在通知供应商关于我们发现的漏洞，这样他们就可以实施这些措施。我们所熟知的各种攻击的变种将会被提供给一个供应商名单。

6.6 讨论

从我们的结果中可以学到一些重要的教训。首先，协议的规范应该是足够精确和明确的。例如，当我们在第3.3节中攻击四次握手时，我们注意到802.11标准对于应该被接收的重放计数器的值是不明确的。更精确或更正式的规范将避免这种潜在的不正确的解释。

其次，这并不是因为协议已经被正式证明是安全的，它的实现也是安全的。在我们的例子中，在正式证明中使用的四次握手模式并没有完全反映现实。这是因为它没有定义何时应该安装协商的会话密钥。因此，不能保证只安装一次会话密钥。只有当我们读代码才发现正式模型并没有和显示情况相匹配，这些key可以重新安装。在这方面，正式的证明实际上可能会适得其反:一旦一个协议被正式验证，社区可能会对审核实际的实现变得不那么感兴趣。

有趣的是，一个模型可能是错误的，因此并不能准确地反映现实，也同样适用于我们自己的对策的证明。换句话说，不是因为我们在NuSMV中建模了对策，所有的实现现在都突然变得安全了。在现实中，我们的正式状态机可能无法准确地反映某些实现，供应商实现可能有缺陷，或者供应商可能受到未知的攻击的影响。因此，保持审计和测试实际实现是非常重要的。

译者：WisFree

预估稿费：180RMB

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

介绍

在我们之前针对64位CCleaner的分析文章中，我们跟大家介绍了关于攻击者如何修改一个合法可执行程序（赛门铁克产品）的方法。攻击者所修改的文件名为EFACli64.dll，修改过程发生在运行时代码之中，更准确地说，攻击者修改的是__security_init_cookie()函数。攻击者修改了该函数中最后一个指令并成功控制程序跳转到了恶意代码之上。但是，著名的反汇编工具IDA Pro却没办法正常显示出代码的修改情况，我们在本文中会跟大家介绍这部分信息。最后，我们还会给大家介绍如何来识别这种恶意形式的代码修改操作，以及相应的限制措施。

IDA Pro与修改后的运行时代码

在我们的对修改后的可执行程序的分析过程中，我们在发现IDA Pro在显示修改后的运行时代码（已编译版本）遇到了一些困难，因为IDA Pro无法使用可视化视图正确地显示已编译版本的运行时代码：

我们可以从上图中看到，最后一条指令为“pop rdi”。如果我们切换到文本视图的话，我们就可以立刻看到，最后一条指令其实应该是“JMP”（跳转到恶意代码）：

我们在对开源反汇编工具Radare2的源代码进行了检查和分析之后，我们发现这个函数的结尾确实是有一个jmp指令：

得到了这些信息之后，我们就开始思考了：为什么IDA Pro没有给我们显示这最后一条指令（这是最重要的一条指令）呢？

由于我们所用的这款软件并不是一款开源软件，因此我们就无法直接去查看程序源代码了。但我们可以假设IDA Pro使用了pdata数据域来获取从开始到结束的运行时函数，我们待会儿会在下一章节对这部分内容进行介绍。

那么第二个问题就来了：攻击者难道是故意利用这种机制来干扰安全研究人员的分析的吗？攻击者是运气比较好碰巧遇到了这个功能，还是说他们就是专门利用这一技巧来在IDA Pro中隐藏他们的跳转命令呢？我们现在也无法百分之百地下定论...

PDATA数据域

微软对pdata数据域的描述和介绍可以参考这篇文章。这个数据域中包含一个存储了函数条目的数组，这些函数均是用来处理程序异常的。在我们的测试环境中，pdata数据域中包含以下数据结构：

下面给出的是与我们的__security_init_cookie()函数有关的数据：

函数的结尾地址（0xF6D3）位于跳转指令的中间位置，通过修改函数的结尾地址（将原来的0xF6D3修改成了0xF6D7），IDA Pro就可以正确显示最后一条指令“JMP”了。这也就是我们为什么可以假设IDA Pro使用pdata数据域来检索运行时函数的原因了。

python脚本检测异常的运行时代码

从上面给出的输出结果中我们可以看到，地址0x0000f620的运行时函数是以一个“pop”指令结束的，这就非常可疑了。

限制

本文所介绍的这种特殊的对抗反编译技术的方法其实并不是一种完美的解决方案，我们用这种方法对大量拥有pdata数据域的64位测试样本集以及很多的合法代码进行了测试和分析，并且测试结果的假阳性非常不理想。除此之外，攻击者可以通过向pdata数据域中引入额外的字节数据来干扰我们的分析。在本文所讨论的分析场景中，我们没有发现任何的异常，而且IDA Pro还可以在可视化视图中正确显示额外的操作代码。我们认为，虽然本文所设计的方法并不完美，但这种方法对于恶意软件分析人员来说，也许可以给他们提供一种额外的代码分析工具、方法或思路。

总结

对于从事恶意软件分析的研究人员而言，想要对那些已被非法修改的合法代码进行安全分析，其实是一个非常巨大的挑战。近些年来，针对产品供应链的攻击事件也层出不穷，即便是你向厂商申请获取“看似合法”的原始代码，你拿到手上的也不一定真的是安全的源代码。当一个合法的应用程序遭到入侵之后，恶意Payload可以隐藏在合法代码的“海洋”之中，想要找到这些恶意Payload就如同大海捞针一样。在本文所讨论的特殊场景中，分析人员还会遇到额外的挑战：即IDA Pro的输出信息并不是完全可信的。我们并不清楚这是攻击者故意用来扰乱分析人员的，还是说只是我们碰巧遇到这个“Bug”，但无论怎样，这种技术会让分析人员一不小心就漏掉了影响严重的恶意代码。我们所提供的这个脚本可以帮助安全分析人员识别可疑的运行时函数，但是对于更普遍的场景而言，我们的技术就不一定能够完美适用了，但这毕竟也是一种新的工具和分析恶意代码的思路。

作者：360天马安全团队&天巡实验室

一.前言

近日，有安全研究员披露 WPA2 协议层中存在逻辑缺陷，几乎所有支持Wi-Fi的设备都面临威胁，其传输的数据存在被嗅探、篡改的风险。攻击者可获取WiFi网络中的数据信息，如信用卡、邮件、账号、照片等，危害巨大。对于用户而言，应该关注设备厂商安全公告，及时更新修补漏洞。而对于企业而言，除了督促员工尽快更新设备外，还可以利用WIPS产品来帮助抵御KRACK攻击等无线安全攻击威胁，保护企业内部的WiFI设备安全。

本文将以KRACK攻击为例，介绍WIPS产品为何能快速支持KRACK攻击检测并进行防御。

二.什么是WIPS

WIPS（无线入侵防御系统）是针对企业无线应用环境的安全威胁发现与防护系统，通过将无线通信技术、无线攻防、数据分析与挖掘等技术相结合，确保企业的无线网络边界安全、可控。

较为出名的WAIDPS，便是一款由python编写的无线入侵检测工具，基于linux平台，完全开源。它可以探测包括WEP/WPA/WPS在内的无线入侵&攻击方式，并可以收集周边WiFi相关的所有信息。

二.1.WIPS（无线入侵防御系统）基本架构

WIPS通常采用采用B/S或者C/S架构，收发引擎分布式部署在企业办公环境中，将收集到的热点信息传给中控服务器。管理员通过通过管理平台查看企业内部热点信息，对捕获到的攻击行为进行告警，并对恶意、违规的热点进行阻断。

二.2.基本功能

利用WIPS产品可以查看并管理企业内可信热点、未知热点；识别并告警可疑攻击行为；快速响应WiFi攻击及威胁事件。能够有效防止恶意热点、未知及外部热点、伪造热点、未授权移动终端等可能带来的安全隐患，从而保护企业的无线网络安全。

分布式部署在企业办公环境中的收发引擎将会回收整个区域内所有802.11原始数据并进行分析识别，如：

热点、客户端识别

回收热点、客户端BSSID、ESSID、PWR、OUI & Loc等信息。

判断并标记恶意热点、未授权热点、错误配置热点（弱密码、有漏洞的加密协议）。

发现客户端未授权连接。

..

攻击行为识别

检测MDK3去认证攻击

检测伪造合法热点攻击

检测伪造MAC地址攻击

检测Aircrack-NG无线破解攻击

..

二.3.无线攻击识别规则

由于后文对KRACK攻击的检测方法涉及检测伪造热点，此处便以此为例进行说明。

伪造热点攻击（Evil-Twin）是众多无线攻击方法中，成本较低、效果较好的一种，因此及时地发现并阻断钓鱼热点是非常必要的。常见的伪造热点攻击检测方法有：热点常规信息检测、登录凭证验证检测、时钟偏差检测等方式。

常规信息检测

利用目标AP的Beacon、Interval、SSID、Channel及其他无线信息进行比较得出判断。

凭证验证检测

利用AP登记保存的凭证信息向目标设备发起连接，若成功再用错误密码尝试连接，若提示错误则证明是合法热点。

时钟偏差检测等方式

通过计算两个相邻信标帧之间的timestamp间隔差异，即时钟偏差，与预先设定的阈值进行比较来检测伪AP。如果AP的时钟偏差值与特征库中储存的偏差值不一样，则可认定这个AP为一个无线钓鱼AP。

三.KRACK攻击原理分析

本次的WPA2“密钥重装攻击”，基本原理为：利用WPA协议层中的逻辑缺陷，多次重传握手过程中的消息3从而导致重放随机数和重播计数器，为攻击者提供了利用条件。

在协议标准中还存在一条危险的注释“一旦安装后，就可从内存中清除加密密钥”，若按此注释进行实现，在密钥重装攻击时会从内存中取回已经被0覆盖的key值，从而导致客户端安装了值全为零的秘钥。而使用了含漏洞wpa_supplicant版本的Linux及Android设备便因此遭受严重威胁。

三.1.KRACK攻击利用方式（攻击视频分析）

1、首先测试设备连接真实的testnetwork网络：

2.开启WireShark监听并在稍后被设为钓鱼热点的网卡：

3、 攻击演示：

真实热点Real AP：

SSID：testnetwork

Mac：bc:ae:c5:88:8c:20

Channel：6

被攻击客户端Target：

SSID: 90:18:7c:6e:6b:20

伪造同名同MAC热点（Rouge AP）：

SSID： testnetwork

Mac：bc:ae:c5:88:8c:20

Channel：1（信道不同）

注入CSA beacon pairs 将客户端信道变为1，也就是迫使客户端Target与Rouge AP通信。伪AP向目标Target发送Disassociate数据包，使其解除关联。

4.利用网卡建立目标AP的伪造热点，迫使客户端连接到伪造热点上。此时设备经历重连，WiFI状态为正在认证。

当目标targe与真实AP完成认证过程，准备发起连接时，注入CSA beacon pairs，使信道切换到Channel 1 实施中间人攻击，同时客户端状态保持在State 2，接下来开始发送四次握手中的Message 3，实施密钥重新安装（Key Reinstallation Attack）攻击。

5.此时密钥重装攻击已经执行成功，客户端已连接上伪造热点：

6.在此伪造热点中，被攻击端所有流量皆可被嗅探、篡改；演示视频中使用经典的MITM工具sslstrip对HTTPS进行降级，便可获取用户传输的明文账号信息。

7、用户提交的账号信息便可被获取：

三.2.检测KRACK的几种途径

之前有讲到KRACK的攻击原理，根据现有KRACK的Demo来看，攻击者的主要利用方式为：在被攻击客户端与正常AP建立连接时，攻击代码（POC）“克隆”了被攻击客户端所连接的AP，建立了一个相同BSSID、ESSID，但Channel不同的热点；通过发送Disassociate Frame迫使被攻击客户端解除关联，此时设备经历重连；准备重新与正常AP发起连接时，注入CSA beacon pairs(Channel Switch Announcement)，使信道切换到恶意AP所在信道，实施中间人攻击；同时客户端状态保持在State 2（通过对访问点进行身份验证的身份验证状态），接下来开始发送四次握手中的Message 3，实施密钥重新安装（Key Reinstallation Attack）攻击，即可与伪AP建立正常连接通信。

根据以上攻击流程，我们分析便得出KRACK现有的攻击方式特征，并能据此添加对KRACK攻击进行检测：

1. 建立同ESSID、BSSID但不同Channel的Rouge AP；

2. 向客户端发送异常Deauth／Disassociate Frame；

3. 重新发送四次握手中的message3强制重置nonce，相同IV；

4. Sequence Number和Timestamp乱序；

5. Client在建立握手的时候切换Channel；

四.红蓝对抗演示

作为使用WPA2协议设备的用户来说，官方的解决方案是等待协议漏洞的修复与厂家设备的升级。在企业环境中，能否将无线防护的主动权掌握在自己手中呢。安全专家的建议是企业应合理部署WIPS，但是WIPS能否抵御这种突如其来的无线安全威胁呢？

在详细分析了黑客的攻击过程后，天巡实验室准备进行一场红黑对抗，一组扮演黑客模拟相同的攻击手段进行无线攻击；另一组实验人员扮演企业管理员进行无线防护，同时在实验环境内部署WIPS，测试WIPS的防御效果。

1. 首先建立testnetwork热点，企业用户连接该热点并通过认证后可访问企业内网资源；通过WIPS管理员可直观了解该热点的设备属性和安全属性，包括热点ESSID、BSSID、热点厂商、频道和加密方式等等。

2. 然后黑客伪造与testnetwork相同名称及配置的热点，尝试欺骗用户连接；此时企业无线网络环境中同时出现了两个热点，非专业人员根本无法识别哪个是企业自建热点，哪个是非法的钓鱼热点。可以看到此时非法热点已经被WIPS识别出来并阻断，当前连接终端数为“无”。

3. 与此同时WIPS也第一时间向管理员通报伪造合法热点攻击事件的发生及处理情况。WIPS的及时响应为管理员在突发情况发生时争取了更多的处置时间。

4. 黑客为了使其他终端连接非法热点简直无所不用其极，泛洪终端拒绝服务攻击是成本最低也是最见效的方式。该种攻击方式可断开所有终端与合法热点的连接，在其他场景也可以干扰公共网络终端与热点的连接，造成网络瘫痪。此时WIPS系统能够发现此类攻击，在提供处理建议的同时，还能定位攻击发生的具体位置，管理员可实地排查是否有可疑人员。

5. 可以说黑客的攻击行踪已经完全暴露在WIPS之下，原本看不见摸不着的无线威胁，透过WIPS的映射逐渐变得清晰。还不知道发生了什么的黑客继续他的攻击，黑客通过收集和重放重新发送四次握手中的Message3强制重置nonce，从而成功攻击加密协议，解密客户端发送通信数据包，截获敏感信息。但是此时WIPS系统已经监测到该攻击，并对实施钓鱼的热点进行了阻断，使不知情的“用户”免于威胁。

五.小结

最终“红方”利用WIPS的监测与阻断服务，成功阻止了“黑方”利用无线网络入侵与监听数据的攻击行为。通过实验表明，WIPS的确可以有效防范KRACKs攻击。随着移动互联网、BYOD、智慧城市、物联网等无线网络应用的兴起，无线网络正在扮演着越来越重要的角色。而无线网络重应用轻防护的建设理念，将吸引越来越多的黑客征服这片未被保护的领域，KRACKs不是无线网攻击的结束，是无线安全认知与建设的开始。

安全团队

天巡实验室

前言

一篇炒冷饭的文章，全当笔记在写了，这个漏洞涉及到 JNDI与 RMI。 这里我主要只写一些其他的 “JNDI注入” 分析文章没写过的东西，如果你看的不是很明白的话可以配合其他人写的分析文章一起看。

需要知道的背景知识

JNDI的概念不细写了，只需要知道我们通过 JNDI 的接口就可以存取 RMI Registry/LDAP/DNS/NIS等所谓 Naming Service 或 DirectoryService的内容

JNDIAPI中涉及到的常见的方法与接口的作用，如：Context.lookup

JNDI中 ServiceProvider以及 ObjectFactory 的作用

Reference类的作用

RMI的相关基础知识，可以看我另一篇公众号，我记的非常全。

JNDI Service Provider

JNDI与 JNDI Service Provider的关系类似于 windows中 SSPI与 SSP 的关系。前者是统一抽象出来的接口，而后者是对接口的具体实现。如上面提到的默认的 JNDI Service Provider有 RMI/LDAP等等。。

ObjectFactory

每一个 Service Provider可能配有多个 Object Factory。Object Factory用于将 Naming Service（如 RMI/LDAP）中存储的数据转换为 Java中可表达的数据，如 Java 中的对象或 Java 中的基本数据类型。 JNDI的注入的问题就出在了可远程下载自定义的 ObjectFactory类上。你如果有兴趣的话可以完整看一下 Service Provider是如何与多个 ObjectFactory进行交互的。

PoC

EvilObjectFactory

代码如下：

Victim

Victim需要执行 Context.lookup，并且 lookup的参数需要我们可控。

我的疑问

最开始看到 PoC 的时候，我以为这是 RMI Class Loading导致的受害者会去指定的 codebase下载我们指定的类并去实例化，因为产生了很大的疑惑。

因为 RMI Class Loading是有条件限制的，比如说默认禁用，以及与 JVM的 codebase配置有很大的关系。

PoC里面向 rmi registry绑定 ReferenceWrapper的时候，真正绑定进去的应该是它的 Stub才对，Stub的对象是怎么造成客户端的代码执行的。

因为懒，这个疑问一直存在了很长时间，直到我开始正式去调试跟一下这个漏洞看看到底发生了什么。后来我看在 marshalsec那篇 pdf 里面也提到了这个问题。

Victim端的触发流程

1.ctx.lookup最终会进入com.sun.jndi.rmi.registry.RegistryContext.lookup。因为传入的 jndi url是以 rmi://开头的。

2.在 lookup里面通过 this.registry.lookup查找出远程对象，赋给 var2。这里的 var2确实是com.sun.jndi.rmi.registry.ReferenceWrapper_Stub类型的。证明我的想法是没有错的，存入 rmi registry的确实是一个 stub。

3.进入 this.decode

4.this.decode内将 stub 还原成了 Reference，这里解决了我一个疑惑。随后进入 NamingManager.getObjectInstance

5.NamingManager.getObjectInstance内部发现当前 JVM中不存在 Reference中指定的 object factory，就自动去我们指定的 codebase地址下载（并不是利用的 RMI Class Loading机制，所以解决了我另一个疑惑）并实例化我们指定的 Object Factory类，并调用其javax.naming.spi.ObjectFactory#getObjectInstance方法。

参考资料

http://docs.oracle.com/javase/jndi/tutorial/TOC.html

http://www.javaworld.com/article/2076888/core-java/jndi-overview--part-1--an-introduction-to-naming-services.html

译者：shan66

预估稿费：200RMB

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

介绍

自动取款机由各种设备组成的，并且每种设备都具有自己的固件。应用程序控制是我们最感兴趣的ATM软件型保护方案。现在，虽然该保护方案在市场上随处可见，但是仍然有人能够成功攻陷ATM。因此，我们对这款软件针对ATM的保护机制非常感兴趣，以便进一步提高黑客窃取现金的难度。

ATM

在本文中，我们研究的主题是ATM的安全性。

我们将把ATM视为一个由计算机控制的保险箱。放入ATM的钱，被装入两个安全装置中：一个用于取款，另一个用于存款。计算机通过封闭式网络连接到银行卡处理服务器。当然，ATM的制造、安装和操作会涉及到许多人员。那么，这些人都有可能利用自己的访问权限来窃取ATM中的现金。

内部的侵犯者：

软件开发人员：在代码中留下后门和bug

承包商：将加密密钥交给攻击者

服务工程师：对硬件和软件组件动手脚，恶意使用密钥，玩忽职守（在保险箱打开的时候故意离开）

运钞车押运员：偷货币箱

外部的侵犯者：

银行客户：对纸币做手脚，取出部分已经存入ATM机的纸币。

没有专业知识的攻击者：盗窃ATM、运钞车押运员、社交工程

具有专业知识和机械工具的攻击者：破坏设备、访问保险箱、操纵存款槽

具有专业知识并且能够现场左右硬件和软件的攻击者：拆解、黑盒攻击、银行卡克隆、访问ATM内的PC

具有专业知识并且能够远程左右硬件和软件的攻击者：通过本地网络进行未经授权的访问、安装恶意软件、利用软件和操作系统的漏洞

我们的特长在于针对设备可编程组件的威胁分析。

在本文中，我们将分析如何利用ATM内置PC上的软件漏洞来发动攻击。利用这些漏洞，攻击者能够以该环境中的最高权限执行任意代码。在内置计算机上执行自己的代码的好处是，允许将命令发送到吐钞器，并且每次插入银行卡时都可以发送该命令。 但是，我们的代码与内置软件不同，省略了所有不相关的细节，例如输入PIN或查看余额等。它要做的只是吐钞，并且是立即吐钞。

演示视频：

ATM的ISS规范

确保ATM安全运行的关键之一是保护系统的完整性。信息安全系统（ISS）禁止任何修改系统或添加外部组件的尝试，包括：软件（可执行文件、软件安装包、脚本）和硬件（USB存储设备、CD/DVD设备）。这样做的目的是防止任何无关的代码在设备上运行。 该系统必须仅实现其自身的功能，并且始终如此。这听起来非常不错，但是现实中，仍存在很多方法可以将恶意软件上传到ATM电脑中：

本地访问：

连接USB总线，方法是弄掉相机，或在电线的位置打孔

打开ATM主体，并通过复制的服务密钥插入磁盘、U盘、无线键盘插头

远程访问：

从银行通过远程桌面上传恶意软件

利用为监控和管理设备而安装的网络服务中的漏洞

此外，访问控制也同样重要。对设备、进程、文件系统、注册表对象和其他元素的访问是由系统控制的，并且如果配置正确的话，攻击者在攻击的初始阶段只具有有限的权限。即使绕过了上述完整性控制，攻击者仍然需要进行提权才能访问关键的资源，例如吐钞器。

此外，市场上面也有一些旨在减轻运营ATM的银行的风险的产品。其中许多产品都是由知名的AV供应商提供的，已经开发的技术包括：支持签名、启发式、仿真器和脱壳功能的AV扫描软件；HIPS（主动保护、行为分析）；防火墙。鉴于这类设备具有特殊的安全性要求，所以这些产品还提供了更严格的安全对策，例如应用程序白名单和设备控制（通常称为完整性控制工具）以及辅助访问控制工具（与OS本机工具相关） 。

我们研究了其中一些ISS组件，并了解了它们的一些有趣的工作原理。下面，我们来考察一下作为这种产品的一员的卡巴斯基嵌入式系统安全（KESS）。

KESS功能概述

在其最低配置情况下，该解决方案仅执行系统完整性控制。完成该任务的有两个模块：

设备控制——控制USB存储设备（如闪存驱动器、外接HDD、MTP Media Player设备等）的连接

应用程序启动控制——控制系统中运行的代码。其中有些规则用于：

进程的运行和库的加载

脚本的运行和MSI软件包。通常情况下，对象是通过数字签名、哈希值和路径来进行标识的

KESS遵循“默认拒绝”策略：禁止所有未明确允许的内容。

此外，您还可以添加实时文件保护——防病毒功能。AV扫描软件将在访问文件时通过签名和启发式方法对文件进行检测。

有关该产品的更多信息，请参阅如下演示文稿： http://www.bts.md/BTS_files/Kaspersky%20Embedded%20Systems%20Security.pdf6

KESS的体系结构

该系统分为两层：

内核模式：KESS驱动程序将在这个特权内核执行模式下运行

用户模式：介于用户和系统进程之间运行的KESS服务在这个模式下运行

图中的组件包括：

驱动程序KLAM.SYS，卡巴斯基实验室拦截器和活动监视器。它为文件系统注册一个过滤器，并在访问文件系统对象时获得对回调的控制权。注册将通知例程去创建进程和线程。因此，它的作用是在内核模式下执行系统范围的监视和控制。该驱动程序是应用程序启动控制和实时文件保护的一部分。

驱动程序KLFLTDEV.SYS，卡巴斯基实验室PNP设备过滤器，用于控制标示为“大容量存储”的PNP设备的使用情况；它属于设备控制的一部分。

驱动程序KLRAMDISK.SYS，卡巴斯基实验室虚拟RAM磁盘。

KlamMsgPort是驱动程序KLAM.SYS和进程KAVFSWP.EXE的消息通道。来自用户模式的各种请求将通过该通道传递给驱动程序。

KAVFS.EXE服务和KAVFSWP.EXE子进程。ISS的检测和解决方案的逻辑都集中在这里。将判决结果传递给驱动程序，从而决定允许或阻止受监视进程的操作（例如，加载DLL）

KAVFSWH.EXE服务进程：实现应用程序和外部代理之间的互连以实现进程内存的保护。

KAVFSGT.EXE服务进程：提供KESS管理功能。

攻击KESS

我们将尝试绕过该安全系统，并在机器上实现代码的提权，这样我们的代码就可以控制吐钞器了。根据该产品提供的解决方案的结构，我们的攻击策略分为以下几个阶段：

首先，获取本地访问权限，绕过设备控制，为在PC上输入我们的数据扫清障碍。我们将绕过过滤器（它会阻止第三方设备连接），并将我们的二进制文件和脚本放到主机上，以便进行下一步的工作。

然后，我们将绕过“应用程序启动控制”机制，在机器上运行我们的代码。

最后一步：我们将通过利用KESS漏洞，通过windows访问控制系统提升我们的进程的权限。这将使我们能够随意访问系统的对象。

绕过KESS

绕过设备控制

KESS限制使用USB驱动器。如果该功能已启用并进行了正确的配置，则可阻止攻击者使用的USB工具。

但是，它是唯一一种可以控制的设备。

如果ATM的主机有一个物理上可以访问的CD驱动器，那就根本无法阻止攻击者从外部上传文件。另外，通过远程桌面访问也是一样的。

如果这些尝试没有成功，那么还有其他绕过方法，包括：

USB、PS/2键盘键盘仿真器，它们可用于：

VBS脚本或内置的Certutil实用程序将打印字符解码为二进制数据

作为十六进制编辑器的旧式DEBUG调试器

空闲的COM端口也可用于数据传输，并且可从cmd命令行获得

所以，有许多方法可以在机器上输入数据。将键盘添加到白名单是不可能的，因为这会令维护服务变得异常复杂。

绕过启动控制

KLAM.SYS驱动程序捕获可执行文件和脚本的启动，以及程序库的加载。

之后，它将其发送给KAVFSWP.Exe（根据指定的规则）进行检查。如果是外部的组件，则不允许使用。

PowerShell

在操作系统中存在许多内置的解释器，如WScript，尽管禁止执行任意脚本，但它们仍然是可以使用的。例如，可以这样做：

这样，文件中的代码就会在解释器中执行，我们就可以完成读写文件和注册表项、启动进程等（请参阅Windows Script Host）操作。虽然这很有趣，但是对于使用吐钞器来说，这是远远不够的。我们需要的是在本地运行代码。

PowerShell在这方面要更加灵活，因为它可以直接访问系统API。为了运行shellcode，可以调用VirtualAlloc、WriteProcessMemory和CreateThread，其实很简单。你可以用之前介绍过的相同方法来解决禁止执行脚本的问题：

但是，PowerShell通常不会安装在Windows XP机器上。在这种情况下，您可以使用以下方法。

带签名的可执行文件

在默认情况下，机器会允许运行带有操作系统信任的数字签名的二进制文件。这适用于所有Windows组件。例如，您可以使用Microsoft签名的调试器将shellcode注入合法进程。也就是说，可以将NTSD调试器与Windows XP一起使用；在所有版本的Windows中都有一个带有签名的调试库，即dbgeng.dll。

NTVDM

对于KESS来说，它并没有禁止运行DOS可执行文件（EXE，COM）。同时，人们发现，NTVDM也是一种提升权限的好方法。

http://web.archive.org/web/20160309015106/archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html

超时

最近，有人公布了针对KESS的超时攻击方法。该方式通过并行运行大量二进制实例来耗尽系统资源。这种攻击会令验证模块超载，从而使得针对启动进程的系统调用的检测超时，这样，就会允许进程启动而不必等待KESS的决定了。

这样，您可以绕过设备控制和应用程序启动控制白名单，从而在本地或远程访问PC的过程中实现任意代码执行了。下一步是提升权限，以绕过操作系统的访问控制。

译者：shan66

预估稿费：200RMB

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

传送门

【技术分享】黑客如何破解ATM，2分钟顺走百万现金 （上）

操纵KESS：提升权限

漏洞

在调查KESS的KLAM.SYS驱动程序时，我们发现一段有趣的代码：

之后，会再次从头到尾处理该列表，并且对于每个模块，都将存放列表数据的结构添加到已分配的缓冲区中。然后，将缓冲区中的偏移量与sz值（而不是sz + 0x1000 - 参见（3））进行比较，以防止发生溢出。

最后，为缓冲区添加8个以上的零，并返回其指针和大小。

实际上，这个缓冲区大小的计算过程有可能发生一个整数溢出。为此，可以：

1.构造一个InMemoryOrderModuleList_fake链接列表，使得第一次循环中，字符串与剩余其他内容的长度之和等于0xffffdff8；

2.将其放在PEB中；

3.通过这个函数触发列表审核;

4.在步骤（2）的操作算法中，该函数将被分配一个值sz + = 0x1008（Sz = 0xFFFFDFF + 0x1008 = = 0xFFFFF000）；

5.调用ExAllocatePoolWithTag，表示大小的参数Sz_arg = sz + 0x1000（sz_arg = 0xFFFFF000 + 0x1000 = = 0）——将分配一个长度为零的缓冲区；

6.然后，InMemoryOrderModuleList_fake的数据将被复制到这个缓冲区，直到偏移值 offs > sz（sz == 0xFFFFF000），这远大于前面分配的缓冲区长度，即零字节:)

对于sz的任何取值，我们都可以为其构建一个InMemoryOrderModuleList_fake。在0xFFFFDFF8 <= sz <0xFFFFEFF8的范围内，我们可以分配大小为0到0x1000字节的缓冲区，然后再设法溢出。

溢出控制

要进行溢出，我们需要解决下面的问题：

1.数据将被复制到缓冲区，直到偏移值 offs> sz，其中sz接近最大的无符号整数，即约4 GB——这时候就应该停下来。

2.让驱动程序在我们的exploit上执行这个函数。

3.把处于我们控制之下的对象放在内存池中，以避免对随机内核对象造成损害。

控制溢出规模

复制4GB的数据简直就是DoS。

第一个想法是在执行易受攻击的函数时替换InMemoryOrderModuleList指针，以使sz的值被溢出；并且在第二次运行时，该列表就会获得一个更适合填充所分配的内存的大小。

实际上，这个想法是可以实现的。当驱动程序处理我们的InMemoryOrderModuleList列表时，它不会阻塞进程，我们可以对另一个指针进行写操作，让它指向PEB。不过，很难抓住合适的替换时机，所以我们只好通过循环，将一个值改为另一个，并希望有好运气。这种方法是可行的，但是非常不稳定。

此外，我们还偶然发现了另一种方便的方法。我们已经注意到，当将数据字符串从指向模块路径的无效指针复制到缓冲区到时，系统没有崩溃蓝屏。关键是，在函数的反编译列表中看不到这些，因为有一个处理程序来处理异常：

当代码运行到memcpy-rep的mov时，ESI寄存器包含一个指向无法读取的存储器的指针，从而将控制权移交到这里；缓冲区被释放；从函数返回，然后继续。我们可以准备好要复制到缓冲区的数据，以便当我们需要使用PAGE_NOACCESS属性阻塞该内存页时，数据的末尾正好是模块路径字符串。 这样，我们可以准确可靠地控制溢出的长度和内容。

触发函数

据说，如果发现某种恶意软件将自身注入到某些进程中的时候，KESS服务就会调用该函数。然而，当扫描大量不同的样本时，发现并没有触发它。

通过运行内存扫描来执行这个存在漏洞的函数是很方便的方法：

但是，没有管理员权限的用户无法做到这一点。我们已经逆向了kavshell.exe，证实运行扫描的权限检查位于KESS服务中，而不是在其界面中，所以我们无法通过提交这种扫描请求而绕过权限检查。KESS开始运行时会为每个进程调用该函数，所以您还需要停止它的权限。您可以通过发送一个样本来重新启动服务，这个示例会导致扫描引擎在解压缩时发生DoS。

进行扫描的时间是系统开始时。该exploit可以放入当前用户可用的自动运行区域，然后重启机器。一旦exploit运行，就会启动扫描并影响我们的进程。但是，为了在内存池中进行喷射来控制分配的顺序，这需要更多的时间；并且，如实验所示，这段时间对我们来说太长了。我们将执行以下操作：所有进程都进行相应的扫描——从最新的进程到最旧的进程。该exploit会启动500个处于挂起模式的计算器程序，当KESS内核处理这些进程的时候，我们就获得了比较长的一段时间。

分页池喷射

为了把我们控制的对象放到溢出的缓冲区之后，我们可以设法生成所需的内核内存状态。我们需要知道，易受攻击的缓冲区需要分配到分页池中。这有点麻烦，原因如下：

当覆盖回调函数时，可用于快速获取控制权的对象被分配到了非分页池中了，具体示例可以看这里。

存在多个页面池，分配程序会来回切换以平衡负载。

要了解更多详细信息，强烈建议您深入研究windows内核分配程序的体系结构。

填充

通过连接调试器并检查分页池的PoolDescriptor.ListHeads列表，请注意，KESS内存扫描是在Windows启动之后进行的，这时候分配的大小与密集的系统初始化过程无关。

例如，我们可以分配一个大小为0x400字节的块，因为系统不太可能在我们的攻击过程中分配和释放相同大小的块，也就不会在喷射中引发错误而影响exploit的可靠性了。您可以通过创建命名对象（例如事件）在分页池中分配这些块。对象名称字符串由WCHAR字符组成，然后将其放入KESS驱动程序用于创建模块列表的同一个页面池中。我们可以设置易受攻击的缓冲区的大小以及用作事件名称的字符串的大小，以使它们进入相同的PoolDescriptor.ListHeads列表。

我们还需要在各个分页池中分配一个块数组。实验表明，在exploit中逐个创建对象会导致相同的池被重用以存储对象的名称字符串，因此，在存在漏洞的驱动程序函数中调用分配程序时，返回的内存块可能源自系统多个页面池中的任何一个。在我们的exploit中，每创建1000个对象后，我们就会添加一个很小的延迟，这个时间通常足以让分配程序切换页面池索引。这样，所有的页面池都将被填满。

接下来，我们通过喷射制造大小为单个内存块的孔洞，从而破坏之前创建的一些对象。指定大小的空闲块被返回给PoolDescriptor.ListHeads列表，然后等待KESS驱动程序去分配。

利用溢出

由于exploit的这部分内容与具体的架构有关，所以这里将使用32位Windows 7 作为目标系统。

在页面池中，可以通过不同的方法来利用溢出漏洞。我们使用的方法是覆盖下一个内存块中的Poolindex。当内存块被释放时，该值被用为PoolDescriptor的索引，指向释放的内存块所要添加到的ListHead。

PoolDescriptor含有PendingFrees列表，即等待添加到ListHeads的块。

首先，ExFreePoolWithTag在其自身内部调用ExDeferredFreePool来释放PendingFrees：合并空闲的相邻块并将它们附加到所需大小的ListHead中。然后，控制从ExDeferredFreePool返回给ExFreePoolWithTag，释放的块将通过该函数添加到PendingFrees中。

当覆盖PoolIndex的值大于系统创建的页面池（在我们的例子中为5）的数量时，对ExDeferredFreePool的调用将采用NULL值——数组中未初始化的地址，当创建页面池时会将这些地址添加到PoolDescriptor。

ExDeferredFreePool必须解除NULL引用，并根据其算法使用PendingFrees和该无效地址结构中的其他成员进行工作。

对于Windows 7来说，NULL指针解引用是必须使用的选项。使用NtAllocateVirtualMemory系统API，我们可以从NULL开始选择内存页，这使得该这片内存非常便于进行读写操作。在这些内存页上，我们可以精心伪造一个PoolDescriptor，让所有成员都具有合适的值，以使ExDeferredFreePool可正常工作。

ExDeferredFreePool将使用我们伪造的PoolDesciptor，并传入PendingFrees列表。它将从该列表中获取一个内存块，检查它和相邻内存块的头部，并将内存块的地址插入到我们的页面池对应的ListHead中。这就是整个行动的关键。

为了将一个表项添加到链接列表中，ExDeferredFreePool中的代码将使用存储在我们的描述符中的指针，并根据指针（从Pendingfrees中释放的内存块的地址）从我们的描述符中写入相应的值。

这样，我们已经把相应缓冲区后面的分配头部覆盖了，从而可以向任意地址写入任意的值了。

充分利用向任意地址执行写操作的能力

在这个基础上，我们可以在一些回调函数中记录shellcode地址，并实现内核模式的执行。这里有一个经典的令牌窃取shellcode，它可以浏览系统中的进程列表，取访问令牌的地址，将我们的进程的访问权限升级到最大的“NT AUTHORITY / SYSTEM”。

但是，我们将采用其他的方法。实际上，有一个NtQuerySystemInformationsystem API，它可以将系统中所有处理程序的信息写入SystemHandleInformation参数。 对于每个处理程序，其引用的内核对象的地址讲被全部公开。 我们可以使用以下方式获取进程的令牌的处理程序：

该对象就是我们要覆盖的目标，因为它包含了定义我们在系统中的访问权限的字段。

只要在正在寻找其地址的令牌中设置一个位，就可以直接赋予我们的进程以SeDebugPrivilege特权，而根本无需劫持内核代码控制流。

利用SeDebugPrivilege

我们的进程由于具备了系统范围级别的调试权限，因此可以读取、写入和执行其他进程中的代码，包括系统进程。通过WriteProcessMemory和CreateRemoteThread，我们对任何进程都可以轻松地进行注入，而不是仅限于有限的用户进程。

还有一些小的细节：

从Windows 7开始，我们无法通过CreateRemoteThread在自己的会话之外的进程中创建新线程。所以，理想的目标是KESS服务进程:)

在会话内部，winlogon也可以用，这时我们的代码能够获取到“NT AUTHORITY/SYSTEM”令牌。

有人会想，对于HIPS来说，最关心的难道不就是通过WriteProcessMemory和CreateRemoteThread进行注入吗？然而，KESS并没有从事这方面的行为分析，而是采取了完全容忍的态度。

因此，您完全能够利用KESS的漏洞来提升权限。

完整的攻击向量

从该产品中发现的安全漏洞来看，我们认为攻击者完善的计划大致如下：

1.在ATM机的塑料面板上打一个孔；然后，访问USB总线。当然，如果可以直接接触到计算机本身就再好不过了。

2.连接键盘模拟器，打开记事本，输入一个base64编码的zip文件，其中存放供将来使用的各种工具。保存该文件。

3.键入将上面的文件解码为二进制形式的VBS脚本，运行脚本，并解压文件。

4.将exploit保存到自动运行的注册表中。重新启动计算机。

5.您必须选择最佳选项，以便您不必在文件中携带任何附加组件。

5.1。如果目标机器运行的是Windows XP，则使用我们提供的脚本运行NTSD调试器。通过脚本控制该调试器，将shellcode注入到某个进程中，例如Calc。

5.2。如果目标机器运行的是较高版本的操作系统，则通过另一个脚本运行PowerShell，该脚本使用VirtualAlloc、WriteProcessMemory和CreateThread在其内存中运行shellcode。

6.将Shellcode读入内存并运行exploit的主要部分，以利用KESS驱动程序漏洞来提升权限。

7. 如果exploit一切顺利的话，攻击者将以“NT AUTHORITY/SYSTEM”权限进入系统。这样就可以运行该攻击中用到的最后一部分代码了。我们可以通过两种方式将命令发送到吐钞器：

7.1。自己填写数据包，并将其发送给驱动程序，让其发送到设备。

7.2。使用通用和有文档说明的XFS界面，这样与设备通信时，就不用考虑具体的硬件类型了。这是在大多数已知的ATM恶意软件中所使用的方式，这些软件包括：Tyupkin、Atmitch、GreenDispenser和Suceful。

小结

我们的分析表明，不包含内置保护机制或不包含OS设计中隐含的保护机制的软件非常容易被攻击者绕过，因为其所在系统的属性与该软件蕴含的安全属性不兼容 。因为，操作系统不是为了维护这种边界而设计的。

将可执行文件静态过滤为可信和不可信（或恶意）文件的方法，并不能杜绝机器状态被操纵的情况发生。

此外，由这种特权实体进行文件分类的复杂逻辑，实际上扩大了被攻击面，因为这样的话，其代码中的常见缺陷会给系统引入更多的漏洞。

Exploit演示视频

作者：360天马安全团队&天巡实验室

1.前言

近日，有安全研究员披露 WPA2 协议层中存在逻辑缺陷，几乎所有支持Wi-Fi的设备都面临威胁，其传输的数据存在被嗅探、篡改的风险。攻击者可获取WiFi网络中的数据信息，如信用卡、邮件、账号、照片等，危害巨大。对于用户而言，应该关注设备厂商安全公告，及时更新修补漏洞。而对于企业而言，除了督促员工尽快更新设备外，还可以利用WIPS产品来帮助抵御KRACK攻击等无线安全攻击威胁，保护企业内部的WiFI设备安全。

本文将以KRACK攻击为例，介绍WIPS产品为何能快速支持KRACK攻击检测并进行防御。

2.什么是WIPS

WIPS（无线入侵防御系统）是针对企业无线应用环境的安全威胁发现与防护系统，通过将无线通信技术、无线攻防、数据分析与挖掘等技术相结合，确保企业的无线网络边界安全、可控。

较为出名的WAIDPS，便是一款由python编写的无线入侵检测工具，基于linux平台，完全开源。它可以探测包括WEP/WPA/WPS在内的无线入侵&攻击方式，并可以收集周边WiFi相关的所有信息。

2.1WIPS（无线入侵防御系统）基本架构

WIPS通常采用采用B/S或者C/S架构，收发引擎分布式部署在企业办公环境中，将收集到的热点信息传给中控服务器。管理员通过通过管理平台查看企业内部热点信息，对捕获到的攻击行为进行告警，并对恶意、违规的热点进行阻断。

2.2.基本功能

利用WIPS产品可以查看并管理企业内可信热点、未知热点；识别并告警可疑攻击行为；快速响应WiFi攻击及威胁事件。能够有效防止恶意热点、未知及外部热点、伪造热点、未授权移动终端等可能带来的安全隐患，从而保护企业的无线网络安全。

分布式部署在企业办公环境中的收发引擎将会回收整个区域内所有802.11原始数据并进行分析识别，如：

热点、客户端识别

回收热点、客户端BSSID、ESSID、PWR、OUI & Loc等信息。

判断并标记恶意热点、未授权热点、错误配置热点（弱密码、有漏洞的加密协议）。

发现客户端未授权连接。

..

攻击行为识别

检测MDK3去认证攻击

检测伪造合法热点攻击

检测伪造MAC地址攻击

检测Aircrack-NG无线破解攻击

..

2.3.无线攻击识别规则

由于后文对KRACK攻击的检测方法涉及检测伪造热点，此处便以此为例进行说明。

伪造热点攻击（Evil-Twin）是众多无线攻击方法中，成本较低、效果较好的一种，因此及时地发现并阻断钓鱼热点是非常必要的。常见的伪造热点攻击检测方法有：热点常规信息检测、登录凭证验证检测、时钟偏差检测等方式。

常规信息检测

利用目标AP的Beacon、Interval、SSID、Channel及其他无线信息进行比较得出判断。

凭证验证检测

利用AP登记保存的凭证信息向目标设备发起连接，若成功再用错误密码尝试连接，若提示错误则证明是合法热点。

时钟偏差检测等方式

通过计算两个相邻信标帧之间的timestamp间隔差异，即时钟偏差，与预先设定的阈值进行比较来检测伪AP。如果AP的时钟偏差值与特征库中储存的偏差值不一样，则可认定这个AP为一个无线钓鱼AP。

3.KRACK攻击原理分析

本次的WPA2“密钥重装攻击”，基本原理为：利用WPA协议层中的逻辑缺陷，多次重传握手过程中的消息3从而导致重放随机数和重播计数器，为攻击者提供了利用条件。

在协议标准中还存在一条危险的注释“一旦安装后，就可从内存中清除加密密钥”，若按此注释进行实现，在密钥重装攻击时会从内存中取回已经被0覆盖的key值，从而导致客户端安装了值全为零的秘钥。而使用了含漏洞wpa_supplicant版本的Linux及Android设备便因此遭受严重威胁。

3.1.KRACK攻击利用方式（攻击视频分析）

1、首先测试设备连接真实的testnetwork网络：

2.开启WireShark监听并在稍后被设为钓鱼热点的网卡：

3、 攻击演示：

真实热点Real AP：

SSID：testnetwork

Mac：bc:ae:c5:88:8c:20

Channel：6

被攻击客户端Target：

SSID: 90:18:7c:6e:6b:20

伪造同名同MAC热点（Rouge AP）：

SSID： testnetwork

Mac：bc:ae:c5:88:8c:20

Channel：1（信道不同）

注入CSA beacon pairs 将客户端信道变为1，也就是迫使客户端Target与Rouge AP通信。伪AP向目标Target发送Disassociate数据包，使其解除关联。

4.利用网卡建立目标AP的伪造热点，迫使客户端连接到伪造热点上。此时设备经历重连，WiFI状态为正在认证。

当目标targe与真实AP完成认证过程，准备发起连接时，注入CSA beacon pairs，使信道切换到Channel 1 实施中间人攻击，同时客户端状态保持在State 2，接下来开始发送四次握手中的Message 3，实施密钥重新安装（Key Reinstallation Attack）攻击。

5.此时密钥重装攻击已经执行成功，客户端已连接上伪造热点：

6.在此伪造热点中，被攻击端所有流量皆可被嗅探、篡改；演示视频中使用经典的MITM工具sslstrip对HTTPS进行降级，便可获取用户传输的明文账号信息。

7、用户提交的账号信息便可被获取：

3.2.检测KRACK的几种途径

之前有讲到KRACK的攻击原理，根据现有KRACK的Demo来看，攻击者的主要利用方式为：在被攻击客户端与正常AP建立连接时，攻击代码（POC）“克隆”了被攻击客户端所连接的AP，建立了一个相同BSSID、ESSID，但Channel不同的热点；通过发送Disassociate Frame迫使被攻击客户端解除关联，此时设备经历重连；准备重新与正常AP发起连接时，注入CSA beacon pairs(Channel Switch Announcement)，使信道切换到恶意AP所在信道，实施中间人攻击；同时客户端状态保持在State 2（通过对访问点进行身份验证的身份验证状态），接下来开始发送四次握手中的Message 3，实施密钥重新安装（Key Reinstallation Attack）攻击，即可与伪AP建立正常连接通信。

根据以上攻击流程，我们分析便得出KRACK现有的攻击方式特征，并能据此添加对KRACK攻击进行检测：

1. 建立同ESSID、BSSID但不同Channel的Rouge AP；

2. 向客户端发送异常Deauth／Disassociate Frame；

3. 重新发送四次握手中的message3强制重置nonce，相同IV；

4. Sequence Number和Timestamp乱序；

5. Client在建立握手的时候切换Channel；

4.红蓝对抗演示

作为使用WPA2协议设备的用户来说，官方的解决方案是等待协议漏洞的修复与厂家设备的升级。在企业环境中，能否将无线防护的主动权掌握在自己手中呢。安全专家的建议是企业应合理部署WIPS，但是WIPS能否抵御这种突如其来的无线安全威胁呢？

在详细分析了黑客的攻击过程后，天巡实验室准备进行一场红黑对抗，一组扮演黑客模拟相同的攻击手段进行无线攻击；另一组实验人员扮演企业管理员进行无线防护，同时在实验环境内部署WIPS，测试WIPS的防御效果。

1. 首先建立testnetwork热点，企业用户连接该热点并通过认证后可访问企业内网资源；通过WIPS管理员可直观了解该热点的设备属性和安全属性，包括热点ESSID、BSSID、热点厂商、频道和加密方式等等。

2. 然后黑客伪造与testnetwork相同名称及配置的热点，尝试欺骗用户连接；此时企业无线网络环境中同时出现了两个热点，非专业人员根本无法识别哪个是企业自建热点，哪个是非法的钓鱼热点。可以看到此时非法热点已经被WIPS识别出来并阻断，当前连接终端数为“无”。

3. 与此同时WIPS也第一时间向管理员通报伪造合法热点攻击事件的发生及处理情况。WIPS的及时响应为管理员在突发情况发生时争取了更多的处置时间。

4. 黑客为了使其他终端连接非法热点简直无所不用其极，泛洪终端拒绝服务攻击是成本最低也是最见效的方式。该种攻击方式可断开所有终端与合法热点的连接，在其他场景也可以干扰公共网络终端与热点的连接，造成网络瘫痪。此时WIPS系统能够发现此类攻击，在提供处理建议的同时，还能定位攻击发生的具体位置，管理员可实地排查是否有可疑人员。

5. 可以说黑客的攻击行踪已经完全暴露在WIPS之下，原本看不见摸不着的无线威胁，透过WIPS的映射逐渐变得清晰。还不知道发生了什么的黑客继续他的攻击，黑客通过收集和重放重新发送四次握手中的Message3强制重置nonce，从而成功攻击加密协议，解密客户端发送通信数据包，截获敏感信息。但是此时WIPS系统已经监测到该攻击，并对实施钓鱼的热点进行了阻断，使不知情的“用户”免于威胁。

5.小结

最终“红方”利用WIPS的监测与阻断服务，成功阻止了“黑方”利用无线网络入侵与监听数据的攻击行为。通过实验表明，WIPS的确可以有效防范KRACKs攻击。随着移动互联网、BYOD、智慧城市、物联网等无线网络应用的兴起，无线网络正在扮演着越来越重要的角色。而无线网络重应用轻防护的建设理念，将吸引越来越多的黑客征服这片未被保护的领域，KRACKs不是无线网攻击的结束，是无线安全认知与建设的开始。

安全团队

天巡实验室

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

简介

ISC 2017中国互联网安全大会举办了人工智能安全论坛。 我们把论坛总结成为一系列文章，本文为系列中的第二篇。

传送门：

【技术分享】深度学习框架中的魔鬼——探究人工智能系统中的安全问题

“逃逸攻击就是要把百分之零点零零一的误判率变成百分之百的攻击成功率”。

虽然深度学习系统经过训练可以对正常输入达到很低的误判率，但是当攻击者用系统化的方法能够生成误判样本的时候，攻击的效率就可以接近100%，从而实现稳定的逃逸攻击。

1. 逃逸攻击简介

图1: 攻击者生成对抗样本使系统与人类有不同的判断

图2: 在图片中添加扰动导致深度学习系统的错误识别实例

下面我们从攻击者的角度介绍如何系统生成对抗样本来达到稳定的逃逸攻击。不关心技术细节的读者可忽略这些内容，直接跳到文章结尾的总结部分。

2. 基于机器学习的对抗样本生成

基于机器学习的逃逸攻击可分为白盒攻击和黑盒攻击。白盒攻击需要获取机器学习模型内部的所有信息，然后直接计算得到对抗样本；黑盒攻击则只需要知道模型的输入和输出，通过观察模型输出的变化来生成对抗样本。

2.1 白盒攻击

白盒攻击的约束条件是一个关键部分。从X起始求解X’使得F(X’)=Y’的过程中，我们必须保证X’的标签不是Y’。例如，对于一个手写体输入“1”，如果我们把它改成“2”使得模型判别是“2”，那就不算是攻击。在计算机视觉领域，我们不太可能使用人力判定攻击方法生成的每一个样本X’，因此引入了距离函数Δ(X, X’)。我们假设在一定的距离内，X’的 含义和标签与X是一致的。距离函数可以选择不同的Norm来表示，比如L2, L∞, 和L0 。

2.2 黑盒攻击

黑盒攻击只依赖于机器学习模型的输出，而不需要了解模型内部的构造和状态。遗传（进化）算法即是一个有效的黑盒攻击方法。

遗传算法是在计算机上模仿达尔文生物进化论的一种最优化求解方法。它主要分为两个过程：首先通过基因突变或杂交得到新一代的变种，然后以优胜劣汰的方式选择优势变种。这个过程可以周而复始，一代一代地演化，最终得到我们需要的样本。

把遗传算法用于黑盒逃逸攻击时，我们利用模型的输出给每一个变种打分，F(X’)越接近目标标签Y’则得分越高，把高分变种留下来继续演化，最终可以得到F(X’)=Y’。这种方法已经成功用于欺骗基于机器学习的计算机视觉模型以及恶意软件检测器。

3.基于遗传算法的对抗样本生成

3.1 对Gmail PDF过滤的逃逸攻击

图3: 利用进化算法生成恶意PDF对抗变种

同样的算法可以用来对实际应用的机器学习系统进行逃逸攻击。上面提到的工作可以对 Gmail内嵌的恶意软件分类器进行攻击， 并且只需4行代码修改已知恶意PDF样本就可以达到近50%的逃逸率，10亿Gmail用户都受到影响。

3.2 利用Fuzzing测试的对抗样本生成

除了对模型和算法的弱点进行分析，黑盒攻击还可以借鉴模糊测试的方法来实现对抗样本的生成。下面以手写数字图像识别为例，我们的目标是产生对抗图片，使其看起来是“1”，而人工智能系统却识别为“2”。我们的主要思路是将这样一个对抗样本生成的问题，转换为一个漏洞挖掘的问题，如下图4所示。

图4：针对手写数字图像识别的对抗样本生成

我们主要是利用灰盒fuzzing测试的方法来实现，首先给定数字“1”的图片作为种子，然后通过对种子图片进行变异，如果机器学习系统将变异后的图片识别为“2”，那么我们认为这样一个图片就是对抗样本。

利用Fuzzing测试的对抗样本生成是基于AFL来实现的，主要做了以下几方面的改进：

1.是漏洞注入，我们在机器学习系统中添加一个判断，当图片被识别为2时，则人为产生一个crash；

2.是在数据变异的过程中，我们考虑文件格式的内容，优先对一些图像内容相关的数据进行变异；

3.是在AFL已有的路径导向的基础上，增加一些关键数据的导向。

下图5是我们生成的一些对抗样本的例子。

图5：针对手写数字图像的对抗样本生成结果

基于Fuzzing测试的对抗样本生成方法也可以快速的应用到其他AI应用系统中，如人脸识别系统。

图6：针对人脸识别系统的对抗样本生成

4. 基于软件漏洞进行逃逸攻击

针对AI系统的对抗性攻击，就是让人工智能系统输出错误的结果。 还是以手写图像识别为例，攻击者可以构造恶意的图片，使得人工智能系统在分类识别图片的过程中触发相应的安全漏洞， 改变程序正常执行的控制流或数据流，使得人工智能系统输出攻击者指定的结果。 攻击思路基本分为两种：

1. 基于数据流篡改可以利用任意写内存漏洞，直接将AI系统中的一些关键数据进行修改(如标签、索引等)， 使得AI系统输出错误的结果。

2. 另一种则是通过常规的控制流劫持(如堆溢出、栈溢出等漏洞)来完成对抗攻击，由于控制流劫持漏洞可以通过漏洞实现任意代码的执行，因此必然可以控制AI系统输出攻击者预期的结果。

关于软件漏洞造成的问题我们在本系列第一篇文章里已有详细介绍。 这里只做了一个简单介绍, 更多细节请参考ISC 2017大会人工智能与安全论坛所发布的内容。

5. 小结

本文的目的是继续介绍被大众所忽视的人工智能安全问题。虽然深度学习在处理自然生成的语音图像等以达到相当高的准确率，但是对恶意构造的输入仍然有巨大的提升空间。虽然深度学习系统经过训练可以对正常输入达到很低的误判率，但是当攻击者用系统化的方法能够生成误判样本的时候，攻击的效率就可以接近100%， 从而实现稳定的逃逸攻击。 随着人工智能应用的普及，相信对逃逸攻击的研究也会越来越深入。这些研究包括对抗样本生成以及增强深度学习对抗能力，我们未来会在后续文章里对这方面的工作进行更新。

6. 参考文献

译者：興趣使然的小胃

预估稿费：200RMB

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

一、前言

PowerShell的身影无所不在，我最近也遇到过越来越多的恶意PowerShell脚本。为什么攻击者热衷于使用PowserShell？因为许多windows版本中都会自带这个工具，并且该工具可以访问WMI以及.Net Framework的全部功能，也能在内存中执行恶意代码以逃避反病毒软件的查杀，对了，与PowerShell相关的日志记录也没有那么完备。

在对这类案例的分析过程中，我发现了多条线索可以证明某位攻击者已经利用PowerShell实施过攻击。这些线索包括已安装的服务、注册表条目以及磁盘上的PowerShell文件。如果启用了日志记录功能，我也能找到许多有用的信息。本文的目的是为那些对PowerShell不是特别熟悉的安全分析人员提供一份参考。在本文中，我会向大家介绍如何定位恶意PowerShell程序的一些经验，同时也会介绍解码经过混淆的PowerShell脚本的一些方法。这一系列文章共有三篇，本文是第一篇，未来几周我会陆续推出后续文章。

二、Part 1：以服务形式安装的PowerShell脚本

首先我想介绍我最喜欢的一个例子：如何通过System事件日志发现攻击者将PowerShell脚本安装成本机服务。为了定位这类程序，我所做的第一件事情就是查找ID为7045的那些事件（Event ID 7045）。当系统中安装某个服务时，日志中就会出现这类事件。以服务形式安装的某个PowerShell脚本如下所示：

上图中我用红框标出了一些值得注意的信息：

1、服务名（Service Name）为随机的字符串。

2、服务文件名（Service File Name）为%COMSPEC%，这个字符串为cmd.exe所对应的环境变量。

3、引用了powershell可执行文件。

4、包含经过Base64编码的数据。

那么，这类事件为什么会出现在日志中？有多种方法可以做到这一点，其中一种方法就是使用内置的Windows服务控制管理器（Service Control Manager）来创建服务，命令如下所示：

上述命令会创建名为“MyService”的一个服务，“binPath=”选项用来启动cmd.exe，后者会执行PowerShell代码。

有个有趣的信息需要引起我们的注意：以这种方式创建服务后，我们可能会得到一些错误信息。然而，这些错误信息并不意味着服务安装失败，原因在于Windows希望安装“真实”的二进制程序，因此在等待这个“服务”时会出现“超时”，最终呈现错误信息。我也是经过测试才知道这一点。在测试过程中，我使用该方法成功安装了一个反弹shell，操作过程中Windows主机上会产生服务错误信息。如下图中，左图为我在攻击虚拟机上启动的一个Metasploit会话，右图为安装了Windows 7系统的虚拟机。虽然Windows 7主机会提示“服务没有及时响应启动或控制请求（The service did not respond to the start or control request in a timely fashion）”，但并不影响Metasploit会话中成功打开反弹shell：

如下两图分别对应System事件日志中的7000以及7009事件。虽然7009事件提示说“FakeDriver服务启动失败（The FakeDriver service failed to start）”，但这并不代表binPath变量中包含的命令执行失败。所以，如果根据这些信息判断PowerShell没有执行，我们可能会得到错误结论：

我们可以使用python来解码System日志中7045事件所包含的经过base64编码的PowerShell命令。有趣的一点是，这是一段Unicode编码的base64代码，因此在解压时我们需要指定额外的参数。（为了便于展示，我没有全部呈现所有base64文本，你需要在解码程序中包含所有的base64文本）：

解码后的PowerShell命令如下所示。快速查看代码后，我们可以找到一些有趣的线索，比如，我们可以在其中找到与Net Socket有关的TCP协议以及IP地址信息：

这段代码在功能上与使用Meterpreter用来创建反弹shell类似。上述PowerShell代码解码起来非常容易，然而，许多场景下，我们面临的情况并没有那么简单。

接下来是另一个例子，这一次我们面对的是“普通”的base64代码。其中我们需要再次注意%COMSPEC%变量以及其中包含的powershell.exe字符串：

我们还是使用Python来解码这段base64编码的PowerShell代码：

这一次，解码后的结果没有那么直观。如果我们回过头好好观察一下System中的事件记录，我们可以发现其中包含有关“Gzip”以及“Decompress”相关信息：

根据这些信息，我们可以逆向思考，这段数据可能先经过Gzip的压缩，然后再使用base64进行编码。因此，我决定使用python将base64的解码结果写入到文件中，以便进一步解压缩处理：

通过7zip，我成功解压了这个gzip文件！操作过程中没有出现任何错误信息，因此我使用的可能是正确的方法：

然后，我通过文本编辑器打开解压后的文件，希望能看到一些PowerShell代码：

什么情况？好吧，是时候祭出十六进制编辑器了：

依然没有太大帮助。我猜测这应该是一段shellcode代码。下一步，我想通过PDF Stream Dumper的shellcode分析工具，即scdbg.exe来分析这段数据：

正中靶心！scdbg.exe可以从shellcode中提取出某些IOC特征。

总结一下，为了解码这段PowerShell代码，我用到了如下方法：

1、解码base64编码的PowerShell字符串。

2、将解码后的base64内容写入zip文件。

3、使用7zip解压Gzip文件。

4、通过scdbg.exe分析所得的二进制输出结果。

如上所述，在取得最终成果前，我们需要通过若干个挑战关卡。

最后一个例子：

这个画面看起来似曾相识。第一步，我们需要解码这段Unicode形式的base64字符串，结果如下所示，我们可以看到base64代码中竟然还包括其他base64代码！：

显然，代码先经过混淆，然后使用压缩方法再次进行混淆。这种情况之前我经常见到。这一次压缩文本中没有显示包含“gzip”字符串，因此我决定将第二轮base64结果保存到常规zip文件中，然后使用7zip再次打开这个文件：

使用7zip打开这个文件时，我看到了如下错误：

使用Windows自带的工具打开时也会提示错误信息：

我也试过使用各种python库来解压这个压缩文件。经过一番调研后，我发现这种压缩方式与某些.Net库有关。由于我自己非常喜欢Python，我想知道如何使用Python来解压这个文件，这样我就能将解压代码写到自己的脚本中。Python是门跨平台语言，在linux、Windows以及Mac都可以使用，而.Net由于核心机制原因无法做到这一点。因此，我选择使用Iron Python来解决这个问题（当然，你可以使用PowerShell来解压这段数据，然而我前面说过，我还是想用Python来完成这个任务）。

根据Iron Python官网的说法，“IronPython是Python编程语言的开源实现方案，与.NET Framework密切相关。IronPython可以使用.NET Framework和Python库，并且其他.NET代码想要使用Python代码也非常简单”。在Windows上安装IronPython非常简单，只需要一个MSI文件即可。安装完毕后，你就可以使用ipy.exe来运行脚本（稍后我会给出具体例子）。

有了这个工具后，我就可以开发python代码（io_decompress.py），使用python IO压缩库来解压zip文件：

通过IronPython来运行这段脚本也非常简单，命令为ipy.exe io_decompress.py，如下所示：

这段脚本生成了decompressed.txt文件，其中包含明文版的PowerShell脚本，如下图所示。我们需要注意其中包含的IP地址信息：

总结一下，为了从事件日志中得到正确结果，我经过了如下步骤：

1、解码Unicode base64代码。

2、解码嵌套的base64代码。

3、解压解码后的base64代码。

三、总结

从上面这三个例子中，我们可以看到，攻击者可能会使用各种技术来混淆他们的PowerShell攻击代码。这些技术可以组合使用，其中一些用法我已经在上面例子中介绍过。对于每种情况，所采取的步骤往往也各不相同。我经常会看到每种案例会对应2到3种变化，并且会在几个月的时间内蔓延到数百个系统中。某些情况下，我们所需要使用的步骤可能为：base64、base64、解压、shellcode，也有可能是base64、解压、base64、明文代码、base64、shellcode。这种情况是不是与俄罗斯套娃非常类似？在完成这一系列文章后，我会介绍如何自动化处理这个过程。如果你使用过类似Harlan Carvy的时间线脚本来获取文本输出结果，那么整个过程处理起来会非常简单。

因此，我们如何在自己的环境中定位并解码这些脚本？可以使用如下步骤：

1、查找带有%COMSPEC%、powershell.exe、-encodedcommand、-w hidden、"From Base64String"之类特征的7045事件。

3、尝试使用sdbg.exe、shellcode2exe或其他恶意软件分析工具来分析得到的二进制文件。

在Part 2中，我会介绍注册表中的PowerShell代码，在Part 3中，我会介绍如何记录PowerShell日志，以及如何从内存中提取相关信息。

热点概要：bug bounty：看我如何接管OLX的每一条广告、krackattacks-test-ap-ft：判断AP是否受到CVE-2017-13082漏洞（WPA2 KRACK Attacks）的影响、WaterMiner：一款新发现的挖矿恶意软件分析、2017 Flare-On挑战题解（Fireeye的CTF）、FaceID真的安全么？针对FaceID的安全性研究

国内热词（以下内容部分来自：http://www.solidot.org/）

英情报机构被指控搜集公民社交媒体及医疗数据

微软的 bug 数据库在 2013 年曾遭到入侵

联想修复影响安卓平板和手机的多个漏洞

https://threatpost.com/lenovo-quietly-patches-massive-bug-impacting-its-android-tablets-and-zuk-vibe-phones/128489/

bug bounty：看我如何接管OLX的每一条广告

https://kciredor.com/taking-over-every-ad-on-olx-automated-an-idor-story.html

浏览器安全之逃逸沙盒

https://blogs.technet.microsoft.com/mmpc/2017/10/18/browser-security-beyond-sandboxing/

Hack.lu 2017安全会议演讲视频

https://www.youtube.com/playlist?list=PLCxOaebc_2yNlOGhuOjInlJvr0Ktb_FYz

krackattacks-test-ap-ft：判断AP是否受到CVE-2017-13082漏洞（WPA2 KRACK Attacks）的影响

https://github.com/vanhoefm/krackattacks-test-ap-ft

WaterMiner：一款新发现的挖矿恶意软件分析

https://minerva-labs.com/post/waterminer-a-new-evasive-crypto-miner

HydraPOS：巴西诈骗者已经利用该设备收集了至少140万张信用卡资料

https://sidechannel.tempestsi.com/hydrapos-operation-of-brazilian-fraudsters-has-accumulated-at-least-1-4-million-card-data-b05d88ad3be0

BoundHook：基于异常，内核控制的用户模式hook

https://www.cyberark.com/threat-research-blog/boundhook-exception-based-kernel-controlled-usermode-hooking/

针对Nitro OBD2的逆向工程

https://blog.quarkslab.com/reverse-engineering-of-the-nitro-obd2.html

在GPD Pocket 7上安装linux

https://medium.com/@tomac/qpd-pocket-7-the-return-of-the-hacker-netbook-fe9be1b02ebf

2017 Flare-On挑战题解（Fireeye的CTF）

https://www.fireeye.com/blog/threat-research/2017/10/2017-flare-on-challenge-solutions.html

Cloakify：Data Exfiltration工具（用于将任何文件类型转换为日常字符串列表、绕过DLP/MLS设备、绕过白名单、AV检测等）

https://github.com/TryCatchHCF/Cloakify

FaceID真的安全么？针对FaceID的安全性研究

https://auth0.com/blog/is-faceid-really-secure/

Kerberos AD Attacks - Kerberoasting

https://blog.xpnsec.com/kerberos-attacks-part-1/

Significant security flaws in smartwatches for children

https://www.forbrukerradet.no/side/significant-security-flaws-in-smartwatches-for-children

译者：blueSky

预估稿费：200RMB

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

简介

WMI（windows Management Instrumentation）自Windows 2000以来一直是Windows操作系统中的一个功能，该功能对系统管理员来说是非常重要的，它能够获取计算机内部状态的信息，能够对磁盘、进程、和其他 Windows 系统对象进行建模，从而实现“指示”功能。正是由于WMI的这种灵活性，在它早期被引入Windows操作系统时，网络攻击者经常利用WMI来对计算机实施攻击。WMI是微软Windows操作系统中的一个非常重要的技术，但从安全的角度考虑，目前还没有一种行之有效的方法去记录某用户操作WMI功能的行为活动。对于“防守者”而言，他们通常利用第三方工具或自己编写的解决方案来去记录操作WMI的行为活动，但这在一定程度上并不能够阻止“攻击者”操作WMI来执行各种网络攻击的行为。在本文中，我们将看看微软是如何改进记录WMI操作行为功能的。

WMI Activity Provider

在2012年之前，Windows系统中的WMI Activity事件日志程序主要用于在WMI启用时记录其跟踪和调试信息，但在Windows新发行版本中扩展了该程序的功能，使用Operational选项可以对WMI的操作行为进行记录。下面我们将使用PowerShell对该新功能进行分析，并使用Get-WinEvent cmdlet来获取信息。

我们首先获得Provider程序的对象：

下面让我们看看LogLinks或者Provider程序将事件日志保存在哪里。

上述Powershell的输出中，我们比较感兴趣的是Microsoft-Windows-WMI-Activity/Operational。现在我们已经确定了哪个EventLog会保存我们感兴趣事件的日志，下面我们可以看看Provider程序生成的事件日志。通常情况下，Provider可以从几个事件中生成超过100个事件日志。因此，我们使用Measure-Object cmdlet来查看Provider生成的事件数量。

通过上述输出我们看到Provider生成了22个事件，下面我们使用Get-Member cmdlet来看看如何组合每个对象。

通过上面的输出我们发现每个事件都有一个LogLink属性，且属性值为System.Diagnostics.Eventing.Reader.EventLogLink ，下面我们来看看这些对象的值是如何形成的。

执行下面这个命令可以筛选出我们想要查看的事件。

此时，我们可以看到与事件日志相关联的特定事件，而且我们还可以获取到每个事件的细节信息，其中包括消息的XML模板，该信息在我们编写XPath过滤器时是十分有用的。我们可以将它们保存到一个变量中，并从中获取事件的ID，具体操作如下所示：

Provider加载过程

每当WMI被初始化时，它将加载用于构建类的Provider程序，并向外界提供用来访问操作系统和系统组件的功能。这些功能都是在当前用户的SYSTEM上下文环境中执行的，也就是说，它们在Windows中将以非常高的特权执行。 因此，攻击者们通常会把恶意的Provider程序用作后门，以便能够持续的、高权限的对Windows操作系统进行访问。下面是一些恶意的Provider程序示例：

https://gist.github.com/subTee/c6bd1401504f9d4d52a0 SubTee Shellcode Execution WMI Class

https://github.com/jaredcatkinson/EvilNetConnectionWMIProvider Jared Atkinson Evil WMI Provider Example

在事件ID列表中，我们注意到一个ID为5857的事件，该事件的结构中有一些非常有价值的信息，具体详情如下所示：

从上图结构信息中我们可以发现加载Provider程序的ProcessID和Thread信息，而且我们还可以看到主机进程的名称以及加载的DLL路径。如果我们使用Windows事件收集器，我们可以根据已知Provider创建一个XML过滤器，使用该过滤器可以对上述的输出结果执行过滤操作以获取未知的Provider程序，下面我们使用PowerShell生成一个简单的privider文件列表，具体输出如下所示：

WMI查询错误

Id为5858的EventLog记录了WMI中所有的查询错误信息，这些信息包括错误代码（ResultCode标签）和引起错误的原因（Operation标签），还包括进程Pid，该字段信息位于ClientProcessId标签中，具体信息如下图所示：

从上图可以看出错误代码是十六进制格式的，不过微软在MSDN中列出了WMI所有的错误常量，我们可以用它来确定具体的错误信息。 我们可以使用XPathFilter轻松查询特定的结果代码。在以下这个示例中，我们通过搜索ResultCode 0x80041010来查找失败的查询请求 ，该操作可以用来确定攻击者是否正在寻找系统上存在的特定类，具体如下所示：

我们还可以搜索由于权限不足而失败的查询，具体搜索如下所示：

WMI事件

WMI事件定义是当创建特定事件类实例或直接在WMI模型定义的一类事件，可以通过监视Windows中CIM数据库生成的特定事件来完成事件的操作。 大多数事件会创建一个查询请求，该请求中定义了我们需要执行的操作，一旦事件发生就会执行我们定义的操作，目前WMI支持两种类型的事件：

临时事件：只要创建事件的进程处于活动状态，临时事件就会被激活。 （他们在进程的特权下运行）

持久事件：事件存储在CIM数据库中，并且会一直处于活动状态，直到从数据库中将它移除。 （它们总是作为SYSTEM运行）

临时事件

由于某些工具在实现上往往使用临时事件，因此一些人认为持久性WMI事件更容易被检测，这些工具通常情况下使用C ++，.Net，WSH或者PowerShell编写，它们允许使用WMI事件过滤器来触发应该由应用程序自己执行的操作。 我们可以使用Id 为5860的事件来跟踪这些操作。一旦应用程序注册事件消费者，事件日志就会被创建。

下面是一个临时事件消费者的一个示例，在示例中它简单地写入已经启动的进程名称。

当事件消费者注册到Register-WmiEvent时，我们会在系统上记录下列事件。

我们可以看到用于监视事件的查询请求被记录在UserData下的Query元素中，而在PlaussibleCause元素中，我们看到它被标记为Temporary。

持久事件

当在WMI CIM数据库中创建一个持久事件时，系统同时还会创建Id为5861的事件日志条目，该事件也会在任何组件类实例被修改时被创建，该事件将包含所有与持久性相关的信息，如下图中的“PossibleCause ”子元素所示：

当修改构成持久事件的__EventFilter或Consumer时，系统会生成相同的一个事件，但数据中并没有字段用来显示此事件是否被修改。也可以通过Id 为5859的事件来查看构成持久事件的__EventFilter类，但是在我所有测试中，我还没有看到使用此Id创建的事件。

结论

正如我们本文中所阐述的，在最新版本的Windows中，通过加入一些日志功能，微软已经改进了WMI的一些安全性。但是，这些功能还没有被加入到Windows 7和Windows 2008/2008 R2操作系统中去。 因此，针对这些系统，我们需要去能够跟踪以下信息：

错误的查询请求；

临时事件的创建；

持久事件的创建与修改；

Provider的加载。

从“攻击者”的视角来看，这让我们知道我们的行为可以被跟踪，当我们在实施某些恶意的行为操作时，我们应该看看这些事件是否会被收集。从“防守者”的角度来看，我们应该在系统环境中收集和分析上述这些事件的信息以用于分析哪些是可能的恶意行为事件。