GitHubs Great-Cannon-DDoS von 2015 machte On-Path-Codeinjektion z

Zusammenfassung

GitHub erklärte, der DDoS-Angriff habe am 26. März 2015 gegen 02:00 Uhr UTC begonnen und sei damals der größte derartige Angriff in der Geschichte des Dienstes gewesen. [1]
Nach GitHubs Darstellung wurden auch Browser unbeteiligter Menschen dazu gebracht, Anfragen gegen bestimmte auf GitHub gehostete Seiten zu senden. Die tatsächlichen Verbindungen stammten von realen Clients, nicht bloß von gefälschten Quelladressen. [1]
GreatFire beschrieb eine bereits am 17. März einsetzende Angriffswelle und führte die Aktivität auf chinesische Behörden zurück. Diese Zuordnung bleibt die Aussage einer betroffenen Organisation und ist kein gerichtlich festgestellter Befund. [7][8]
GreatFire berichtete, dass Schadcode an die Stelle von Ressourcen im Umfeld von Baidu Analytics getreten sei. Baidu bestritt, dass die eigenen Produkte kompromittiert worden seien; diese Gegenposition gehört zwingend zum Tatsachenbild. [8]
Citizen Lab und weitere Forschende rekonstruierten ein netzseitig positioniertes System, das ausgewählte unverschlüsselte HTTP-Anfragen erkennen, Antworten ersetzen und Browser außerhalb Chinas für wiederholte Zielanfragen einspannen konnte. [2][3][4][5]
Die Forschung stützte eine Einschätzung über einen wahrscheinlich staatlichen Betreiber, bewies jedoch weder eine individuelle Befehlskette noch eine rechtsverbindliche staatliche Verantwortlichkeit.
BCP 38, uRPF und verwandte Verfahren bleiben wichtige Mittel gegen gefälschte Quelladressen. Sie halten jedoch keine Anwendungskommunikation auf, die ein Browser nach Ausführung injizierten Codes von seiner echten Adresse aus beginnt. [12][13][14]
Authentisierte Verschlüsselung erschwert die unbemerkte Veränderung einer Antwort auf dem Übertragungsweg erheblich. Sie beseitigt aber weder jeden DDoS-Vektor noch Blockaden, Endpunktkompromittierungen oder andere Formen der Netzmanipulation. [15][16]
Verantwortlichkeit muss sich daran orientieren, wer über den Übertragungsweg, die eingebettete Ressource, die Browserausführung, GitHubs Netzrand und die DDoS-Abwehr tatsächlich verfügen konnte – und wer darüber überprüfbare Aufzeichnungen besaß.

Nicht nur die Größe des Angriffs war außergewöhnlich

Als GitHub Ende März 2015 unter massiven Lastdruck geriet, lag die Besonderheit nicht allein in der Größenordnung. GitHub bezeichnete das Ereignis als den bis dahin größten DDoS-Angriff auf seinen Dienst. Bedeutender für die langfristige Bewertung war jedoch, wie ein Teil des Datenverkehrs entstanden sein soll: Browser unbeteiligter Personen erhielten demnach veränderten JavaScript-Code und sandten anschließend wiederholt Anfragen an ausgewählte, auf GitHub gehostete Inhalte. [1]

Damit verschob sich die entscheidende Frage. Es ging nicht mehr nur darum, wie viel unerwünschter Verkehr an GitHubs Netzrand eintraf. Zu klären war vielmehr, wie ein gewöhnlicher Abruf einer unverschlüsselten Drittressource in eine Angriffshandlung verwandelt werden konnte, ohne dass der Benutzer dies beabsichtigte und ohne dass jeder beteiligte Rechner zuvor wie ein klassischer Bot kompromittiert worden sein musste.

Die Browser stellten echte Verbindungen her. Ihre Quelladressen waren grundsätzlich plausibel. Aus Sicht eines Routers konnte eine Verbindung topologisch korrekt aussehen, obwohl ihre Ursache eine fremde, auf dem Übertragungsweg eingeschleuste Anweisung war. Der Benutzer hatte weder GitHub als Ziel ausgewählt noch notwendigerweise erkennen können, dass sein Browser dafür Datenverkehr erzeugte.

Diese Trennung zwischen technischer Herkunft und menschlicher Absicht ist für die Verantwortungszuordnung grundlegend. Eine IP-Adresse kann den Ursprung einer Verbindung beschreiben, aber nicht erklären, warum die Anwendung sie aufgebaut hat. Ein Domainname kann zeigen, welche Ressource angefordert wurde, aber nicht beweisen, dass die empfangenen Bytes tatsächlich unverändert vom vorgesehenen Ursprung stammten. Ein Statusbericht kann die Lage eines Zielsystems beschreiben, aber nicht von selbst offenlegen, was auf einem entfernten Transitweg geschah.

Genau deshalb ist das Ereignis keine beliebig austauschbare Geschichte über einen großen Internetangriff. Seine Kernaussage betrifft Netzbetrieb: Ein Akteur mit Zugriff auf einen geeigneten Übertragungsweg soll ungeschützte Anwendungsinhalte verändert und damit fremde Browser als Quelle einer Verfügbarkeitsbelastung eingesetzt haben. Nimmt man Transitwege, Antwortintegrität, Browserausführung und die Schutzmaßnahmen am GitHub-Netzrand aus der Analyse heraus, bricht die Verantwortlichkeitsthese zusammen.

Was der öffentliche Befund tatsächlich trägt

GitHubs eigene Mitteilung bildet den verlässlichsten Ausgangspunkt für die Ereignisse auf der Seite des betroffenen Dienstes. Das Unternehmen erklärte, der Angriff habe am Donnerstag, dem 26. März 2015, gegen 02:00 Uhr UTC begonnen. Es berichtete von mehreren Angriffsvektoren und von neuartigen Techniken, durch die Browser unbeteiligter Nutzer GitHub mit Anfragen belasteten. GitHub erklärte außerdem, verfügbare Berichte hätten zu der Annahme geführt, dass das Unternehmen zur Entfernung einer bestimmten Art von Inhalten gedrängt werden sollte. [1]

