【渗透测试】渗透测试最强秘籍（Part 2：配置和部署）

Strict Transport Securityhttps://isc.sans.edu/diary/Wordpress+%22Pingback%22+DDoS+Attacks/17801

https://hackerone.com/reports/96294

https://github.com/1N3/Wordpress-XMLRPC-Brute-Force-Exploit/blob/master/wordpress- xmlrpc-brute-v2.py

https://testpurposes.net/2016/11/01/wordpress-xmlrpc-brute-force-attacks-via-burpsuite/

对源代码审计的注释

这是非常普遍的, 甚至是建议的行为。

配置审计

应考虑到一些共同准则:

• 只启用应用程序所需的服务器模块
• 使用自定义页面处理服务器错误代码
• 确保服务器软件以最小化的权限运行在操作系统中

• 确保服务器软件正确记录合法访问和错误
• 确保服务器配置为正确处理过载和DoS攻击

日志

日志记录是应用程序体系架构安全性的重要资产, 因为它可以用来检测应用程序中的缺陷, 日志通常是由 web 和服务器软件生成的。

日志中的敏感信息

某些应用程序可能会使用GET来转发表单数据, 在服务器日志中可以查看。这意味着服务器日志可能包含敏感信息 (如用户名密码或银行帐户详细信息)。如果攻击者获得日志, 例如通过管理接口或已知的 web 服务器漏洞或配置错误 (如基于 Apache 的 HTTP 服务器的状态错误配置), 攻击者可能会利用此敏感信息。。

日志位置

尝试将日志保存在另外的位置, 而不是在 web 服务器中。这也使得聚合来自不同源的日志 (如 web 服务器场的应用程序) 更容易, 而且它也使得在不影响服务器本身的情况下进行日志分析 (可以是 CPU 密集型) 更容易。

日志存储

