IT-säkerhet enligt HPS

(Publicerad 2009-11-23)

En sårbarhet i Postkodslotteriets Tittarfråga har under en tid utnyttjats av ett fåtal personer för att vinna en massa pengar. Som vanligt är incitamenten dåligt anpassade.

Aftonbladet publicerade igår artikeln Proffsspelarna blåser tittarna om personer som använder särskilda strategier för att öka sina vinstchanser i Postkodlotteriets tittarfråga.

Tävlingen
Tittarfrågan är en, oftast väldigt enkel, fråga med fyra svarsalternativ som visas under varje program. Om du tror att du har rätt svar och vill tävla ringer du 099-313 30 och har du tur kommer du igenom slumpvalet och får svara på Tittarfrågan. Därefter kommer ytterligare tre frågor. Vinnaren är den som snabbast svarat rätt på de tre ytterligare frågorna. (Beskrivningen är hämtad från Aftonbladets artikel.)

Hur man vinner
Strategin för att vinna är enkel; när frågan visas ringer du tillräckligt mycket för att komma fram till de tre frågorna, kollar upp svaren med Google och memorerar dem. Därefter ringer du upprepade gånger och varje gång du kommer fram till frågorna svarar du så fort som möjligt, med bara tre frågor räcker det förmodligen med frågans första stavelse. (Man får anta att svarsalternativens ordning inte är slumpmässig.)

En mycket enkel och, uppenbarligen, effektiv strategi. Men, även om personerna inte bryter mot varken några lagar eller regler så kan nog de flesta vara överrens om att det inte är "fair play".

Varför är det så här då?
Vem drabbas av det här? Vanliga tittare; de som ringer en eller ett par gånger och hoppas på att ha tur. De har inte en chans när det finns strateger med i spelet. Vad kan jag som vanlig tittare göra åt saken då? Inget, möjligen kan jag bojkotta Postkodlotteriet eller hela TV 4 men det är bara naivt, gör inget för att förbättra läget och leder dessutom till att jag inte kan vara med i spelet jag ville spela från första början.

TV 4 då, lider de av det här på något sätt? Nej, inte alls, de har endast två avsikter med Tittarfrågan och det är att (1) få en del av de 9,90 kr som det kostar att ringa och att (2) få högre tittarsiffror (som i o f leder till inkomster på andra sätt). Om man gör det sannolika antagandet att de två strateger som verkar dominera vinnarlistan inte skulle spela alls om de inte kunde vara relativt säkra på att vinna så leder det bara till att TV 4 faktiskt tjänar mer pengar.

(I sammanhanget är det förmodligen bara en spottstyver. Trots detta verkar de agera för att mörka det hela genom att inte publicera namnen på vinnare. Detta behöver dock inte vara i vinstsyfte utan kanske för att slippa behöva designa om sitt kassa system.)

Det här är ett klockrent exempel på perveterade incitament; den part som har bäst möjlighet att göra något åt problemet är inte de som får lida för det.

Jag kan inte nog understryka hur viktig ovanstående paragraf är, om du vill läsa mer om problemet rekommenderar jag Ross Andersons sida om ekonomi och säkerhet.

Några (svagt genomtänkta) förslag på vad TV 4 skulle kunna göra för att avhjälpa problemet:

• Inför en obligatorisk betänketid på 5+n sekunder (där n är slumpmässig mellan 0 och 2 sekunder) efter att svarsalternativen lästs upp.
• Skippa modellen med tre statiska frågor och utnyttja istället den enorma bank med enkla och medelsvåra frågor som programmet borde ha tillgång till. Att läsa in frågorna borde vara ett mindre problem.
• Att slumpa fram ordningen på svarsalternativen är ingen självstående lösning på problemet och meningslös i samband med obligatorisk betänketid men kan säkert skydda mot andra attacker.
• Eventuellt skulle någon form av gräns på antal samtal eller samtal per tidsenhet införas men det ligger knappast i bolagets intresse.

När det säkerhetsproblem finns i system, ägna alltid en tanke på vem som får lida och vem som har bäst möjlighet att skydda systemet. Det är sällan samma person.

--
Stefan Pettersson

(Publicerad 2009-11-20)

Network World har nyss släppt artikeln 3 Basic Steps to Avoid Joining a Botnet, tipsen är som följer (fritt översatt):

1. Patcha systemet och håll antivirusprogrammet uppdaterat.
2. Använd de senaste versionerna av webbläsare.
3. Var lite mer försiktig när du får länkar eller bifogade filer.

Det finns tusen liknande artiklar (vi är skyldiga till ett par). Efter att ha läst den i Network World undrar jag om det inte är nyttigt att göra motsatsen, det borde åtminstone visa på hur lätt det kan vara att trilla dit.

Så, tre grundläggande steg för att hamna i ett botnät:

1. Installera Windows XP, skippa gärna ett servicepack för bättre effekt men det är inte nödvändigt.
2. Installera massor av program, som minst följande; Quicktime, Adobe Acrobat, Adobe Flash, WinAmp, RealPlayer, Java RE och Microsoft Office.
3. Öppna Internet Explorer 6 och ge dig ut och surfa som vanligt. Det kanske tar tio minuter, det kanske tar fyra månader, men snart så är du med i botgänget.

Men, säger många, det där låter som min kompis dator. Ja men sen finns det ju väldigt många, väldigt stora botnät också, någons dator måste ju ingå i dem.

Trevlig helg i alla fall!

--
Stefan Pettersson

(Publicerad 2009-11-18)

Säkerhetsforskarlaget på Cambridge har värpt ännu ett guldägg.

Tillsammans med en av personerna bakom den brittiska TV-serien The Real Hustle ("Syna bluffen" i svensk TV) har Frank Stajano författat rapporten Understanding scam vicitims: seven principles for systems security (pdf).

Sammanfattningen av rapporten lyder:

The success of many attacks on computer systems can be traced back to the security engineers not understanding the psychology of the system users they meant to protect. We examine a variety of scams and “short cons” that were investigated, documented and recreated for the BBC TV programme The Real Hustle and we extract from them some general principles about the recurring behavioural patterns of victims that hustlers have learnt to exploit.

Rapporten tar bland annat upp det klassiska "spelet" Monte (Youtube-film) som t ex förekommer på Drottninggatan utanför riksdagshuset. Denna och ett gäng andra bedrägerier beskrivs och i rapportens andra halva kopplas sju principer som bedragarna använder för att kunna blåsa sina offer. De sju principerna är som följer:

1. The Distraction principle
Medan du är distraherad av vad som intresserar dig kan bedragare göra vad de vill mot dig och du kommer inte att märka det.

2. The Social Compliance principle
Samhället tränar personer till att inte ifrågasätta auktoriteter. Bedragare utnyttjar denna "minskning av misstänksamhet" för att få dig att göra som de vill.

3. The Herd principle
Även misstänksamma offer sänker guarden när alla andra i närheten verkar dela samma risker. Säker i flocken? Inte om alla konspirerar emot dig.

4. The Dishonesty principle
Allt illegalt du gör kommer att användas emot dig av bedragaren vilket gör det svårare för dig att söka hjälp från myndigheterna när du inser att du blivit lurad.

5. The Deception principle
Saker och personer är inte alltid vad de verkar vara. Bedragare vet hur de ska manipulera dig att tro att de verkligen är det.

6. The Need and Greed principle
Dina behov och önskningar gör dig sårbar. Så snart en bedragare vet vad du verkligen vill ha kan de enkelt manipulera dig.

7. The Time principle
När du ska fatta ett viktigt beslut under tidspress använder du en annorlunda beslutsstrategi. Bedragare styr dig mot en strategi som involverar mindre resonemang.

Stefan och Armanijackorna
Minns ni Stefan? Han som köpte tre skinnjackor av en "Italienare" på en bensinmack och insåg (med frugans hjälp) att de var (rejält dåliga) piratkopior först efter att han betalat 2 000 spänn för dem.

I det fallet utnyttjade bedragaren främst "The Need and Greed principle"; Stefan sade ju själv att han "blev bara begeistrad av att få så mycket märkesgrejor för så lite". Vidare gjorde jag antagandet att det hela gjordes under viss tidspress för att Stefan skulle ha begränsat med tid för att autentisera jackorna, ringa frugan, etc. Alltså "The Time principle". Naturligtvis passar också "The Deception principle".

Dessutom skulle man kunna applicera "The Dishonesty principle". Även om Stefan inte gör sig skyldig till ett brott i Sverige (i Italien hade det inneburit rejäla böter) så är det förstås inte helt kosher att köpa svindyra jackor billigt vid bensinmackar mitt i natten.

Uppdatering @ 13:24
Om det är något man ska ta med sig från rapporten så är det:
[...] it is naive and pointless just to lay the blame on the users and whinge that "the system I designed would be secure if only users were less gullible"; instead, the successful security designer seeking a robust solution will acknowledge the existence of these vulnerabilities as an unavoidable consequence of human nature and will actively build safeguards that prevent their exploitation.

--
Stefan Pettersson

(Publicerad 2009-11-06)

I veckan höll .SE sin stora, årliga konferens Internetdagarna på Folkets hus i Stockholm. En workshop hölls under rubriken "Measuring the health of the Internet".

Jag var inbjuden för att delta i rundbords-diskussionen om att mäta säkerhet. Ett sjukt svårt ämne, tyvärr. Man kan säga att forskningen på området till stor del drivs av Dan Geer. En ärrad veteran som var med under Project Athena och (bland annat) är känd för att ha sparkats från @stake efter att ha kritiserat deras största kund; Microsoft. Rapporten som resulterade i avskedet, en intervju av Gary McGraw.

I en presentation berättar Geer om hur han konfronterades med en Chief Information Security Officer från en stor Wall Street-bank. CISO:n sade "Är ni säkerhetsfolk så korkade att ni inte kan berätta för mig...":

• Hur säker jag är?
• Om jag har det bättre i år än vid samma tid förra året?
• Om jag spenderar rätt mängd pengar på säkerhet?
• Hur jag har det i jämförelse med andra i branschen?

"Om jag hade varit på någon annan avdelning på banken, obligationsportföljer, aktiehandelsstrategier eller prissättning av derivat så hade jag kunnat besvara frågorna med fem decimalers nogrannhet."

Det är svårt att mäta säkerhet. Alla är överens om att det vore väldigt bra att kunna göra det. Det skulle leda till att vi kan kontrollera hur mycket säkerhet vi får för en viss peng, det skulle vara möjligt att kontrollera om säkerheten har blivit bättre eller sämre efter en förändring, det skulle vara en barnlek att jämföra olika system och så vidare. Framförallt; om vi kan mäta så kan vi sätta en gräns för vilken säkerhet som är tillräckligt bra och hålla oss till den. Som (svenska) kunder alltid säger; vi vill inte ha fullständig säkerhet, vi är ingen bank, vi vill ha lagom.

Mätning kräver en mätenhet och en kvantitet av detta så frågan är egentligen; vilken mätenhet ska vi använda?

Tyvärr går det inte att jämföra med att räkna pengar, mäta avstånd, väga vikter eller andra, konkreta mätningar. Säkerhet är oerhört komplext och abstrakt, det finns ingen naturlig enhet.

Vi sänker ambitionsnivån lite. Vi fokuserar på mindre system, inte en hel Bank utan kanske en applikation.

Den populäraste enheten är utan tvekan "antal upptäckta sårbarheter". Den användes till exempel av Microsoft under 2007 för att påvisa att Internet Explorer var säkrare än Firefox (pdf). Microsofts rapport möttes av en del kritik...

Tyvärr är enheten "antal upptäckta sårbarheter" pinsamt ofullständig. Många frågor väcks genast:

• Hur många letade?
• Hur länge letade de?
• Hur duktiga var de?
• Hur stort är systemet?
• Hur komplext är systemet?
• Var slutar systemet?
• Hur allvarliga var sårbarheterna?
• Hur svåra är sårbarheterna att utnyttja?
• Under hur lång tid gick de att utnyttja?
• Kommer nya sårbarheter att introduceras? Vad gäller för dessa?
• ...

