Zusammenfassung

  • Öffentlich erreichbares memcached über UDP konnte eine winzige Anfrage mit gefälschter Opferadresse in eine tausendfach größere Antwort an das Opfer verwandeln.
  • Die Abwehr blieb verteilt: Version 1.5.6 schaltete UDP standardmäßig ab, Zugangsnetze konnten gefälschte Quellen verwerfen, und GitHub kontrollierte Erkennung, BGP-Umleitung und den gewählten Filterpfad selbst.

Was der Diff tatsächlich änderte

Memcached 1.5.6 erschien am 27. Februar 2018. Die Release Notes nennen als Hauptzweck, UDP standardmäßig zu deaktivieren. Der zugehörige Commit ist konkret: settings.udpport = 11211 wurde zu settings.udpport = 0. Außerdem öffnete die Angabe nur eines TCP-Ports nicht länger stillschweigend denselben UDP-Port. Die Tests wurden passend geändert.

Das Protokoll wurde nicht entfernt. Ein Betreiber konnte es mit -U 11211 ausdrücklich wieder einschalten. Darin liegt die architektonische Qualität der Änderung. Ein legitimer lokaler Sonderfall blieb möglich; Untätigkeit erzeugte aber nicht länger automatisch einen UDP-Reflektor.

Ein Versionsetikett beweist dieses Verhalten trotzdem nicht. Distributionen, Service Units oder lokale Parameter können UDP erneut aktivieren. Eine ältere Version kann auf eine private Adresse gebunden und durch eine Firewall geschützt sein. Entscheidend ist, ob der laufende Dienst auf eine nicht vertrauenswürdige UDP-Anfrage an Port 11211 antwortet und wie groß die Antwort ausfällt.

Running-Code Primacy lässt sich hier Zeile für Zeile beobachten. Die Release Note beschreibt die Absicht. Der Code verändert den Ausgangszustand. Der Test hält ihn fest. Erst Socket-Inventar, externe Sonde und Paketmessung beweisen die Adoption auf einem bestimmten Host.

Warum ein Cache für einen Fremden zahlte

Memcached war für schnelle Zugriffe in einem vertrauenswürdigen Anwendungsnetz gedacht. UDP baut vor der Antwort keine Verbindung auf. Bei öffentlicher Erreichbarkeit konnte der Dienst daher die angegebene Quelladresse als Rücksendeadresse akzeptieren, ohne den Absender zu verifizieren.

Cloudflare beschrieb den Ablauf: Ein Angreifer legte zunächst einen großen Wert in einem exponierten Cache ab und schickte danach ein kleines get mit der IP-Adresse des Opfers als gefälschter Quelle. In einem Versuch lösten 15 Byte 134 KB aus. In einer gesonderten Beobachtung entstanden aus 15 Byte 750 KB, ein Faktor von 51.200.

Diese Werte sind weder universelle Protokollgrenzen noch eine Messung jedes GitHub-Pakets. Sie zeigen die Kostenverschiebung: Der Angreifer sendet wenig, ein fremder Cache bezahlt den großen Egress, und das Opfer erhält eine nie bestellte Antwort.

Zwei Freigaben mussten zusammentreffen. Der Cache beantwortete nicht vertrauenswürdiges UDP, und ein Ursprungsnetz transportierte ein Paket mit einer Adresse, die seinem Kunden nicht gehörte.

GitHubs neun Minuten

GitHub.com war am 28. Februar von 17:21 bis 17:26 UTC nicht verfügbar und bis 17:30 zeitweise gestört. GitHub erklärte, Vertraulichkeit und Integrität der Daten seien zu keinem Zeitpunkt gefährdet gewesen.

Der Angriff kam aus mehr als 1.000 autonomen Systemen und von Zehntausenden Endpunkten. Er erreichte 1,35 Tbps sowie 126,9 Millionen Pakete pro Sekunde. Das sind GitHubs Vorfallmessungen, nicht hochgerechnete Cloudflare-Labortests.

