Vulnerability

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

Ransomware - det växande hotet.

Publicerat: 
2015-11-13 11:20

Ransomware är ett av de mest högljudda hoten i dag, risken är liten att du missar att du har blivit drabbad. Det drabbar både privatpersoner och företag hårt genom att göra att filer blir otillgängliga och förblir så såvida du inte betalar den lösensumma som begärs ut. Filer som den krypterar ligger oftast inte bara lokalt, utan de inkluderar exempelvis nätverkshårddiskar som finns mappade så att ännu fler blir drabbade.

Infektion sker oftast genom en av två infektionsvägar; antingen via bilagor i phishingmail och ibland finns det även länkar som skickar användaren till URLer som kör exploit-kits. Ett exploit-kit kan utnyttja brister i olika programvaror som användaren har installerad på datorn för att leverera skadlig kod.

Det första ransomwaret sägs vara upptäckt i Ryssland 2006 som då skapade lösenordsskyddade zip-filer och raderade orginalfilerna. Då fick offret betala 300$ för att kunna låsa upp de lösenordsskyddade filerna. Under en lång period hade ransomware en begränsad spridning, men 2012 började de även dyka upp i Europa. Den första typen av ransomware var ”polis ransomware” som låste användarens dator på något sätt eller krypterade filer som gjorde dem otillgängliga för användaren. En bild visades till användaren där det stod att “polisen” hade “beslagtagit” dina filer för att du hade gjort något olagligt. Den information som visades till användaren var ofta anpassad så att det såg ut som det var den lokala polisorganisationen som krävde lösensumman. I exemplet nedan som ser ut att komma från Polisen kostade det 1000 SEK att låsa upp datorn eller filerna.

Ransomware som utger sig för att vara från Polisen

Sedan under 2013 kom den första versionen av CryptoLocker och därefter har en mängd varianter vuxit fram. Idag dominerar ransomwarefamiljerna TeslaCrypt, CryptoWall, CBT-Locker och Cryptolocker. Symantec rapporterar att ransomware (alla typer, inte bara crypto-ransomware) haft en ökning på 113% från 2013 till 2014. Samtidigt ser 2015 ut att vara året för de nya varianterna av ransomware… Även McAfee förutspår en ökning för 2016 där den nya affärsmodellen ”Ransomware-as-a-service”  fortsätter att växa.

Statistik från McAfee visar en ökning av det totala antalet ransomware.

Redan under de senaste veckorna har det skett några förändringar i ransomware-sfären. Den senaste varianten av CryptoWall v4 skapar nu slumpmässiga filnamn. En annan variant av ransomware, Chimera, hotar med att publicera filerna som den har tagit som gisslan. Och nu är inte heller Linux-användare säkra med Linux.Encoder.1 i det vilda. Som tur är hade den första varianten av Linux-ransomwaret några brister och BitDefender har tagit fram ett verktyg för dekryptering.

Det är inte första missen som utvecklarna av ransomware gör, till exempel så har Kaspersky utvecklat verktyget Rakhni Dekryptor för ransomware som bland annat skapar filändelserna .locked, .oshit, .encrypted på de krypterade filerna. Men man kan inte alltid förlita sig på att det finns ett verktyg som kan dekryptera filerna, cert.se gick ut med en uppmaning med råd hur man kan skydda sig och vad man kan göra om man blir drabbad. Följande är några generella råd som alltid är bra att följa:

  1. Filtrera inkommande e-post, baserat på misstänkta sändare/domäner och bilagor som exempelvis är .exe filer.
  2. Blockera åtkomst till kända webbsidor som sprider skadlig kod, här kan båda din anti-virusprogramvara vara tillhjälp, men för företag som använder andra säkerhetskomponenter kan applicera filter på flera nivåer för att öka skyddet ytterligare.
  3. Svartlista/Vitlista program, exempelvis genom att konfigurera grupp-policies (GPO:er) som förhindrar att vissa program körs på systemet samt varifrån program får köras och vad de tillåts att göra.
  4. Ta backuper, på hela eller delar av disken, och se till att återställning av backuper fungerar.
  5. Se till att uppdatera datorn med de senaste uppdateringarna för programvaror och operativsystem och anti-virusskydd.
  6. Undvika att vara inloggad med lokala administratörsrättigheter
  7. Begränsa behörigheter på nätverksdiskar

Vad kan vi vänta oss härnäst då? Vad händer om Ransomware börjar plantera exekverbara filer med skadlig kod på filytor som delas med andra användare? Ja, det skulle säkert leda till en ökad spridning. McAfee förutspår en ökning av ”RaaS” och ransomware som inte gör så mycket väsen av sig, utan krypterar i det tysta. Det skulle kunna medföra att krypterade filer även hamnar i backuper som tas regelbundet, och då kan man inte längre förlita sig på att kunna använda sig av backuper för att återskapa filer.

Och förresten… Var extra försiktiga på fredagar, då är det tydligen är den dag i veckan som flest malware sprids!

Skribent(er): 
Tiina Loukusa Hyttnäs

Peter Recenserar: OWASP ZAP sårbarhetsskanner

Publicerat: 
2015-10-02 09:52

