DDoS-Incident-Response - Ein Bericht von der Front

Intro

Im Juni hatten wir mit einem DDoS-Vorfall zu tun, der unserem Kunden schon mehrere Tage lang massiv Probleme bereitete. Eine Analyse unserseits zeigte, dass der Angreifer über ein hohes Skill-Level verfügte und mit weiteren Angriffen zu rechnen ist. Wir übernahmen das Incident-Response-Handling und die Sofortabwehr, mit dem Ziel, die ECommerce-Plattform zu einem Cloudanbieter mit automatisiertem Schutz zu migrieren. In der zeit unseres Incident-Handlings kam es zu keinen weiteren nennenswerten Störungen, nach 5 Tagen war das Ziel erreicht, und die Angriffe wurden durch die Mitigationslösung abgewehrt.

Tag 0

Mitte Juni erreichte uns ein Hilferuf eines Kunden: die ECommerce-Plattform wurde mittels einer niederschwelligen DDoS-Attacke angegriffen, das Problem wäre eigentlich unter Kontrolle, ob wir uns das Ganze aber mal ansehen könnten.

Wir bekamen zügig die angefragten Logfiles der Loadbalancer, spielten diese in unsere Analyseplattform ein und begannen nach einem Gespräch mit den beteiligten Technikern mit der Analyse.

Unsere erste Vermutung deutete in Richtung Botnet-Angriff, da an der ersten Welle knapp 400 weltweit verteilte IPs beteiligt waren, die die Suchfunktion mit einem Random-String a la /katalogsuche?q=RANDOMSTRING angriffen.

Nachdem wir die Angriffs-IPs extrahiert und näher untersucht hatten, ergab sich aber ein anderes Bild: wir hatten es mit einem versierten Angreifer zu tun, der definitiv seine Hausaufgaben gemacht hatte.

Folgende Punkte ließen uns nach der Erstanalyse auf einen fachlich versierten Angriff schließen (Level 5 nach DRS: Advanced Attack); eine Einschätzung, die sich in den folgenden Tagen noch erhärten würde:

• der Angreifer verfügte über ein ausgeklügeltes Angriffstool, mitdem er die Requests/Sekunde genau einstellen konnte, egal wie viele "Bots" benutzt wurden (Flatline-Angriffe)
• die jeweils "aktiven" IPs waren nur für max 30 Sekunden aktiv und wechselten sich ständig ab; dies erschwerte die Analyse, sodass man ein komplettes Lagebild über die beteiligten IPs erst nach einiger Zeit erhielt
• die ersten Wellen liefen parallelisiert über das TOR-Netzwerk, wobei sich die IPs ständig änderten
• der Angreifer sorgte zwar für eine Störung im Shopbereich, ging mit seinem Angriff aber nie soweit, den Shop komplett lahmzulegen, wohl in der Hoffnung, etwaige Monitoringsysteme nicht ansprechen und den Angriff unbemerkt zu lassen
• nach manuellen Mitigationen (Blocken von IPs, Sperren von URLs) änderte der Angreifer seine Methoden und angreifenden IPs während des Angriffs, war also auf Gegenmaßnahmen vorbereitet und hatte seinerseits weitere Angriffspunkte verfügbar
• der Angreifer stoppte die Angriffe häufig innerhalb einer Minute nach einer erfolgreichen Mitigation unsererseits
• der Angreifer hatte Zugriff auf ein gesäubertes Botnet; ein Eindringen unsererseits war nicht möglich; alle Sicherheitslücken waren geschlossen
• der Angreifer konnte seine Angriffe auf einzelne Regionen beschränken
• der Angreifer konnte seine Angriffstools/IPs innerhalb kurzer Zeit umstellen (TOR -> Botnet -> manuelle Ressourcen)
• der Angreifer hatte innerhalb von 24h Zugriff auf Ressourcen aus Regionen, die wir nicht blocken konnten (gehackte Server in der Region DACH/EU)
• der Angreifer brachte immer nur gerade soviel Ressourcen zum Einsatz, die zur Zielerreichung notwendig war, und zeigte nie sein gesamtes Potential/Arsenal
• der Angreifer setze in den letzten Phasen "Smokescreening" ein, d.h. er erzeugte soviel Noise, dass das kleine Signal von Tests und echten Angriffen schwierig zu finden war

Da wir die ersten beiden Angriffswellen aus dem TOR-Netzwerk verorteten, übergaben wir auch eine entsprechende Konfiguration, um als Erstmaßnahme am Loadbalancer alle TOR-IPs zu sperren. Wir informierten den Kunden, dass wir von einem nicht-trivialen Angriff ausgingen und er sich darauf einstellen muss, dass im Worst Case die Angriffe aus anderen Bereichen des Internet weitergingen.