Um 17:21 erkannte die Überwachung ein ungewöhnliches Verhältnis von eingehendem zu ausgehendem Verkehr. Als der Transit an einem Standort über 100 Gbps stieg, entschied GitHub, den Verkehr zu Akamai zu verlagern. Um 17:26 zog ein ChatOps-Befehl BGP-Ankündigungen über Transitprovider zurück und kündigte AS36459 ausschließlich über Akamai-Verbindungen an. Nach der Rekonvergenz filterten ACLs am Akamai-Rand; um 17:30 meldete GitHub vollständige Erholung.

Um 17:34 wurden auch Routen an Internetknoten zurückgezogen, wodurch weitere 40 Gbps verlagert wurden. Kurz nach 18 Uhr folgte eine zweite Spitze von ungefähr 400 Gbps. GitHub wollte künftig die Aktivierung von DDoS-Dienstleistern automatisieren. Der Bericht belegt dieses Ziel, nicht dessen spätere Umsetzung.

Die Sequenz markiert den lokalen Entscheidungsraum des Opfers. GitHub konnte entfernte Caches nicht schließen. Es konnte die eigene Kante messen, eigene Routen verändern, einen Partner auswählen und die Erholung verifizieren.

Die gefälschte Quelle gehört an die Zugangskante

Geschlossene UDP-Dienste verringern die Zahl der Verstärker. Quelladressvalidierung verhindert die Lüge, die Antworten zum Opfer lenkt.

RFC 2827, BCP 38, empfiehlt, den Verkehr eines nachgelagerten Kunden auf Quellpräfixe zu begrenzen, die dieser Kunde legitim nutzt. Nahe am Anschluss müsste ein Paket verworfen werden, das aus Kundennetz A kommt, aber GitHub als Quelle ausgibt.

Mehrfach angebundene und asymmetrische Netze machen die Umsetzung anspruchsvoll. RFC 3704 behandelt Eingangs-ACLs, Strict RPF, Feasible-Path RPF und lockerere Varianten. Ein unpassender strikter Test kann legitimen Verkehr verwerfen. Ein lockerer Test kann irgendeine Route zur Quelle finden, ohne zu beweisen, dass gerade dieser Kunde sie verwenden durfte.

Die minimale gemeinsame Regel sollte die Eigenschaft festlegen: Eine Kundenkante exportiert keine fremde Quellidentität. Mechanismus, Routingdaten, Ausnahmen und Einführung bleiben lokale Entscheidungen. Diese Freiheit setzt den Betreiber nicht von einem messbaren Ergebnis frei.

Drei Grenzen, drei Nachweise

Der Cache-Betreiber weist effektive Bindung, Firewall, externe Erreichbarkeit und Antwortvolumen nach. Das Zugangsnetz weist Anti-Spoofing-Tests und Flussdaten nach. Das Opfer übt Anomalieerkennung, BGP-Wechsel, Filterkapazität und sichere Rückkehr.

Scrubbing schützt das Opfer, nachdem Reflektoren bereits gesendet haben. UDP-off entfernt einen Reflektor, aber keine gefälschten Quellen anderswo. BCP 38 stoppt viele falsche Anfragen, baut jedoch weder GitHubs Kapazität noch seinen Notfallpfad. Kein Nachweis ersetzt die beiden anderen.

Auch entsteht daraus kein Mandat für einen zentralen Lenker. Akamai filterte auf einem von GitHub gewählten Pfad. Das memcached-Projekt änderte seinen Default, ohne Nutzernetze zu regieren. RFCs koordinieren eine Praxis, ohne Router zu betreiben.

Beweisgrenzen

Die Quellen tragen den Mechanismus, GitHubs Spitze und die Softwareänderung. Sie belegen nicht, dass jede memcached-Instanz öffentlich war, jedes Paket um 51.200 verstärkt wurde oder jedes Ursprungsnetz BCP 38 vermissen ließ. GitHubs Automatisierungsabsicht ist kein fertiges System.

Die robuste Aussage ist enger: Ein unsicherer Default erteilte Maschinen stillschweigend das Recht, Bandbreite für Fremde auszugeben. Eine ungefilterte Kante verlieh fremde Identität. Das Opfer erholte sich mit bereits vorhandener lokaler Routingmacht. Schutz wird veröffentlicht; wirksam wird er erst im laufenden System.

Quellen