Zusammenfassung

  • Die unbefugte Ankündigung von 162.55.80.0/24 beließ Hetzners AS24940 als scheinbaren Ursprung im Pfad und wurde wegen einer bis /24 offenen ROA als RPKI Valid eingestuft.
  • Virtualizor rekonstruierte die Verbreitung anhand von 368 RIPE-RIS-Peers, konnte aber keine endgültige Liste betroffener Installationen erstellen, weil die Antworten des Angreifers nie in den eigenen Logs erschienen.
  • Benötigt wird ein datensparsamer Update-Beleg am Installationsort, der angeforderte Version, signiertes Manifest, Paket-Hash, akzeptierten Schlüssel, Prüfergebnis sowie Installation oder Rollback verbindet.

Bei Sicherheitsvorfällen beansprucht die größte Zahl im Bericht häufig eine Bedeutung, die sie nicht besitzt. In diesem Fall lautet sie 368. Virtualizor berichtet, dass alle 368 Peers der untersuchten RIPE-RIS-Menge die entführte Route irgendwann während des Vorfalls führten. Das ist ein aussagekräftiger Befund über ihre topologische Reichweite. Es ist keine Zahl der Kunden, Update-Anfragen, abgeschlossenen Downloads oder kompromittierten Server.

Die Trennung ist für die Beweiskette entscheidend. BGP-Kollektoren sehen angekündigte Pfade. Eine Zertifizierungsstelle protokolliert Domainprüfung und Zertifikatsausstellung. Der Rechner des Angreifers sieht die umgeleiteten Anfragen. Jede Virtualizor-Installation entscheidet lokal, ob sie ein Paket anfordert, akzeptiert und ausführt. Der Angriff berührte alle vier Ebenen, doch keine Ebene beobachtet dieselbe Grundgesamtheit wie die andere.

LACNIC veröffentlichte am 10. September 2026 eine spanische Fassung der Kentik-Analyse. Damit wurde der Fall zu einem aktuellen Signal für die regionale Betreiber-Community. LACNIC war aber nicht Betreiber der betroffenen Systeme. Die Seite weist ausdrücklich darauf hin, dass die Ansichten der Autoren nicht zwingend die Ansichten des Registers sind. Saubere Zuordnung gehört zur Analyse: LACNIC veröffentlichte, Kentik untersuchte die Route, Virtualizor beschrieb den Produktschaden.

Was RPKI Valid hier bedeutete

Gegen 20:57 UTC am 28. August erschien 162.55.80.0/24 in der globalen Routing-Tabelle; der Pfad endete auf 6204 62390 24940. Das /24 war spezifischer als Hetzners gewöhnliche Ankündigung 162.55.0.0/16. Wo Router beide Wege akzeptierten, zog Longest Prefix Match den Verkehr für das /24 zur neuen Route.

Der Angreifer ersetzte den sichtbaren Ursprung nicht. AS24940 von Hetzner blieb am rechten Ende des AS path stehen. Die abdeckende ROA erlaubte diesen Ursprung und Präfixlängen bis /24. Die Ursprungsvalidierung konnte deshalb RPKI Valid melden. Sie bestätigte, dass Präfix, Länge und letztes AS in eine veröffentlichte Autorisierung passten. Sie bestätigte weder AS62390 als berechtigten Upstream noch die Wahrheit der vorherigen Nachbarschaften.

RFC 9319 beschreibt diese Angriffsklasse als Forged-Origin Sub-Prefix Hijack. Deckt eine nicht minimale ROA spezifischere Präfixe ab, die der Inhaber gar nicht ankündigt, kann ein Gegner den autorisierten Ursprung an seinen Pfad hängen und den freien Teilraum besetzen. Die Empfehlung für minimale ROAs schließt diese Lücke, wo der Betrieb es zulässt. Sie macht aus Ursprungsvalidierung jedoch keine kryptografische Bestätigung des gesamten Pfads.

„Gültig“ braucht daher ein Objekt. Für den Ursprung gültig bedeutet nicht: Pfad genehmigt, Upstream autorisiert, Endpunkt echt oder Software vertrauenswürdig. Diese Begrenzung entwertet RPKI nicht. Sie schützt dessen Nutzen vor einer überzogenen Zusage. Die Prüfung beantwortete ihre vorgesehene Frage; der Angreifer nutzte eine unbeantwortete.

