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

mdns Highlighted Attack Attributes

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
mdns SVN flood

Ü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.

mdns attack

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.

mdns sample script usage
mdns sample script usage

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

mdns basic response

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.

mdns mitigation

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: