IT-säkerhet enligt HPS

Det är lätt att slänga sig med begreppet best practice. Vi konsulter, misstänker jag, gör det i synnerhet. Kanske borde vi i själva verket tala om good practice, okay practice eller t o m not bad practice istället.

För har vi någon vidare bra uppfattning egentligen?

Under julledigheten hann jag beta av några centimeter från att-läsa-högen™. Bland dessa centimeter fanns Jay Jacobs korta essä A Call to Arms: It Is Time to Learn Like Experts (pdf) och forskningsrapporten The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis (pdf) av Yinqian Zhang et al.

Den tidigare problematiserar vår benägenhet att ge rekommendationer baserat på magkänsla och antaganden, min fetstil:

Businesses and organizations rely almost exclusively on the opinions of security experts for direction and priority of risk-based resource allocation. This reliance on the subjective experience of experts begs the question, "Under what conditions are the opinions of security professionals worthy of trust?" This complicated question has a relatively simple answer: unvalidated expert judgment is not a reliable foundation for making risk-based information security decisions.

Har vi hört det där förut eller... Vanligtvis fortsätter författaren med något utspel i stil med "vi måste börja mäta säkerheten..." eller "vi måste göra riskanalyser där sannolikheten och konsekvensen bedöms..."  o s v "annars kan vi aldrig nå framgång". Blah blah...

Men, inte den här gången! Jacobs går in på forskning om i vilka sorters miljöer det finns goda och dåliga förutsättningar för att öva upp sin intuition (läs: magkänsla). Bra och dåliga förutsättningar kallas för kind respektive wicked environments. Förklaringen Jacobs ger är så klar att jag bara citerar, min fetstil:

A kind environment will offer unambiguous, timely, and accurate feedback. For example, most sports are a kind environment. When a tennis ball is struck, the feedback on performance is immediate and unambiguous. If the ball hits the net, it was aimed too low, etc. When the golf ball hooks off into the woods, the performance feedback to the golfer is obvious and immediate.

Jacobs observation är att informationssäkerhet utgör en elak miljö, min fetstil:

[In wicked environments] we see feedback that is not timely, extremely ambiguous, and often misperceived or inaccurate. Years may pass between an information security decision and any evidence that the decision was poor. When information security does fail, proper attribution to the decision(s) is unlikely, and the correct lessons may not be learned.

Jag har svårt att komma med några invändningar. Ett förslag på att mildra problemet är en form av feedbackloop, varje gång du är på väg att ge en rekommendation baserat på magkänsla eller antagande, ställ dig själv två frågor:

1. Varför tror jag det?
2. Hur skulle jag få reda på att jag har fel?

Läs essän i sin helhet, den hänvisar till källor som förtjänar tid.

I princip alla källor till best practice inom säkerhet har alltid sagt att lösenord ska bytas ut med jämna mellanrum. Varför tror vi det? Hur får vi reda på om vi har fel?

Det här tar oss till forskarrapporten jag nämnde i början; The Security of Modern Password Expiration. Rapporten är av någon outgrundlig anledning en orgie i matematisk notation.

Kortfattat har forskarna, med hjälp av lösenordshistorik från 7700 riktiga användarkonton, konstaterat att det är betydligt enklare att gissa det nuvarande lösenordet om man vet ett föregående. Naturligtvis beror det på att användare inte väljer helt nya lösenord utan bara modifierar det en aning vid varje byte.

Syftet med regelbundna lösenordsbyten är ju att begränsa tiden under vilket ett läckt lösenord är värdefullt. Om en angripare får tag i ditt lösenord nu är tanken att det bara ska vara användbart fram till nästa lösenordsbyte om några månader. (Visst låter det skakigt när man uttrycker sig så?)

Nåväl, rapporten visar alltså tecken på att effekten av lösenordsbyten i praktiken inte är så stor som man kanske hoppats. Detta kombinerat med att regelbundna lösenordsbyten är en kunglig smärta i bakdelen generellt gör att man gärna ställer sig frågan: är det värt det?

Nej. Gör det (1) svårt för användare att välja svaga lösenord och (2) besvärligt för angripare att gissa lösenord. Det är en mycket bättre väg framåt...

...varför tror jag det? Hur vet jag om jag har fel?

Trevlig helg förresten!

--
Stefan Pettersson

Aftonbladet har just nu en omröstning i samband med en misstänkt bugg som sprider skräck. Frågan som ställs är "Vågar du skicka privata meddelande på Facebook?" (sic). Efter fyra och en halv timmes röstande var tre fjärdedelar av de nästan sju tusen röstberättigade rörande överens om att svaret var nej, absolut inte.

Det behöver väl knappast tilläggas att det inte är ett särskilt bra underlag... Aftonbladetläsare som precis har fått reda på att en "allvarlig bugg sprider skräck", att det "kan innebära skilsmässor", att det är "fruktansvärt" och är "en otrolig förtroendekris för Facebook" kan inte förväntas ge sin uppriktiga bedömning.

Likväl. Om 75 % fullständigt saknar förtroende för Facebook; ett företag som aktivt försöker förbättra sin säkerhet och är öppen med det och har åtta annonser ute efter säkerhetsfolk, då blir man mörkrädd över vad förtroendet är för godtycklig tidning, myndighet, bank eller företag... som i regel inte är i närheten.

Uppdatering @ 2012-01-11: Omröstningen har planat ut nu (16 000 röstande) men fördelningen är densamma. Vi saknar fullständigt förtroende för ett företag som har ett långt större engagemang för säkerhet än den stora majoriteten företag vi vanligtvis kommer i kontakt med.

--
Stefan Pettersson

Gott nytt år och god fortsättning. Hoppas att nyårsfirandet inte resulterade i förlorade ögonbryn (eller värre) på grund av felkonstruerade fyrverkerier. Förhoppningsvis så tillämpar de flesta defense in depth och ser till att inte hålla nunan ovanför pjäsen trots säkerhetsfunktionen med fördröjd avfyrning (stubintråd)...

Själv var jag i London under helgen för firande, kunde dock inte låta bli att lägga märke till lite vardags- eller "populärsäkerhet" som jag gillar att kalla det.

POPULÄRSÄKERHET pop⁴ ω lä⁴r ~sä ³ker ~he ²t, sbst., r. l. f.; best. -en, (sälls.) pl. -er

1) säkerhetsfunktioner l. -detaljer l. -rutiner o. dyl. som finns i människors vardag; sällan anmärkningsvärda, uppfattas ofta inte alls; äv. vardagssäkerhet; t. ex. endast vänsterskor i skobutik, vinflaska öppnas framför gäst på restaurang. jfr. SÄKER, SÄKERHET, POPULÄRVETENSKAP m. fl.

Under en promenad på nyårsafton runtomkring Trafalgar Square där många samlas för att se fyrverkerierna vid London Eye (pariserhjulet) såg vi skyltar på olika stolpar. Här på ett rödlyse t ex, "beware anti-climb paint":

Jag har ju ingen personlig erfarenhet av det här men tydligen är det svårt att se fyrverkerier från torg om man är kort. Detta kombinerat med ett gäng öl gör att folk klättrar upp i stolpar, ramlar ner och gör sig illa. Hur ska du hindra dem? Ett alternativ är förstås att hyra in "stolpvakter" som försöker stoppa folk från stolpklätteri, ett annat är att plocka ner stolparna. Båda låter både dyra och omständliga. (Vid närmare eftertanke vore det dessutom en ganska dum idé att plocka ner rödlysen...) Ytterligare ett alternativ är att linda in dem med taggtråd, förmodligen kommer de dock att klippas av med en enklare avbitartång, dessutom kan folk göra sig mer illa.

London har tydligen valt att måla stolpen från två meters höjd och uppåt med någon tjärliknande färg som smetar av sig när man rör vid den. Kanske är den vattenlöslig också så att problemet löser sig (no pun intended) själv efter några dagars regn.

Det här fick jag aldrig en bild på men på tal om stolpar; lyktstolpar, elskåp och andra släta ytor i vissa kvarter var täckta vad som såg ut som svart spackel. Ytan var som väldigt grov och hård strukturtapet. Här var anledningen knappast att avskräcka aspirerande fasadklättrare, ytan gav snarare bättre grepp. Efter ett tag slog det mig att det måste vara för att slippa en stadsmiljö täckt med politiska klistermärken. Ni vet vilka jag menar, de "väderbeständiga" med "permanent klister"...

Ett annat exempel kommer från de finare kvarteren,  en av Rolexbutikerna har inga klockor framme när det är stängt. På så vis kan man ha stora, fina fönster trots värdet på klockorna. Två saker att notera dock: (1) detta skvallrar om att det är äkta klockor som ligger i fönstrena och (2) istället kan rånrisken öka...