Många av er som sysslar med IT-säkerhet har nog vid ett eller annat tillfälle hört talas om organisationen OWASP. Vad så många inte vet är att OWASP själva står bakom ett sårbarhetsskanningsverktyg. Närmare bestämt ZAP eller Zed Attack Proxy.
OWASP själva beskriver verktyget som ett lättanvänt verktyg för penetrationstestare och annat säkerhetsintresserat folk som är gratis och har fler funktioner än din vardagliga sårbarhetsskanner. Låter detta för bra för att vara sant? I denna recension undersöker vi närmare den chockerande sanningen om ZAP.

ZAP finns gratis att hämta på OWASPs hemsida och finns tillgängligt för både Windows och Linux. ZAP är skrivet i Java och kräver därför att du har Java installerat innan du kan starta upp programmet.
När du först startar upp ZAP möts du av välkomstskärmen där du har valet att antigen göra en sårbarhetsskanning på en URL eller installera det tillhörande plug-and-hack tillägget och via din webbläsare exekvera skanningar och andra tester direkt på ditt mål.
Likt många andra sårbarhetsskannrar konfigurerar du först en policy som anger vilka inställningar och funktioner som ska användas i skanningen. Därefter är det bara att välja mål och din policy och börja skanna.
ZAP har även stöd för egenskrivna scripts som kan användas för att utöka eller förbättra funktioner.
Dessa skrivs i valfritt programmeringsspråk som stöds av JSR 233,vilket bland annat är C, Python, PERL och JavaScript.

Nedan väljer vi att attackera en instans av WebGoat (Också från OWASP) som är en plattform avsedd att simulera en webserver med sårbarheter och som används i testsyfte.
Målets IP-adress skrivs in i adress-fältet och skanningen initieras därefter genom att trycka på go. Därefter är det bara att invänta resultatet. Medan vi väntar kan vi i realtid se vad ZAP utför för tester och vilka resultat de ger.

På välkomstskärmen kan du enkelt välja att skanna en enstaka sida genom att skriva in en URL i adressfältet.

Vid en standard-skanning börjar ZAP med att ”spindla” igenom målet och därmed upptäcka alla underkategorier på hemsidan. Därefter påbörjas själva skanningen av sårbarheter. Vanligtvis tar det ungefär lika lång tid för ZAP att skanna igenom en hemsida som för Acunetix, vilket är den sårbarhetsskanner vi vanligtvis använder för webapplikationer.
När skanningen är avslutad får vi en summering av alla påträffade sårbarheter. Vi kan sen välja att exportera dessa som antigen en HTML eller XML-fil.

Plugga och hacka
Den andra delen av ZAPs sårbarhetsskanner är i form av plug-n-hack tillägget. Denna funktion fungerar som ett utskott av själva sårbarhetsskannern och tillåter en användare att exekvera samma funktioner direkt i webbläsaren. Detta kan vara användbart när du enbart vill rikta tester mot en specifik funktion på en hemsida eller behöver mer kontroll över vad som testas under skanningen.

Och det övriga
ZAP står ut från andra sårbarhetsskannrar med sitt stora urval av funktioner. Eftersom denna recension främst fokuserar på sårbarhetsskannern kommer vi inte göra någon djupdykning i dessa funktioner, dock är det värt att nämna att ZAP kommer med funktioner så som en fuzzer, en proxy för att fånga in efterfrågningar från en hemsida och websockets.

ZAP vs Acunetix
I slutändan är det viktigaste med en sårbarhetsskanner hur pass riktigt resultatet är. Eftersom sårbarheterna i WebGoat är dokumenterade så kan vi undersöka vilken av de två tillgängliga sårbarhetsskannrarna som bäst återger korrekta sårbarheter. I detta fall har både Acunetix och ZAP körts mot WebGoat med standard-inställningar och standard policyer.
Resultatet var näst intill identiskt och både verktygen hade hittat alla dokumenterade sårbarheter på dem sidorna som var åtkomliga. Det bör dock noteras att i det i andra tester där ZAP körts mot fler miljöer visats att nyare sårbarheter inte plockas upp av skannern. Detta beror på att sårbarhetsdatabasen inte uppdateras lika frekvent som de kommersiella sårbarhetsskannrarnas databas.

Den chockerande sanningen
Sanningen är att ZAP är ett riktigt bra verktyg. Personerna som har arbetat med ZAP har lyckats med att ta fram ett gratis open-source verktyg som både är hyfsat lättanvänt och ger bra resultat. Det finns fortfarande utrymme för förbättringar b.la i hur gränssnittet ser ut och hur plug-n-hack tillägget fungerar. Jag ser dock att ZAP är på väg mot en ljus framtid då communityn bakom verktyget ständigt arbetar på att förbättra och expandera verktyget.

Det bra

Det dåliga

  • Open source och gratis
  • Sårbarhetsskannern är lättanvänd.
  • Flertal inbyggda funktioner.
  • Finns massvis med gratis tillägg.

 

  • Genererade skanningsrapporter är dåligt strukturerade.
  • Plug-n-hack tillägget är struligt att få igång.
  • Sårbarhetsdatabasen uppdateras inte så frekvent.

 

Slutbetyget för ZAP blir 3,5 av 5 krypterade kameler

 

Skribent(er): 
Peter Hildeblom