Om vi ska ta hänsyn till dessa och alla andra faktorer som spelar in kommer vi att få en rejält komplicerad enhet i knäet. Med all sannolikhet kommer vi aldrig komma till den punkten eftersom det i princip är omöjligt att bestämma relationen mellan alla dessa faktorer. Man skulle lugnt kunna säga att fåniga enheter i stil med newton-ampere-sekunder-per-kilogram-kvadratmeter skulle kännas fullständigt naturliga i jämförelse...

Vi backar och förenklar ytterligare en aning. Kan vi mäta enskilda säkerhetshål?

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å detta är Common Vulnerability Scoring System (CVSS). CVSS används för att värdera hur allvarlig en sårbarhet är genom att göra en beräkning utifrån 14 värden fördelade i tre grupper. Varje värde är diskret, det finns mellan fyra och fem alternativ för varje.  Resultatet efter beräkningen av CVSS är ett värde mellan 0 och 10 och en "CVSS-vektor" som beskriver varje delvärde.

Jag rundar av det här innan det svävar iväg för lå(n)gt. Området är svårt och, åtminstone jag, känner att det verkar rätt hopplöst. Lyckligtvis är det inte såna som jag som arbetar med det. Jag kommer att fortsätta på ämnet en uppföljande post.

Trevlig helg!

--
Stefan Pettersson

(Publicerad 2009-10-30)

Igår fick vi se två DDoS-angrepp mot dels Basefarm (vilket drabbade media), men också mot Polisen. Människor har en förväntan om att offentlig verksamhet med stora behov av säkerhet också har det, men i praktiken är nog denna offentlig verksamhet snarare sämre skyddad än privat.

Ämnet är bekant för bloggens följare sedan tidigare. Vi har under flera år levt med en undermåligt skyddad offentlig verksamhet. Uppbyggnaden som finns i Sverige bygger på att myndigheterna själva visar intresse av att ta till sig information från bl.a. SITIC. Men det finns ingen kravställning och konsekvenserna uteblir när revision efter revision visar hur säkerheten brister.

DDoS-angrepp har exempelvis onlinespelsbranschen dragits med i flera år och vet hur man hanterar. Men först nu ombeds myndigheten för samhällsberedskap att ta fram planer för hur IT-incidenter ska förebyggas och hanteras.

Här är något jag går i borgen för
Oavsett hur många utredningar man tillsätter kommer det aldrig bli bra förrän man utkräver ansvar. Informationssäkerheten behöver införas som något man bedömer verksamhetsresultatet på, från minister och neråt. En generaldirektör skall veta att om riksrevisionens granskning visar skit, så sitter han/hon löst.

Att man har SITIC och MSB som hjälper, koordinerar och skapar planer har naturligtvis ett värde, men det finns för många system där ute för att förlita sig på välvilja och reaktivt arbete. Utkräv ansvar från höga positioner - först då kommer allmänhetens förväntningar på IT-säkerhet infrias.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-10-27)

FBI har nu i dagarna gjort något så unikt som att gått ut med siffror på hur mycket cyberbrottslingar stulit från amerikanska företag de senaste åren. Det är inte något säkerhetsbolags uppskattningar av värdet på information, utan rena dollar som har lämnat bankkonton.

I Sverige var det för några år sedan mycket uppmärksamhet kring hur cyberbrottslingar stal pengar från Nordea-kunder. Tillvägagångssättet var phishing-mail där man stal engångskoder, och sedan använde dessa för att logga in på offrens konton och föra över pengar till andra konton. Den exakta summan av förluster offentliggjordes aldrig, men minst tvåsiffrigt antal miljoner kronor försvann.

Att Nordea drabbades på det sättet var på grund av att man var en stor bank och att Nordeas "skraplotter" var enklare att angripa än konkurrerande storbankers koddosor.

Företag drabbas också
Men nu har alltså FBI offentliggjort siffror som visar hur mycket amerikanska små och medelstora företag har förlorat genom liknande överföringar. Det har försökts stjälas $85M (cirka 575 miljoner kronor), och tjuvarna har kommit undan med strax under hälften - $40M (cirka 270 miljoner kronor).

Transaktionerna har gjorts med tillräckligt små summor för att det inte ska väcka någon misstänksamhet eller utlösa bankerna automatiska larm.

Trender
... och att det här hände var naturligtvis förutsägbart. Pengar lockar, och man tar enklaste vägen. Det finns två trender som är viktiga att notera från det här:

• Cyberbrottslingar ger sig på att stjäla även från företag. Företag har ofta mer pengar än privatpersoner, så det faller naturligt att de förr eller senare blir utsatta.
• Koddosor är inte tillräckligt skydd längre. Även om många av de utsatta företagen hade konton som bara krävde användarnamn och lösenord så har även de som använt koddosor blivit utsatta.

Det sistnämnda sker troligen genom "man in the browser"-angrepp, där en legitim session används för att göra transaktionerna.

Inom säkerhetsvärlden är det här ett känt ämne. Exempelvis bloggade Stefan om det förra månaden här på vår blogg, och även i maj, då på OWASP Sweden-bloggen.

Vad kan jag som kund göra?
Vad rekommenderar då vi från HPS att man kan göra om man vill fortsätta använda banker online och samtidigt minska risken. Här är några konkreta råd:

• Datorn som används för ekonomiska transaktioner skall används enbart till det. Ingen mail, inget surfande utanför bankerna.
• Datorn ska inte vara med i företagets "domän". Tvärtom bör den stå så isolerad som möjligt, och med bra lösenord.

Svenska bankers utsatthet och vad banken kan göra
Här i Sverige har exempelvis Swedbank och SEB har gjort mycket av vad som är rimligt att göra. Nämligen att använda koddosor och när man signerar transaktion så matar man in totalsumman i dosan. Hos Länsförsäkringar gör man inte det, men där kontrolleras å andra sidan applikationsflödet väldigt strikt. För mer tips för vad man kan göra rekommenderar jag att läsa Continuing Business with Malware Infected Customers.

Att ta sig runt applikationsflödet är dock ingen gigantisk utmaning - "utloggning" blir "inloggning" för angriparen.

Att signera transaktionen med summan är bra. Men då måste kunderna veta om att det är vad som händer, och vara vaksamma att summan stämmer. Har din bank det systemet är det alltså något du behöver se till att vara vaksam på. Till skillnad från hur privatpersoner blivit ersatta för sina förluster är det relativt ovanligt att företag blir det

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-10-16)

Tillbaka från Sundsvalls årliga konferens Sundsvall 42. Materialet online.

Mitt bidrag Murphys onda tvilling finns att ladda ner här (pdf). Presentationen finns att kolla online på Prezi.

Presentationen ingick i utvecklings-tracket (B.6, 10:00-10:40 på torsdagen) och fokuserade på sju stycken fundamentala principer för hur säkra system ska designas:

• Minimize attack surface.
• Don't mix code and data.
• Security features != secure features.
• Fail safe.
• Minimize feedback.
• Use least privilege.
• Never trust external systems.

Trevlig helg!

--
Stefan Pettersson

(Publicerad 2009-10-08)

Frankrikes nationella underrättelsetjänst tycks anse att det är en bra idé att införa helkroppsröntgen på flygplatser. Detta sedan det för nån månad sedan skett ett mordförsök med en ”rumpbomb”. Men de kan väl aldrig mena allvar?

Efter ett mordförsök med en "rumpbomb" får vi nu alltså se hur långt gångna förslagen kan vara. Att införa helkroppsröntgen är väl förvisso att föredra framför fullständiga kroppsbesiktning i det här fallet, men är de verkligen seriösa med förslaget?

I augusti var "Feed Over E-mail" en världsnyhet. Jag bloggade om det, och P3 Nyheter intervjuade mig. Min ståndpunkt var kort att det handlade snarare om politik än något som skulle kunna göra en praktisk skillnad för den stora massan.

Liknande tror jag det är med den här storyn. Det *kan* bara inte vara så att fransmännens underrättelsetjänst är så dumma. Bruce Schneier sammanfattade argumenten mot idén redan innan den kommit ut:

1. Man får inte plats med så mycket sprängmedel, så det kan inte bli någon stor detonation
2. Att detonera en sådan bomb är problematiskt
3. Den mänskliga kroppen kommer ta upp en stor del av explosionen (tänk på någon som slänger sig över en granat för att rädda sina kompisar)

Utan att gå in närmre på det så hävdar jag att det helt enkelt är en vansinnig ekvation att införa helkroppsscanners för en sådan här sak. Och det är väl klart att fransmännen förstår det! Även om vi fått se prov på att underrättelsetjänster inte är så smart som man skulle tro, så finns det ändå gränser. Så vilka är de verkliga motiven?

Jag har ett förslag: En sidoeffekt från röntgen här vore att man skulle se alla som försöker smuggla knark genom att svälja en större mängd små ”gummibollar”, var och en med bara några gram knark. Det är i praktiken ett långt större problem än människor som stoppar upp sprängmedel. Betydligt vanligare förekommande.Och vad är enklast att få folk att acceptera: att de ska bli kränkta i jakten på knark - något som är långt borta från Svensson-vardagen - eller att de ska bli skyddade från att bli sprängda i luften?

Edit: Det kan förstås också vara ytterligare ett exempel av Cover Your Ass (pun intended),  att de helt enkelt inte är seriösa med förslaget utan mest vill ha något att visa på om något nånsin skulle hända som hade kunnat upptäckas med en helkroppsröntgen.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-10-07)

Mozilla har börjat införa content security policy (CSP) i webbläsaren Firefox. CSP ger utvecklare möjlighet att skydda sina besökare mot cross-site scripting.

John Wilander (Omegapoint/OWASP Sweden) pratade om vitlistning av script med Computer Sweden i våras och gissade där att Mozilla skulle vara först ut med en lösning. I somras visade det sig att han verkade ha rätt och nu är CSP på väg att rullas ut med Firefox.

Hur det fungerar
Beskrivningen som ges i dagens TechWorld är en bra analogi. Det handlar om en innehållsdeklaration. När webbläsaren kontaktar en webbserver och hämtar en sida fås också en lista på vilka script som ska ingå:

Vi har det här scriptet för att styra vårt menysystem, vi har det här scriptet för att hålla koll på besökarantal och dessutom det här för att anpassa sidan efter din webbläsare. Det är allt.

Anta att samma sida har en sårbarhet där andra besökare kan injicera javascript i innehållet t ex via en kommentarfunktion på en blogg. Trots att en av kommentarerna innehåller javascript så kommer webbläsaren inte att köra det eftersom det inte finns med i innehållsdeklarationen. Läs mer om specifikationen här.

Content security policy ger alltså webbutvecklare möjlighet att skydda sina besökare mot cross-site scripting. I detta inkluderas alla attacker som resulterar i att script injiceras i sidor, även om det sker via t ex SQL injection vilket har varit ganska vanligt.

Överkurs
Säkerheten vilar på att en angripare inte kan modifiera innehållsdeklarationen i samband med att script injiceras i sidan. Det är ett godtagbart antagande. Om en angripare har möjlighet att ändra innehållsdeklarationen d v s HTTP-headers på vägen från servern till klienten eller direkt på servern så är cross-site scripting ett av dina mindre problem.

Det här betyder inte att det är dags att göra sig av med NoScript riktigt än. Skyddet ligger i utvecklarnas händer men attacken det skyddar mot är riktat mot besökaren.

--
Stefan Pettersson

(Publicerad 2009-09-23)

Under konferensen i Polen i maj i år bloggade jag om hur bankernas tvåfaktorsautentisering borde göras. Schneier är lite bättre på att förklara...

Allas vår Bruce bloggade igår om Hacking Two-Factor Authentication och pratar specifikt om bankernas användning av tvåfaktorsautentisering. Det centrala budskapet är:

