Hackad

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 efter vi stängt av QSS.
TP-links inställningar för avstängning av WPS (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

Tänk om opinionsmätningarna var rätt men valresultatet fel?

Publicerat: 
2016-11-11 17:00
Dagen innan presidentvalet i USA utsågs Hillary Clinton som vinnare. Ett annat resultat vore osannolikt enligt mätningarna. Det samma gällde Brexit-omröstningen. Även omröstningen i Colombia avseende fred med FARC-guerillan slog slint. Även i Sverige har opinionsmätningarna visat sig vara felaktiga. I samtliga fall försöker man hitta rimliga förklaringar, som att mätningarna inte är rättvisande, att mätningarna är slappa, att soffliggare får för sig att rösta, arga vita män och så vidare. Det som ingen verkar beröra, eller som man blundar för, är frågan om opinionsmätningarna var rätt men resultatet fel. För min del är det märkligt att mätningar de senaste åren varit så missvisande. 
 
Utan att ha en djupare kunskap om exakt hur IT-systemstöd fungerar i valsammanhang, så måste de lösa en hel del logistiska problem. 
 
1. Hantering av kandidater
2. Hantering av röstlängder 
3. Räkning av röster
 
För små val sker räkningen manuellt, medan för större val så används rösträkningsmaskiner. Logistiken är både komplicerad och måste även hantera en geografisk spridning. Komplexiteten ger utrymme för sårbarheter. För att klara komplexiteten används det alltid någon form av IT-stöd. I vissa fall är systemen tredjepartsprodukter, medan i andra fall har systemen utvecklats själv.
 
En främmande makt som bestämt sig för att påverka ett val kan lägga ner energi och resurser på att påverka valresultat genom att på ett långsiktigt sätt manipulera de IT-system som används i samband med ett val. Genom att få kontroll över rösträkningsmaskiner eller servrar skulle valresultat kunna manipuleras.
 
Frågan är då om hur reell denna risk är? Vi har ett gammalt exempel som visar på att möjligheterna är obegränsade och att risken är stor.
 
Stuxnetviruset tillverkades av USA och Israel och var det första steget i Cyberkrigföring [Kom Zetter]. Attacken riktade in sig mot Siemens SCADA-utrustningar. Stuxnetviruset fungerade i flera lager och spreds från PC till PC. När viruset detekterade att PCn användes för att administrera Siemensenheter aktiverades mer kod, som kontrollerade de SCADA-enheter som PCn kopplades upp till. Stuxnet-viruset kollade om SCADA-enheterna hade specifika serienummer, och om så var fallet injicerade de kod in i SCADA-enheterna. I detta fallet så styrde SCADA-enheterna centrifuger för anrikning av uran, och den kod som injicerades påverkade varvtalet på ett väl uttänkt sätt så att anrikningen saboterades och att centrifugernas livslängd förkortades. På så sätt hejdades Irans kärnvapenprogram, genom att dels sabotera anrikningen samt att dels höja kostnaderna. Koden som injicerades var liten och obetydlig. Stuxnet kom igenom de olika typer av säkerhetskontrollerna genom att tillverkaren av viruset lyckats stjäla certifikat och signera koden som pålitlig. Även efter Stuxnet var iranierna paranoida för varje fel som uppkom. Att veta om det är en logisk bomb eller bara en bug är svår att urskilja. Efter Stuxnet riktades alla blickar mot SCADA-system som det primära målet för cyberkrigföring. Stuxnet var ingen enkel konstruktion och att ta fram Stuxnet innebar utveckling under flera års tid, och utvecklarna var tvungna att testa lösningen på en uppsatt urananrikningsanläggning för att verifiera funktionaliteten [Kim Zetter]. Stuxnet löste dock inte ensamt problemet med Irans kärnvapenprogram, utan kombinerades med lönnmord, attentat och bombanfall. Stuxnet var bara en del i något mycket större.
 
En hackerattack mot ett röstningssystem kan inte ensamt vinna ett val. Det krävs att angriparen också lägger ner resurser på att vara opinionsbildare, att angriparen genomför informations- och desinformationskampanjer, samtidigt som denne ger ekonomiskt stöd för att valkampanjer ska lyckas. 
 
Däremot vill man vinna ett cyber-krig mot demokratier så är det värt att lägga ner energi på att angripa de system som används för rösträkning. Genom att låta ogynnsamma partier, kandidater eller alternativ vinna val eller omröstningar kan man sakta bryta ner ett lands förmåga att fungera. För att säkra demokratin behöver vi se cyberkrigföring i ett vidare perspektiv och verkligen se till att bevisa att våra val och omröstningar är säkra.
 
 
För att läsa mer se:
Bok som beskriver det första cyberkriget och Stuxnet är Kim Zetters – Countdown to Zeroday.
 
I USA används röstmaskiner. Dess säkerhet har ifrågasatts vid flertalet tillfällen. Röstmaskiner används bl.a. i de så kallade swing staterna Pennsylvania, Florida och Virginia.
En bra artikel som ifrågasätter säkerheten i röstmaskinerna hittas på:
 
Hursti hack som genomfördes 2005 visar hur man kan påverka ett val. https://en.wikipedia.org/wiki/Hursti_Hack
 
I Wired Magazine finns en artikel med en annan vinkling på hur val kan påverkas genom hacking.
I
 
Skribent(er): 
Mikael Simovits

Kort om APT ProjectSauron

Publicerat: 
2016-08-16 16:35

Förra veckan gick flera stora anti-virusföretag med information om att en ny APT-plattform identifierats under hösten 2015 som döpts till ProjectSauron av Kaspersky respektive Remsec av Symantec. APTn misstänks ha varit aktivt sedan 2011. Aktivitet har identifierats i bland annat Ryssland, Kina, Iran, Rwanda, Belgien och även en organisation i Sverige har blivit drabbad. Infektionsvektorn är dock inte känd och den har endast setts användas för att angripa Windows-baserade operativsystem.

ProjectSauron är en modulär plattform som används för cyberspionage, där fler moduler laddas ner vid behov. Plattformen gör det möjligt för en angripare att ta kontroll över ett system och röra sig över nätverk. Modulerna kan exempelvis användas för att lyssna på kommandon över nätverk, öppna bakdörrar, spela in knapptryckingar genom keylogger-moduler samt för att stjäla filer. Det finns närmare 50 olika moduler som ProjectSauron kan utnyttna. För att kommunicera utnyttjar ProjectSauron ett flertal vanliga kommunikationsprotokoll, där DNS-protokollet används i stor utsträckning för att exfiltrera data men även för att rapportera ”status”.

Nätverk som är air-gappade kan också bli angripna av ProjectSauron genom en specifik modul. Denna modul gör det möjligt att från ett air-gappat system flytta data till ett system som är anslutet till internet genom förflytta data med flyttbart USB-media. USB-mediat partitioneras på ett sådant sätt att den inte identifieras av operativsystemet korrekt, vilket medför att data från ett isolerat system kan förflyttas obemärkt och därefter exfiltreras från ett internetanslutet systemet.

ProjectSauron har kunnat agera obemärkt under flera år av tack vare flera olika egenskaper. ProjectSauron körs i många fall inte aktivt utan fungerar som en ”sovande-cell” och väntar på nätverkskommandon för att aktiveras, vissa moduler kör även endast i minnet vilket försvårar upptäckt. För kommunikation används vanligt förekommande kommunikationsprotokoll för att exfiltrera data och skicka statusuppdateringar och på så sätt döljer sig den aktiviteten enkelt bland normal nätverkstrafik.
 

Hur kan man skydda sig?
ProjectSauron förändras beroende på mål, så klassiska signaturer är troligen inte användbara. Men både Kaspersky och Symantec har tagit fram ett antal IoC:er (Indicators of Compromise) utifrån de fall de har undersökt för att identifiera ProjectSauron.
https://securelist.com/files/2016/07/The-ProjectSauron-APT_IOCs_KL.pdf
http://www.symantec.com/content/en/us/enterprise/media/security_response...

Skribent(er): 
Tiina Loukusa Hyttnäs

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

En oönskad affär!

Publicerat: 
2015-09-01 15:25
När man tar upp sidan för Ashley Madison, nu nästan två månader senare, så slås man av två saker: Det första är att den fortfarande är uppe, och det andra är att de har en medalj längst ner som hävdar att de fått utmärkelse för pålitlig säkerhet.
 
Av vad som går att förstå av vad som lästs på nätet så hackades Ashley Madison den 10 juli i år av en hackergrupp som kallar sig ”Impact team”. Dumpen från hacket publicerades ca tio dagar senare. Vad som var fascinerande var att dumpen bestod av 10 Gbyte. Den innehöll bland annat följande:
  1. Användarnamn, namn, e-postadresser och lösenordshashar för 33 miljoner konton. Användarprofilerna innehöll även sexuella preferenser eller böjelser samt GPS-koordinater. 
  2. Ca 15000 av användarnas e-postadresser tillhörde amerikanska  myndigheter.
  3. Företagsinterna dokument som bland annat beskrev IT-infrastrukturen för siten.
  4. För en del av kontona fanns delar av  kreditkortsnummer samt hemadresser.
  5. Loggar för användning av tjänsten.
Den 18 och 20 augusti dumpades ytterligare 25 Gbyte data på Internet. Dessa dumpar innehöll enligt utsago intern e-post från Ashley Madison samt källkod till siten.
 
Intressant iakttagelse är dock de sekundära konsekvenser av hacket vilket innebär mycket mer både ur ett integritetsperspektiv, IT-säkerhetsperspektiv och förtroendeperspektiv:
  1. Enligt en kontroll Gizmodo har gjort visade det sig att endast 15000 av de 5 miljoner kvinnliga kontona användes på en regelbunden basis. För varje gång en kvinna kollade sin mailkorg, kollade 13585 män sin mailkorg. 
  2. Användare av siten började utpressas. Enligt France24 så återfanns t.ex. 1200 Saudiska e-postadresser. I Saudiarabien kan otrohet straffas med döden.
  3. Vd:n för företaget avgick. Säkerhet är ju trots allt ledningens ansvar.
  4. Källkoden visar enligt Gizmodo att Ashley Madison använde sig av Fembots dvs programvara som utgav sig vara kvinnlig deltagare (också kallat för engagers).
  5. Kunder kunde betala för att ta bort sitt konto från Ashley Madison. Hacket visade att kontona endast deaktiverades och att data aldrig raderades.
  6. Mer än två självmord misstänks relateras till hacket. 
Listan kan göras längre. Vi har ännu inte tagit upp kostnader av stämningar, utökade kostnader för att säkra nätet samt förlorade intäkter. Man kan  fundera över hur företaget hade gjort sin riskanalys då del lanserade tjänsten. Hacket visar också att konsekvenserna av ett hack kan vara mer långtgående än vad man tidigare har kunnat föreställa sig. Så vad skulle konsekvenserna bli om ni blev hackade och er databas dumpades på nätet? Vi har helt enkelt passerat en gräns där detta numera är en realitet och inte en sannolikhet.
Skribent(er): 
Mikael Simovits