2017-08-02 17:48:32
阅读：547次
点赞(0)
收藏
来源： blog.cloudflare.com
作者：興趣使然的小胃
译者：興趣使然的小胃
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
一、前言
上一个月，我们发表了一篇分析文章，与大家分享了常见的反弹式攻击的统计信息。当时SSDP攻击的平均流量大约为12 Gbps，被我们记录在案的规模最大的SSDP（Simple Service Discovery Protocol，简单服务发现协议）反弹式攻击有以下几点统计数据：
1、30 Mpps（每秒发送上百万个包）
2、80 Gbps（每秒发送数十亿个比特）
3、大约使用了94万个IP用于反弹攻击
几天以前，我们发现了一个规模异常巨大的SSDP放大攻击，再次刷新了这些记录。这次攻击值得好好深入研究一番，因为它的规模已经超过了100Gbps这个阈值。
整个攻击过程中，每秒发送的数据包走向大致如下图所示：
带宽占用情况如下图所示：
整个数据包洪泛攻击持续了38分钟。根据我们采样的网络数据流，我们发现这次攻击用到了93万个反弹服务器。我们估计在时长38分钟的攻击中，每个反弹服务器往Cloudflare发送了11.2万个数据包。
反弹服务器遍布全球，其中以阿根廷、俄罗斯以及中国的服务器占比最大。以IP数统计的话，反弹服务器在每个国家或地区的分布情况如下所示：
$catips-nf-ct.txt|uniq|cut-f2|sort|uniq-c|sort-nr|head 439126CN 135783RU 74825AR 51222US 41353TW 32850CA 19558MY 18962CO 14234BR 10824KR 10334UA 9103IT ... 反弹服务器所在的IP分布与ASN的规模成正比，这些服务器通常位于全世界最大的家用ISP（Internet Service Provider，互联网服务提供商）网络中，如下所示：$catips-nf-asn.txt|uniq|cut-f2|sort|uniq-c|sort-nr|head 3184054837#CNChinaUnicom 847814134#CNChinaTelecom 7230122927#ARTelefonicadeArgentina 238233462#TWChunghwaTelecom 195186327#CAShawCommunicationsInc. 194644788#MYTMNet 188093816#COColombiaTelecomunicaciones 1132828573#BRClaroSA 707010796#USTimeWarnerCableInternet 68408402#RUOJSC"Vimpelcom" 66043269#ITTelecomItalia 637712768#RUJSC"ER-TelecomHolding" ...
二、何为SSDP
攻击所用的报文为UDP报文，源端口为1900。SSDP协议使用的正是这个端口，而SSDP协议是UPnP的核心协议之一。UPnP是零配置（zero-configuration）网络协议的一种。大众使用的家庭设备一般都支持这个协议，以便用户的主机或手机能够轻松发现这些设备。当一个新的设备（比如说笔记本）加入到网络中时，它可以向本地网络查询特定设备是否存在，这些设备包括互联网网关、音频系统、TV或者打印机等。读者可以参考此处阅读UPnP与Bonjour的详细对比。
UPnP协议的标准化做的不尽如人意，在有关M-SEARCH请求报文的规范文档中，部分内容摘抄如下（这也是UPnP在探测设备时使用的主要方法）：
“当某个控制节点（control point）加入到网络中时，控制节点可以根据需要使用UPnP探测协议搜索网络中的其他设备。在搜索过程中，控制节点通过在保留地址及相关端口（239.255.255.250:1900）上广播请求来查找其他设备，所使用的搜索消息包含特定的模式，不同的设备或服务具有不同的类型和标识符”。
规范中关于M-SEARCH报文的应答有如下说明：
“为了能被网络搜索发现，目标设备应该向发起多播请求的源IP地址及端口发送单播UDP响应。如果M-SEARCH请求报文的ST头部字段以“ssdp:all”、“upnp:rootdevice”或者“uuid:”开头，后面跟着与设备相匹配的UUID信息，或者如果M-SERCH请求与设备支持的设备类型或服务类型相匹配，那么该设备就会应答M-SEARCH请求报文”。
这种策略在实际环境中能够正常工作。例如，我的Chrome浏览器经常会请求搜索智能电视：
$sudotcpdump-nieth0udpandport1900-A IP192.168.1.124.53044>239.255.255.250.1900:UDP,length175 M-SEARCH*HTTP/1.1 HOST:239.255.255.250:1900 MAN:"ssdp:discover" MX:1 ST:urn:dial-multiscreen-org:service:dial:1 USER-AGENT:GoogleChrome/58.0.3029.110windows这个报文被发往一个多播IP地址。监听这一地址的其他设备如果与报文头部中指定的ST（search-target，搜索目标）多屏幕类型设备相匹配，那么这些设备应该会响应这个请求报文。
除了请求具体的设备类型，请求报文中还可以包含两类“通用的”ST查询类型：
1、upnp:rootdevice：搜索root设备
2、ssdp:all：搜索所有的UPnP设备以及服务
你可以运行以下python脚本（在另一脚本的基础上修改而得），使用前面提到的这些ST查询类型来枚举网络中的设备列表：
#!/usr/bin/envpython2 importsocket importsys dst="239.255.255.250" iflen(sys.argv)>1: dst=sys.argv[1] st="upnp:rootdevice" iflen(sys.argv)>2: st=sys.argv[2] msg=[ 'M-SEARCH*HTTP/1.1', 'Host:239.255.255.250:1900', 'ST:%s'%(st,), 'Man:"ssdp:discover"', 'MX:1', ''] s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM,socket.IPPROTO_UDP) s.settimeout(10) s.sendto('\r\n'.join(msg),(dst,1900)) whileTrue: try: data,addr=s.recvfrom(32*1024) exceptsocket.timeout: break print"[+]%s\n%s"%(addr,data)在我个人的家庭网络中，我总共发现了两个设备：
$pythonssdp-query.py [+]('192.168.1.71',1026) HTTP/1.1200OK CACHE-CONTROL:max-age=60 EXT: LOCATION:http://192.168.1.71:5200/Printer.xml SERVER:NetworkPrinterServerUPnP/1.0OS1.29.00.4406-17-2009 ST:upnp:rootdevice USN:uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice [+]('192.168.1.70',36319) HTTP/1.1200OK Location:http://192.168.1.70:49154/MediaRenderer/desc.xml Cache-Control:max-age=1800 Content-Length:0 Server:linux/3.2UPnP/1.0Network_Module/1.0(RX-S601D) EXT: ST:upnp:rootdevice USN:uuid:9ab0c000-f668-11de-9976-000adedd7411::upnp:rootdevice三、防火墙配置不当
现在我们对SSDP的基本概念有了一定程度的了解，那么理解反弹式攻击也不是件难事了。我们可以使用两种方式发送M-SEARCH报文：
1、如前文所述，我们可以使用多播地址发送这个报文
2、使用普通单播地址上的启用UPnP/SSDP协议的主机
第二种方法也是行之有效的，例如，我们可以将我的打印机所在的IP地址作为目标：
$pythonssdp-query.py192.168.1.71 [+]('192.168.1.71',1026) HTTP/1.1200OK CACHE-CONTROL:max-age=60 EXT: LOCATION:http://192.168.1.71:5200/Printer.xml SERVER:NetworkPrinterServerUPnP/1.0OS1.29.00.4406-17-2009 ST:upnp:rootdevice USN:uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice现在问题已经变得非常明朗了：SSDP协议并没有检查请求报文是否来自于设备所在的那个网络。即便M-SEARCH报文来自于互联网，设备也会积极应答这个报文。如果防火墙配置不当，将1900这个UDP端口暴露在互联网中，那么这个端口就会成为UDP放大攻击的绝佳目标。
如果目标配置不当，我们的脚本就可以在互联网中畅通无阻：
$pythonssdp-query.py100.42.x.x [+]('100.42.x.x',1900) HTTP/1.1200OK CACHE-CONTROL:max-age=120 ST:upnp:rootdevice USN:uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice EXT: SERVER:TBS/R2UPnP/1.0MiniUPnPd/1.2 LOCATION:http://192.168.2.1:40464/rootDesc.xml四、报文放大
ST类型中，ssdp:all这个类型所造成的破坏更加明显，这个类型的响应报文体积上更为庞大：
$pythonssdp-query.py100.42.x.xssdp:all [+]('100.42.x.x',1900) HTTP/1.1200OK CACHE-CONTROL:max-age=120 ST:upnp:rootdevice USN:uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice EXT: SERVER:TBS/R2UPnP/1.0MiniUPnPd/1.2 LOCATION:http://192.168.2.1:40464/rootDesc.xml [+]('100.42.x.x',1900) HTTP/1.1200OK CACHE-CONTROL:max-age=120 ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1 USN:uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::urn:schemas-upnp-org:device:InternetGatewayDevice:1 EXT: SERVER:TBS/R2UPnP/1.0MiniUPnPd/1.2 LOCATION:http://192.168.2.1:40464/rootDesc.xml ...6moreresponsepackets....在这个特定的场景中，一个SSDP M-SEARCH报文就能触发8个响应报文。tcpdump结果如下所示：
$sudotcpdump-nien7host100.42.x.x-ttttt 00:00:00.000000IP192.168.1.200.61794>100.42.x.x.1900:UDP,length88 00:00:00.197481IP100.42.x.x.1900>192.168.1.200.61794:UDP,length227 00:00:00.199634IP100.42.x.x.1900>192.168.1.200.61794:UDP,length299 00:00:00.202938IP100.42.x.x.1900>192.168.1.200.61794:UDP,length295 00:00:00.208425IP100.42.x.x.1900>192.168.1.200.61794:UDP,length275 00:00:00.209496IP100.42.x.x.1900>192.168.1.200.61794:UDP,length307 00:00:00.212795IP100.42.x.x.1900>192.168.1.200.61794:UDP,length289 00:00:00.215522IP100.42.x.x.1900>192.168.1.200.61794:UDP,length291 00:00:00.219190IP100.42.x.x.1900>192.168.1.200.61794:UDP,length291这个目标完成了8倍的报文放大作用，以及26倍的带宽放大作用。不幸的是，这种情况对SSDP来说普遍存在。
五、IP地址欺骗
攻击所需的最后一个步骤就是欺骗存在漏洞的服务器，让它代替攻击者向目标IP发起洪泛攻击。为了做到这一点，攻击者需要在请求报文中使用源IP地址欺骗技术。
我们对此次攻击中使用的反弹式IP地址进行了探测。我们发现在92万个反弹IP中，只有35万个IP（约占38%）会响应我们的SSDP探测报文。
有响应的反弹IP节点中，平均每个节点发送了7个数据包：
$catresults-first-run.txt|cut-f1|sort|uniq-c|sed-s's#^\+##g'|cut-d""-f1|~/mmhistogram-t"ResponsepacketsperIP"-p ResponsepacketsperIPmin:1.00avg:6.99med=8.00max:186.00dev:4.44count:350337 ResponsepacketsperIP: value|--------------------------------------------------count 0|******************************23.29% 1|****3.30% 2|**2.29% 4|**************************************************38.73% 8|**************************************29.51% 16|***2.88% 32|0.01% 64|0.00% 128|0.00%响应报文平均大小为321字节（正负29字节）。我们的请求报文大小为110字节。
根据我们的测量结果，攻击者使用包含ssdp:all头部的M-SEARCH报文能够达到以下效果：
1、7倍的数据包放大效果
2、20倍的带宽放大效果
据此，我们可以推测出，生成43 Mpps/112 Gbps的攻击大概需要：
1、6.1 Mpps的伪造报文容量
2、5.6 Gbps的伪造报文带宽
换句话说，一个连接稳定的具备10 Gbps带宽的服务器就可以通过IP地址欺骗技术发起这种规模的SSDP攻击。
六、关于SSDP服务器的更多说明
根据我们对SSDP服务器的探测结果，我们从响应报文的Server头部中，梳理出最常见的几个设备信息，如下所示：
104833Linux/2.4.22-1.2115.nptlUPnP/1.0miniupnpd/1.0 77329System/1.0UPnP/1.0IGD/1.0 66639TBS/R2UPnP/1.0MiniUPnPd/1.2 12863Ubuntu/7.10UPnP/1.0miniupnpd/1.0 11544ASUSTeKUPnP/1.0MiniUPnPd/1.4 10827miniupnpd/1.0UPnP/1.0 8070LinuxUPnP/1.0Huawei-ATP-IGD 7941TBS/R2UPnP/1.0MiniUPnPd/1.4 7546Net-OS5.xxUPnP/1.0 6043LINUX-2.6UPnP/1.0MiniUPnPd/1.5 5482Ubuntu/lucidUPnP/1.0MiniUPnPd/1.4 4720AirTies/ASP1.0UPnP/1.0miniupnpd/1.0 4667Linux/2.6.30.9,UPnP/1.0,PortableSDKforUPnPdevices/1.6.6 3334Fedora/10UPnP/1.0MiniUPnPd/1.4 28141.0 2044miniupnpd/1.5UPnP/1.0 13301 1325Linux/2.6.21.5,UPnP/1.0,PortableSDKforUPnPdevices/1.6.6 843Allegro-Software-RomUpnp/4.07UPnP/1.0IGD/1.00 776Upnp/1.0UPnP/1.0IGD/1.00 675Unspecified,UPnP/1.0,Unspecified 648WNR2000v5UPnP/1.0miniupnpd/1.0 562MIPSLINUX/2.4UPnP/1.0miniupnpd/1.0 518Fedora/8UPnP/1.0miniupnpd/1.0 372TendaUPnP/1.0miniupnpd/1.0 346Ubuntu/10.10UPnP/1.0miniupnpd/1.0 330MF60/1.0UPnP/1.0miniupnpd/1.0 ...最常见的ST头部值如下所示：
298497upnp:rootdevice 158442urn:schemas-upnp-org:device:InternetGatewayDevice:1 151642urn:schemas-upnp-org:device:WANDevice:1 148593urn:schemas-upnp-org:device:WANConnectionDevice:1 147461urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1 146970urn:schemas-upnp-org:service:WANIPConnection:1 145602urn:schemas-upnp-org:service:Layer3Forwarding:1 113453urn:schemas-upnp-org:service:WANPPPConnection:1 100961urn:schemas-upnp-org:device:InternetGatewayDevice: 100180urn:schemas-upnp-org:device:WANDevice: 99017urn:schemas-upnp-org:service:WANCommonInterfaceConfig: 98112urn:schemas-upnp-org:device:WANConnectionDevice: 97246urn:schemas-upnp-org:service:WANPPPConnection: 96259urn:schemas-upnp-org:service:WANIPConnection: 93987urn:schemas-upnp-org:service:Layer3Forwarding: 91108urn:schemas-wifialliance-org:device:WFADevice: 90818urn:schemas-wifialliance-org:service:WFAWLANConfig: 35511uuid:IGD{8c80f73f-4ba0-45fa-835d-042505d052be}000000000000 9822urn:schemas-upnp-org:service:WANEthernetLinkConfig:1 7737uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000 6063urn:schemas-microsoft-com:service:OSInfo:1 ... 根据结果，存在漏洞的IP似乎都是未经保护的家用路由器。七、开放式SSDP已经成为突破口
为了能从互联网访问家用打印机而开放1900 UDP端口，这并不是件多么新奇的事情，但并不是个好主意。早在2013年，已经有研究结果指出了相关问题的存在。
SSDP的作者显然没有考虑UDP报文放大攻击可能造成的破坏性。人们已经提了若干个建议，以便在未来安全地使用SSDP协议，如下：
1、SSDP的作者应该明确真实世界中使用单播地址发起M-SEARCH查询报文的必要性。根据我的理解，只有在本地局域网中以多播方式查询时M-SEARCH报文才有实际意义。
2、单播形式的M-SEARCH应该被废弃，或者在查询速率上有所限制，与DNS响应速率限制方案类似。
3、M-SEARCH响应报文只能投递到本地网络中。发往外网的响应报文不仅意义不大，而且容易存在漏洞。
与此同时，我们有如下提议：
1、网络管理员应当确认防火墙会阻拦使用UDP 1900端口的入站请求。
2、互联网服务商绝对不应该允许IP地址欺骗技术横行其道。IP地址欺骗技术是这个问题的根本原因，读者了解臭名昭著的BCP38就能理解这一点。
3、互联网服务商应该允许他们的客户使用BGP Flowspec功能来限制从来自于UDP 1900源端口的入站流量。
4、互联网服务商应该在内部收集netflow协议样本。我们需要使用netflow来识别发起攻击的真正来源。通过netflow，我们可以快速得出问题的答案，类似问题包括“哪些客户向1900端口发送了6.4Mpps的网络流量？”等。由于隐私保护问题，我们建议服务商在隐私保护前提下尽可能地收集netflow样本数据，比如6.4万个报文中抽样1个报文来收集信息。这种采样频率对跟踪DDoS而言已经足够，同时也能保留单个客户的隐私信息。
5、开发者在没有考虑UDP报文放大问题时，不要过于着急推出自己的UDP协议。UPnP协议应当经过适当的标准化和审查。
6、我们倡导终端用户使用如上脚本在他们的网络中扫描支持UPnP的设备，然后决定哪些设备可以连接互联网。
此外，我们推出了一个在线检查网站。如果你想知道你的公共IP地址是否暴露存在漏洞的SSDP服务，你可以访问此链接进行检测。
令人遗憾的是，此次攻击中我们看到大量路由器来自于中国、俄罗斯以及阿根廷，我们对这些地方的互联网状况不是特别了解。
八、总结
我们的客户能够完全免疫此类SSDP攻击以及其他的L3放大攻击，我们的基础设施足以抵御此类这些攻击，客户不需要做特别的操作。不幸的是，对其他互联网公众而言，这种大规模的SSDP攻击可能是一个严峻的问题。我们应该建议ISP在内部网络中禁用IP伪装技术，提供BGP Flowspec功能，配置netflow数据收集选项。
感谢Marek Majkowski以及Ben Cartwright-Cox的辛勤劳动成果。
本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。
原文链接：https://blog.cloudflare.com/ssdp-100gbps