Givetvis stoltserar London också med den lite mera konventionella varianten av säkerhet. Utsikten nedan gör förstås att man känner sig väldigt välkommen till slottsträdgården bakom Buckingham Palace. London har verkligen sinnesjukt många kameror ute på gatorna.

Men, om inget annat fungerar kan man ju alltid tillämpa ekonomiska styrmedel. Det är tydligt att London verkligen inte vill att man matar duvorna, överträdelse beivras och ger £500 i böter (vilket är tjugo gånger högre än vad det kostar att åka dit för plankning i samma stad).

Får jag passa på att påminna om bloggens nya RSS-feed? Den gamla plockas snart ner så se till att uppdatera eventuell RSS-läsare.

--
Stefan Pettersson

Kort uppföljning på förra posten om att bl a klättra över glasspärrarna. Det var ju inte riktigt läge att dokumentera attacken när den genomfördes, stämningen hade nog blivit obehaglig. Som tur är har jag studerat CISSP-kapitlet om forensics mycket noggrant och kan nu presentera exhibit A nedan. Det ser ut som att metoden inte är helt ovanlig.

 

--

Stefan Pettersson

Jag är ju rätt förtjust i SL:s arbete med att skydda mot plankare, har skrivit om spärrarna generellt, om SMS-biljetter och lite annat.

Stod och väntade på fästmön i tunnelbanan i veckan (de har nyligen satt upp glasdörrar där) och såg då två framgångsrikt genomförda "attacker":

Först kom en liten kille, bedömt 150 cm, klättrar upp på plåten mellan ingångarna och gränslar, med viss möda och anträngt ansiktsuttryck (hans ben var marginellt kortare än glaset var högt), glaset och hoppar ner på andra sidan. Inte så märkvärdigt.

Minuter senare kommer en postpubertal herre med mobiltelefon i örat, stannar upp när han inser att det är glasspärrar, säger något i telefonen och går bort till spärrvakten. "Hörru, öppna spärren", spärrvakten tittar upp från sin bok och ser förvånat på gossen. Gossen ifråga pekar hotfullt mot rutan, "Öppna. Spärren!". Spärrvakten rycker på axlarna och glasdörrarna far upp. Gosse återupptar samtalet i mobilen på vägen bort mot perrongen.

Det anmärkningsvärda här är inte att glasspärrarna inte fungerade. De fyllde faktiskt sin funktion strax innan mobiltelefonkillen dök upp när ett litet gäng efter en stunds förvånade blickar mot glasdörrarna plockade upp sina telefoner och beställde (eventuellt legitima) SMS-biljetter.

Det anmärkningsvärda är att de svårpasserade dörrarna ledde till att spärrvakten hamnade i en obehaglig situation.

Det här är ett vanligt fenomen när nya säkerhetsfunktioner införs, det klassiska exemplet är bilar som har blivit så svåra att stjäla när de är parkerade att de istället stjäls under vapenhot när föraren sitter i bilen. Det är inte orimligt att lägenhetsdörrar av plåt med flera låskolvar och ram i plåt leder till lägenhetsrån istället för lägenhetsinbrott.

Angripare följer minsta motståndets lag vilket egentligen bara är ett annat uttryck för konceptet "svagaste länken".

"Människan/användaren är svagaste länken" är en uppfattning som man gärna slänger sig med i våra kretsar, det är dock viktigt att respektera skillnaden mellan sårbarheten "klantig människa hjälper angripare" och "hotad människa hjälper angripare".

--
Stefan Pettersson

Det finns ett svar på den uråldriga frågan:

Hur kan vi jämföra vår egen säkerhetsnivå med våra konkurrenters utan att (1) kunna särskilt mycket om säkerhet generellt eller (2) ha detaljkunskaper om varken vårt eget eller deras säkerhetsarbete?

Jo, varje organisation som utför någon form av säkerhetsarbete faller i en av följande tre kategorier. Organisationen

1. försöker förhindra intrång och incidenter,
2. förbereder sig på intrång och incidenter, eller
3. försöker upptäcka intrång och incidenter.

Naturligtvis implicerar andra och tredje kategorin de föregående.

Det är egentligen en stretch att kalla det här för en mognadsmodell... men sen sade jag ju också att den var trivial. Vi ignorerar förstås här faktumet att man kan vara olika bra inom respektive kategori. Det är inte det viktiga, det viktiga är att framhäva att det finns tre, grundläggande utvecklingsstadier.

