[Tarnkappe] DDoS: Github extrem unter Beschuss

Das Online-Portal für Software-Entwicklungsprojekte Github war am 28. Februar heftigsten DDoS-Angriffen ausgesetzt. Es war der stärkste DDoS-Angriff der Internet-Geschichte. Nie zuvor wurde ein derart massiver Angriff registriert. Dennoch überstand Github die Attacke, nach einigen Stunden war alles vorbei.

Für die Einen ist es ein Versionskontrolldienst, für die Anderen das geilste Sourcecode-Lager der Welt. Github war letzte Woche Mittwoch Woche heftigsten DDoS-Angriffen ausgesetzt. Seit Jahren nutzen Kriminelle DDoS-Angriffe, um Unternehmen gezielt zu schädigen oder zu erpressen. Ihre immense Schlagkraft macht sie zu einer unkalkulierbaren, ernst zu nehmenden Gefahr.
Ein DDoS-Angriff ist eine spezielle Art der Cyber-Kriminalität. Der Distributed-Denial-of-Service (DDoS) ist ein verteilter Denial-of-Service (DoS), der wiederum eine Dienstblockade darstellt. Diese liegt vor, wenn ein angefragter Dienst nicht mehr bzw. nur noch stark eingeschränkt verfügbar ist. Auslöser ist in den meisten Fällen eine Überlastung der IT-Infrastruktur. Angreifer nutzen diese Art der Cyber-Kriminalität, um von ungeschützten Unternehmen Lösegelder zu erpressen.



Während des Angriffes wurden innerhalb weniger Minuten um die 1,3 Terabit Daten pro Sekunde in Richtung Github-Server geschleudert. Doch der Angriff auf Github war anders gelagert als zum Beispiel der große Mirai-Botnet-Schlag von 2016, der mithilfe unzähliger IoT-Geräte etwa die Hälfte der Datenmenge auf die Server eines Sicherheitsdienstes warf. Es handelte sich diesmal nicht um den Angriff eines Zombie-Bot-Netzwerks, das tausende übernommene Einheiten in den Krieg führt. Stattdessen war es ein Response-Angriff, bei dem unzählige kleinster Anfragen mit verfälschter Absender-IP (in unserem Falle die von Github-Servern) an tausende Server bestimmter Datendienstanbieter, wie Memcached, gesendet wurden. Die Antworten der angefragten Server sind viel datenintensiver als die Mikroanfragen der eigentlichen Täter und legen so das angestrebte Angriffsziel lahm. Es ist also möglich von einer kleinen Einheit, zum Beispiel einem kleinen PC oder einem mobilen Raspberry Pi mit Tor-Anbindung, über ein beliebiges WLan unzählige kleinste Anfragen an Memcached-Server zu senden, die dann zur Beantwortung ungleich größere Datenmengen auf die Reise schicken und zwar an das eigentliche Ziel, in unserem Falle Github. Laut dem botfrei blog machen sich die Kriminellen die Tatsache zunutze, dass bei vielen Memcashed-Servern der UDP-Port 11211 für externe Verbindungen verfügbar ist und sie diesen somit von außen kontrollieren können. Jetzt werden mithilfe der übernommenen Memcashed-Server sowohl das Netzwerk als auch die Server belastet. Sowohl im Ziel, als auch auf den Weg dorthin, kann nur noch ein Bruchteil des Datenverkehrs abgewickelt werden. So kommen eigentlich legitime Anfragen nicht mehr durch oder können nur noch eingeschränkt (also mit extremer Verzögerung) bearbeitet werden. Die Memcashed-Server fungieren also als eine Art Verstärker.

Github selbst spricht von einer Verstärkung von 1 zu 51.000. Das bedeutet, dass für jedes Angriffs-Byte in Richtung Memcached gleich 51 Kilobyte von Memcached auf Github geflogen sind. Die Turmuhr der Saints Peter and Paul Kirche schlug exakt 8.21 Uhr, als der Angriff begann. Unmittelbar nach Angriffsbeginn hörte Github auf, im Internet zu existieren. Es dauerte fünf bis zehn Minuten, dann schaltete Github den Sicherheitsanbieter Akamai ein, der auf solche Angriffe spezialisiert ist. Mit Glockenschlag 17.30 Uhr war Github wieder vollständig verfügbar.