Tag 1

Um kurzfristig die Abwehr zu koordinieren und so schnell wie möglich eine Mitigationsstrategie zu erarbeiten, übernahmen wir das Incident-Response-Handling und bauten über die Supportabteilung des Rechenzentrums, in dem die Server standen, eine 24/7 Eskalationskette auf, um bei etwaigen Ausfällen sofort die entsprechenden Personen alarmieren zu können.

Des weiteren etabalierten wir einen Chatroom, indem wir uns parallel austauschten, da die Koordination über Email-Pingpong nicht funktioniert.

Alle weiteren Schritte und Strategien wurden in enger Absprache mit dem Kunden und seinem RZ-Betreiber getroffen und beinhalteten im wesentlichen 2 Milestones:

1. Implementierung einer kurzfristigen Angriffsabwehr in den Loadbalancern (nginx), basierend auf GeoIP/IP-Blocks, um instantan und flexibel auf sich ändernde Angriffe reagieren zu können (24h)
2. Evaluierung einer mittelfristigen Mitigationslösung, entweder cloudbasiert oder auf Basis einer WAF, die Module zur DDoS-Abwehr gegen Layer-7-Angriffe bereithält, und DNS-Schwenk dorthin

Als Zeitansatz wurden max. 5 Tage geplant.

Um Milestone 1 zu erreichen, lenkten wir die Access-Logs von den Loadbalancern zu unserer Analyseplattform um. Dadurch waren wir in der Lage, den Angriffen in Echtzeit zuschauen und diese analysieren zu können, um Gegenmaßnahmen einzuleiten.

Sichtbarkeit und Analysemöglichkeit sind elementare Voraussetzungen bei der Abwehr von DDoS-Angriffen und zentrale Punkte unseres DDoS-Abwehr-Toolkits.

Bis zum frühen Nachmittag war Ruhe, danach gingen die Angriffe weiter, aber nur vereinzelt, immer nur von wenigen IPs aus einer Region, immer nur für einige Minuten, ohne aber Ausirkungen auf den Shopbetrieb zu haben.

Die IPs kamen nicht nicht mehr aus dem TOR-Netzwerk, sondern aus Taiwan und Indonesien.

Wir gingen davon aus, dass der Angreifer einzelne Tests fuhr um zu sehen, von wo und wie er seine Angriffe fortsetzen kann; wir rechneten mit verschiedenen Arten von Botnetz-Angriffen.

Parallel machten sich 2 zeroBS - Mitarbeiter daran, die IPs zu analysieren und die Mitigationsstrategien für Milestone 2 zu testen.

Tag 2

Am späten Nachmittag des 2. Tages gingen die echten Angriffe weiter. Diesmal nicht nur Testangriffe, sondern schon etwas mehr Dampf, beteiligt waren knapp 200 IPs, die alle Brasilien stammten. Da der Angriff den Shopbetrieb nicht beeinträchtigte, ließen wir ihn laufen, um ggfs wertvolle Informationen über die verwendeten IPs zu sammeln und bereiteten einen GeoIP-Block für Brasilien vor. Der Angriff zog sich über mehrere Stunden hin, während dieser Zeit wechselten mehrmals die Methoden, und mit der letzten Welle fand der Angreifer eine Methode, die den Shop gefährdeten, also sperrten wir BR komplett aus.

Tag 3

Anhand der IPs, die wir aus den Angriffswellen extrahierten, analysierten wir, WAS denn da überhaupt angreift. Wir sahen auch hier wieder das Pattern, dass die Bots jeweils immer nur kurz wirklich aktiv waren und sich in den jeweiligen Angriffswellen abwechselten. Insgesamt waren 300 IPs beteiligt, die alle eins gemeinsam hatten: Mikrotik-Router.

Nach kurzer Zeit wurde unser Analyseteam fündig: eine Sicherheitslücke und ein zugehörender Exploit aus dem Oktober 2018 deuteten auf ein Botnetz aus ungepatchten Routern hin.

Ein Botnetz, das sich so steuern lässt, dass es nur aus bestimmten Regionen angreift, das seinem Botmaster Rückmeldung über Erfolg/Mißerfolg des Angriffs gibt, sodass dieser sofort auf Gegenmaßnahmen reagieren kann, war schon etwas ungewöhnlich. Der nächste Fund aber, nämlich ... NICHTS ... bestätigte unsere Annahmen eines "Advanced Attackers". Egal auf welche Weise unser Analyseteam versuchte, auf einen der beteiligten Router zuzugreifen und evtl. einen Bot für ein Reverse-Engineering zu fangen: alle Lücken waren geschlossen, derjenige, der das Botnetz betreibt, hatte fein säuberlich hinter sich aufgeräumt und einen weiteren Zugriff von außen gesperrt. Chapeau!

