Geekly Articles each Day

愚かなシンプルなDDoSプロトコル（SSDP）が100 Gbps DDoSを生成

5月に、最も人気のあるリフレクション攻撃に関する統計を共有しました 。 その後、平均的なSSDP攻撃のサイズは約12 Gb / sであり、反射を伴う最大のSSDP攻撃は次のとおりでした。


数日前、SSDPパケットの異常に大きな増加に気づいたとき、それはすべて変化しました。 これは、攻撃が100 Gb / sの象徴的なマイルストーンを超えたため、より徹底的な調査に値します。

パケット/秒グラフ：



バンドの使用：



バッチフラッドは38分間続きました。 データフローのサンプルから判断すると、930万のリフレクションサーバーが使用されました。 見積もりによると、各リフレクターはCloudflareに12万パケットを送信しました。

反射型サーバーは世界中に配置され、そのほとんどがアルゼンチン、ロシア、中国にありました。 国別の一意のIPアドレスは次のとおりです。

$ cat ips-nf-ct.txt|uniq|cut -f 2|sort|uniq -c|sort -nr|head
439126 CN
135783 RU
74825 AR
51222 US
41353 TW
32850 CA
19558 MY
18962 CO
14234 BR
10824 KR
10334 UA
9103 IT
...

ASNによるIPアドレスの配布は非常に一般的です。 これは、主に世界最大のホームインターネットプロバイダーと相関しています。

$ cat ips-nf-asn.txt |uniq|cut -f 2|sort|uniq -c|sort -nr|head
318405 4837 # CN China Unicom
84781 4134 # CN China Telecom
72301 22927 # AR Telefonica de Argentina
23823 3462 # TW Chunghwa Telecom
19518 6327 # CA Shaw Communications Inc.
19464 4788 # MY TM Net
18809 3816 # CO Colombia Telecomunicaciones
11328 28573 # BR Claro SA
7070 10796 # US Time Warner Cable Internet
6840 8402 # RU OJSC "Vimpelcom"
6604 3269 # IT Telecom Italia
6377 12768 # RU JSC "ER-Telecom Holding"
...

ただし、SSDPとは何ですか？


この攻撃は、ポート1900からのUDPパケットで構成されています。このポートは、 SSDPおよびUPnPによって使用されます。 UPnPは、構成または特別なサーバーなしでIPネットワークを作成するZeroconf （Zero Configuration Networking）プロトコルの1つです。 ほとんどの場合、ご使用のホームデバイスがサポートしているため、コンピューターや電話から簡単に見つけることができます。 新しいデバイス（ラップトップなど）が参加すると、インターネットゲートウェイ、オーディオシステム、テレビ、プリンターなどの特定のデバイスのローカルネットワークをポーリングできます。 詳細については、UPnPとBonjourの比較を参照してください。

UPnPはあまり標準化されていませんが、主な検出方法であるM-SEARCHフレームの仕様からの抜粋です。

ネットワークにチェックポイントが追加されると、UPnPディスカバリプロトコルにより、このチェックポイントはネットワーク上の目的のデバイスを検索できます。 これを行うには、デバイスまたはサービスの識別子のタイプに対応するテンプレートまたはターゲットを使用して、検索メッセージを予約済みのアドレスとポート（239.255.255.250:1900）にマルチキャストします。

M-SEARCHフレームへの回答：

検索クエリで検出するには、デバイスは、マルチキャストを使用してメッセージを送信した送信元IPアドレスとポートにユニキャストUDP応答を送信する必要があります。 M-SEARCHリクエストのs-headerフィールドが「ssdp：all」、「upnp：rootdevice」、「uuid：」、およびデバイスのUUIDと完全に一致するUUIDを示す場合、またはM-SEARCHリクエストが一致する場合、回答が必要です。デバイスのタイプまたはデバイスがサポートするサービスのタイプ。

したがって、実際に機能します。 たとえば、私のChromeブラウザーは、私が理解しているように、スマートテレビを定期的にポーリングします。

$ sudo tcpdump -ni eth0 udp and port 1900 -A
IP 192.168.1.124.53044 > 239.255.255.250.1900: UDP, length 175
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: Google Chrome/58.0.3029.110 Windows

このフレームはマルチキャストIPアドレスに送信されます。 このアドレスでリッスンし、特定のマルチスクリーンタイプST （検索ターゲット）をサポートする他のデバイスが応答する必要があります。

特定のデバイスタイプのリクエストに加えて、2つの「一般的な」タイプのSTリクエストがあります。


