BGP-Hijack und gefälschtes TLS-Zertifikat treffen Softaculous

Ein BGP-Hijack wurde genutzt, um einen Angriff auf einen Hosting-Software-Anbieter zu unterstützen. BGP, das Border Gateway Protocol, ist das System, mit dem Netzwerke im Internet einander mitteilen, welche Adressblöcke sie erreichen können. Softaculous Ltd, das Unternehmen hinter dem Softaculous-Auto-Installer und der Virtualizor-Plattform zur Verwaltung virtueller Maschinen (Softwareversionen eines Computers, die auf einem physischen Server laufen), hat beschrieben, wie ein Angreifer einen solchen Hijack mit einem technisch gültigen TLS-Zertifikat kombinierte, um ein schädliches Virtualizor-Update-Paket an eine kleine Anzahl von Installationen zu liefern. Das Unternehmen riet Kunden, eine Reihe von Schritten zu befolgen, um zu prüfen, ob sie betroffen waren. Die technische Analyse stammt von Doug Madory, Head of Internet Analysis bei Infoblox, und wurde ursprünglich im Kentik-Blog veröffentlicht.

Wie der Hijack die Adressen übernahm

Am 28. August 2026 um 20:57 UTC gelangte ein neues Präfix in die globale Routing-Tabelle. Ein Präfix ist ein Block von Internetadressen in Kurzschreibweise; dieses hier, 162.55.80.0/24, umfasste Adressen, die vom Software-Update-Endpunkt von Softaculous sowie von dessen Kunden- und Abrechnungsseite verwendet wurden. Es wurde entlang eines AS-Pfads angekündigt, der ? 6204 62390 24940 lautet. Ein AS-Pfad ist die Liste der Netzwerke, die eine Route durchläuft, geschrieben als Nummern, die Autonomous System Numbers (ASNs) genannt werden. Die Ankündigung war ein spezifischerer Teil des größeren Blocks 162.55.0.0/16, der normalerweise von Hetzner Online (AS24940) originert wird. Die Route stammte wahrscheinlich vom zweitletzten Netzwerk im Pfad, NexonHost (AS62390), entweder weil dieses Netzwerk kompromittiert wurde oder weil ein Kunde Lücken in dessen Sicherheit ausnutzte.

Warum es legitim aussah

Der Pfad trug auch einen gefälschten Origin. Durch das Anhängen von 24940 als rechteste Nummer ließ der Angreifer die Route RPKI-gültig erscheinen. RPKI, die Resource Public Key Infrastructure, ist ein System signierter Datensätze, die angeben, welches Netzwerk welche Adressen ankündigen darf. Die Route passierte aus zwei Gründen: Hetzners Route Origin Authorization (ROA, der signierte Datensatz selbst) erforderte AS24940 als Origin, und sie erlaubte eine Präfixlänge zwischen /24 und /16. Netzwerke, die RPKI-ungültige Routen ablehnen, hatten daher keinen Grund, sie zu verwerfen. Da keine andere Route für 162.55.80.0/24 existierte, die mit ihr konkurrierte, verbreitete sich die Ankündigung so weit, wie es die Filterrichtlinien zuließen. Router bevorzugen immer die spezifischste verfügbare Übereinstimmung, sodass Datenverkehr, der für diesen Adressbereich bestimmt war, auf die gekaperte Route umgeleitet wurde, anstatt der echten 162.55.0.0/16 zu folgen.

Wie lange es dauerte

Kentiks BGP-Visualisierung, die den Anteil der BGP-Vantage-Points (unabhängige Beobachtungspunkte im Internet) zeigt, die 162.55.80.0/24 über die Zeit in ihren Routing-Tabellen hatten, zeichnet die Zeitachse nach. Vom ersten Erscheinen der Route am 28. August um 20:57 UTC an pulsierte sie mehrmals an und aus, bis das echte AS24940 fast 12 Stunden später, am 29. August um 08:44 UTC, das Präfix selbst ankündigte. Bis 14:10 UTC am nächsten Tag hatte AS24940 es wieder zurückgezogen. Der Hijack kehrte am 29. August um 19:55 UTC zurück und pulsierte wiederholt, bis AS24940 erneut eingriff und 162.55.80.0/24 am 30. August um 05:45 UTC ankündigte, woraufhin der Hijack zurückgezogen wurde. Zum Zeitpunkt des Schreibens kündigte AS24940 das Präfix noch immer an. Das Diagramm zeigt, dass sich die gekaperte Route etwas weniger weit verbreitete als die legitime, ein Beleg dafür, dass einige Routenfilterung sie begrenzte, aber die Verbreitung war dennoch erheblich und schuf das Potenzial für eine weitreichende Fehlleitung des Datenverkehrs.