We have to stop trying to authenticate the person; instead, we need to authenticate the transaction.

Det är precis det här jag pratade om på OWASP Swedens blogg (även om jag inte var tillräckligt skärpt för att få ur mig frasen i rubriken ovan) som vi gästade under konferenserna i Polen i våras.

[...] Om alla tre värden ingår i checksumman (från, till, summa) och det framgår tydligt i bankdosan vad det är du fyller i så att det står "Mottagarkonto:" istället för "SÄKKOD #3" eller liknande (som i dagens) blir det svårare att lura en användare. Man ska märka att man gör fel "hey, det här är inte min mammas kontonummer". Det är en större tröskel att slå in den där "verifieringskoden" när det står "Mottagarkonto:" på dosan.

Det är svårt att prata om sådana här saker på ett koncist och förståeligt sätt. Bruce är en av de bästa på det. Om du inte har sett honom tala tidigare och har en timme över, kolla in The Future of the Security Industry: IT is Rapidly Becoming a Commodity från OWASP Minneapolis den 24 augusti.

--
Stefan Pettersson

(Publicerad 2009-09-18)

Sam Sundberg på SvD nöje har skrivit en kolumn om att Lisbeth Salander är osannolik av flera anledningar, bland annat för att hon väljer att köra Mac.

Artikeln Datorn sabbar pusslet Salander publicerades 17:12 igår (torsdags) kväll. Tidigt i morse var den redan uppe i 300 kommentarer från upprörda Mac-användare som kände sig angripna.

I stora drag tar artikeln upp två punkter:

Lisbeth Salander är tillbaka på vita duken, och med henne en av de mest osannolika fiktiva hackers som någonsin skapats. Konkurrensen är i och för sig hård. Medan verkliga hackers brukar se ut ungefär som Gottfrid Svartholm Warg spelas filmhackers av Sandra Bullock (The Net), Angelina Jolie (Hackers), Carrie- Anne Moss (The Matrix) och Keanu Reeves (The Matrix).

och

Problemet är bara Salanders datorpreferenser. Att se en elithacker sitta och knappa på en Mac är som att se Dirty Harry dödshota småtjuvar med en vattenpistol istället för en Smith & Wesson. Macar är inte datorer för hackers, det är datorer för författare, formgivare, mediepajsare och andra figurer som föredrar teknik med minimalt motstånd framför teknik med maximala möjligheter.

Gissningsvis är det den andra passagen som har bidragit till den uppretade stämningen bland SvD:s kommentarer.

Så, herr Sundberg har två postulat: riktiga hackers ser ut som Gottfrid Svartholm Warg och de använder inte Mac.

Well allow me to retort...

För er referens; Gottfrid himself. Andra kända "hackers" i sammanhanget är till exempel David Litchfield, Joanna Rutkowska (längst till vänster), Robert "rsnake" Hansen eller den här trion där killen i mitten är Samy som sänkte MySpace under 2005 (rekommenderad läsning).

Ser väl rätt normala ut?

Apple Macintosh då? Ptjaa... Googlehackern Johnny Long, naturligtvis Mac-hackarna Dino Dai Zovi och Charlie Miller (som jag har nämnt tidigare) eller kanske Bruce Potter, frontfiguren i Shmoo group.

Bekännelse: Själv är jag inte en Mac-användare, har inte ens en iPod eller -Phone. Däremot kan det väl hända att elakheter om Mac-användade kollegor slinker ur mig... Men det är bara för att Mac-användare är så lättstötta. Med all sannolikhet var det därför Sam publicerade sin artikel.

QED och trevlig helg!

--
Stefan och SÄK på HPS

(Publicerad 2009-09-16)

Snow Leopard är nysläppt. Charlie Miller är tillbaka och klagar över att Apple inte har implementerat skydd mot att säkerhetshål utnyttjas.

I en tidigare bloggpost från i våras hänvisade jag till en intervju med Charlie Miller där han hävdar att det är mycket enklare att utnyttja säkerhetshål i OS X jämfört med t ex Vista. Det visar sig att det är samma visa igen med Snow Leopard enligt en artikel i MacWorld.

Alexander Sotriov från Determina (nu VMware) gjorde en matris som beskriver vilka operativsystem som har vilka säkerhetsfunktioner. Den visar tydligt att det finns fler anledningar än Aero att uppgradera till Vista eller Windows 7...

--
Stefan Pettersson

(Publicerad 2009-09-03)

Det brittiska parlamentet råkade nyligen ut för ett angrepp. En rumänsk cracker stal via SQL Injection inloggningsuppgifter som var lagrade i klartext. Incidenten betonade vidare administrativa brister då hålet inte stängdes förrän The Register gått ut med en artikel där hålet öppet pekades ut.

The Registers artikel är ovanlig i det att det varken tidningar eller säkerhetsforskare sällan går ut med så detaljerad information om sårbarheter som ännu inte är patchade. Så vad fick The Register att göra något sådant? Svaret finns i artikeln - det hade redan skickats minst 4 meddelanden under loppet av 48 timmar utan någon som helst respons. Därmed kommer lite extra betoning på de administrativa brister som låg bakom den här incidenten. Några lärdomar man kan dra:

• SQL Injection är en välkänd sårbarhet, den hade troligen hittats om man gjort ens grundläggande säkerhetstestning. Lärdom: lägg ett minimum vid att säkerhetstesta applikationerna. Diskutera gärna med applikationsleverantörerna om säker utveckling.
• Lösenord skall inte lagras i klartext. Endast en saltad hash av den skall lagras.
• När någon söker kontakt för att rapportera en säkerhetsbrist måste det vara klart och tydligt vem som skall vara mottagare för informationen.
• En informationsmottagare behöver ge säkerhetsrapporter högsta prioritering. Bedöms det senare som mindre riskabelt kan man prioritera ner. Default måste dock vara högsta prioritering.

Som salt i såren visade det sig sedan att lösenorden var av sådan usel kvalitet att till och med namnet på en superhjälte stack ut som bra. Det passar naturligtvis också väl in i mönstret kring hela incidenten, nämligen att IT-säkerheten var usel.

Brittiska myndigheter har tidigare visat sig vara ovanligt usla på IT-säkerhet. I maj bloggade jag om hur Mi6 - en organisation som borde vara van vid att hantera topphemligt material - tappade bort ett okrypterat USB-minne och därmed riskerade livet på ett antal "under cover"-agenter och man fick ställa in antidrogoperationen man höll på med.

Nu ska vi inte tro att britterna är ensamma, vi har ju sett liknande exempel bland svenska politiker och myndigheter. Två exempel på detta är SAPnet-skandalen och Riksrevisionens rapport från 2007 där slutsaten var just att regeringen inte kontrollerade IT-säkerheten tillräckligt.

Tyvärr saknar Sverige ännu någon vettig styrning från regeringsnivå som kan åtgärda detta. Föregångarna heter istället USA, även det bloggade jag om tidigare i år, då Obama satte upp informationssäkerhet på home land security's agenda.

När Sverige kan tänkas åstadkomma något vettigt här? Vi får väl se om något parti tar med det i sitt program inför nästa val...

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-08-28)

I förra delen lades ett påstående fram. Att man genom att skydda sig mot interna brottslingar automatiskt kan skydda sig mot inkompetens. Hur kommer det sig?

Som av en händelse blev ämnet på tapeten när landstingets granskning av hur sjukhusen i Skåne drabbades av Conficker i våras publicerades. CS skriver "Slarv bakom virusangreppet i Skåne":

Det står klart att dåligt uppdaterade Windowsdatorer bär en del av skulden till att den skadliga koden kunde sprida sig så snabbt och till så stora delar av sjukvårdens it-system. En säkerhetsuppdatering som Microsoft släppte i oktober 2008 saknades på minst 1 000 datorer. Just den säkerhetslucka som åtgärdas med uppdateringen är en av dem som masken Conficker utnyttjar för att infektera fler maskiner på nätverket.

Hur som helst, förra posten avslutades med följande påstående:

Skydd implementerade för att motverka elakingar motverkar generellt också klantar. Dock inte nödvändigtvis tvärtom.

Påståendet är lätt att ta till sig när man inser att elakingen kan välja att ignorera bestämmelser och försöka gå förbi skydd. En varningsskylt vid utgången som säger "Du har väl inte känslig data med dig hem?" leder sannolikt till att färre råkar få med sig data hem. (Givetvis gäller detta bara fram till att alla har vant sig vid skylten och inte ser den längre eller slutar bry sig för att det uppfattas som en dum regel.) Samma sak gäller för bensinmackar på landet som lånar ut toalettnyckeln på en nyckelring i form av en 30 cm lång två-tum-fyra så att den inte ska glömmas kvar i fickan.

Man behöver inte ens gå in på i vilken utsträckning skylten och nyckelringen hindrar elakingar...

(Här skulle man kunna dra en tydlig parallell till säkerhetskontroller som är implementerade på klientsidan. Vi skippar det.)

Vad kan göra för att skydda sig mot elakingar på riktigt då? Och, framför allt, påverkar det samtidigt klantarna? (Detta är inte nödvändigtvis en uttömmande lista.)

Minimera möjligheter till insiderbrott:

1. Betro bara personer du tror att du kan lita på.
2. Betro så få personer som möjligt.
3. Betro varje person så lite som möjligt.
4. Tillse att personer har överlappande ansvar.
5. Betala betrodda personer väl.
6. Straffa brott mot förtroendet och var öppen med det.

(Punkterna ovan är inspirerade av tankar från Bruce Schneier och Ross Anderson, något anpassad för svenska förhållanden.)

Det är självklart att ovanstående är riktat mot eventuella elakingar men hur påverkar det klantarna?

(1) På samma sätt som du känner att du kan lita på att grannen inte stjäl din post när hon vattnar dina blommor under semestern kan du eventuellt också lita på att hon inte glömmer att låsa dörren efter sig. En semestervattnare bör ha båda kvaliteter. Om du inte har en egen uppfattning kan du exempelvis kontrollera med andra grannar som du litar på vad de har för uppfattning (jfr bakgrundskontroll).

(2) Ju färre som har tillgång till känslig information, desto färre kan sprida den av misstag.

(3) Ju mindre information som är tillgänglig för personen, desto mindre värde kan förloras.

(4) Här avses överlappande ansvar som att det krävs två eller fler personer för att genomföra något, även att klanta sig. På samma sätt som två semestervattnare kan kontrollera varandra så att de inte stjäl posten kan de påminna varandra om att stänga balkongen efter sig.

(5 och 6) Båda handlar om att ge personen mer att förlora, det kommer naturligt att personer aktivt undviker detta. Dessa två är förmodligen de som är minst effektiva mot klantarna.

Där har ni det. Huruvida man borde öppet, straffa systemadministratörer som inte patchar 1 000 Windowsdatorer mot ett nästan två månader gammalt säkerhetshål som är lätt att utnyttja är dock en helt annan fråga.

--
Stefan Pettersson

(Publicerad 2009-08-26)

RSA har beställt en undersökning från IDC som tittar på insiderbrott. Resultaten är inte överraskande men intressanta.

BBC och The Register har artiklar om rapporten. Det mest intressanta resultatet är att 52 % av de incidenter ett företags egen personal står för beror på misstag medan endast 19 % görs med avsikt. (Ingen av artiklarna nämner de återstående procenten och originalrapporten står ej att finna.) Det här förstås smaskens. Än en gång (se Verizons 2009 Data Breach Investigations Report) visar det sig att insiderbrott inte är så vanligt som det sägs.

Resultatet är ganska lätt att acceptera; hur många på din avdelning tror du är kapabla (för någon definition på kapabla) till att stjäla känslig information och sprida jämfört med att sumpa ett USB-minne med samma data på tunnelbanan?

Det är ett vanligt misstag att överdriva sensationella hot (en rysk spion på säljavdelningen) och bagatellisera alldagliga (en slarvpelle på ekonomiavdelningen). Därför är det bra att problemet lyfts.

