IT-säkerhet enligt HPS

Social authentication

Thu, 23 Feb 2012 11:16:29 +0100

Herrarna på Cambridge är på väg ut med en ny, spännande rapport; Social Authentication — harder than it looks!.

Det handlar huvudsakligen om Facebooks metod att autentisera dig genom att t ex låta dig peka ut vilka dina vänner är utifrån deras profilbilder. Som rubriken skvallrar om är det inte så effektivt. Tyvärr. I rapporten tar de upp många intressanta detaljer:

[...] Most people want privacy only from those close to them; if you’re having an affair then you want your partner to not find out but you don’t care if someone in Mongolia learns about it. And if your partner finds out and becomes your ex, then you don’t want them to be able to cause havoc on your account. Celebrities are similar, except that everyone is their friend (and potentially their enemy).

Givetvis knyter forskningen i viss utsträckning an till sådana "hemliga" lösenordsfrågor som används av de flesta, större webbplatserna. I något sammanhang, i samband med att Sarah Palin hade ett intrång på sitt Yahoo!-konto, skrev jag något i stil med: "när det skrivs böcker om ditt liv behöver du verkligen tänka efter innan du kan komma på en lämplig 'hemlig' fråga för att få tillbaka ditt lösenord". Nu kan jag naturligtvis inte hitta var jag skrivit det... Det kanske inte var på bloggen.

Anywho. Precis som rapporten om effekten av lösenordsbyten från i början av året, och av samma anledning, är det här viktig forskning.

--
Stefan Pettersson

Kerckhoffs princip

Fri, 10 Feb 2012 15:29:45 +0100

The entire security of a cryptographic algorithm should be based exclusively on the confidentiality of its key, rather than the confidentiality of the algorithm. -August Kerckhoff (1835-1903)

Joachim Strömbergson på Secworks ger idag fenomenala exempel på brott mot Kerckhoffs princip. De är hämtade från verkligheten och är bra att ha i beredskap för att tvinga ner förvirrade leverantörer i partär.

En effekt av att säkerheten ligger i nyckeln är att man har hemligheter som är lätta byta ut vilket är eftersträvansvärt, något som Joachim förstås tar upp. Artikeln är lång men läs den i alla fall.

Själv har jag en lite ful ovana att referera till Kerckhoff även i frånvaro av kryptografi. Säkerheten i ditt nätverk ska t ex inte bero på huruvida en angripare kan se vilken version av BIND du har. Här brukar man använda det lite sexigare begreppet security by obscurity men det är mer eller mindre samma sak.

Trevlig helg!

--
Stefan Pettersson

Response vid plankning

Wed, 08 Feb 2012 17:13:28 +0100

Ni har säkert hört talas om prevention, detection och response; kategorier som säkerhetskontroller kan sorteras i. Personligen lägger jag till ett par kategorier men dessa tre är de vanligt förekommande.

Glasspärrarna är att betrakta som prevention. Tjutandet som uppstår när någon piggybackar (följer efter någon in) eller någon på insidan öppnar för någon på utsidan faller under detection. Cirkeln har nu slutits ty response finns tydligen också med. På en station längs gröna linjen finns en ganska lång rulltrappa innanför spärrarna som leder upp till perrongen. Detta är hittills obekräftat (jag har inte sett det själv) men en av spärrvakterna har tydligen för vana att stänga av sagd rulltrappa när någon klättrar över glasspärrarna. Plankaren får då gå upp för den stillstående rulltrappan. Trist.

--
Stefan Pettersson

Hälsa och säkerhet

Fri, 03 Feb 2012 11:30:16 +0100

Bloggrannen Cornucopia? skrev i veckan om AstraZenecas förargliga varsel i Södertälje och fick en kommentar från en läsare (Cornus fetstil):