Die Betreiber des Software-Portals gaben an, künftig noch mehr auf derartige Angriffs-Szenarien eingehen zu wollen, um die eigene Infrastruktur besser zu schützen. Offenbar will man auch auf den Einsatz einer künstlichen Intelligenz (KI) setzen, denn der neue Schutz gegen derartige Angriffe soll auch unabhängiger von menschlichen Eingriffen werden. Der Sicherheits-Anbieter Akamai geht davon aus, dass es nur eine Frage der Zeit ist, bis es zu noch stärkeren Memcached-Angriffen kommt. Wer für solch kriminelle Handlungen nicht bestraft werden will, lässt besser die Finger davon.



Bildquelle Pexels, thx! (CC0 1.0)



https://tarnkappe.info/ddos-github-extrem-unter-beschuss/Quelle
Autor: Antonia
Quelle

 

[Metal_Warrior]

Liebe Antonia,

Gottseidank bist du nicht Köppken. Das ging mir durch den Kopf, als ich das gelesen hab, insofern ist sogar noch Hoffnung.

Stattdessen war es ein Response-Angriff, bei dem unzählige kleinster Anfragen mit verfälschter Absender-IP (in unserem Falle die von Github-Servern) an tausende Server bestimmter Datendienstanbieter, wie Memcached, gesendet wurden.

Ähm, nein. Es wurde der Dienst memcached angegriffen bzw. zum Angriff genutzt, nicht der Anbieter (der bietet nämlich nur die Software an). Memcached schiebt Datenbank-Querys, Seiten, Daten etc. vorgefertigt in den RAM, um damit schnell auf Anfragen antworten zu können. Die Wikipedia nutzt das zum Beispiel, um die eigenen Seiten schnell ausliefern zu können und die Last auf der Datenbank gering zu halten. Normalerweise sollte nur der servereigene Webdienst, der von einer solchen Vorverarbeitung profitiert, überhaupt mit dem memcached-Dienst reden dürfen. Aufgrund einer Fehlkonfiguration (und mangelnder Nutzung von Firewalls) konnte jedoch jeder Internetnutzer den memcached-Dienst direkt ansprechen, und so eine direkte Response triggern. Der Rest stimmt dann - falsche Absender-IP, Response geht an den falschen Server, der geht down. War übrigens kein neues Phänomen, war vor ein paar Jahren auch mit ntpd möglich (dem Zeitserver), nur mit wesentlich geringerer Multiplikation.

Jetzt werden mithilfe der übernommenen Memcashed-Server sowohl das Netzwerk als auch die Server belastet.

Wieder falsch. Die memcached-Server wurden nicht übernommen. Sie wurden ihrer eigentlichen Aufgabe vollends gerecht, ihre Sicherheit war nie infrage gestanden. Auch die Daten, die sie ausliefern, sind üblicherweise nicht kritischer Natur (weil sie durch den Webserver sowieso ausgeliefert würden).

Die Turmuhr der Saints Peter and Paul Kirche schlug exakt 8.21 Uhr

Das passiert also, wenn man die Kirchenglocken abschaltet - die Leute denken, dass die jede Minute gebimmelt haben, 24 Stunden am Tag, 7 Tage die Woche. Und dabei wurde sicher niemand der Dörfler jemals wahnsinnig...

Eine Kirchturmuhr schlägt zur vollen Viertelstunde einmal, zur halben zweimal, zur dreiviertelten dreimal und zur vollen Stunde viermal mit der hellen Glocke, um dann anschließend (nur zur vollen Stunde) die jeweils neue Zeit im 12-Stunden-Format mit einer dunkleren Glocke anzuzeigen. Um 8:21 Uhr hat also zuletzt die Glocke einmal geschlagen - 6 Minuten vorher. Und wenn du schon St. Peter and Paul anführst - welche Kirche meinst du? Die in London sicher nicht, das ist nämlich die St. Pauls Cathedral, und die in Rom auch nicht, das ist nämlich der Petersdom, sofern du nicht von der Basilika redest. Ich hab dir da mal ne unvollständige Liste:
https://de.wikipedia.org/wiki/Peter-und-Paul-Kirche