Diese Aussage dokumentiert GitHubs Beobachtung und damalige Deutung. Sie beantwortet jedoch nicht jede denkbare Frage. Der öffentliche Bericht nennt weder eine vollständige Verkehrsmenge noch eine belastbare Gesamtzahl beteiligter Browser. Er beziffert keinen finanziellen Schaden und legt keinen minutengenauen Wiederherstellungszeitpunkt offen. Ebenso wenig weist er eine individuelle Person als Auftraggeber oder Entscheider aus.

GreatFire beschrieb die Vorgeschichte aus Sicht eines weiteren Betroffenen. Die Organisation teilte mit, ihre Dienste seien bereits seit dem 17. März einer außergewöhnlich starken Anfrageflut ausgesetzt gewesen. In einer späteren Darstellung erklärte GreatFire, dass eingeschleustes JavaScript Browser auf GreatFire-Inhalte und zwei bei GitHub gehostete Seiten gelenkt habe. GreatFire schrieb die Vorgänge chinesischen Behörden zu. [7][8]

Diese Zuordnung muss als Zuordnung von GreatFire kenntlich bleiben. Sie ist Teil des Quellenbildes, darf aber nicht in eine unanfechtbare Feststellung umformuliert werden. Das gilt ebenso für die Frage nach Baidus Rolle. GreatFire brachte den veränderten Code mit Ressourcen im Umfeld von Baidu Analytics in Verbindung. Baidu bestritt, dass die eigenen Produkte kompromittiert worden seien. [8] Serverkompromittierung, wissentliches Mitwirken, missbräuchliche Nutzung einer Ressource und Veränderung einer Antwort auf dem Übertragungsweg sind technisch unterschiedliche Behauptungen.

Die detaillierteste öffentliche Rekonstruktion stammte von Citizen Lab, dem International Computer Science Institute, Forschenden der University of California, Berkeley, Princeton und weiteren Beteiligten. Ihre Arbeiten unterschieden das Great Cannon genannte System von der Great Firewall, stellten aber Ähnlichkeiten bei Code und Netzposition fest. Die Messungen deuteten darauf hin, dass das System ausgewählte unverschlüsselte HTTP-Anfragen beobachten und veränderte Antworten einspeisen konnte. Der ausgeführte Code veranlasste Browser außerhalb Chinas, wiederholt Anfragen an festgelegte Ziele zu senden. [2][3][4][5]

Die Forschenden lokalisierten beobachtbares Verhalten und entwickelten eine begründete Einschätzung über einen wahrscheinlich staatlichen Betreiber. Die Präzision dieser Aussage ist wichtig. Eine technische Ortsbestimmung und die Übereinstimmung mehrerer Merkmale können eine starke Zuordnung stützen. Sie ersetzen aber weder eine offengelegte Befehlskette noch ein gerichtliches Verfahren. Der öffentliche Befund erlaubt eine wahrscheinliche Betreiberbewertung, keine erfundene Gewissheit über einzelne Entscheidungsträger.

Wie On-Path-Injektion aus normalem Webverkehr Angriffslast machte

Der entscheidende Kontrollpunkt lag zwischen der beabsichtigten Ressource und dem Inhalt, den der Browser tatsächlich akzeptierte. Eine Webseite forderte eine Drittressource über unverschlüsseltes HTTP an. Der Browser sendete seine Anfrage über eine Kette von Zugangs-, Transit- und weiteren Netzkomponenten. Ein System mit geeigneter Position auf diesem Weg konnte die Anfrage erkennen und dem Browser eine veränderte Antwort liefern.

Plaintext-HTTP bietet keine kryptografische Garantie dafür, dass der empfangene Inhalt unverändert vom bezeichneten Ursprung stammt. Ein On-Path-System kann versuchen, schneller als die legitime Antwort zu reagieren oder anderweitig eine Antwort einzuschleusen, die der Browser als Ergebnis seiner Anfrage akzeptiert. Enthält diese Antwort ausführbaren JavaScript-Code, wird aus einer Abweichung bei der Auslieferung unmittelbar Anwendungsverhalten.

Der Browser konnte daraufhin wiederholt HTTP-Anfragen an die ausgewählten GitHub-Ziele senden. Dafür war keine gefälschte Quelladresse nötig. Der Client eröffnete die Verbindung selbst und verwendete seine tatsächliche Adresse. Ebenso musste der Rechner nicht dauerhaft in ein Botnetz aufgenommen worden sein. Die Ausführung konnte vorübergehend an den Abruf der manipulierten Ressource gebunden sein.

Diese Architektur unterscheidet sich auch von einer üblichen Reflexionsattacke. Bei klassischer UDP-Reflexion gibt ein Angreifer häufig die Adresse des Opfers als gefälschte Quelle an und bringt fremde Server dazu, ihre Antworten an das Opfer zu senden. Im Great-Cannon-Fall erzeugten Browser dagegen nach dem öffentlich rekonstruierten Mechanismus eigenständige Anwendungsanfragen. Der Datenverkehr wurde nicht lediglich durch eine gefälschte Absenderadresse umgelenkt.

Drei Identitäten dürfen daher nicht miteinander verschmolzen werden:

Die im Dokument bezeichnete Ressource beschreibt, was der Browser abrufen sollte.
Die tatsächlich empfangenen Bytes zeigen, was der Browser über seinen konkreten Weg bekam.
Die spätere Clientverbindung zu GitHub zeigt, welcher Browser die Anfrage technisch absandte.

Keine dieser Identitäten beweist für sich allein die anderen beiden. Ein korrekter DNS-Eintrag beweist keine unveränderte Auslieferung. Eine plausible Clientadresse beweist keine Absicht des Benutzers. Ein Ressourcenname beweist nicht, dass der bezeichnete Betreiber genau den beobachteten Code ausgeliefert hat.

Der laufende Netzbetrieb hat Vorrang vor dem Verwaltungsbild