Så, hur skyddar man sig mot sina kollegor? Om vi delar in alla kollegor i två kategorier; elaka kollegor och klantiga kollegor. De flesta av oss kommer att (som tur är) tilldelas epitetet klantig. Ett intressant förhållande råder mellan elakingar och klantar:

Skydd implementerade för att motverka elakingar motverkar generellt också klantar. Dock inte nödvändigtvis tvärtom.

Jag tänkte återkomma till hur detta kommer sig i en senare post eftersom att jag har lovat mig själv att skriva kortare inlägg...

Avslutningsvis skriver The Register i artikeln:

IDC concludes that organisations ought to apply a comprehensive risk management-based approach to information security, rather than firefighting security problems.

Nähä?

(Se nästa del.)

--
Stefan Pettersson

(Publicerad 2009-08-14)

De senaste dagarna har det förekommit notiser om att USA håller på att testa programvara för att komma runt den webbcensur som finns i bland annat Kina och Iran. Enligt uppgift är Google, Yahoo och Microsoft med i satsningen. Men vad väntar man sig egentligen åstadkomma?

Enligt Reuters så heter det nya systemet "Feed Over E-mail" och en sida på Google Code antyder att systemet kommer använda sig av SMTP och POP3 som protokoll. Om nyheten är sann (det finns inga pressmeddelanden om det på Broadcasting Board of Governors hemsida, vilket är byrån sägs ligga bakom projektet) så är frågan vad man egentligen förväntar sig uppnå med det.

Skulle en sådan tjänst slå igenom är det högst osannolikt att den ignoreras av censurregimerna. Det innebär inte direkt några stora tekniska utmaningar att istället för att göra pattern matching på webbsidor istället göra det på e-post.

Finns det då något som kan göras för att vanlig pattern matching inte ska fungera? Koda eller kryptera informationen på något sätt? Även om så vore fallet så ska det ut till en stor del av befolkningen och då kommer sättet det kodas på bli allmänt känt och på ena eller andra sättet skulle man kunna hitta även dessa meddelanden.

I grunden är det här en katt-och-råtta-lek. Och kommer alltid att förbli:

• En stat kommer aldrig kunna hindra *alla* från att nå vissa sajter - det kommer alltid gå att komma runt det genom olika typer av tunnlar och proxies med diverse kryptering.
• Samtidigt kommer aldrig alla kunna kringgå skydden - data måste i slutändan hamna hos användaren och vet alla om hur den kan erhållas i klartext så kan staten göra detsamma längs vägen och göra bedömningar utifrån det. Enda sättet vi idag känner till att komma runt något sådant är genom asymmetrisk kryptering. Men en stat har inga problem att genomföra man in the middle attacker - det enda man kan göra mot dem är att upptäcka dem och staten bryr sig föga om att bli "upptäckt" som de som spionerar på trafiken - alla vet ändå om det.

Några alternativ vi här uppe i skrapan ser som mer rimliga är:

• Det är ett rent politiskt utspel
• Ken Berman har missuppfattat något
• Syftet med programmet har missuppfattats av media och oss andra
• Det är en distraktion för att dölja något annat [konspirationsteori ftw]

Ett femte alternativ är de helt enkelt är så vansinnigt okunniga och ignoranta att de tror att det gör någon skillnad.

Ett sjätte alternativ är att det är något ruskigt innovativt som slår världen med häpnad. Eller i vart fall mig.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-07-07)

Twitter har haft sin beskärda del av angrepp, i synnerhet är det deras lite mer kända kunder som Britney och Obama som har fått smaka. Hur kommer det sig att Twitter är såpass utsatt?

Man kan koka ner det till två huvudanledningar. Först och främst är de störst inom "mikrobloggande". De har ett antal konkurrenter men är tveklöst störst. Sånt drar till sig intresse från diverse mindre nogräknade individer.

Vad som är mer intressant är Twitters autentisering och min käpphäst förtroende.


Ponera att någon du verkligen inte tycker om har konto på Twitter och att du vill vara elak mot denna person genom att posta i deras namn. Om du inte kan hitta en sårbarhet i Twitters sidor eller API (vilket vi kan anta är svårt) behöver du personens lösenord.

Att gissa ett lösenord som tillhör någon användare, vemsomhelst, på Twitter skulle vara störtenkelt. (1) Sammanställ en lista på en 500 aktiva kontonamn. (2) Testa att logga in med ett par lösenord på varje; t ex 123456, twitter1 och användarnamnet. (3) En eller flera konton kommer sannolikt att bära frukt.

Det är sannolikt svårare att gissa rätt lösenord om du riktar in dig på ett specifikt konto. Det har förstås gjorts tidigare dock när en admin visade sig ha "happiness" som lösenord, det resulterade i att ett gäng kändisar gjorde löjliga uttalanden.

Så... vi kan inte gissa lösenordet och vi hittar ingen sårbarhet på twitter.com. Är vi körda? Å nej...

För användare är Twitter inte en applikation, det är en hel uppsjö av applikationer som alla löser olika uppgifter. Om du till exempel vill kunna twittra upp ett foto kan du använda Twitpic, vill du twittra genom att helt enkelt skicka ett mail kan du göra det via Twittermail. Dessa applikationer drivs inte av Twitter utan drivs helt av olika tredjeparter.

Det finns jättemånga liknande tjänster.

Okej, Twittermail ger dig en mailadress, säg [email protected], och om du skickar ett kort mail dit dyker det upp som ett inlägg på ditt konto på twitter.com. Hur går det till? Ja, Twittermail måste ju kunna logga in i ditt ställe så de behöver ditt lösenord sparat och det är precis vad de har. I klartext! Ergo, provkör en tredjepartsapplikation en gång och vips så har de ditt lösenord tills du byter det. Det är ett stort förtroende man ger dem.

Plötsligt ökar våra chanser att få tag i en persons lösenord markant! Vi kan nu sikta in oss på någon av de tredjepartsapplikationer personen använder också.

För någon vecka sedan åkte Britney på en liknande attack när någon kom på att det inte fanns någon gräns på hur många gissningsförsök man fick göra på att gissa den hemliga, fyrsiffriga PIN-koden som används för att maila in foton till Twitpic. Jag kan tänka mig att Britneys stab har bra kontakt med Twitter vid det här laget...

Det finns ett bättre sätt för tredjepartsapplikationer än att låna användares lösenord och det kallas OAuth. Tyvärr, används det inte i särskilt stor utsträckning.

Du har förmodligen redan hört om Month of Twitter Bugs som går av stapeln nu under juli månad där Aviv Raff sparkar på just sådana här problem.

CJ stack på semester förra veckan och jag går nästa så bloggen kommer att ligga i dvala i någon månad framöver. Ha en trevlig sommar!

--
Stefan Pettersson

(Publicerad 2009-06-26)

Secunia har kommit ut med ny statistik om hur vanligt det är med sårbara program på desktopdatorer. Medeltalen är till och med fördelade på länsnivå... Gotlands län har det sämst ställt.

Uppdatering @ 2009-07-10: Gilså har plockat upp nyheten på IDG också och poängterar att de som har PSI redan har gjort något åt säkerheten. Sannolikt är det värre hos de utan.

Programmet
Secunia Personal Software Inspector (PSI) är ett (gratis)program som håller reda på vilka program du har på din dator och om de behöver patchas. PSI scannar dels efter installerade program men övervakar också nya installationer. Data om vad du har installerat skickas till Secunias HQ, tillbaka skickas (i gengäld) information om vad som behöver patchas (med direktlänkar till patchar).

Det är inte en så dum idé faktiskt. Alla Linux-varianter har haft samma sak i evigheter i och med pakethanteringssystemens intåg...

Jag har kört programmet mer eller mindre sedan det lanserades för något år sen. Föga oväntat så går det lite knackigt, det blir så när man ska försöka kontrollera hundratals olika former av installationsrutiner som olika Windowsprogram har. (Det är mycket smidigare i Linux.)

Jag skulle rekommendera att prova PSI och köra en scan, du kommer nog att bli överraskad.

Statistiken
Back to the point. Statistiken är presenterad i Secunias WorldMap. I snitt är det nio sårbara program per gotlänning... som kör Secunia PSI. 57 000 personer bor i Gotlands län. Secunia har dock undlåtit att berätta hur många av dem som kör PSI (jag kan inte hitta några siffror i alla fall, rätta mig om jag har fel). Värdet på statistiken på den nivån blir alltså rätt medioker. (Det blev en bra rubrik dock.)

Vad som är än mer irriterande med statistiken är att de inte berättar vilka program som oftast är sårbara. Jag ger mig på en gissning:

1. Adobe Acrobat
2. Adobe Flash
3. QuickTime
4. Java RE
5. *joker*

Jag tror inte att Microsoft är med i toppen, även om de har mjukvara på _varenda_ dator med PSI, vilket de andra knappast har. Tack Microsoft Update. Man får ta med i sammanhanget att Microsoft har betydligt större rörelsefrihet och kraft i sina automatiska uppdateringar eftersom de "kontrollerar"operativsystemet som kontrollerar programmen.

Säkerhet
Säkerhet? Eh, jo, osäkra klientprogramvaror är naturligtvis en guldgruva för trojaner i legitima hemsidor som utnyttjar deras sårbarheter. Gumblar och grabbarna med andra ord.

Så...
(1) Det är intressant att medeltalet world-wide är fyra sårbara program per dator. Inte konstigt att klientattacker fungerar. (2) Automatiska uppdateringar är nog det bästa sättet att hålla siffran nere. För de program som inte har sådana funktioner finns PSI. Det kräver en del handpåläggning ibland men det är svårare att ignorera en säkerhetspatch när du får se det sådär svart på vitt.

Trevlig helg!

--
Stefan Pettersson

(Publicerad 2009-06-22)

Om exakt ett år (minus en dag) kommer Sverige att vara värdland för konferensen OWASP AppSec.

Datumet är satt till 21-24 juni 2010, strax efter att prinsessan Victoria gifter sig 19 juni och strax innan midsommar 26 juni. Konferensen genomförs i samarbete med Institutionen för data- och systemvetenskap (DSV) på Stockholms universitet i hörsalen Aula Magna.

Samarbetet med DSV och ordet Research i namnet visar avsikten att både näringsliv och akademi är inbjuden. AppSec 2010 kommer att bli kanon! Mer information finns på OWASP-wikin. Här nedan visas John när han med bestämdhet annonserar konferensen publikt för första gången för någon månad sen i Krakow.

HPS är representerad med Carl-Johan och undertecknad i konferenskommitén. Av intresse är nog också den månatliga utmaningen (den 21:a varje månad) där biljetter till konferensen står att vinna. Den första utmaningen annonserades igår, spana in OWASP-wikin för instruktioner.

--
Stefan Pettersson

(Publicerad 2009-06-10)

Bland säkerhetsexperter finns det inga dispyter om att OS X och Safari är långt mer sårbart än Vista och Internet Explorer. Men betyder det att Vista/IE är bättre för att slippa angrepp?

När Apple nu släppt sitt jumbopack sätter det återigen igång debatten kring säkerhet i OS X. För en vecka sedan skrev Rich Mogull, känd bl.a. från sina sju år på Gartner, en artikel på ämnet med titeln "Five Ways Apple Can Improve Mac and iPhone Security". Tyngden i artikeln förstärktes sedan naturligtvis när Apple nu rullat ut ett så stort antal säkerhetsfixar, och The Register var snabba med att pussla ihop det.

Även vi på HPS har varit inne på ämnet tidigare. Jag själv då jag i mars var med i TV4 Nyhetsmorgon och Stefan som bloggade om det några veckor senare, när Charlie Miller hade vunnit en Mac efter att ha utnyttjat en sårbarhet i Safari som han hållt på i ett år.

