IT-säkerhet enligt HPS

För mer än två år sedan skrev jag om de här ständigt aktuella farbröderna från Cambridge och deras korta artikel om 3-D Secure: Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication.

Farbröderna presenterade ett flertal grundläggande problem med 3-D Secure. En bekant till mig trillade dit på ett av dem för några veckor sedan vilket ledde till att en skurk kunde köpa elektronikprylar för 12 000 kr utan att spendera en enda (egen) krona.

Först, en lite utförligare förklaring av 3-D Secure.

Bakgrund
3-D Secure är det tekniska, gemensamma namnet för Visas och MasterCards respektive varumärken Verified by Visa samt MasterCard SecureCode. Det är säkerhetsåtgärden att du måste koppla ett ytterligare autentiseringssteg (i regel ett lösenord med tillhörande "hälsningsfras") till ditt betalkort och sedan ange detta i samband med att du köper något på kortet över internet.

Handlare motiveras (ges incitament) till att implementera detta genom att kortföretagen tar på sig risken vid bedrägerier. Alltså, om du som handlare säljer någonting och köpet senare bestrids av kortinnehavaren som bedrägligt så får du behålla pengarna; om du använder 3-D Secure och därmed kräver den extra autentiseringen av kortinnehavaren. Om du inte har säkerhetsåtgärden implementerad vid köp så får du ge snällt ge tillbaka pengarna, även fast varan är levererad. Vissa, större företag har medvetet tagit den här risken då de tror att det extra steget hindrar spontana köp och därför innebär större förluster än vad eventuella bedrägerier medför. CDON är ett exempel.

NB att det inte finns något i protokollet som begränsar autentiseringen av kortinnehavaren till lösenord. Kortutgivaren (banken) kan mycket väl använda SMS eller befintliga bankdosor för att styrka kortägarens identitet enligt 3-D Secure.

Gången är som följer: du fyller i alla dina kortuppgifter som vanligt vid köpet men innan det avslutas dirigeras du till kortutgivaren (din bank), ofta via en popup eller iframe. På bankens webbsida får du bevisa ditt ägarskap genom att ange ditt lösenord.

"Hälsningsfrasen" som nämnts ovan kallas formellt för personal assurance message (PAM). Det är ett kort, godtyckligt meddelande du anger på internetbanken i samband med att du väljer ett lösenord. När du, vid ett köp, blir ombedd att fylla i ditt lösenord i samband med Verified by Visa/MasterCard SecureCode visas ditt valda PAM-meddelande. Detta syftar till att försäkra dig om att det är banken du pratar med, det är alltså ett skydd mot phishing-liknande attacker. Tanken är att det bara är du och banken som vet PAM och lösenord, en form av ömsesidig autentisering.

Du ska alltså bara ge ditt lösenord på den sida som visar din PAM-hälsningsfras. I mitt fall, som bilden visar, ska jag dra öronen åt mig ifall hälsningsfrasen inte är "Dags att pröjsa grabben!". Det skulle nämligen betyda att det inte är SEB, min kortutgivare, som finns på andra sidan.

Det tänkte inte min gode vän på tyvärr.

(Ja, det är som sagt meningen att PAM ska vara en delad hemlighet mellan dig och banken. Man ska alltså inte publicera den på sin blogg på det här viset.)

Bedrägeriet
Följande hände: Liten, svensk webbshop på svenskt webbhotell säljer prydnadssaker. För att inte bli belastade med PCI DSS-kraven har man låtit en payment service provider (PSP) hantera alla kortbetalningar. Detta betyder att webbshopen aldrig hanterar någon kortinformation och alltså inte lyder under PCI DSS.

Vän placerar prydnadsföremål i varukorg och trycker på "Till kassan". Får en lista på valda varor presenterade samt en lista på betalningsalternativ. Trycker på "Kontokort". Ett formulär glider snyggt ned under kortalternativet och begär "det vanliga": namn, adress, kortnummer, utgångsdatum, CVV-kod och... Verified by Visa-lösenord. Med synapserna låsta på prydnadsföremålet fyller god vän i uppgifterna och trycker på "Köp".

Efter trycket på "Köp"-knappen dirigeras webbläsaren vidare till butikens PSP som visar upp ett formulär och begär "de vanliga" uppgifterna. Igen. "Vad faan...", tänkte god vän och fyllde i kortnummer o s v ännu en gång. Tryck på en "Nästa"-knapp ledde till ytterligare en omdirigering till en sida på bankens servrar som visar vännens hälsningsfras och begär Verified by Visa-lösenordet som plikttroget fylldes i. Ett par dagar senare levereras ett styck prydnadsföremål och allt är grannt.

Ytterligare några dagar senare har tre köp om 4 000 kr gjorts på en stor, svensk nätbutik för elektronikprodukter. Min vän har utsatts för ett kortbedrägeri. Polisen lade ner ärendet kort efter att polisanmälan gjorts.

Hur gick det till?
Enkelt, den lilla webbutikens webbsida hade hackats och dess kassa-sida (som visade vilka produkter som valts och vilka betalningsalternativ som fanns) hade fått några ytterligare rader kod ditlagda. Kod som (1) visar ett formulär som begär betalningsuppgifter inklusive Verified by Visa-lösenordet, (2) sparar, alternativt skickar uppgifterna någonstans och sedan (3) ansluter till det ordinarie köpförloppet hos PSP:n. Detta var anledningen till att god vän fick fylla i uppgifterna två gånger. En gång till bedragaren, en gång för att köpa sitt prydnadsföremål.

Tre saker är viktiga här:

1. Att webbutiken använde en PSP hade ingen betydelse.
2. PCI DSS, kortföretagens säkerhetsstandard för alla som hanterar kortnummer, var irrelevant.
3. 3-D Secure, om det användes på den butik där god väns kort utnyttjades för att köpa tv-apparater, resulterade bara i att det är banken som får ersätta god vän, inte butiken.

Skuld och skydd
Vems fel var det här? Rent krasst så är det såklart webbutikens. Deras (hans/hennes förmodligen) bristande säkerhet ledde till att någon kunde jacka in sig i köpförloppet och stjäla god väns betalningsuppgifter. (Detta förstås med reservation för att det också kan vara webbhotellets fel.)

Är man ännu mer krass kan man säga att det är god väns fel. Hur kan man vara så jävla dum, och så vidare.

Problemet är dock knepigare än så, säkerhet ligger väldigt långt ner på både webbutikens och kundens lista över saker-jag-bryr-mig-om. Butiken vill sälja prydnadsföremål, kunden vill köpa prydnadsföremål, resten är av underordnad betydelse. Det känns oansvarigt att lägga ansvaret på endera av dem.

Jag kan dock inte säga att jag omdelbart ser hur någon annan än dessa två skulle kunna ha hindrat detta.

Är det här förutsättningarna för den nya tidens handel, e-handeln? Om du driver en vanlig butik nere på torget får du se till att låsa dörren på natten, om du driver en webbutik får du se till att inte få kassa-sidan hackad. Inget försäkringsbolag i världen skulle ju ersätta dig om du hade inbrott och det kom fram att du inte låser dörren.

Uppdatering: Joachim på SecureWorks skrev om 3-D Secure och problemet med phishing i höstas. Som alltid när det gäller "något du vet" så är phishing en attack att ta hänsyn till.

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

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

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

Update @ 2011-05-30: Lockheed Martin tydligen.

Snabbt inlägg.

Någon snubbe påstår att ett företag i USA som levererar till amerikanska försvaret byter ut alla sina SecurID-tokens, enligt utsago p g a intrånget i RSA i mars där seeds sannolikt stals:

It seems likely that whoever hacked the RSA network got the algorithm for the current tokens and then managed to get a key-logger installed on one or more computers used to access the intranet at this company. With those two pieces of information they were then able to get access to the internal network.