Die Heng.lu-Perspektive liefert hier einen besonders scharfen Maßstab: Register und administrative Aufzeichnungen sind wichtige Beweismittel, aber keine souveräne Wahrheit über das Verhalten eines laufenden Netzes. Entscheidend ist, was das System tatsächlich ausführt und ausliefert.

Ein Domainname, ein DNS-Eintrag, eine IP-Zuweisung, ein Zertifikat oder ein Hostingvertrag beschreibt beabsichtigte Identität und Zuständigkeit. Solche Aufzeichnungen sind unverzichtbar, um Erwartungen festzuhalten. Beim Great-Cannon-Ereignis konnte ein Browser jedoch offenbar den erwarteten Namen auflösen und dennoch Bytes ausführen, die auf dem Übertragungsweg eingefügt worden waren. Das Verwaltungsbild blieb äußerlich konsistent, während die reale Auslieferung davon abwich.

Der Vorrang des laufenden Codes bedeutet nicht, Registerdaten oder Netzaufzeichnungen zu verwerfen. Im Gegenteil: Erst ihre Verbindung mit Beobachtungen macht eine belastbare Rekonstruktion möglich. DNS-Antworten, Routingtabellen, sichtbare BGP-Pfade, Transitbeziehungen, Schnittstellenzuordnungen, Zertifikatsketten und HTTP-Metadaten beschreiben das Erwartete. Antwort-Hashes, Zeitverläufe, Browserprotokolle und Messungen aus mehreren Netzen zeigen, ob diese Erwartung erfüllt wurde.

Auch RPKI wäre in diesem Zusammenhang kein universeller Gegenzauber. RPKI und ROAs können Aussagen darüber verbessern, welche autonomen Systeme bestimmte Präfixe rechtmäßig originieren dürfen. Sie beglaubigen jedoch nicht den Inhalt einer unverschlüsselten HTTP-Antwort. Eine gültige Routenautorisierung kann mit einer späteren Veränderung auf einem durchlaufenen Weg koexistieren.

Daraus folgt eine Realitätsebene der Verantwortlichkeit. Nicht die überzeugendste Interessenbehauptung entscheidet, sondern die Verbindung zwischen technischer Kontrolle und überprüfbaren Spuren. Wer konnte den betreffenden Verkehr sehen? Wer konnte Antworten verändern? Welche Systeme waren dazu fähig? Welche Konfigurationen, Freigaben und Zugriffsprotokolle existierten? Was erhielten Clients in unterschiedlichen Netzen wirklich?

Diese Fragen sind weder Werbung für eine Regierung noch für GitHub, GreatFire, Baidu oder eine bestimmte Verschlüsselungspolitik. Sie prüfen, ob die behauptete Autorität mit dem beobachteten Betrieb übereinstimmte. Genau das ist die zentrale Pflicht eines Netzes, das Vertrauen nicht nur verwalten, sondern technisch einlösen soll.

Warum Quelladressvalidierung wichtig blieb – und trotzdem nicht genügte

BCP 38 und verwandte Verfahren sollen verhindern, dass Netze Verkehr mit Quelladressen weiterleiten, die hinter der betreffenden Schnittstelle nicht plausibel sein können. Weiterentwickelte uRPF-Verfahren berücksichtigen komplexere Routensituationen und asymmetrische Pfade. NIST ordnet Quelladressvalidierung gemeinsam mit Routing-Sicherheit und DDoS-Abwehr in ein breiteres Resilienzmodell ein. [12][13][14][17]

Diese Kontrollen sind für das Internet von großer Bedeutung. Sie erschweren Angriffe, die Quelladressen fälschen, und verringern den Spielraum für bestimmte Reflexions- und Verstärkungsmechanismen. Korrekt eingesetzte Filter verbessern außerdem den Beweiswert einer beobachteten Quelladresse, weil triviale Fälschungen weniger wahrscheinlich werden.

Der öffentlich rekonstruierte Browsermechanismus hatte jedoch eine andere Eigenschaft. Der Browser öffnete die Verbindung von seinem tatsächlichen Netzanschluss aus. Ein Filter konnte daher korrekt feststellen, dass die Quelladresse zum einliefernden Weg passte, und den Verkehr dennoch passieren lassen. Die schädliche Ursache lag nicht im Absenderfeld der IP-Kommunikation, sondern im injizierten Anwendungscode, der die Verbindung ausgelöst hatte.

Das macht Quelladressvalidierung nicht überflüssig. DDoS-Ereignisse können mehrere Vektoren kombinieren, und die Reduzierung gefälschten Verkehrs schützt knappe Filter- und Verarbeitungskapazität. Falsch wäre lediglich die Behauptung, BCP 38 hätte diese konkrete Form der Browseranwerbung allein verhindert.

Ein belastbares Kontrollmodell muss deshalb jeder Maßnahme die richtige Eigenschaft zuordnen:

Quelladressvalidierung begrenzt die Fälschung von Netzadressen.
Authentisierte Verschlüsselung schützt die Integrität und Vertraulichkeit einer Verbindung innerhalb ihres Sicherheitsmodells.
Browserrichtlinien begrenzen die Ausführung und Wirkung fremden Codes.
Edge- und Anwendungskontrollen begrenzen Anfrageraten und Ressourcenverbrauch.
Kapazitätsplanung und DDoS-Mitigation begrenzen den Verfügbarkeitsverlust.
Mehrpunktmessungen verbessern die Lokalisierung und Beweisführung.

Keine dieser Ebenen kann die gesamte Kette allein beherrschen.

Authentisierte Verschlüsselung verändert die Macht auf dem Übertragungsweg

TLS verbindet Verschlüsselung mit Authentisierung und Integritätsschutz. Ein Browser, der eine korrekt validierte TLS-Verbindung zum vorgesehenen Ursprung aufbaut, erwartet geschützte Inhalte, deren Veränderung erkannt wird. Ein On-Path-System kann dann nicht einfach eine beliebige Ersatzantwort einschleusen, ohne die Authentisierung zu umgehen, einen Endpunkt oder eine Vertrauenskomponente zu kompromittieren oder einen sichtbaren Verbindungsfehler hervorzurufen.

