Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

Heel het internet af te luisteren door zeer ernstig lek

  • Door
  • Arnout Veenman
  • geplaatst op
  • 28 augustus 2008 08:05 uur

Recent hadden we het DNS-lek dat door Dan Kaminsky werd ontdekt, achteraf blijkt het om een relatief oude kwetsbaarheid te gaan, waar Kaminsky een nieuw element aan had toegevoegd. Met het DNS-lek nog vers in het geheugen is er nu een nieuw lek dat nog velen malen ernstiger is, omdat het hele internet er door af te luisteren is.

Het gaat om een kwetsbaarheid van het Border Gateway Protocol (BGP), dat net als het DNS-lek een oude kwetsbaarheid is. Begin dit jaar werd YouTube wereldwijd onbereikbaar door de kwetsbaarheid, doordat Pakistan Telecom per ongeluk de IP-adressen van YouTube begon te announcen via BGP, waardoor al het YouTube dataverkeer richting Pakistan ging.

Onderzoekers Anton “Tony” Kapela en Alex Pilosov hebben echter een nieuw element toegevoegd aan deze kwetsbaarheid, waardoor het niet alleen mogelijk is om dataverkeer dat voor andere netwerken bestemd is naar je toe te trekken (te kapen), maar het uiteindelijk ook weer af te leveren bij de ontvanger, waardoor een Man-in-the-Middle aanval mogelijk is.

De wijze waarop ze dat doen is redelijk eenvoudig. Allereerst wordt er vanaf het eigen netwerk met “as-prepends” een route aangelegd naar het netwerk van het slachtoffer, waardoor de route tussen het netwerk van het slachtoffer en de aanvaller altijd dezelfde is. Daarna announced de aanvaller de IP-adressen van het slachtoffer netwerk in kleinere blokken dan het slachtoffer netwerk zelf, waarna al het dataverkeer bestemd voor het slachtoffer naar het netwerk van de aanvaller komt en na ontvangst (en mogelijk aanpassing) gaat het dataverkeer via de statische route alsnog naar het slachtoffer.

Wat dit lek helemaal ernstig maakt is dat er feitelijk geen oplossing voor handen is. Wel zouden ISP’s (carriers) hen klanten moeten filteren, zodat zij geen IP-blokken kunnen announcen die niet van hun zijn, maar je hebt maar één ISP nodig die het niet doet en het probleem blijft bestaan. Een structurele oplossing voor het probleem zou de implementatie van Secure BGP (SBGP) zijn, waarbij de netwerkblokken die geannounced worden gesigned worden, waarmee die oplossing vergelijkbaar is met de structurele oplossing voor het DNS-lek: DNSSEC, maar vooralsnog lijken netwerkhardware fabrikanten en ISP’s niet aan SBGP te willen.

Met deze nieuwe kwetsbaarheid wordt end-to-end security op internet weer belangrijker, en dus ook protocollen als HTTPS, SFTP, S/MIME en IPSec, want een Man-in-the-Middle attack slaagt alleen maar als de aanvaller bij de data kan en deze kan meegluren en/of veranderen.

Igor, 28 augustus 2008 8:34 am

Ik vind dit erg overtrokken en bij lange niet vergelijkbaar met het DNS probleem.
Als eerst ontvang je met de beschreven methode alleen het verkeer wat naar het doel gaat en niet het terugverkeer. Je kan overigens natuurlijk het laatste verkeer ook opvangen als je ook de andere kant gaat spoofen.
Ten tweede,.. hoe krijg je in godsnaam een statiche route naar het doelnetwerk? Je moet dan een p2p verbinding met hun hebben want zit er maar 1 BGP router tussen dan werkt het al niet, want dan gaat het verkeer immers gewoon weer terug naar de spoofer.
Als laatste zal het zeer snel opvallen. Vooral van verbindingen die doorgaans zeer snel zijn en plotseling een stuk trager werken. Een traceroute verteld dan precies wat er aan de hand is. Natuurlijk kan in die tijd al genoeg informatie ontvangen zijn maar anoniem is de spoofer niet.

Arnout Veenman, 28 augustus 2008 8:37 am

@Igor, in [url=http://blog.wired.com/27bstroke6/files/edited-iphd-2.ppt]deze powerpoint[/url] hebben de onderzoekers hun bevindingen en opzet van de aanval uit te doeken gedaan.

Frank Louwers, 28 augustus 2008 8:50 am

Arnoud toch. Je gaat echt wel moeten leren om je verhalen te dubbelchecken en te laten nalezen door iemand die er echt iets van weet.

Een paar onjuistheden eerst:

- "Een structurele oplossing voor het probleem zou de implementatie van Secure BGP (SBGP) zijn ... vergelijkbaar is met de structurele oplossing voor het DNS-lek: DNSSEC ..."

Wel, de structurele oplossing voor het dns-"lek" is gewoon doen wat een aantal dns-soft vendors al jaren doen. Noch PowerDNS noch DJB-dns waren kwetsbaar voor die bug, omdat zij "slimmer" waren dan de standaard implementatie. Gewoon hun checks inbouwen in andere dns soft, was de oplossing, komt helemaal geen DNSSEC aan te pas. Dit wil niet zeggen dat dnssec geen nut heeft, maar de oplossing voor dat dns-"lek" was veel eenvoudiger dan dat.

- De titel van je artikel is bijzonder misleidend. Je spreekt van een "lek" en dat "heel het internet af te luisteren is". Er is helemaal geen "lek". Heel het internet is een "web of trust". Het is per definitie de-centraal. Live with it. De paper die gepresenteerd werd op DevCon combineert gewoon een aantal (bestaande) technieken die allemaal een gevolg zijn van dat decentrale. Als je je BGP-peers (in de technische zin van het woord, kan dus gaan om transit, klanten of "peers") niet vertrouwt, moet je je afvragen waarom het je BGP peers zijn en of je dat wel wil houden. Als je ze wel vertrouwt, en hen niet filtert, moet je maar met de gevolgen leven. Dit is helemaal geen "lek", dit is gewoon een gevolg van hoe het internet werkt.

- Je beschrijving van de attack is niet compleet, je moet nog je AS paden gaan juistzetten en op je routers met de TTLs gaan spelen als je het "zo onzichtbaar mogelijk" wil doen, maar dat zijn details.

Wat zijn nu wel oplossingen om zoiets tegen te gaan? Wel er zijn er een paar:

- Zorg eerst dat je eigen info correct bij RIPE staat. Neen, serieus, hoeveel Nederlandse en Belgische bedrijven er zijn wiens RIPE routing-db info niet correct is, het is erg. Iedereen heeft zijn mond vol van dat fameus "lek" zoals jij het noemt, maar diezelfde mensen zouden beter eerst kijken of hun eigen dingen in orde zijn.

- Filter minstens je transit klanten, en zet een max-prefix op je "peering" bgp peers. In een ideale wereld filter je al je bgp peering klanten want als ze allemaal stap 1 van hierboven correct doen, zullen die filters correct zijn.

- Registreer je bij diensten als myASN van Ripe, PHAS, renesys enz. Momenteel detecteren de meeste van die instanties de BGP MITM attack nog niet, maar het is niet zoveel werk voor hen om het wel te doen. Meer nog, ik weet dat ze er allemaal aan bezig zijn om dit zeer snel te gaan implementeren. Als er dan iemand zo'n aanval op je uitvoert, ben je er tenminste bijzonder snel van op de hoogte.

Frank Louwers, 28 augustus 2008 8:51 am

@Igor: je bent correct dat het niks te maken heeft met de DNS-attack. Maar over die statische routes en zo: lees de pdf, het iets ingewikkelder dan wat Arnout beschreef, maar het kan volledig.

Igor, 28 augustus 2008 9:06 am

@Frank,Arnoud: Klopt. Met de AS-prepends is het wel degelijk mogelijk om de more-specific te filteren bij de paar uplink providers van de target. Neemt niet weg dat natuurlijk klanten van die providers geen last hebben van de spoof.
En wat ik dus niet netjes vind is dat Arnoud het 'statische' routes noemt. Hij voegt verkeerde informatie toe aan een nieuws item. Voor je het weet wordt dit opgepakt door anderen en klopt het hele item niet meer.

Arnout Veenman, 28 augustus 2008 9:09 am

@Igor, dat het werkt met static routes is toch echt wat ik gelezen heb in de powerpoint, al kan ik het onderstaande verkeerd begrepen hebben:
[quote]
1. Traceroute & plan reply path to target
2. Note the ASN’s seen towards target from traceroute & bgp table on your router
3. Apply as-path prepends naming each of the ASN’s intended for reply path
4. Nail up static routes towards the next-hop of the first AS in reply path
5. Done[/quote]

Igor, 28 augustus 2008 9:12 am

@Arnout: Je bedoelt punt 4. Ze bedoelen daar, .. leg een statische route naar je first hop. Maw,.. bijna gelijk aan je default gw.
Maar het belangrijkste is het nieuws item is punt 3. Dat zorgt er voor dat de more-specific update (die de spoofer de wereld in stuurt) gefiltered wordt bij de paar uplink providers van de target.

Arnout Veenman, 28 augustus 2008 9:20 am

@Igor, ik heb er nu het volgende van gemaakt "De wijze waarop ze dat doen is redelijk eenvoudig. Allereerst wordt er vanaf het eigen netwerk met “as-prepends” een route aangelegd naar het netwerk van het slachtoffer, waardoor de route tussen het netwerk van het slachtoffer en de aanvaller altijd dezelfde is.", klopt dat?

Robin, 28 augustus 2008 9:21 am

Oplossing lijkt mij simpel, verplichte aanmelding op een internationaal filter voor alle ARIN/RIPE/AFRINIC Members
onderhouden en beheerd door ICANN. word het filter niet gebruikt dan lidmaatschap ontbinden, dit filter kan alle foute announces er uitpikken waardoor leden geen ranges kunnen announcen die ze niet mogen announcen.

Dennis Wijnberg (JR Online), 28 augustus 2008 9:29 am

@Robin; de oplossing is even simpel als complex. Hoe ga je die verplichting opleggen, op welke termijn etc. etc. Technisch is het goed te doen, maar in de praktijk zal het nog behoorlijk lang duren voordat dit is doorgevoerd. (Denk aan softwareleveranciers die software moeten schrijven/updaten etc.)

Frank Louwers, 28 augustus 2008 9:30 am

Robin: wat doe je met projecten als AS112? Of anycast prefixen die vanuit verschillende ASN's worden announcet? (Niet proper, maar kan, en wordt gedaan).

Robin, 28 augustus 2008 10:26 am

@ Dennis,

Inderdaad, het zal tijd en geld kosten om een dergelijk iets te implementeren, maar ik denk dat er genoeg partijen zijn die hier in willen investeren, vooral nu de geest uit de fles is, de verplichting kan worden opgelegd door een aanpassing in het reglement van of de RIR of door ICANN.


@ frank

Ik moet bekennen dat ik AS112 project niet ken, maar als ik het goed gelezen en begrepen heb zou ik zeggen dat die private ranges niets te zoeken hebben in het publieke bgp domein, ik zelf filter deze ranges per default.

Als er partijen zijn die afzonderlijke niet root dns servers willen gebruiken voor die queries, dan is dat prima mogelijk op een virtueel of private netwerk tussen deze partijen.

Bedoel je met de anycast het RFC3068 6to4?

MikeN, 28 augustus 2008 12:25 pm

@Frank: "Wel, de structurele oplossing voor het dns-”lek” is gewoon doen wat een aantal dns-soft vendors al jaren doen. Noch PowerDNS noch DJB-dns waren kwetsbaar voor die bug, omdat zij “slimmer” waren dan de standaard implementatie."

Dat is incorrect, ze zijn minder vatbaar, maar nog steeds is spoofing mogelijk. Ipv enkele seconden duurt het echter ongeveer een dag. Zie bijvoorbeeld http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spoofing-an-agile-source-port-randomised-resolver

robbert, 28 augustus 2008 12:31 pm

Daarom werk je ook met filters en werken de meeste carriers ook met filters. Het is logisch dat ik IP adressen van Microsoft kan announcen, echter echt ver kom je niet. Plus je bent _altijd_ te traceren. Je hebt upstream partijen nodig. Als deze geen prefix filters hebben op hun klanten dan kan het inderdaad wel eens uit de hand lopen.

Om je zelf te behoeden van typefouten werk je uiteraard zelf ook werken met prefixfilters naar buiten toe....

Verder werken veel carriers met de databases zoals die van RIPE. Netwerken moeten op een IP blok een route-object aanmaken, hiermee bewijs je dat de range van het netwerk is die hem gaat announcen.

Zo moeilijk is het niet als iedereen zich aan de regeltjes houd ;)

Lennie, 28 augustus 2008 2:42 pm

@robbert: er is wel 1 probleem, _iedereen_ moet zich aan de regeltjes houden wil het echt goed werken. Kijk maar eens naar het voorbeeld van Pakistan/YouTube hoe makkelijk het op mis kan gaan. Als een grootte transit een route accepteert, accepteren de andere ze ook en daarmee een heleboel andere partijen.

Er zijn wel mensen die protocollen hebben bedacht voor geautomatiseerde verificatie van announcements, dat lijkt mij een veel beter plan, maar die zijn nergens geimplementeerd.

1 werkt op basis van DNS, maar is natuurlijk zonder DNSSec niet veilig genoeg.

Jammer dat IANA de root beheert voor DNS en ook de IP's uitgeeft anders was het misschien zinnige geweest een andere DNS-root voor bgp te gebruiken. Dat was dan een mooie test voor DNSSec geweest. Nu staat dat hele traject stil.

Feedback!
Fill out my online form.
Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.