枚举 Web 服务器上的应用程序

概括

测试 Web 应用程序漏洞的最重要步骤是找出 Web 服务器上托管了哪些特定应用程序。许多应用程序都有已知的漏洞和已知的攻击策略，可以利用这些漏洞和攻击策略来获得远程控制或利用数据。此外，许多应用程序经常配置错误或未更新，因为人们认为它们仅在“内​​部”使用，因此不存在威胁​​。随着虚拟 Web 服务器的激增，IP 地址和 Web 服务器之间传统的 1:1 关系正在失去其原有的大部分意义。多个网站或应用程序的符号名称解析为同一 IP 地址的情况并不少见。这种场景不仅限于托管环境，也适用于普通的企业环境。

安全专业人员有时会获得一组 IP 地址作为测试目标。有争议的是，此场景更类似于渗透测试类型的参与，但无论如何，预计此类任务将测试可通过此目标访问的所有 Web 应用程序。问题是给定的 IP 地址在端口 80 上托管 HTTP 服务，但是如果测试人员应该通过指定 IP 地址（这是他们所知道的）访问它，它会报告“此地址未配置 Web 服务器”或类似消息. 但是该系统可以“隐藏”许多与不相关的符号 (DNS) 名称关联的 Web 应用程序。显然，分析的范围深受测试人员测试所有应用程序或只测试他们知道的应用程序的影响。

有时，目标规范更丰富。测试人员可能会得到一个 IP 地址列表及其相应的符号名称。然而，这个列表可能传达了部分信息，即它可能省略了一些符号名称，而客户甚至可能没有意识到这一点（这在大型组织中更有可能发生）。

影响评估范围的其他问题由在非明显 URL（例如，http://www.example.com/some-strange-URL）上发布的 Web 应用程序表示，这些 URL 未在其他地方引用。这可能是由于错误（由于配置错误）或有意（例如，未公布的管理界面）造成的。

为了解决这些问题，有必要执行 Web 应用程序发现。

测试目标

• 枚举范围内存在于 Web 服务器上的应用程序。

如何测试

Web 应用程序发现是一个旨在识别给定基础架构上的 Web 应用程序的过程。后者通常指定为一组 IP 地址（可能是一个网络块），但也可能包含一组 DNS 符号名称或两者的混合。这些信息在评估执行之前分发，无论是经典风格的渗透测试还是以应用程序为中心的评估。在这两种情况下，除非参与规则另有规定（例如，仅测试位于 URL 的应用程序http://www.example.com/），否则评估应力求范围最全面，即它应识别可通过给定目标访问的所有应用程序。以下示例检查了可用于实现此目标的一些技术。

以下一些技术适用于面向 Internet 的 Web 服务器，即 DNS 和反向 IP 基于 Web 的搜索服务以及搜索引擎的使用。示例使用私有 IP 地址（例如192.168.1.100），除非另有说明，否则代表_通用_IP 地址并且仅用于匿名目的。

影响有多少应用程序与给定 DNS 名称（或 IP 地址）相关的三个因素：

1. 不同的基本 URL

   Web 应用程序的明显入口点是www.example.com，即，使用这种简写符号，我们认为 Web 应用程序起源于http://www.example.com/（这同样适用于 HTTPS）。然而，即使这是最常见的情况，也没有强制应用程序从/.

   例如，相同的符号名称可能与三个 Web 应用程序相关联，例如：http://www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3

   在这种情况下，URLhttp://www.example.com/不会与有意义的页面相关联，并且这三个应用程序将被隐藏，除非测试人员明确知道如何访问它们，即测试人员知道_url1_、url2_或_url3。通常不需要以这种方式发布 Web 应用程序，除非所有者不希望以标准方式访问它们，并且准备告知用户其确切位置。这并不意味着这些应用程序是秘密的，只是它们的存在和位置没有被明确公布。

2. 非标准端口

   虽然 Web 应用程序通常位于端口 80 (HTTP) 和 443 (HTTPS) 上，但这些端口号并没有什么神奇之处。事实上，Web 应用程序可能与任意 TCP 端口相关联，并且可以通过指定端口号来引用，如下所示：http[s]://www.example.com:port/. 例如，http://www.example.com:20000/。