Precis min spaning; och jag råkar vara utbildad läkare. Att KI eller AZ skulle syssla med att främja människors "hälsa" är naturligtvis skrattretande absurt. Deras levebröd är just att människar har ohälsa, och där finns alltså inget som helst incitament att främja någon "hälsa". Hälsa främjas, precis som du skriver, av motion, tallriksmodellen, solsken, meningsfullt socialt liv, närhet, och i bästa fall kärlek. Lejonparten av dagens läkemedel har i princip syftet att minska biverkningarna från felaktig kost, stillasittende, och ensamhet. Att främja hälsa är extremt enkelt och billigt - mycket svårt att tjäna pengar på dvs. Att producera molekyler kallade läkemedel har däremot stora profitmarginaler.

Det kan vara det nyktraste jag läst på länge och jag kan inte låta bli att dra paralleller till säkerhetsbranschen. Det är svårt att tjäna pengar på säkerhetsarbete genom att:

Förorda ordning, reda och disciplin.
Hävda att man inte ska lägga all kraft på att förebygga problem.
Säga att säkerhet är enkelt, det handlar bara om att göra det.
Förespråka öppenhet gällande säkerhetsproblem.
Tjata om att övning är viktigt.

Vad sysslar jättarna i branschen med? De stora är de som utvecklar och säljer produkter. Jag undrar om det verkligen är att gå för långt att använda den andra meningen i citatet ovan för att beskriva de flesta.

Analogin haltar lite. Vi har nämligen en extraordinär omständighet i vår bransch, något vi i princip bara delar med Polisen och Försvarsmakten; vi har intelligenta, antagonistiska motståndare. Motståndare gör säkerhet svårt. Inom "hälsovården" har man inga intelligenta motståndare.

Det är fortfarande en mycket tänkvärd liknelse.

--
Stefan Pettersson

Angående lösenordsbyten

Wed, 01 Feb 2012 15:52:18 +0100

(Det slog mig att det här inlägget låg och jäste i utkorgen, glömde att publicera det. Så without further ado...)

Tydligen var det lösenordsbytardagen häromdagen, den 20 januari. Det verkar vara något som PC för Alla, en datortidning, har dragit igång. Jag nämnde lösenordsbyten förut i samband med en diskussion om best practice.

Jag har fått kritik för det där så när det har varit lösenordsbytardagen och allt kan det vara på sin plats med en utveckling. Det finns ingen riktig slutpoäng i det här inlägget utan jag försöker väl mest förklara hur jag ser på det.

Från förra inlägget:

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.

Jag var rätt tydlig med att jag i regel inte tycker att det är värt besväret.

Notera dock att min syn på det hela i första hand inte är som användare av systemet utan främst som designer av eller ansvarig för systemet. Det finns flera skillnader:

Som användare är man intresserad av att skydda sig själv.
Som ansvarig är man intresserad av att skydda systemet och dess användare.
Som användare litar man inte nödvändigtvis på den ansvarige.
Som ansvarig litar man absolut inte på användaren.

I användarperspektivet, som PC för Alla har, vill man som sagt skydda sig själv; anta att vi pratar om vardagliga webbaserade tjänster: webbmail, sociala nätverk, gratismedlemssidor o dyl. Det enda du kan använda för att påverka säkerheten som användare är ditt lösenord:

Du kan välja ett starkt lösenord.
Du kan byta lösenord regelbundet.

Det är ju en ganska mager verktygslåda när man tänker efter...

Ett starkt lösenord hindrar angripare från att gissa lösenordet vid inloggning (s k online-attack). Ett ännu starkare lösenord hindrar angripare från att gissa lösenordet med tillgång till lösenordshashen (s k offline-attack). Ett ännu starkare lösenord hjälper dock inte alls om systemet inte hashar lösenorden. (En anledning till att inte nödvändigtvis lita på den ansvarige.) Lösenordsbyten skulle dock förmildra omständigheterna genom att, som sagt, begränsa tiden angriparen har tillgång.

Som designer och ansvarig har du en enorm verktygslåda. Bland annat kan du tvinga användarna att välja bra lösenord (eftersom du inte litar på dem) och använda en rejäl hash så att lösenordsknäckningen blir en mardröm för aspirerande angripare. Det var mina förslag på alternativ till lösenordsbyten.

