In den letzten Stunden sind ein gutes Dutzend Meldungen darüber verbreitet worden, dass ein Angreifer versucht (und es vielleicht geschafft hat), Kryptowährungen mit Hilfe eines BGP-Leaks zu stehlen.
CC BY 2.0 Foto von elhombredenegro
Was ist das BGP (Border Gateway Protocol)?
Das Internet besteht aus Routen. Für unseren DNS-Resolver 1.1.1.1 teilen wir der Welt mit, dass alle IPs im Bereich 1.1.1.0 bis 1.1.1.255 über jeden Cloudflare-PoP erreichbar sind.
Diejenigen, die keinen direkten Link zu unseren Routern haben, erhalten die Route über Transitanbieter, die Pakete an diese Adressen liefern, da sie mit Cloudflare und dem restlichen Internet verbunden sind.
So funktioniert das Internet normalerweise.
Es gibt Stellen (Regional Internet Registries, RIRs), die für die Vergabe von IP-Adressen zuständig sind, um zu vermeiden, dass derselbe Adressbereich von verschiedenen Leuten verwendet wird. Dabei handelt es sich um IANA, RIPE, ARIN, LACNIC, APNIC und AFRINIC.
Was ist ein BGP-Leak?
Die weit gefasste Definition eines BGP-Leaks wäre ein IP-Bereich, der von jemandem bekanntgegeben wird, der vom Eigentümer des Bereichs nicht zugelassen ist. Wenn Transitanbieter Cloudflares Bekanntgabe von 1.1.1.0/24 aufnehmen und im Internet bekanntgeben, erlauben wir ihnen dies. Sie überprüfen auch anhand der RIR-Informationen, dass nur Cloudflare ihnen den Bereich bekanntgeben kann.
Wobei es schwierig werden kann, alle Bekanntgaben zu überprüfen. Vor allem, weil es mehr als 700.000 Routen im Internet und Ketten von Anbietern gibt, die untereinander Traffic austauschen.
Routen-Leaks sind naturgemäß örtlich begrenzt. Je mehr Sie lokal vernetzt sind, desto geringer ist das Risiko, eine durchgesickerte Route zu akzeptieren.
Um anstelle einer legitimen Route akzeptiert zu werden, muss die Route eine der beiden folgenden Kriterien aufweisen:
Einen kleineren Präfix haben (10.0.0.1/32 = 1 IP vs. 10.0.0.0/24 = 256 IPs)
Bessere Metriken haben als ein Präfix mit gleicher Länge (kürzerer Pfad)
Die Ursache für ein BGP-Leak ist in der Regel ein Konfigurationsfehler: Ein Router gibt plötzlich die ihm bekanntgewordenen IPs bekannt. Oder kleinere Präfixe, die intern für Traffic Engineering verwendet werden, werden plötzlich öffentlich.
Aber manchmal geschieht es auch in böswilliger Absicht. Das Präfix kann umgeleitet werden, um die Daten passiv zu analysieren. Oder jemand kann auch einen Dienst einrichten, der stattdessen unrechtmäßig antwortet. Dies ist schon vorgekommen.
Was ist heute passiert?
Cloudflare unterhält eine Reihe von BGP-Sammlern, die BGP-Informationen von Hunderten von Routern auf der ganzen Welt sammeln.
BGP4MP|04/24/18 11:05:42|A|205.251.199.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.197.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.195.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.193.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.192.0/24|10297
...
BGP4MP|04/24/18 11:05:54|A|205.251.197.0/24|4826,6939,10297Heute zwischen ca. 11:05:00 UTC und 12:55:00 UTC haben wir die folgenden Bekanntgaben gesehen:
Das sind spezifischere Bekanntgaben der Bereiche:
205.251.192.0/23205.251.194.0/23205.251.196.0/23205.251.198.0/23
Dieser IP-Bereich ist Amazon (AS16509) zugeordnet. Aber das ASN, das ihn bekanntgab, war eNet Inc (AS10297), das ihn an seine Peers und an Hurricane Electric (AS6939) weitergab.
Diese IPs sind für Route53 Amazon DNS-Server. Wenn Sie eine Abfrage für eine ihrer Client-Zonen senden, antworten diese Server.
Während des zweistündigen Leaks haben die Server in diesem IP-Bereich nur auf Abfragen nach myetherwallet.com geantwortet. Einige Leute stellten SERVFAIL fest.
Jeder DNS-Resolver, der nach Namen gefragt wurde, die von Route53 abgewickelt werden, musste die maßgeblichen Server fragen, die über das BGP-Leak gekapert wurden. Dies vergiftete DNS-Resolver, deren Router die Route akzeptiert hatten.
Darunter befand sich auch der Cloudflare DNS Resolver 1.1.1.1. Wir waren in Chicago, Sydney, Melbourne, Perth, Brisbane, Cebu, Bangkok, Auckland, Muscat, Djibouti und Manila betroffen. Im Rest der Welt funktionierte 1.1.1.1 normal.
BGP hijack this morning affected Amazon DNS. eNet (AS10297) of Columbus, OH announced the following more-specifics of Amazon routes from 11:05 to 13:03 UTC today:205.251.192.0/24205.251.193.0/24205.251.195.0/24205.251.197.0/24205.251.199.0/24
— InternetIntelligence (@InternetIntel) April 24, 2018
Correction: the BGP hijack this morning was against AWS DNS not Google DNS. https://t.co/gp3VLbImpX
— InternetIntelligence (@InternetIntel) April 24, 2018
$ dig +short myetherwallet.com @205.251.195.239
54.192.146.xxBeispielsweise erhalten Sie auf die folgende Abfrage legitime Amazon-IPs:
Aber während des Hijackings erhielten Sie als Antwort IPs, die einem russischen Provider (AS48693 und AS41995) zugeordnet sind. Sie mussten die gekaperte Route nicht akzeptieren, um Opfer des Angriffs zu werden, es genügte, einen DNS-Resolver zu nutzen, der vergiftet wurde.
Wenn Sie HTTPS verwendeten, zeigte die gefälschte Website ein von einer unbekannten Zertifizierungsstelle signiertes TLS-Zertifikat an (die im Zertifikat aufgeführte Domain war korrekt, aber es war selbst signiert). Dieser Angriff konnte nur funktionieren, wenn man fortfuhr und das falsche Zertifikat akzeptierte. Von diesem Zeitpunkt an wurde alles, was Sie senden, verschlüsselt, aber der Angreifer hatte die Schlüssel.
Wenn Sie bereits angemeldet waren, sendete Ihr Browser die Anmeldeinformationen im Cookie. Andernfalls wurden Ihr Benutzername und Ihr Passwort gesendet, wenn Sie sie auf einer Anmeldeseite eingeben.
Sobald der Angreifer die Anmeldeinformationen erhalten hatte, konnte er sie auf der legitimen Website verwenden, um Ethereum zu übertragen und zu stehlen.
Zusammenfassung in Bildern
Normalfall
Nach einem BGP-Routen-Leak
Betroffene Regionen
Wie bereits erwähnt, hat AS10279 diese Route bekanntgegeben. Aber nur einige Regionen waren betroffen. Hurricane Electric hat eine starke Präsenz in Australien, vor allem aufgrund der Internetkosten. Chicago war betroffen, weil AS10279 eine physische Präsenz hat, die zu direktem Peering führt.
Die folgende Grafik zeigt die Anzahl der empfangenen Pakete in den betroffenen Regionen und nicht betroffenen Regionen (Y-Achse normiert). Der Rückgang ist darauf zurückzuführen, dass der maßgebliche Server nicht mehr auf unsere Anfragen reagiert hat (er hat nur für die eine Website geantwortet und alle anderen Amazon-Domains wurden ignoriert).
Die anderen von eNet verwendeten Transits (CenturyLink, Cogent und NTT) schienen diesen Weg nicht akzeptiert zu haben. Ein Grund könnte sein, dass sie Filter und/oder Amazon als Kunden haben.
eNet bietet IP-Dienste an, sodass möglicherweise einer seiner Kunden hinter der Bekanntgabe steckt.
Gibt es jemanden, dem man Schuld zuweisen kann?
Da es viele Beteiligte gibt, ist es schwierig, Fehler zuzuweisen. Beteiligte Akteure:
Der ISP, der ein Subnetz bekanntgegeben hat, das ihm nicht gehört.
Die Transitanbieter, die die Bekanntgabe vor der Weiterleitung nicht überprüft haben.
Die ISPs, die die Route akzeptiert haben.
Die mangelnde Sicherheit bei DNS-Resolvern und -Zertifizierungsstellen.
Die bei Anbietern in Russland gehostete Phishing-Website.
Die Website, die keine legitimen TLS-Zertifikate erzwungen hat.
Der Benutzer, der auf „Fortfahren“ geklickt hat, obwohl das TLS-Zertifikat ungültig war.
Wie bei einer Blockchain ist eine Netzwerkänderung in der Regel sichtbar und wird archiviert. RIPE unterhält eine Datenbank für diesen Zweck.
$ whois -h whois.radb.net ' -M 205.251.192.0/21' | egrep '^route:|^origin:|source:' | paste - - - | sort
route: 205.251.192.0/23 origin: AS16509 source: RADB
route: 205.251.192.0/23 origin: AS16509 source: REACHKönnten wir dieses Problem vermeiden?
Diese Frage ist schwer zu beantworten. Es gibt Vorschläge zur Sicherung von BGP:
Einige Begriffe können den RIR-Datenbanken hinzugefügt werden, sodass eine Liste zulässiger Quellen erstellt werden kann:
Die Erstellung von RPKI/ROA-Einträgen bei RIR als Quelle der Wahrheit zum Weg einer Route, obwohl nicht jeder solche Einträge erstellt oder validiert. IP und BGP wurden vor einigen Jahrzehnten geschaffen, mit unterschiedlichen Anforderungen an Integrität und Authentizität (weniger Routen).
Auf den oberen Ebenen des Netzwerkstapels können ein paar Dinge getan werden.
Beim DNS können Sie DNSSEC verwenden, um Ihre Einträge zu signieren. Die von der gefälschten DNS zurückgegebenen IPs wären nicht signiert, da sie nicht über die privaten Schlüssel verfügen.
Wenn Sie Cloudflare als DNS verwenden, können Sie DNSSEC mit wenigen Klicks im Panel aktivieren.
Bei HTTPS überprüft Ihr Browser das von der Website bereitgestellte TLS-Zertifikat. Wenn HSTS aktiviert ist, benötigt der Browser immer ein gültiges Zertifikat. Die einzige Möglichkeit, ein legitimes TLS-Zertifikat für eine Domain zu erzeugen, besteht darin, den Cache eines Nicht-DNSSEC-DNS-Resolvers der Zertifizierungsstelle zu vergiften.
DANE bietet eine Möglichkeit, Zertifikate über DNS an einen Domainnamen zu binden.
Mit DNS-over-HTTPS könnte man auch überprüfen, ob Sie mit dem richtigen Resolver sprechen, falls das Leak bei den DNS-Resolvern statt bei der DNS-Zertifizierungsstelle liegt.
Es gibt keine perfekte und einzelne Lösung. Je mehr dieser Schutzmaßnahmen getroffen sind, desto schwieriger wird es für einen böswilligen Akteur sein, diese Art von Angriff durchzuführen.
Tags: BGP, Krypto, TLS, HTTPS, Sicherheit, Schwachstellen