Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

On Using Application-Layer Middlebox Protocols for Peeking Behind NAT Gateways

作者:Teemu Rytilahti, Thorsten Holz

单位:Ruhr University Bochum

会议:The Network and Distributed System Security Symposium (NDSS) 2020

原文:On Using Application-Layer Middlebox Protocols for Peeking Behind NAT Gateways

Abstract

由于 NAT、防火墙等原因,现有的端口扫描器并不能完整覆盖到所有连接到互联网上的设备。尤其是 NAT 的广泛部署带来了一个隐藏设备的副作用。但是由于一些需要端到端的协议的需求,很多方法被部署用来穿透网络屏障。

在这篇文章中,作者研究了攻击者是如何使用这种应用层中间件来攻击网关后面的设备的。更具体而言,作者使用合法的协议特性来调查这几种不同的应用层中间件。

  1. 持久性端口映射协议,例如 UPnP 和 NAT-PCP/PMP
  2. 非持久协议,例如 SOCKS 和 HTTP 代理

作者进行了一次互联网际的扫描并分析发现,互联网上有数十万个主机存在上述问题。而更令人担忧的是,经验性的证据表明已经有攻击者在互联网上利用这种漏洞来攻击 NAT 网关后的设备。作者还发现有至少 24% 的开放互联网代理配置有误,可以用来访问不可路由的主机的地址。

Introduction

端口扫描是互联网上非常普遍的现象。常用的 nmap 工具并不能快速扫描非常广的目标,因此像 zmapmasscan 这种可以互联网际扫描的工具被开发出来。现在,我们也有 CensysShodan 这种互联网际端口扫描数据库来供我们分析。

但是,上述这种典型的扫描工具并不能覆盖到所有连接到互联网上的设备。由于 IPv4 地址空间紧缺还有防火墙等问题,现在互联网已经很难端到端连接两台主机。因此,IPv6 被设计出来以解决 IPv4 地址空间紧缺等问题,但是底层协议的更换需要大量的人力物力,也不可能很快普及。在这种情况下,NAT 被设计出来并广泛部署以扩大 IPv4 的地址空间。最近也有很多运营商级别的 NAT(CGN)完成了部署从而扩大用户容量。仅需要一个面向广域网的设备作为网关并分配给客户端不可在广域网上路由的地址就可以容纳海量的客户端。

在本文中,作者探索了多种方式去访问本来不应当被访问到的,隐藏在 NAT 网关之后的设备。作者的方法基于这样的见解,即通过 NAT/CGN 进行连接也有弊端。重要的是,NAT 会破坏端到端的连接,例如 VoIP 协议和 FTP 协议主动模式等,更重要的是,NAT 会抛掉没有指定转发到内网主机的外网入站数据包,使得外网主机在没有 NAT 转发的情况下不可能访问到内网主机。为了克服 NAT 这种问题,有很多应用层中间件被开发出来,例如 UPnP 和 NAT-PMP/PCP 这种端口转发配置协议与 HTTP 和 SOCKS 这种代理协议。

作者拟出这样的一种威胁模型:外部攻击者使用这种应用层中间件协议穿透 NAT 网关攻击内网主机。作者首先使用互联网际扫描工具获得了超过 40 万个可能存在安全漏洞的 UPnP 响应主机,而有趣的是,其中有超过 6 万个主机存在已经被攻击过的痕迹。作者还提供了在 UPnP 枚举特性的帮助下获得的 NAT 端口映射使用情况的全面的分析。其次,作者还研究了非持续性、临时中继的 HTTP 与 SOCKS 代理协议。作者发现,暴露在互联网上的代理中接近 3% 是开放的,没有鉴权的代理。在开放代理中,有 23% 配置有误,攻击者可以使用这些开放代理访问内网设备。

Key Contribution

  1. 探索了几种不同的方法可以通过 NAT 网关连接内网设备
  2. 进行了互联网际的大规模扫描,全面分析了这些应用层中间件协议
  3. 提供了一个相较于之前研究更加全面且综合的对代理生态系统的分析视角

UPnP 网关设备

UPnP 协议可以使设备能够轻松发现和控制其他支持 UPnP 的设备。家庭娱乐设备就是 UPnP 在现实场景中的典型应用。在本文中,作者主要关注 UPnP 网关设备的配置文件,即 UPnP Internet Gateway Device(IGD)描述文件。由于不同厂商对 UPnP 协议的实现不同,UPnP 可以提供的功能也非常多样,不过普遍功能包括查询外部接口连接状态、控制例如 DHCP 的潜在综合服务和控制端口映射。

在这章中,作者调查了 UPnP IGD 中的端口映射控制配置文件,尤其关注外部用户如何滥用这种配置文件来增加新的端口映射并攻击内网主机。作者还强调,这种攻击方法可能已经被攻击者滥用。

