基于SSDP的反射放大攻击调研

随着物联网的蓬勃发展，智能家电、无线路由器、打印机、网络摄像头、游戏机等设备越来越普及，也就导致承载了UPnP协议的设备越来越多，也就是可以利用来进行SSDP反射放大协议的反射器越来越多。

什么是 UPnP ？和 SSDP 有什么关系？

UPnP 是 Universal Plug and Play 的缩写，也就是通用即插即用，这是用于发现和与网络上各种设备提供的服务进行交互的标准。

UPnP使用多种不同的协议来实现它的目标:

- SSDP: Simple Service Discovery Protocol,简单服务发现协议，用于发现本地网络上的通用即插即用设备。

- SCPD: Service Control Point Definition,服务控制点定义，用于定义各种服务提供的操作。

- SOAP: Simple Object Access Protocol, 简单对象访问协议，用于实际调用操作。

以下是通用即插即用会话流程的示意图，以及不同协议的作用。

UPnP 的标准操作流程是首先使用 SSDP 来发现网络上可用的通用即插即用设备。这些设备返回一个 XML 文件的位置，该文件定义了每个设备提供的各种服务。接下来，我们在每个服务上使用 SCPD 来发现每个服务提供的各种操作。从本质上说，SCPD 是一种基于 xml 的协议，它描述了类似于 WSDL的 SOAP API。最后使用 SOAP 调用与服务交互。[1]

关于UPnP的详细信息可以参考 UPnP standard。

为什么SSDP协议可以用来进行反射放大攻击？

能进行发射放大的协议必须满足：

1、基于无连接的UDP，可以进行源地址欺骗

2、该协议的某些请求会导致比该请求大很多的回复

3、互联网上有大量可用的反射器——实现该协议并开放端口的设备/服务器

下面针对上述三个点分别阐述 SSDP 能被用来进行反射放大的原因。 

1. SSDP 使用 UDP 协议而不是 TCP

   因为 SSDP 是用来做服务发现的，我们一开始并不知道设备服务的位置，所以需要通过广播包来发现设备服务，这就导致了 SSDP 只能使用无连接的 UDP 协议。SSDP 的 OSI 模型如图所示：

2. SSDP 的 M-SEARCH 请求包可以导致放大的回复

   M-SEARCH 是 SSDP 发现设备的主要方法：控制点通过在保留地址和端口(239.255.255.250:1900)上多播一个搜索消息，用来搜索感兴趣的设备或服务。当设备在收到符合条件的 M-SEARCH 包后需要给这个包的源IP地址发送一个回复包表明自己的存在。

   那对设备来说什么是符合的包呢？

   1. M-SEARCH请求的ST头字段是ssdp:all或者upnp:rootdevice

   2. M-SEARCH请求的uuid字段与设备所声明的uuid完全匹配

   3. M-SEARCH请求与设备所支持的设备类型或服务类型匹配

   SSDP M-SEARCH 的请求包格式如下：

    M-SEARCH * HTTP/1.1

    Host: 239.255.255.250:1900    //IANA 为 SSDP 预留的组播地址

    ST: ssdp:all                               //Search Target，搜索的节点类型

                                                    //如果搜索所有的设备和服务，则为 ssdp:all

                                                    //如果是搜索根设备，则为 upnp:rootdevice

    Man: "ssdp:discover"

    MX: 3                                      //1到5之间的一个值,表示最大的等待响应的秒数

    回复包的大概格式如下：

    HTTP/1.1 200 OK

    CACHE-CONTROL: max-age=1800

    DATE: Tue, 11 Dec 2007 09:13:18 GMT

    EXT:

    LOCATION: http://10.123.9.41:49152/description.xml

    SERVER: Linux/2.6.5-it0, UPnP/1.0, Intel SDK for UPnP devices /1.2

    ST: upnp:rootdevice

    USN: uuid:{59765E24-0C12-4d20-BsdsEE-71578AE02CB9}_e0:61:b2:14:9d:10::upnp:rootdevice

    有些设备的回复包的数量会很多，从而导致流量的放大，这些设备就可以成为反射器。那如何利用这个反射器？一般情况下控制点都是在保留地址和端口(239.255.255.250:1900)上多播搜索消息，要利用反射器只需要把目的地址从多播地址改为反射器的地址，并且把 ST 设为 ssdp:all/upnp:rootdevice，这样就会反射器一定会回复。此时再把源 IP 地址改为要攻击的 IP，这些反射器的回复就都发送到要攻击的 IP 上去了。

