I motsetning til phishing krever ikke pharming at brukeren klikker på en ondsinnet lenke. Dette gjør at pharming er en større trussel en phishing.

Hostfile

En angriper kan endre en brukers hostfil ved å installere malware, eller redigere filen direkte. En hostfil vil fortele maskinen hvilken ipadresse som skal slåes opp for en gitt nettadresse.

Et tenkt scenario er at en angriper setter opp en egen webserver med en kopi av paypal sine websider. Når dette er gjort redigerer han hostfilen til offeret slik at den gir ipaddressen til angriperens webserver som resultat på forespørselen www.paypal.com. Når brukeren så går til paypal.com vil han se en side som ser helt legitim ut, men når han prøver å logge inn vil angriperen få brukernavn og passord, og kan bruke dette på den reelle paypal siden for å stjele offerets penger.

# This is an example of the hosts file
127.0.0.1 localhost loopback
::1 localhost
10.11.12.13 paypal.com

Mange hackerkits har egne verktøy som tar kopi av legitime sider og klargjør de for denne typen angrep.

DNS

Om ikke maskinen finner et oppslag i hostfilen vil den spørre sin nærmeste navnetjener etter svar. Dersom denne navnetjeneren ikke har informasjonen som trengs, vil den igjen spørre sin nærmeste navnetjener. Sånn vil det fortsette helt til man treffer en navnetjener som kan svare på forespørslen

Disse navneoppslagene er en av de viktigste funksjonene på Internett.

DNS Pharming

Målet her er det samme som i hostfile eksempelet over, men istedet for å redigere en lokal fil på offerets datamaskin, angriper man en navnetjener. Angriperen er nå ute etter å infisere navnetjenerens DNS cache (cache poisoning) med falske oppslag. Fordelen med å infisere navnetjeneren istedetfor hostfilen er at det er veldig mange maskiner spør en gitt navnetjener, så angriperen får lurt flere besøkende til den falske ondsinnete siden sin.

Klassisk angrep

Angrepet

Angriper lager en webside som har et bilde som er lenket fra hackershotel.com.

Brukeren besøker websiden, og nettleseren må nå foreta et oppslag for hackershotel.com for å finne bildet.

Brukerens ISP har ikke hackershotel.com på sin navnetjener, så den spør hackershotel.com sin egen navnetjener.

Denne svarer, men sender samtidig oppføringer for andre domener, for eksempel paypal.com.

ISP sin navnetjener tar imot og lagrer den nye informasjonen den har fått fra hackershotel.com sin navnetjener. I tillegg til den nye informasjonen, lagrer den også de oppdaterte pekerene til paypal.com siden den alikevel har fått disse fra hackershotel.com.

Angriperen har nå lykkes med å infisere ISP sin navnetjener for paypal.com med falske oppføringer. Når andre brukere nå spør ISP navnetjeneren etter paypal.com vil de bli sendt til angriperenes server.

Fiksen

Dette problemet har blitt fikset ved å ignorere all ekstra informasjon som ikke gjelder domenet som forespørslen opprinnelig var ute etter. Denne fiksen kalles Bailwick checking og ble implementert i de aller fleste DNSer på slutten av 90-tallet.

Dette klassiske angrepet er altså veldig gammelt, og sluttet å fungere for mange år siden, men illustrerer godt konseptet bak DNS poisoning.

Enda et klassisk angrep

Det andre klassiske angrepet baserer seg på at det ikke er noe autentisering mellom navnetjenere, og at det ikke er noe integritetssjekk av kommunikasjonen mellom navnetjenerene. Den eneste kontrollen har vært at hver forespørsel har fått en numerisk id som må matche med svarene som kommer tilbake. Frem til slutten av 90-tallet ble disse nummerene tildelt i rekkefølge, men dette har blitt endret til at tildelingen er tilfeldig.

Uansett har en forespørsel id kun 16 bit, som gir 65536 mulige verdier, noe som gir angriperen en fair sjanse for å gjette riktig id om han får prøve mange nok ganger.

Angrepet

Angriperen sender en forespørsel til en navneserver om å slå opp et navn som den ikke har lagret i sin cache.

Navneserveren vil nå sende forespørslen videre i hierarkiet til den treffer en navneserver som har svar på forespørselen, og så returneres svaret.

Mens navnetjeneren venter på et legitimt svar vil angriperen bombadere navneserveren med en falsk ip og forskjellige ider. Om angriperen greier å svare med riktig id før det legitime svaret kommer tilbake vil angriperens falske ip bli lagret og det legitime svaret bli avvist siden angriperen var først ute.

Fiksen

Etter at tildelingen av id nummer gikk fra å være sekvensiell til å bli tilfeldig er det veldig små sjanser for en angriper å gjette riktig id. En addresse blir lagret i DNS cachen en stund, så om angriperen mislykkes må han vente før han kan forsøke angrepet på nytt. Dette angrepet er derfor ikke særlig effektivt, og dermed lite utbredt.

Kaminskys attack

Dan Kaminsky modifiserte de to klassiske angrepene for å komme rundt bailwick checking og tilfeldig generering av forespørsel id.

Everything breaks when DNS breaks

Angrepet

Angriperen spør navnetjener etter en ikke-eksisterende adresse innenfor et domene, f.eks aaa.paypal.com

Navnetjeneren vil sende forespørslen videre helt til den kommer til paypal sin egen navnetjener.

Angriperen vil bombadere navnetjeneren med falske svar og tilfeldig genererte forespørsel id i håp om at en av forespørsel idene skal være riktige, og komme inn før svaret fra paypal sin legitime navntjener.

Om angriperen feiler med aaa.paypal.com kan han gjenta angrepet med aab.paypal.com.

Tilslutt vil angriperen lykkes med å gjette riktig forspørsel id før den legitime navnetjeneren rekker å svare, og siden angriperen har sendt forespørsel etter noe innenfor paypal.com domene, vil han få oppdatere informasjon for hele domenet.

Fiksen

I 2008 ble det introdusert en fiks som gjorde at også portnummeret som DNS forespørslene bruker ble generert tilfeldig. Nå må angriperen gjette riktig både 16 bit forespørsel id, samt 16 bit portnummer.

DNSSEC er en utvidelse av DNS som har som mål å sikre informasjonen i DNS mot den type angrep som jeg har skrevet litt om her.

Drive-by-pharming

Igjen handler det om å endre DNS innstillinger, men i dette angrepet er det ikke navnetjenere eller enkeltmaskiner som er målet. Dette angrepet baserer seg på at veldig mange hjemmerutere er satt opp med ingen, eller standard passord for å administrere ruterens innstillinger.

Angrepet

Angriperen bruker først en java applet som gir han informasjon om det interne nettet offeret er på. Om offeret har en ip-addresse 10.0.0.3 på det interne nettet, vil ruteren i de aller fleste tilfellene befinne seg på 10.0.0.1 eller 10.0.0.100. Det er denne ruteren som er målet.

Når må angriperen finne ut hvilken ruter som skal angripes. Dette kan gjøres ved å søke etter kjente elementer som finnes i ruterenes webgrensesnitt, for eksempel bilder, css tagger og andre html elementer.

Når modellen er funnet gjenstår det bare å autentisere med de mest brukte standard brukernavn / passord kombinasjonene.

Om angriperen har nådd så langt har han full kontroll over ruteren. Han kan flashe firmware, endre innstillinger osv. I dette tilfellet vil han endre ruterens DNS server til å peke til sin navnetjener. Angriperen vil nå kontrollere alle oppslag som blir gjort av alle maskiner som befinner seg bak den kompromitterte ruteren.

Angriperen kan nå sende brukeren til sine ondsinnete sider for å stjele brukernavn, passord og andre sensitive opplysninger. Eventuelt kan han sette opp sin egen Windows update server og så rediregere brukerens windowsupdate.com opplslag til sin falske Windows update server. Han kan nå installere malware kamuflert som windows oppdateringer, eller sørge for at ingen av maskinene faktisk får de legitime oppdateringene de skal ha, og dermed vil være sårbare for kjente sikkerhethutshull.

I motsetning til private datamaskiner står disse ruterene gjerne på å månedsvis med direkte tilkobling på nettet, uten at noen oppgraderer programvaren, sjekker enheten for virus eller gjør noen andre mottiltak. I mange tilfeller vil mest sansynlig eieren av ruteren aldri oppdage at ruteren har vært utsatt for et vellykket angrep.

Fiksen

Det første man bør gjøre er å endre administrator passordet på ruteren til et sikkert passord. Forhåpentligvis vil leverandørene begynne å levere rutere til hjemmemarkedet med et standard oppsett som er sikrere en det som har vært praktisert til nå.

Det andre man bør gjøre er å skru av java i nettleseren, og / eller ikke tillate ukjente java appleter å kjøre på maskinen. Husk at drive-by-pharming blir initiert ved at brukeren godkjenner at en ondsinnet java applet får kjøre.

Referanser

• http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug
• http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
• http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR641
• http://en.wikipedia.org/wiki/Hosts_(file)