Det första som slår mig är bristen på bakgrundshistoria. Hur vet han det här?

--
Stefan Pettersson

När företag blir hackade och attacken publiceras blir jag glad. Det är inte fråga om någon skadeglädje, tvärtom känner jag i regel medlidande. Jag hävdar t ex fortfarande att det är synd om HBGary, eller åtminstone om Greg Hoglund. Min glädje beror snarare på ren själviskhet. Dels kan kan lära sig mycket av andras misstag men framförallt ger det en bättre bild av vilka attacker som används och vilka som angrips. I verkligheten.

Att vara publik om intrång
Företag är ju, som bekant, ovilliga att medge att de har utsatts för lyckade angrepp. Deras resonemang är att det gör situationen värre, konsekvensen av att deras hemligheter har stulits förstärks ju av att det blir allmänt känt att de har stulits (m a o de klarar inte av att skydda sina hemligheter).

Själv resonerar jag som Don Corleone, dåliga nyheter vill man ha reda på omedelbart. Att blunda för, eller att inte känna till deras existens, är värre än att vara medveten, då har du åtminstone möjlighet att agera.

Det här kan leda till en motsättning och jag vill illustrera det med ett dilemma. Du är säkerhetsansvarig och får ett mail:

Hej, om en stund kommer jag att singla en slant för att avgöra om jag ska bryta mig in i ditt företag och stjäla dina hemligheter. Du kommer inte att kunna stoppa attacken och du kommer inte att kunna upptäcka om det har skett eller inte. Du har nu två val: vill du att jag — om jag genomför attacken — (1) inte berättar det för någon eller (2) berättar för alla (massmedia)?

Dilemmat ska illustrera följande:

1. Konsekvensen av intrånget ökar om det blir publikt.
2. Konsekvensen av intrånget ökar om du själv inte vet att det har hänt.

Dilemmat är ju lite ansträngt och det är förstås aldrig så här svart eller vitt men om det skulle komma till sin spets, vad föredrar man?

Spontant skulle man vilja välja alternativ ett och sedan gå ut med intrånget på egna villkor och därmed behålla initiativet. Ha kakan och äta den. Den vägen blir tyvärr lite konstig eftersom det inte går att avgöra om intrånget har skett. Du kan med andra ord aldrig lova allmänheten att allt är väl, du riskerar alltid att intrånget verkligen har genomförts och att dina hemligheter eventuellt dyker upp någonstans när du är som minst förberedd. Du vet inte heller vad som har stulits eller vilka som har tillgång till det.

Ju mer man tänker på det desto rimligare verkar alternativ två men det är förenat med andra problem; du hinner t ex inte förbereda dig utan medias bild av intrånget kommer att få störst exponering.

...men annars skulle det ju inte vara ett dilemma.

--
Stefan Pettersson

Första halvåret 2011 verkar bli intressant avseende intrång. Senast i raden är Wordpress som har fått ett antal servrar rootade:

Tough note to communicate today: Automattic had a low-level (root) break-in to several of our servers, and potentially anything on those servers could have been revealed.

Notera särskilt kommentarerna till blogginlägget:

• Thanks for the update team. Crap happens, but you’re always keeping us up to date. Much appreciated. Hopefully no one was exposed too badly.
• Thank you for being transparent!
• Thanks for the info. All the best!
• Thanks for all your hard work, guys!
• Thanks for keeping us in the loop.
• Thank you for your prompt and honest post.
• Yikes… Glad you guys are up front about it though. Much appreciated.
• Honesty and transparency are rare. Thank you for being upfront and so quick to let us know!

Vi kanske ska revidera vår gängse uppfattning om att det är dålig PR att råka ut för intrång. Det kanske snarare är hur man hanterar intrånget som avgör allmänhetens dom.

Trevlig helg!

--
Stefan Pettersson