Und von welchen Uhrzeiten redest du jetzt genau? Wir sind auf jeden Fall im Angelsächsischen Raum, denn sonst hättest du St. nicht als Saint ausgeschrieben...

Der Sicherheits-Anbieter Akamai geht davon aus, dass es nur eine Frage der Zeit ist, bis es zu noch stärkeren Memcached-Angriffen kommt.

Davon geh ich jetzt nicht aus - das hat die Runde in der Security-Szene gemacht, jetzt wurden die Firewalls aktualisiert und Feierabend ist es mit den Angriffen. Memcached hat von außen nicht erreichbar zu sein.

Wer für solch kriminelle Handlungen nicht bestraft werden will, lässt besser die Finger davon.

Erstmal finden, bevor man große Sprüche reißt...

 

[Shodan]

Memcached hat von außen nicht erreichbar zu sein.

Full Ack. Aber warum sind dann tausende von Memcached Servern von außen erreichbar? Die Security-Szene sieht die Schuld bei ahungslosen Entwicklern, die komplette Systeme wie memcached nach dem Baukastenprinzip einsetzen, ohne zu verstehen, wie diese funktionieren:

“In the vast majority of cases, developers build things that work, not things that are hardened against misuse or attack,” Migues said. “In many cases, IT/system administrators get things working and then never touch them again because they don’t really understand how it works and what might cause it to stop working.”

“So we have millions of people in critical positions in hundreds of thousands of companies managing access to and creating functionality around quadrillions of dollars of electronic data, life-and-death functions, and the ability to have a 21st century civilization,” he said, “and 95% are unqualified for the security aspects of their job.” (Quelle)

Details zur Verteidigung ala GitHub: https://blog.thousandeyes.com/how-github-successfully-mitigated-ddos-attack/
TLDR: einfach den Traffic über einem Partner routen, der ihn aushalten kann und warten, bis es aufhört.

Weitere netzweit laufende Mitigations, soweit mir bekannt:
- Memcached wurde angepasst, und hört ab Version 1.5.6 nicht mehr per default auf UDP 11211, sondern nur noch dann, wenn es explizit so konfiguriert wurde (Quelle)
- DigitalOcean, die wohl einen nennenswerten Teil der öffentlich erreichbaren Memcached Server hosten, haben udp port 11211 dicht gemacht (Quelle)
- OVH, ebenfalls namentlich in den Presseberichten erwähnt, nutzt ein komplexes Filtersystem, um DDOS zu filtern, legitimen Traffic aber zu erlauben (Quelle)
- Der ISP NTT drosselt den UDP Port 11211 Datenstrom. Andere machen das vielleicht auch. (Quelle)

Wirklich behoben ist es aber noch nicht, DDoSMon zeigt laufende Attacken weltweit. Man könnte auf Infrastrukturebene alles dicht machen, aber wie heißt es so schön in den Kreisen: Don't! Irgendwo hängt vielleicht irgend ein saudummes Krankenhaussystem an dem Port und dann sterben plötzlich Leute, damit ein Webservice erreichbar bleibt. Ja ist sehr weit her geholt, aber ISPs und Cloudanbieter sind nicht die Sheriffs des Internets. Sie sind Kutscher und Wirte.

Warum der plötzliche Peak, das war doch schon lange machbar? Möglicherweise weil eine Refrenzimplementation im November auf einer Konferenz vorgestellt wurde. Die Angreifer sind selten die tatsächlichen Entwickler solcher Angriffe. Sie schnappen diese nur auf und setzen sie in ein Geschäftsmodell um. Insofern ist es fast erstaunlich, dass es drei Monate gedauert hat, bis das passiert ist:

The actor/group that appears to be leveraging this technique has used this same attack technique with the same amounts and wallet address against multiple victims in multiple industries. (Quelle)

 

[Metal_Warrior]

@Shodan: Du widersprichst dich grad selber - es werden grad Firewalls hochgezogen und trotzdem siehst du das Problem nicht als behoben. Also wenn ich mir deinen Link so ansehe, ist es genau das - in zwei Tagen.

 