RFC 7258 behandelt pervasive Überwachung und die Unterwanderung von Kommunikation als Angriffe, die beim Protokolldesign berücksichtigt werden müssen. TLS 1.3 formuliert später die Eigenschaften eines authentisierten und verschlüsselten Kanals, der Abhören, Manipulation und Nachrichtenfälschung erschweren soll. [15][16] Diese Standards liefern einen Kontrollrahmen; sie sind kein nachträglicher Beweis für jedes technische Detail der 2015 verwendeten Infrastruktur.

Die angemessene Schlussfolgerung lautet deshalb nicht, HTTPS hätte jeden denkbaren Angriff verhindert. Authentisierte Verschlüsselung hätte die beschriebene unbemerkte Ersetzung einer Plaintext-Antwort erheblich erschwert. Ein Angreifer hätte aber weiterhin Verbindungen blockieren, zurücksetzen oder überlasten können. Auch kompromittierte Ursprünge, fehlerhafte Zertifikatsprüfung, bösartige Drittressourcen, Routingmanipulation oder andere DDoS-Verfahren bleiben denkbar.

Der Verantwortungsmaßstab ist konkret: Betreiber sollten wissen, welche ausführbaren Ressourcen über authentisierte Verbindungen ausgeliefert werden, wo noch unverschlüsselte Abhängigkeiten bestehen, welche Mixed-Content-Regeln greifen und wie Fehler aus verschiedenen Netzen sichtbar werden. Eine pauschale Aussage wie „HTTPS löst das Problem“ wäre ebenso unzureichend wie die Behauptung, Verschlüsselung sei irrelevant, weil DDoS weiterhin möglich bleibt.

Mehrpunktmessung als Voraussetzung belastbarer Zuordnung

Ein selektiv arbeitendes Injektionssystem muss nicht jede Anfrage verändern. Es kann nur bestimmte Hostnamen, Pfade, Parameter, Quellnetze, Ziele oder Zeitfenster erfassen. Auf einem Transitweg kann der Effekt auftreten, während ein anderer Weg unverändert bleibt. Eine Messung von nur einem Standort kann daher kaum entscheiden, ob eine abweichende Antwort am Ursprung, in einem lokalen Gerät oder unterwegs entstand.

Mehrpunktmessungen schaffen Vergleichbarkeit. Forschende können dieselbe Ressource aus unterschiedlichen Netzen abrufen, den Inhalt hashen, Antwortzeiten und Metadaten dokumentieren und – soweit rechtlich und datenschutzgerecht möglich – detailliertere Übertragungsbeobachtungen sichern. Erhält ein Standort anderen Code als ein zweiter, während der vorgesehene Ursprung konsistente Inhalte protokolliert, lässt sich der Kreis möglicher Kontrollpunkte einengen.

Das Zeitverhalten ist besonders aufschlussreich. Trifft eine abweichende Antwort vor der legitimen Antwort ein, kann dies eine Race-Injektion stützen. Beweisen kann dieses Merkmal die gesamte Betreiberfrage allein jedoch nicht. Benötigt werden eine nachvollziehbare Zeitbasis, bekannte Uhrabweichungen und eine saubere Trennung zwischen Erfassung, Übertragung, Speicherung und späterer Analyse.

Rohbeobachtung und Schlussfolgerung müssen getrennt bleiben. Zur Rohbeobachtung gehören Zeitstempel, angeforderte Ressourcen, empfangene Inhalte, Hashes, Zertifikatsprüfungen, Resolverantworten, sichtbare Routeninformationen und Browserverhalten. Zur Schlussfolgerung gehören die vermutete Position des Injektors, seine Beziehung zu bekannter Filterinfrastruktur und die Einschätzung über den Betreiber.

Diese Trennung schützt die Analyse vor zwei Fehlern: Einerseits darf technische Unsicherheit nicht als Vorwand dienen, offensichtliche Zusammenhänge vollständig zu ignorieren. Andererseits darf eine plausible Lokalisierung nicht in einen behaupteten persönlichen Befehl umgedeutet werden. Gute Netzbeweise machen sichtbar, welche Aussage unmittelbar beobachtet, welche abgeleitet und welche weiterhin offen ist.

GitHubs tatsächliche Kontrollgrenze

GitHub kontrollierte den angegriffenen Dienst und damit eine andere Grenze als ein möglicher Injektor auf dem entfernten Übertragungsweg. Das Unternehmen konnte unerwünschte Anfragen klassifizieren, Kapazität am Netzrand bereitstellen, Raten begrenzen, mit Mitigationsanbietern zusammenarbeiten, besonders belastete Pfade schützen und die Betriebsverfügbarkeit kommunizieren.

GitHubs ältere Darstellung seiner DDoS-Abwehr beschreibt unter anderem angepasste Netzwerk-Stacks, Grenzen an Lastverteilern, Filtertechnik und die Zusammenarbeit mit einem externen Mitigationspartner. [9] Diese Angaben sind wertvoller Architekturkontext. Sie beweisen jedoch nicht, dass jede beschriebene Maßnahme im März 2015 unverändert aktiv war oder gegen jeden beobachteten Vektor gleich gut wirkte.

Eine überprüfbare Ereignisakte auf der Seite GitHubs müsste Anfragemuster, Zielpfade, Netzverteilung, Verbindungsverhalten, Auslastung von Edge- und Anwendungssystemen, Filterentscheidungen, Übergaben an Mitigationspartner und kundenrelevante Auswirkungen zusammenführen. Jede wesentliche Änderung sollte mit Zeitpunkt, Verantwortlichem, erwarteter Wirkung und beobachtetem Ergebnis verbunden sein.

Die Klassifikation war schwierig, weil der Verkehr wie echte Anwendungskommunikation erscheinen konnte. Ein pauschales Sperren aller beteiligten Quelladressen hätte möglicherweise Nutzer getroffen, die nichts von der Browserausführung wussten. Gemeinsame Adressräume und Zugangsnetze erhöhen dieses Kollateralrisiko. Umgekehrt konnte das ungefilterte Bedienen wiederholter Anfragen wertvolle Ressourcen verbrauchen.