Alltså, ironiskt nog, användaren som tycker att lösenordsbyten är fördjävliga har anledning att göra det medan den ansvarige, som inte behöver lida direkt av det, kan egentligen ägna sig åt bättre saker.

Det finns en lös tråd här, användare som slarvar bort sitt lösenord då? Skriver det på en lapp och lämnar den någonstans eller något annat som den ansvarige inte kan göra något åt? Tja... jag ställer mig frågan om det är tillräckligt vanligt för att det ska vara värt att tvinga alla användare att byta lösenord om och om igen.

Oavsett vad jag säger, när det kommer till kritan, handlar det om vad du skyddar mot vad. Jag hävdar dock att lösenordsbyten inte ska vara en huvudåtgärd, det finns annat som är effektivare.

Fundera t ex över följande tre fall, hur skulle du motivera användandet?

Case #1: Fjortiskommunen.se, tiotusentals användare som lagrar foton o s v på system anslutet till webben (tänk bilddagboken).

Case #2: Robert's Asset Management, ett hundratal användare lagrar känslig information om kunder och affärer (tänk Windowsdomän).

Case #3: Freedom Fighters DB, tiotal företrädare i motståndsrörelse har en databas (tänk CRM) över sina infiltratörer och agenter hos motståndaren (tänk Mossad).

En tumregel kunde vara ju fler användare desto större anledning att byta lösenord regelbundet. Samtidigt, ju fler användare och ju oftare lösenord byts, desto oftare görs det i onödan. Det är lättare att diskutera sådana här saker i ett sammanhang än generellt (som jag då gjorde).

--
Stefan Pettersson

Vad är egentligen best practice?

Fri, 13 Jan 2012 13:14:06 +0100

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:

Varför tror jag det?
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

Förtroende säkerhet Facebook?

Tue, 10 Jan 2012 14:54:46 +0100

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

Populärsäkerhet i London

Tue, 03 Jan 2012 17:53:30 +0100

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

Glasspärr-forensics

Wed, 21 Dec 2011 11:55:27 +0100

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

Glasspärrarna: path of least resistance

Wed, 14 Dec 2011 14:30:41 +0100

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

Trivial mognadsmodell för säkerhetsarbete

Mon, 05 Dec 2011 09:45:05 +0100

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

försöker förhindra intrång och incidenter,
förbereder sig på intrång och incidenter, eller
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

Det finns ett svar på den uråldriga frågan:
Hur kan ni jämföra er egen säkerhetsnivå med era konkurrenters utan att (1) kunna särskilt mycket om säkerhet generellt eller (2) ha detaljkunskaper om varken ert 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

försöker förhindra intrång och incidenter,
förbereder sig på intrång och incidenter, eller
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 oundvikliga.
...fast sannolikheten att du har en alldeles egen APT är ju ganska låg så du kan ju chansa.

Personuppgiftslagen och datasäkerhet -- del 2

Tue, 29 Nov 2011 15:02:25 +0100

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å:

Skada ska ha vållats,
uppsåtligen eller av vårdslöshet och
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

Ny RSS-feed

Mon, 14 Nov 2011 10:00:15 +0100

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

Personuppgiftslagen och datasäkerhet -- del 1

Fri, 11 Nov 2011 16:42:39 +0100

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

Bloggtoppen hackat: party like it's 2008

Tue, 25 Oct 2011 23:40:02 +0200

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

RSA var nog inte ensamma

Mon, 24 Oct 2011 18:19:20 +0200

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

Förenklad eller förfinad riskanalys

Fri, 21 Oct 2011 13:39:28 +0200

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

20 Critical Controls & Security 101

Fri, 07 Oct 2011 09:18:55 +0200

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:

Dina osäkra system påverkar säkerheten i dina säkra system.

--
Stefan Pettersson

MySQL & SSL

Wed, 28 Sep 2011 09:52:00 +0200

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:

Angriparen behöver kunna exekvera JavaScript i din browser från Facebook.
Angriparen behöver kunna se din krypterade trafik mot Facebook.
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

Skadeansvar åvilar tillverkaren

Fri, 23 Sep 2011 14:30:54 +0200

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

Okontroversiella men riktiga åsikter

