Simovits

WPS – Weakly Protected Setup? – Del 2

Denna blogginläggsserie på två delar, skriven av Peder Sparell, 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.

<<<<< Tillbaka till Del 1 <<<<<

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.

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.

  

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

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.

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.

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.

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.

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:

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.

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 efter vi stängt 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.

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.

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.

Ä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.

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!

Publicerat 2016-12-30 Skrivet av Simovits Consulting