Hinzu kam der offenbar inhaltsbezogene Druck. GitHub erklärte, die Absicht habe nach seiner Einschätzung darin bestanden, das Unternehmen zur Entfernung bestimmter Inhalte zu bewegen. [1] Technische Kontinuität schützte damit nicht nur einen abstrakten Verfügbarkeitswert, sondern verhinderte, dass ein externer Akteur durch Netzlast faktisch über GitHubs Hostingentscheidungen verfügte.

Daraus folgt keine Aussage darüber, dass jede konkrete Inhaltsentscheidung des Dienstes unangreifbar wäre. Die Verantwortungsfrage lautet enger: Konnte GitHub den Dienst und die Integrität der gehosteten Inhalte erhalten, ohne unbeteiligte Benutzer pauschal als Angreifer zu behandeln und ohne die eigene Policy stillschweigend an den erzeugten Lastdruck abzutreten?

Die Beweislast der Betreiber auf dem Transitweg

Wer eine Netzposition kontrolliert, an der Anwendungsverkehr beobachtet oder verändert werden kann, besitzt eine besondere technische Macht. Aus dieser Macht entsteht eine Pflicht zur überprüfbaren Kontrolle.

Ein verantwortlicher Betreiber sollte nachvollziehen können, welche Systeme Inhalte inspizieren oder verändern dürfen, welche Regeln dies auslösen, wer Konfigurationen ändern kann und welche Protokolle Aktivierung, Änderungen und Zugriffe festhalten. Wird eine Beteiligung bestritten, sind konsistente, unabhängig prüfbare Aufzeichnungen aussagekräftiger als eine nicht weiter belegte kategorische Erklärung.

Das bedeutet nicht, dass jeder Transitprovider auf einem sichtbaren Weg für jede Manipulation haftet. Internetverkehr durchquert mehrere Verwaltungsbereiche, und Routen können sich während eines Ereignisses ändern. Ein Betreiber kann Verkehr weiterleiten, ohne die fragliche Funktion zu kontrollieren oder überhaupt Einblick in geschützte Anwendungsinhalte zu haben. Verantwortung muss tatsächlicher Verfügung folgen, nicht bloßer geografischer Nähe oder einer politischen Vermutung.

BGP-Daten können die Untersuchung eingrenzen. Sie zeigen, welche autonomen Systeme Präfixe ankündigten und welche Pfade öffentliche Messstellen sahen. Sie beweisen aber nicht allein, an welcher Stelle eine HTTP-Antwort verändert wurde. Interne Leitungen, private Peering-Beziehungen und nicht öffentlich sichtbare Policy-Systeme bleiben außerhalb des öffentlichen Kontrollbildes.

Auch IP-Zuweisungen und Geolokationsangaben haben Grenzen. Ein Registereintrag benennt eine Zuweisung oder administrative Kontaktstelle. Er beweist weder, welches konkrete Gerät zu einem Zeitpunkt eine Antwort erzeugte, noch welcher Mensch dieses Gerät steuerte. Das Register ist ein Ledger und Ausgangspunkt der Untersuchung – kein Urteil.

Drittressourcen: kontrollierte Abhängigkeit, nicht automatische Täterschaft

Der rekonstruierte Mechanismus beruhte darauf, dass Browser Drittressourcen über unverschlüsseltes HTTP anforderten. Damit werden Ressourcenanbieter und einbettende Webseiten Teil der Kontrollkarte. Das macht sie nicht automatisch zu Beteiligten am Angriff.

Ein Ressourcenanbieter kontrolliert, ob seine Inhalte über authentisierte Verbindungen verfügbar sind, welche Weiterleitungen gelten, wie Änderungen dokumentiert werden und wie er Meldungen über abweichende Antworten untersucht. Eine einbettende Seite entscheidet, welche externen Skripte sie in den Ausführungskontext ihrer Besucher holt. Browser wiederum legen fest, wie sie unsichere oder gemischte Inhalte behandeln.

Baidus Dementi ist gerade deshalb zentral. [8] On-Path-Substitution kann einen legitimen Anbieter so erscheinen lassen, als habe er Code ausgeliefert, den seine eigenen Systeme nach seiner Darstellung nicht erzeugten. Verantwortliche Analyse fragt deshalb nicht zuerst, wem der sichtbare Ressourcenname gehört, sondern was die Ursprungsprotokolle zeigen, was Clients aus mehreren Netzen erhielten und ob die Übertragung authentisiert war.

Organisationen sollten ein belastbares Inventar externer Abhängigkeiten führen. Für jede ausführbare Ressource sind mindestens Schema, Hostname, Betreiber, erwartete Funktion, Aktualisierungsweg, Integritätsschutz und Ausfallverhalten relevant. Ein fremdes Skript hat ein anderes Risikoprofil als ein statisches Bild, weil es im Browser weitere Kommunikation auslösen kann.

Subresource Integrity und Content-Security-Policy können in geeigneten Architekturen zusätzliche Grenzen setzen. Auch sie wirken nur innerhalb ihres jeweiligen Modells. Ein vertrauenswürdiger Hash muss sicher zum Browser gelangen; dynamisch wechselnde Inhalte können die Nutzung erschweren; eine unvollständige Policy kann Lücken lassen. Keine Einzelmaßnahme ersetzt die Kontrolle der gesamten Abhängigkeitskette.

Browser zwischen Ausführungsmacht und legitimer Funktion

Der Browser entscheidet, ob empfangener Code ausgeführt wird und welche Netzhandlungen daraus folgen dürfen. Er setzt Same-Origin-Regeln um, prüft Zertifikate, behandelt Mixed Content und vermittelt Anfragen zwischen Seite und Netz. Damit besitzt er eine reale Kontrolloberfläche, die im Great-Cannon-Ereignis sichtbar wurde.

