Pressemitteilung

1,3 Tbit/s vom VAC abgewehrt: Erste Beobachtungen zu den Memcached-Angriffen

2018
Pressemitteilung
Deutschland

corporate

""Am Donnerstag, den 1. März um ungefähr 2 Uhr morgens (GMT+1) hat unser VAC einen gewaltigen DDoS-Angriff mit über 1,3 Tbit/s abgewehrt, der gegen einen unserer Kunden gerichtet war. Dabei wurde auch der bisherige Rekord von 1 Tbit/s des Mirai-Programms gebrochen. Einige Stunden zuvor kämpfte Github mit einem ebenso starken Angriff von 1,3 Tbit/s. Leider konnte die Github-Seite einige Minuten lang nicht aufgerufen werden. Diese gigantischen Attacken hatten etwas gemeinsam: Sie nutzten weltweit schlecht konfigurierte Memcached-Dienste, um sogenannte Amplification-Angriffe durchzuführen. Blicken wir zurück auf eine anstrengende Woche, in der wir viele Nachforschungen angestellt haben...

Abbildung 1: DDoS-Angriff auf einen unserer Kunden mit 1,3 Tbit/s vollständig vom VAC abgewehrt Beitrag in Zusammenarbeit mit Alban Lecoq vom VAC Team Memcached: Eine Standardkonfiguration führt zu Problemen Memcached ist eine als Open Source zur Verfügung gestellte Cache-Software, mithilfe derer Daten als einfache „Key-Value-Paare“ gespeichert werden können. Der Dienst wird außerdem dazu verwendet, um vor allem die Performance von Webseiten zu steigern, Anfrageergebnisse in Datenbanken zu speichern oder dynamische Seitenanwendungen zu beschleunigen. Memcached wird häufig von Webmastern genutzt und auch einige Software-Herausgeber haben diesen Dienst in ihren Lösungen integriert (z. B. in der Webmail-Lösung Zimbra.

Wie kann es dann sein, dass eine so häufig genutzte Software plötzlich außer Kontrolle gerät? Bereits 2017 haben Forscher des chinesischen Internet-Security-Unternehmens Qihoo 360 herausgefunden, wie eine Standardkonfiguration von Memcached dazu genutzt werden kann, Distributed-Denial-of-Service-Angriffe per Amplification auszuführen. Bei seiner Installation wird Memcached nämlich standardmäßig über eine öffentliche Schnittstelle konfiguriert. Da dabei keine Firewall-Einstellungen vorgenommen werden, bleibt Memcached im Internet über die öffentliche IP jedes beliebigen Servers erreichbar. Würde der Dienst nur das TCP-Protokoll erlauben, wäre das Problem auf eine Verletzung vertraulicher Daten beschränkt (wenn keine weitere Authentifizierung vorhanden ist).

Doch leider verbindet sich der Dienst auch via UDP − und genau dort liegt die Schwachstelle. Denn so ist es möglich, eine Amplification („Verstärkung“) mit einem beeindruckenden Faktor von bis zu 51.000 auszulösen. Das NTP-Protokoll kommt gerademal auf einen Faktor von 557. Was ist eigentlich ein Amplification-Angriff? Bei einer Amplification zielen Angreifer darauf ab, das System lahmzulegen, indem sie eine kurze Anfrage schicken, auf die eine riesige Antwort generiert wird. Abbildung 2 zeigt eine Amplification mit dem Faktor 2. Die Antwort ist hier zweimal größer als die Anfrage.

Abbildung 2: Das Schema zeigt eine um den Faktor 2 größere Antwort als Anfrage (Verstärkungsfaktor 2). Um diesen Mechanismus voll auszuschöpfen und ihn für DDoS-Angriffe zu nutzen, koppeln die Angreifer die Amplification mit einem Reflection-Mechanismus. Bei einer Reflection wird eine bestimmte IP-Adresse gefälscht, sodass die Antwort an die so „gestohlene“ IP gesendet wird. Der Server antwortet blind an die Quell-IP eines empfangenen Pakets, auch wenn diese missbräuchlich verwendet wurde.

Abbildung 3: Darstellung der Kombination von Amplification und Reflection Das Opfer empfängt so, ohne etwas angefragt zu haben, Datenpakete des Servers. UDP-Verbindungen werden häufig für Reflection-Angriffe genutzt, da es sich hierbei um ein verbindungsloses Protokoll handelt. Im Gegensatz zu TCP gibt es kein „Three-Way-Handshake“-Verfahren. Es reicht also aus, ein einziges Datenpaket zu schicken, damit man von der korrespondierenden Instanz eine Antwort erhält.

Über TCP müssen mindestens 4 Pakete zwischen Client und Server ausgetauscht werden, bevor sie eine Verbindung erlauben. Wenn in diesem Fall die IP gefälscht wurde, wird die Antwort des Servers (SYN-ACK) an das Opfer weitergeleitet und der eigentliche Initiator der Verbindung kann die Verbindungsherstellung (ACK) nicht bestätigen. Dadurch wird diese unmöglich und die missbräuchliche Verwendung der IP-Adresse war völlig umsonst. Auf Wikipedia finden Sie eine ausführliche Erklärung der Funktionsweise des Transmission Control Protocol. Maßnahmen bei OVH Infolge des unverhältnismäßigen Anstiegs Memcached-basierter Amplification-Angriffe haben wir umgehend Maßnahmen ergriffen, um Rekord-DDoS-Angriffen standzuhalten. Amplification ist ein leicht zu identifizierender Angriffsvektor. Dennoch müssen wir sicherstellen, dass unsere Verbindungen mit anderen Operatoren (Peering) nicht betroffen sind, damit die Dienstqualität nicht beeinträchtigt wird. Unsere Maßnahmen wurden auch sogleich auf die Probe gestellt: bei einem Angriff mit mehr als 1,3 Tbit/s auf einen unserer Kunden (Abbildung 1). Der Angriff wurde vom VAC vollständig und ohne Dienstunterbrechung abgewehrt. Darüber hinaus sollen die Maßnahmen verhindern, dass Kunden mit einem schlecht konfigurierten Memcached-Dienst selbst in solchen Angriffen beteiligt werden. Folgende Punkte müssen wir dazu beachten:

  • Potenziell betroffene Kunden gezielt informieren und sie bei der Konfiguration des Dienstes mit einer Anleitung unterstützen.
  • Nicht stunden- oder tagelang darauf warten, dass die Kunden das Problem beheben, sondern gleich eingreifen und die OVH IPs, die als Reflektoren dienen, ermitteln. Die Dienstqualität wird hierbei nicht beeinträchtigt.

Wir haben uns entschieden, den UDP-Port 11211 (dieser Port wird von Memcached verwendet) in unserem Netzwerk nicht zu blockieren, da er auch als Client-Port für die Kommunikation genutzt werden kann. Bei einer Blockierung des Ports kann es zu Einschränkungen des Dienstes kommen, insbesondere bei Online-Games, Internettelefonie (VoIP), Streaming oder anderen Diensten, die UDP verwenden. Stattdessen stellen wir IPs, die pro Sekunde eine sehr große Anzahl an Memcached-Anfragen erhalten und so als Mitwirkende bei DDoS-Angriffen identifiziert wurden, unter permanente Mitigation. Auf diese Weise werden solche bösartigen Anfragen gleich bei ihrer Ankunft verhindert und wir können gewährleisten, dass die Dienste unserer Kunden nicht für Reflection-Angriffe missbraucht werden. Unsere Nachforschungen Die ersten Angriffe, die wir beobachten konnten, wurden am 26. Februar 2018 über GET-Anfragen generiert, wie in Abbildung 4 gezeigt. Genau wie Cloudflare haben wir festgestellt, dass mit dieser Anfrage ein Schlüssel gelesen werden konnte, der eine passwortgeschützte zip-Datei enthielt, in der wiederum eine gif-Datei enthalten war.

Abbildung 4: Von unseren Honeypots am 27.02.2018 registrierte Anfragen an den UDP-Port 11211 (Memcached) Was hatte dieser zip-Ordner in den Caches zu suchen? Uns war sofort klar, dass die anvisierten Dienste vorbereitet wurden, um dann für Attacken verwendet zu werden, und haben versucht, die Quelle ausfindig zu machen. Außerdem wussten wir, dass Memcached schon seit einigen Tagen wieder als Basis für Amplification-Angriffe genutzt wurde. Die Grafiken in Abbildung 5 stellen die Serverbandbreite eines unserer Kunden dar, dessen Dienst seit dem 24. Februar 2018 genutzt wurde, um Angriffe gegen die chinesische IP „59.56.19.xxx“ zu starten (das letzte Byte ist bewusst verborgen).

Abbildung 5: Amplification über den UDP-Port 11211 des Servers eines unserer Kunden am 24.02.2018 (Zeitzone GMT+1) Diese IP wurde anscheinend regelmäßig und äußerst synchron von mehreren Rechnern unseres Netzwerks via Amplification (LSAP, NTP, SNMP etc.) attackiert. Dafür kann es mehrere Gründe geben: Entweder wird unter dieser IP ein Dienst gehostet, der geradezu verhasst ist, oder es handelt sich um eine Test-IP für die Vorbereitung von Memcached-basierten Amplification-Angriffen. Bei genauerem Hinsehen fällt auf, dass die Attacken gegen diese IP generell sehr kurz sind. Sie gehen ein paar Zehntel Sekunden bis höchstens einige Minuten lang. Andere Angriffe nehmen im Allgemeinen eher längere Zeiträume in Anspruch. Die längste beobachtete Attacke dauerte 3 Stunden. Einiges weist also darauf hin, dass diese IP ein „Dstat“ ist, das heißt eine IP, über die die Effizienz eines DDoS-Angriffs in Echtzeit gemessen werden kann. Daher denken wir, dass die Admins eines „Booters“ (Plattform, die DDoS-Angriffe zum Kauf anbietet) möglicherweise ihre unterschiedlichen Amplification-Angriffe mit einer Memcached-Amplification vergleichen wollten. Bei den Tests, die alle im selben Zeitfenster durchgeführt wurden, registrierten wir NTP (UDP/123), LDAP (UDP/389), SSDP (UDP/1900) und BitTorrent. Bei weiteren Recherchen in Foren, die auf DDoS-Angriffe spezialisiert sind, sind wir schließlich auf einen ziemlich expliziten Austausch gestoßen (Abbildung 6), in dem ein Nutzer zugibt, dass seine DDoS-Verkaufsplattform die erste Plattform war, die eine Amplification via Memcached zur Verfügung stellte.

Abbildung 6: Ein Nutzer gibt öffentlich an, dass er der Autor des Skripts ist, das Memcached-basierte Amplification-Angriffe ermöglicht. Die Entwicklung der Bedrohung Innerhalb einer Woche hat die Lage sich stark verändert. Anfangs sah es noch so aus, als stamme die Idee der Memcached-basierten Amplification von einem einzigen Booter. Doch bereits nach kurzer Zeit haben andere Anbieter das Skript implementiert und ihren Kunden zum Kauf angeboten. Seit den ersten Fällen haben unsere Honeypots viele verschiedene Arten aufgedeckt, wie Memcached-basierte Dienste im Internet für Angriffe genutzt werden.

Abbildung 7: Verteilung der Memcached-Anfragen, die von unseren Honeypots registriert wurden. Bei manchen Diensten wurde die zip-Datei, die im „a“-Schlüssel enthalten war, mit der Kette „abcdefghij“ ersetzt, die sich tausende Male wiederholt, ohne dass wir dabei einen Schreibversuch erkennen konnten.

Abbildung 8: Beispiel eines Memcached mit einem „a“-Schlüssel, der eine alphabetische Buchstabenabfolge enthält, die sehr häufig wiederholt wird. Wir haben außerdem Schlüssel identifiziert, die Nachrichten mit der Aufforderung enthielten, 50 XMR zu zahlen; eine beliebte Kryptowährung, die auch unter dem Namen Monero bekannt ist. Handelt es sich hierbei tatsächlich um einen Erpressungsversuch von Datenbanken, die naturgemäß nur temporäre Daten speichern? Oder ist es nur ein Mittel, um den Cache zu füllen und so den Verstärkungsfaktor zu erhöhen?

Abbildung 9: „a“-Schlüssel eines Memcached-Dienstes, der die Aufforderung, 50 XMR zu zahlen, enthält. Auch wenn eine kleine Anzahl von ungesicherten Memcached-Diensten schnell korrigiert wurde, gibt es immer noch unzählige Dienste, die für Angriffe genutzt werden können. Genau wie bei den Angriffen via NTP wird wohl auch die Bedrohung durch Memcached-basierten Attacken noch länger anhalten. Auch wenn die Schutzmechanismen, die inzwischen von Hostern eingerichtet wurden, die Größe der Angriffe drastisch reduziert haben (die Mehrheit liegt aktuell bei unter 100 Gbit/s), ist die einzige wirklich effiziente Lösung die sichere Konfiguration des Dienstes seitens der Nutzer. Bereits die NTP-basierten Angriffe haben uns gelehrt, dass Server selbst nach 5 Jahren häufig noch anfällig sind, und das trotz verfügbarer Patches. Vielleicht ist es gar keine so schlechte Idee, nach der Lektüre dieses Beitrags noch einmal die Einstellungen Ihrer Firewall zu überprüfen und einen Blick auf Ihre Dienste zu werfen, die möglicherweise ungeschützt im Internet bereitstehen...  "