Eine englische Version dieses Artikels finden Sie hier
Intro
Vor circa 12 Monaten haben wir das Konzept des DDoS-RedTeamings entwickelt, um unseren Kunden mit bereits ein hohes Security Maturity Level noch besser auf Angriffe vorzubereiten.
Wir haben schnell bemerkt, dass wir genau zur richtigen Zeit damit angefangen haben, da auch die entsprechenden ThreatActors OSINT-Methoden in der Zielauswahl benutzen, um die wirklich spannenden und lohnenswerten Angriffspunkte zu identifizieren.
In den letzten Monaten hat die KillNet-Gruppe gezeigt, dass sie sich innerhalb kürzester Zeit vom Standard-Level mit meist harmlosen Angriffen auf Webseiten hin zu einer echten Bedrohung entwickelt hat. Killnet hat sich durch Training und Lernen in nur 2 Monaten in die Lage versetzt, echte Schäden anzurichten, indem sie Steuerbehörden, Businessportale, VPN/Accessgateways, Logistikunternehmen, Paymentprovider, OAuth-Provider etc erfolgreich angriffen und tagelange Betriebsunterbrechungen erzwangen.
Sinn und Zweck von DDoS-RedTeamings
Bei unseren Leistungsnachweisen gehts es um das grundsätzliche Funktionieren der DDoS-Abwehr. Die Angriffe finden unter in Laborbedingungen statt, da wir mit festgelegte Zielen, Drehbüchern und Abläufen arbeiten.
Beim RedTeaming sind wir grundsätzlich in der Auswahl der Ziele und Waffen frei. Es gibt einen Scope und einige wenige Eingeweihte, mit denen wir unsere potentiellen Ziele absprechen. Der Rest des Teams (SOC, NOC, Support, Operations etc) wissen nicht Bescheid.
Wir haben Kunden, die eine hybride Lösung zum Schutz vor Volumenangriffen im Einsatz haben, mit einer lokalen Appliance und manuellem BGP-Schwenk. Dort geht es darum, die Filter, Alarmierung und Workflows zu testen. Andere Kunden testen die Einstellungen ihrer WAF/Botnet-Abwehr bei Layer7-Angriffen.
Im Grunde geht es darum zu Testen, ob der DDoS-Schutz einem echten Angriff und Angreifer auch tatsächlich standhalten würden, wenn dieser etwas mehr Skills und Schlagkraft als ein Booter-Service hat.
Das Vorgehen
Beim RedTeaming geht es darum, tatsächliche Schwachpunkte zu finden.
Wir nutzen hierzu verschiedene OSINT-Techniken und Tools, um einen Überblick über die Infrastruktur zu erhalten und potentielle Angriffspunkte zu ermitteln. Diese können sehr individuell sein und geben uns einen sehr guten Eindruck über das Security-Maturity-Level.
RedTeamings können eine Woche dauern oder einen Monat, und wir haben auch kontinuierliche Tests bei Kundne etabliert. Sie beinhalten immer eine Aufklärungs/Recon-Phase, in der wir versuchen, potentielle Schwachpunkte zu identifizieren. Auch aus dieser Sicht ergibt sich ein Benefit für den Kunden, da er seine Infrastruktur mit der Hackerbrille sieht. Neben den betriebene Diensten und Applikationen schauen wir uns dabei auch die Upstream-Konnektivität, Peerings, Traceroutes usw an, um ggfs herauszufinden, mit welchem Schutzanbieter wir es zu tun haben.
Nach der Recon-Phase entwickeln wir einen Angriffsplan und führen verschiedene kleine Testangriffe durch.
Wir haben häufig Erfolg mit direkten Angriffen auf einzelne Dienste und mixen dabei mehrere Angriffsarten für maximalen Impact. So haben wir verschiedene, effektive Angriffsmethoden entwickelt, die bisher nicht ITW gesehen wurden, deren Details wir aber mit DDoS-Schutzanbietern teilen.
Bei der ersten Reihe Screenshots ist z.B. zu sehen, wie wir bei einem gezielten multiplen Angriff auf eine Applikation mit nur 6 Mbit Traffic die Filter überlisteten, und die Applikation zum Stillstand brachten.
Die zweite Reihe Screenhots zeigt einen Angriff mit ungewöhnlichen Protokollen (GRE/MPLS) gegen die Router-Infrastruktur eines Rechenzentrums, auf den die Anti-DDoS-Lösung nicht eingestellt war. Wir konnten mit 5 GB/s Angriffstraffic den 10 GB-Uplink so sehr stören, dass ein Großteil des normalen Traffics verloren ging, ohne dass der DDoS-Schutz darauf reagiert hat.
Wir können unseren eigenentwickelten Sensor Emox/GNA" dazu benutzen, den Traffic auf dem Ziel und damit die Qualität der DDoS-Schutzlösung zumessen. Vor allem geht es dabei um Reaktionszeit, Verhältnis Clean-Traffic zu Angriffstraffic, Finden von Schutzlücken und potentiell kritischer Protokolle.
Learnings und Ergebnisse
Bei einem RedTeaming weichen wir von den Standard-Angriffswegen eines Botnetzes ab und suchen gezielt nach Schwachstellen in Infrastruktur und Applikationen, die bisher nicht betrachtet wurden.
Die Kunden lernen dabei, ob es eventuell noch Schwachpunkte gibt, die bisher nicht betrachtet wurden, und unter welchen Annahmen diese ausnutzbar sind.
Mit einem RedTeaming lässt sich das Schutzniveau gegen gezielte Angriffe enorm erhöhen.
Wir haben weiterhin festgestellt, dass sich das Maturity-Level eines engagierten BlueTeams innert eines Jahres von einem leicht desaströsen Zustand (DRS Level 3 und weniger) auf ein sehr robustes Schutzniveau verbessern kann, wenn die Bedrohung und Verantwortung ernst genommen werden.
Beispiele
Nachfolgend weitere Beispiele aus einem RedTeaming und einem echten Angriffen, bei denen gezielet Angriffe auf neuralgische Punkte schwierig zu verteidigen waren und zu großen Problemen führten
1.
Ein Kunde hatte ein sehr gut aufgestellte Abwehr und gutem Team. Wir konnten maximal 30 Sekunden Downtime erzwingen, danach waren unsere Versuche jeweils abgewehrt. Der einzige Punkt, den wir nach Analyse der Infrastruktur als angreifbar fanden, war die DNS-Infrastruktur, die als Authoritative Server für mehrere tausend weitere Kundendomains fungierte; es gab nur 2 DNS-Server, und diese standen im gleichen Netzsegment. In einer Nacht um 3Uhr morgens griffen wir dann die DNS-Server mit einem Layer-7-Angriff an und zwangen sie in die Knie. Da der gesamge Ingress-Traffic die 1 GB/s - Marke nie überschritt und die Anfragen legitim waren, konnte der Volumenschutz diesen Angriff nicht "sehen", und er war erfolgreich. Der Schutz vor einem solchen Angriff ist im übrigen sehr einfach: "Fallback-DNS mit Anycast: eine einfache Methode zur Stärkung der DNS-Infrastruktur gegen DDoS-Angriffe"
2.
ECommerce-Unternehmen mit Umsätzen in 2stelligen Millionenbereich in einem stark umkämpften Marksegment. Die Gewinnung von Neukunden während Kampagnenzeiten ist extrem wichtig, dafür werden regelmäßig hohe Werbebudgets bereitsgestellt.
Ein gezielter Angriff auf die Nekunden-Registrierung kann diesem Unternehmen starke Verluste bescheren, ohne dass dieser Angriff sofort bemerkt wird. Man muss garnicht die Applikation großflächig stören; es reicht aus, den Prozess so sehr zu verlangsamen, dass sich kaum noch Neukunden anmelden. Das hat den Vorteil, dass das Monitoring dies ggfs nicht direkt mitbekommt und deswegen der Angriff unbemerkt bleibt.
Genau so einen Angriff haben wir bei einem Incidence-Reponse-Auftrag für einen Kunden gesehen. Der Angriff führte über 10 Tage lang zu einem Schaden von 30.000 Euro/Tag, bevor er überhaupt bemerkt wurde.
Fragen? Kontakt: info@zero.bs