Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

0
0
【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

2017-08-02 17:48:32

阅读:547次
点赞(0)
收藏
来源: blog.cloudflare.com





【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

作者:興趣使然的小胃





【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

译者:興趣使然的小胃

预估稿费:200RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


一、前言

上一个月,我们发表了一篇分析文章,与大家分享了常见的反弹式攻击的统计信息。当时SSDP攻击的平均流量大约为12 Gbps,被我们记录在案的规模最大的SSDP(Simple Service Discovery Protocol,简单服务发现协议)反弹式攻击有以下几点统计数据:

1、30 Mpps(每秒发送上百万个包)

2、80 Gbps(每秒发送数十亿个比特)

3、大约使用了94万个IP用于反弹攻击

几天以前,我们发现了一个规模异常巨大的SSDP放大攻击,再次刷新了这些记录。这次攻击值得好好深入研究一番,因为它的规模已经超过了100Gbps这个阈值。

整个攻击过程中,每秒发送的数据包走向大致如下图所示:


【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

带宽占用情况如下图所示:


【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量

整个数据包洪泛攻击持续了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的辛勤劳动成果。



【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量
【技术分享】如何利用SSDP协议生成100Gbps的DDoS流量
本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://blog.cloudflare.com/ssdp-100gbps

Viewing all articles
Browse latest Browse all 12749