3. 虚拟主机

   DNS 允许单个 IP 地址与一个或多个符号名称相关联。例如，IP 地址192.168.1.100可能与 DNS 名称www.example.com、helpdesk.example.com、相关联webmail.example.com。不必所有名称都属于同一个 DNS 域。这种 1 对 N 的关系可以反映为通过使用所谓的虚拟主机来提供不同的内容。我们所指的指定虚拟主机的信息嵌入在 HTTP 1.1主机标头中。

   人们不会怀疑除了显而易见的之外还有其他 Web 应用程序的存在www.example.com，除非他们知道helpdesk.example.com和webmail.example.com。

解决问题 1 的方法 - 非标准 URL

没有办法完全确定是否存在非标准命名的 Web 应用程序。由于是非标准的，因此没有管理命名约定的固定标准，但是测试人员可以使用多种技术来获得一些额外的洞察力。

首先，如果 Web 服务器配置错误并允许目录浏览，则可能会发现这些应用程序。漏洞扫描器可能在这方面有所帮助。

其次，这些应用程序可能会被其他网页引用，并且有可能被网络搜索引擎抓取和索引。如果测试人员怀疑此类隐藏应用程序的存在，www.example.com他们可以使用_网站_运营商进行搜索并检查查询结果site: www.example.com。在返回的 URL 中，可能有一个指向这样一个不明显的应用程序。

另一种选择是探测可能是未发布应用程序候选者的 URL。例如，可以从 https://www.example.com/webmail、https://webmail.example.com/ 或 https://mail.example.com/等 URL 访问 Web邮件前端。这同样适用于管理界面，它们可以在隐藏的 URL 上发布（例如，Tomcat 管理界面），但不会在任何地方引用。因此，进行一些字典式搜索（或“智能猜测”）可能会产生一些结果。漏洞扫描器可能在这方面有所帮助。

解决问题 2 的方法 - 非标准端口

很容易检查非标准端口上是否存在 Web 应用程序。Nmap等端口扫描器可以通过-sV选项进行服务识别，识别任意端口上的http[s]服务。所需要的是对整个 64k TCP 端口地址空间的全面扫描。

例如，以下命令将通过 TCP 连接扫描查找 IP 上所有打开的端口，192.168.1.100并尝试确定哪些服务绑定到它们（仅显示_必要_的开关 - Nmap 具有广泛的选项集，其讨论是超出范围）：

nmap –Pn –sT –sV –p0-65535 192.168.1.100

检查输出并查找 HTTP 或 TLS 包装服务的指示（应探测以确认它们是 HTTPS）就足够了。例如，上一个命令的输出可能如下所示：

Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

从这个例子中，可以看出：

• 有一个 Apache HTTP 服务器在端口 80 上运行。
• 443端口好像有HTTPS服务器（不过这个需要确认，比如https://192.168.1.100用浏览器访问）。
• 在端口 901 上有一个 Samba SWAT Web 界面。
• 端口 1241 上的服务不是 HTTPS，而是 TLS 封装的 Nessus 守护进程。
• 端口 3690 具有未指定的服务（Nmap 返回其_指纹_- 此处为清楚起见省略 - 以及将其提交并纳入 Nmap 指纹数据库的说明，前提是您知道它代表的服务）。
• 端口 8000 上的另一个未指定服务；这可能是 HTTP，因为在此端口上找到 HTTP 服务器并不罕见。让我们检查一下这个问题：

$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...

这证实它实际上是一个 HTTP 服务器。或者，测试人员可以使用网络浏览器访问该 URL；或使用 GET 或 HEAD Perl 命令，它们模仿 HTTP 交互，例如上面给出的交互（但是 HEAD 请求可能不会被所有服务器接受）。

• Apache Tomcat 在端口 8080 上运行。

