Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 28 reacties

Het border gateway-protocol, een van de belangrijkste protocollen van het internet dat is gebaseerd op vertrouwen, wordt sinds dit jaar actief misbruikt voor het uitvoeren van man-in-the-middle-aanvallen. Dat stellen onderzoekers van Renesys, dat ip-verkeer monitort.

Het misbruiken van het border gateway-protocol voor het uitvoeren van man-in-the-middle-aanvallen is in theorie al veel langer mogelijk, maar dit jaar is het bgp voor het eerst op grote schaal gebruikt voor het onderscheppen van internetverkeer. Dat schrijft Renesys, dat voor zijn klanten het internetverkeer monitort. Volgens het bedrijf zijn er dit jaar op meer dan zestig dagen in totaal 1500 individuele ip-blocks gekaapt, voor perioden die varieerden van minuten tot dagen. Mogelijk zijn ook Nederlanders slachtoffer geworden, zo blijkt uit een kaart die Renesys heeft gepubliceerd.

Het bgp is een belangrijke pilaar van internet: het zorgt ervoor dat verschillende netwerken met elkaar verbinding kunnen maken, door aan te geven volgens welke route een bepaald ip-netwerk kan worden bereikt. Providers hebben daartoe bgp-routers die informatie over bereikbaarheid over tcp uitwisselen. Het bgp stamt nog uit de begindagen van Arpanet, de voorloper van internet, en hoewel het protocol meerdere keren is aangepast, is het nog steeds gebaseerd op vertrouwen. Bgp-routers nemen route-informatie zonder verdere verificatie van elkaar over.

Het op vertrouwen gebaseerde model was in de tijd van het kleinschalige Arpanet geen probleem, maar vandaag de dag kan het voor grote verstoringen zorgen. Dat gebeurde in het verleden bijvoorbeeld toen Pakistan YouTube wilde blokkeren, en de nationale internetprovider bgp gebruikte om het internetverkeer naar YouTube te blokkeren. Die wijziging werd opgemerkt en opgepakt door andere bgp-routers, waardoor al het internetverkeer naar ip-adressen van YouTube in feite naar Pakistan ging en de site feitelijk onbereikbaar werd.

Pakistan kaapte het wereldwijde YouTube-verkeer onbewust, maar dit jaar is er een aantal aanvallen geweest die wijzen op kwadere bedoelingen, stelt Renesys. Zo heeft een provider in Wit-Rusland, over het algemeen gezien als een dictatuur, via bgp internetverkeer uit onder meer de Verenigde Staten, Zuid-Korea, Duitsland en Tsjechië onderschept. Daarbij ging het om internetverkeer van onder meer overheden en financiële instellingen. Internetverkeer werd omgeleid naar Minsk, waarna het weer naar de originele bron werd verstuurd. Door de omweg via Minsk zou het land internetverkeer kunnen onderscheppen en analyseren.

In een ander voorbeeld onderschepten providers uit IJsland internetverkeer. In één voorbeeld werd verkeer tussen twee locaties in dezelfde stad, Denver, dankzij het border gateway-protocol omgeleid via IJsland. Volgens de provider ging het om een softwarefout; als dat echt zo is, is dat een ernstige bug, stelt Renesys.

Overigens zijn bgp-fouten en -hacks eenvoudig op te sporen: iemand kan zelf een traceroute uitvoeren om te kijken of het internetverkeer een logische route volgt. Eerder stelde een werkgroep voor om een systeem te gebruiken vergelijkbaar met ssl, waarbij bgp-routes worden ondertekend, zodat internetverkeer niet zomaar een andere route kan nemen.

bgp-detour via minsk

Moderatie-faq Wijzig weergave

Reacties (28)

Strikt filteren van peers is helaas geen oplossing, dit is namelijk te arbeidsintensief gezien het internet dynamisch hoort te zijn.

Voor dit probleem is er reeds een oplossing, namelijk: BGP origen validation (RPKI). Met RPKI kunnen ISP's de prefixes die ze bezitten laten signen door hun RIR. Vervolgens kunnen BGP routers routes valideren. Als er een route "valid" blijkt te zijn zou deze altijd de voorkeur moeten hebben.