在 UNIX 系统中, 日志将位于/var (虽然某些服务器安装可能驻留在 /opt 或 /usr/local）, 因此确保包含日志的目录位于单独的分区中是非常重要的。在某些情况下, 为了防止系统日志受到影响, 服务器软件本身的日志目录 (如 apache web 服务器中的 var/log/apache) 应该存储在专用分区中。

日志分割

大多数服务器 (但很少有自定义应用程序) 会分割日志以防止它们填满其驻留的文件系统。

应测试此功能, 以确保:

• 日志保存遵循安全策略中定义的时间, 不多也不少
• 日志分割时压缩 (这将意味着更多的日志将被存储在相同的可用磁盘空间中)
• 分割后的文件系统权限和日志文件本身是相同的。例如, web 服务器需要写入它们所使用的日志, 但实际上并不需要写入分割的日志, 这意味着可以在分割时更改文件的权限, 以防止 web 服务器进程修改它们。

某些服务器在达到给定大小时可能会分割日志。如果发生这种情况, 必须确保攻击者无法强制日志分割以隐藏其踪迹。

日志内容

• 日志中是否包含敏感信息？
• 日志是否存储在专用服务器？
• 日志的使用是否为DoS提供条件？
• 如何保存日志备份？
• 如何查看日志？管理员可以使用这些检查来检测目标攻击吗？
• 他们是怎么分割的？日志是否保留了足够的时间？

3. 测试文件扩展处理敏感信息

文件扩展通常在 web 服务器中使用, 以方便地确定哪些技术/语言/插件满足 web 请求。

黑盒测试

提交涉及不同文件扩展名的 http 请求, 并验证它们是如何处理的。这些验证应在每个 web 目录基础上进行。
web 服务器永远不应返回以下文件扩展名, 因为它们与可能包含敏感信息的文件相关, 也不应用于没有理由提供服务的文件。

• .asa
• .inc

使用谷歌黑客技术, 容易找到他们, 例如

• ext: asa inurl:www.maybole.org

下面的文件扩展名与文件有关, 在访问时, 浏览器将显示或下载此文档。因此, 必须检查具有这些扩展名的文件, 以验证它们是否确实应该被送达 (而不是剩饭), 并且它们不包含敏感信息。

• .zip, .tar, .gz, .tgz, .rar, …: (Compressed) archive files
• .java: No reason to provide access to Java source files
• .txt: Text files
• .pdf: PDF documents
• .doc, .rtf, .xls, .ppt, …: Office documents
•  .bak, .old and other extensions indicative of backup files (for example: ~ for Emacs backup files)

有关更多信息, 请访问此链接: http://filext.com/

我们可以用下面的技术来解决这个问题:

• 漏洞扫描程序
• 蜘蛛工具
• 镜像工具

灰盒测试

对文件扩展名处理执行白盒测试, 以检查 web 服务器/应用服务器中参与 web 应用程序体系结构的配置, 并验证它们如何为不同的文件提供服务扩展。如果 web 应用程序依赖于负载平衡的异构基础结构, 则确定这是否会引入不同的行为。

4. 审计旧的、备份的和未引用的文件以发现敏感信息

虽然 web 服务器中的大多数文件都是由服务器本身直接处理的, 但发现未引用和/或被遗忘的文件并不少见, 它们可用于获取有关基础架构或登录凭据的重要信息。常见的情形包括：重命名的修改后的文件的旧版本、可以作为源下载的加载到选则语言中的包含文件, 以压缩存档形式进行的自动或手动备份。所有这些文件都可以授予渗透测试人员对内部工作、后门、管理接口甚至凭据的访问权限, 以连接到管理接口或数据库服务器。

黑盒测试

使用自动化和手动技术对未引用文件进行测试:

• 枚举应用程序的所有页面和功能: 这可以使用浏览器手动完成, 或者使用应用程序爬虫工具。大多数应用程序使用识别命名方案, 并使用描述其功能的单词将资源组织到页面和目录中。从用于发布内容的命名方案中, 通常可以推断未引用页的名称和位置。例如, 如果找到了一页 viewuser. asp, 那么也可以查看 edituser、adduser asp 和 deleteuser. asp。如果找到了目录/app/user, 那么也可以查看/app/admin and /app/manage 。
• 发布内容中的其他线索: 许多 web 应用程序在发布的内容中留下线索, 这会导致发现隐藏的页面和功能。这些线索经常出现在 HTML 和 JavaScript 文件的源代码中。应手动检查所有已发布内容的源代码, 以确定有关其他页和功能的线索。

关于未引用目录的另一个线索来源是用于向 web 机器人提供指令的/robots.txt 文件。

• 通过服务器漏洞和错误的配置获得的信息
• 公开可用的信息: 谷歌黑客, shodan. io

5. 枚举基础结构和应用程序管理接口

黑盒和灰盒测试

下面介绍可用于测试管理接口是否存在的向量。这些技术还可用于测试相关问题, 包括权限升级。

• 目录和文件枚举-管理接口可能存在, 但并不对测试人员可见。试图猜测管理接口的路径可以做如下简单请求:/admin or /administrator 等。测试人员可能还必须标识管理页的文件名。强行浏览到标识的页面可以提供对接口的访问。
• 注释和源中的链接-许多站点使用为所有站点用户加载的通用代码。通过检查发送到客户端的所有源, 可能会发现指向管理员功能的链接, 并应进行调查。
• 查看服务器和应用程序文档-如果应用程序服务器或应用程序部署在其默认配置中, 则可以使用配置或帮助文档中描述的信息访问管理界面。如果找到了管理界面并且需要凭据, 则应咨询默认密码列表。
• 替代服务器端口-可以在主机上的不同端口上看到替代服务器端口管理接口, 而不是主应用程序。例如, 在端口8080上通常可以看到 Apache Tomcat 的管理界面。
• 参数篡改-启用管理员功能可能需要Get或 POST 参数或 cookie 变量。

6. 测试 HTTP 方法

HTTP 提供了许多可用于在 web 服务器上执行操作的方法。许多论文的方法旨在帮助开发人员部署和测试 HTTP 应用程序。

虽然 “GET” 和 “POST” 是用于访问 web 服务器提供的信息的最常用方法, 但超文本传输协议 (HTTP) 允许使用其他几种方法 (以及一些不太熟悉的方法):

• HEAD
• GET
• POST
• PUT
• DELETE
• TRACE
• OPTIONS
• CONNECT

其中一些方法可能会对 web 应用程序造成安全风险, 因为它们允许攻击者修改存储在 web 服务器上的文件, 在某些情况下窃取合法用户的凭据。更具体地说, 应禁用的方法如下:

• PUT: 此方法允许客户端在 web 服务器上上载新文件。攻击者可以通过上传恶意文件来利用它 (例如: 通过调用 cmd.exe 执行命令的 asp 文件), 或者简单地使用受害者服务器作为文件存储库
• DELETE: 此方法允许客户端删除 web 服务器上的文件。攻击者可以利用它作为一种非常简单直接的方法来破坏网站或安装 DoS 攻击。
• CONNECT: 此方法允许客户端使用 web 服务器作为代理
• TRACE: 此方法只是回显客户端任何字符串已发送到服务器, 主要用于调试目的。

黑盒测试

发现支持的方法

测试 XST 潜能

查找您想访问的网页, 该页面具有安全约束, 因此它通常会强制将302重定向到登录页或直接强制登录。此示例中的测试 URL 与许多 web 应用程序一样工作。但是, 如果您获得的不是登录页的 “200” 响应, 则可以绕过身份验证, 从而进行授权。

www.example.com 80 JEFF / HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK

Date: Mon, 18 Aug 2008 22:38:40 GMT

Server: Apache

Set-Cookie: PHPSESSID=K53QW…

如果您的框架或防火墙或应用程序不支持 “JEFF” 方法, 它应该产生错误页 (或者最好是405 Not Allowed 或501 Not implemented error page )。如果它相应了该请求, 它就受到了威胁。

如果您认为系统易受此问题威胁, 请发出类似于 CSRF 的攻击, 以便更充分地利用此威胁:

• FOOBAR /admin/createUser.php?member=myAdmin
• JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
• CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add
• HEAD /admin/createUser.php?member=myAdmin

幸运的是, 使用上面的三个命令-修改以适应测试和测试要求下的应用程序-将创建一个新用户, 分配一个密码, 并成为管理员。

7. 测试 HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) 标头是一种机制, web 站点必须与 web 浏览器通信, 所有与给定域交换的通信必须始终通过 https 发送。