Majoriteten, man kan nog säga "nästan alla" utan att skämmas, sitter och häckar i första kategorin. Synnerligen få befinner sig i den tredje, det rör sig nästan uteslutande om storbanker, militära organisationer och gigantiska företag (i Sverige Ericsson, Ikea, H&M och motsvarande).

I en värld av (det vi tydligen har kommit överens om att kalla) APT, d v s någon som har bestämt sig för att göra intrång hos just dig och inte tänker sluta försöka förrän det lyckas, blir kategori två och tre viktiga. Prevention eventually fails, som Richard Bejtlich säger.

...fast sannolikheten att du har en alldeles egen APT är ju ganska låg så du kan ju chansa.

In other news, den riskvilliga bocken i Gävle brann ner i fredags, i år igen, något som togs upp här för två år sedan ungefär.

--
Stefan Pettersson

I förra delen om säkerhet och PuL lade jag lite groundwork för vad lagen säger om just säkerhet och faktumet att man inte kan bli straffad för att säkerhetsnivån är olämplig. Däremot kan man, som sagt, bli skadeståndsskyldig. Dock kunde inte Datainspektionen hänvisa till några fall där skadestånd utbetalats på grund av att en personuppgiftsansvarig inte hade tillsett att säkerhetsnivån var lämplig.

De exempel som gavs (felaktigt registrerad som avliden, personnummer bland tentaresultat o dyl) verkar mest handla om slarv.

Frågan jag ställer mig är: varför har ingen av användarna på Efterfesten, Bilddagboken, Gratisbio, Bloggtoppen eller någon av de andra som hackats startat ett civilrättsligt mål och begärt skadestånd?

Håll i er för nu blir det IANAL på riktigt.

Skadestånd definieras av svenska Wikipedia som "den ersättning som den som orsakat en skada betalar till den som drabbats av skadan, som ersättning för denna". Första paragrafen i skadeståndslagen beskriver den s k allmänna ansvarsregeln:

1 § Den som uppsåtligen eller av vårdslöshet vållar personskada eller sakskada skall ersätta skadan.

Tre krav (eller rekvisit som det heter på juridiska) finns alltså:

1. Skada ska ha vållats,
2. uppsåtligen eller av vårdslöshet och
3. skadan ska ha drabbat en person eller sak.

Det räcker med ett enda exempel. Granska valfri tråd på Flashback som rör dumpar från community-sajter så kan du snabbt konstatera att det här inte är en engångshändelse.

Det här är omedelbart efter att Bloggtoppen-dumpen har publicerats på Flashback. Lösenorden i dumpen knäcks och används tillsammans med mailadresserna för att hitta konton på Facebook, webbmail, Dropbox, etc där samma eller liknande lösenord används. Ett manuellt men trivialt arbete. Snubben i forumet bedömer att 15-20 % av användarna har samma lösenord till sina mailkonton.

 

Payoff för det (ringa) besväret är i det här fallet nakenbilder på bloggare (eller deras flickvänner). På sikt är det sedan i princip oundvikligt att dessa sprids och när de en gång har gjort det kommer de ALDRIG att försvinna. Vad som kommer att hända är att de dyker upp på porrsajter.

 

Märk väl att det finns flera personer att lasta i allt det här: (1) det är webbtjänsten som har lösenorden, (2) det är tjuven som bryter sig in, stjäl dem och publicerar dem, (3) det är kräk... personen som tar lösenorden, stjäl nakenbilder och publicerar dem samt (4) offret. Jag fokuserar här endast på de först- och sistnämnda.

 

Tillbaks till juridiken; duger beskrivningen ovan för rekvisit 1 och 3, att skada har vållats en person? Självklart. Hur är det då med vårdslösheten? Det finns flera sätt att argumentera fram och tillbaka kring det här men låt mig ta det till spetsen på en gång:

 

Betrakta följande:

• Lisa, 16 har samma lösenord på (det påhittade) nätverket Fjortiskommunen.se som på Dropbox.
• Lösenordet är dåligt, "fotboll1995" eller nåt.
• Fjortiskommunen har omkring 50 000 medlemmar.
• Fjortiskommunen lagrar bland annat namn, ålder, kön, ort, intressen, mailadress och diverse annat som användarna laddar upp själva.
• Fjortiskommunen lagrar lösenord i klartext, MD5-hash eller motsvarande format.
• Fjortiskommunen har ett skolboksexempel på SQL injection i sökfunktionen.