Vilka är dina hot?
Vår ståndpunkt kring det är alltså att OS X med Safari är klart underlägset Vista och Internet Explorer när det kommer till kodkvalitet och sårbarheter. MEN, en sårbarhet i sig gör ingen skada. För att skada ska ske så behöver sårbarheten utnyttjas. För att kunna värdera behöver man därför titta på hotet - vem kommer angreppen från och varför?

Malware
Eftersom OS X ännu är en plattform i minoritet finns det i jämförelse endast mikroskopiska mängder malware där ute. Det är därför LÅNGT mycket troligare att man drabbas av malware om man kör Vista/IE än om man kör OS X/Safari. Så om malware är ditt huvudbry (som det ofta är för privatpersoner) så är det i dagsläget OS X/Safari du ska köra. Detta kan dock ändra sig med tiden - ju fler som kör OS X desto mer malware kommer dyka upp för just OS X.

Riktade angrepp
Är det istället riktade angrepp mot just dig eller just din organisation som är ditt huvudbry, så blir det knepigare. Beroende på din angripares kompetens och kontaktnät kan det vara avsevärt mycket sämre att köra OS X. Precis som Stefan bloggade om så är det "kolossalt mycket svårare att utnyttja de hål som finns" i Vista/IE. Lägg till det att de sedan kommer vara avsevärt svårare att hitta - både för att de är svårupptäcka och för att de är mindre till antalet. Det betyder alltså att om din angripare själv kan hitta och utnyttja sårbarheter eller om han har kontakter med någon som kan det så är det klart olämpligt att använda OS X/Safari. Befinner man sig i ett sådant läge kan det vara läge att köra något helt annat än OS X eller Vista, men är det bara dem som finns att välja mellan? Då är det Vista som gäller.

Prioritera utifrån risk - inte utifrån sårbarhet
Samma typ av resonemang behöver man göra för säkerhet i allmänhet. Som säkerhetsnördar har vi ibland allt för lätt att stirra oss blinda på de sårbarheterna. Faktum är dock att våra resurser är begränsade och därför måste vi prioritera var vi ska lägga dem. Både i mindre skala (vilken sårbarhet åtgärdar vi först?) och i större skala (hur mycket resurser ska vi lägga på säkerhet?). För att få gehör hos omvärlden är det oerhört viktigt att vi alltid har det med oss.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-06-05)

Försvarsmakten ska köra SAP. Det verkar bli ganska... dyrt. Dessutom klarar systemet inte kraven på hemlig information.

Computer Sweden skriver om hur 2,4 miljarder kronor satsas på Försvarsmaktens nya SAP-system. Det verkar dock som att FM har stött på patrull; SAP klarar inte av att hålla information som har en säkerhetsnivå av "hemlig" utan får bara innehålla upp till nivån "öppen".

Knappast förvånande. Affärssystem är enorma bestar av komplexitet, innehåller mängder av gammal kod och testas (med sannolikhet) i väldigt liten utsträckning (säkerhetstestning, that is). SAP är inget undantag.

Jag håller nog med CJ; "för två och en halv miljard kan man väl förvänta sig att någon tar på sig att utveckla ett affärssystem från scratch".

...ja, ett med några miljoner rader kod färre kanske? Spontant känns det lite orimligt att FM inte accepterar publika krypteringsalgoritmer eller kommersiella brandväggar (de kör Färist) hursomhelst. Att köra SAP däremot, det är piano.

Vi var på den nya, svenska säkerhetskonferensen Sec-T i höstas. Mariano Nuñez Di Croce presenterade sitt pentestverktyg för SAP; sapyto. Hans presentation finns att ladda ner (pdf), de övriga från Sec-T 2008 finns också att ladda ner (zip). SAP stora problem med bl a access control för användare och grupper samt standardlösenord... Ett smakprov från presentationen:

--
Stefan Pettersson

(Publicerad 2009-06-03)

Vi hade besök från Kina igår, närmare bestämt från Zhejiang-provinsens "Information Industry Department". Säljchef Stefan berättade om HPS och jag och Jocke om vad vi ser som de större säkerhetsproblemen idag.

Min del handlade om skiftet från att attackera servrar till att rikta in sig på klienter och hur detta gjorts framgångsrikt över webben. Mer eller mindre samma innehåll som föregående blogpost om Attacker från legitima siter.

Delegationen verkade nöjd med besöket. Stort tack till vår tolk Yanan Li. Yanan har stor erfarenhet som guide och tolk åt kinesiska besökare, han är dessutom frilansfotograf.

--
Stefan Pettersson

(Publicerad 2009-06-02)

Malena Ernman övar på nationalsången utanför vårt fönster och Carl-Johan debatterar för säkerhet i utvecklingsprojekt.

På lördag är det landskamp i fotboll, vanligtvis bryr jag mig inte så mycket men de ska ju faktiskt spela precis utanför kontorsfönstret. För någon timme sedan var schlager-operasångerskan Malena Ernman nere på gräsplanen och övade på nationalsången. (Det är inte hon på bilden, hon smet så kvickt att det blev en bild på en vaktmästare istället.)

In other news så fick CJ precis en debattartikel publicerad på TechWorld, rubriken är "SSL säkrar inte din webbapplikation?". Poängen är inte att SSL är dåligt utan att "vi använder SSL" ofta är standardsvaret när man ställer en fråga om säkerhet till en leverantör.

För inte så länge sedan var jag inblandad i en upphandling av en "informationsspridningsprodukt" (lagom intetsägande, ja). Av fyra leverantörer var det bara en som inte automatiskt svarade "SSL" på första frågan om "hur de arbetar med säkerhet i utvecklingen".

--
Stefan Pettersson

(Publicerad 2009-06-01)

Gumblar och grabbarna är tillbaka. Förstås. Hur går det till? Vad kan vi göra för att skydda oss?

Ni har kanske hört talas om "attacken" Gumblar. Till och med mainstream-media som SvD har rapporterat om det (på inrikessidorna av oklar anledning). Gumblar har nu fått en kompis/konkurrent som arbetar på samma sätt. Websense verkar ha kommit ut med det först. Den har inte legat på latsidan; 30 000 siter är hackade. Båda dessa är inkarnationer av samma företeelse och de är inte först med det, det har förekommit många gånger tidigare.

(Den intresserade kan läsa "Your Botnet is My Botnet: Analysis of a Botnet Takeover" av ett gäng på UCSB om hur de tog över Torpig-nätet i tio dagar. Torpig sprider sig på samma sätt som t ex Gumblar.)

Vad är grejen då?
Syftet med attackerna är (inte helt oväntat) att sammanställa botnät för att kunna skicka spam, hosta halvt och helt olagliga sidor, genomföra DDoS-attacker, hyra ut till högstbjudande, etc. Samma sak som Storm, Conficker, Torpig och de andra i branschen. Det vanliga med andra ord.

Hur går det till?
Det luriga med sättet de rekryterar datorer till botnätet är att attackerna levereras från legitima siter. En attack behöver alltså inte komma från nudescreensavers.info eller appcracks.ru utan snarare från emmashunddagis.se, teknikboden.se eller alfaforsakringar.se.

Man kan dela upp sådana här attacker i fyra steg; (1) sätt upp infrastruktur för att skapa och administrera botnät. (2) Tillverka eller köp exploits som försöker utnyttja ett antal sårbarheter i webbläsare och tilläggsmoduler som t ex Flash- eller PDF-läsare. (3) Förbered javascriptkod som försöker köra dessa exploit i en besökares webbläsare. (4) Utnyttja sårbarheter (SQL injection eller cross-site scripting exempelvis) i legitima sidor för att injicera javascriptkod i dem som skickar besökare vidare till din uppsatta infrastruktur så att dina exploits körs i användarens webbläsare. Om besökarens program är sårbar för något av dina exploits har du precis fått en till dator i botnätet.

Metoden är väldigt effektiv och som vanligt handlar det om ett utnyttjande av förtroende. Besökaren låter emmashunddagis.se köra javascript i sin webbläsare. Något som nudescreensavers.info förmodligen inte hade fått.

Hur borde man skydda sig?
Det finns minst tre sätt:

• Håll programvara uppdaterad. När det kommer till kritan så handlar det ju om att utnyttja sårbarheter i program; inga sårbarheter, inget utnyttjande. Titta på Secunia PSI.
• Begränsa användningen av javascript. Javscript används nästan alltid för att trigga de exploits som används; inget javascript, inga exploits körs. Titta på NoScript.
• Använd blacklists. De domäner som används för att hosta exploits blir kända relativt snart efter att attackerna har börjat; blockade domäner, ingen åtkomst, inga exploits körs. Titta på Malwaredomainlist.

Ingen av dessa är helt hundra. (1) Ibland finns ingen patch för sårbarheterna även fast de är kända (detta tenderar hända i Adobes programvaror). (2) Ibland används inte ens exploits som behöver triggas med javascript utan besökaren ombeds bara (under någon förevändning) att ladda ner och köra en fil. (3) Slutligen används fast-flux i allt större utsträckning vilket försvårar blacklistornas arbete.

Givetvis kan man försöka sig på att använda antivirusprogram men det är inte särskilt effektivt. Polymorfism är inte raketforskning längre och det är något som antivirusföretagen har svåra problem med.

Vad kallar vi det här?
Jag vet inte, det är ingen traditionell mask som gör kopior på sig själv för att sprida sig som t ex Conficker. Det är definitivt inte ett virus... (det är det aldrig nuförtiden). På sätt och vis är det en trojansk häst eftersom den gömmer sig i en legitim sida. Oavsett har jag inte sett någon entydig, bra benämning på det här fenomenet. Förslag/kommentarer tas gärna emot.

--
Stefan Pettersson

(Publicerad 2009-05-22)

Just nu är MySpace sårbar för reflected cross-site scripting.

Någon som kallar sig Methodman som verkar ingå i ett gäng som kallar sig Teamelite postade igår kväll en sårbarhet på MySpace. Det finns även en länk till en video på YouTube som visar hur det går till. Av allt att döma injiceras scriptet på flera ställen i koden utan att det HTML-kodas.

Intressant nog har Methodman lagt upp fler filmer på YouTube, en om XSS i PayPal. Hans feed kan vara bra att hålla ett öga på.

Svårt att säga att det är nyheter, MySpace har (som alla andra större siter) råkat ut för det flera gånger tidigare.

Det var ungefär det här som Samy hade att arbeta med från början. Samy var killen som skrev den första stora XSS-masken i slutet av 2005, den fick MySpace att stänga ner helt efter bara 20 timmar. Om ni inte läst hans redogörelse, gör det, den är lärorik och underhållande.

Uppdatering @ 2009-05-25 09:16
Hålet är fortfarande öppet.

Uppdatering @ 2009-05-29 10:27
Hålet är fortfarande öppet.

--
Stefan Pettersson

(Publicerad 2009-05-18)

Jag och CJ har varit en vecka i Krakow på två konferenser.

Först deltog vi OWASP AppSec 2009 och sedan den polska konferensen CONFidence 2009. Vi rapporterade om de presentationer vi såg på OWASP Swedens blogg.

--
Stefan Pettersson

(Publicerad 2009-05-13)

OWASP AppSec i Krakow, Polen har börjat. Första dagens keynote ges av Ross Anderson från universitetet i Cambridge.

Ross är en av mina stora förebilder i branschen, precis som Schneier har han en väldigt bred och klar syn på säkerhetsfrågor.

Security economics
Inte helt oväntat så fokuserade Ross på ekonomiska aspekter av säkerhet. Han, och ett gäng andra forskare, kallar området för "security economics". Den centrala idén är upptäckten att system ofta inte brister av tekniska skäl utan på grund av att incitamenten att skydda dem ligger på fel personer. Den eller de personer som har bäst möjlighet att göra ett system säkert är inte samma person eller personer som lider av dess säkerhetsbrister.

Security economics kan förklara många av de fundamentala problem som finns inom säkerhet. Varför skulle en användare betala för antivirus när det skyddar mot malware som attackerar Microsoft (masken Blaster)?  Masken utnyttjar ju till och med säkerhetshål som Microsoft själva är ansvariga för.