考虑到此安全措施的重要性, 验证网站是否使用此 HTTP 标头非常重要, 以确保所有数据都从 web 浏览器加密到服务器。

HTTP Strict Transport Security (HSTS) 功能允许 web 应用程序通过使用特殊的响应报头通知浏览器它不应该使用 HTTP 建立到指定域服务器的连接。相反, 它应该自动建立所有连接请求, 通过 HTTPS 访问站点。

HSTS标头使用两个指令:

• max-age : 指示浏览器应自动将所有 HTTP 请求转换为 HTTPS 的秒数。
•  includeSubDomains: 指示所有 web 应用程序的子域都必须使用 HTTPS。下面是 HSTS 头实现的一个示例:

Strict-Transport-Security: max-age=60000; includeSubDomains

必须检查 web 应用程序使用此标头, 以查找是否可能导致以下安全问题:

• 攻击者嗅探网络流量并访问通过未加密通道传输的信息
• 因为接受不受信任的证书二导致攻击者利用中间人攻击
• 用户在浏览器中错误地输入了 http 中的地址而不是 HTTPS, 或者在 web 应用程序中单击某个错误的http链接。

如何测试

• 我写了一个工具, 可以分析报头
• Burpsuite回应

8. 测试 RIA 跨域策略

RIA 是基于 web 的服务, 它执行与桌面应用程序系统相同的功能。

跨域策略文件指定 web 客户端 (如 Java、Adobe Flash、adobe Reader等) 用于跨不同域访问数据的权限。对于 Silverlight, Microsoft 采用了 Adobe 的 crossdomain.xml 的一个子集, 另外还创建了它自己的跨域策略文件: clientaccesspolicy. xml。

每当 web 客户端检测到必须从其他域请求资源时, 它将首先在目标域中查找策略文件, 以确定是否允许执行跨域请求 (包括标头和基于套接字的连接)。

主策略文件位于域的根目录中。可能会指示客户端加载其他策略文件, 但它始终首先检查主策略文件, 以确保主策略文件允许请求的策略文件。

如何测试

我们应该尝试从应用程序的根目录和每个找到的文件夹中检索策略文件 crossdomain.xml 和 clientaccesspolicy.xml。

检索所有策略文件后, 应根据最小特权原则检查允许的权限。请求只应来自需要的域、端口或协议。应该避免过于宽松的政策。应密切审查在这些政策中采用 “*”。