Fullständigt trovärdiga omständigheter. Vem har varit vårdslös? Jag skulle svara Fjortiskommunen vilken dag i veckan som helst.

Går det att jämföra med en familj som förvarar kopior av sina hemnycklar hos ett larmbolag och att det sedan framkommer att bolaget förvarade nycklarna i ett arkivskåp på lastkajen? Larmbolaget har definitivt varit vårdslöst.

Frågan är sedan, har Lisa varit vårdslös? Visst men vad spelar det för roll? Var hon mer vårdslös än familjen med nycklarna? Är hon vårdslös när hon använder kontokortet på en skimmad bankomat? De har ju knappast en skyldighet att utvärdera säkerheten i tjänsten de köper.

Jag har inte några gjort enorma ansatser att diskutera det här med peers såhär innan publikation (det här är en blogg, inte debattsidan i SvD) men två tydliga responser har dykt upp. Den första är tyvärr fel och den andra är, som tur är, fel.

Respons 1: "Men straff, än mindre skadestånd, skulle ju inte hindra sånt här för att hända."

Nähä? Så traffet för att bryta mot 3 kap. 1 § i brottsbalken hindrar inte heller någon från att "beröva annan livet"?

Respons 2: "De där sajterna kommer bara att friskriva sig i sina användaravtal."

Nej ser du, det får man nämligen inte göra! Se sidan 368 angående 31 § i Personuppgiftslagen, En kommentar av Sören Öman och Hans-Olof Lindblom: "Kraven på säkerhetsåtgärder kan inte frångås ens med den registrerades samtycke".

 

Faktumet att man inte kan friskriva sig är ju en vinst för personuppgiftslagen. Min fråga kvarstår dock: varför har ingen av användarna på Efterfesten, Bilddagboken, Gratisbio, Bloggtoppen eller någon av de andra som hackats startat ett civilrättsligt mål och begärt skadestånd? Vi har ju mängder med exempel som mycket väl skulle kunna visa sig uppfylla alla tre rekvisit i den allmänna ansvarsregeln.

 

--

Stefan Pettersson

Om ett tag kommer jag att byta ut den RSS-feed som slussar ut inläggen från bloggen. Om ni vill fortsätta läsa via RSS kommer ni att behöva byta till följande URL:

http://feeds.feedburner.com/it-sakerhet-enligt-hps

Anledningen är förstås att FeedBurner ger mig en mycket bättre överblick över hur många eller få ni är som läser via RSS och vilka inlägg ni läser respektive inte läser. Förhoppningen är att det ger vägledning av vad som är populärt... och inte. Låt oss kalla det kundvård. :-)

Alternativet är att börja med sådana där irriterande RSS-flöden där man inte får hela artikeln utan måste besöka sidan för att se innehållet.

Som sagt, den gamla kommer inte att stängas av omedelbart, det blir en inkörningsperiod först. Jag förvarnar.

--

Stefan Pettersson

Innan du fortsätter läsa, märk väl att IANAL, trots det skulle jag vilja skriva lite om lagkrav. Lagom till att it-bubblan började blåsas upp ordentligt, 1998, kom personuppgiftslagen (1998:204) eller PuL som den kallas. Lagen har ett syfte som är enkelt att förstå:

1 § Syftet med denna lag är att skydda människor mot att deras personliga integritet kränks genom behandling av personuppgifter.

Innan vi går vidare på datasäkerhet kan det vara värt att ta del av ett par viktiga definitioner som görs i 3 §:

Behandling (av personuppgifter)
Varje åtgärd eller serie av åtgärder som vidtas i fråga om personuppgifter, vare sig det sker på automatisk väg eller inte, t.ex. insamling, registrering, organisering, lagring, bearbetning eller ändring, återvinning, inhämtande, användning, utlämnande genom översändande, spridning eller annat tillhandahållande av uppgifter, sammanställning eller samkörning, blockering, utplåning eller förstöring.

Personuppgifter
All slags information som direkt eller indirekt kan hänföras till en fysisk person som är i livet.

Personuppgiftsansvarig
Den som ensam eller tillsammans med andra bestämmer ändamålen med och medlen för behandlingen av personuppgifter