Helaas zijn er nog weinig grote partijen die hun prefixes signeren. Facebook doet het bijvoorbeeld wel.

Hier een video van RIPE die het uitlegt in 3 minuten: http://www.youtube.com/watch?v=I3Owb0u8Wuk
Hier een tool die ik gemaakt heb voor SURFnet welke inzicht geeft in de gesigneerde prefixes: http://rpki.surfnet.nl/
En het bijbehorende rapport voor mensen die er meer van willen weten: http://staff.science.uva..../2012-2013/p59/report.pdf
RPKI is zoals Jay-v zegt het antwoord op dit probleem: http://ripe.net/certification

Op dit moment biedt dit systeem de mogelijk tot BGP Origin Validation, maar het vormt het fundament voor een systeem dat ook path validation mogelijk maakt. Standaarden hiervoor worden op dit moment ontwikkeld in de Secure Inter-Domain Routing working group in de IETF.

Het mooie van RPKI is dat Cisco en Juniper routers native ondersteuning bieden aan deze technologie, wat het publiceren van statements over de BGP routing configuratie tot het gebruiken deze data set een naadloze oplossing maakt.

Over het gebruik: van de 100 groostste ISPs in Europa, Rusland en het Midden Oosten, heeft ongeveer 60% RPKI opgezet, waaronder KPN, XS4ALL, Deutsche Telecom, France Telecom en Telefonica.
RPKI is inderdaad wel een mooie oplossing vooral omdat dat implementeren door een ISP er meteen voor zal zorgen dat zijn klanten gevalideerde routes krijgen (voorlopig nog enkel op origin dan, nog niet echt AS Path). Voor zover routes gevalideerd kunnen worden natuurlijk, alle 'Not Found' routes weigeren is voorlopig geen oplossing maar het lijkt me dat ook NSP's die belangrijke sites hosten wel mee zullen gaan doen aan het registeren / laten signen van routes.

Overigens is dit wel een interessant artikel betreffende RPKI en de werking ervan: http://www.cisco.com/en/U...n/xe-3s/irg-origin-as.pdf

[Reactie gewijzigd door ik222 op 20 november 2013 12:51]

RPKI is zoals Jay-v zegt het antwoord op dit probleem: http://ripe.net/certification
Ik heb net even wat gegoogled.

Voor zover ik kan zien, is RPKI een tool om te kijken of een prefix wel origineel geadverteerd wordt door het AS aan wat het is toegewezen. Meer niet.

Zo'n tool kan goed helpen tegen misconfiguraties. Maar het helpt weinig voor security als er opzettelijke kwaadaardigheid in het spel is.
Over het gebruik: van de 100 groostste ISPs in Europa, Rusland en het Midden Oosten, heeft ongeveer 60% RPKI opgezet, waaronder KPN, XS4ALL, Deutsche Telecom, France Telecom en Telefonica.
Prachtig. Maar ik las net dat nog geen 3% van de prefixes in de global routing table aanwezig is in RPKI. Dat zet geen zoden aan de dijk natuurlijk. En het betekent ook dat waarschijnlijk ~3% van de ISPs in de gaten zal hebben als jouw keurig ge-authenticated prefixes door een ander gehijackt worden.
Routes uit de RIR (zoals RIPE) halen is wat ik bedoel met strict filteren. Op zich hoeft dat niet arbeidsintensief te zijn omdat je tools heb die automatisch je prefix lists kunnen bijwerken op basis van wat in de RIR staat.

Signeren is inderdaad het mooiste maar als iedereen al eens zou beginnen met route objects uit bijvoorbeeld de RIPE database halen zou dat al veel helpen. Helaas heb je heel veel partijen die dat om praktische redenen of onbewust niet doen en ook partijen die het bewust niet doen omdat ze zich aan de 'dark side' van het internet bevinden

[Reactie gewijzigd door ik222 op 20 november 2013 10:53]

Border GateWAY protocol :)

Verder is hier wel eea voor te regelen, RIPE bijvoorbeeld heeft de mogelijkheid je prefixes daar vast te leggen zodat een ander ze kan verifieren alvorens ze te accepteren. Maar als je ziet wie er af en toe `gratis` transit op de AMS-IX naar zicht toetrekken gebeurd dat nog veel te weinig.

Verder is SSL verificatie leuk, maar de kracht van BGP is juist dat je via andere paden alsnog je bestemming kan vinden

[Reactie gewijzigd door _-= Erikje =-_ op 20 november 2013 08:12]

Verder is SSL verificatie leuk, maar de kracht van BGP is juist dat je via andere paden alsnog je bestemming kan vinden
Dat is nu juist de bedoeling. Dat je de paden die je niet vertrouwt negeert. En je traffic stuurt via de paden die je wel vertrouwt.

Het eerste waar ik aan dacht toen ik dit artikel las:
Never attribute to malice that which is adequately explained by stupidity.
Toevallig kwam ik die quote ook tegen in een van de eerste publicaties over RPKI die ik net las. :)
Ik denk dat wat deze onderzoekers zagen voornamelijk misconfiguraties waren, en geen kwaadwillendheid.

Ik keek net even hoe Renesys (de schrijver van deze publicatie) zijn geld verdient.
http://www.renesys.com/products/
Routing alarams.
Provides network operations teams with real-time alerts and notifications to protect their critical operations and networks from costly attacks, disruptions and damage.
Dat is dus duidelijk.
Renesys verdient geld met mensen waarschuwen als er iets mis is met de global routing. Voordat mensen geld gaan betalen om gewaarschuwd te worden, moeten ze eerst weten hoe verschrikkelijk verschrrrikelijk erg het gesteld is met de veiligheid van BGP routing. Snel mensen, snel geld betalen aan Renesys, dan waarschuwen die je als de Russen je prefixes proberen te kapen.

[Reactie gewijzigd door gryz op 20 november 2013 15:17]

Authenticatie op een BGP sessie heeft geen zin om het probleem wat in dit artikel beschreven wordt tegen te gaan. Waar het namelijk om gaat is dat routers ergens in het internet meer specifieke routes gaan announcen waardoor verkeer daar heen getrokken wordt. Die meer specifieke routes worden vervolgens doorgegeven door de upstream providers waardoor op steeds grotere schaal verkeer de verkeerde kant op gaat.

De enige manier om dit soort aanvallen kansloos te maken is het implementeren van strikte filtering van prefixes op basis van RIPE informatie. Maar als je dat zelf als provider netjes doet wil dat alleen maar zeggen dat jij niet bijdraagt aan het in stand houden van dit soort aanvallen. Het wil niet zeggen dat jou routes niet ergens op (een gedeelte van) het internet gekaapt kunnen worden omdat er partijen zijn die bewust of onbewust foute prefixes wel accepteren.
Ik weet idd niet precies meer hoe BPG bepaalt via welke AS hij zijn traffic gaat sturen, maar ging er wel vanuit dat hij dan eerst vast stelt dat die AS er is en dat die peer, is wie hij zegt datie is.

Net zoals een gewone eigrp, rip of ospf router, een route laat vallen. als hij de next hop van die route kwijt is.
Lijkt mij dus een probleem van providers die onvoldoende checken met wie dat ze te doen hebben.
Het zou mij ten zeerste verbazen als op dat niveau iedereen zomaar mee mag peer-en
Ik weet idd niet precies meer hoe BPG bepaalt via welke AS hij zijn traffic gaat sturen,
Bij default kies je het pad met de kortste AS-length.
Het mooie van BGP is echter dat je heel veel mogelijkheden hebt om zelf policies te creeeren welke routes je prefereert.
Details over path selection kun je hier lezen.
maar ging er wel vanuit dat hij dan eerst vast stelt dat die AS er is
Nee. Als je een pad accepteert van je buurman, dat zegt dat prefix X ergens ver weg bereikbaar is, dan geloof je dat gewoon. Er is geen mogelijkheid om direct te communiceren met een AS waar je niet zelf direct aan grenst.
en dat die peer, is wie hij zegt datie is.
Dat wel. Via het IP adres natuurlijk, en via cryptografie.
Net zoals een gewone eigrp, rip of ospf router, een route laat vallen. als hij de next hop van die route kwijt is.
Voor de goede order: OSPF (en IS-IS) werken heel anders dan RIP en EIGRP.
Lijkt mij dus een probleem van providers die onvoldoende checken met wie dat ze te doen hebben. Het zou mij ten zeerste verbazen als op dat niveau iedereen zomaar mee mag peer-en
Het probleem is niet dat je je direct peers moet vertrouwen. Het probleem is dat je ook hun peers moet vertrouwen. En de peers van de peers van de peers. Etc. Een beetje zoals geslachtsziekten. Je kunt je bedpartner wel vertrouwen misschien, maar vertrouw je ook de (ex-)partners van de (ex-)partners van je partner's partner ?
daarnaast ondersteunt BPG net als eigrp en ospf encryptie waardoor niet elke elke router zomaar in the topology terecht kan komen.
Forgive me if I'm wrong, maar wordt daar geen ander protocol voor gebruikt? BGP checkt of een AS toegang heeft en "advertised" dat vervolgens aan zijn peers via welke route dan ook beschikbaar is. Die gaan, eenmaal bekend met elkaar, controleren via welke route het "goedkoopste" traject kan worden afgelegd en dan established men die route(s) en is t feestje compleet, maar dat laatste gebeurd met een ander routing protocol.
Wat is er toch zo logisch aan die kaarten met witte zee en blauwe landen?!
Ik voelde me al dom. Ashburn zag ik even aan voor Amsterdam, dat was een vreemde kaart van Europa... toen viel het kwartje.
Lol idd! Ik werd er zelf ook een beetje scheel van...
oh crap ik dacht dat ik naar het zuiden van afrika zat te kijken, nu zie ik dat het zuid amerika is lol, beetje uitgezoomd.
Dat krijg je als vormgevers zich gaan bemoeien met zaken die al lang "vast" gebruikt worden.
Of een kleurenblinde vormgever?
het uitgangspunt van 100% vertrouwen en dergelijke klopt al jaren niet meer. Heel veel organisaties gebruiken hashing en authenticatie mechanismen voor het betrouwbaar maken van de broninformatie. Op die manier voorkom je dat een man-in-the middle de informatie kan vervuilen.

Daarnaast wordt ook meestal geverifieerd of de info klopt door middel van route filters. voldoet de info niet aan het filter gaat het de bittenbak in.

Als je die mechanismen niet gebruikt doe je het jezelf aan. Dat ligt niet aan BGP.
Authenticatie van prefixes door cryptografisch tekenen door het source-AS is een idee dat al minstens 15 jaar bestaat. Misschien wel 20.

Het probleem was altijd dat het (verhoudinggewijs) ontzettend veel rekenkracht kost om de handtekening van een prefix te checken. En als je 500.000 prefixs hebt op het Internet, dan wordt dat wel een heel zwaar rekenkundig probleem. Misschien niet als je een stub-AS bent, en slechts een paar routes ontvangt. Maar als je full-routing doet, en verschillende full views binnen krijgt van verschillende peers, dan heb je zo meer dan een miljoen paden in je BRIP. En die moeten allemaal gecheckt worden.

Dat was lang geleden zo. Routers hebben nu snellere CPUs in hun control-planes zitten. Maar het aantal prefixes is ook ontzettend toegenomen. En hardware om encryptie te kraken is verhoudingsgewijs (zelf ASICje branden, ala bitcoin) nog goedkoper. Ik kan me niet voorstellen dat de situatie nu beter is dan 10-15 jaar geleden. En dat cryptografische authenticatie van prefixes nog steeds practisch onhaalbaar is. Weet er iemand meer ?
Haha, dit onderwerp is duidelijk niet mijn cup of tea. de acroniemen en jargon vliegen me hier om de oren. :+ Ik kan er niet al teveel soep van maken als software developer. Zou me een uurtje wikipedia kosten om Łberhaupt wat meer te begrijpen wat er nou precies gezegd wordt in bovenstaande reacties.

Dat er flaws in het ontwerp van bepaalde protocollen zat wist ik wel. Het zou dus niet helemaal als een verrassing moeten komen dat dit zo makkelijk gaat. Ik sta er echter toch een beetje van de te kijken. Kan me voorstellen dat het kosten/baten verhaaltje er toe leidt dat dienstverleners niet in de startblokken staan om verbeteringen zoals waar in de reacties hierboven wordt gesproken te implementeren.

De NSA lacht zich ondertussen rot volgens mij. Die zijn helemaal niet gebaat bij die beveiligde protocollen e.d.
Als je iemand opbelt, weet je zeker dat de call dan ook echt bij zijn telefoontoestel uitkomt ?

Nee. Je vertrouwt je telefoonmaatschappij. En jouw telefoonmaatschappij vertrouwt de telefoonmaatschappij van de persoon die jij belt. Maar je weet niks zeker.

Zo werkt het hier ook. Je vertrouwt erop dat je pakketjes naar de goede eindbestemming worden gestuurd. Helaas zijn er manieren om dit vertrouwen te misbruiken, en pakketjes naar jou richting op te laten sturen. Zodat je ze kunt afluisteren. Of veranderen.

Dit is echter een ineffectieve manier voor de NSA om jouw verkeer af te luisteren. En het zou direct in de gaten lopen.

Het probleem is al lang bekend. 20 Jaar of meer. Maar wat doe je er tegen ? Zoals altijd bij security, zul je cryptografie moeten toepassen. Voor authenticatie. Daar zijn altijd problemen bij: 1) het maakt alles veel gecompliceerder, 2) alles wordt minder robust omdat je eerder configuratie fouten maakt, en 3) het kost een hoop extra rekenkracht. Rekenkracht die er niet altijd is. Ik kan me herinneren dat er al 15 jaar geleden over cryptografische oplossing werd gesproken. Het feit dat die er nog steeds niet zijn geeft aan dat het geen triviaal probleem is.
Op zich off-topic, maar wel interessant om aan het aantal reacties op dŪt topic te zien dat een mechanisme wat essentieel is voor de juiste (en vooral stabiele) werking van 'ons' internet blijkbaar dusdanig complex is dat relatief weinig Tweakers zich hier aan een reactie wagen.
(Dit in vergelijking tot een artikel over het blokkeren van TPB, waar op dit moment gemiddeld 1 reactie per minuut is gegeven.)
Niet iedereen heeft hier kaas van gegeten natuurlijk. Tenzij je CCNA of iets dergelijks gedaan hebt.
Dus zo gek is dat niet.
*grinnik* BGP pas vanaf dit jaar misbruikt...? Neem er nog een jongens :P Dat wordt al langer misbruikt, een paar jaar geleden zijn er wat algoritmes en redundante checks ingebouwd in de protocollen en advertising van netwerken om te zorgen dat het niet meer zomaar gejihacked wordt e.d., maar toch slaagden mensen er nog in om fake routes te adverteren... Daarmee kon al het verkeer onderschept worden, phising opgezet worden, verkeer afluisteren, etc.

Kortom: niets nieuws dunkt mij.
Overigens zijn bgp-fouten en -hacks eenvoudig op te sporen: iemand kan zelf een traceroute uitvoeren
lekker makkelijk gesteld. Ik kan prima traceroutes negeren en de TTL niet naar beneden bijstellen. Vervolgens het verkeer na dat het omgeleid is weer de juiste kant op sturen en er is niets zichtbaar.
In jou deel van het netwerk misschien. Maar niet in de delen van het pad voor en na jouw netwerk. Ik heb zo'n vermoeden dat het in de meeste gevallen gewoon onmogelijk is om de veranderingen te verhullen voor traceroute.
Ja en nee.
Het ligt eraan wat de verandering is. Als iemand niet uit z'n hoofd weet hoe de route eerst liep (wat ik trouwens me heel goed voor kan stellen) en er komt opeens 1 hop of een time-out bij tussen een aantal hops in, dan kun je niet per direct weten of dat nou wel of niet de bedoeling is, zeker niet als een leek.
Kortom: het hoeft niet eens perse verhuld te zijn om onopgemerkt er in te zitten.

Het wordt pas overduidelijk raar als je naar de USA wil, en je routeert eerst via Pakistan.
Dan kan je wel even achter je hoofd krabbelen wat er in godsnaam aan de hand is.

[Reactie gewijzigd door WhatsappHack op 21 november 2013 13:08]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True