Bloggtoppen hackat: party like it's 2008
Våren 2008 saknar egentligen fortfarande motstycke gällande läckta lösenord: Efterfesten och Bilddagboken samt ett par andra mindre siter trillade dit i en våg av intrång från nyår och framåt. (Sök på "efterfesten hackat" eller motsvarande.) Sammantaget handlade det om ett par hundra tusen lösenord som var svagt skyddade. Fest utbröt på Flashback och Fragbite, många mail- och Facebook-konton (med samma lösenord) fick lida i efterdyningarna.
Nu har sidan Bloggtoppen har blivit av med mellan 50 och 90 000 vanilj-MD5-hashade lösenord. Det har under dagen rapporterats i mainstream-media, t o m på TV och radio. Dock inte för att det rör sig om många lösenord eller för att hasharna, även den här gången, var värdelösa. Nej, förmodligen bara för att några av dem twittrades på en politikers kapade konto. Jaja...
Anmärkningsvärt nog var det ganska precis en månad sedan som läckan skedde och det var inte heller i "undergroundkretsar" utan det var mitt på ljusa dagen på ni-vet-vilket-forum. SQL injection, förstås. Än mer anmärkningsvärt är att SVT ger en väldigt... öppensinnig(?) rapportering i artikeln Kolla om du finns med i Bloggtoppen-läckan. De länkar till databasdumpen och berättar (i princip) hur man gör för att knäcka MD5-hashar. Enligt SVT kunde de enkelt knäcka 80 % av lösenorden m h a en vanlig rainbow-site.
Säker lagring av lösenord
"Hur ska man hasha lösenord?" är det nog många söker på (SEO FTW) så vi tar det kort. Svaret är egentligen förvillande enkelt men jag utvecklar det lite här för sakens skull (något ska man ju ha att göra på tisdagkvällar). Låt mig citera vad en av mina favoritböcker, Security Engineering, säger om hashfunktioner på sidan 141:
The first main property of a random function is one-wayness. [...] A second property of pseudorandom functions is that the output will not give any information at all about even part of the input. [...] A third property of pseudorandom functions with sufficiently long outputs is that it is hard to find collisions.
Det är egentligen bara den första som är intressant i fallet med lösenordslagring. Det ska vara svårt att gå från h(x) till x där h(x) är hashen av lösenordet x. Vetskap om hash ska inte innebära vetskap om lösenord.
Enligt databasdumpen från Bloggtoppen var det någon anställd på Aftonbladet som hade lösenordet "tejp" och Bloggtoppen använde hashfunktionen MD5. Alltså:
MD5(tejp) = 24b5c8dc3ae3aa06240d463dd681d8ab
Problemet är att det inte är svårt att gå från lösenordshashen "24b5c8dc3ae3aa06240d463dd681d8ab" till lösenordet "tejp". Det är lätt. Den huvudsakliga anledningen till detta är att lösenordet är svagt; "tejp" är, som bekant, inte ett särskilt starkt lösenord.
Problemet är att även lösenord som "jonathan28" kan knäckas relativt enkelt och det är ju inte lika väntat. Det är ju trots allt tio tecken långt och inte helt värdelöst. Nu skulle jag inte längre hävda att det huvudsakligen är lösenordets fel att det knäcktes, det är hashfunktionen, MD5:s fel. I klartext, beräkningarna som en dator måste göra för att beräkna h(x) från x är för få vilket innebär att man kan gissa lösenord för snabbt. För MD5 är sex miljoner lösenordsgissningar i sekunden inga konstigheter för en vanlig, gammal laptop som min med vanlig COTS-programvara som Cain. Med den bakgrunden är det klart att Jonathan får problem.
Således, det måste krävas fler beräkningar för att beräkna h(x) från x, fler beräkningar för att gissa ett lösenord, helt enkelt.
En "hashfunktion" som har denna egenskap är PBKDF2 eller Password-based key derivation function 2 som egentligen används för att göra en kryptonyckel av ett lösenord. Förutom denna egenskap (tekniken bakom heter key stretching) som teoretiskt kan tvinga ner en angripare i ett par hundra gissningar i sekunden har den även key salting som inför ytterligare en önskvärd egenskap i lösenordshasharna: att samma lösenord aldrig hashas likadant varje gång. Jag har inte gått in på det här ovan men saltet hindrar de där sex miljonerna gissningar per sekund från att bli många miljoner fler med hjälp av en time-memory tradeoff-princip (sök på "rainbow tables").
Så, använd PBKDF2 för att hasha dina användares lösenord. Om du samtidigt tvingar användare att välja relativt starka lösenord skulle du, åtminstone i teorin, inte behöva oroa dig ifall en databasdump kommer på vift. Och varför skulle man annars ödsla tid med att hasha lösenorden från första början?
--
Stefan Pettersson
RSA var nog inte ensamma
Alla stora, svenska ISP:er är representerade. Det betyder, som Brian säger, inte att de har hackats, snarare att deras kunder har det. Kunder som får antas vara svenska.
Oklart vad det här betyder just nu, spontant känns det osannolikt att det inte har kommit ut tidigare så viss skepsis är befogad. Om det är sant kan det ta hus i h-e när det rullas upp.
--
Stefan Pettersson
Förenklad eller förfinad riskanalys
I ett två år gammalt inlägg, när jag första gången skrev om att mäta säkerhet, var jag inne på att något så komplext som säkerhet borde kunna beskrivas genom att bryta ner det i flera, enkla faktorer:
Om vi kan bryta ner en tänkt, komplicerad mätenhet i flera, enkla enheter som genom någon relation till varandra motsvarar den komplexa borde det underlätta. Det är lätt att se hur felbedömningar är ovanligare om mätvärdet är simpelt och väldefinierat, kanske till och med diskret. Ju fler enkla mätvärden som kombineras desto mer exakt blir i sin tur kompositvärdet.
Ett exempel på det här var common vulnerability scoring system (CVSS). Nu har det kommit a new kid on the block, nämligen binary risk analysis (BAR), framtagen av Ben Sapiro. I BAR bedöms en säkerhetsrisk genom att svara ja eller nej på tio frågor, utifrån detta klassas den sedan som låg, medel eller hög.
Binary risk analysis har tagit idén från (bl a) CVSS men förenklat den ytterligare (färre faktorer, färre svarsalternativ), bytt vulnerability mot risk och använder inga tekniska begrepp, förmodligen för att locka en annan, bredare publik. När det kommer till kritan har dock både CVSS och BAR i princip samma syfte: hur mycket behöver jag oroa mig för x? Att den ena i princip bara används av sårbarhetsscanners och den andra är tänkt att användas av "riskanalytiker" är bara semantik. Båda kretsar kring chansen för x och effekten av x.
Samtidigt som BAR kan ses som en förenkling av vad riskanalyser borde vara tror jag att det i stor utsträckning snarare är en förfining av gängse metoder. Det är definitivt inte ovanligt att riskanalyser där man (som vanligt) definierar risk som
RISK = KONSEKVENS × SANNOLIKHET
egentligen resulterar i risker som är produkten av en UPPSKATTNING och en GISSNING. Knappast hjälpsamt och något vi måste ta död på snart innan vi slösar mer pengar på det.
Vad BAR huvudsakligen bidrar med är att strukturera faktorer som SANNOLIKHET och KONSEKVENS består av. N.B. att det fortfarande är uppskattningar och gissningar men de är lättare att få rätt och ett fel påverkar inte svaret i lika stor utsträckning.
Om du inte har råd att låta en kompetent, analytisk person med bred erfarenhet av säkerhetsproblem bedöma vilka problem som är värda att oroa sig över. Då är BAR ett snabbt och enkelt sätt att få lite fason på säkerhetsriskbedömningarna.
De frågor som CVSS, BAR och liknande metoder bygger på är ju trots allt precis sådana frågor som en säkerhetsspecialist implicit ställer sig, viktar och svarar på när hon gör en bedömning. Automagiskt och kanske omedvetet. Skillnaden är att specialisten är... specialist: har fler frågor, fler svar, är bättre på att göra bedömningar, har erfarenhet och är ajour.
BAR är en bra men trubbig metod. Trubbigheten kan dock utgöra en del av värdet: faktumet att man kanske orkar använda det konsekvent istället för att bara multiplicera uppskattningar med gissningar.
Ett problem med säkerhetsbedömningar som BAR inte löser och kanske t o m förvärrar är att man måste uppfinna hjulet varje gång. Även om två situationer sällan är identiska är det bra att ha något att gå tillbaka till för att se hur man har bedömt liknande situationer tidigare. En kunskapsdatabas. BAR marknadsförs som ett verktyg där säkerhetsrisker kan värderas lite snabbt på stående fot vilket knappast borgar för extensiv dokumentation.
Jag kommer att få anledning att återkomma till en sådan kunskapsdatabas.
Så för att knyta ihop mina åsikter: (1) BAR skulle definitivt innebära en förbättring för många riskanalyser även om (2) det är trubbigt. (3) För att få kontinuitet över tiden krävs rutiner utöver detta som gör att analyserna inte blir så snabba och lätta som man skulle önska. Dessutom sitter man fortfarande där med (4) konsekvensproblemet p g a att attackträd ofta får många grenar.
Trevlig helg!
...läs förresten CJ:s kritik mot MSB:s vägledning för smarta telefoner som publicerades igår.
--
Stefan Pettersson
20 Critical Controls & Security 101
Jag gillar dock innehållet av den enkla anledningen att det ligger i linje med ordning, reda, disciplin och så vidare.
Det hör inte till medvetenhetsmånaden men den 3 oktober publicerade Tom Liston ett inlägg: Security 101: Security Basics in 140 characters or less som jag tycker är fantastisk. Han bad folk ge grundläggande säkerhetsråd via Twitter och samlade dem i bloggen. Mina favoriter:
@Keldr1n Know your network - and all devices in it - well enough to spot unusual activity.
@connellyuni It's more important to know what you don't know than it is to know what you do know.
@cutaway Monitor and alert to new accounts and accounts being added to Domain Administrator, SUDO, or root groups.
@cutaway Service accounts should adhere to corporate password policies and be monitored for modifications including lockout.
@tliston If you're not putting as much thought into your outbound firewall rules as you are for your inbound rules, you're doing it wrong.
@tliston If you've never tested restoring from your backups, then you don't have backups - you have a crapload of data and hope.
@tliston Run scans against your network. It's the only way to really know what's out there. I've yet to see a fully accurate network diagram.
@tliston Centralize your logging - you have no idea how helpful it will be.
@tliston If it plugs into your network, know why. The last thing you ever want to hear an admin say is, "That thing has a web interface?!?"
@tliston Shared accounts are never a good idea.
...men vinnaren är:
@cutaway Assets using secure authentication are directly and adversely impacted by your assets using plain text authentication.
Det ryms så mycket i den. Säkerheten i enskilda system ska inte betraktas i isolation. De höga lösenordskraven i extranet-systemet betyder ingenting om ett lösenord för inloggning ligger och skräpar i någons inbox i en fil på en borttappad dator eller på en webbmail med sårbarheter:
--
Stefan Pettersson