Två saker är viktiga att notera angående definitionerna: (1) I princip allt du kan göra med data är behandling, jag har svårt att komma på något som inte skulle falla under begreppet. (2) Personuppgifter behöver inte nödvändigtvis vara sådant man tänker på i första hand, t ex personnummer. Det är t ex fullt rimligt att postnummer och förnamn tillsammans kan betraktas som en personuppgift. Anta att förnamnet är Qristofer och att postnumret är till en liten ort utanför Skumträsk med 300 invånare så förstår du varför.

PuL beskriver också i 4 och 5 §§ ett par förutsättningar som måste vara uppfyllda, förenklat att behandlingen måste vara helt eller delvis automatiserad samt att behandlingen måste ske i Sverige.

Så vilka säkerhetskrav ställer personuppgiftslagen? Beroende på hur man ser på det så är lagen antingen väldigt tydlig eller väldigt otydlig. PuL säger följande om säkerhet (min fetstil):

31 § Den personuppgiftsansvarige skall vidta lämpliga tekniska och organisatoriska åtgärder för att skydda de personuppgifter som behandlas. Åtgärderna skall åstadkomma en säkerhetsnivå som är lämplig med beaktande av

a) de tekniska möjligheter som finns,
b) vad det skulle kosta att genomföra åtgärderna,
c) de särskilda risker som finns med behandlingen av personuppgifterna, och
d) hur pass känsliga de behandlade personuppgifterna är.

Det är allt.

Jag har absolut inga problem med det. För det första, hur ska man annars uttrycka sig i en lagtext? För det andra, säkerhetsnivån ska ju alltid vara som den beskrivs i 31 §, oavsett om det handlar om personuppgifter eller kärnstridsspetsar.

Tillsynsmyndigheten Datainspektionen (DI) har dock en del rekommendationer eller "allmänna råd", se t ex Säkerhet för personuppgifter. Texten från DI ställer inga särskilda krav så det är inte alls att jämföra med t ex PCI DSS. Däremot rekommenderar man förstås lösa saker som ledningssystem för informationssäkerhet och riskanalyser. Håhåjaja...

Då har jag mer problem med 49 § som beskriver straff: "Till böter eller fängelse i högst sex månader eller, om brottet är grovt, till fängelse i högst två år döms den som uppsåtligen eller av grov oaktsamhet" bryter mot diverse paragrafer. Dock inte säkerhetsåtgärderna, 31 §.

Säkerhetsåtgärderna kan man alltså strunta i, det enda man riskerar då är skadeståndskrav enligt 48 §. Jag har tyvärr inte hittat några civilrättsmål där 31 § har varit inblandad (DI kunde inte nämna några heller) men här är några andra:

• En person var, under en vecka, felaktigt registrerad som avliden i folkbokföringsdatabasen. Fick 25 000 kr i ersättning för kränkningen. (beslut 2002-09-03, dnr 1652-02-42)
• En person var felaktigt registrerad i belastningsregistret vid två tillfällen. Fick 10 000 kr. (beslut 2006-06-26, dnr 955-06-42)
• En student fick 1 000 kr i ersättning för att universitetet hade publicerat en resultatlista med hans personnummer på intranätet under mindre än 48 timmar. (beslut 2003-03-28, dnr 73-02-42)

Så kan det gå... I nästa del tänkte jag jämföra dessa med andra fall där just brott mot 31 § skulle kunna vara anledningen till att någon har utsatts för kränkning eller lidit skada. Då blir det förstås ännu mer varning för IANAL. Jag tror dock att det kan vara informativt ändå, det borde om inte annat skapa debatt.

Trevlig helg!

--
Stefan Pettersson

Update @2011-10-26: Aftonbladet rapporterar om ett 50-tal ytterligare siter, dessa är t o m äldre än Bloggtoppen, samma lirare publicerade dem för över två månader sedan.

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

Brian Krebs, som verkar ha sanslösa kontaktytor mot de mörkare delarna av internet, har publicerat en lista på företag som kan ha åkt dit i samband med attacken mot RSA i våras.

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

Som bekant är jag skeptisk till riskanalyser och andra försök till att mäta säkerhet.

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

De har börjat sin årliga CyberSecurity Awareness Month på SANS Internet Storm Center nu. Vanligtvis innebär det en osalig blandning av ämnen under en månads tid men i år kommer de att fokusera på vad de kallar The 20 Critical Controls. Dessa beskrivs i ett onödigt pratigt dokument vars senaste version (3.0) publicerades i april i år.

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

