Skip to content

Drucksache: PHP Magazin 2.16 - BGP - so gefährdet wie nie

Im PHP Magazin 2.2016 ist ein Artikel über Angriffe auf und über das Border Gateway Protocol BGP erschienen.

Das Border Gateway Protokoll ist ungeschützt und daher ein leichtes Ziel für Angriffe. Die Sicherheitsforscher haben 2015 in mehreren Vorträgen auf Schwachstellen und mögliche Angriffe hingewiesen, und auch "in the Wild" wurde das BGP bereits angegriffen oder meist vielleicht eher misshandelt.

Die Probleme mit dem BGP sind nicht neu. Mal abgesehen von den im Artikel beschriebenen Vorfällen waren sie auch schon früh ein Thema bei den Sicherheitsforschern.

Schon 1989 warnte Steven M. Bellovin unter anderem vor der Manipulation von Routen über BGP (PDF). Und 2008 haben Anton Kapela und Alex Pilosov auf der DEF CON 16 MitM-Angriffe mit Hilfe des BGP vorgeführt (Material). Dabei haben sie gezeigt, wie sich über BGP-Manipulation der Netzwerkverkehr für die Konferenz in Las Vegas über einen Router in New York umleiten lässt, der sie dann an das eigentliche Ziel weiterleitet.

2009 beschloss die Internet Society, die Routen abzusichern (PDF). Die zuständige Working Group der IETF war immerhin schon 2012 mit ihrer Arbeit fertig. Jetzt muss das Ganze nur noch implementiert und ausgerollt werden, schon sind die Routen sicher. Was nur sehr langsam passiert, wie Wim Remes gezeigt hat.

Es gibt allerdings auch gute Gründe für die Verzögerungen bei der Einführung der Resource Public Key Infrastructure (RPKI). Das bisher nicht hierarchische Routing-System bekommt damit eine Hierarchie übergestülpt, und die lässt sich zum einen missbrauchen und wirft zum anderen Fragen nach der Zuverlässigkeit auf.

So können über RPKI auch Routen zurück gezogen werden, was Staaten mit entsprechendem Einfluss die Möglichkeit gibt, unliebsame AS aus dem Netz zu verbannen. Das Bedrohungsmodell für die RPKI geht davon aus, dass den Authorities vertraut werden kann und das Routing angegriffen wird. Was passiert, wenn man es umdreht und nicht vertrauenswürdige Authorities hat, wird erst seit kurzem untersucht.

Und die Ausgabe und Verwaltung der Route Origin Authorizations (ROA) stellt besondere Anforderungen an die ausgebenden Stellen. Wir haben schließlich genug Probleme mit dem Zertifizierungssystem für SSL/TLS, da können wir ähnliche Probleme bei der Absicherung der Routen nun wirklich nicht brauchen. Dass die AS ihre Bedenken erst ausgeräumt haben möchten, bevor sie RPKI einführen, ist verständlich.

Aber den meisten von uns bleibt in diesem Fall sowieso nur die Beobachterrolle, zum Beispiel beim BGP Stream. In der Hoffnung, dass dort nicht plötzlich eine für uns relevante Route, zum Beispiel zu unserem Webserver oder auch dem unserer Bank, auftaucht.

Und weil ich gerade SSL/TLS erwähnt habe: Über die Manipulation von Routen sind zwar MitM-Angriffe möglich, so lange der MitM aber kein passendes Zertifikat hat, kann er auf den Inhalt der mit SSL/TLS geschützten Verbindungen nicht zugreifen.

Leider kann er sich ein gültiges Zertifikat unter Umständen auch über BGP-Manipulationen verschaffen. Aber die (Un)sicherheit von SSL/TLS und deren Zertifikaten ist eine andere Geschichte.

Und hier noch die Links und Literaturverweise aus dem Artikel:

Carsten Eilers

Trackbacks

Keine Trackbacks