Der Artikel ist in drei Teile gegliedert. Die erste enthält allgemeine Informationen zu BGP-Hijacking und seiner traditionellen Version. Für diejenigen, die mit diesem Phänomen vertraut sind, wird empfohlen, direkt zum zweiten Teil überzugehen. Der zweite Teil beschreibt die Methode zum Ankündigen von Fremdpräfixen durch Hinzufügen eines Fremd-AS zu Ihrem AS-SET. Im dritten Teil wird die Komplexität der Verwendung der im zweiten Teil beschriebenen Methode bewertet, um die IP-Adresse der Ressource torproject.org zu erfassen und ein Zertifikat dafür auszustellen. Es wird davon ausgegangen, dass der Leser mit den Prinzipien von BGPv4 vertraut ist.
Einfache BGP-Entführung
Kurz gesagt, BGP-Hijacking erfasst die IP-Adressen anderer Personen (zufällig oder absichtlich).
Normalerweise sieht BGP-Hijacking so aus: Ein AS, der kein Präfix besitzt, beginnt, es anzukündigen (das Präfix eines anderen), Uplinks / Peers akzeptieren es und es beginnt sich über das Internet zu verbreiten. Sie akzeptieren dies aus dem Grund, dass an der Kreuzung keine Filterung von Präfixen erfolgt (entweder handelt es sich um einen Konfigurationsfehler oder um einen solchen Fehler) (da es aus verschiedenen Gründen sehr schwierig ist, an der Kreuzung einen Präfixfilter mit sehr großen Operatoren zu erstellen, ist dies für diesen Artikel nicht wichtig). ) Eines der bekanntesten Beispiele der letzten Zeit, als Rostelecom (
AS12389 )
begann, die Präfixe Mastercard (
AS26380 ), Visa und einige andere Finanzorganisationen bekannt zu geben (laut
offizieller Version aufgrund eines Softwarefehlers). Sie können sehen, wie diese Ankündigungen in der bgplay-Historie aussahen (
Anzeige über Web ,
JSON (
Archiv )). Hier ist eine davon auf einem der RIPE-Kollektoren (das Präfix 216.119.216.0/24 gehört zu Mastercard (AS26380)):
"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24
Und so sah die eigentliche Ankündigung aus:
"source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24
Das heißt, In diesem Fall hat Rostelecom ein Präfix direkt von seinem AS angekündigt (der letzte AS in AS-PATH ist 12389). Probleme könnten vermieden werden, wenn Uplinks und Feste von Rostelecom Präfixe von Rostelecom filtern, indem
Präfixlisten gemäß AS-SET erstellt und / oder
Präfixe gemäß ROA RPKI validiert werden . Die Erstellung von Präfixlisten zwischen großen Operatoren wird häufig nicht durchgeführt, und nicht alle haben RPKI implementiert (aber es gibt
Fortschritte ). Eine solche Entführung kann theoretisch von jedem durchgeführt werden, jedoch nur, wenn das angekündigte Präfix durch mindestens einen Uplink / Fest „leckt“. Normalerweise konfigurieren große russische Betreiber Präfixfilter in Richtung ihrer Kunden, und daher können kleine AS (kleine / mittlere Betreiber, einige Hosting- und einige Unternehmen) fast immer keinen solchen Angriff ausführen (aber auch dies hängt alles von der Region ab / Land / spezifischer Betreiber).
Angreifer finden jedoch immer noch Orte (Uplinks), an denen die Filterung nicht konfiguriert ist (2017 war Brasilien
führend bei der Entführung ), und führen einen Angriff durch, indem sie IP-Adressen abrufen (solche Ereignisse fallen häufig in Newsfeeds), um einen effektiveren Angriff zu erzielen. Kündigen Sie spezifischere Präfixe (mit einer längeren Maske) als einen echten Urheber an. Fahren wir nun mit der Angriffsversion fort, in der weder die ROA-RPKI-Validierung noch die AS-SET-Präfixlisten gespeichert werden.
BGP-Hijacking mit der Hinzufügung eines AS-Opfers in seinem AS-SET
Stellen Sie sich das folgende Szenario vor:
- Ein Angreifer erhält AS- und IP-Adressen (technisch gesehen benötigt er keine IP-Adressen, sie verursachen eher keine Fragen).
- Der Angreifer stellt eine Verbindung zu verschiedenen großen Operatoren und IXs (mindestens einem Operator oder IX) her und gibt nicht nur sein AS, sondern auch sein AS-SET als Datenquelle für die angekündigten Präfixe an (dies ist die übliche Praxis für die Interaktion zwischen Operatoren (einschließlich) einschließlich in einer Client-Uplink-Beziehung) oder zur Aufnahme in IX-ah)). Im Normalfall wird AS-SET angegeben, und nicht nur AS, wenn angenommen wird, dass der Client keine Sackgasse ist, sondern selbst Clients mit bgp und ihren eigenen Netzwerken hat (oder haben wird).
- Nach einiger Zeit fügt der Angreifer das AS des Opfers zu seinem AS-SET hinzu und beginnt, sein Präfix durch sich selbst anzukündigen, d. H. Der angekündigte AS-PATH sieht folgendermaßen aus: "AS_ Angreifer AS_ Opfer". Aus Sicht von automatisch erstellten Präfixlisten und aus Sicht von RPKI ist dies eine vollständig gültige Ankündigung, sodass beide Schutzmechanismen hier nicht funktionieren.
- Das angekündigte Präfix beginnt mit der tatsächlichen Ankündigung (der Ankündigung des Opfers) zu konkurrieren, irgendwo gewinnt er und gelangt in die Routing-Tabelle, irgendwo verliert er und wird es nicht (die Ankündigung des Opfers bleibt dort). Dies hängt davon ab, wie viele Uplinks und wie viele IXs ein Angreifer verwendet. Wenn ein Angreifer als Client eine Verbindung zu einem AS herstellt, gewinnt er (meistens) das Opfer aufgrund einer größeren lokalen Präferenz (wenn das Opfer kein Client mit demselben Uplink ist, gewinnt das Opfer durch AS-PATH, wenn er dies nicht tut vorangestellt), d.h. Ein Angreifer muss mit seinem AS-SET eine Verbindung zu so vielen Uplinks wie möglich herstellen, um die Effektivität seines Angriffs zu maximieren.
Außerdem muss der Angreifer eine Verbindung mit der maximalen Anzahl von IXs herstellen, z Normalerweise setzen Deadlock-ASs die höchste lokale Präferenz auf IXs. Wenn das Opferpräfix nicht an IX beteiligt ist, verliert es die Ankündigung des Angreifers in den Routing-Tabellen der Deadlock-ASs.
Theoretisch ist dies ein ziemlich starker Angriff, aber in der Praxis ergeben sich glücklicherweise die folgenden Einschränkungen:
- Sie müssen eine juristische Person erstellen, mindestens eine, die jedoch höchstwahrscheinlich in verschiedenen Ländern erforderlich ist.
- Es ist notwendig, Vereinbarungen mit Betreibern, IXs, zu schließen, die fast immer eine Verbindungsgebühr mit LIR / RIR erheben.
- Einige Operatoren erstellen immer noch nicht automatisch AS-SET-Präfixlisten, sondern müssen dafür Buchstaben schreiben. Ein erfahrener Administrator wird etwas vermuten, wenn das AS-ka eines bekannten Unternehmens plötzlich im AS-SET eines unbekannten Unternehmens erscheint.
- Nach dem Angriff wird die verwendete Ausrüstung (wenn sie sich in einem Rechenzentrum befindet) höchstwahrscheinlich beschlagnahmt, falls ein Strafverfahren eröffnet wird.
- Die Präfixlisten für verschiedene Operatoren / IX werden zu unterschiedlichen Zeiten aktualisiert. Sie müssen daher analysieren, wer aktualisiert wird, wenn dies auch nicht die einfachste Aufgabe ist.
Mögliche Schutzmaßnahmen:
- Theoretisch müssen Sie, um sich gegen einen solchen Angriff zu verteidigen, so viele Schnittstellen wie möglich mit den Operatoren (besser den Client-Schnittstellen, da sie eine höhere lokale Präferenz haben) und IXs haben. Das heißt, Machen Sie dasselbe, was ein Angreifer tun wird. In der Praxis ist dies natürlich äußerst schwierig umzusetzen und erfordert erhebliche Ressourcen. Diese Methode ist nur für Dienste relevant, die auf professioneller Basis Informationssicherheitsdienste bereitstellen.
- Wenn Sie eine Website haben, verwenden Sie einen CAA-Eintrag mit der Kontoaufgabe (wenn Ihr SSL-Zertifikatanbieter dies unterstützt. Letsencrypt unterstützt) (siehe RFC6844 ). In diesem Fall kann der Angreifer kein Zertifikat ausstellen (es sei denn, er kann den CAA-Datensatz ändern).
- Theoretisch sollte die weit verbreitete Implementierung von BGPsec einen solchen Angriff eliminieren, aber sein Schicksal ist noch nicht klar (in der Praxis wird es noch nicht angewendet oder sehr selten).
- Implementierung der alternativen Überprüfung AS_PATH (ohne BGPsec) (bisher ist dies ein Entwurf , der das beschriebene Problem im Falle seiner weit verbreiteten Implementierung löst).
- Das Verbot der unkontrollierten Hinzufügung eines fremden AS zu Ihrem AS-SET (ohne die Erlaubnis des AS-Besitzers) könnte die Möglichkeit solcher Angriffe in den Regionen verringern, in denen AS-SETs zum Filtern an Gelenken verwendet werden. Jetzt gibt es kein solches Verbot.
Tatsächlich ist für die meisten Leser der einzige Ratschlag, der für sie gilt, Nr. 2 (in Bezug auf die Verwendung eines Kontos in einem CAA-Datensatz) und teilweise Nr. 1 im Zusammenhang mit der Auswahl eines Hosts mit guter Konnektivität. Gleichzeitig müssen Sie sich an mögliche Angriffe auf den DNS-Dienst erinnern, in dem Sie Ihre Einträge hosten (dies ist jedoch ein separates Problem, und es sind viele Materialien darauf enthalten).
Ist es schwierig, torproject.org zu erfassen?
Ein Angreifer muss zwei Probleme lösen:
- Leiten Sie den Datenverkehr an die Zielgruppe weiter (Zielgruppe - wer erhält die gefälschte Website)?
- Zertifikat generieren
Einführung:
$ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197
Wie Sie sehen, gibt es einen CAA-Datensatz, Sie können ein Zertifikat von letsencrypt erhalten, es gibt keine Bindung an das Konto im CAA-Datensatz, was bedeutet, dass das Problem theoretisch vom Angreifer gelöst wird. Die IP-Adressen von torproject.org gehören dem bekannten Hezner-Hosting.
Angenommen, die Zielgruppe eines Angreifers sind die Kunden eines russischen Betreibers. Hezner ist kein Kunde russischer Betreiber (hat aber Peering mit großen - direkt oder über IX-s). Der einfachste Weg für einen Angreifer, CA-Verkehr zu sich selbst umzuleiten, besteht darin, Client dieses Betreibers zu werden und einfach auf Kosten eines höheren lokalen Prefs zu gewinnen. Hier ist alles besonders relativ einfach und klar.
Um ein Zertifikat in letsencrypt zu erhalten, benötigen Sie den Anbieter, auf dem letsencrypt hostet, um den Datenverkehr an den Angreifer und nicht an Hezner (AS24940) zu leiten. letsencrypt wird für amerikanische und europäische IP-Adressen in unterschiedliche Adressen aufgelöst. Lassen Sie uns jedoch sehen, wie schwierig es sein wird, den Datenverkehr von acme-v02.api.letsencrypt.org/2.19.125.202 zum Host des Angreifers zu beeinflussen. Hier sehen wir uns mit der Tatsache konfrontiert, dass letsencrypt auf Akamai CDN gehostet wird, das weltweit über eine sehr gute Konnektivität verfügt (bei den meisten großen IXs vorhanden, direkte Verbindungen mit einer großen Anzahl von Hauptakteuren). Akamai hat kein öffentliches LG. Grundsätzlich gibt es eine
API für Clients, mit der Sie Traceroute / Ping durchführen können. Aber auch ohne ein öffentliches LG können Sie sich
Peering DB ansehen, um das Ausmaß ihrer Präsenz zu beurteilen. Ebenso kann man sich
hezner ansehen . Es ist leicht zu erkennen, dass beide AS dieselben IXs haben, daher können wir schließen, dass mit einer Wahrscheinlichkeit nahe der Einheit die AS Hezner-Präfixe (AS24940) in der Akamai-Tabelle (AS20940) mit AS_PATH 24940 sichtbar sind. Dies bedeutet, dass es sich um einen Angreifer handelt Wenn versucht wird, Hezners Präfixe über IX anzukündigen, verlieren sie laut AS_PATH die tatsächlichen Ansagen von Hezner (da AS_PATH die AS des Angreifers enthält). Eine mögliche Lösung wäre, ein "direktes" Peering zwischen dem Angreifer und Akamai zu organisieren (wenn Akamai dem zustimmt und wenn die lokale Präferenz höher ist als an den Kreuzungen mit IXs).
Zusammenfassend lässt sich sagen, dass Sie durch Hinzufügen des AS eines anderen zu Ihrem AS-SET die Website torproject.org erheblich beeinträchtigen können (für eine große Anzahl von Clients, im allgemeinen jedoch nicht für alle). Sie erhalten jedoch das SSL-Zertifikat torproject.org in letsencrypt. höchstwahrscheinlich wird es aufgrund der guten Konnektivität zwischen dem echten Urheber (Hezner) und dem von letsencrypt (Akamai) verwendeten CDN nicht funktionieren. In anderen Fällen ist jedoch das Risiko, ein Zertifikat mit der beschriebenen Methode zu erhalten, erheblich erhöht, wenn zwischen dem Hosting des Opferstandorts und der Zertifizierungsstelle Transit-AS bestehen und diese in AS_PATH vorhanden sind.