Två händelser har uppmärksammats senaste veckan: (1) en protokollsårbarhet har upptäckts i SSL 3.0 och TLS 1.0 som gör att angripare t ex kan stjäla cookies från https-sessioner och (2) www.mysql.com serverade ett exploit pack under, bedömt, några timmar efter ett intrång.

Sårbarheten i SSL
Attacken mot SSL som implementerats av Thai Doug och Juliano Rizzo bygger på att en angripare kan modifiera klartextblock innan de krypteras och XOR:as med nästa klartextblock i CBC-mod. Mer specifikt genom att skjuta in en sträng framför klartexten för att på så sätt "flytta" gränsen mellan två block. De kallar attacken för blockwise chosen-plaintext attack (BCPA). I klarspråk betyder det att de kan gissa cookien ett tecken i taget.

Attacken har dock ett par förutsättningar för att du ska kunna utsättas, säg att du är uppkopplad mot Facebook:

1. Angriparen behöver kunna exekvera JavaScript i din browser från Facebook.
2. Angriparen behöver kunna se din krypterade trafik mot Facebook.
3. Angriparen behöver tid på sig så du måste vara på Facebook tillräckligt länge.

(Förutsättningarna är lite mer generaliserade i originalartikeln, det här är en förenkling.)

Till exempel kan det här översätta till cross-site scripting i Facebook och att angriparen sitter på samma (osäkra) trådlösa nät som du. (Det finns andra situationer men det här borde vara den som är mest trovärdig.)

Mycket bra research. Attacken bygger på och förfinar andras arbete och implementeras dessutom på ett av våra vanligaste krypteringsprotokoll.

Attacken mot www.mysql.com
Det är oklart hur attacken gick till, hur angriparna fick in JavaScriptet på MySQLs hemsida. (Brian Krebs har en teori.) Resultatet är dock känt, varje besökare dirigeras om till en annan server där de möts av BlackHole exploit pack som försöker utnyttja sårbarheter i webbläsare, Flash, Acrobat, Java, etc. I de fall attacken mot klienten lyckas laddas någon form av botprogram ner, vid tillfället kunde bara fyra av 44 antivirusprogram upptäcka det.

Attacken var av typ standard 1A. Inget märkvärdigt egentligen mer än att det var en välbesökt (400k personer/dag) sida som åkte dit. En detalj i det hela var att en av de inblandade malware-servrarna ligger hos ett svenskt webbhotell.

Slutsats
Så, vi fick (1) en riktigt häftig och krävande protokollsårbarhet mot vårt vanligaste säkerhetsprotokoll och (2) en standardattack på standardmanér mot en webbsida. Jag är övertygad om att den senare skördade många fler offer under sina första minuter än vad den förra kommer att göra någonsin.

Det är synd på fler än ett sätt.

--
Stefan Pettersson

Update @2011-09-28: God vän och insiktsfull kollega Christoffer har tagit upp software liability också.

Trots att jag gör det hela tiden så gillar jag egentligen inte att bara hänvisa till andra bloggar eller artiklar och säga "det här är bra". Nu måste jag dock göra det igen...

Poul-Henning Kamp, FreeBSD-utvecklare extraordinaire (och pappa till FreeBSD-MD5-hashen), skrev för omkring två veckor sedan en artikel om software liability: tillverkare av mjukvara borde hållas ansvariga för fel i produkten. Precis som tillverkare av hus, bilar eller tvättmaskiner. Jag har skämtat om ämnet tidigare och tycker att det är en väldigt attraktiv tanke men jag har inte tagit en tydlig position ännu. Jag har lite svårt att överblicka effekterna.

Anywho, Kamps artikel är suverän. Han inleder med en diskussion och utveckling av Ken Thompsons tal Reflections on Trusting Trust från 1984 (som jag har nämnt tidigare någon gång tror jag) och problemen med att man aldrig kan lita på andras kod. Därifrån tar han det vidare till ett förslag om tre klausuler (FreeBSD, go figure) som lämpar över ansvaret för skador på tillverkaren.

Rolig är han också:

Today the operant legal concept is "product liability," and the fundamental formula is "if you make money selling something, you'd better do it properly, or you will be held responsible for the trouble it causes." I want to point out, however, that there are implementations of product liability other than those in force in the U.S. For example, if you burn yourself on hot coffee in Denmark, you burn yourself on hot coffee. You do not become a millionaire or necessitate signs pointing out that the coffee is hot.

Trevlig helg!

--
Stefan Pettersson