Den här då... Kollega Martin skickar en länk där en anställd på TripAdvisor berättar att root-konton används väldigt promiskuöst i deras system:

Pfft. "root on your box" is so last week. Here at TripAdvisor, we give engineers root on EVERY box. I'd add "modulo the live site", but when I needed that, it was made available.

Inlägget är lite mer än ett halvår gammalt. Det här är ett tydligt tecken på en s k knarkarkvart.

(För er som missade det häromdagen, medlemmar på siten TripAdvisor, en enorm webbsida för folk som gillar att resa, fick sina mailadresser stulna.)

--
Stefan Pettersson

I en period där det har skett ovanligt många, allvarliga högprofilintrång (RSA, Comodo, franska finansdepartementet, TripAdvisor, Europakommissionen, m f l) kan det vara på sin plats med några, lite mer harmlösa, exempel.

Filmen som visar hur man hackar en billboard på Times Square med en iPhone var ju (uppenbart) fejkad. Det betyder förstås inte att det är omöjligt. Minns t ex de dynamiska vägskyltarna i Texas som hade default-lösenord för ett år sedan:

Eller ett färskare exempel; en reklamskärm längs en motorväg i Ryssland visade porrfilm i 20 minuter i januari. Ni behöver inte vara oroliga dock, faran är över, den hemska förövaren är gripen, åtalad och dömd till sex år i fängelse:

Trevlig helg!

--
Stefan Pettersson

För några veckor sedan skrev jag om första intrycket vid blindträffar, att det är svårt att verifiera en person om man inte vet något om dem på förhand. Jag länkade också till uppsatsen Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf) som handlar om hur en stat skulle kunna tvinga en CA att utfärda certifikat till t ex mail.google.com.

Ett annat alternativ är förstås att bryta sig in hos en CA eller deras partners och signera ett par certifikat på egen hand.

Det är precis vad som hände en av de större, Comodo, den 15 mars. Läs deras incidentrapport och deras kommentarer i bloggform. De misstänker att Iran ligger bakom attacken.

Det kommer definitivt att vara lärorikt att följa den här historien. Ful-certifikat på det här sättet är ett fruktat säkerhetsproblem. En variant på lösningen som presenteras i Certified Lies skulle dock kunna skydda mot sånt här. Åtminstone i teorin.

--
Stefan Pettersson

Mångas favoritsäkerhetsfarbror Steven M. Bellovin, känd för sina RFC:er och boken Firewalls and Internet Security från 1994, har resonerat en del kring vad RSA-angriparna egentligen kom över och vad det kan leda till. Inlägget The RSA SecurID Problem tonar ner komplexiteten i SecurID och beskriver dess konceptuella funktion väldigt bra.

Det värsta som kan hända är väl mer eller mindre att RSA har en master secret som allt står och faller med. Angående nyckeln K som varje token använder för att generera sina koder:

It is tempting to calculate K=G(K',serial_number), where K' is a closely-held RSA secret and G is some other hash function. The risk here is discovery of K'; any new devices would be at risk of compromise if the attacker knew the serial numbers associated with some target customer. This is the really big question: how are the K values generated?

Men som Bellovin själv säger, det är förmodligen ganska otroligt.

--
Stefan Pettersson

Flera datorer tillhörande franska regeringen har hackats. Enligt utsago har det skett med hjälp av övertygande mail till rätt personer. Mail med bifogade filer som kunde köra kod på något sätt för att skapa ett brohuvud åt angriparna.

Visst har vi sett det förut. T ex i januari förra året i samband med att Google och en del andra företag blev angripna av vad som verkade vara Kinesiska staten. Eller varför inte när samma gäng var ute efter Dalai Lama och tibetaktivister. (Vem kan sjunka så lågt att de angriper en spirituell ledare, förresten?)

I inlägget jag skrev då, Google, Adobe, Kina och trojaner, refererade jag till några läsvärda artiklar och påbörjade en lista på vad man kan göra för att motverka liknande attacker. Det finns nämligen ingen produkt man kan installera för att värja sig från detta, oavsett vad leverantörerna hävdar. Från förra posten:

1. Kör inte som administratör.
2. Använd moderna operativsystem som Windows Vista/7.
3. Använd moderna webbläsare.
4. Uppdatera tredjepartsprogramvara.
5. Använd antivirus på mail-gateways.
6. Var misstänktsam mot bifogade filer.

Ytterligare verktyg:

1. Filtrera utgående trafik i brandväggen.
2. Tvinga in utgående http-trafik genom ett proxy.
3. Logga för att kunna hantera situationen när något upptäcks.
4. Agera när något händer så att angriparna inte får röra sig fritt så länge.
5. Använd SPF eller DKIM så att har möjlighet att upptäcka spoofade mail.

Det finns massor av saker som påverkar angripares rörlighet och möjligheter. Har ni fler förslag?

--
Stefan Pettersson

Som bekant är jag en sucker för berättelser från verkligheten. Ars Technica har en artikel som utförligt beskriver hur "hackergruppen" Anonymous angrep HBGary, HBGary Federal och Rootkit.com. Bakgrunden till det hela är att HBGary, ett säkerhetsföretag, hade lagt en massa tid på att försöka identifiera ett par medlemmar i Anonymous. Attacken var en hämndaktion helt enkelt.

Om du inte orkar ta dig igenom hela berättelsen (en stor del av texten ägnas åt att förklara grundläggande saker) så följer här en kortversion:

1. HBGary Federal har CMS specialutvecklad av tredje part. CMS har SQL injection-sårbarhet.
2. Databas med användare och lösenordshashar dumpas.
3. Vanlig vanilj-MD5 har använts för att hasha. Rainbow tables.
4. Vissa användares lösenord är samma på Linuxservern support.hbgary.com och har där SSH-access.
5. Linuxservern är en privilege escalation-sårbarhet. Tillgång till backuper och diverse forskningsdokument.
6. Ytterligare ett av lösenorden från CMS-databasen användes för administration av företagets Google Apps-konto.
7. Som administratör, återställ lösenord på Greg Hoglunds mailkonto, logga in.
8. Använd Gregs konto för att lura en annan administratör av rootkit.com att återställa lösenordet på ett användarkonto och öppna brandväggen.
9. Rootlösenordet till rootkit.com fanns i ett mail i Greg Hoglunds inbox.
10. Defacea och dumpa användardatabasen på rootkit.com.

Så kan det gå. Artikeln tar upp flera saker som kunde ha förhindrat hacket på flera lager. Det mest uppseendeväckande i hela kedjan väl användandet av social engineering. Resterande steg är fairly straightforward. För att citera Ars Technica:

Most frustrating for HBGary must be the knowledge that they know what they did wrong, and they were perfectly aware of best practices; they just didn't actually use them. Everybody knows you don't use easy-to-crack passwords, but some employees did. Everybody knows you don't re-use passwords, but some of them did. Everybody knows that you should patch servers to keep them free of known security flaws, but they didn't.

Precis vad jag tycker:

Drift är osexigt men ur säkerhetssynpunkt är det så mycket viktigare med "det dagliga" än implementeringsdetaljer i webbapplikationer. Det värsta med det hela är att det inte är raketkirurgi; alla vet att det är viktigt med ordning och reda, alla vet att det inte är bra att receptionisten har sådana rättigheter, alla vet att "123456" är världens sämsta lösenord, alla vet att det är farligt att inte förstå sig på sina system. Det är inga nyheter.

Samma lösenord för system med olika krav är dåligt. Publika nycklar för att logga in över SSH är bättre än lösenord. Säkerhetspatchar, i synnerhet då det finns publika exploit, är viktiga. Man kan hålla på hur länge som helst och räkna upp alla dessa vanliga saker som gör skillnaden mellan osäkert och säkert.

Wake up people. Vi kan ju det här. Varför gör vi det inte?

--
Stefan Pettersson

Uppdatering @ 2011-01-13: Tydligen har jag och CJ fortfarande någon form av mind sync; han tar diskussionen om bakdörrar till en högre nivå på sin blogg. Samtidigt. :-)