Ein Browser kann jedoch nicht jede wiederholte Anfrage als bösartig einstufen. Moderne Webanwendungen erzeugen viele Hintergrundanfragen, aktualisieren Daten und nutzen verschiedene Ursprünge. Zu strenge Grenzen beschädigen legitime Funktionen; zu lockere Grenzen erleichtern den Missbrauch. Die angemessene Aufgabe liegt daher in nachvollziehbaren, evidenzbasierten Begrenzungen.

Dazu gehören sichere Standardeinstellungen für Transport, deutliche Einschränkungen ungeschützter aktiver Inhalte, Kontrolle ungewöhnlicher Hintergrundaktivität und Diagnosemöglichkeiten für unerwartete ursprungsübergreifende Anfragemuster. Browserhersteller können außerdem Werkzeuge bereitstellen, mit denen sich abweichende Inhalte und Ausführungsfolgen sichern lassen, ohne unnötig das übrige Surfverhalten offenzulegen.

Die beteiligten Browser waren nicht automatisch dauerhaft kompromittierte Bots. Der öffentlich beschriebene Vorgang erforderte keine Behauptung, jeder Client sei infiziert, fernadministriert oder dauerhaft unter Kontrolle eines Angreifers gewesen. Präzise Sprache unterscheidet zeitweilige Ausführung injizierten Codes von einer konventionellen Botnetzinfektion.

DDoS-Abwehr ohne falsche Gleichsetzung

RFC 4732 ordnet Denial-of-Service-Risiken anhand von Ressourcenerschöpfung, Verstärkung und Protokolldesign ein. [11] Diese Grundsätze helfen, belastbare Dienste zu entwerfen, beweisen aber nicht den genauen Aufbau des Great Cannon.

Browsergenerierte Anwendungsanfragen erfordern Schutz auf mehreren Ebenen. Netzkontrollen können Verkehr verteilen oder absorbieren. Transportkontrollen können Verbindungsdruck begrenzen. Anwendungslogik kann Wiederholungsmuster, besonders teure Pfade und abweichendes Verhalten erkennen. Caches können kostengünstige Antworten bereitstellen. Externe Anbieter können zusätzliche Filter- und Bereinigungskapazität übernehmen.

Jede Maßnahme erzeugt Nebenwirkungen. Aggressive Sperren können legitime Benutzer ausschließen. Interaktive Prüfungen können Barrieren für Menschen mit Einschränkungen schaffen. Ratenbegrenzungen können ganze gemeinsam genutzte Zugangsnetze benachteiligen. Eine Verlagerung von Verkehr kann einen bislang unbelasteten Pfad überfordern. Das Entfernen des angegriffenen Inhalts kann dem Angreifer genau die geforderte Steuerungsmacht verschaffen.

Daher genügt die Aussage „der Angriff wurde abgewehrt“ nicht. Ein verantwortlicher Bericht muss zeigen, welche beobachtete Eigenschaft eine Maßnahme adressierte, wie sich die Systemgesundheit anschließend änderte und welche Kollateraleffekte entstanden. Wo öffentliche Offenlegung Sicherheitsrisiken erzeugt, müssen zumindest intern vollständige und nachprüfbare Aufzeichnungen erhalten bleiben.

Mitigationsanbieter besitzen häufig besonders wertvolle Beobachtungen: Verkehr vor und nach der Filterung, Klassifikationen, Routenänderungen, Kapazitätsgrenzen und Fehlerquoten. Verträge sollten sicherstellen, dass der betroffene Dienst auf relevante Ereignisdaten zugreifen kann. Auslagerung der technischen Abwehr darf nicht zur Auslagerung der Beweisführung führen.

Minderung und Betreiberzuordnung müssen getrennt bleiben

Betriebsteams können nicht auf vollständige Betreiberzuordnung warten, bevor sie einen überlasteten Dienst schützen. GitHub musste auf messbare Eigenschaften reagieren: Zielpfade, Anfragehäufigkeit, Verbindungsverhalten, Ressourcenkosten und Dienstzustand. Ob die wahrscheinlichste politische oder institutionelle Zuordnung bereits feststand, änderte nichts an der unmittelbaren Notwendigkeit der Abwehr.

Umgekehrt beweist eine erfolgreiche Filterregel nichts über den Betreiber des Injektionssystems. Zuordnung beruht auf einer Kombination aus technischer Position, Codeeigenschaften, Zielauswahl, Zeitmustern, Infrastrukturbeziehungen und alternativen Erklärungen. Jede Kategorie trägt ein eigenes Vertrauensniveau.

Der Wert der Citizen-Lab-Forschung liegt darin, dass sie nicht bei einer politischen Bezeichnung stehen blieb. Sie beschrieb einen Mechanismus, unterschied technische Systeme und stützte die Einschätzung mit Messungen. [2][3] Die begleitenden wissenschaftlichen Veröffentlichungen erweiterten diese technische Prüfung. [4][5][6] Dennoch bleibt eine forschungsbasierte Betreiberbewertung etwas anderes als ein rechtskräftiges Urteil.

GreatFires Zuordnung, GitHubs Interpretation des ausgeübten Drucks, Baidus Dementi und die unabhängigen Messungen können gleichzeitig Bestandteil einer sorgfältigen Darstellung sein. Sie dürfen nicht in einen künstlichen Konsens verschmolzen werden. Verantwortlichkeit gewinnt an Glaubwürdigkeit, wenn Widersprüche und unterschiedliche Beweisstärken sichtbar bleiben.

Ein Mindestbestand überprüfbarer Ereignisdaten

Ein vergleichbares Ereignis sollte anhand eines verknüpften Beweisbestands rekonstruierbar sein. Dazu gehören:

1. Ereignisidentität und Zeitqualität

Ein stabiler Ereignisbezeichner, UTC-Zeitpunkte, verwendete Zeitquellen, bekannte Uhrabweichungen und Verzögerungen bei der Erfassung. Erste Beobachtung, bestätigter Vorfall, Gegenmaßnahmen, Stabilisierung und Abschluss müssen getrennte Zeitpunkte bleiben.

2. Ressourcen- und Transportidentität