これらのクエリをシミュレートするには、次のようなPythonスクリプトを実行できます（ この作業に基づいて） 。

 #!/usr/bin/env python2 import socket import sys dst = "239.255.255.250" if len(sys.argv) > 1: dst = sys.argv[1] st = "upnp:rootdevice" if len(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) ) while True: try: data, addr = s.recvfrom(32*1024) except socket.timeout: break print "[+] %s\n%s" % (addr, data)

2つのデバイスがホームネットワークに応答しています：

 $ python ssdp-query.py [+] ('192.168.1.71', 1026) HTTP/1.1 200 OK CACHE-CONTROL: max-age = 60 EXT: LOCATION: http://192.168.1.71:5200/Printer.xml SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009 ST: upnp:rootdevice USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice [+] ('192.168.1.70', 36319) HTTP/1.1 200 OK Location: http://192.168.1.70:49154/MediaRenderer/desc.xml Cache-Control: max-age=1800 Content-Length: 0 Server: Linux/3.2 UPnP/1.0 Network_Module/1.0 (RX-S601D) EXT: ST: upnp:rootdevice USN: uuid:9ab0c000-f668-11de-9976-000adedd7411::upnp:rootdevice

ファイアウォール


SSDPの基本を理解したので、リフレクション攻撃の本質を理解するのは簡単です。 M-SEARCHフレームを配信するには、実際には2つの方法があります。


2番目の方法も機能します。 プリンターのIPアドレスを具体的に指定できます。

 $ python ssdp-query.py 192.168.1.71 [+] ('192.168.1.71', 1026) HTTP/1.1 200 OK CACHE-CONTROL: max-age = 60 EXT: LOCATION: http://192.168.1.71:5200/Printer.xml SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009 ST: upnp:rootdevice USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice

現在、問題は容易に理解されています。SSDPは、メッセージの送信者がデバイスと同じネットワーク上にあるかどうかをチェックしません。 インターネットからのM-SEARCHリクエストに喜んで応答します。 ポート1900が外部に対して開かれている場合は、わずかに誤ったファイアウォール設定のみが必要です。これがUDPフラッディングを増やすための理想的なターゲットです。

不正なファイアウォール構成を使用してスクリプトにこのようなターゲットを指定すると、インターネット経由で正常に機能します。

 $ python ssdp-query.py 100.42.xx [+] ('100.42.x.x', 1900) HTTP/1.1 200 OK CACHE-CONTROL: max-age=120 ST: upnp:rootdevice USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice EXT: SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2 LOCATION: http://192.168.2.1:40464/rootDesc.xml

パケット乗算


ただし、 ssdp:all STが最も大きな害を及ぼします。 彼の答えははるかに大きい：

 $ python ssdp-query.py 100.42.xx ssdp:all [+] ('100.42.x.x', 1900) HTTP/1.1 200 OK CACHE-CONTROL: max-age=120 ST: upnp:rootdevice USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice EXT: SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2 LOCATION: http://192.168.2.1:40464/rootDesc.xml [+] ('100.42.x.x', 1900) HTTP/1.1 200 OK 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/R2 UPnP/1.0 MiniUPnPd/1.2 LOCATION: http://192.168.2.1:40464/rootDesc.xml ...   6  ....

この特定のケースでは、単一のM-SEARCH SSDPパケットが応答で8パケットを引き起こしました。 tcpdumpで表示：

$ sudo tcpdump -ni en7 host 100.42.xx -ttttt
00:00:00.000000 IP 192.168.1.200.61794 > 100.42.xx1900: UDP, length 88
00:00:00.197481 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 227
00:00:00.199634 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 299
00:00:00.202938 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 295
00:00:00.208425 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 275
00:00:00.209496 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 307
00:00:00.212795 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 289
00:00:00.215522 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 291
00:00:00.219190 IP 100.42.xx1900 > 192.168.1.200.61794: UDP, length 291

ターゲットは、パケットの8倍の乗算とトラフィックの26倍の乗算を実行しました。 残念ながら、これはSSDPの典型的なケースです。

IPスプーフィング


攻撃を実行するために必要な最後の手順は、脆弱なサーバーに、攻撃者ではなく被害者のアドレスに応答パケットを送信させることです。 これを行うには、攻撃者はリクエストで送信者のIPアドレスを偽造する必要があります。

前述の100 Gb / s攻撃で使用されたリフレクターのIPアドレスをポーリングしました。 SSDPトライアルリクエストに応答するのは、92万件のアドレスのうち、わずか35万件（35％）であることが判明しました。

トライアルリクエストに回答した人に平均7パケットを送信しました。

