引言

近日诸事不利，遂求于高人，高人曰：“施主貌比潘安，恐已遭人妒忌，身边有小人作祟！需破100文香火钱，贫道可替施主消此灾厄。”笔者闻言大惊，乃付。高人颔首，笑曰此灾已破，施主可安心矣，遂返。是夜忐忑入梦，忽见一皓首道人大笑曰：“小友，20文香火钱焉能消灾？本道见你貌比潘安，与你有缘，便送你一个在野0day可好？”

梦回惕醒，怒骂之：匹夫安敢黑我香火钱！一怒之下怒了一下，方才入睡。

在野的0day

言归正传，当笔者拖着疲惫的身躯开始扮演一只会点鼠标的猴子时，突然回想起昨日的一幕，不禁悲从中来，感叹生活之艰难之余，点开了告警监测系统，赫然发现了一条任意文件读取的告警，被攻击系统是某知名传媒行业的新闻采编系统，难道说这就是那个在野0day？

于是对告警信息进行了仔细研究，经过多次的构造数据包和验证，终于发现了这个已经被人在实际利用的漏洞。不过并非任意文件读取漏洞，而是ssrf漏洞，可操作性比任意文件读取要强一丢丢。

在互联网和cnvd都搜索了一下这个漏洞是否被公开过，结果是并没有！

好家伙，大佬真是坏昂，干什么都藏着掖着。

ssrf漏洞利用

概念

经常水洞的朋友都知道，SSRF漏洞（也就是服务器端请求伪造漏洞）就是攻击者通过构造一个恶意的 URL（如指向内网服务的地址）提交给服务器，服务器在没有做任何验证和过滤的情况下将该 URL 解析并执行访问，继而返回响应结果。

这里的关键就是攻击者可以自由构造的URL，我们在水洞的时候有一个漏洞叫做URL重定向漏洞，也是可以修改URL地址。但其实两者只是有一定的相似性，从利用方式和原理上都是有很大的差异，SSRF漏洞的危害远比重定向漏洞要高。

利用方式

1. 访问内网资源

在许多网络环境中，内网资源通常对外部访问是做了限制的，但服务器可能具有访问内网资源的权限。攻击者可以利用 SSRF 漏洞访问内网中的敏感服务，例如：

• 内网 HTTP 服务

• Redis、Memcached 等未授权的数据库

• Cloud Metadata 服务（如 AWS EC2 的 Metadata API）

示例： 攻击者通过漏洞构造如下 URL：

http://assrf-example.com/file?url=http://192.168.0.1/admin

服务端将上述请求解析并发送至目标地址，可能导致内部管理页面泄露，更严重点就是有struts2、redis未授权访问这些漏洞被利用直接getshell内网了。

以这个某全媒体采编系统的SSRF漏洞为例，可直接使用burp suite爆破http服务。

2. 利用协议的扩展攻击

要不是水过洞，我也是不会去关注URL除了http和https协议外，还有其他的协议可以使用。我们可以试一下在浏览器的URL中输入file:///C: 看看。

这也是攻击者最常用的攻击方式，SSRF 不局限于 HTTP 协议，攻击者还可能通过文件协议、FTP 等实现其他类型的攻击。

• • • 利用file://协议读取服务器本地文件：

      http://assrf-example.com/file?url=file:///etc/passwd

    • 利用gopher://协议发送定制的二进制数据：

    • http://assrf-example.com/file?url=gopher://127.0.0.1:6379/_%0D%0ASET%20key%20value%0D%0A

    • 利用ftp://文件传输协议

      http://assrf-example.com/file?url=ftp://192.168.9.1:21/

除了这些扩展协议外，当然还有dict等协议可以利用，也能做一些扫内网口等操作。这里还是测一下这个知名新闻采编系统的file协议来看看。

想读哪里读哪里，非常好用。

SSRF 漏洞的典型案例

很多人也许意识不到SSRF漏洞的严重性，觉得其远没有命令执行、反序列等这些RCE漏洞的危害性大。但他们却忽略了敏感信息泄露对网络安全造成的致命危害，一旦其被攻击者捕捉到，也许安全的瓦解也就由此开始。

Capital One 数据泄露事件

Capital One 遭遇的一次大规模数据泄露中，攻击者利用 AWS EC2 Metadata 服务，通过 SSRF 漏洞获取 IAM 角色的临时凭证，并使用这些凭证访问了 S3 存储桶中的敏感数据。

此次事件是由一个漏洞和一个错误配置所导致的。其中SSRF漏洞是一切的开端，让攻击者找到了突破口，得以窥视内部的网络服务；随后，一个错误配置让攻击者获得了大量的敏感信息。

SSRF 漏洞的防范

1. 输入校验和白名单机制

• 严格校验用户输入：对用户传入的 URL 参数进行验证，确保其符合预期格式。例如，可以使用正则表达式匹配合法的域名或 IP 地址。

• 启用白名单：仅允许访问特定的安全地址或域名。例如：

  allowed_domains = ["example.com", "api.example.com"]
  if parsed_url.netloc not in allowed_domains:
      raise Exception("该域名禁止访问")

2. 禁止访问本地地址

• 拦截私有 IP 地址范围的访问，例如：

  • 127.0.0.0/8（本地回环地址）

  • 10.0.0.0/8（内网地址）

  • 192.168.0.0/16（内网地址）

• 示例实现：

  import ipaddress
  
  def is_private_ip(ip):
      try:
          ip_obj = ipaddress.ip_address(ip)
          return ip_obj.is_private
      except ValueError:
          return False

3. 网络层防护

• 配置防火墙或安全组，限制服务器对不必要的内网资源或外部地址的访问。

• 禁止服务器直接访问云服务的 Metadata 地址。

4. 限制协议支持

• 如果应用仅需要访问 HTTP 或 HTTPS 地址，明确限制协议类型，拒绝file://、gopher://等非 HTTP 协议。

示例代码：

allowed_protocols = ["http", "https"]
parsed_url = urlparse(user_input_url)
if parsed_url.scheme not in allowed_protocols:
    raise Exception("Unsupported protocol")

5. 最小化权限设计

• 确保服务器的权限最小化，避免不必要的敏感信息暴露。

• 对云服务使用 IAM 角色时，限制角色权限，防止攻击者通过 Metadata API 获取高权限凭证。

总结

在云计算的快速发展下，SSRF 对云上系统提出了更大的安全挑战。云环境中的多租户架构、动态资源分配以及广泛使用的元数据服务使得 SSRF 漏洞的影响范围更为广泛。例如，通过 SSRF 攻击云服务的 Metadata API，攻击者可能获取云实例的访问密钥，进一步入侵其他服务。