Fri, 23 Sep 2011 11:13:03 +0200

Val Smith (valsmith) är, och har länge varit, en riktigt duktig reverse engineer och exploit-utvecklare. Han har presenterat på massa konferenser, skrivit en massa uppsatser och är inblandad i Metasploit och Offensive Computing. Han har rejält med street cred i branschen helt enkelt.

Nu har valsmith skrivit ett blogginlägg, My Personal War Against Overuse of Memory Corruption Bugs, där han säger att han har slutat lägga tid på buffer overflows och liknande sårbarheter där minne skrivs över (min fetstil):

[...] but how much skilled time investment is required to take a bug from a crash to a highly reliable, continuation of execution, ASLR / DEP bypassing exploit ready for serious use? Average numbers I have heard from friends who do this all day long are 1 - 3 months, with 6 months for particularly sticky bugs. How many people are there that can do this? Not many. So you have a valuable resource tied up for months at a time to produce a bug which may get discovered and published in the interm ( a process you have no real control over), patched and killed. When was the last time you heard about a really bitchin Windows 7 64bit remote?

I could not agree more.

Det är ingen tvekan om att sånt här (pdf) är sinnesjukt imponerande. Sotirov, HD Moore, Charlie Miller, Dino, Zalewski, Dave och alla deras gelikar är avundsvärt begåvade och extremt målinriktade. Arbetet med att ta sig förbi ASLR, DEP, sandlådor och diverse andra skydd för att till slut få ett robust exploit är dock inte värt det. Tänk om all deras energi istället kunde fördelas på tusen gånger fler människor som istället lade energin på att få ordning på de enkla sakerna. Då kanske Comodo, RSA, DigiNotar o s v hade klarat sig.

Men, eftersom omfördelning av energi sådär än så länge inte ens är science fiction så är valsmiths eget förslag: att lägga energin på att hitta och utnyttja mer fundamentala sårbarheter som är riktigt svåra att reparera, alldeles fantastiskt.

--
Stefan Pettersson

Säkerhet och biologi

Thu, 22 Sep 2011 09:18:54 +0200

Inte är det konstigt att känna viss upphetsning när man läser en uppsats som inleds med orden:

The security and stability of a nation, group, or people can be considered as closely analogous to the immunity of a multicellular organism against internal and external threats to its integrity.

Uppsatsen heter From Bacteria to Belief, är skriven av Luis P. Villarreal och utgör kapitel fyra i Natural Security: A Darwinian Approach to a Dangerous World.

Den tvärvetenskapliga synen på säkerhet har sedan många år sett till ekonomi och psykologi. Biologi eller åtminstone immunologi och evolutionsbiologi kanske kan visa sig nyttigt i framtiden. Kul att läsa om är det i alla fall.

--
Stefan Pettersson

Mail v. instant messaging

Fri, 16 Sep 2011 13:20:12 +0200

Hur kommer det sig att företag lägger så pass mycket energi på att utvärdera, fundera och undra över säkerheten i instant messaging-program som Skype och MSN när de inte tycks ha problem med mail?

Man är i regel oroad över två saker angående IM: (1) sårbarheter i klientprogramvaran och de nödvändiga uppdateringsrutinerna som kommer med problemet. (2) Den andra saken verkar vara funktionen programmet är till för att lösa, d v s att låta anställda skicka och ta emot meddelanden samt att skicka och ta emot filer.

Låt oss angripa dem en i taget.

(1) Gällande sårbarheter i klientprogramvaran så gissar jag att de "vanliga" programmen, Excel, Word, Acrobat och Flash, står för en så mycket större mängd av klientsårbarheter att det blir svårt använda det som ett argument. Om du vågar köra dessa program så innebär inte en IM-klient en särskilt förhöjd risk.

(2) Ponera att SMTP, POP3, IMAP, etc inte fanns idag utan att alla använde t ex Skype för att skicka meddelanden och filer till varandra. Anta att någon skapade de RFC:er som beskriver nämnda protokoll idag och publicerade dem. Mailprotokollen hade aldrig blivit accepterade. Både säkerhetsfolk och användare hade ju skrattat.