$ cat results-first-run.txt|cut -f 1|sort|uniq -c|sed -s 's#^ \+##g'|cut -d " " -f 1| ~/mmhistogram -t "Response packets per IP" -p
Response packets per IP min:1.00 avg:6.99 med=8.00 max:186.00 dev:4.44 count:350337
Response packets per IP:
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%

要求パケットのサイズは110バイトでした。 応答パケット-平均321バイト（±29バイト）。

私たちの測定によると、 ssdp:all M-SEARCHを使用して、攻撃者は以下を取得できます。


次を使用して、1秒あたり4,300万パケットと112 Gb / sの攻撃が開始されたと推定できます。


言い換えれば、IP改ざんが可能な1台の適切に接続された10 Gb / sサーバーは、重大なSSDP攻撃を引き起こす可能性があります。

SSDPサーバーの詳細をご覧ください。


脆弱なSSDPサーバーをポーリングしたため、最も一般的なServerヘッダー値を表示できます。

104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
77329 System/1.0 UPnP/1.0 IGD/1.0
66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2
12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
10827 miniupnpd/1.0 UPnP/1.0
8070 Linux UPnP/1.0 Huawei-ATP-IGD
7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4
7546 Net-OS 5.xx UPnP/1.0
6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5
5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4
4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0
4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4
2814 1.0
2044 miniupnpd/1.5 UPnP/1.0
1330 1
1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00
776 Upnp/1.0 UPnP/1.0 IGD/1.00
675 Unspecified, UPnP/1.0, Unspecified
648 WNR2000v5 UPnP/1.0 miniupnpd/1.0
562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0
518 Fedora/8 UPnP/1.0 miniupnpd/1.0
372 Tenda UPnP/1.0 miniupnpd/1.0
346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0
330 MF60/1.0 UPnP/1.0 miniupnpd/1.0
...

最も一般的なSTヘッダー値：

298497 upnp:rootdevice
158442 urn:schemas-upnp-org:device:InternetGatewayDevice:1
151642 urn:schemas-upnp-org:device:WANDevice:1
148593 urn:schemas-upnp-org:device:WANConnectionDevice:1
147461 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
146970 urn:schemas-upnp-org:service:WANIPConnection:1
145602 urn:schemas-upnp-org:service:Layer3Forwarding:1
113453 urn:schemas-upnp-org:service:WANPPPConnection:1
100961 urn:schemas-upnp-org:device:InternetGatewayDevice:
100180 urn:schemas-upnp-org:device:WANDevice:
99017 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:
98112 urn:schemas-upnp-org:device:WANConnectionDevice:
97246 urn:schemas-upnp-org:service:WANPPPConnection:
96259 urn:schemas-upnp-org:service:WANIPConnection:
93987 urn:schemas-upnp-org:service:Layer3Forwarding:
91108 urn:schemas-wifialliance-org:device:WFADevice:
90818 urn:schemas-wifialliance-org:service:WFAWLANConfig:
35511 uuid:IGD{8c80f73f-4ba0-45fa-835d-042505d052be}000000000000
9822 urn:schemas-upnp-org:service:WANEthernetLinkConfig:1
7737 uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000
6063 urn:schemas-microsoft-com:service:OSInfo:1
...

脆弱なIPアドレスは、主にホームルーターに属しているようです。

Open SSDPは脆弱性です


言うまでもなく、インターネットから自宅のプリンターまたは他のデバイスへの1900 / UDPインバウンドトラフィックを許可することはお勧めできません。 この問題は、少なくとも2013年1月から知られています。


SSDPの作成者は、UDPの可能性をパケットマルチプライヤとして明確に考えていませんでした。 将来SSDPを使用するための明確なガイドラインがいくつかあります。


同時に、以下をお勧めします。


さらに、オンライン検証用のWebサイトを作成しました。 パブリックIPアドレスに脆弱なSSDPサービスがあるかどうかを確認する場合は、以下を確認してください。


残念ながら、この攻撃で使用された保護されていないルーターのほとんどは、インターネットプロバイダーの速度で歴史的に有名ではない中国、ロシア、アルゼンチンにあります。

まとめ


Cloudflareクライアントは、SSDP攻撃や他のL3乗算攻撃から完全に保護されています。 これらの攻撃はCloudflareインフラストラクチャによく反映されており、追加のアクションは不要です。 ただし、SSDPのサイズを増やすことは、他のインターネットユーザーにとって深刻な問題になる可能性があります。 ISPに対して、ネットワークでのIPスプーフィングの禁止、BGP flowspecサポートの有効化、ネットワークフロー収集（netflow）のセットアップを促す必要があります。

この記事は、Marek MajkowskiとBen Cartwright-Coxが共同で作成しました。

Source: https://habr.com/ru/post/J332812/

More articles:


All Articles