BGP-Anomalien während des Stromausfalls in Venezuela

 (loworbitsecurity.com)
2 Punkte von GN⁺ 2026-01-06 | 1 Kommentare | Auf WhatsApp teilen
  • Gleichzeitig mit dem Stromausfall in Venezuela wurden Anomalien im BGP-Routing rund um CANTV (AS8048) beobachtet
  • Laut Daten von Cloudflare Radar wurden am 2. Januar acht IP-Präfixe mit CANTV-Pfaden über ungewöhnliche AS-Pfade geroutet
  • Diese Pfade umfassten Sparkle (Italien) und GlobeNet (Kolumbien); Sparkle wird als „unsicherer“ Anbieter ohne RPKI-Filterung eingestuft
  • Die Analyse mit bgpdump zeigte, dass die CANTV-Nummer (8048) im AS-Pfad zehnmal wiederholt wurde, was nicht zu den üblichen Regeln der Pfadauswahl passt; der betroffene IP-Bereich gehört laut Bestätigung zu Dayco Telecom in Caracas
  • Da BGP-Route-Leak, Stromausfall, Explosion und der Zeitpunkt des Eintreffens des US-Militärs zeitlich nahe beieinanderlagen, wird deutlich, dass es Aktivitäten auf Netzwerkebene gab, die vom Normalzustand abwichen

Stromausfall in Venezuela und BGP-Anomalien

  • Während des Stromausfalls in Venezuela trat ein BGP-Route-Leak rund um CANTV (AS8048) auf
    • In den Daten von Cloudflare Radar wurden acht IP-Präfixe über ungewöhnliche Pfade geroutet, die über CANTV führten
    • Zu den Pfaden gehörten Sparkle (Italien) und GlobeNet (Kolumbien)
  • Cloudflare Radar verzeichnete am 2. Januar einen starken Anstieg von BGP-Announcements und einen Rückgang des öffentlichen IP-Adressraums
    • Die Ursache ist unklar
  • Sparkle wird auf isbgpsafeyet.com als „unsicherer“ Anbieter eingestuft; bestätigt wurde außerdem, dass keine RPKI-Filterung angewendet wird

Analyse der BGP-Daten

  • Mithilfe öffentlicher Daten von ris.ripe.net und des Tools bgpdump wurden fehlende Präfixe, die Cloudflare nicht angezeigt hatte, extrahiert
    • Die Analyse ergab, dass CANTV (8048) im AS-Pfad zehnmal wiederholt wurde
    • Da BGP kürzere Pfade bevorzugt, deutet diese Wiederholung auf eine ungewöhnliche Pfadkonstruktion hin
    Anzeige
  • Alle acht Präfixe befanden sich innerhalb des Blocks 200.74.224.0/20
    • Eine WHOIS-Abfrage bestätigte, dass er Dayco Telecom (mit Sitz in Caracas) gehört
  • Eine Reverse-DNS-Abfrage zeigte, dass der IP-Bereich kritische Infrastruktur wie Banken, Internetanbieter und E-Mail-Server umfasste

Zeitlicher Ablauf des Vorfalls

    1. Januar, 15:40 UTC: BGP-Route-Leak erkannt (Cloudflare Radar)
    1. Januar, ca. 06:00: Explosion in Caracas gemeldet (NPR)
    1. Januar, 06:00: US-Militär erreicht Maduros Residenz (NBC News)
    Anzeige
    1. Januar, 08:29: Maduro an Bord der USS Iwo Jima (CNN)
  • In diesem Zeitraum gibt es Hinweise darauf, dass BGP-Verkehr über einen dritten Transitpunkt umgeleitet wurde; bei Kontrolle dieses Pfads hätte die Möglichkeit zur Informationsgewinnung bestanden

Analyse und Beobachtungen

  • Dass CANTV AS8048 zehnmal in den Pfad eingefügt wurde, hatte den Effekt, die Priorität des Traffics zu senken
    • Ob dies absichtlich geschah, ist unklar, aber es ist eindeutig, dass es ungewöhnliche Manipulationen am Pfad gab
  • Schon auf Basis öffentlich verfügbarer Daten lohnt sich eine weitergehende Analyse der damaligen Netzwerkanomalien
  • Der Beitrag verzichtet auf politische Deutungen und behandelt ausschließlich technische Anomalien aus Sicht offensiver Sicherheit

