Apache 日志中具有重复协议 (GET /https://https://www.DOMAIN.com) 的格式错误的 HTTP 请求 - 他们正在扫描什么漏洞？

信息安全 阿帕奇 漏洞扫描器
2021-08-31 01:32:50

大约每天一次，我在我的 Apache 2.4 httpd 日志中看到以下一系列请求，我试图找出正在扫描的漏洞。这些扫描的每次出现都具有相同的模式（将我的域名替换为 DOMAIN）：

89.123.16.10 - - [20/Dec/2017:05:35:37 +0000] "GET /https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:37 +0000] "GET /https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:38 +0000] "GET /https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:39 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:40 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:41 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:42 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236
89.123.16.10 - - [20/Dec/2017:05:35:42 +0000] "GET /https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://https://www.DOMAIN.com HTTP/1.1" 301 236

请求来自以下主机：

103.194.169.16 - 荷兰（在IIS 8.5 Windows Server上运行的 Java 1.8 客户端）
109.102.111.66 - 罗马尼亚布加勒斯特（Java 1.6 客户端，被一项服务禁止）
109.102.111.67 - 罗马尼亚布加勒斯特（Java 1.6 客户端，被多项服务禁止） , 字典攻击, 垃圾邮件屋)
109.102.111.76 - 罗马尼亚布加勒斯特 (Java 1.7 客户端, 被多个服务禁止)
109.102.111.84 - 罗马尼亚布加勒斯特 (Java 1.6 客户端, 被一项服务禁止)
109.102.111.89 - 罗马尼亚布加勒斯特 (Java 1.6 客户端，被一项服务禁止）
109.102.111.92 - 罗马尼亚布加勒斯特（Java 1.6、1.8 客户端，被多项服务、字典攻击、垃圾邮件屋禁止）
172.111.130.9- 罗马尼亚布加勒斯特（Java 1.6 客户端，被一项服务禁止）
172.111.200.61 - 德国法兰克福（Java 1.6 客户端，被一项服务禁止）
23.227.201.194 - [Swiftway Cloud - swiftwaycloud.com] 美国芝加哥（Java 1.6在 IIS 7.5 ASP.NET 服务器上运行的客户端，被一项服务禁止）
79.5.128.38 - Piansano，拉齐奥，意大利（Java 1.6 客户端，被多项服务禁止）
89.123.14.74 - 罗马尼亚布加勒斯特（Java 1.6 客户端，被多项禁止服务，垃圾邮件屋）
89.123.16.10 - 罗马尼亚布加勒斯特（Java 1.6 客户端，被多项服务禁止）
89.123.20.221 - 罗马尼亚布加勒斯特（Java 1.6 客户端，被多项服务禁止，垃圾邮件屋）
89.123.31.76- 罗马尼亚布加勒斯特（Java 1.6 客户端，被多项服务、字典攻击、垃圾邮件屋禁止）
89.136.31.222 - 罗马尼亚布加勒斯特（可能是家庭宽带地址、Java 1.6 客户端，被多项服务、字典攻击、垃圾邮件屋禁止）

大多数主机都是罗马尼亚人，所以我假设这些扫描的来源是在那里。此外，我可以在请求时间中辨别出的唯一模式是，这些请求从未在 UTC 时间 09:00 到 UTC 时间 12:00（罗马尼亚的晚上 11 点到凌晨 3 点）发生。已涵盖一天中每隔 30 分钟的时间段，每天最多出现 4 次，每天最少出现 1 次。

正如评论中提到的，我使用重定向规则将 HTTP 请求转发到 HTTPS：

RedirectMatch permanent ^ https://www.DOMAIN.com

值得注意的是，这些请求都只出现在我的非 SSL 日志中。我的服务器配置返回 301（永久移动），它将非 SSL 请求重定向到https://www.DOMAIN.com。执行这些扫描的 IP 地址从不通过 HTTPS 发出任何请求，并且只执行这种类型的扫描。

我已经使用 curl 复制了确切的日志：

C:\>curl -s -D - http://www.DOMAIN.com/https://https://www.DOMAIN.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 21 Dec 2017 15:49:58 GMT
Server: Apache
Location: https://www.DOMAIN.com
Content-Length: 236
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.DOMAIN.com">here</a>.</p>
</body></html>

日志条目中的结果（替换了我的域和 IP 地址）：

192.168.1.5 - - [21/Dec/2017:14:29:57 +0000] "GET /https://https://www.DOMAIN.com HTTP/1.1" 301 236

概括

来自远程主机的初始格式错误的请求：

GET http://www.DOMAIN.com/https://https://www.DOMAIN.com

我的服务器返回：

301 https://www.DOMAIN.com

远程主机从不请求上述 URL。

来自远程主机的第二个格式错误的请求：

GET http://www.DOMAIN.com/https://https://https://www.DOMAIN.com

我的服务器返回（有关确切的服务器响应，请参见上面的 curl 示例）：

301 https://www.DOMAIN.com

远程主机从不请求上述 URL。

依此类推，进行 24 次迭代。我的服务器总是返回的事实https://www.DOMAIN.com表明格式错误的 URL 是由远程主机故意构建的。

是否存在正在扫描的特定已知漏洞或服务器配置错误？

我相信任何 SSL 证书问题都可以简单地排除，因为这些主机从未发出过 SSL 请求（除非扫描被划分以避免牵连其他主机）。

我只发现了另一个类似的案例（2016 年 4 月）：

  1. 无法映射 GET /https:///https:///https:/https:///https:/https:/https:/ ...

我添加了来自Project Honeypot和What Is My IP Address Blacklist的元数据。据报道，这些主机都使用 Java 客户端，范围从 Java 1.4 到 Java 1.8。

1个回答

我更新了问题以添加有关发出这些请求的远程主机的信息。事实证明，由于各种原因（字典攻击、垃圾邮件、行为不端的网站爬行），除了一个之外，其他所有人都已经在公共黑名单上。这些请求是由各种过时的 Java VM 发出的，这可能表明所有这些主机都受到了损害（但是，由于它们中的大多数都来自一个国家，这可以作为该论点的对立面）。

有趣的是，三台非罗马尼亚主机中有两台正在运行 IIS 服务器（v7.5 和 v8.5）——我强烈怀疑这些主机是受感染的主机。只是为了好玩，我尝试对这些服务器进行相同的格式错误的 HTTP 请求，但只是收到 404 错误。罗马尼亚主机没有（显然）运行 IIS，但（表面上）运行的是 Java 的古老版本。

使用旧版本的 Java（1.4 到 1.6）发出这些请求的问题在于，这些版本不支持在 Web 上实现的任何常见 SSL。Java 1.6 支持 SSLv3 和 TLS 1.0，也不支持 SNI。这恰好是我在SNI Hole问题中描述的同一台服务器。

最终，远程客户端可能遇到了重定向循环，这不是由于配置错误，而是更可能是由于其旧 Java VM 中缺乏 SNI 支持。请求将仅通过 IP 地址传递到我的默认主机 (www.DOMAIN.com)，然后重定向回默认主机名。本质上，我的服务器返回一个 SNI 主机名，但他们的客户端不理解它。

我认为这些请求来自各种较旧的 Java VM 的原因是它们受到了一些已知的 Java 漏洞和/或已知的 IIS 漏洞的影响。

重定向 URL 中“/https://”的累积可能是由于爬虫/扫描程序 Java 代码不支持该协议，这是有道理的，因为相同的代码（很可能）在 Java 1.4（无 SSL ，无 SNI，最低公分母）、1.6 SSLv3+TLS1.0、1.7 (SSL+SNI) 和 1.8 (SSL+SNI)。如果代码打算在古老的 Java VM 上运行，那么在代码中没有真正的理由支持甚至理解 SSL，因此它可能认为 HTTPS 协议 URL 是相对的而不是绝对的。

归根结底，为了确定这些请求的确切性质，我需要一份用于发出这些请求的 WAR、JAR 或类文件的副本。我已经联系了 Swiftway Cloud，看看他们是否可以提供一份来自参与此活动的芝加哥受感染服务器的副本。

更新： Swiftway Cloud 回应称，即使使用此处提供的信息，他们也无法识别主机上的任何“恶意”活动。这是一个问题，因为责任分离（“无害”爬行/探测与“恶意”垃圾邮件），即使有明确的主机之间共谋的证据，似乎已经导致无法说服云供应商对记录的问题采取反应措施。

其它你可能感兴趣的问题
上一篇iCloud 功能中的 iMessages = Apple 服务器上的所有未加密消息。有多安全？ 下一篇命令替换和管道是否可以防止窥探者看到散列密码从进程 A 传递到 B？