Virtualizor setzt den Vorfall ungefähr von 20:57 UTC am 28. August bis 06:10 UTC am 30. August an. Zwei aktive Wellen waren durch eine etwa elf Stunden lange Ruhephase getrennt. Die Rekonstruktion zählt rund 10.600 Route Withdrawals. Ein Zehn-Minuten-Raster ist bei solchem Flapping kein lückenloser Film. Nach Angaben des Anbieters sind die mit den achtstündlichen RIB-Dumps ausgerichteten Zeitpunkte zuverlässiger; dazwischen können sichtbare Peers unterzählt werden.

Auch 368 von 368 enthält eine Zeitbedingung. Jeder Peer sah die Route mindestens einmal, nicht alle sahen sie gleichzeitig. Auf dem Höhepunkt einer aktiven Welle waren ungefähr 72 Prozent der vollständigen 368er-Menge betroffen. Selbst dieser Anteil ist ein Topologie-Proxy und keine Byte-Messung. Ein Peer eines großen Transitnetzes und der eines kleineren Teilnehmers zählen gleich. Wer daraus Kundenwirkung ableitet, wechselt unbemerkt den Nenner.

Ein gültiges Zertifikat für das falsche Ziel

Die Umleitung erfasste auch den Verkehr zur Domainvalidierung. Virtualizor zufolge erhielt der Angreifer ein technisch gültiges TLS-Zertifikat für mehrere Namen aus der Softaculous-Produktfamilie, darunter Verteilendpunkte. Ein fehlgeleiteter Client konnte deshalb ohne Zertifikatswarnung eine verschlüsselte Verbindung aufbauen. TLS schützte die Sitzung mit dem vom Routing gelieferten Ziel. Es brachte den Client nicht zum vom Hersteller beabsichtigten Ziel zurück.

Multi-Perspective Issuance Corroboration, MPIC, soll diesen Angriff verteuern. Statt einer einzelnen Netzwerkposition lässt eine Zertifizierungsstelle mehrere entfernte Perspektiven die Domainkontrolle bestätigen. Für die einschlägigen Prüfungen verlangen die geltenden CA/Browser-Forum-Regeln seit dem 15. Juni 2026 mindestens vier entfernte Perspektiven; bestätigende Perspektiven müssen mindestens zwei RIR-Service-Regionen abdecken. Let’s Encrypt erläutert seit Jahren, warum eine einzelne Prüfung durch das Entführen oder Umlenken ihres Pfads getäuscht werden kann.

Die Ausstellung des Zertifikats macht MPIC nicht wertlos. Kentiks Aussage ist enger: Eine unbestrittene, spezifischere Route verbreitete sich so weit, dass genügend Perspektiven dieselbe Antwort des Angreifers sahen. Mehrere Standorte entdecken eine lokale Lüge durch Widerspruch. Wird die Lüge zur gemeinsamen Sicht, kann das Quorum dem falschen Ziel zustimmen. Strikte ROAs, Pfadwarnungen, path-bewusste Kontrollen und tatsächlich diverse Zertifikatsperspektiven bleiben unterschiedliche, sich ergänzende Sicherungen.

Das legitime Log kann eine fremde Antwort nicht enthalten

Virtualizor bestätigt, dass ein bösartiges Paket eine kleine Zahl von Installationen erreichte, beschrieben auch als eine Handvoll Server. Zugleich kann das Unternehmen keine endgültige Liste erstellen. Die bösartigen Antworten kamen vom System des Angreifers und erreichten die eigenen Logs nie.

Das ist kein Widerspruch. Ein Origin-Log erfasst nur Anfragen, die diesen Origin erreichen. Fehlt während einer erfolgreichen Umleitung eine Zeile, kann der Client untätig gewesen sein oder ein anderer Server hat geantwortet. Genau wenn der Gegner den Verkehr gewinnt, wird das zentrale Log der legitimen Seite unvollständig. Eine erneute Auswertung kann keine Transaktion finden, an der der Server nie beteiligt war.

Der normale Update-Ablauf vergrößert die Kosten der Blindstelle. Laut Virtualizor-Dokumentation sucht das Produkt standardmäßig alle 24 Stunden nach Updates, sofern die Automatik nicht abgeschaltet ist. Administratoren können den Vorgang zudem im Panel oder auf der Kommandozeile auslösen. Für eine belastbare Eingrenzung müsste man wissen, welche Installationen während der aktiven Stunden prüften, welche Anfragen gerade umgeleitet wurden, welche Downloads vollständig waren, welche Pakete angenommen und welche ausgeführt wurden. Die Routing-Tabelle kennt keine dieser Spalten.

Der Anbieter benennt eine weitere zentrale Schwäche: Die Update-Clients prüften Pakete zu diesem Zeitpunkt noch nicht kryptografisch. Künftig sollen alle Pakete signiert werden. Das ist die unverzichtbare Prävention. Ein privilegierter Updater muss signierte Metadaten, Paket-Hash, Version, Kanal und autorisierten Schlüssel prüfen und bei einem Fehler geschlossen abbrechen. Transportsicherheit darf nicht allein über die Echtheit ausführbaren Codes entscheiden.

