Bedrohungsratgeber: mDNS-Reflection-DDoS-Angriffe

Autor: Wilber Mejia

Übersicht

Gegen Ende des 3. Quartals 2015 bemerkte das Akamai SIRT erstmals eine geringe Anzahl von DDoS-Angriffen, die über mDNS-fähige (Multicast Domain Name System) Geräte durchgeführt wurden. Ebenso wurde im März 2015 wurde auf die Gefahr hingewiesen, dass mDNS zunehmend als Vektor in DDoS-Reflection- und -Verstärkungsangriffen eingesetzt werden könnte.

Dieser Ratgeber erläutert das Konzept und die Techniken des mDNS-Reflection-Angriffsvektors und empfiehlt Maßnahmen zu seiner Abwehr. Möglich wird dieser Angriffsvektor erst durch die Verfügbarkeit von Quellgeräten, die das mDNS-Protokoll über Port 5353 im Internet freigeben.

Bis Oktober 2016 konnte Akamai sieben mDNS-DDoS-Angriffe auf Ziele in der Spiele- und Software/Technologie-Branche erkennen und erfolgreich abwehren. Bis jetzt ist offen, ob dieser Angriffstrend von Dauer sein wird. Diese Zweifel basieren auf einer Reihe von Eigenschaften, die bei realen Angriffen beobachtet wurden.

Zeitlicher Verlauf der Angriffe

Seit seinem ersten Auftreten im September 2015 wurde der mDNS-Angriffsvektor nur sporadisch eingesetzt. Wie der zeitliche Verlauf unten zeigt, vergingen etwa fünf Monate zwischen dem ersten und dem darauffolgenden Angriff. Dies lag vermutlich daran, dass die Angriffsskripte zunächst getestet wurden. Erst gegen Ende März bzw. Anfang April 2016 wurde der Angriffsvektor regelmäßiger eingesetzt. Die Angriffe mit mDNS als einzigem Vektor fielen jedoch bisher lange nicht so stark aus wie die mit anderen Reflection-Vektoren.

mDNS attack timeline

Eigenschaften eines Beispielangriffs

Im folgenden Abschnitt gehen wir auf einen Angriff ein, der 2016 stattfand. Die sieben bisher beobachteten Angriffe richteten sich alle gegen unterschiedliche Ziele.

  • Spitzenbandbreite: 2,9 Gbit/s
  • Pakete pro Sekunde in Spitzenzeiten: 465.200 Pakete pro Sekunde
  • Angriffsvektor: mDNS
  • Quellport: 5353 (mDNS)
  • Zielport: Willkürlich


17:07:32.071836 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

17:07:32.071857 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

17:07:32.071873 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _http._tcp.local., PTR _rfb._tcp.local. (143)

17:07:32.072187 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _ipp._tcp.local. (123)

17:07:32.072274 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

17:07:32.072279 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _pdl-datastream._tcp.local., PTR _printer._tcp.local., PTR _ipp._tcp.local., PTR _http._tcp.local. (143)

17:07:32.072295 IP Z.Z.Z.Z.5353 > X.X.X.X.80: 0*- 8/0/0 PTR _workstation._tcp.local., PTR _webdavs._tcp.local., PTR _webdav._tcp.local., PTR _smb._tcp.local., PTR _sftp._tcp.local., PTR _http._tcp.local., PTR _afpovertcp._tcp.local., PTR _device-info._tcp.local. (235)

17:07:32.072361 IP 193.147.161.117.5353 > X.X.X.X.80: 0*- 7/0/0 PTR _workstation._tcp.local., PTR _ftp._tcp.local., PTR _edcp._udp.local., PTR _afpovertcp._tcp.local., PTR _device-info._tcp.local., PTR _smb._tcp.local., PTR _http._tcp.local. (209)

Der zuletzt beobachtete mDNS-Angriff erfolgte am 27. Oktober 2016. Dabei handelte es sich um einen DDoS-Angriff mit mehreren kombinierten Vektoren, der aus SYN-Flood, UDP-Flood, UDP-Fragment, DNS-Flood und mDNS-Flood mit einem Spitzenwert von 41 Gbit/s bestand.

  • Startzeit des Vorfalls: 27. Oktober 2016 06:01:00 UTC
  • Spitzenbandbreite: 41 Gbit/s
  • Pakete pro Sekunde in Spitzenzeiten: 6 Millionen Pakete pro Sekunde
  • Angriffsvektor: SYN-Flood, UDP-Flood, UDP Fragment, DNS-Flood, mDNS-Flood
  • Quellport: Willkürlich
  • Zielport: Willkürlich

 