I sin essä The Cathedral and the Bazaar från 1997 konstaterar Eric Raymond att given enough eyeballs, all bugs are shallow. När tillräckligt många programmerare tittar på koden kan alla buggar upptäckas. Bakgrunden till teorin är förstås erfarenheterna från Linuxkärnans utveckling under 90-talet.

I projekt med öppen källkod kan ju vem som helst titta på källkoden. "Vem som helst" borde ju innebära "väldigt många", inte sant? Eftersom säkerhetsbuggar är en delmängd av buggar, finns det generellt färre säkerhetsbuggar i program med öppen källkod?

Det här är ett fånigt känsligt ämne och är bidragande till många bråk. De som hörs mest är, som vanligt, de längst ut på vardera kant och, som vanligt, har ingen av kanterna rätt. Teorin är alldeles för generaliserad för att kunna besvaras som ett antingen-eller.

En vanlig tillflyktsort för Raymonds förespråkare är "...men du har åtminstone möjligheten att granska koden". Det är helt korrekt men har inget att göra med mängden buggar som finns eller inte. Det är dock intressant, varför skulle man vilja granska ett program? Uppfyller det våra säkerhetskrav? Verkar det vara välskrivet? Innehåller det några bakdörrar?

Bakdörrar
En bakdörr i ett program kan beskrivas som ett inofficiellt och dolt gränssnitt till programmet. Begreppet blev populärt i samband med filmen Wargames från 1983 där ett hemligt lösenord, "joshua", ger omedelbar tillgång till AI-datorn WOPR på NORAD. <begreppsnazism>Bakdörr är också vad många generellt menar när de istället säger trojan även fast gränsen ofta är fin.</begreppsnazism> Nyckeln till det hela är att bakdörren är just dold. Annars hade det väl bara varit en... dörr, antar jag.

Ken Thompson, legendarisk för sitt arbete med Multics och UNIX, höll 1984 ett tal, Reflections on Trusting Trust, där han beskrev hur en kompilator kan trojaniseras så att den lägger till bakdörrar i program den kompilerar. Som en bonus trojaniserar den även sig själv vid kompilering (även kompilatorer kompileras, ibland paradoxalt nog av sig själva). Inte nog med det, Thomson demonstrerade också en kompilator som sabbade de disassemblers den kompilerade så att de helt enkelt gömde de bakdörrar kompilatorn placerat ut.

Förhoppningsvis (vi vet ju inte) är bakdörrar i "verkligheten" sällan så esoteriska. För att knyta ihop; några exempel på bakdörrar i projekt med öppen källkod:

Linux 2.6
Vi börjar med ett som är rätt gammalt men ändå förtjänar ett omnämnande. I november 2003 lades två rader till i filen kernel/exit.c. Om ett särskilt kriterium uppfylldes uppgraderades användaren till root. Väldigt subtilt. Läs konversationen på kernel-listan på Kerneltrap. Bakdörren upptäcktes omedelbart.

UnrealIRCd 3.2.8.1
I somras (2010) gick utvecklarna bakom den populära IRC-servern ut med att en bakdörr har upptäckts i filen include/struct.h. Även den här gången har två rader lagts till varav den ena anropar system() för att exekvera kommandon. Läs mer på deras forum. Bakdörren hade funnits i källkoden i mer än ett halvår.

ProFTPD 1.3.3c
I början av december 2010 upptäcktes en bakdörr i FTP-servern. När kommandot "HELP ACIDBITCHEZ" gavs hamnade man i ett root-shell. Ändringen gjordes på servern som servrar tarbollarna, inte i CVS-trädet. Läs meddelandet på mailinglistan för mer information. Bakdörren hade existerat i mindre än en vecka.