[Shodan]

Meine Vermutung ist, dass das komplette dichtmachen ala DigitalOcean ein extremer Ausnahmefall bleibt. Die meisten werden sich damit begnügen eine Aufforderung an den Kunden zu versenden, der den Memcached Server bezahlt. Das ist halt das Ding damit: keiner weiß, ob das Dummheit oder Absicht ist. Einem zahlenden Kunden eine Funktion wegzunehmen, die der vielleicht benutzen will, auch wenn sich alle einig sind, dass diese sau dämlich ist, wird von den meisten Unternehmen nur ungern eingesetzt.
("Killing your customer is very low on the list of acceptable business practices. It is on the list, but you have to follow a flowchart" - sfdebris)

Langfristig müssen tausende öffentlich erreichbaren memcached Server von ihren Eigentümern abgesichert werden. Und das wird noch eine Weile dauern, denn diese Eigentümer sind eben nicht Teil der Security-Szene, sonst hätten sie die Dinger gar nicht erst online gestellt. Sie sind Teil der "Swipe to deploy Community".
(Note to self: Keine "konträr zu Metal_Warriors Aussage" Einleitungen als Aufhänger verwenden - previous post edited for compliance)
Auf Infrastrukturebene wird mit QoS (Quality of Service) und SPI (Stateful Packet Inspection) an dem Problem gearbeitet: Die Datenströme werden unterwegs durchleuchtet, kategorisiert und katalogisiert und wenn sie auffällig Muster zeigen, gedroppt und den Behörden gemeldet. Ja ok, ich sehe deinen Punkt, das ist eine Firewall. Aber ich will gar nicht wissen wie viel diese providerseitige Mitigation global an Strom, Hardware und Arbeit frisst. Ja, es funktioniert und deswegen sehen wir hoffentlich sobald keinen weiteren Terrabyte DDoS mehr, aber "behoben" ist imho was anderes. Gigantische "Scrubbing Centers" sind keine langfristig sinnvolle Lösung, auch wenn die Statistik aktuell gut aussieht.

Ich will mich mit dir nicht streiten. Einigen wir uns darauf, dass du Recht hast und meine "Definition of Done" unrealistisch ist

 

[Metal_Warrior]

@Shodan: Mir ist schon klar, dass es den hinterletzten Wald-und-Wiesen-Admin nicht erreicht, und der weiterhin seinen tollen Server online hält, bei dem er wahrscheinlich gar nicht erst dran denkt, dass memcached eingesetzt wird. Und Firewall... kennt auch keiner.

Ich denke aber, dass das Groß der memcached-Server Datenbankserver sind, unter Anderem für CMS, Foren und Wikis. Wenn die Swipe-to-Play betrieben werden, dann meist von Rechenzentren bzw. Hostingprovidern, die da geschlampt haben. Und ich denke, dass die durchaus Firewalls hochziehen können, ohne die Applications ihrer Kunden (die ja auch auf ihren Servern laufen) gleich zu killen. Ich kann mir vorstellen, dass die jetzt ne Woche lang (oder zwei) die externen Verbindungen monitoren, und wenn da nix aufschlägt, machen sie einfach zu. 98-99,5% aller Kunden, die memcached einsetzen, würden diese Änderung wohl selbst dann kaum mitbekommen, wenn man das gleich machen würde. Memcached macht eigentlich (in meinen Augen) nur lokal wirklich Sinn - wenn du dir die Daten erst über Netzwerk mit zig Zwischenhops zukommen lassen musst, kannst du auch gleich die komplette DB-Abfrage durchziehen, das wird kaum noch nen Einschlag in der Performance zeigen.

Spoiler

Widersprechen darfst du mir gern jederzeit, du hast ja auch Quellen geliefert - alles gut. Ich interpretier sie nur anders als du, aber auch das ist ja kein Schaden. Wir diskutieren hier ja nicht, weil wir uns nicht leiden können, sondern weil wir ein Stück näher an die Wahrheit kommen wollen. Insofern: Hau ruhig drauf, ich kann das ab