Är säkerhet kommersiellt irrationellt?
Utvecklarnas incitament för säkerhet är i direkt konkurrens med vad som är kommersiellt rationellt. På 90-talet (innan de ägde marknaden) hade Microsoft (enligt utsago) talesättet "We'll ship it on tuesday and get it right by version 3". Det låter illa men när man tänker efter är det helt rimligt. Att ta marknaden  fort genom att tillfredsställa kunder och därmed få stor användarbas leder till att utvecklare vill göra sina program för plattformen. Stort utbud av programvara leder sedan till fler användare. Cirkeln är sluten.

Så, hur lockar man användare? Funktionalitet. Hur lockar man utvecklare? Besvära dem inte med säkerhet. Användarna får ta kostnaden för säkerhetsproblem. Facebook-grundaren Mark Zuckerberg (som också har tagit över sin marknad totalt) formulerade sig så här:

"Growth is primary, revenue is secondary."

Det handlar alltså om klassisk "customer-lock-in". Om vi hoppar framåt lite:

När man tänker på ett systems säkerhet bör man alltså ta reda på vem som har störst möjlighet att göra det säkert alternativt försvara det. Krasst sett är det den personen som borde få lida för eventuella säkerhetsbrister.

Här ligger lagstiftning om att hålla utvecklingsföretag ansvariga för säkerhetshål  väldigt nära. Det är ingen idé att skriva något om detta här, Bruce Schneier har förstås redan beskrivit det hela mycket väl:

Information Security and Externalities

Software Makers Should Take Responsibility

--
Stefan Pettersson

(Publicerad 2009-05-08)

Uppgifter har kommit fram om att en kvinnlig agent 2006 tappade bort ett USB-minne med topphemlig okrypterad information. Som ett resultat behövde mångmiljonoperationen ställas in och agenter flyttas om då deras liv riskerades.

Man upphör aldrig att förvånas. Tydligen har MI6 inte varit ett dugg bättre än det svenska försvaret som också tappade bort ett okrypterat USB-minne förra året.

Inte ens de som har mångmiljon-investeringar, en tradition av säkerhet och hemlighållande och där människors liv står på spel klarar tydligen av något så "avancerat" som att kryptera sin data. Herregud!

Hur man kan tillåta så känslig information ligga okrypterad på något så lättappat som USB-minnen är bortom mig. Att varken någon inom organisation eller någon ansvarig politiker reagerat tidigare är fullkomlig skandal!

Har man svårt att hitta budget för att köpa in kommersiell mjukvara eller hårdvara så finns ju för tusan gratisalternativ som TrueCrypt. Kvar finns bara eventuell lösenordshantering, något som dessa organisationer bör vara väldigt vana vid. Jag ser verkligen INGA godtagbara ursäkter för det inträffade. In med lite nytt fräscht tänkande - och låt er gärna inspireras av hur drogkartellerna sköter sin säkerhet.

1. Kryptera
2. Lösenordshantera
3. Plocka in nytt blod

Ett exempel på hur lösenordshantering INTE skall skötas kommer även det från Storbrittanien. Då hade man tejpat fast lösenordet på USB-minnet. Lättanvänt, men inte så smart...

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-05-06)

Killen från Uppsala som hackade flera svenska universitet, Cisco, Nasa, Sveriges superdatorcentrum och lite annat under 2004 är på tapeten igen.

Romantiken i en ensam 16-årig grabb från Uppsala som hackar några USA:s största IT-företag och myndigheter leder förstås till att nästan alla skriver om det:

Expressen: Svensk åtalad för dataintrång i USA

Aftonbladet: Svensk hackare åtalas i USA

Svenska dagbladet: Svensk hackare åtalas för intrång hos Nasa

De skriver dock ungefär samma sak. Vad den nyfikne dock inte borde missa är Leif Nixons version av vad som hände, se hans presentation Stakkato-intrången (pdf). Han arbetade på Nationellt Superdatorcentrum i Linköping under intrången och i presentationen berättar han om hur intrången upptäcktes, hur de gick till och vad de gjorde åt saken.

Man kan inte nog understryka hur sällsynt det är med liknande historier, vanligtvis vill man ju naturligtvis mörka incidenter. Ta chansen och läs.

--
Stefan Pettersson

(Publicerad 2009-05-06)

Förra gången diskuterade vi hur man kan se det som att brandväggar behövs när man inte kan lita på sina datorer. Är det verkligen så enkelt?

Ja. Problemet är att detta inte hjälper dig hela vägen eftersom du fortfarande måste lita på applikationerna som kör på dessa datorer när de går att nå genom brandväggen. (Naturligtvis måste du lita på din personal oavsett.) I förra delen sa vi ju att nya applikationer kan dras igång på datorer utan att den som är ansvarig vet om det. Brandväggar är dennes sätt att skydda sig mot sådant. Tyvärr är applikationer sårbara emellanåt och man kan inte lita på en sårbar applikation. Så här ser din brandvägg och webbtjänst ut idag:

Klienten (webbsurfaren) skickar sina paket rakt genom brandväggen hela vägen fram till webbservern. En av brandväggens huvuduppgifter är att släppa fram sådan trafik.

Nu kanske du säger att du kör ISA Server, att din brandvägg normaliserar HTTP-trafik eller liknande. Det är ju förstås bra; om webbservern har sårbarheter i sig (nyare IIS och Apache skulle klara sig fint) så behöver den inte bli tagen på sängen av en 8000 tecken lång User-Agent. Sådana brandväggar har möjlighet att skydda webbservern.

Som bilden tydligt visar slutar det dock inte där. Inkommande trafik kan te sig helt normal och följa webbserverns protokoll (HTTP) till punkt och pricka medan den skulle innebära en katastrof för applikationen.  En vanlig brandvägg, även en som förstår sig på HTTP, förstår sig inte på applikationens behov och begränsningar. Samma sak gäller i nästa steg mot databasen, varken applikationen eller brandväggen förstår sig på databasen. (Det är för övrigt därför vi har problem med SQL injection idag.)

Det här är förstås inget som stannar vid webbapplikationer. En brandvägg har precis lika liten uppfattning om hur andra komplicerade eller specialgjorda protokoll fungerar. Det finns givetvis funktioner i dyra brandväggar som kan kolla SMTP, FTP eller till och med andra protokoll efter fuffens. Tyvärr beror detta på att dessa protkoll är triviala jämfört med exempelvis kommunikationen mellan webbläsare och applikationer som Gmail eller EPiServer.

Är det något du ska ta med dig från den här blogposten så är det följande:

1. En av brandväggens viktigaste uppgifter är att släppa fram trafik till webbservern.
2. Brandväggar avgör vilka applikationer som ska vara nåbara.
3. En brandvägg kan inte skydda en applikation eftersom den inte förstår dennes behov och begränsningar.

John Wilander (ledaren för svenska OWASP) säger att "applikationerna är det nya slagfältet". Jag kopierar och säger "applikationerna är det nya slagfältet och brandväggen kan inte hjälpa dig".

--
Stefan Pettersson

(Publicerad 2009-05-02)

Ännu en gång har Twitter blivit drabbade av en säkerhetsincident. En fransk cracker tog sig in till administrationspanelen genom att få tag i en adminstratörs konto. Hur? Genom Yahoo.

Intrånget tycktes börja den 27:e april då en Twitter-adminstratörs Yahoo-konto togs över av fransmannen. Tillvägagångssättet var det samma som från förra året då Sarah Palin fick se sitt konto kapat; återställning av lösenordet. En något intresseväckande detalj i sammanhanget är att administratören bad Yahoo-security kontakta honom, men övervägde tydligen inte konsekvenserna för vad hans kapade konto på Yahoo skulle kunna ha i övrigt. Det visade sig att i hans maillåda fanns inloggningsuppgifter till administratörspanelen på Twitter.

Några reflektioner:

• Mailkonton är nästan alltid bundna till andra konton.
• Återigen så är beroenden något som missas. Och det är precis vad som används vid intrång - en angripare kommer vara väldigt medveten om vilka beroenden som finns eftersom han lägger kraft på att hitta dem.
• Lösenordsåterställningsfunktioner är en balansgång mellan säkerhet och bekvämlighet. Grundproblemet finns dock alltid där: Hur vet man att personen verkligen är den som den utger sig för att vara?
• Yahoo väljer det som passar den stora massan och det som blir billigast för Yahoo. Det är fullt rimligt.
• Bland de som använder Yahoo Mail finns personer som tar risker som drabbar andra än dem själva. Förmodligen är detta risktagandet omedvetet.
• Organisationer bör tydliggöra hur externa siter får användas. Utgångsläget bör vara att hålla all information helt inom organisationens kontroll och utanför andras.
• Ska man förlita sig på andras system kan det vara klokt att göra en riskbedömning på beslutet först - i det inkluderas att utvärdera säkerhet i det systemet man förlitar sig på.

... man kan fundera på hur alla dessa säkerhetsincidenter påverkar Twitters affärer. Vid det här laget borde deras brist på säkerhet ha skrämt en hel del av Twitters högprofilerade användare så som Britney Spears och Ashton Kutcher. Kommer de verkligen våga fortsätta?

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-04-23)

Brandväggar har under många år fått bära ett tungt lass inom IT-säkerheten och förväntas lösa (lite väl) många av våra problem. I första delen ska jag försöka ändra din syn på brandväggar. De handlar nämligen en hel del om förtroende.

Varning: denna bloggpost tar inte hänsyn till förkortningar som UTM, VPN och IDP som brukar associeras med dagens brandväggar. Vi har en ganska gammaldags syn; en brandvägg är ett flexibelt paketfilter.

En lärare på ISY på Linköpings universitet, Niclas Wadströmer, hade en härligt klar syn på brandväggar. Han sade någon gång att man behöver en brandvägg om man inte kan lita på datorerna i sitt nätverk. Det här kan tyckas vara raka motsatsen till hur vi vanligen ser på saken, elakingarna är ju på Internet, utanför nätverket. Det är ju de vi inte litar på.

Det är dock lätt att få vem som helst att acceptera Niclas syn; om alla datorer på ditt nätverk är säkra så att du kan lita på dem och du behöver ingen brandvägg. I verkligheten kan tyvärr ingen riktigt göra det. Tillit är alltid farligt och robusta system är sådana som inte kräver att man litar på andra.

Det är nu vi kan se brandväggens styrka, den minskar mängden förtroende vi måste ha för ändpunkterna i vårt nätverk. Vi samlar ansvaret i en punkt. En ansvarig för säkerhet behöver inte längre oroa sig för att en administratör plötsligt ska dra igång en sårbar webbtjänst på mailservern så att den är åtkomlig från Internet. Det spelar ingen roll, brandväggen släpper bara fram trafik till mailtjänsten.

Synsättet passar lika bra för användarnas datorer och den lokala brandvägg de (förhoppningsvis) kör. Användaren råkar ut för en drive-by-download, något främmande program installeras och detta försöker öppna en port för att ta emot eller (vilket är mycket vanligare) hämta instruktioner. En lokal brandvägg kan stoppa båda dessa attacker; användaren kan alltså känna sig trygg även om hon inte kan lita på sin webbläsare. NB: Det här förutsätter givetvis att webbläsaren inte körs med administratörsrättigheter. Men det gör den ju inte, eller hur?

En brandvägg används inte för att skydda mailserverns mailtjänst. En brandvägg används för att se till att det bara är mailtjänsten som är tillgänglig. Det är denna skillnad som tas upp i del 2.

--
Stefan Pettersson

(Publicerad 2009-04-17)

För några dagar sedan kom Verizon Business ut med sin 2009 Data Breach Investigations Report. Rapporten är en guldklimp packad med pålitlig och högst användbar, statisitk, men statistiken måste tolkas i sitt rätta sammanhang.

Rapporten baseras på intrång utredda av Verizon Business under 2008 och analysen tar även med resultaten från förra årets rapport som baserades på 2004-2007. Den är GULD och jag rekommenderar varmt alla att läsa den. Några av höjdpunkterna:

• 69% av intrången upptäcktes av tredje part
• 81% av de som skulle vara PCI DSS-compliant var det inte
• 83% av angreppen var inte särskilt svåra
• 87% ansågs ha kunnats undvika genom enkla eller medelsvåra åtgärder ("intermediary controls")

Det öppnar för MASSOR av intressanta diskussioner:

• Betyder det här att PCI DSS fungerar, eller är det så att 81% av alla som skall följa PCI DSS inte gör det? Frågan ansluter till min debattartikel i Internetworld från tidigare i år.
• Hur många intrång begås som inte upptäcks av någon alls, om nu 69% har gett så uppenbara resultat att det upptäcks först av en tredje part? Hur stor andel av dessa 69% är det VISA eller MasterCard som upptäckt genom analys av bedrägerier?
• Hur kommer det sig att man inte genomfört ens de enklaste åtgärderna? Den största orsaken till intrång var defaultkonton och delade konton. Det är tämligen lätt att genomföra engångsåtgärder och kräver i princip inget tekniskt kunnande alls - så varför görs det inte?

Vill någon diskutera dessa ämnen eller få min syn på det så skulle jag tyckta det vore jättekul att få kontakt. Hur som helst, det var en sak som fick mig att börja skriva om det här, och det var att rapportresultatet måste naturligtvis tolkas i sitt sammanhang.

1. Data har enbart hämtats från intrång som har upptäckts
2. Data är enbart hämtade från fall där man har valt att plocka in en extern part för att utreda vad som hänt

Några implikationer:

• Det rör bara intrång som varit så "högljudda" att någon upptäcks och som bolaget inte kan förneka.
• Enkla attacker blir då överrepresenterade. De som utför bättre attacker är rimligen också bättre på att dölja sina spår och inte bli upptäckta.
• Tredje partsupptäckter kommer också bli överrepresenterade. Enligt min erfarenhet väljer många bolag att hålla ärendet internt om de upptäcker det själva, ofta vet bara en liten krets om det. Dessa fall kommer Verizon aldrig få med i sin rapport.
• Insiders är bättre på att dölja sina spår eftersom de vet mer om hur systemet är skyddat och vad som kan göras utan att det upptäcks. Insider vs. externt angrepp kommer därför skevas upp till att visa en större andel externa angrepp än vad som är verkligheten på alla angrepp.
• Kortdata och de som hanterar kortdata kommver vara överrepresenterade. Detta på grund av att VISA och MasterCard upptäcker intrång tack vare att kortdata som stjäls används vid bedrägerier, och sedan kräver extern utredning av det. Motsvarande mekanismer finns inte någon annanstans.

...och det finns troligen fler sådana vinklar man kan hitta. Icke desto mindre är det en mycket intressant rapport och jag hoppas Verizon fortsätter publicera dessa uppgifter.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-04-15)

Under påskhelgen drabbades Twitter av ett mindre antal cross site scripting maskar. Twitter var i vanlig ordning inte speciellt snabba på att reagera. Det var däremot malwarespridarna som snabbt ordnade bra google-placeringar.

Angreppet sägs ha börjat med att 17-årige Michael Mooney "inte hade något bättre för sig". Att Twitter var långsamma att reagera och att de blivit angripna flertalet gånger förr är intressant i sig, men här skulle jag bara kort vilja nämna något som blev en trend under 2008 och som lär fortsätta växa. Nämligen att de som sprider malware utnyttjar ett existerande behov kring något aktuellt.

Gör en sökning på Google på 'twitter worm' (utan ') och titta igenom sökresultaten. Vid det här laget då jag skriver så har Google taggat flera av dessa sidor som malware-spridare, något som inte fanns där från början. Faktum är att det till och med finns med på top 10 sökresultat.

Google-sökning på twitter worm; skadlig kod sprids genom att utnyttja aktuella händelser och förtroende som finns för Google:

Vad jag kan komma ihåg så blev fenomenet att utnyttja aktuell information populärt i och med spridningen av Storm med start januari 2007. Då var det aktuella händelser som Katrina, påsk, jul osv som användes för att få folk att öppna bifogade filer och följa länkar.

Eftersom det var effektivt tog idén fäste och det skapades falska antivirus som "hittade" och mot betalning "rensade" virus. I själva verket installerade de trojaner.

Nu har trenden gått mot att utnyttja ännu mer specifika och aktuella händelser - och se till att man hamnar högt på google då det söks på detta. Vi lär få se mycket mer av detta framöver.

Den som inte vill bli smittad av malware eller råka ut för desinformation bör göra som seriösa journalister alltid har gjort - se till att ha pålitliga källor.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-03-24)

Ryan Naraine från ZDNet intervjuar Charlie Miller som vann en Macbook Air under CanSecWests Pwn2Own genom att exploita Safari 4 på en fullpatchad OS X. Igen.

Under intervjun har Miller många bra svar, han kan verkligen tala med auktoritet i den gamla (och meningslösa) diskussionen om huruvida Apples OS X är säkrare än Windows. Millers åsikt är solklar; det är mycket lättare att utnyttja ett säkerhetshål i OS X än i Windows.

Utan att ge oss in i diskussionen om OS X och om det är säkrare; varför anser Miller att OS X är så mycket lättare att utnyttja? (NB: första och sista stycket.)

Why Safari? Why didn’t you go after IE or Safari? [sic]

It’s really simple. Safari on the Mac is easier to exploit.  The things that Windows do to make it harder (for an exploit to work), Macs don’t do.  Hacking into Macs is so much easier. You don’t have to jump through hoops and deal with all the anti-exploit mitigations you’d find in Windows.

It’s more about the operating system than the (target) program.  Firefox on Mac is pretty easy too.  The underlying OS doesn’t have anti-exploit stuff built into it.

With my Safari exploit, I put the code into a process and I know exactly where it’s going to be.  There’s no randomization. I know when I jump there, the code is there and I can execute it there.  On Windows, the code might show up but I don’t know where it is.  Even if I get to the code, it’s not executable.  Those are two hurdles that Macs don’t have.

It’s clear that all three browsers (Safari, IE and Firefox) have bugs. Code execution holes everywhere.   But that’s only half the equation.  The other half is exploiting it.  There’s almost no hurdle to jump through on Mac OS X.

Det här är precis vad jag skrev om i en tidigare blogpost "Penicillin är inte lösningen" för några veckor sedan. Varje enskild skyddsmekanism gör inte allt men tillsammans resulterar de i att det blir kolossalt mycket svårare att utnyttja de hål som finns. (Det finns alltid hål.)

Charlie Miller och Dino Dai Zovi (som knäckte en MacBook Pro i samma tävling 2007) har förresten nyligen kommit ut med en bok från Wiley, "The Mac Hacker's Handbook". Jag har inte läst den (än) men generellt brukar Wileys "Hacker's Handbook"-böcker hålla hög standard.

--
Stefan Pettersson

(Publicerad 2009-03-19)

Erfarenheter är vårt överlägset bästa sätt att lära oss på. Även om vi vet att något inte är bra, även om vi får höra det och kan förstå det teoretiskt, så är det ibland först när något personligt inträffar som det känns verkligt.

Igår nådde nyheten fram till mig att en kollega i branschen dog i söndags. Han jobbade nere i Karlskrona, tillhörde precis som jag och Stefan en generation som vuxit upp med datorer och var även han djupt insatt i teknisk IT-säkerhet. Dödsorsak: brand i hemmet.

Jag blir förvånad över hur personligt och nära det hela känns för mig.  Trots att jag bara hade växlat några ord med honom så känner jag mig betydligt mer påverkad av hans frånfälle än av diverse bränder och elände jag hört om i min geografiska närhet.  Det hände en av oss!

Så fungerar vi nog alla, om än i olika grad. Erfarenhet väger tungt, teori mindre tungt. För ett och ett halvt år sedan flyttade jag och min fästmö från lägenhet till villa. Sedan flytten har våra brandvarnare aldrig blivit uppskruvade, utan har istället bara legat högt upp på hyllor och skåp. Detta trots att vi för ett halvår sedan hade en besiktningsman hemma hos oss som påpekade just detta. Vi har hela tiden gått omkring och tänkt ”det fixar vi senare” eller ”nästa gång vi håller på med rummet så ordnar vi det då”, samtidigt som en svag gnagande känsla av att det där är nog inte så bra funnits där.

Att dra parallellen till IT-världen är enkel. Flera undersökningar av intrång har visat att man genom rimliga åtgärder hade kunnat förhindra cirka 90% av dem. Oftast är det enkla småsaker som alla redan känner till, men som det slarvats med. Det är lätt att föreställa sig att det rationaliserats bort i tankarna med resonemang som ”det har ju ändå inte hänt någonting”, och större delen av tiden så fungerar resonemanget. Men när olyckan väl är framme kan konsekvenserna bli katastrofala. Då känns det hela väldigt onödigt. Det hade ju varit så enkelt att förhindra!

Att man pratar om sina erfarenheter är jätteviktigt. Samtidigt kan det vara svårt att våga om det är något man skäms för och man räds konsekvenserna av att berätta. Min erfarenhet säger dock att i rätt sällskap så finner man ofta förståelse, och tillsammans blir man starkare.

Med detta vill jag uppmuntra alla våra läsare att prata mer om sina erfarenheter. Själv går jag hem och skruvar upp mina brandvarnare.

--
CJ

(Publicerad 2009-03-05)

En undersökning bland 500 utvecklare världen över har visat att PHP är scriptspårket utvecklarna är mest nöjda med. I en kommentar till IDG säger Ola Bini att han tror det har att göra med "det är lätt att få en fungerande lösning". Och då lider säkerheten.

Artikeln på IDG nämner också att intresset för scriptspråk fortsätter öka i popularitet. Jag har i flera år talat om de olika krafter som ligger bakom varför vi ser så ohyggligt många sårbara webbapplikationer. En av dem är just att det finns väldigt kraftfulla scriptspråk.

Det finns fyra synliga faktorer som beställaren och omgivningen är synnerligen intresserade av: funktionalitet, tillgänglighet, kostnad och kalendertid för utvecklingen.  Alla fyra märks och är lätta att mäta. Sist kommer ett "jag vill ha den säker också", som brukar specificeras synnerligen luddigt. Självklart kommer utvecklingen då att luta åt att uppfylla de aspekter som är synliga och man vet kommer märkas och följas upp. Temat återfinns i min artikel från sommaren 2007.

Det är enkelt att få en applikation till det stadiet där den beter sig fungerande för en vanlig användare. Men eftersom det är så enkelt ställs det låga krav på utvecklarna, samtidigt som det ställs höga krav för att kunna koda säkert. De höga kraven kommer från en hög komplexitet med mängder av olika språk och protokoll som behöver kunnas, förutom den "naturliga" kodkomplexiteten.

Just PHP är särskilt sårbart i det här avseendet och det är jätteviktigt att man utbildar sina utvecklare i säker kodning.

--
CJ

(Publicerad 2009-02-27)

I dagarna täppte Facebook till ytterligare Cross Site Scripting-hål. Det kort efter att man blivit informerade om sårbarheten från en säkerhetsforskare. Men för bara två månader sedan var det ett helt annat ljud i skällan.

Facebook har täppt till ytterligare XSS hål i sin sida. Det är bara ett av flera som uppdagats det senaste halvåret. Vad som är särskilt intressant är hur snabbt attityden från Facebook har ändrats.

Augusti 2008 blev Facebook informerade om ett annat XSS-hål. Men inget svar kom. Det var först då säkerhetsforskaren fyra månader senare gick ut till media med hålet och The Register skrev om det som Facebook ansåg det var värt att bry sig om det.

Om och om igen ser man samma sak. Forskare försöker bete sig ansvarigt, lägger tid och kraft på att dokumentera och nå fram med resultaten till någon som kan fixa det. Inget svar.  