Wir wussten also jetzt, dass auf der anderen Seite jemand saß, der weiß, was er tut. Und das wir uns beeilen müssen, um auf eine automatisierte Mitigation zu schwenken. Also begannen wir parallel, 3 verschiedene, cloudbasierte Lösungen zu testen.

Da wir mit weiteren Angriffen aus wechselnden Regionen rechnen mussten, entschieden wir uns statt des Blacklist für einen Whitelist-Ansatz, also anstatt immer nachzuziehen und einzelne Länder zu blocken, bekamen wir eine Liste mit Ländern, die nach Möglichkeit gehen sollten, im Zweifel aber geblockt werden können, und eine Liste mit Ländern, aus denen heraus das Kerngeschäft stattfindet, bei denen ein GeoIP-Block nicht möglich ist.

Und wir mussten nicht lange warten. Aus folgenden Regionen liefen ca 24h verschiedenen wechselnde Angriffe, die jeweils erfolgreich durch den GeoIP-Block automatisch abgewehrt wurden:

• Indien
• Indonesien
• Russland
• Brasilien
• Taiwan
• Korea

Tag 4

Im Laufe des 4 Tages liefen die Angriffe aus allen Regionen weiter. Wir gingen davon aus, dass der Angreifer wusste, dass seine Angriffe aktuell geblockt werden, er dieses Störfeuer aber benutzte, um uns etwas blind zu machen für seine Tests. Unsere Annahme war, dass der Angreifer, dem wir mittlerweile auf "Günther" getauft haben, seine möglichen Optionen testet und direkt von wenigen einzelnen IPs aus angreifen wird.

Eine weitere Achillesferse wurde am 4. Tag geschlossen: das RZ war gut gegen Volumenangriffe geschützt, aber die DNS-Infrastruktur war eher ungünstig aufgestellt. Hätte der Angreifer hier zugeschlagen, hätte es massive Probleme gegeben. Wir konnten unseren Kunden davon überzeugen, einen Fallback-DNS auf Anycast-Basis einzurichten, was auch sehr kurzfristig geschah.

Die Scheinangriffe liefen weiter, mittlerweile hatte "Günther" herausgefunden, dass er aus Finnland und Frankreich erfolgreich angreifen konnten, hatte hier aber nur einige wenige IPs zur Verfügung, die wir manuell jeweils innerhalb weniger Minuten nach Angriffsbeginn identifiziert und geblockt haben.

Der Kunde hatte sich nach efolgreichen Tests der Staging-Plattform für einen Mitigationsanbieter entschieden, der Wechsel über ein DNS-Forwarding dahin wurde am Abend des 4. Tages vorbereitet; die DNS-TTL für die gefährdeten Domains hatten wir schon am 1. Tag auf 300 Sekunden gesetzt.

Tag 5

Mit dem DNS-Schwenk der beteiligten Domains, und dem Schutz der Origin-IP durch Setzen entsprechender Firewallregeln, wurden die Angriffe durch den Mitigationsanbieter automatisiert abgewehrt. Sie liefen zwar noch eine Woche weiter, bildeten aber keine Gefahr mehr und wurden zu 100% geblockt.

Alle Beteiligten gingen wieder in den Normalbetrieb über und konnten die nächsten Nächte in Ruhe schlafen.

Lessons learned

• Sichtbarkeit ist das A und O bei der Analyse und Abwehr
• die Analysen des Angriffs/Angreifers sind immer sinnvoll und bestimmen die weiteren Schritte
  -> kein Headles-Chicken-Problem
• das DDoS-Abwehr-Toolkit hat sich ein weiteres mal bewährt, die einzelnen Schritte auf jeden Fall empfehlenswert
• Vorbeugen und Testen spart eine Menge Stress, Aufwand und Umsatzverluste
• alle DDoS-Angriffsvektoren sind zu betrachten und hinsichtlich Auswirkungen abzuwägen (Volumenangriffe, Layer-7-Angriffe, Angriffe auf DNS)

Epilog

Wir möchten allen Beteiligten Technikern, Entscheidern und Mitarbeitern auf Seiten der Ecommerce-Plattform und des Rechenzentrums für die schnelle und souveräne Abarbeitung des Vorfalls danken. Die zwei Kisten CyBier, die wir persönlich vorbeibringen werden, sind redlich verdient.

Unsere Analyseplattform ist eine Weiterentwicklung der "Logstation", die bereits 2015 vorgestellt wurde und mittlerweile recht kampferprobt und robust bei DDoS-Angriffen arbeitet. Schließlich hat sie die ersten Mirai-Angriffe aus dem Sommer 2016 miterlebt und überlebt.

---

---

Fragen? Kontakt: info@zero.bs