mDNS-Flood

 

06:05:36.522973 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

06:05:36.522976 IP X.X.X.X.53301 > X.X.X.X.80: Flags [R], seq 194989615, win 0, length 0

06:05:36.523036 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _http._tcp.local., PTR _device-info._tcp.local., PTR _smb._tcp.local. (144)

06:05:36.523040 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local. (97)

06:05:36.523102 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

06:05:36.523114 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (121)

06:05:36.523147 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 4/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (147)

06:05:36.523168 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _https._tcp.local., PTR _http._tcp.local. (119)

06:05:36.523221 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local. (97)

06:05:36.523285 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 3/0/0 PTR _workstation._tcp.local., PTR _ssh._tcp.local., PTR _sftp-ssh._tcp.local. (121)

06:05:36.523313 IP X.X.X.X.5353 > X.X.X.X.80: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _sftp-ssh._tcp.local. (102)

06:05:36.523322 IP X.X.X.X.58727 > X.X.X.X.80: Flags [R.], seq 2670641259, ack 2670641259, win 1400, length 0

 

SYN-Flood

6:01:35.894589 IP X.X.X.X.28970 > X.X.X.X.80: Flags [SEW], seq 4054777856, win 0, length 0

06:01:35.894639 IP X.X.X.X.1028 > X.X.X.X.80: Flags [SEW], seq 1405550592, win 0, length 0

06:01:35.894646 IP X.X.X.X.50021 > X.X.X.X.80: Flags [SEW], seq 3309240320, win 0, length 0

06:01:35.894655 IP X.X.X.X.40602 > X.X.X.X.80: Flags [SEW], seq 2493120512, win 0, length 0

06:01:35.894658 IP X.X.X.X.3847 > X.X.X.X.80: Flags [SEW], seq 1046675456, win 0, length 0

06:01:35.894658 IP X.X.X.X.21163 > X.X.X.X.80: Flags [SEW], seq 2160787456, win 0, length 0

 

UDP-Flood

06:08:36.313095 IP X.X.X.X.42862 > X.X.X.X.80: UDP, length 1

06:08:36.313768 IP X.X.X.X.648 > X.X.X.X.80: UDP, length 11

06:08:36.314002 IP X.X.X.X.60399 > X.X.X.X.80: UDP, length 6

06:08:36.322169 IP X.X.X.X.19246 > X.X.X.X.80: UDP, length 9

06:08:36.327485 IP X.X.X.X.22952 > X.X.X.X.80: UDP, length 11

06:08:36.327764 IP X.X.X.X.55095 > X.X.X.X.80: UDP, length 9

 

UDP-Fragment

06:06:43.088487 IP X.X.X.X > X.X.X.X: udp

06:06:43.088489 IP X.X.X.X > X.X.X.X: udp

06:06:43.088501 IP X.X.X.X > X.X.X.X: udp

06:06:43.088504 IP X.X.X.X > X.X.X.X: udp

06:06:43.088507 IP X.X.X.X > X.X.X.X: udp



DNS-Reflection

06:16:34.508072 IP Z.Z.Z.Z.53 > X.X.X.X.23130: 28397| 20/0/1 MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, TXT "v=spf1 ip4:x.x.x.x ip4:x.x.x.x ip4:X.X.X.X mx a:list.cpsc.gov -all", A x.x.x.x, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY, Type51, RRSIG[|domain]

06:16:34.508077 IP Z.Z.Z.Z.53 > X.X.X.X.23130: 28397| 20/0/1 MX hormel.cpsc.gov. 5, MX stagg.cpsc.gov. 5, TXT "v=spf1 ip4: X.X.X.X ip4:X.X.X.X ip4:X.X.X.X mx a:list.cpsc.gov -all", A x.x.x.x, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY, Type51, RRSIG[|domain]

06:16:34.508409 IP Z.Z.Z.Z.53 > X.X.X.X.10157: 32564 14/2/0 MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG,[|domain]