漏洞扫描器可能会执行相同的任务，但首先检查所选扫描器是否能够识别在非标准端口上运行的 HTTP[S] 服务。例如，Nessus 能够在任意端口上识别它们（前提是它被指示扫描所有端口），并且将提供关于 Nmap 的大量针对已知 Web 服务器漏洞的测试，以及 TLS/ HTTPS 服务的 SSL 配置。如前所述，Nessus 还能够发现流行的应用程序或 web 界面，否则可能会被忽视（例如，Tomcat 管理界面）。

解决问题 3 的方法 - 虚拟主机

有许多技术可用于识别与给定 IP 地址关联的 DNS 名称x.y.z.t。

DNS 区域传输

考虑到 DNS 服务器基本上不支持区域传输这一事实，这种技术现在的使用受到限制。但是，这可能值得一试。首先，测试人员必须确定服务于x.y.z.t. 如果一个符号名称已知x.y.z.t（假设为），则可以通过、或等工具通过请求 DNS NS 记录www.example.com来确定其名称服务器。nslookup``host``dig

如果没有已知的符号名称x.y.z.t，但目标定义至少包含一个符号名称，测试人员可能会尝试应用相同的过程并查询该名称的名称服务器（希望该名称服务器x.y.z.t也能提供服务）。例如，如果目标由 IP 地址x.y.z.t和名称组成mail.example.com，则确定域的名称服务器example.com。

以下示例显示如何www.owasp.org使用以下host命令识别名称服务器：

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

现在可以向域的名称服务器请求区域传输example.com。如果测试人员幸运的话，他们将得到该域的 DNS 条目列表。这将包括明显www.example.com的和不太明显的helpdesk.example.com以及webmail.example.com（可能还有其他）。检查区域传输返回的所有名称，并考虑所有与正在评估的目标相关的名称。

尝试owasp.org从其名称服务器之一请求区域传输：

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.

DNS 反向查询

此过程与前一个过程类似，但依赖于反向 (PTR) DNS 记录。不要请求区域传输，而是尝试将记录类型设置为 PTR 并在给定的 IP 地址上发出查询。如果测试人员幸运的话，他们可能会得到一个 DNS 名称条目。此技术依赖于 IP 到符号名称映射的存在，但不能保证这一点。

基于 Web 的 DNS 搜索

这种搜索类似于 DNS 区域传输，但依赖于在 DNS 上启用基于名称的搜索的基于 Web 的服务。其中一项服务是Netcraft 搜索 DNS服务。测试人员可能会查询属于您选择的域的名称列表，例如example.com. 然后他们将检查他们获得的名称是否与他们正在检查的目标相关。

反向 IP 服务

反向 IP 服务类似于 DNS 反向查询，不同之处在于测试人员查询基于 Web 的应用程序而不是名称服务器。有许多这样的服务可用。由于它们倾向于返回部分（并且通常是不同的）结果，因此最好使用多种服务来获得更全面的分析。

• MxToolbox 反向 IP
• DNSstuff（提供多种服务）
• Net Square（域名和IP地址的多次查询，需要安装）

谷歌搜索

从以前的技术收集信息后，测试人员可以依靠搜索引擎来改进和增加他们的分析。这可能会产生属于目标的其他符号名称的证据，或者可以通过不明显的 URL 访问的应用程序。

例如，考虑前面关于 的示例www.owasp.org，测试人员可以查询 Google 和其他搜索引擎以查找与新发现的域 、 和 相关的信息（因此，DNSwebgoat.org名称webscarab.com）webscarab.net。

谷歌搜索技术在测试：蜘蛛、机器人和爬虫中有解释。

数字证书

如果服务器接受通过 HTTPS 的连接，则证书上的通用名称 (CN) 和主题备用名称 (SAN) 可能包含一个或多个主机名。但是，如果网络服务器没有受信任的证书，或者正在使用通配符，则可能不会返回任何有效信息。

CN和SAN可以通过手动查看证书获取，也可以通过OpenSSL等其他工具获取：

openssl s_client -connect 93.184.216.34:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org
DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net

工具

• nslookupDNS 查找工具，例如dig和类似的工具。
• 搜索引擎（Google、Bing 和其他主要搜索引擎）。
• 专门的 DNS 相关的基于 Web 的搜索服务：见正文。
• 地图
• Nessus 漏洞扫描程序
• 尼克托