Signatur und nachträgliche Zuordnung sind allerdings verschiedene Kontrollen. Eine Signatur kann ein künftig nicht autorisiertes Paket zurückweisen. Sie sagt nicht automatisch, was jede Maschine in der Vergangenheit getan hat. Auch mit Signaturen braucht der Betreiber einen Nachweis: angeforderte Version, empfangener Hash, akzeptierter Schlüssel, Prüfergebnis, Installation, Quarantäne oder Rollback.

Der fehlende Beleg gehört auf die Installation

Jeder Update-Versuch sollte dort, wo entschieden wird, einen kleinen manipulationssichtbaren Beleg erzeugen. Er enthält Kanal und angeforderte Version, Zeitpunkt, Hash des signierten Manifests, Paket-Hash, akzeptierten Schlüssel oder Schwellwert, Verifikationsergebnis und lokalen Ausgang: Zurückweisung, Quarantäne, Installation, Fehler oder Rückkehr. Spätere Sperrungen, Incident-Mitteilungen und Reparaturpakete müssen auf denselben Beleg verweisen können.

Dafür muss keine Kundenliste veröffentlicht werden. Der Betreiber kann den Beleg behalten, das Gerät oder die Flotte pseudonym bezeichnen und nur die im Vorfall notwendige Evidenz offenlegen. Der Anbieter könnte optional quittieren: Er nimmt einen verblindeten oder pseudonymen Beleg an und gibt einen Zeitstempel zurück. Große Betreiber aggregieren intern, kleine exportieren beim Support-Fall den Datensatz einer Maschine. Datenschutz begrenzt Erhebung; er verlangt keine Beweislosigkeit.

Der Beleg verbindet zwei Aussagen. Das Release-Register des Anbieters legt fest, welches Manifest, Paket und welche Schlüssel genehmigt waren. Der lokale Datensatz sagt, was diese Installation angefordert, geprüft und entschieden hat. Kontrolliert ein Angreifer Route und Webserver, nicht aber den Signaturschlüssel, bleibt die Zurückweisung sichtbar. Wird ein Schlüssel später widerrufen, sind die ihn akzeptierenden Systeme auffindbar. Hat der Prüfer selbst einen Fehler, grenzt der Paket-Hash die tatsächliche Population ein.

Zugleich ordnet der Beleg fünf oft vermischte Begriffe. Ein RIPE-Peer mit der Route belegt mögliche Netzexposition. Eine Anfrage während der Umleitung schafft eine Lieferchance. Ein fertiger Download belegt Erwerb. Eine Installation belegt Ausführung. Ein Schadindikator belegt Auswirkung. Diese Stufen sind Filter, keine Synonyme. Jede Zahl braucht ihren Nenner, ihre Beobachtungsmethode und ihre Unsicherheit.

Eine substanzielle Reaktion, aber ohne lokale Quittungen

Die stärkste Verteidigung des Anbieters gehört vor die Kritik. Virtualizor veröffentlichte die Lieferung, nannte einen Kompromittierungsindikator, verlangte Schlüsselwechsel und Zugriffsbeschränkungen, empfahl Prüfung und Beweissicherung, meldete das Zertifikat zum Widerruf, rekonstruierte die Routen und sagte Paketsignaturen zu. Kentik und LACNIC erklärten minimale ROAs und Monitoring, ohne aus der Ursprungsprüfung eine komplette Pfadgarantie zu machen.

Der Mangel besteht nicht darin, dass Virtualizor keine unmögliche Gewissheit aus den Logs des Angreifers gewonnen hat. Die Branche hatte den Entscheidungspunkt nicht verpflichtet, einen portablen Nachweis zu schreiben. Antwortete der falsche Server, war das zentrale Log kein Teil der Transaktion mehr. Die unabhängige Evidenz musste auf der Installation liegen. Alle Betreiber zur Prüfung aufzurufen ist bei unbekannter Population vernünftig; es ist zugleich der operative Preis fehlender Belege.

Ein reifer nächster Bericht sollte drei Register nebeneinanderlegen können. Das Routing-Register nennt Perspektive, Pfad und Zeit. Das Release-Register nennt Manifest, Paket, Version und Schlüssel. Das Installationsregister nennt die lokale Entscheidung. Keines ersetzt ein anderes. Zusammen machen sie aus einer Warnung an alle eine begründete Reparaturliste.

Quellen