Überblick über den Angriff und mDNS

Multicast DNS (mDNS) ist ein vorgeschlagenes Standardprotokoll, das 2013 unter dem Namen RFC6762 veröffentlicht wurde. Es vereinfacht die Erkennung von Geräten und Diensten, idealerweise in kleinen Netzwerken, ohne oder mit nur geringer Beteiligung des Nutzers. Daher ist mDNS auch für den Einsatz als Komponente für Zero Configuration Networking (Zeroconf) geeignet. mDNS verfügt größtenteils über die gleiche Struktur wie reguläre DNS-Pakete, was wahrscheinlich einer der Gründe ist, warum das Protokoll so schnell als DDoS-Angriffsvektor genutzt wurde.

Ein simples Protokoll, über das ein Gerät einfach verbunden und sofort verwendet werden kann, ist natürlich mit einem gewissen Risiko verbunden. Chad Seaman erkannte eine Schwachstelle (VU#550620) in mDNS, bei der mDNS Antworten auf Abfragen zulässt, die von einer Quelle außerhalb des lokalen Netzwerks eingehen. Diese Antworten geben Informationen zum betroffenen Gerät frei, wie die darauf installierten Softwareprogramme und Services, sowie andere potenziell vertrauliche Informationen, wie Hostname, interne Netzwerkkonfigurationseinstellungen, Modellnummer usw. Ein Angreifer kann dieses Feedback nutzen, um einen beliebigen mDNS-Host, der über die internetfähige Schnittstelle auf Unicast-Abfragen antwortet, in DDoS-Reflection-/-Verstärkungsangriffen einzusetzen. Weitere Informationen zu dieser Schwachstelle finden Sie hier.

Bei einem ähnlichen Konzept sendet das von einem Angreifer generierte mDNS-Angriffsskript eine spezielle Unicast-Abfrage, um eine Antwort von mDNS-Geräten auszulösen. Die in RFC6763 definierte Abfrage zur Dienstaufzählung dient dazu, alle angekündigten Diensttypen in einem Netzwerk auszugeben. Das Angriffsskript generiert eine Nutzlastabfrage mit 46 Byte, wie in der folgenden Abbildung gezeigt, indem eine DNS-Abfrage für „_services._dns-sd._udp.local“ an den angreifbaren Host gesendet wird. Dabei sollen alle bekannten Dienste an die anfordernden Geräte zurückgegeben werden. Die entsprechenden Dienste können auch einzeln mit unterschiedlichen Antwortgrößen abgefragt werden, was Angreifern noch mehr Möglichkeiten eröffnet. Bei dieser Taktik wäre jedoch ein raffinierteres Angriffstool erforderlich, das diese zusätzlichen Angriffsnutzlasten auch problemlos in einem DDoS-Angriff einsetzen kann.

 

STRUKTUR EINES ANGRIFFSSKRIPTS FÜR UDP-NUTZLASTDATEN:

 

0000000: 0000 0000 0001 0000 0000 0000 095f 7365  ............._se

0000010: 7276 6963 6573 075f 646e 732d 7364 045f  rvices._dns-sd._

0000020: 7564 7005 6c6f 6361 6c00 000c 0001       udp.local.....

 

Die bisher in DDoS-Angriffen beobachteten mDNS-Antwortnutzlasten verfügten über eine beschränkte Größe. Die größte Nutzlast umfasste 428 Byte an Daten – 12 GByte weniger als ein einzelnes monlist-Datenantwortpaket bei NTP. Die typische beobachtete mDNS-Antwortgröße lag jedoch zwischen 100 und 200 Byte. Das bedeutet, dass der Vektor in der Regel eine maximale Verstärkung um das 4,35-Fache erreicht, wenn man nur die Anforderungsnutzlast von 46 Byte und die Antwortnutzlast von 200 Byte berücksichtigt.

Nutzungsbeispiel für Angriffsskripte und Signaturen

Das für mDNS erstellte Angriffsskript ist eine abgeänderte Version der zahlreichen Skripte, die derzeit für UDP-Reflection- und -Verstärkungsangriffe verfügbar sind. Seine Nutzung ähnelt ebenfalls der anderer Skripte: Es müssen einfach eine Ziel-IP, ein Zielport, eine Liste von mDNS-Geräten im Internet, Threads, die Paketdrosselungsrate und schließlich eine Angriffslaufzeit angegeben werden. Das Skript gibt sich dann als die Ziel-IP aus und sendet die schädlichen Abfragen mit 46 Byte (wie in der nachfolgenden Abbildung gezeigt) über tcpdump.

 

18:37:12.565541 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.565908 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.566332 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.566726 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567137 IP Z.Z.Z.Z.13763 > X.X.X.X.188.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567507 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.567895 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.568274 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.568672 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

18:37:12.569069 IP Z.Z.Z.Z.13763 > X.X.X.X.5353: 0 PTR (QM)? _services._dns-sd._udp.local. (46)

In unseren Labortests wurden die Abfragen an einen Linux-Server mit einem mDNS-Listener gesendet. Die allgemeine Antwort finden Sie in der folgenden Abbildung.

 

18:38:10.252994 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.253256 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.253694 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254043 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254394 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.254739 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255098 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255458 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.255823 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

18:38:10.256193 IP Z.Z.Z.Z.5353 > X.X.X.X.47070: 0*- 2/0/0 PTR _workstation._tcp.local., PTR _udisks-ssh._tcp.local. (104)

Am 4. November 2016 führte die Shadowserver Foundation einen mDNS-Scan (5353/UDP) durch, bei dem 526.245 eindeutige IPs auf eine mDNS-Abfrage antworteten. Die folgende Abbildung zeigt die 20 Länder und ASNs, bei denen auf Grundlage des Scans die höchste Anzahl von für die mDNS-Abfrage zugänglichen Geräten festgestellt wurde.

mDNS Source Distribution Countries
mDNS Source Distribution ASNs

Abwehr

Hierbei handelt es sich um ein Protokoll, das zur Verwendung innerhalb eines lokalen Netzwerks vorgesehen ist. Somit sollte kein Grund bestehen, warum mDNS-Geräte über das Internet zugänglich sind. Bei Bedarf bietet es sich an, eingehende Abfragen zu filtern und nur Abfragen von bekannten Quellen zuzulassen. Zudem kann ein IDS wie Snort eingesetzt werden, um solche Abfragen zu erkennen und die Nutzung Ihrer Geräte bei einem DDoS-Angriff weiter einzuschränken. Nachfolgend finden Sie ein Beispiel für eine Snort-Erkennungsregel.

 

alert udp $EXTERNAL_NET !5353 -> $HOME_NET 5353 \

(msg: "mDNS DDoS Abuse request"; \

flow: to_server; \

content: "|00 00 00 00 00 01 00 00 00 00 00 00 09 5f 73 65 72 76 69 63 65 73 07 5f 64 6e 73 2d 73 64 04 5f 75 64 70 05 6c 6f 63 61 6c 00 00 0c 00 01|"; dsize:46<>46; \

classtype:Reflection-Abuse; \

sid: 201600004; rev:1;)

Fazit

Der mDNS-Angriffsvektor wurde bis heute nur begrenzt eingesetzt. Wie SSDP basiert dieser Vektor üblicherweise hauptsächlich auf Geräten innerhalb eines Heimnetzwerks. Frühe Angriffe verfügten nur über relativ geringe Durchschlagskraft. Innerhalb unserer Abwehrplattform werden jedoch täglich Scanvorgänge des mDNS-Ports 5353 beobachtet. Es besteht die Gefahr, dass die Angriffe größer ausfallen, sobald die Anzahl spezifizierter Geräte steigt. Wie bei SSDP kommt es auch bei mDNS zu einer unnötigen Offenlegung des Protokolls. Es steht jedoch zu vermuten, dass mDNS keine große Zukunft als DDoS-Angriffsvektor hat, da ISPs beginnen, eine Filterung an diesem Port für private Nutzer implementieren. SSDP jedoch wird auch nach Jahren der Verwendung weiterhin täglich eingesetzt und kann für beträchtliche DDoS-Angriffe genutzt werden. Das bedeutet, dass mDNS-Angriffe möglicherweise in ihrem Umfang stark zunehmen könnten, bevor eine vorausschauende Filterung verfügbar ist.

Referenzen: