En av mine oppdragsgivere sendte meg på et RIPE NCC-kurs i Edinburgh i forrige uke. Kurset omhandlet primært routing (eller rooting som en av våre nyfunnede britiske venner insisterte på å kalle det… Gale briter) gjennom RIPE-databasen, om hvordan man kunne sette opp RIPE-databasen til å eksponere informasjon om routing på BGP-nivå.

Kurset i seg selv var forferdelig nyttig, både for min oppdragsgiver som nå har spart enorme mengder penger, og for meg selv som lærte forferdelig mye både om BGP, RIPE og hvor fantastisk sårbart internett faktisk er.

Under kurset ble vi altså oppfordret av RIPE NCC til å bruke RIPE databasen til å eksponere vår routinginformasjon, og vi lærte hvordan vi kan bruke automatiske verktøy for å konfigurere routere basert på hva som ligger i RIPE-databasen. I utgangspunktet er dette veldig nyttig fordi det åpner for at man kan oppdatere sine samarbeidspartnere sine routere når man selv endrer sin routinginformasjon.

Det som derimot sjokkerte meg, dypt ned i hårrøttene, og som jeg fortsatt har vanskelig for å tro, er den totale mangelen på sikkerhet i RIPE-databasen. Jeg trodde ikke et knyst på min kollega når han fortalte at tilstandene faktisk var tilfellet, det var først når jeg fikk det bekreftet både fra andre kursdeltakere og RIPE NCC selv at jeg begynte å forstå hvor sårbart dette var.

Alle objekter i RIPE-databasen er beskyttet av en såkalt maintainer, som egentlig bare er en autoriseringswrapper. Denne maintaineren har et tilknyttet passord som man må oppgi for å gjøre endringer på objektet som maintaineren beskytter. Streit nok.

Problemene begynner nå… For å bruke passordautentisering på maintainerobjektet må man sende passordet i klartekst. Yep, that’s right, selv om passordet er MD5-kryptert i RIPE-databasen må man fortsatt sende dette i klartekst når man skal autentisere og autorisere seg.

En bitteliten ting i RIPE-databasen sin favør er her at forbindelsen kan SSL-krypteres når man sender inn over HTTP og dermed er det hakket vanskeligere å avlytte. Man må nå plutselig _se_ at passordet skrives inn. Eller bruke en av MITM-angrepene som er beskrevet i litteraturen.

Det er også slik at passordene ikke trenger å være MD5-kryptert i det hele tatt, de kan også være kryptert med den relativt svake CRYPT-PW, som begrenser passordets lengde til 8 tegn. Mange objekter, også relativt nye, er kun beskyttet med CRYPT-PW passord, og derfor relativt åpne for direkte bruteforce-angrep.

Videre er det situasjoner der man faktisk trenger to passord for å autorisere en oppdatering. Den eneste måten å få til dette er å sende meldingen inkludert det ene klartekstpassordet til den andre som skal skrive inn sitt klartekstpassord. Galskap i beste fall…

Men det stanser ikke der, nei, for det er også slik at veldig mange objekter ikke er beskyttet i det hele tatt! Foredragsholderen fortalte om en uheldig utvikler som skulle lage et script for å slette en del testobjekter. Dessverre var ikke scriptet testet skikkelig selv og fyren endte opp med å slette 30.000 RIPE-objekter som ikke hadde noen beskyttelse, objekter som tilhørte helt andre brukere og kunder enn den som kjørte scriptet.

Til nok et forsvar av RIPE skal det nevnes at de har muligheten for å signere endringsmeldinger i stedet for å bruke klartekstpassord. Dette har for eksempel NORID krevet av sine domeneregistrarer i lang tid, mens RIPE kun har det som en mulighet. NORID tok jobben med å innføre krav til PGP-signering og det er det minste RIPE bør gjøre, for å unngå at kritiske objekter kan slettes mer eller mindre ad hoc av hvem som helst.

Og ja, jeg sa hvem som helst, og jeg mener hvem som helst. Objekter som ikke har sin mnt-by kan endres av alle som gidder. De aller, aller fleste nyere objekter er beskyttet, men det finnes eldre objekter som ikke er det. Gjøre et søk i RIPE-databasen, finn et objekt uten mnt-by, og gjør oppdateringene du vil via oppdateringsverktøyet som RIPE gjør lett tilgjengelig. Du kan også lage dine egne objekter, om du skulle ha noen interesse av det.

Mitt konkrete spørsmål til kursholderene var som følger: Hvis jeg da kan endre på routinginformasjon i RIPE-databasen som igjen reflekteres i faktiske BGP-routinger så betyr det at jeg kan stanse hele det europeiske internettet?

Svaret fra kursholderene var “Does he have a tiny version of himself there, og perhaps a cat?” hvorpå det ble bekreftet at dersom RIPE-routingobjekter ikke var tilstrekkelig beskyttet så kan man i teorien lamme store deler av det europeiske internettet. Når man så vet at passordene for å gjøre dette, uansett om objektene er beskyttet, sendes i klartekst så begynner jeg å skjønne hvor mirakuløst det er at internett i det hele tatt fungerer.

Min oppfordring til RIPE er å innføre krav til signering av alle endringsmeldinger umiddelbart. Det er kun et tidsspørsmål før noen starter et massivt angrep som potensielt kan stanse eller skade store deler av det europeiske internettet. I mellomtiden må alle vedlikeholdere av RIPE-objekter oppfordres til å sikre sine objekter med signaturer. Vi andre får bare folde våre hender og be til våre respektive deitier.

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

Leave a Reply

Your email address will not be published.