Angeforderte Ressource, Schema, Hostname, Resolverergebnis, erwarteter Ursprung, Zertifikatsdaten, Antwortmetadaten, Inhalts-Hash und Browserentscheidung. Wenn rechtmäßig verfügbar, sollten sowohl veränderte als auch legitime Antwortbeispiele gesichert werden.

3. Beobachtungen aus mehreren Netzen

Messstandort, Netzbetreiber, sichtbarer Routenkontext, Antwortzeit und empfangener Inhalt. Öffentliche BGP-Daten und interne Routenschnappschüsse können die Einordnung verbessern, ohne als alleiniger Beweis für den Injektionsort ausgegeben zu werden.

4. Browserausführung

Verhalten des Codes, Zielanfragen, Wiederholungsmuster, Browserversion, relevante Sicherheitsrichtlinien und erforderliche Benutzeraktion. Vorübergehende Ausführung muss von dauerhafter Kompromittierung unterschieden werden.

5. Dienstzustand am Ziel

Anfrageraten, Zielpfade, Edge- und Anwendungsgesundheit, Filteränderungen, Übergaben an Mitigationsanbieter, Latenz, Fehlerraten und beobachtete Auswirkungen. Jede Maßnahme sollte mit einer messbaren Zustandsänderung verknüpft sein.

6. Kontrollnachweise der Betreiber

Für Systeme mit Inspektions- oder Veränderungsfähigkeit: autorisierende Policy, Konfigurationsänderungen, Zugriffsrechte, Freigaben und Integritätsprotokolle. Betreiber außerhalb des verdächtigen Weges sollten ihre tatsächliche Grenze belegen können, statt nur eine pauschale Erklärung abzugeben.

7. Zuordnungsbewertung

Beobachtete Tatsachen, analytische Schlussfolgerungen, Vertrauensniveau und Alternativerklärungen müssen getrennt dokumentiert werden. Externe Zuordnungen sind mit ihrem jeweiligen Urheber zu benennen.

8. Datenschutz und Aufbewahrung

Netz- und Browserdaten können persönliche Informationen enthalten. Erfassung und Aufbewahrung müssen auf das Erforderliche begrenzt, Zugriffe kontrolliert und Veränderungen an den Beweismitteln dokumentiert werden. Datenschutz verlangt sorgfältige Beweissicherung, nicht Beweislosigkeit.

Ökonomische Anreize und betriebliche Kontinuität

Netzsicherheit leidet häufig darunter, dass derjenige, der eine Schutzmaßnahme umsetzen kann, nicht den größten Schaden ihres Fehlens trägt. Ein Ressourcenanbieter kann eine alte unverschlüsselte Schnittstelle weiterbetreiben, während fremde Webseiten, Benutzer und Angriffziele die Folgen einer Veränderung tragen. Ein Transitbetreiber kann geringe kommerzielle Anreize für langfristige Ereignisprotokolle haben. GitHub musste Kapazität für Verkehr bereitstellen, der aus Browsern stammte, die es weder verwaltete noch angeworben hatte.

Verträge können diese Lücken verkleinern. Hosting- und Mitigationsvereinbarungen können Zugangsrechte zu Ereignisdaten, Aufbewahrungszeiten, Zeitqualität, Unterstützung bei Tests und Regeln für Routenänderungen festlegen. Beschaffungsrichtlinien können authentisierte Auslieferung und ein Inventar aktiver Drittressourcen verlangen. Solche Dokumente beweisen die technische Umsetzung nicht; sie definieren nur Erwartungen, die am laufenden Betrieb geprüft werden müssen.

Kontinuität ist dabei mehr als bloße Erreichbarkeit. Ein Dienst kann technisch online bleiben und dennoch seine wesentliche Funktion verlieren, wenn er unter Angriffsdruck Inhalte entfernt oder legitime Benutzer massenhaft aussperrt. Umgekehrt ist eine starre Haltung ohne angemessene Schutzmaßnahmen keine belastbare Betriebsstrategie. Verantwortliche Kontinuität verbindet Verfügbarkeit, Inhaltsintegrität, nachvollziehbare Entscheidungen und reversible Gegenmaßnahmen.

GitHubs Aufgabe bestand daher nicht darin, allein ein politisches Symbol zu verteidigen. Sie bestand darin, seine Hosting- und Netzidentität unter Last technisch glaubwürdig zu erhalten. Das heißt: Zielinhalte mussten unverändert bleiben, der übrige Dienst durfte nicht unnötig beeinträchtigt werden, und Schutzentscheidungen mussten sich an gemessenen Wirkungen statt an bloßen Vermutungen orientieren.

Spätere Wiederverwendung bleibt ein eigener Sachverhalt

Spätere Veröffentlichungen berichteten über erneute Aktivitäten von Werkzeugen, die als Great Cannon bezeichnet wurden. [10][18] Diese Berichte zeigen, warum dauerhafte Mehrpunktmessung, authentisierte Auslieferung und der Austausch technischer Nachweise wichtig bleiben.

Sie erlauben jedoch nicht, spätere Ereignisse rückwirkend mit dem GitHub-Angriff von März 2015 gleichzusetzen. Zielauswahl, Infrastruktur, Betreiber, technische Konfiguration und Befehlsketten können sich unterscheiden. Ein wiederkehrender Name ist kein Beweis für eine unveränderte operative Einheit.

Die Ereignisidentität muss deshalb stabil bleiben. Der GreatFire-GitHub-Zusammenhang von März 2015 besitzt eigene Daten, Ziele, Messungen und Aussagen betroffener Parteien. Spätere Beobachtungen können Hypothesen anregen oder die fortdauernde Relevanz eines Mechanismus zeigen. Sie dürfen die Lücken des ursprünglichen Befunds nicht nachträglich mit fremden Details füllen.

Kontrollalternativen und ihre Grenzen

Ein disziplinierter Rückblick fragt nicht, welche einzelne Maßnahme alles gelöst hätte. Er untersucht, welche Eigenschaft eine Maßnahme verändert hätte und welche Angriffswege offen geblieben wären.