OpenBSD?
I mitten av december fick Theo de Raadt ett mail som hävdade att FBI hade lagt in bakdörrar i operativsystemets IPSEC-stack. Det hela verkar ganska otroligt och har inte kunnat bevisas.

Ettercap NG-0.7.3?
I ett zine som publicerades under julhelgen, Owned and Exposed, gjordes antydningar till att det populära snifferverktyget Ettercap har haft en bakdörr sedan många år tillbaka. Inget har bekräftats och på SpiderLabs blogg har man undersökt saken och kommit fram till att det är osannolikt.

Samtliga exempel ovan har antingen upptäckts (ibland snabbt, ibland inte) eller inte kunnat bevisas. Vilka slutsatser kan vi dra från det gentemot Raymonds teori om många ögon och Thompsons exempel på bakdörrar som är extremt svåra att hitta? Inte många.

--
Stefan Pettersson

Bloggkonglomeratet Gawker Media hackades den 11 december och strax över en miljon användarnamn och lösenord hamnade på diverse torrent-trackers. Joseph Bonneau i säkerhetslabbet på Cambridge har skrivit en bra sammanfattning av vad som har kommit ut hittills; The Gawker hack: how a million passwords were lost.

Jag har sagt det tidigare, med tanke på hur sällan information om angrepp "kommer ut" tycker jag att man ska ta varje chans att lära sig från andras misstag.

--
Stefan Pettersson

Omkring 800 lägenheter hos fastighetsägaren Platen i Motala fick inomhustempraturen sänkt för några dagar sedan. Det visade sig att det var någon utomstående som gjort det. Det visade sig att det var via ett administrationsgränssnitt för något av SRÖ-systemen (styr, regler, övervakning) som låg öppet på webben. Blott ett lösenord bort.

Jag har refererat till artikeln i AffNyheter tidigare men jag har svårt att se hur den kan bli mer aktuell (PDF). Den har snart två år på nacken men budskapet blir bara mer aktuellt: fastigheter får allt fler tekniska system, dessa system blir allt mer IT-fierade, detta ökar risken för angrepp.

--
Stefan Pettersson

Politisk hacktivism, som det kallas, har aktualiserats såhär i valtider. Sverigedemokraternas hemsida led av en överbelastningsattack (DDoS med botnät vad det verkade) under några dagar, SSU:s sida hackades förra helgen, en del interna mail läckte. Senast, under gårdagen eller under natten, hackades Kristdemokraterna Västerbotten (screenshot nedan) och tidningen Expo (även här läckte internt material). Expo säger sig i och för sig vara politiskt obundna men det är många som skulle hävda motsatsen så det ligger nära till hands att betrakta hacket som ett politiskt statement.

Chefredaktören på Expo, Daniel Poohl, intervjuades igår av Sydsvenskan. Hans svar är inte särskilt imponerande. Till en början blir det de vanliga svaren; "som der ser  ut nu har inget känsligt material från oss har lagts ut" (sic), att man är livrädd för att information om källor ska läcka ut och att man redan har en hög datasäkerhet. Inget annorlunda. Slutligen ställs dock frågan "Har ni någon särskild hotbild mot er just nu?" och svaret blir:

-Nej, det har vi inte.

Ursäkta, men wtf? Expo sysslar alltså med att "kartlägga högerextrema och rasistiska organisationer och nätverk i Sverige". It's right there! Han bekräftar till och med (för sig själv) att det finns många som verkligen ogillar vad de gör.

Det är väldigt ovanligt att organisationer och företag har särskilda hot, oftast består det av den stora, gråa massan med vardagshackers/script kiddies, botnätägare och möjligen, men ovanligen, konkurrenter. Politiska organisationer däremot, i synnerhet de som inte är mainstream, har uttalade fiender; motståndarsidan. Om man, dessutom, sysslar med att kartlägga sagd motståndare... Det är banne mig svårt att hitta en tydligare hotbild!