Samma mönster gick att se förra veckan då en 14-åring kontaktade administratörer för ”Kunskapsnätet”. Istället för att lyssna på honom, tacka och åtgärda felet så valde man att försöka stänga ute honom genom att byta hans lösenord. Svaret blev att utnyttja en XSS-bug och dirigera om trafiken till ett filmklipp. Efter det låg sajten nere i tre dygn.

Det finns högar med fler exempel som alla visar samma sak. Men vi kan väl försöka vara glada åt att åtminstone Facebook nu verkar ha lärt sig?

--
CJ

(Publicerad 2009-02-10)

IT-säkerhet som område är fullt av olösta problem och vi är många som försöker vara en del av lösningen. Tyvärr råder det ofta förvirring kring vilkea problem som ska lösas.

OWASP har släppt sin sjätte podcast. Jag har inte lyssnat på någon av dem innan men eftersom sexan enligt utsago skulle vara ett "round table" om web application firewalls (WAFs) så passade jag på. Det talades om en del annat också men jag fokuserar på just vad de hade att säga om WAF.

Herrarna kring runda bordet var (mer eller mindre) kategoriskt emot att skydda webbapplikationer med en WAF. Den här posten syftar dock inte till att redogöra för alla deras argument eller mina motargument. Bara ett av dem.

Ett vanligt argument som användes går något i stil med: "Det är inte lösningen på problemet, fel i mjukvara ska rättas i mjukvara". Detta upprepades också i diskussionen/kriget på WASC:s mailinglista som följde där Martin O'Neal skriver:

The place to fix software vulnerabilities, is yes, in the software.  You can mask them and fudge them elsewhere, but you can only fix them in the software.  WAFs can only fiddle around on the fringe, and can only address many issues by damaging the user experience. Whereas fixing the software should not.

Är inte det här något vi har hört förr? Ganska många gånger? När stöd för NX-biten kom till x86-processorer i slutet av 90-talet och man ville införa det i Linux så opponerade sig Linus:

In short, anybody who thinks that the non-executable stack gives them any real security is very very much living in a dream world. It may catch a few attacks for old binaries that have security problems, but the basic problem is that the binaries allow you to overwrite their stacks. And if they allow that, then they allow the above exploit.

Det här är ett ställningstagande som återkommer i diverse sammanhang. Det har bl a sagts i samband med diskussioner om StackGuard, /GS, ASLR och andra skydd mot buffer overflows. Jag var tyvärr inte med på den tiden men jag räknar kallt med att liknande argument har använts mot antivirus och brandväggar.

Nu kommer det hemska; de har ju rätt. De är inte lösningen på problemet. Antivirusprogram missar rutinmässigt filer som den inte har hört talas om, brandväggar kan inte göra något åt trafik den släpper igenom (läs: HTTP), NX skyddar inte mot return-to-libc, ASLR kan inte nödvändigtvis täcka hela processens minne, o s v.

Detta är inte helhetslösningar det är verktyg som löser (ibland väldigt) specifika problem.  En stack som inte är exekverbar skyddar definitivt från att kod exekveras på stacken, inget annat. Så enkelt är det.

WAF har tyvärr väldigt många och lösa definitioner än så länge men de löser sina specifika uppgifter på ett bra sätt. (Vilka dessa är tar vi någon annan gång.)

Att penicillin inte hjälper när någon har gett dig en fläskläpp gör det inte värdelöst. Penicillin hjälper oss mot bakterier, det är en del av vårt sjukvårdssystem.

--
Stefan Pettersson

(Publicerad 2009-02-06)

Efter att Obama blivit president har Homeland Security fått direktiv att skydda informationsnätverk. En punkt i detta är "Mandate Standards for Securing Personal Data and Require Companies to Disclose Personal Information Data Breaches". Det liknar vad Kalifornien och 43 andra stater redan har, och vad Sverige också borde ha.

Obama har gjort gott på sitt vallöfte om att lyfta informationssäkerhet som en fråga för landets säkerhet. På vita husets webbsida för homeland security kan man numera se sex olika punkter som ska förstärkas. Mycket föredömligt. Det är ett ämne i sig som jag kommer återkomma till, och jämföra med hur det ser ut i Sverige. Men idag är det bara en av punkterna som behandlas här.

Debatten som funnits rör huruvida lagstiftandet verkligen gör nytta. Å ena sidan hävdas att:

• Genom tvingande att offentliggöra ges incitament att förbättra säkerheten.
• Varje person har rätt att veta om deras personliga data kommit på drift.

Å andra sidan argumenteras det mot det för att:

• Sannolikheten för att bli offer för identitetsstöld efter ett intrång är mycket låg, kring 2%
• Ett offentliggörande skulle inte kosta så mycket i förhållande till vad som redan lagts ut.
• Marknaden kanske sköter det själv genom att konsumenter väljer att gå till de som är schyssta och självmant meddelar när de haft intrång.
• En desensiteringsprocess skulle sättas igång och konsumenterna skulle inte längre reagera efter ett antal intrång offentliggjorts. [Tänk: vargen kommer!]

Jag som jobbar med IT-säkerhet ”ute på fältet” kan bara konstatera att oavsett vilket så är varje intrång en källa till mycket värdefull information. Vid varje intrång kan man se exakt vad som har gått fel i de förebyggande åtgärderna. Det är värdefull information för alla. Dessutom får man publika exempel på att saker faktiskt händer, vilket behövs för att bemöta ”det händer inte mig”-attityden. Faktum är oftast: det händer flertalet, det kan hända dig, det kan ha hänt dig utan att du märkt det.

Utöver det så har jag lätt att hålla med om argumenten för lagstiftning, medan argumenten mot känns väldigt tama, långsökta och felaktiga.

--
Carl-Johan "CJ" Bostorp

(Publicerad 2009-01-22)

Varumärken som väljer att marknadsföra sig som lite extra dyrbara har alltid (och kommer alltid) att få slåss mot piratkopior. Problemet för konsumenterna är att det står "Authentic Marlboro" även på piratkopiorna.

I morgonens Metro finns en artikel om min namne Stefan, 46, som har blivit lurad att köpa tre fejkade Armani-jackor för 2000 kr.

Stefan mötte bedragaren på Q8-macken i Hallunda. Mannen, som utgav sig för att vara italienare, gick till väga på samma sätt som ligan gjort sedan 2005.

Han sa att han varit på modemässa och skulle till flygplatsen. Han ville bli av med visningsexemplar [tre jackor från Armani], eftersom de inte fick plats i bagaget.

-Min fru såg direkt att de inte var äkta. Jag blev bara begeistrad av att få så mycket märkesgrejor för så lite.

Intressant #1: Klassisk pretexting; bedragaren hade en relativt sensationell men trovärdig historia. Man kan med säkerhet anta att han även sa att han hade bråttom till flyget och att Stefan måste bestämma sig på en gång.

Intressant #2: Vi pratar alltså om autentisering här. Enligt Wikipedia är autentisering "[...] the act of establishing or confirming something (or someone) as authentic". Precis vad Stefan var tvungen att göra. På plats. Utomhus i dålig belysning. Och, framförallt, med väldigt begränsad erfarenhet av Armanikläder samt en förmodad undertryckt önskan att de verkligen var riktiga.

Intressant #3: I artikeln finns faktarutan "Så vet du att det du köper är äkta vara". Råden är som följer:

Så vet du att det du köper är äkta vara (numrering har lagts till):

1. På de flesta Armani-jackor finns identifikation på blixtlås eller knappar. Den karaktäristiska örnen eller namnet.
2. Hangtag-etikett med artikelnummer. Dubbel etikett med blank framsida och räfflat papper inuti.
3. Handla inte av någon som stoppar dig utomhus.

Det har sagts att lösenord förmodligen är den sämsta möjliga autentiseringsmetoden som går att frambringa. De två första ovan har mer att göra med identifiering och den sista är inte ens applicerbar. (1) Att gravera/gjuta ett blixtlås med "den karaktäristiska örnen eller namnet" är en smal sak för lirarna som tillverkar jackor. Dess existens må identifiera märket Armani men det är sannerligen inte autentiserat. I så fall hade man gjort blixtlåset svårt att tillverka (jämför med papperspengar). Tyvärr sätts lite väl stor tilltro till liknande metoder, hologrammen på kreditkort till exempel. (2) Etikettens utseende är irrelevant i detta fall, bedragaren förklarar helt enkelt att de _naturligtvis_ tagit bort den på mässan.

Punkt tre är den enda som är rimlig om du inte har erfarenhet av fejkade märkesplagg vilket majoriteten av Metros läsare (i synnerhet undertecknad) sannolikt saknar.

--
Stefan Pettersson

(Publicerad 2009-01-15)

Nu är det då äntligen dags för oss att påbörja vår nya blogg. Precis som vår kollega Jocke von Braun är inne på i sin blogg så ser vi förbättringspotential i den nuvarande IT-säkerhetsdebatten.

Under förra året så stötte vi på mängder med exempel på kunskapsbrister och missförstånd i detta ämne: felaktig fakta, saknade sammanhang, långa tider mellan händelse eller publikation i utländsk media till dess att det nådde ut på bredd även i Sverige. För att inte nämna en del viktiga frågor som över huvud taget inte nådde ut.

Vi vill därför med vår blogg erbjuda en pålitlig källa där vi lyfter fram sådant som annars har svårt att komma fram. Vårt fokus kommer inte ligga på att kritisera andra, utan på att utifrån vår erfarenhet och kunskap analysera och dra slutsatser kring sådant som är aktuellt – vare sig det är något vi själva kommit i direktkontakt med, något som vi läst om i bloggar eller något vi hittat i media. Genom det hoppas vi speciellt tilltala de likasinnade som precis som vi vet att ”djävulens finns i detaljerna”.

Samtidigt kommer bloggen vara ett personligt utlopp för oss.  Vi har under åren haft många intressanta diskussioner internt på HPS.  Oftast börjar dessa med ett utspel från en i rummet som har en åsikt om någon fråga. Inte så sällan har det varit jag som stått för dessa, och medarbetare som vare sig de velat eller inte fått ta del av den senaste "CJ-analysen". Nu är det dags för Sverige att ta del av dessa analyser! Med mig har jag min kollega Stefan Pettersson som jag alltid kunnat förlita mig på då jag behövt prata av mig. Tillsammans hoppas vi kunna erbjuda mycket intressant läsning framöver, och vara ett konkret komplement till en annars svävande IT-säkerhetsdebatt!

Mvh Carl-Johan Bostorp

"The computer industry is the only industry that is more fashion-driven than womens-fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about." -Larry Ellison (Oracle-grundaren) om "Molnet"

Vi har efter en del funderande bestämt oss för att flytta ut bloggen i "molnet". Under en period framöver kommer våra gamla inlägg att migreras över. Tyvärr har man inte möjlighet att bakdatera inlägg på blogg.se vilket kommer att resultera i en jädra massa aktivitet under en och samma månad för att sedan återgå till normal frekvens.

Hoppas att ni har överseende med detta!

Bonus: Schneiers åsikter om säkerhetsproblemen med att ha tjänster i molnet; Be Careful When You Come to Put Your Trust in the Clouds.

Hur tar vi hänsyn till det här?
Vi kan inte göra något åt att blogg.se t ex har en SQL injection-sårbarhet i någon parameter någonstans som leder till att våra inlägg kan ändras. Vi får helt enkelt lita på att de har koll på läget. I det här fallet anser vi att risken är låg, inte för att det är låg sannolikhet utan för att det inte påverkar oss i någon vidare utsträckning.

Vad som är viktigare för oss däremot är att allt arbete vi lägger på att skriva inlägg inte går förlorat för att blogg.se får en hårddiskkrash och inte har backup. Vi kan minska följderna av detta problem genom att ta egna kopior på inläggen, exempelvis via ett script som hämtar och arkiverar uppdateringar via RSS.

Sammantaget innebär det här en säkerhetsnivå som vi tycker är acceptabel.

--
Stefan Pettersson