Va? Kan man skicka meddelanden till vem som helst helt utan att "lägga till" dem först?
Va? Kan man inte alls lita på vem som är avsändare?
Va? Skickas meddelanden i klartext över Internet?
Va? Skickas filer också i klartext?
Va? Kommer den där filen jag skickar till dig att ligga och skräpa, inte bara på min och din hårddisk utan även i våra respektive mailkorgar, både lokal cache och på servern, för överskådlig framtid?
Va? För att förtydliga, en känslig fil som skickas från mig till dig lagras alltså på minst fyra, kanske sex, kanske fler, platser?
Va? Kommer 95 % av alla meddelanden som skickas mellan personer att vara skräp och annonser som ingen vill ha?
Va? Kommer det att vara svårt att överföra filer som är större än 5 Mb?

När man tittar nyktert på situationen ter den sig tämligen absurd.

Trevlig helg i alla fall!

--
Stefan Pettersson

Öppenhet om intrång/sårbarheter

Fri, 26 Aug 2011 14:13:10 +0200

John Wilanders krönika i TechWorld från häromdagen, Mörkläggning stor risk för företagen, diskuterar fördelarna med att företag är öppna med vilka säkerhetshål de patchar och nackdelarna med att inte göra det. Jag håller med på alla punkter, det är en öppenhet som gagnar företaget och jag förespråkar. En sak hade jag inte hört talas om tidigare:

I våras presenterade Google sina erfarenheter av att betala för säkerhetsbuggar. "Mer prisvärt än granskning gjord av konsulter" var deras slutsats. Plus att de får en strid ström av bra rekryteringstips. Google anser sig alltså själva tjäna på responsible disclosure.

Men när man tänker efter så känns det ju rätt naturligt.

Jag tar tillfället i akt och pitchar två tidigare inlägg i ämnet öppenhet: Molnleverantörers transparens och Offrets dilemma.

John säger det ju inte rakt ut i krönikan men jag är glad att han åtminstone hintar om det. Själv har jag funderat på att skriva om det ett bra tag men har inte vågat riktigt... Hur kommer det sig att Sony fick en sådan rejäl omgång i år? En bidragande orsak, kan jag tänka mig, är att Sony helt enkelt inte är särskilt omtyckta.

John hänvisar till stämningsförsöket mot hackers som jailbreakade Playstation 3 men det rör sig om flera liknande "incidenter" där Sony har gjort kundfientliga val. Rootkitet på musik-skivor är ju vida känt och den, något överdrivna kan man tänka, bloggen Sony Sucks har flera exempel.

Som individ kan man ju minska sina risker att bli utsatt för våldsbrott på t ex krogen genom att vara trevlig och artig. Gäller samma sak för företag?

Trevlig helg, igen!

--
Stefan Pettersson

Generella åtgärder mot specifika sårbarheter

Fri, 26 Aug 2011 13:48:43 +0200

Det här är ett utmärkt exempel på varför det här är kan vara en bra idé. Att segmentera klienterna är ännu ett verktyg tillsammans med de jag diskuterat i ett tidigare inlägg då franska regeringen åkt dit på liknande sätt som RSA.

Dessa "social-engineering-APT-klientsårbarhet-mail"-attacker är enormt svåra att skydda sig emot. Oavsett vad UTM-brandväggs- och vissa antivirusleverantörer hävdar. Den bästa metoden är en kombination av flera åtgärder, bl a de från inlägget om franska regeringen. Det är krångligt men on the upside så innebär de en höjning av säkerheten generellt, inte bara mot det här specifika hotet.

Med andra ord, det är bra att bekämpa specifika sårbarheter med generella åtgärder. Genrella åtgärder är oftast enklare och kan ofta ge positiva bieffekter. En appliance som söker igenom inkommande mail efter trojaner skyddar bara mot trojaner i inkommande mail. Att filtrera utgående trafik från klienter skyddar bland annat mot trojaner, oavsett om de kommer med mail eller USB-stickor.

Trevlig helg!

--
Stefan Pettersson