Weitere sicherheitsbezogene Links

  • MCP Security: Demonstriert, dass bösartige MCP-Server AI-Prompts und Umgebungsvariablen stehlen können
  • The Year in LLMs (2025): Zusammenfassung zu Reasoning-Modellen, Coding Agents, chinesischen Open-Weight-Modellen, MCP-Adoption und mehr
  • Linux is Good Now: Diskussion darüber, ob 2026 das Jahr des Linux-Desktops wird
  • No strcpy Either: Das curl-Projekt entfernt strcpy() und führt Wrapper mit expliziter Puffergröße ein
  • Kubernetes Networking Best Practices: Leitfaden zu CNI-Auswahl, Netzwerk-Policies, Service Mesh und Troubleshooting

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-06
Hacker-News-Kommentare

  • BGP-Traffic kann so manipuliert werden, dass er auf dem Weg von A nach B über C geleitet wird.
    Wenn man den Punkt C kontrolliert, kann man Informationen sammeln, aber im Fall von CANTV (AS8048) scheint es sich nur um einfaches AS-Path-Prepending zu handeln.
    Das ist eine gängige Form des Traffic Engineerings, um Traffic zu reduzieren, und wurde auch früher oft so eingesetzt.
    Diesmal scheint der Pfad von Telecom Italia Sparkle (AS6762) an GlobeNet Cabos Sumarinos Columbia (AS52320) weitergegeben worden zu sein; ein einfacher Konfigurationsfehler ist sehr wahrscheinlich.
    Es gibt keine Anzeichen für ein Route Hijacking zu Dayco Telecom (AS21980); durch das Prepending wurde die Wahrscheinlichkeit eines Weges über CANTV sogar geringer.

  • Interessant an dem Artikel war, dass 7 % der DNS-Abfragen an 1.1.1.1 vom Typ HTTPS waren.
    Das hängt mit der Implementierung von ECH (Encrypted Client Hello) in TLS 1.3 zusammen; DNS hostet dabei den öffentlichen Schlüssel des Servers, damit der Servername in der HTTPS-Anfrage vollständig verschlüsselt werden kann.
    Da große Webserver wie Nginx dies noch nicht unterstützen, dürften diese 7 % größtenteils Cloudflare-eigener Traffic sein.
    Die zugehörigen Daten sind bei Cloudflare Radar zu sehen.

    • Browser verwenden diese Abfrage auch, um zu prüfen, ob eine Website HTTP3 unterstützt.
      Wenn die Verbindung langsam ist, erfolgt automatisch ein Fallback auf HTTP1/2.
    • Bei Adguard Home und Ähnlichem kann man DNS-Anfragen so konfigurieren, dass sie per HTTPS verarbeitet werden.
      Beispiel: https://dns.cloudflare.com/dns-query
    • Bei diesem Verfahren wird der Hostname auf DNS-Ebene nicht offengelegt.
      Ich habe das allerdings noch nicht selbst getestet.

  • Ich würde annehmen, dass Atommächte von solchen Entführungsoperationen ausgenommen sind.
    Solche Vorfälle dürften eher den Druck zur nuklearen Proliferation erhöhen.

    • Das lässt einen denken, dass Nordkorea von Anfang an recht hatte.
      Früher erschien mir das überzogen, aber inzwischen wirken eher wir wie die Clowns.
    • Bei einem Vorfall auf dem Niveau eines BGP Hijackings hat das nichts mit nuklearer Abschreckung zu tun.
      Das ist eine ganz andere Größenordnung als militärische Aktionen wie ein US-Enthauptungsschlag.
    • Der Besitz von Atomwaffen ist kein bloß binäres Konzept.
      Trägersysteme und Verteidigungsfähigkeit sind entscheidend, und bei Vorfällen wie der Entführung einer Führungsperson ist die Wahrscheinlichkeit eines nuklearen Gegenschlags gering.
      Schon der bloße ‘Versuch’ mit Nuklearwaffen ist eine riskante Kalkulation.
      Zum Beispiel ist bei iranischen Raketenangriffen einkalkuliert, dass die meisten abgefangen werden.
    • Nukleare Abschreckung funktioniert nur, wenn auch der Wille zum Einsatz vorhanden ist.
      Selbst wenn Venezuela Atomwaffen hätte, wäre das hier vermutlich trotzdem passiert.

  • Der Vorfall wirkt eher nicht böswillig; es sieht vielmehr so aus, als hätte CANTV (AS8048) eine mit Prepending versehene Ankündigung an 52320 gesendet.
    Eher scheint ein Problem mit den Upstream-Peer-Verbindungen von MDS (269832) dazu geführt zu haben, dass dieser Pfad stärker auffiel.

  • Wenn man diesen Vorfall betrachtet, hat man das Gefühl, dass sich eine vollständige Vermeidung von US-Technologieabhängigkeit kaum erreichen lässt.
    Die Aussage „steckt noch tiefer in US-Technologie drin“ klingt ironisch.

    • Es gibt keine Grundlage für die Annahme, dass dieser Angriff wegen US-Technologie möglich war.
      Wegen der Sanktionen dürfte Venezuela eher noch mehr chinesische Technologie nutzen.
      Dem Punkt, dass Abhängigkeit von der Technologie geopolitischer Gegner riskant ist, stimme ich aber zu.
    • Der Großteil der Welt nutzt ohnehin bereits Geräte von Google oder Apple.
      Es gibt kaum noch Spielraum, die Abhängigkeit weiter zu erhöhen.
    • Technologie ist in Entwicklung und Herstellung extrem teuer.
      Ohne eigene Fähigkeiten muss man letztlich Technologie anderer Länder verwenden.
      Wenn man die USA ausschließt, bekommt man am Ende nur eine ‘Infrastruktur ohne die USA’, wirtschaftlich ist der Wert ähnlich.
      Für ein Land wie Venezuela bedeutet das letztlich nur technologische Abhängigkeit von einer anderen Großmacht.
      Technologie-Geopolitik läuft am Ende auf die Realität hinaus: „Je mehr Brot du hast, desto weniger fremde Scheiße musst du essen.“

  • Ich frage mich, ob die OSRS-(Old School RuneScape)-Wirtschaft von diesem Angriff betroffen war.
    Das Internet scheint ja nicht vollständig ausgefallen zu sein.

    • Vielleicht hätte ein OSRS-Serverausfall sogar stärkere Auswirkungen auf Venezuelas Wirtschaft.
    • Es gibt tatsächlich einen Tweet, der Auswirkungen andeutet.
    • Ich frage mich, ob jemand Kontakt zu einem venezolanischen OSRS-Clan hat.

  • Ich frage mich, ob es an Weihnachten oder Neujahr ähnliche BGP-Anomalien gegeben hat.

    • Im Cloudflare-Dashboard wirkt selbst der Angriffstag insgesamt nicht wie ein Ausreißer.

  • Damit ein AS-Pfad der Länge 15 im Internet auftaucht, müssen alle besseren Pfade verschwunden sein.
    Auch diesmal scheint das so gewesen zu sein, und das wirkt unabhängig von CANTV.
    Manchmal bleiben BGP-Pfade wegen Fehlern bei der Verarbeitung von Withdrawals ‘hängen’; in solchen Situationen können lange Pfade auftauchen.

  • Das Fazit ist nicht ganz eindeutig, aber diese Untersuchung und Analyse war sehr interessant.
    Vielleicht findet noch jemand weitere Verbindungslinien.

  • Ich denke, dass es infolge dieses Vorfalls möglich gewesen sein könnte, Traffic über Sparkle abzuhören.
    Ich kenne die Netzwerktopologie allerdings nicht gut genug, um das sicher zu sagen.

    • Wenn man bei Diensten wie WhatsApp, Telegram oder Gmail einen Teil der Pakete verwirft, kann das Kommunikationsverzögerungen verursachen.
      Das könnte in einer Krisensituation als Blockade wichtiger alternativer Kommunikationsmittel wirken.
    • Tatsächlich lief wohl nur der Traffic von GlobeNet zu Dayco vorübergehend über CANTV.
      Warum Telecom Italia Sparkle ausdrücklich erwähnt wurde, ist unklar.