Wäre die Drittressource durchgehend über korrekt authentisierte Verschlüsselung ausgeliefert worden, wäre die direkte, unbemerkte Ersetzung der Antwort schwieriger gewesen. Daraus folgt nicht, dass der verantwortliche Akteur sein Ziel aufgegeben hätte. Blockaden, Verbindungsabbrüche, andere ungeschützte Ressourcen, Endpunktangriffe oder ein anderer DDoS-Vektor wären weiterhin möglich gewesen.

Hätten Browser unerwartete, repetitive Hintergrundaktivität strenger begrenzt, hätte dies möglicherweise die erzeugte Last reduziert. Eine solche Grenze müsste zugleich legitime dynamische Anwendungen berücksichtigen und mit veränderlichen Anfrageintervallen umgehen können.

Mehr Edge-Kapazität bei GitHub hätte den Dienst widerstandsfähiger machen können. Sie hätte aber nicht die entfernte Verletzung der Antwortintegrität behoben. Der öffentliche Befund erlaubt auch keine seriöse Zahl darüber, wie viel zusätzliche Kapazität erforderlich gewesen wäre.

Eine flächendeckende Quelladressvalidierung hätte zahlreiche gefälschte Reflexionsangriffe erschwert. Gegen plausible Clientverbindungen aus realen Browsern hätte sie allein nicht ausgereicht. RPKI hätte die Vertrauenswürdigkeit bestimmter Routenursprungsangaben verbessern können, aber nicht den Inhalt einer unverschlüsselten Antwort authentisiert.

Genau daraus entsteht die Lehre der geschichteten Kontrolle: Antwortintegrität, Routingvertrauen, Quelladressvalidierung, Browsergrenzen, Edge-Mitigation und beweisfähiger Betrieb behandeln verschiedene Teile des Problems. Fortschritt entsteht durch ihre Verbindung, nicht durch die Suche nach einer universellen Einzelmaßnahme.

Ein Verantwortungsstandard für On-Path-Injektion

Aus dem Ereignis lassen sich acht dauerhafte Anforderungen ableiten:

Ausführbare Ressourcen authentisieren. Unverschlüsselte Skripte schaffen eine direkte Gelegenheit für Veränderung auf dem Weg.
Abhängigkeiten vollständig inventarisieren. Betreiber müssen wissen, welche externen Inhalte im Browser Code ausführen dürfen.
Aus mehreren Netzen messen. Ursprungsprotokolle zeigen nicht alles, was ein Client tatsächlich empfängt.
Kontrolle nach Ebenen zuordnen. Ressource, DNS, Routing, Transit, Browser, GitHub-Edge und Mitigation besitzen unterschiedliche Verantwortliche.
Maßnahmen mit Ergebnissen verbinden. Filter, Kapazitätsänderungen und Routenentscheidungen brauchen Zeitpunkt, Eigentümer, Ziel, Wirkung und Rückfallbedingung.
Zuordnungsgewissheit begrenzen. Eine wahrscheinliche Betreiberbewertung darf nicht zu einer erfundenen individuellen Befehlskette werden.
Unbeteiligte Benutzer schützen. Ein angeworbener Browser ist nicht mit einem willentlichen Angreifer gleichzusetzen.
Register am laufenden Netz prüfen. Administrative Identität gewinnt ihren Wert erst durch den Abgleich mit tatsächlich beobachteter Auslieferung.

Schlussfolgerung

GitHubs Great-Cannon-DDoS von 2015 war eine Bewährungsprobe für Netzverantwortung, weil der entscheidende Kontrollpunkt zwischen einer erwarteten Webressource und dem im Browser ausgeführten Code lag. Der Angriff nutzte nach der öffentlichen technischen Rekonstruktion gewöhnliche Clients, echte Adressen und gemeinsam genutzte Übertragungswege. Dadurch wurden die Grenzen einfacher Erklärungen sichtbar, die allein auf Botnetze, gefälschte Quelladressen oder eine Überlastung des Zielsystems schauen.

Der belastbare Befund ist enger als manche spätere Erzählung, aber gerade deshalb aussagekräftig. GitHub erlebte einen außergewöhnlich großen, nach eigener Einschätzung inhaltsbezogenen DDoS-Angriff. GreatFire dokumentierte einen vorausgehenden Angriff und schrieb die Aktivität chinesischen Behörden zu. Forschende maßen einen Mechanismus zur selektiven Veränderung unverschlüsselter Antworten und stützten eine wahrscheinliche Betreiberbewertung. Baidu bestritt, dass seine Produkte kompromittiert worden seien.

Vollständige Verkehrsmengen, Benutzerzahlen, finanzielle Schäden, genaue Wiederherstellungszeiten und individuelle Befehlswege sind öffentlich nicht belegt.

Verantwortung folgt den tatsächlichen Kontrollgrenzen. Betreiber auf dem Übertragungsweg müssen Veränderungen und Zugriffe überprüfbar machen. Ressourcenanbieter und einbettende Seiten müssen aktive Abhängigkeiten und authentisierte Auslieferung beherrschen. Browser müssen die stille Nutzung ihrer Netzfähigkeit begrenzen. GitHub und seine Mitigationspartner müssen Schutzmaßnahmen mit gemessenen Auswirkungen verbinden. Forschende und öffentliche Stellen müssen Beobachtung, Schlussfolgerung und Zuordnung auseinanderhalten.

Die dauerhafte Regel lautet: Ein Netz ist nicht nur nach seinen Einträgen, Adressen und Verträgen zu beurteilen, sondern nach den Inhalten und dem Verhalten, die es wirklich hervorgebracht hat. Register beschreiben vorgesehene Autorität. Der laufende Code zeigt, ob diese Autorität in der Realität Bestand hatte. Wo beides auseinanderfällt, beginnt Verantwortlichkeit damit, die Abweichung messbar, nachvollziehbar und bestreitbar zu machen.

GitHubs Great-Cannon-DDoS von 2015 machte On-Path-Codeinjektion zur Bewährungsprobe für Netzverantwortung