Warum ein Routing-Hijack allein nicht ausreichte

Der Angreifer benötigte auch ein gültiges TLS-Zertifikat. TLS ist die Verschlüsselung, die eine Verbindung schützt und auch die Identität einer Website nachweist. Dieselbe Schwachstelle wurde 2022 beim Angriff auf KLAYswap ausgenutzt, eine Online-Kryptowährungsbörse in Südkorea. In ihrem Beitrag zu diesem Vorfall schrieben Henry Birge-Lee und seine Kollegen in Princeton, dass KLAYswap und Kakao TLS ordnungsgemäß verwendeten und dass kein Fehler im TLS-Protokoll selbst ausgenutzt wurde; stattdessen missbrauchte der Angriff das falsche Vertrauen, das TLS in die Routing-Infrastruktur setzt. Der Angreifer richtete seinen Hijack zunächst auf die PKI (Public Key Infrastructure, das System der Zertifizierungsstellen, die Zertifikate ausstellen) und führte einen Man-in-the-Middle-Angriff auf den Zertifikatsverteilungsprozess durch. Erst nachdem er ein gültiges digitales Zertifikat für die Zieldomain erhalten hatte, wandte er sich an echte Nutzer und lieferte eine schädliche JavaScript-Datei über eine verschlüsselte Verbindung aus. Ihr Beitrag trug den Titel "Attackers exploit fundamental flaw in the web's security to steal $2 million in cryptocurrency".

Die Identitätsgarantie von TLS ist nur so vertrauenswürdig wie das Routingsystem, das den Zertifikatsvalidierungsverkehr an den richtigen Ort bringt. Um dies anzugehen, verwendet die öffentliche Zertifizierungsstelle Let's Encrypt seit mehreren Jahren Multi-Perspective Issuance Corroboration (MPIC). Unter MPIC validiert eine Zertifizierungsstelle die Kontrolle über eine Domain nicht von einem einzigen Beobachtungspunkt aus, den ein lokalisierter BGP-Hijack vortäuschen kann. Sie prüft gleichzeitig von mehreren geografisch und topologisch unterschiedlichen Netzwerkstandorten aus und verlangt ein Quorum, das zustimmt, bevor ein Zertifikat ausgestellt wird, sodass ein Hijack, der nur einige Beobachtungspunkte erreicht, durch Uneinigkeit der anderen aufgedeckt wird. In diesem Fall, weil die Hijack-Route eine unangefochtene spezifischere Route war, schuf ihre globale Verbreitung ein Quorum, das vollständig vom Angreifer kontrolliert wurde.

Was frühere Vorfälle zeigten

Im Jahr 2022 zielte ein BGP-Hijack auch auf Celer Bridge, einen von AWS gehosteten Kryptowährungsdienst. In dem Beitrag, den Madory damals schrieb, nannte er AWS' damalige Praxis, sehr liberale ROAs zu verwenden, die mehrere Origins und Präfixe von einer /10 bis hinunter zu einer /24 erlaubten, als Faktor, der die Wirksamkeit der RPKI Route Origin Validation einschränkte. Er schlug eine Alternative vor: das zu tun, was Netzwerke wie Cloudflare und Comcast getan haben, und Origin sowie maximale Präfixlänge genau so festzulegen, wie das Präfix geroutet wird. Dieser Ansatz kostet den Aufwand, eine ROA bei jeder Routenänderung zu aktualisieren, lässt aber wenig Raum für alternative Versionen einer Route. AWS führt jetzt exakte Übereinstimmungen in seinen ROAs durch.

Madory ist vorsichtig, RPKI Route Origin Validation (ROV), die Praxis, Routen anhand signierter Datensätze zu prüfen, nicht als Verteidigung gegen einen entschlossenen Angreifer zu überverkaufen. Angreifer können AS-Pfade fälschen, um Hijacks RPKI-gültig zu machen. Dennoch: Hätte Hetzner Online strikte ROAs mit maximalen Präfixlängen verwendet, die seinen Routen entsprachen, wäre die Verbreitung des Hijacks stark verringert worden, was wiederum MPIC ermöglicht hätte, die Ausstellung eines gültigen TLS-Zertifikats zu verhindern.

Auch eine Erkennung wäre möglich gewesen. Wie beim Celer-Bridge-Angriff hätte BGP-Monitoring Hetzner alarmieren können, dass ein neues /24 aus seinem Adressraum angekündigt wurde, obwohl der gefälschte Origin es legitim erscheinen lassen könnte. Als dieses neue /24 mit einem unerwarteten Upstream, NexonHost (AS62390), auftauchte, hätte ein Alarm auf die Anomalie aufmerksam machen sollen. Das Detail, das es vom Erscheinen eines weiteren Peers von Hetzner Online unterschieden hätte, war, dass der neue Upstream von der überwiegenden Mehrheit der BGP-Vantage-Points gesehen wurde: Das Präfix wurde ausschließlich von diesem relativ unbekannten Hosting-Anbieter transitiert.

Was die Branche daraus mitnehmen sollte

RPKI ROV hat Routing-Pannen deutlich reduziert, ist aber nicht darauf ausgelegt, einen Vorfall wie diesen vollständig zu verhindern. Es funktioniert, indem es die Verbreitung geleakter Fehl-Origins reduziert, die typischerweise auf unschuldigen Fehlern beruhen, und seine Vorteile zeigten sich auch bei sogenannten "absichtlichen, aber auch versehentlichen" Hijacks, wie der Blockierung von Telegram in Indien im Juni. Strengere ROAs hätten es RPKI ROV ermöglicht, die gekaperte Route so weit einzuschränken, dass MPIC das Zertifikat blockieren konnte.

Infrastrukturangriffe wie diese heben Probleme hervor, die nicht auf Kryptowährungen oder Hosting-Software beschränkt sind. Unternehmen, die ihre internetzugewandte Infrastruktur sichern, sollten robustes BGP- und DNS-Monitoring einsetzen und sowohl ihre eigenen Systeme als auch alle internetbasierten Abhängigkeiten beobachten, auf die sie sich verlassen. Sie sollten RPKI-ungültige Routen ablehnen und strikte ROAs für ihren Adressraum erstellen, mit maximalen Präfixlängen, die den tatsächlich verwendeten Präfixlängen ihrer Routen entsprechen. RFC 9319, The Use of MaxLength in the Resource Public Key Infrastructure, besagt, dass es eine Best Current Practice für Netzwerke ist, das maxLength-Attribut in ROAs ganz zu vermeiden, außer unter bestimmten Umständen; das Leer lassen des maxLength-Felds hat denselben Effekt wie das Setzen auf die Präfixlänge. Diese Schritte reduzieren das Zeitfenster für einen Angreifer erheblich.

In einem Update nach der Veröffentlichung seines Beitrags bemerkte Madory, dass Hetzner die ROA für 162.55.0.0/16 geändert hat, um eine maxLength von 16 einzuschließen, wodurch die Möglichkeit eines ähnlichen Subpräfix-Angriffs in Zukunft beseitigt wird. Hetzner tat dasselbe für die ROAs, die 213.133.96.0/19 und 213.239.192.0/18 abdecken, die zuvor eine maxLength von 24 erlaubten und nun 19 bzw. 18 erlauben. Selbst nach diesen drei Korrekturen zeigten 50 der ROAs von AS24940 noch dasselbe Muster: 78.46.0.0/15 wird als /15 geroutet, aber seine ROA erlaubt bis zu /24, eine Lücke von 9, und die meisten /16-Blöcke erlauben ebenfalls /24, obwohl nur das /16 selbst geroutet wird. Die Verschärfung ist daher teilweise, und dasselbe maxLength-Problem besteht über den größten Teil des Adressraums des Netzwerks fort. Separat wies Bryton Herdes von Cloudflare darauf hin, dass Hetzner einen ASPA-Datensatz hinzugefügt hat, eine signierte Liste, die aufzählt, welche Netzwerke autorisiert sind, Datenverkehr für AS24940 zu transportieren. Mit diesem Datensatz sollten Netzwerke, die ASPA prüfen, Routen sofort ablehnen können, deren AS-Pfad einen Upstream von AS24940 enthält, der nicht auf der Liste steht, wie AS62390 in diesem Vorfall.

Für Website-Betreiber lautet die Lehre, dass sowohl der Pfad, den Ihr Datenverkehr nimmt, als auch die Namensauflösungen, auf die sich Ihre Mitarbeiter und Besucher verlassen, es wert sind, beobachtet zu werden. Niemand kann einen Routing-Hijack von der Client-Seite aus rückgängig machen, aber die private und verschlüsselte DNS-Auflösung, wie sie ein Dienst wie AEU DNS bietet, verhindert, dass Namensauflösungen auf dem Weg zum Resolver still beobachtet oder verändert werden, der Teil dieser Kette, den ein Website-Betreiber tatsächlich kontrollieren kann.