3. 本应该应用在内网的端口被无意中开放到外网,并且不检查查询方是否与设备在同一个网络中

   虽然 SSDP 大多数情况下都是用在局域网，也有论文直接表明在英特网上 SSDP 大部分都不是良性的：

Most other protocols can be filtered, as they have little benign use on the Internet(e.g., CharGen, QOTD, or even typical LAN protocols such as NetBIOS and SSDP). [2]

   但本文参考的一篇文章的作者表明他希望用UPnP支持从外部网络到本地运行的应用程序的连接:

I underwent this whole journey of UPnP because I wanted a way transparently support connections from externals networks to my locally-running application.[1]

   除非 SSDP 标准明确表明这是一个只能用在 LAN 中的协议，否则在公网上直接过滤 SSDP 会导致误伤，ISP 可以通过权衡这个误伤和带来的好处做出最后的决策。

英特网中 SSDP 流量

上述第三点让我想知道英特网中到底有多少 SSDP 流量，以及他们都在做什么。

我在某网络的镜像流量中每十分钟统计 SSDP 占 UDP 流量的百分比，20191106的最后统计结果是0.04%到2.5%，平均占比0.44%，对比DNS流量的平均占比0.97%，SSDP 的占比不算低。

那这些 SSDP 流量都在做什么呢？我存了2分钟左右 SSDP 数据包进行了人工查看，有一部分不是 SSDP ，但因为用了 UDP 1900 端口，所以被我统计进去了，但占比不多，有时间可以进一步精确化统计代码。还有一部分猜测是扫描，从一个 IP 发送完全相同的数据包到很多不同 IP 的1900端口。

另外有一个 IP 引起了我的注意，这个 IP 相关包的字节数占了所有捕获下来流量的99.36%。这个 IP 和某几个IP在进行持续不断的通信，但是通信内容都是一样的，一个请求包和三个回复包：

并且我发现这些回复包的资源 IP 都是一个内网 IP，即使知道了这个资源地址也并不能获取到相关资源，也就是说这个请求包的目的并不是获取这个资源，这一现象很可疑，我猜想这个 IP 有可能一个 SSDP 的反射器，于是使用 ssdp_query.py[4] 对这个 IP 发送了一个 SSDP M-SEARCH 的包，这个 IP 果然回复了我三个包，放大倍数是8.96。

根据这个报文的 SERVER 字段推测这个 IP 是属于一家提供存储解决方案的公司，我不知道他们这个1900端口是不是不小心打开的，还是他们的业务需要用这个端口在互联网上进行交流。但是可以肯定的是这个 IP 的确可以用来进行反射放大攻击。

这个实验让我大概了解到公网中的 SSDP 流量几乎都是没有用的。另外确认了可以从流量中获取反射器的信息，从而可以联系相关负责人减少反射器的存在。

参考资料

1. Krämer, L., Krupp, J., Makita, D., Nishizoe, T., Koide, T., Yoshioka, K., & Rossow, C. (2015). Amppot: Monitoring and defending against amplification ddos attacks. International Symposium on Recent Advances in Intrusion Detection, 615–636.

2. Ferry Boender, Exploring UPnP with Python

3. 阿凡达，DDoS反射放大之SSDP攻击

4. Marek Majkowski, Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS