Nätverkshacking

WPS - Weakly Protected Setup? - Del 2

Publicerat: 
2016-12-30

<<<< Tillbaks till Del 1 <<<<

Denna blogginläggsserie på två delar behandlar WPS, vilket är en extra funktion för trådlösa nätverk som genom sin konstruktion är väldigt bristfällig.
I första inlägget, del 1, förklaras kort vad WPS är och varför det är så sårbart, och i denna del (del 2) utför vi praktiska tester där vi genomför attacker mot två WiFi-enheter.
 

Förberedelser

Airmon-ng

För att Reaver ska fungera bra behöver man en dator med ett nätverkskort som går att sätta i ”Monitor mode”. För att aktivera monitor mode kan vi använda verktyget airmon-ng.
En snabb koll med kommandot iwconfig visar att datorns trådlösa nätverksgränssnitt heter ”wlan0”. Det är den enda uppgift man behöver för att starta airmon-ng, vilket vi då kan göra med kommandot: 
airmon-ng start wlan0 
Airmon-ng svarar med att den satt wlan0 i monitor mode på ett nytt gränssnitt ”mon0”, men om man vill dubbelkolla kan man återigen använda iwconfig, och bekräfta att man nu har ytterligare ett gränssnitt. Som ni ser på bilden finns mycket riktigt nu en ny post som heter mon0, och är i ”Mode:Monitor”. 
Om vi skulle vara riktiga angripare skulle vi nu kanske vilja dölja vår egen identitet så mycket som möjligt, och därför ändra (”spoofa”) vår egen dators MAC-adress. Detta är en trivial uppgift som man exempelvis skulle kunna göra med verktyget macchanger, men det behöver inte göras i vårt fall, så vi hoppar över det.
Förberedelse av gränssnitt med airmon-ng 
 

Wash 

Om vi nu inte skulle ha fysisk tillgång till de routrar vi tänker attackera så behöver vi veta dels vilket BSSID de har, dels om de över huvud taget har WPS igång.
Ett litet verktyg som ger oss bägge dessa uppgifter är ”wash”. Det är utvecklat av samma person som utvecklat Reaver, Craig Heffner.
Man startar det med kommandot: 
wash –i mon0 –s
där ”–i mon0” betyder att vi ska använda gränssnittet mon0, och ”–s” betyder scan. 
Resultatet syns i bilden nedan, där man ser båda våra angreppsmål, deras BSSID och ESSID, att de stöder och har igång WPS version 1.0, att WPS inte är i låst läge, samt vilken kanal de använder.
BSSID:t är samma som MAC-adressen och står ju oftast på bak- eller undersidan av enheterna (se exempelvis tp-link), men en angripare skulle i de flesta fall inte kunna titta där. Vi som har fysisk tillgång till enheterna kan åtminstone dubbelkolla där om vi tror att wash bara hittar på, men det ser onekligen ut att stämma.
Accesspunkternas WPS-information i Wash
 

Brute force-attack 1 – TP-link

Start

Nu har vi de uppgifter som behövs och är redo att utföra själva attacken, och vårt första mål blir TP-link-modemet.
Vi startar attacken med kommandot:
reaver –i mon0 –b F4:EC:38:FF:94:06 -c 11 –vv –x 360
  • mon0 är vårt nätverksgränssnitt i monitor mode som vi skapade med airmon-ng
  • F4:EC:38:FF:94:06 är accesspunktens BSSID som vi hittade med hjälp av wash
  • 11 är kanalen som accesspunkten använder, och det såg vi också i wash. Denna uppgift kan utelämnas, men då måste Reaver leta upp vilken kanal som gäller och det går åt någon sekund extra i inledningen av attacken.
  • 360 är en viloperiod (360 s = 6 min) som Reaver ska pausa om den upptäcker 10 likadana fel i rad, för att låta accesspunkten stabilisera sig.
Inledning av attack mot TP-linkenheten
Bilden visar startkommandot och när Reaver precis startat igång och associerat sig med accesspunkten. Som man kan se på rad 2 i loggen har vi startat en session mot detta modem tidigare. Reaver frågar om man vill återuppta den sessionen men vi valde så klart att inte göra det för att testet skulle göra sig rättvisa, men det är en bra funktion i andra fall.
Efter att man har verifierat att det inte kommer några direkta fel på ett tag kan man i princip lita på att Reaver sköter sig själv, och med gott samvete ta en lång paus och göra annat ett tag.
Vissa accesspunkter har skydd mot brute force-attacker som kan låsa WPS vid för många misslyckade försök. Men om det fortfarande inte visat sig några felmeddelanden på några minuter kan man nog lugnt misstänka att Reaver kommer göra sitt jobb utan problem även resten av tiden.
 

Mellantid

På bilden nedan har processen varit igång några timmar, och man kan se att det tar hela 3 sekunder att evaluera varje PIN. Hastigheten är beroende av fler faktorer, exempelvis prestandan hos accesspunkten, hos datorn samt signalstyrkan mellan dem. Det är trots allt en del beräkningar som görs med Diffie-Hellman-nycklar och checksummor etc.
Här har det gått 4 timmar sedan start och vi kan även se att det kommer att ta max 6 timmar och 8 minuter till om vi har maximal otur. 
Vi ser också vilka typer av meddelanden som skickas och att accesspunkten mycket riktigt sänder en NACK efter meddelandet M4, vilket betyder att vi inte hittat första halvan av koden än. Detta bekräftas ju även när man tittar på vilka PIN-koder som just nu testas: 
Efter 3634 567 0 testas 3635 567 9. Då ser man att den första halvan byts från 3634 till efterföljande 3635, och att de 3 första siffrorna i andra halvan 567 ignoreras just nu och troligen bara är en rest från när den gissade på en av de vanligare koderna 12345670 innan den började med sekventiell gissning. Den sista siffran är som tidigare nämnt en checksumma som vi ser ändras beroende av de andra siffrorna i koden.
Utdrag ur reavers logg under pågpående attack
 

Halva koden hittad

När sökandet pågått i 7 timmar och 20 minuter ser vi plötsligt på första bilden nedan att accesspunkten plötsligt godtar vårat meddelande M4, och skickar meddelande M5 istället för en NACK. Detta betyder att första halvan är rätt, och om vi smygkikar på undersidan av enheten kan vi bekräfta att första halvan mycket riktigt är 6749.
Efter detta ser vi även att den börjar söka efter andra halvans tre okända siffror med början på 000.
 
Den andra bilden är tagen några sekunder efter den första, och visar att även när den börjar med gissningarna på andra delen så börjar den med några vanligare standardkombinationer innan den börjar gissa sekventiellt. 
Vi ser även att de nya statusraderna plötsligt visar rejält mer positiva siffror, eftersom vi slapp försöka ca 3250 sifferkombinationer i steg 1, och nu bara har 995 kvar att försöka med i värsta fall.
Halva PIN-koden hittad Gissningen fortsätter på andra halvan av PIN-koden
 

PIN hittad

Efter ytterligare ca en halvtimme har Reaver slutfört sitt arbete och avslutar. Vi kan se på de sista tre raderna på bilden nedan att den mycket riktigt har hittat rätt PIN, 67495740, och att den serverar oss WPA2-nyckeln på ett silverfat så fort vi använder rätt PIN.
Värt att notera är att det inte spelar någon som helst roll hur lång och avancerad nätverksnyckel man konfigurerat sitt nätverk med. Den temporära långa vi hade satt för detta test och som vi med denna metod fick tag på efter ca 8 timmar, skulle inte kunna crackas av en angripare med en sedvanlig brute force-attack mot WPA under ett löjligt antal miljoner gånger hans livstid, då den är 58 tecken lång och innehåller såväl gemener, versaler, siffror som specialtecken.
PIN hittad och WPA-nyckel erhållen på TP-linkenheten
 

Brute force-attack 2 – Netgear

Start

Med vårt lyckade försök med det något nyare TP-link-modemet nära i minnet angriper vi förväntansfullt vårt andra mål, Netgear-routern på samma sätt.
reaver –i mon0 –b 00:22:3F:95:F5:49 -c 8 –vv –x 360
Självklart byter vi ut BSSID och kanalen mot de som denna router använder, och som vi tidigare tagit reda på med verktyget wash.
Reaver sätter igång och testar PIN-koder exakt som i förra försöket, och allt ser bra ut i inledningen.
 

Låsning

Efter 20 testade PIN-koder händer dock något annorlunda. Routern slutar sända meddelandet M1. Vi får vid upprepade återförsök en timeout i väntan på detta meddelande.
Netgear har tydligen varit tillräckligt förutseende för att inse att WPS skulle kunna utsättas för brute force-attacker, och låter routern låsa för fler inkommande WPS-anslutningsförsök efter gränsen på 20 st misslyckade. 
På bilden ser vi strax nedanför mitten en varning om att Reaver uppfattat att den fått 10 st likadana misslyckanden i rad och har därför då pausat (även om just pausen inte loggats) i 6 minuter innan den återupptog försöken. Denna paus kom sig av vårat argument –x 360 i kommandot, men verkade uppenbarligen inte ha hjälpt eftersom samma timeout fortsätter inträffa i samma anda efteråt.
Låsning av Netgear efter 20 försök
 

Försök att kringgå låsningen

Paus efter låsning
De flesta accesspunkter som låser WPS-funktionen brukar släppa låsningen automatiskt efter en viss tid. 
I vårt första försök hade vi redan något oavsiktligt förberett för detta genom att lägga in en paus på 360 sekunder om något fel inträffar 10 gånger i rad. Denna router talar uppenbarligen inte om att den är låst, utan slutar bara svara vilket blir ett felmeddelande om timeout i Reaver. Därför testar vi först med att använda samma pausfunktion för att pausa en längre period än vad vi gjorde i första försöket för att sedan återuppta försöken och se om det går bättre. 
Detta gör vi genom att höja siffran efter argumentet –x. Vi har redan testat med 6 minuter (360 sekunder), så jag valde att utöka till drygt 15 minuter, sedan 30 minuter osv.
För att bara ta reda på låsningstiden kan man ju även stänga ner Reaver helt och starta om det efter en viss tid för att se om låsningen fortfarande är aktiv om man tycker det är smidigare över långa perioder.
Efter ett antal utökningar av paustiden, drar jag till slut slutsatsen att det dessvärre verkar som att det enda sätt att låsa upp denna router kräver en administratörs handpåläggning, antingen genom att starta om routern eller att stänga av och sätta på WPS-funktionen via webgränssnittet. Jag väntade till slut i nästan ett dygn för att se om den låste upp sig själv, vilket den inte gjorde. Där gav jag upp, för om man bara kan testa 20 PIN-koder per dygn blir attacken något opraktisk, om än genomförbar med nästan två års tålamod.
 
Paus innan låsning
Vi satsar i stället på att försöka få routern att inte låsa sig alls. Det kan ju vara så att den glömmer de tidigare försöken efter en stund. 
Reaver har en funktion även för detta i argumentet –r X:Y, där X är det antal försök den ska göra innan den tar paus i Y sekunder.
Vi börjar testa med –r 19:125. En avancerad gissning, eftersom accesspunkter enligt WPS-specifikationen skall minnas åtminstone 2 minuter tillbaks i tiden.
Då detta inte funkade, utökade jag tiden på ungefär samma sätt som i förra försöket. Jag försökte även några olika kombinationer med ändrat X-värde i argumentet, men routern kom ihåg varenda misslyckat försök och låste sig varje gång. 
Även här sträckte jag mig inte längre än ungefär ett dygns paus utan resultat innan jag gav upp av samma anledning som tidigare.
 
Fördröjning mellan PIN-försök
En viktig parameter som routern kan kolla på för att avgöra om den är utsatt för en brute force-attack är frekvensen av inkommande anslutningar.
Därför försökte jag att med hjälp av argumentet –d utöka fördröjningen mellan de olika PIN-försöken. Jag använde samma teknik som i föregående försök, att utöka tiden en bit i taget.
Även här gick jag bet när jag till slut inte tyckte det var idé att fortsätta då jag bara gjorde ett försök per timme.
 
Övriga försök
Självklart testade jag även några olika kombinationer av ovanstående försök, samt en del andra av Reavers argument. 
Exempel på vilka jag testade trots att jag ansåg många av dem icke relevanta för detta problem är:
  • -l (lock-delay) Att beordra Reaver att ta en paus när den upptäcker att accesspunkter är låst gjorde ingen skillnad eftersom Reaver inte ansåg routern låst, utan snarare bara oresponsiv.
  • -t (timeout) Att utöka tiden för mottagning av paket gav inte bättre resultat.
  • -N (no-nacks) Handlar om att Reaver inte ska skicka NACK-meddelanden, vilket inte var problemet och därför inte heller gjorde skillnad.
  • -L (ignore-locks) Hade ingen effekt eftersom accesspunkten inte visade att den var låst.
  • -E (eap-terminate) Vissa accesspunkter blir tydligen gladare om de får ett EAP FAIL-meddelande efter varje försök, men inte denna.
Jag provade till och med att byta kanal som nätverket använde, till ingen skillnad.
 
Byte av firmware
Till slut ansåg jag Netgears implementation av låsningen i denna enhet tillräckligt säker, men denna enhet hade jag tidigare uppdaterat så den hade den senast släppta inbyggda programvaran (firmware). Kunde det vara någon skillnad i detta avseende på olika firmware, var frågeställningen som dök upp eftersom jag är envis och inte gillar att ge mig i första taget.
Jag nedgraderade således enheten från firmware version 1.2.3.7, som är den senast släppta, till version 1.1.2.6 som är ursprungsversionen för denna modell. 
Jag gick i princip igenom alla ovanstående försök ännu en gång, men utan resultat. Däremot kan man se en skillnad mellan versionerna i form av att Reaver av någon anledning inte signalerar timeout. Jämför nedanstående bild med den tidigare.
Ingen timeoutsignal med äldre Netgear-firmware
 

Godkänt skydd 

Vid det här laget är jag redo att ge upp med slutsatsen att Netgear verkar ha ett bra skydd mot brute force-attacker i sin WPS-implementation.

Avaktivering av WPS

Efter att denna sårbarhet blev offentlig gick de flesta tillverkare ut med tipset på deras hemsidor att stänga av WPS för att skydda sig mot denna attack, och på de flesta enheter kan man göra detta via webgränssnittet. Men det är fortfarande många (speciellt äldre) enheter och firmware som har WPS aktiverat som default i fabriksinställningarna. Båda modellerna vi testat till exempel.
Men vet man bara om problemet kan man alltså stänga av WPS och vara ”säker” igen, skönt. Helt säker kan man ju så klart aldrig vara, men åtminstone mot denna attack. 
Eller kan man?
Det har rapporterats (Okänd/flera författare, 2011-2013) om enheter som inte helt stänger av WPS trots att man väljer detta i administratörsgränssnittet, så det får bli vårt sista test på båda enheterna om de gör det eller inte.
 

TP-link

Trots att användarvänligheten är usel i TP-links webgränssnitt, så går det att hitta avstängningsvalet under den något konstigt valda rubriken ”Multiple SSID settings”, där man för övrigt sätter upp resten av de grundläggande trådlösa inställningarna. Bilden visar en översikt över dessa inställningar innan vi stängde av QSS.
Efter att ha stängt av gör vi en test med Reaver. Vi startar en attack, och prövar då med att lägga till argumentet –L för att ignorera låsningar, för att se om/hur modemet svarar. 
Denna enhet verkar åtminstone stänga av WPS helt, då vi inte får någon som helst respons från den. Vi lyckas inte associera med den, vilket är det första steget och Reaver fastnar då tills man stänger ner med Ctrl-c. Se bild nedan.
Detta anser jag bekräfta att WPS är avstängt och helt oåtkomligt, så TP-link fick godkänt på detta test.
Ingen respons från TP-Linkenheten efter nedstängning av WPS/QSS
 

Netgear

Senaste firmware
Vi gör samma test mot netgear-routern, och börjar med den nyaste inbyggda programvaran laddad, version 1.2.3.7.
Vi börjar med att stänga av WPS, eller som det står i webgränssnittet: ”Avaktivera routerns PIN-kod”. Inställningarna för detta visas i bilden nedan.
Avstängning av WPS i Netgearenhetens GUI
När det är gjort, startar vi återigen en attack mot routern och ser snabbt att det är skillnad mot TP-links implementation, med tanke på att vi lyckas associera med routern och den frågar vem vi är innan den slutar prata med oss. (Se bild nedan)
Nu hjälper det inte oss så mycket, eftersom det ser precis likadant ut som när routern låste sig, och det är säkert på samma sätt de har implementerat avaktiveringen. Vi lyckades inte komma runt låsningen tidigare, så vi lär inte lyckas komma runt avaktiveringen heller.
Vi drar slutsatsen av detta test att denna firmware verkar hålla måttet och låsa ute alla försök till WPS-anslutningar. 
Avaktiveringen lyckas i Netgears nyare firmware
 
Äldre firmware
Eftersom jag tidigare lade märke till att den äldre inbyggda programvaran betedde sig något, än så lite, annorlunda i de andra testerna, så kan det ju vara någon liten skillnad mellan de två på detta test också. 
Så vi laddar åter igen in den ursprungliga versionen 1.1.2.6 i enheten och avaktiverar WPS på samma sätt som ovan.
Vi drar igång en attack, och se god dag då, Reaver börjar faktiskt gissa PIN-koder precis som om WPS inte skulle varit avaktiverat.
Vi hittade till slut en sårbarhet i Netgears implementation! 
Nu har vi ju dock redan testat brute force mot denna firmware, och efter 20 PIN-försök låser den sig, och samma svårigheter att gå runt låsningen uppstår ju även nu. Det ser ut exakt som på tidigare bild, så en extra bild är överflödig.
 
Men ponera exempelvis detta inte helt otänkbara scenario:
Du har fest hemma eller gäster på kontoret, och en av gästerna är en halvt okänd skum bekant till någon bekant, som du vid ett obevakat tillfälle avslöjar snoka vid nätverksutrustningen. Du funderar lite och inser att han kan ha sett PIN-koden på baksidan av routern. Inga problem tänker du, bara att dubbelkolla att WPS är avstängt…
Du säkerställer att WPS är avstängt, och sover nu lugnare på natten i din tro att nätverket är säkert.
Men den skumma gästen tar nu med sig en laptop och sätter sig i bilen utanför huset/kontoret och skriver in detta Reaver-kommando, där han även anger vilken PIN-kod som ska testas med argumentet -p: 
reaver –i mon0 –b 00:22:3F:95:F5:49 –vv –p 55340670 –L
Vilket ger resultatet enligt bilden nedan; ditt långa lösenord som du slitit så länge med för att få extra långt och avancerat överfört till inkräktaren på två sekunder.
Oavsett om du efter detta byter nyckel/lösenord kan han återkomma och köra samma kommando igen när som helst under enhetens livstid (eller tills du byter firmware) för att erhålla den nya nyckeln på samma korta tid. PIN-koden går ju inte att ändra, och tydligen inte heller att stänga av. 
WPA-nyckel erhålles på 2 sekunder med rätt PIN
 

Slutsats

Våra test visade att TP-link TD-W8951ND är sårbar för brute force-attacken, men det går att stänga av WPS (eller QSS) med gott resultat. Vidare visade det sig att Netgear WNR2000 var imponerande motståndig mot attacken, men en bugg i en tidig firmware gjorde att det inte gick att stänga av WPS-funktionen som utlovat.
Mot vissa accesspunkter kan det alltså vara väldigt lätt att utnyttja sårbarheten i WPS. Det kan vara gjort på några timmar eller under ett dygn, vilket är en relativt kort tid om man jämför med en traditionell brute force-attack mot ett WPA-nätverk som har en hyffsat bra nyckel.
Om tillverkaren tillämpat ett bra skydd mot brute force-attacker genom låsning av WPS på ett bra sätt kan det fördröja attacken tillräckligt för att det ska bli opraktiskt att genomföra den.
Om de däremot har gjort en miss i avstängningsfunktionen så att WPS egentligen inte alls stängs av, vilket av någon anledning verkar vanligt, anser jag att det kan vara anledning att stänga av hela enheten (om nu åtminstone det går) och inte använda den igen förrän firmware är uppdaterad som löser problemet, alternativt byta enheten mot en annan modell.
Mitt första intryck av WPS när det var nytt var att det var en totalt onödig extra funktion som verkade tulla på säkerheten en hel del för att vinna en gnutta användarvänlighet (ett vanligt fenomen). Detta intryck har förstärkts ytterligare nu efter jag gjort denna undersökning. Det övergår dessutom mitt förstånd vad som gör just PIN-funktionen mer användarvänlig och varför man skulle komma ihåg en 8 siffrors PIN-kod lättare än en nätverksnyckel man designar själv, trots att PIN-koden är kortare.
Man kan ju för övrigt tycka att det redan är allt för många som inte byter ut sitt default-lösenord till sin nyinköpta router, och WPS-funktionen som i princip kan innebära att användaren inte ens behöver logga in en enda gång i webgränssnittet för att använda routern hjälper ju inte direkt till att påminna användaren om att göra detta.
Det allmänna tipset jag har (förutom att hålla all din utrustning uppdaterad och aktuell), och som stöds av de flesta tillverkarna som implementerar funktionen är: 
Stäng av WPS!
 

 

Skribent(er): 
Peder Sparell

WPS - Weakly Protected Setup? - Del 1

Publicerat: 
2016-11-28

Denna blogginläggsserie på två delar behandlar WPS, vilket är en extra funktion för trådlösa nätverk som genom sin konstruktion är väldigt bristfällig.

Det är ingen ny funktion, och dess sårbarhet som vi tar upp här är inte direkt någon nyhet, men det känns fortfarande aktuellt då förvånandsvärt få känner till hur sårbar deras WLAN-utrustning är på grund av detta, och många har utrustning stående som installerats med defaultinställningar för några år sedan och sedan glöms bort tills de får en ny accesspunkt vid nästa abbonemangsbyte eller tills något slutar fungera. Många vet inte ens vad WPS är och/eller struntar helt enkelt att bry sig om inställningarna för den funktionen för de inte tänker använda den.

Om du är en av dem, så är du med stor sannolikhet omedvetet sårbar för en effektiv attack mot ditt WiFi, där en angripare lätt kan få tag på din WPA-nyckel (PSK) oavsett hur lång och komplicerad den är.

I detta inlägg, del 1, förklaras kort vad WPS är och varför det är så sårbart, och i del 2 kommer vi att utföra praktiska tester där vi utför attacker mot två WiFi-enheter.

Det har upptäckts ytterligare kritiska sårbarheter i implementationen av WPS i vissa enheter, men vi kikar i huvudsak på den som upptäcktes i slutet av 2011.
 

Översikt WPS

För att sätta upp ett trådlöst nätverk manuellt måste oftast användaren efter att ha kopplat in sin nya router koppla en dator till den via det fysiska nätverket för att kunna logga in i dess administratörswebgränssnitt. Sedan måste han in i inställningarna för det trådlösa nätverket och skriva dit ett SSID (nätverksnamn), välja säkerhetstyp samt en nätverksnyckel. När detta är gjort kan han koppla upp sina trådlösa enheter genom att välja sitt nätverks SSID och skriva in samma nyckel i den aktuella enhetens inställningar.

Detta ansåg Wi-Fi Alliance vara på tok för avancerat för medelanvändaren, så för att förenkla konfiguration av trådlösa nätverk för användare i hem och småföretag presenterade de 2007 lösningen ”Wi-Fi Protected Setup” – WPS, som skulle låta medelanvändaren konfigurera sitt nätverk utan att behöva gå igenom de steg som tidigare var nödvändiga för att sätta upp sitt nätverk, utan i stället låta mycket av detta ske automatiskt. 
För att en WLAN-produkt ska bli certifierad och därmed få använda de skyddade namnen ”Wi-Fi Protected Setup” eller ”WPS” måste produkten följa Wi-Fi Alliance framtagna standard. Det kan förklara att de flesta tillverkare har egna namn på samma funktion som kan sitta i av någon anledning icke ännu certifierade produkter, vilket kan anses till viss del förvirrar och motverkar enkelheten. Exempelvis om vi tittar på de enheter vi tänkte testa kallar ibland Netgear sin funktion för PNC - ”Push 'N' Connect”, och TP-Link kallar sin för QSS - ”Quick Security Setup” och ibland kallar de den båda för WPS.
 

Metoder 

WPS har olika metoder för att ansluta en enhet till en nätverket, varav de vanligaste två (PBC och PIN) förklaras nedan. Accesspunkter måste stöda båda dessa metoder för att bli certifierade.
Det finns även ”out-of-band”-metoder som är något mer ovanliga, där man med hjälp av annan media så som ett usb-minne eller NFC (Near Field Communication) utbyter nyckeln.
  • PBC – PushButton Configuration
    För att automatiskt konfigurera nätverket och ansluta en klient till nätverket trycker användaren på en knapp på accesspunkten och strax därefter på en knapp på klientenheten. Dessa knappar kan vara fysiska alternativt logiska i något användarinterface.Detta förfarande måste ske inom ett intervall på två minuter, vilket kallas ”Walk time”. Accesspunkten ska även logga PBC-ansökningar (knapptryckningar på klienter i närheten) kontinuerligt två minuter bak i tiden (”PBC Monitor time”), och om två olika enheter ansöker om att få koppla upp under [PBC Monitor time] + [Walking time], ska den inte tillåta någon av anslutningarna på grund av ”session overlap”.
  • PIN (internal registrar)
    En PIN-kod bestående av 8 siffror och tillhörande klienten som ska anslutas skrivs in i accesspunktens webgränssnitt. PIN-koden står antingen på en etikett på klienten, eller kan genereras i dess tillämpningsprogram.
  • PIN (external registrar)
    Räknas oftast som samma funktion som ovan, skillnaden är var PIN-koden skrivs in. I detta fall är det accesspunktens PIN-kod bestående av 8 siffror som skrivs in i klientens tillämpningsprogram. Accesspunktens PIN-kod står oftast på baksidan av enheten, och/eller i dess webgränssnitt. Det är denna metod som är sårbar för attacken vi snart ska genomföra, varför vi nedan kommer att koncentrera oss på den.
     

Protokollet

WPS använder sig av Wi-Fi Simple Configuration, vilket innefattar en specifikation på protokollet som används för att skicka meddelanden mellan de olika parterna.
Den första figuren nedan är från (Wi-Fi Alliance, 2006, s. 22) som visar en översikt över vilka meddelanden som skickas mellan parterna. I vårt fall spelar verktyget Reaver som vi ska använda rollen som både ”User” och ”Registrar”, och ”AP” är accesspunkten.
Den andra figuren har en mer detaljerad men ändå överskådlig sammanställning, och är Stefan Viehböcks tabell från (Viehböck, S. (2011-1)) som är enkel att följa och har förklarande text för ändamålet. 
Meddelandeflöde    WPS-Detaljer
 
 
Om man tittar på meddelande M4, så ska ”Registrar” (i vårt fall verktyget Reaver) i detta meddelande till ”Enrollee” (i vårt fall accesspunkten) bevisa att han känner till första halvan av PIN-koden, och i M6 bevisa att han känner till andra halvan. 
I den lilla rutan längst ned syns även hur PIN-koden är uppdelad.
Varför dessa saker är intressanta förklaras nedan.
 

Sårbarheten

I slutet av december 2011 offentliggjordes sårbarhet VU#723755 av cert.org, efter att den rapporterades av Stefan Viehböck. Föga överraskande hade ännu ett team, lett av Craig Heffner, upptäckt samma sårbarhet och dagen efter släppte de sitt verktyg ”Reaver” som kan användas för att utnyttja den i praktiken.
Till att börja med så borde det säga sig självt att WPS kringgår all säkerhet som reglerna för nyckellängd i WPA/WPA2 medför, genom att använda sig av en PIN-kod på exakt 8 siffror för att kunna ansluta sig, jämfört med WPA:s nyckel som kräver minst 8 siffror/bokstäver/specialtecken (skrivbara ASCII-tecken).
För att använda en brute force-attack mot en 8-siffrig sifferkod måste man testa 10^8=100 miljoner kombinationer, vilket jämfört med en 8 tecken lång slumpmässig WPA-nyckel som ger ca 95^8 = ~6,6 biljarder kombinationer är en struntsumma. Dock så blir det ändå opraktiskt i brute force-sammanhang när varje försök mot WPS tar i storleksgraden 1 sekund. Att testa alla 10^8 kombinationer skulle ta ca 32 år, men statistiskt sett är medeltiden tills man hittar rätt nyckel den halva, alltså enbart 16 år.
Det finns dock några svagheter i algoritmen och protokollet för meddelandeutbytena i WPS som förenklar för angriparen och drar ner antalet kombinationer väsentligt:
  • Om WPS-autentiseringen misslyckas vid något tillfälle måste accesspunkten skicka ett EAP-NACK-meddelande för att avbryta sessionen. Eftersom meddelandena ser ut som de gör inser accesspunkten vid mottaget meddelande M4 enligt ovan att de första 4 siffrorna är fel, och skickar sin NACK. Den andra halvan evalueras i senare meddelande. Det gör att angriparen kan gissa på första delen först, och vänta med andra delen. Alla kombinationer som behöver testas för att inse att första 4 siffrorna är rätt är 10^4 = 10 000 st.
  • Sista siffran i PIN-koden är en checksumma som beräknas med känd enkel algoritm på resten av koden, vilket betyder att den andra delen bara består av 3 siffror. Antal kombinationer = 10^3 = 1 000 st.

Antal kombinationer drogs nu drastiskt ned till 10 000 + 1 000 = 11 000 st. Detta gör att en brute force-attack är helt klart genomförbar och realistisk trots långsam onlinegissning. Om man lyckas med att hålla hastigheten 1 gissning per sekund medför det att man kan prova alla kombinationer på ca 3 timmar, och medelgenomförandetiden för en attack blir ca 1½ timme.
 

Reaver - översikt

Reaver är ett verktyg utvecklat av en av upptäckarna av sårbarheten, Craig Heffner, och finns i en open source-version samt en kommersiell hårdvaruversion. Hårdvaruversionen har ett grafiskt gränssnitt, är optimerad i sitt PIN-kodssökande, och kan skicka resultatet till specificerad e-mailadress när den hittat PIN och nätverksnyckel.
Gratisversionen av verktyget är ett kommandoradsprogram och några viktiga argument förklaras nedan. Denna version ingår i Kali Linux, och är den vi kommer att använda.
Verktyget försöker först med kända vanliga default-PIN-koder, och fortsätter därefter gå igenom alla varianter av första halvan av PIN-koden och struntar i att ändra på andra delen (förutom checksumman som måste stämma). När den väl hittat första delen fortsätter den med de tre siffrorna i andra delen tills den slutligen hittar rätt. 
 

Argument

Detta är inte en komplett lista på Reavers alternativ, utan en lista på de vanligaste eller av annan anledning intressanta.
 
Argument Förklaring Exempel Obligatorisk? default
-i Interface
Vilket nätverksgränssnitt som ska användas. (Måste vara i monitor mode.)
-i mon0 Ja  
-b BSSID
AP:ns MAC-adress.
-b 00:11:22:33:44:55 Ja  
-c Channel
Vilken kanal som Reaver ska använda. Något snabbare initiering, men om AP:n byter kanal följer inte Reaver efter.
-c 11 Nej  auto
-e ESSID/SSID
Nätverkets namn
-e Homenetwork Nej (bara om AP:n inte sänder ut sitt SSID) auto
-t Timeout
Timeout för mottagning av meddelanden.
-t 2 Nej 5
-d Delay
Dröjsmål mellan PIN-försök (sekunder).
-d 5 Nej 1
-v
-vv
Verbose
Visa fler statusmeddelanden (-vv=ännu fler).
-vv Nej  
-l Lock delay
Om reaver upptäcker att AP:n låst sig, vänta med att försöka mer i detta antal sekunder.
-l 300 Nej 60
-r X:Y Recurring delay
Efter ett antal (X) PIN-försök, vila ett antal (Y) sekunder.
-r 10:15 Nej  
-x Fail wait
Om samma fel sker 10 försök i rad, vila i detta antal sekunder.
-x 360 Nej 0
-S
Small Diffie-Hellman keys
Använd små dh-nycklar för att AP:n ska få jobba mindre och därmed snabba upp processen.
-S Nej  
-h Help. -h Nej  

 

Våra attackmål

De enheter vi använder som testobjekt är något äldre, men det är något oväsentligt då det dels faktiskt fortfarande finns många som använder dessa modeller eller motsvarande, samt att sårbarheten till stor del består av själva implementationen av funktionen som fortfarande har samma standard, även om många tillverkare på nyare modeller börjat implementera bättre skydd såsom låsning vid för många misslyckade PIN-kodsförsök etc.
 

TP-link

Den första enheten som är tänkt som mål för attacken är en TP-Link TD-W8951ND, och är ett ADSL-modem med inbyggd router/switch samt WLAN-accesspunkt. Denna produkt kan fortfarande, trots åldern, medfölja vid tecknande av nytt bredbandsabbonemang.
Denna produkt är WiFi-certifierad i november 2010, men själva WPS-funktionen verkar inte ha klarat testerna, så detta modem är inte WPS-certifierad. Den WPS-liknande funktionen heter därmed i denna produkt QSS istället för WPS. 
På framsidan sitter knappen för PBC-anslutningar och PIN-koden står på en etikett på undersidan (se bild) så väl som i inställningarna för det trådlösa nätverket i webgränssnittet (se bild).
PIN-koden är 67495740 som ni kan se på bilderna nedan (klicka för att förstora).
(Normalt avråder vi så klart starkt från att på något sätt blotta sådan känslig information, men i detta fall kommer inte dessa enheter att nånsin användas igen.)
 
Front på TP-linkenheten  PIN-kod på baksidan av TP-linkenheten  Pin-kod i GUI för TP-link
 

Netgear

Den andra modellen är en router/switch med inbyggt WLAN och heter Netgear WNR2000. Den har några år på nacken och blev (senast) WPS-certifierad 1 augusti 2008
Även denna modell har sin PCB-knapp på framsidan, men till skillnad från TP-linkmodemet kan den alltså stoltsera med att skylta knappen med bokstavskombinationen ”WPS”.  
Likt TP-linkmodemet har denna också sin PIN-kod på en etikett på baksidan (se bild), samt i webgränssnittet på sidan för ”Avancerade trådlösa inställningar” (se bild).
WPS är som förval aktiverat i fabriksinställningarna, även i den senaste inbyggda programvaran daterad december 2011. Sårbarheten offentliggjordes senare samma månad, och efter det har ingen ny programvara till denna modell släppts, vilket känns positivt inför testet.
Denna enhets PIN-kod är som synes på bilderna nedan: 55340670.
 
Netgear front  PIN-kod på baksidan av Netgearenhet  PIN-kod i Netgear-GUI
 

Härnäst kommer vi att utföra attacker mot dessa två accesspunkter med hjälp av i huvudsak verktyget Reaver.
 

>>>> Vidare till Del 2 >>>>
 

Referenser

Heffner, C. (2011-2016). Reaver Open Source Project Home
Microsoft. (2006). WCN-Netspec (version 1.1)
Okänd/flera författare. (2011-2016). WPS Vulnerability Database
Wi-Fi Alliance. (2006). Wi-Fi Protected Setup Specification (version 1.0h) 
 
Skribent(er): 
Peder Sparell

RSAC2016 - Lösenfrasknäckning, samt Hackerspårning med hjälp av Sysinternals SysMon

Publicerat: 
2016-03-24

I början av månaden gick RSA Conference USA 2016 av stapeln i San Francisco. Jag och Mikael var där och höll vår presentation angående mitt/vårt arbete med lösenfrasknäckning med hjälp av Markovkedjor. Vi fick bra respons och många frågor efteråt, och det kändes som att åhörarna tyckte det var intressant, nydanande och att de kommer att få inspiration av vår metod för knäckning av långa lösenordsfraser. Åtminstone kommer de nog tänka till lite extra innan de väljer sin nästa lösenordsfras.

Vår session fick dessutom privilegiet att vara en av de tre som presenterades under rubriken "Agenda & Tracks" på förstasidan på konferensens site, dessutom strax jämte keynotetalaren Sean Penn, bara en sån sak… Nu har de precis ersatt både Sean och oss med andra rubriker, men vi fick pryda huvudsidan i ungefär tre veckor, däribland hela den vecka som konferensen pågick.

Mer information om vårt arbete med knäckning av lösenordsfraser kan hittas via referenserna [2] samt [3]. Rapport finns nu även publicerad på International Association For Cryptologic Research [4].

Givetvis fanns även en hel del andra sessioner som var mycket intressanta, och en av dem som jag kände kunde ha stor praktisk nytta i mitt arbete såväl som privat, var en genomgång av Sysinternals-svitens relativt nya tillskott ”SysMon” (1,5 år gammalt, men ny version ute nyligen). Denna sessions titel var “Tracking Hackers on Your Network with Sysinternals Sysmon”, och jag tänkte här försöka återberätta de intressantare delarna med hjälp av egna ord, kommentarer och tester.

Sysinternals

För den som inte känner till Sysinternals [7], så var det ett företag som skapade en mängd praktiska och kraftfulla freeware-systemverktyg för Windows med hjälp av operativsystemets mestadels odokumenterade nativa API, vilket gör att de ofta kan trolla mer med avancerade funktioner i Windows än verktyg som använder de mer officiella API:erna. Företaget är sedan en bra tid tillbaks uppköpt och en del av Microsoft TechNet, men de lyckades vid övertagandet förhandla fram att hela deras svit skulle vara fortsatt gratis och fritt att använda.

SysMon

Ett av de senare verktygen de tagit fram är alltså SysMon [8], och dessutom släpptes en ny version strax innan RSA-konferensen, så huvudutvecklaren Mark Russinovich var där och presenterade verktyget och dess nya features samt gav en del tips om det.

SysMon är i princip det enda verktyget i sviten som behöver installeras, och det körs sedan som en service som startar automatiskt vid varje systemstart, och loggar vissa systemaktiviteter som kan vara typiska vid exempelvis intrång och/eller malware. Dessa loggar skrivs till en egen sökväg i Windows eventlog, och kan vara till god hjälp både för att upptäcka och spåra konstiga processer/malware samt vid forensikarbete efter ett eventuellt intrång eller virusangrepp.

Aktivitetstyper som kan loggas: (alla är inte påslagna i defaultinstallationen)

1 Process Create
Detaljerad information om startade processer, såsom full kommandorad, processens ID och GUID, filens hashvärde (SHA1 som default, men det går att aktivera andra), användare etc.

2 File Creation Time Changed
När en process i efterhand ändrar tiden för skapande av en fil. Utan filtrering kan detta ge många false positives då exempelvis komprimeringsprogram och webbläsare kan ändra denna tidsstämpel för att den ska matcha originalfilens, men det är även ett vanligt sätt för hackare och malware att dölja sina spår.

3 Network Connection
Loggar nya nätverksanslutningar över såväl UDP som TCP. Här sparas bland annat vilken process som initierade anslutningen, vilket protokoll, IP, port som användes hos såväl mottagare som avsändare, samt i förekommande fall dnsnamn och portnamn.

4 Sysmon Service State Change
Loggning vid ändring av körstatus på själva SysMons service. Här kan man alltså se om och när SysMon stängts av eller satts igång.

5 Process Terminated
Processens ID och GUID, samt aktuell tid anges här för en process som avslutats.

6 Driver Loaded
Loggar laddade drivrutiner med information om vilken avbild som använts, dess hashvärde(n), samt om den är signerad och i sådant fall av vem.

7 Image Loaded
Logg över vilka moduler (dll-filer) som laddas av olika processer. Logghändelsen innehåller information om processens ID, GUID samt sökväg till avbild, den laddade modulen och dess hashvärde(n) samt om den är signerad och i sådant fall av vem.
Denna loggning är avstängd i grundinställningarna och bör användas med försiktighet då det även vid vanlig användning skapas väldigt många sådana här event. På 2,5 minuter loggades 480 händelser när jag testade denna funktion. Denna loggning kan vara bäst att använda för att med hjälp av config-filen filtrera på och bevaka någon speciell process eller modul.

8 CreateRemoteThread
Loggar när en process skapar en tråd i en annan process. Detta är vanligt att angripare/malware gör för att exempelvis använda sig av andra processer för att hålla sig dolda eller eskalera sin behörighet. Dock finns det också legitim användning även av denna metod.
Loggar innehåller diverse information om källprocess, målprocess, samt vilken adress i minnet tråden startades på.

9 RawAccessRead
Skapar loggar över direktläsning av diskar/volymer. Detta är vanligt bland malware i försök att kringgå filsystemets normala säkerhetsskydd för filer etc.  

255 Error
Om något fel inträffar i själva SysMon loggas det som en händelse av denna typ.

Sökning av hashvärden i Virustotal

En fils beräknade hashvärde kan ses som ett (i princip) unikt globalt ID för filen. Ett mycket användbart sätt att använda de hashvärden som sparas i SysMons loggar, är att göra en sökning på dem på exempelvis siten virustotal [10], för att få en indikation på om det aktuella programmet är pålitligt eller ej.

Nedan visas ett exempel på en sökning av en process startad av taskeng.exe (som normalt startar schemalagda uppgifter):

I eventet på bilden ser vi en hel del information om den startade processen, såsom användare som startade den, vilken sökväg den startades på, vilken kommandorad den startades med, information om den överordnade processen etc. Enligt denna information i eventet kan man skapa en hypotes om att det antagligen är en schemalagd uppdatering för Flash som startats, men eftersom vi är misstänksamma av oss vill vi bekräfta detta. I eventet hittar vi även hashvärden för processens fil, något av dessa använder vi i nästa steg för att på virustotal.com verifiera filens ursprung, samt om den kan vara skadlig.

SHA1-värdet som är markerat i bilden ovan klistrar man enkelt in på virustotal (fliken "Sök"/"Search") enligt bild nedan:

Just denna fil verkar enligt virustotal rätt ofarlig enligt sökresultatet:

Sökresultat visar att den aktuella filen inte är flaggad som direkt farlig

Man kan även exempelvis se på fliken "File Detail" att filen tillhör Flash Player Update Service, och är signerad av Adobe/Verisign, vilket ytterligare bekräftar vår initiala hypotes.

Filen är signerad av Adobe/Verisign, och tillhör Flash uppdateringstjänst.

Om man nu anser att ett program som Flash är pålitligt och oskadligt (!?), så kan man nu pusta ut och avfärda sin misstänksamhet mot denna processtart.

Installation/konfiguration

Installationen av SysMon sker genom att, efter nedladdning/uppackning, som administratör köra exempelvis kommandot:

sysmon –accepteula –i

Detta installerar SysMon med defaultkonfiguration, vilket innebär att endast SHA1-hashvärden beräknas för de filer som förekommer i loggarna, samt att loggning av nätverksanslutningar (eventID 3) och modulladdning (eventID 7) är avstängda. Med -accepteula slipper man dessutom popuprutan med licensavtalet, vilket vi antagligen sett förut då det är samma för samtliga sysinternalsverktyg.

Det finns ett fåtal ytterligare alternativ man kan sätta antingen direkt vid installationen, eller efteråt med nedanstående kommando.

sysmon –c [alternativ]

med de alternativ man vill ha (om man inte ger ytterligare alternativ visas nuvarande konfig).

Exempel kan vara att man vill att alla stödda typer av hashvärden (sha1, sha256, md5, imphash) skall visas för de filer som förekommer i eventen, vilket fås av kommandot

sysmon –c –h *

för att aktivera loggning av nätverksanslutningar lägger man till –n

för att aktivera loggning av modulladdningar lägger man till –l (med eventuell påföljande lista på målprocesser att övervaka, för att slippa överflödsinformation)

Konfigurationsfil och filtrering

För att ha större kontroll och lättare kunna göra mer avancerade inställningar, speciellt filtrering, är det dock smidigare att först skapa en konfigurationsfil som man sedan laddar genom kommandot

sysmon –c [sökvägtillkonfigfil].xml

Filen skall vara i xml-format, och här ges ett exempel med en del mer eller mindre användbara filter (gjorda mest för illustration), några kopierade från [6].
 

<Sysmon schemaversion="2.01">
 
  <!--Inkludera alla typer av hashvärden-->
  <HashAlgorithms>*</HashAlgorithms>
 
  <EventFiltering>
 
  <!--Logga bara inkommande anslutningar eller till port 443-->
    <NetworkConnect onmatch="include">
      <Initiated condition="is">false</Initiated>
      <DestinationPort condition="is">443</DestinationPort>
    </NetworkConnect >
 
    <!--Logga bara trådinjektioner i lsass eller winlogon-->
    <CreateRemoteThread onmatch="include">
      <TargetImage condition="image">lsass.exe</TargetImage>
      <TargetImage condition="image">winlogon.exe</TargetImage>
    </CreateRemoteThread >
 
    <!--Strunta i att logga start av moduler signerade av Microsoft-->
    <ImageLoad onmatch="exclude">
      <Signature condition="contains">microsoft</Signature>
      <Signature condition="contains">windows</Signature>
    </ImageLoad>
 
    <!--Ignorera filtidsändringar gjorda av chrome och 7zip-->
    <FileCreateTime onmatch="exclude">
      <Image condition="end with">chrome.exe</Image>
      <Image condition="contains">7zip</Image>
    </FileCreateTime>
 
    <!--Stäng av loggning av avslutade processer (för att vi inkluderar ingenting)-->
    <ProcessTerminate onmatch="include" />
 
  </EventFiltering>
</Sysmon>

 

Man kan filtrera på vilka fält man vill i eventen, och villkoren kan vara exempelvis vad fältet ska innehålla, sluta med, vara lika med, vara lägre/högre än m.m.

För att helt sätta på eller stänga av loggning av en händelsetyp, använder man ”exclude” respektive ”include” utan att specificera några filter. Det känns kanske fel att stänga av all loggning genom att skriva ”include”, men det är ju för att listan på händelser man ska inkludera är tom (se sista regeln i exempelfilen ovan).

Konfigurationsfilen är riktigt användbar om man vill sålla bort ointressanta händelser (false positives), eller enbart vill leta efter/övervaka en mycket specifik händelse.

För mer info och detaljer om konfigurationsfiler rekommenderas framför allt Marks slides [6] från RSA-konferensen.

Central loggning/övervakning

Windows eventloggar är inte är särskilt skyddade mot manipulering/radering om nu en angripare väl tagit kontroll över den lokala datorn, så för att skydda loggarna och dessutom för att få en central övervakning/loggning så är det relativt enkelt att integrera med exempelvis Splunk eller Microsoft OMS för att skicka iväg och spara loggarna centralt. Vid en sådan setup kan man bland annat skapa dashboards och larm baserat på informationen från SysMons loggar från samtliga datorer i nätverket, och exempelvis korrelera händelser från olika datorer för att skapa larm etc. Hur man skapar en sådan setup är något beroende av det övervakningsprogram man valt, men det finns länkar och mer info om integrering med Splunk eller OMS i bland annat [6] och [9].

Slutsats

Som de flesta andra i Sysinternals svit, är Sysmon ett verktyg med stor användbarhet för Windowsanvändare/administratörer/säkerhetsspecialister etc.

SysMon är ett intressant verktyg bara att köra lokalt, men det har ännu större potential om man i en företagsmiljö installerar det på samtliga datorer och sätter upp en nätverksspännande övervakning. Då kan dess loggar användas för exempelvis central larmning och dashboards, och vara till oerhörd stor hjälp vid såväl upptäckt som spårning/forensisk utredning vid incidenter som malware eller hackerintrång som spridit sig via nätverket, vilket inte är helt ovanligt för APT exempelvis.

Även om vi säkerhetsfolk brukar gilla ordentlig loggning så kan det ibland gå till överdrift, så lite tid och tanke bör nog läggas på att konstruera en konfigurationsfil som filtrerar bort vissa händelser för att inte överflöda loggutrymmet med ointressanta loggar.

Slutord och rekommendation blir: Installera och testa SysMon, för en vacker dag kommer även du den bäste att råka ut för någon slags incident som detta verktyg kan vara till god hjälp vid.

Referenser/länkar:

[1] – RSA Conference USA 2016, http://www.rsaconference.com/events/us16

[2] – Session: Linguistic Passphrase Cracking, https://www.rsaconference.com/events/us16/agenda/sessions/2396/linguistic-passphrase-cracking

[3] – Post Passwords 2015 - Phraser release on Github (earlier blogpost related to our talk), http://www.simovits.com/blogg/post-passwords-2015-conference-phraser-release-github

[4] – International Association For Cryptologic Research, Report 2016/246 - Linguistic Cracking of Passphrases using Markov Chains, https://eprint.iacr.org/2016/246

[5] – Session: Tracking Hackers on Your Network with Sysinternals Sysmon, https://www.rsaconference.com/events/us16/agenda/sessions/2461/tracking-hackers-on-your-network-with-sysinternals

[6] – Slides: Tracking Hackers on Your Network with Sysinternals Sysmon, https://www.rsaconference.com/writable/presentations/file_upload/hta-w05-tracking_hackers_on_your_network_with_sysinternals_sysmon.pdf

[7] – Sysinternals website, www.sysinternals.com or https://technet.microsoft.com/sysinternals/

[8] – SysMon info & download, https://technet.microsoft.com/sysinternals/sysmon

[9] – SysMon/Splunk integration, http://blogs.splunk.com/2014/11/24/monitoring-network-traffic-with-sysmon-and-splunk/

[10] – Virustotal search, https://www.virustotal.com

Skribent(er): 
Peder Sparell

Nätverkshacking Del 2: WiFi Honeypot

Publicerat: 
2016-02-05 11:45

Den första delen av Nätverkshacking-serien handlade om arp-spoofing, men nu är det dags att gå mot modernare tider och undersöka närmare vad man kan göra med trådlösa nätverk.

Vi börjar med att sätta upp en WiFi honeypot som ovetande användare kan ansluta sig till. Till detta behövs en laptop (eller vilken dator som helst fungerar egentligen), verktygslådan Aircrack-ng som innehåller en mängd WiFi verktyg och ett externt nätverkskort, ALFA NETWORK AWUS036H som ansluts via USB till datorn. På min laptop har jag dessutom Kali installerat, så de flesta verktyg som behövs för att sätta upp en WiFi honeypot finns redan.

Vi börjar med att konfigurera en DHCP server så att användarna som ansluter sig får en giltig IP-adress. För att sätta upp en DHCP-server kan du behöva du installera paketet isc-dhcp-server <apt-get install isc-dhcp-server>.
Nu när du har en DHCP-server, konfigurera din server för att dela ut IP-adresser, redigera filen /etc/dhcp/dhcpd.conf.

Nästa steg är att sätta upp Alfa-nätverkskortet i monitoreringsläge. Kontrollera först att nätverkskortet känns igen av operativsystemet med <ifconfig> . I mitt fall heter det gränssnittet wlan1, och för att sätta upp det i monitor-läge använder vi airmon-ng <airmon-ng start wlan1>. Detta skapar ett virtuellt gränssnitt som fått namnet wlan1mon.

Men nu har jag Kali 2.0 installerat, och då behöver vi göra några extra steg för att få detta att fungera ordentligt. Om du inte har Kali 2.0 kan du skippa ifconfig och iwconfig kommandona nedan.

…och nu borde monitoreringen på gränssnittet wlan1mon fungera som det ska! Vi kan använda airodump-ng för att se vilka nätverk vi har i närheten. Och för den luriga så kan din Honeypot sen fungera som en Evil Twin (en nod som har samma namn som ett annat nätverk), men det gör vi inte denna gång.
För att skapa en hotspot används ännu ett verktyg i Aircrack-suiten, Airbase-ng och kommandot <airbase-ng -e GratisWiFi -c 9 wlan1mon>. Flaggan –e står för ESSID som jag i detta, kanske något tråkiga exempel, valt att kalla ”GratisWiFi” och –c för vilken kanal som den ska användas, här kanal 9, och wlan1mon är namnet på gränssnittet. Airbase-ng skapar ännu ett nytt gränssnitt, at0, som kan användas för att sniffa trafik. at0 har inte ett IP och vi har inte satt upp att DHCP konfigurationen, vilket vi nu behöver göra med kommandona <ifconfig at0 up 10.0.0.1 netmask 255.255.255.0> och <dhcpd -cf /etc/dhcp/dhcpd.conf at0> som löser detta.

Och – ta da! Nu har vi honeypoten uppe, utan kryptering och helt öppen, och klienter kan fritt ansluta sig till den.

Som ni ser i Wireshark-dumpen på interfacet at0 ovan kan klienten med IP 10.0.0.100 inte surfa någonstans via "Gratis WiFi", utan här ser vi bara DNS frågor eftersom vi inte har konfigurerat den delen att man faktiskt kan surfa, men vem vet – det kanske vi löser nästa gång.
 

Skribent(er): 
Tiina Loukusa Hyttnäs

Nätverkshacking Del 1: ARP spoofing

Publicerat: 
2015-09-11 10:20

Välkommen till Del 1 i Simovits Consultings första bloggserie om nätverkshacking! Hur svårt är det egentligen för en angripare att fånga upp information från cyberrymden? Vilken typ av information kan fångas upp? Finns det anledning att vara orolig? Och hur kan vi skydda oss?

Idag är de flesta nätverk switchade, vilket gör att trafiken skickas ut till rätt port där mottagaren borde befinna sig. Detta till skillnad från hubbar (som i stort sätt är utdöda idag), eftersom hubbar skickade ut trafiken till alla portar. Då var det tillräckligt att vara ansluten till samma hubb för att kunna sniffa all trafik som passerade den. En mycket enkel metod för att fånga trafik är att placera en hubb mellan en switch och internet, men då krävs det att man har möjlighet att ansluta en hubb på det sättet vilket kanske inte är särskilt diskret.

I första delen går på offensiven och demonstrerar en metod för att sniffa trafik på ett trådat nätverk, genom ARP spoofing eller ARP poisoning (eller ARP förgiftning på svenska).

Vad är ARP och hur kan det användas för att sniffa trafik?

ARP, Adress Resolution Protocol, är det protokoll som används för att mappa en MAC adress till en IP adress. När data skickas från en dator till en annan är det IP adresser som används, men för att data faktiskt ska komma fram behöver man den MAC adress som det mottagande nätverkskortet har.

ARP poisoning är en typ av man-in-the-middle attack och går ut på att förgifta enheters IP till MAC mappning. ARP cachen, ”adresslistan”, förgiftas genom att skicka en stor mängd spoofade ARP meddelanden för en eller flera IP adresser. Resultatet blir att all IP till MAC mappning pekar på den MAC-adress som angriparen valt (sin egen).

För att demonstrera hur man kan gå tillväga att utföra en ARP förgiftning använder vi Cain & Abel men ett alternativt verktyg är Ettercap.

Steg för steg - ARP spoofing och ARP poisoning med Cain & Abel

Efter att du har installerat Cain & Abel, börja med att stänga av datorns lokala brandvägg. Det första du gör efter att du startat programmet är att du konfigurerar Cain & Abel för att använda rätt nätverkskort på din dator. Nästa steg är att navigera in på ”Sniffer”-fliken.

cain configure arp spoofing

Starta sniffning och ARP spoofing genom att trycka på de två ikonerna i övre vänstra hörnet. Tryck på plussikonen eller högerklicka sedan i det vita fältet för att välja ett nätverksspann som verktyget ska söka efter MAC-adresser på. Denna lista ger vilka enheter som finns på nätverket som vi sedan kan försöka ARP förgifta.

cain arp poisoning add hosts

Listan börjar nu populeras med IP- och MAC adresser som har fångats upp i det nätverk som sniffningen har utförts mot.

cain host list arp

Nu är det dags att välja vilka enheter som ska ARP förgiftas. Klicka på den nedre ARP fliken och högerklicka i det vita fältet för att välja ”ARP Poisoning Routing”. Här väljer vi mellan vilka noder som vi vill fånga trafik, förslagsvis mellan en router och en eller flera datorer.

cain arp poison routing

Under tiden som giftet sprids kan vi se en mängd ARP meddelanden om vi tittar i Wireshark, och Cain visar ”poisoning”-status på enheterna:

cain arp poisoning

cain wireshark arp poisoning

Sen är det bara att vänta på att informationen rullar in...

Fliken ”Passwords” kan vara en guldgruva. Den här gången har vi inte lyckats få några intressanta lösenord i labbmiljön. Vi har i alla fall ett användarnmamn ”tiinal” och ett lösenord ”Pa55w0rd” som vi fångat upp! Med Wireshark exempelvis kan vi såklart se all trafik som passerar om även det skulle vara av intresse.

cain sniff passwords arp poisoning

Så går man tillväga för att utföra en ARP poisoning för att sniffa trafik på ett switchat nätverk. I nästa del tittar vi närmare på möjligheterna i trådlösa nätverk…

Skribent(er): 
Tiina Loukusa Hyttnäs