Det handlar inte om raketkirurgi. Om man har hot emot sig som är mer motiverade och organiserade än vardagshackers, då måste man helt enkelt ta hänsyn till detta i säkerhetsarbetet.

Det är pinsamt svagt av en organisation som verkar vara beroende av uppgiftslämnare, kanske till och med insiders, att inte ta det här på större allvar. Det kan vara så att riktigt känsliga uppgifter på Expo inte lagras digitalt överhuvudtaget men av chefredaktörens uttalanden att döma (och erfarenhet) så är det osannolikt.

Jag tror att vi kan börja räkna dagarna till att www.frihet.se defaceas. Deras hotbild har ökat markant.

--
Stefan Pettersson

En man från Beaverton har dömts för "computer crime" efter att ha klonat och använt andras presentkort. Ni vet, sådana där kontokortsformade magnetkort som står vid kassan på Åhléns, på SF Bio och på Bauhaus bland annat. Du tar ett kort, ger det till personen i kassan och berättar hur mycket pengar du vill ladda kortet med.

He wondered how gift cards worked, how the little magnetic strip on the back of them turned cash into store credit and how easily he could reproduce the information stored on the card.
[...]
After researching how gift cards work, Zepeda purchased a magnetic card reader online, began stealing blank gift cards, on display for purchase, from Fred Meyer and scanning them with his reader. He would then return some of the scanned cards to the store and wait for a computer program to alert him when the cards were activated and loaded with money.

Affären hade en tjänst på sin hemsida där man kunde slå in presentkortets serienummer och få reda på hur mycket pengar kortet var laddat med. Det här är en riktigt snitsig attack, även om den dömde genomförde det hela ganska slarvigt:

Fred Meyer Stores' fraud investigators detected that the cards had been tampered with when they saw that each card racked up hundreds of balance inquiries a day.

The average gift card user might check the card's balance online once in the card's lifetime, Hanada said, so this activity strongly suggested the work of a non-human inquirer.

Nu verkar det ju som att detta faktum, att tjänsten på webbsidan kontaktades onormalt ofta, upptäcktes först after-the-fact. Det hade ju annars varit ett bra exempel på anomaly detection. Detta hade han ju förstås kunnat undvika genom att vara lite mer tålmodig och bara kolla balansen någon gång per dag eller mer sällan.

Avslutningsvis:

"This is the first time I've ever seen it," [police detective] Hanada said. "This was really unique."

Nonsens, Johan Höglund (of Hamsterpaj fame) redogjorde för precis den här attacken för tre år sedan, då mot Åhléns. IDG, och till och med Aftonbladet, skrev om det.

--
Stefan Pettersson

Apache.org råkade ut för ett rätt allvarligt intrång förra veckan. Som ni kanske har märkt så gillar jag berättelser om sådant från real-life. Apache.org-bloggen har en write-up där hela förloppet beskrivs och John har en bra på svenska. Glöm inte att läsa bådas slutsatser.

Jag har inte så mycket att tillägga egentligen (därför stal jag Johns rubrik).

Dock. Komplicerade webbapplikationer som t ex JIRA, lider av ungefär samma problem med säkerhet som företagsnätverk gör; de är hårda på utsidan men mjuka och kladdiga på insidan. Så fort du tar dig in innanför brandväggen så är oftast spelet slut, det finns massor av svagheter att utnyttja (läs: attackytan ökar enormt). Samma sak gäller ofta med dessa, större webbapplikationer; så fort du tillskansar dig ett användarkonto (eller beroende på typ av applikation, ett administratörskonto) så ökar attackytan dramatiskt.

Det var precis det som hände i JIRA, en mindre allvarlig sårbarhet som cross-site scripting ledde till ett administratörskonto som gav tillgång till en betydligt allvarligare sårbarhet, köra godtycklig Javakod. Se figur 1 för illustration av analogi.

Figur 1. Före och efter inloggning.

--
Stefan Pettersson