Skip to content

Angriffe auf TCP/IP (10) - DDoS-Angriffe aus dem IoT (2)

Die DDoS-Angriffe durch das Mirai-Botnet haben 2016 zuvor ungeahnte Ausmaße angenommen. Grund genug, mal einen genaueren Blick auf Mirai zu werfen.

Mirai unter der Haube

Verschiedene Forscher haben die von Mirai durchgeführten Angriffe sowie den zuerst auf Hackforums.net und kurz darauf auf GitHub veröffentlicht Mirai-Sourcecode untersucht, darunter u.a. welche von F5 und Imperva. Aus diesen und meinen eigenen Untersuchungen stammen die folgenden Informationen.

Mirai kann Angriffe sowohl auf den Netzwerkschichten als auch auf der Anwendungsschicht (HTTP Floods) ausführen. Auf den Netzwerkschichten kommen weitgehend die üblichen DDoS-Angriffe über Flooding zum Einsatz: SYN- und ACK-Floods, STOMP (Simple Text Oriented Message Protocol) Floods, DNS Floods und UDP Floods.

Auffallend ist, dass für DNS-Angriffe die zwar schon zuvor beobachtete, aber wenig genutzte "DNS Water Torture"-Technik zum Einsatz kommt. Außerdem gibt es auf der Netzwerkschicht noch die bisher noch nicht beobachteten Flood-Angriffe mit GRE-Paketen.

DNS-Wasserfolter

Bei der "DNS Water Torture" lässt der Bot den rekursiven Nameserver seines ISP die Hauptarbeit für den Angriff auf die autoritativen Nameserver des Angriffsziels machen.

Der Bot sendet eine wohlgeformte DNS-Anfrage nach dem Domain-Namen des Ziels zwecks Auflösung an den Nameserver des ISP. Eigentlich wäre die Namensauflösung kein Problem, die Domain existiert ja. Der Bot setzt vor den Domainnamen aber einen zufällig erzeugten Prefix, so dass der Nameserver des Angriffsziels die Adresse für z.B. poiuzt.name.example, lkjhgf.name.example, ... nennen soll.

Die Suche nach diesen nicht existierenden Namen dauert etwas, und die Menge der Anfragen führt dann dazu, dass der erste autoritative Nameserver nicht schnell genug antwortet. Die anfragenden Nameserver senden ihre Anfrage daher an den nächsten autoritativen Nameserver, der dann irgendwann ebenfalls überlastet ist und nicht rechtzeitig antwortet, so dass der nächste autoritative Nameserver an die Reihe kommt. So werden nach und nach alle autoritativen Nameserver überlastet, und legitime Anfragen können nicht mehr beantwortet werden - die Domain ist nicht mehr erreichbar.

GRE-Flooding

GRE (Generic Routing Encapsulation) ist ein Tunneling-Protokoll, dass eine Vielzahl von Netzwerkprotokollen in virtuelle Punkt-zu-Punkt-Verbindungen kapseln kann. Übertragen werden die GRE-Pakete über UDP. Die Forscher von F5 vermuten, dass GRE verwendet wird, weil sich darüber große Payloads übertragen lassen, die beim Angriffsziel zusätzliche Arbeit machen.

Außerdem enthalten: "cfnull" - ein nicht nutzbarer Angriff...

Zusätzlich zu diesen Angriffen ist in Mirai ein weiterer Angriff implementiert, der aber überhaupt nicht vom Code aufgerufen werden kann. Dieser "cfnull" genannte Angriff erfolgt auf der Anwendungsschicht und ist vergleichbar einem GET-/POST-Flooding, verwendet aber eine große POST-Payload von 80 MB zufällig erzeugter alphabetischer Strings. Das würde beim angegriffenen Webserver große Mengen Ressourcen verbrauchen.

... der aber schon auftrat?

Auch wenn Mirai keine Funktion besitzt, um diesen Angriff aufzurufen, wurde ein ähnlicher Angriff bereits beobachtet, und zwar von Cloudflare.

Dort ist man dazu übergegangen, bei Angriffen auf der Anwendungsschicht wie z.B. über HTTP nicht mit Gbps oder Tbps sondern mit HTTP Requests pro Sekunde zu rechnen. Teilweise wurden 1.75 Millionen HTTP Requests pro Sekunde (Mrps) beobachtet, aber diese Request waren i.A. mit ca. 121 Byte pro Request relativ kurz und kann nur auf 2 Gbps. Es wurde aber auch ein HTTP-basierter Angriff beobachtet, der 360Gbps erreichte. Er bestand aus GET- und POST-Requests mit großer Payload, siehe das Beispiel in Listing 1 für einen GET-Request.

GET /en HTTP/1.1

User-Agent: <ein String>

Cookie: <ein Cookie>

Host: server.example
Connection: close
Content-Length: 800000

a[]=&b[]=&a[]=&b[]=&a[]=&b[]=&a[]=&b[]=&a[]=&b[]=&a[]=&b[]=...
Listing 1: GET-Request mit großer Payload

Cloudflare geht davon aus, dass der Angriff nicht von einem Mirai-Botnet ausging. Die Ähnlichkeit mit dem von F5 beschriebenen "cfnull"-Angriff von Mirai ist aber auffallend.

Vor allem die Größe der Payload sowie ihr Aufbau passen eigentlich zu gut, um Zufall zu sein. Entweder gibt es also eine Mirai-Version, in der der "cfnull"-Angriff verwendet werden kann, und der Angriff auf Cloudflare geht doch auf das Konto eines Mirai-Botnets. Oder der Mirai-Entwickler hat den Angriff aus einem anderen DDoS-Tool übernommen und nicht mehr fertig implementiert, bevor er den Sourcecode veröffentlicht hat.

Soviel zu den DDoS-Angriffen von Mirai. In der nächsten Folge werfe ich einen Blick auf die Verbreitungsroutine des Bots.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Angriffe auf TCP/IP (11) - DDoS-Angriffe aus dem IoT (3)

Vorschau anzeigen
Die DDoS-Angriffe durch das Mirai-Botnet haben 2016 zuvor ungeahnte Ausmaße angenommen. Die DDoS-Angriffe des Botnets habe ich bereits beschrieben, in diese Folge geht es um die Verbreitungsroutinen von Mirai Die folgenden Informatione