检测方法

  1. 使用 ZMap 进行互联网际扫描 UPnP 设备
  2. 下载设备描述文件,查找是否有暴露的服务
  3. 枚举已经存在端口转发

网际扫描

虽然 SSDP 使用类似 HTTP 协议的请求监听在 239.255.255.250 UDP 多播地址,1900 端口上,但是架构规范规定也应当接受单播的搜索请求。因此,作者使用通配目标 ssdp:all 来获得 UPnP 设备的所有可用服务。由于 ZMap 只扫描 1900 端口,但是并不是所有 UPnP 服务都跑在 1900 端口上的,所以作者还修改了 ZMap 来扫描所有可能有 UPnP 服务的主机。

寻找端口映射服务

在上一步中,作者从扫描到的主机中的响应拿到的 LOCATION 字段中指定了设备描述文件位置,这样再将内网 IP 地址替换为 SSDP 返回的地址发起一次 SSDP 请求就可以获得设备描述文件。这里作者主要关注 WANIPConnectionWANPPPConnection 这两个服务的接口地址。

列举已经存在的端口映射

使用上面获得服务地址发起一次列举请求,获得网关的端口映射信息。

评估

  1. 作者的 ZMap 互联网际扫描拿到了约 280 万个 UPnP 主机响应,超过半数来自亚洲
  2. 作者筛选出了约 38% 即约 110 万个 UPnP 主机存在端口映射服务。但是 86% 的主机的 SSDP 返回了 SOAP 错误响应,指出其虽然支持该接口但是没有活跃的端口转发
  3. 作者在约 27% 个 WAN*Connection 的接口中获取到了接近 500 万个端口转发,覆盖了几乎所有可能的端口。在筛选了显示禁用的或者没有更多信息的端口后,结果还剩余 330 万个端口转发

作者将结果分为三类:Galleta Silenciosa、转发外网可路由地址和无害的端口转发:

  • Galleta Silenciosa - Silent Cookie:约占 32%(约 42000 个主机),EternalSilence 攻击后产生的痕迹,转发 139 与 445 端口。约有 160 万个 IP( 7600 个不同的 /24 子网)转发到了约 22000 个独立 IP 地址。这种现象表明,已经有攻击者大规模发起过对 UPnP 协议的滥用,攻击了大量内网主机。
  • 外部端口映射:超过 18000 个网关设备映射到了 32000 个不同 IP 地址。更具体而言,常见的描述是 galleta silenciosa(约 27000 转发到了 约 10000 个主机),MONITOR(在约 5100 个主机上存在约 53 万个映射),还有 Node.js UPnP 库的 node:nat:upnp(在约 1400 个主机上存在超过 1800 个映射)。然而这里的 galleta silenciosa 很像链接到同一组网关中的路由器,node:nat:upnp 则指向 DNS 端口。MONITOR 的转发目标没有被包含在作者的数据集中,这些转发大多数在 HTTP(S) 端口和 11239 个独立的 IP 上,且约有 7000 个地址存在 DNS 反向解析记录指向了大多数广告网络、VPS提供商和 CDN 目标等,可能用于域名前置。
  • 无害端口映射:约 114000 个主机存在超过一百万个不重复的端口转发,包括约 25000 个主机转发 HTTP(S)、telnet、SSH、SMTP 与 FTP 等端口,UDP 中一般是 WhatsApp、WeChat 与 PlayStation 等端口映射。最普遍的子网网段是 192.168.0.0/24 与 192.168.1.0/24。

转发 0 号端口与转发广播地址:转发 0 号端口非常奇怪,规范规定 0 号端口不允许作为转发目标,只能作为通配符来表示所有未映射的端口都要转发到指定的客户机上(约 500 个网关上映射了外部端口,约 3100 个转发内部地址),这种可能存在潜在的流量监听的风险。转发 255.255.255.255 地址也非常奇怪,大约 1300 个主机转发了 1300 个 TCP 端口(大部分是 44382)和 2100 个 UDP 端口

作者使用(制造商,型号名,型号编号)来标记评估的主机,来确定是否有漏洞存在。最后作者筛选出了约 48 万个 SOAP 接口暴露的设备可能存在潜在漏洞,并且其中 86% 的主机绝对存在漏洞。

UPnP 网关蜜罐

依据前文所述的经验性结果,作者部署了一个 UPnP 蜜罐来尝试追踪这种攻击。作者部署的蜜罐实现了 GetGenericPortMappingEntryAddPortMapping 这两个接口,并使用一台真实的且有漏洞的设备。由于 SSDP 协议可能用于发起 DDoS 攻击,作者限制了蜜罐响应的频率防止蜜罐被滥用。作者还修改了设备描述符的地址去观察真实攻击者会不会解析响应。

从 2018 年 12 月 9 日到 2019 年 2 月 3 日,作者一共观察到了 791 个 HTTP 请求来自 52 个不同的 IP 地址,其中 821 个 IP 地址发送了 SSDP 发现请求(?)。作者观察到的添加端口映射请求似乎是在内网尝试使用 CVE-2014-8361 的命令注入 exp(D-Link 路由器 RCE 洞)。

关键发现

作者分析发现并指出在互联网上已经有攻击者使用这种特性来扫描 NAT 网关后的设备、攻击这些设备或者当成跳板来伪装流量。最常见的无害映射为 Bittorrent 或者 VoIP 软件。最常见的内网网段为 192.168.0.0/24 和 192.168.1.0/24。

NAT-PMP 与 PCP

NAT-PMP 协议也是一种简单的 UDP 协议,使用 5351 端口。它只支持三种操作:ANNOUNCE 来决定 NAT 网关的外部地址和用来服务器通知客户端,MAP UDPMAP TCP 来请求端口映射。PCP 协议则是 NAT-PMP 协议的继任者,并且兼容 NAT-PMP 协议。PCP 协议扩展了 IPv6 支持和出站映射等。

检测方法

与前文一样,使用 ZMap 来进行互联网际扫描。但是 NAT-PMP 和 PCP 都不支持枚举已经存在的端口映射,作者只能尝试探测这种误配置的存在。

  1. PCP 服务器发现:使用 ZMap 发送单个 ANNOUNCE 请求到 5351 端口进行互联网际扫描,期望获得 SUCCESS 响应
  2. 检查第三方选项:发送一个 MAP 请求来尝试映射端口,并检查响应

评估

  1. PCP 服务器发现:互联网际扫描获得了 625057 个暴露的接口。89% 响应仅支持 NAT-PMP,几乎所有支持 PCP 协议的响应了 NOT_AUTHORIZED
  2. 第三方选项支持:约 31000 个服务器有预期响应,并且出乎意料的是没有服务器不支持这种请求或者返回了另一种错误代码或者完全忽略请求。
  3. 请求端口映射:绝大多数都返回了 NOT_AUTHORIZED

流量劫持

作者发现小部分误配置的 NAT-PMP 网关可以使路由器通告一个内部地址为外部地址。这种情况可能创建端口映射使得指向路由器给定端口的流量都会转发给该端口映射的创建者。作者扫描了 Rapid7 的 NAT-PMP 扫描结果并发现仍然有 48 万多个设备将 RFC1918 定义的内网 IP 作为外部地址。

关键发现

仅有一小部分主机支持更安全的 PCP 协议,其他 NAT-PMP 主机存在误配置,但是不能确定是否存在端口映射来访问内部主机。

网络代理

不同于先前讨论的 NAT 端口映射这种通过修改路由表达到的端口映射,代理可以临时地在客户端与目标之间转发数据。由于 Tor 和便宜的 VPN 解决方案增多,代理数量已经大量减少,但是现在网络上仍然有大量的开放互联网代理可以用于绕过地理性网络阻断。

HTTP/SOCKS 代理

  • HTTP 代理可以使用绝对地址来代理客户端请求,例如 GET http://localhost/ HTTP/1.1,也可以使用 CONNECT 方法来代理 TCP 流
  • SOCKS 有两个版本:SOCKS4(A) 与 SOCKS5,都可以用来代理 TCP 流。SOCKS5 还支持 IPv6 代理和 UDP 代理。

检测方法

  1. 互联网际扫描:扫描几种常见的代理端口
  2. 确认开放:确认扫描到的代理可以正常访问到作者部署的 Judge 主机
  3. 检查内网访问:检查代理是否可以请求 127.0.0.1 或 192.168.0.1 这种内网地址和 21,22,23,25 等服务端口
  4. 辅助代理爬取:从 ProxyBroker 中爬取代理列表来辅助代理检查

评估

这里没啥好说的,代理能访问内网地址本来就没有任何问题,更谈不上是安全漏洞。很多情况下代理访问内网地址可以作为反向代理,是有意为之的。就对作者检测的访问内网地址而言,作者也没有去爆破内网地址,而是简简单单去访问 127.0.0.1 和 192.168.0.1,端口数量也很少,只测了 21,22,23,25 这几个有 banner 回显的端口。但是像 139、445 这种高度敏感的端口作者也没有测试。这种不免使研究结果显得有点单薄。

避免这种代理的安全问题最好也最简单的办法就是代理鉴权。开放代理带来的问题远远不止访问内网地址这么点,可能因为与本文作者研究没有太大关系,因此没有说明。

讨论与局限

伦理考虑

由于作者研究是研究网络上的存活主机,因此作者尽可能避免其扫描和攻击对存活主机造成影响。

补救措施

  • 关闭 UPnP 在公网上的访问
  • 代理鉴权

Appendix

  • CVE-2020-12695