It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Month: mars, 2011

Knarkarkvart på TripAdvisor?

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

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

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

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


Stefan Pettersson

Att hacka skyltar

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

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

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

Trevlig helg!


Stefan Pettersson

Mardrömmen: intrång hos en CA

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

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

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

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


Stefan Pettersson

Attacken mot RSA SecurID

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

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

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

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


Stefan Pettersson

Riskanalysens mörka hemlighet — del 2

I förra delen diskuterade vi konsekvensproblemet; nästa problem med riskanalyser är sannolikhetsproblemet.

Sannolikhetsproblemet
Det vi vill göra med faktorn SANNOLIKHET är att avgöra hur mycket vi behöver bry oss om en KONSEKVENS. Kommer konsekvensen att påverka oss ofta? Kommer den att inträffa överhuvudtaget? En lindrig konsekvens som påverkar väldigt ofta kan ju, åtminstone teoretiskt, vara värre än en allvarlig konsekvens som slår sällan. Det är lite som, vad är värst: att bli träffad av en tennisboll i huvudet 30-40 gånger per dag eller att bli knivhuggen var 70:e år?

Det finns de som är väldigt bra på sannolikheter; Transportstyrelsen har t ex en rätt god uppfattning om hur vanligt det är att personbilar krockar i rondeller jämfört med fyrvägskorsningar. Tyvärr handlar det om fel sorts säkerhet, det är olyckor, inte attacker. Polisen då? De arbetar ju med att förhindra attacker (fast de kallar det för brott). I programmet Efterlyst har t ex Leif GW Persson lärt oss att det i en klar majoritet av fallen är en manlig bekant som är ansvarig när en kvinna har blivit misshandlad.

För polisen, vars verksamhet i stor utsträckning kretsar kring utredningar after-the-fact, är kunskaper om sådana sannolikheter av stort värde. Det passar dock inte oss. Vi är mer i läget där vi vill veta hur stor sannolikheten är att en familjemedlem blir misshandlad, inte hur stor sannolikhet det är att det skulle vara en manlig bekant som är förövare.

(Varning för fabricerade citat och påhittad statistik nedanför.)

”Men”, säger Leif GW, ”det är enkelt, det beror ju på vad det är för familjemedlem. Din son löper t ex större risk att bli misshandlad än din dotter eftersom män blir misshandlade oftare än kvinnor.” Här är vi något på spåren. Vetskapen att sonen är utsatt för större risk än dottern kan vara värdefull men det är inte vad vi är ute efter, vi vill veta hur stor risk sonen är utsatt för. ”Äsch”, svarar Leif GW, ”man brukar väl säga att män i snitt blir misshandlade var 26:e år. Yngre män i tjugoårsåldern får väl spö dubbelt så ofta men det finns andra faktorer som väger in också.”

Så ju mer vi vet om analysobjektet (sonen) desto mer rättvisande sannolikhet kan Leif GW ge oss. Nu är vi verkligen något på spåren.

Anta att vi är föräldrar och har enäggstvillingar. Vi vill veta hur stor risk de löper att bli misshandlade. Med hjälp av brottsstatistikoraklet Leif GW kan vi analysera situationen:

  • Tvillingarna är män och borde därför bli misshandlade, i snitt, var 26:e år.
  • Tvillingarna är män och mellan 20 och 30 år gamla och borde därför misshandlade var 13:e år.
  • Tvillingarna är män, 20-30 år gamla och är ofta inne i stan på natten. De blir därför misshandlade var åttonde år.
  • Tvillingarna är män, 20-30 år gamla, tillbringar mycket tid inne i stan och har flera kompisar som är kriminella. Det borde innebära att de blir misshandlade var tredje år.
  • Den ena tvillingen har 200 000 kr i spelskulder till maffian. Han blir hotad och misshandlad flera gånger i veckan.
  • Den andra tvillingen doktorerar i konflikthantering och blir nästan aldrig misshandlad.

Vår sannolikhetsbedömning beror på hur mycket vi vet. I det här fallet, ju mer vi lär känna tvillingarna desto större risk visar det sig att de är utsatta för. Om vi hade nöjt oss med att det var två unga män hade vi konstaterat att båda skulle bli angripna var 13:e år. När vi grävde djupare visade det sig dock att de, tvillingskapet till trots, löpte totalt olika risk för misshandel. Teoretiskt, om vi gräver vidare, skulle vi ju kunna hitta fler detaljer som förändrar den bild vi har. Någonstans måste vi dock stanna.

Det är ju smått fantastiskt var man kan komma med lite analys. Men don’t get your hopes up, inom IT-säkerhet har vi det långt ifrån lika förspänt som Polisen har. Sannolikhetsproblemet är att vi sällan är säkra på vad som påverkar sannolikheten och att vi inte har någon aning om hur sannolikheten påverkas.

I klartext betyder det här att vi i regel inte vet vad som påverkar sannolikheten att ett system blir hackat. Samtidigt, om vi nu skulle ha det, har vi definitivt ingen aning om i vilken utsträckning det påverkar.

Vi sitter och tittar på ett arkitekturdokument, konstaterar att konsekvenserna av att en angripare får kontroll över ett reverse-proxy är rätt stora och behöver bilda oss en uppfattning om hur sannolikt det är att det händer. Vår sannolikhetsbedömning här avgör huruvida det hamnar högst upp på listan eller om det hamnar under något-att-bry-sig-om-strecket. Spelar det roll att det är Apache 2 på Windows? Hur stor roll spelar det?

Epilog
Vi har ingen Transportstyrelse, vi har inget Brottsförebyggande råd, våra angripare är för intelligenta och de tekniska förutsättningarna för både oss och angriparna ändras för snabbt. Vi har inte år av samlad statistik att luta oss tillbaka mot. Förutsättningarna är såpass dåliga att man undrar om de ens är värda att försöka sammanställa. Vi är beroende av aktuell kunskap och erfarenhet hos individer när det gäller att bedöma risker, utstuderade metoder som resulterar i värden erbjuder ingen genväg.

Vanligen är försvaret mot sådana här anklagelser något i stil med ”man behöver ju inte vara helt exakt, det viktiga är ju att man försöker”. Ja, på sätt och vis. Värdet av att olika personer samlas och gnuggar geniknölarna kring det här är stort men man kanske ska nöja sig med en konsekvensanalys och hålla tungan rätt i mun när (om) sannolikheten ska bedömas. Sannolikheter rörande säkerhet som påverkar våra verkliga liv kan vara enkla att bedöma. Vår värld inom IT-säkerhet är mycket svårare, de flesta av oss har en dåligt utvecklad intution.


Stefan Pettersson

Riskanalysens mörka hemlighet

Det är en gammal sanning att hävda att säkerhet är riskhantering. Inget ont om det. Riskanalys däremot, en av de gängse metoderna för att hantera risker, hur det med dem? Är riskanalys verkligen en bra idé?

Riskanalys i teorin
Riskanalyser genomförs i bl a utvecklingsprojekt i syfte att avgöra vilken typ och nivå av ”säkerhet” som behövs för att uppnå en ”tillräckligt låg risknivå”. Först, låt oss normalisera våra begrepp. Vi håller det enkelt och nöjer oss med att

RISK = KONSEKVENS × SANNOLIKHET

där KONSEKVENS är den negativa effekten av att något (i regel oönskat) inträffar och SANNOLIKHET är, ja, sannolikheten att det inträffar. RISK defineras sedan helt enkelt som produkten av dessa, d v s det är en uppskattning av hur ofta något slår och hur hårt det slår.

Riskanalys i praktiken
Ett riskanalysarbete kan innefatta att en samling personer som har kunskaper om ett analysobjekt, ett mailsystem t ex, sätter sig runt ett bord och brainstormar scenarier som kan leda till oönskade konsekvenser för att sedan bedöma sannolikheten att de inträffar. Idéer diskuteras fram och tillbaka, vissa saker kommer man överens om, vissa inte. Ofta utmynnar arbetet sedan i en lista på scenarier, konsekvenser, sannolikheter och riskvärden, sorterade efter de senare. Projektet ska sedan använda denna lista för att prioritera i säkerhetsarbetet.

Riskanalys i verkligheten
Det finns två relativt uppenbara problem med riskbegreppet som det är definierat ovan: (1) hur bedömer vi konsekvensen? och (2) hur bedömer vi sannolikheten?

Konsekvensproblemet
Konsekvensproblemet är enklast att förklara. För analysobjektet mailsystem, tänk scenariot angripare skickar mail med vår domän som avsändare. En rimlig och fullt tänkbar risk (ibland används begreppet risk slarvigt såhär). Vad är konsekvensen av detta för oss som företag? Redan här stöter vi på problem; konsekvenserna kan vara flera beroende på vad mailet ifråga innehåller och vem det skickas till.

Scenariot måste specificeras; angripare skickar mail till vår kund och utger sig för att vara oss. Det är för öppet, vi kan fortfarande inte bedöma konsekvensen. Vad sägs om angripare lurar till sig kundens lösenord genom att utge sig för att vara oss. Mja, vi är fortfarande inte där, vad kan de göra med lösenordet? Sabba för kunden? Tappar vi kundens förtroende då? Tappar vi kunden? Vad innebär det? Här börjar vi närma oss konsekvensen.

Det stämmer ju att den enda konsekvens ett företag bryr sig om är den som kan mätas i någon valuta. Förutom i enstaka fall är det generellt slöseri med tid att sikta på monetära konsekvenser. Istället brukar man falla tillbaka på någon diskret skala i stil med obetydlig, lindrig, betydlig och allvarlig för att göra bedömningen.

Konsekvensproblemet är att medan vi närmar oss ett tillräckligt specifikt scenario där konsekvensen är möjlig att uppskatta förlorar vi täckning. Det är tydligt ovan att lura till sig lösenord är en specificering av attacker som involverar att spoofa avsändardomäner i mail. Vi täcker inte lika många scenarier helt enkelt, nu måste vi t ex också ta ställning till vad som händer om mailet till kunden ovan syftar till något annat eller är riktat till en leverantör istället.

Att vi behöver specifiera oss så här gör att processen tar längre tid, att det resulterar i mera utdata, att det blir svårare att överblicka o s v. Det är inte mycket att göra åt. Så är det när man arbetar med komplicerade system. Konsekvensproblemet är inte allvarligt, bara jobbigt.

Vi tar sannolikhetsproblemet i en uppföljande post. Fortsättning följer…


Stefan Pettersson

Bifogade filer till franska regeringen

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

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

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

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

Ytterligare verktyg:

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

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


Stefan Pettersson

Första intrycket är viktigt

TOFU är inte bara något som vegetarianer, av outgrundlig anledning, äter. (Hej CJ!) Det är även en förkortning av begreppet trust on first use. Något som Stanley utnyttjade när han sade: ”Doctor Livingstone, I presume?” i Afrika för hundra år sedan. Vad menar jag nu?

Principen är att du bara behöver lita blint på en motpart vid din första kontakt med dem. Tänk dig en blind date; din kompis (förmedlaren av dejt) säger att din träff kommer att stå och vänta utanför Åhléns entré vid Drottninggatan klockan 18 på fredag. När du kommer dit, hur vet du att det är rätt person du går fram till?

Det gör du inte.

Man kan ju tänka sig att någon med alldeles för mycket fritid skulle kunna ställa sig utanför Åhléns eller vid ”ringen” på Centralstation på luncher och kvällar. Sedan väntar de bara på att någon går fram, ser lite tveksam ut och frågar om det är Adam. Denne svarar jakande och ser vart det hela leder.

Ganska osannolikt men hey…

Vid dejt nummer två kommer det däremot att vara betydligt mindre riskfyllt då ni kommer att känna igen varandra till utseendet och inte behöver lita blint på varandra. Notera här att du kan ha haft fel vid första dejten utan att ha upptäckt det ännu. Låt oss dock anta att det i s f hade framgått vid den här tiden. (Skadan kan i o f redan vara gjord…)

Jag tar upp det här för att ”blind date-metoden” (TOFU) är en säkerhetsfunktion i flera av de protokoll vi använder varje dag. De mest framgångsrika exemplena är vanlig SSH samt SSL i de fall ingen pålitlig tredjepart (Certificate Authority) har signerat certifikatet.

Du har säkert sett följande någon gång när du har loggat in på en SSH-server första gången:

$ ssh 10.0.0.1
The authenticity of host ‘10.0.0.1 (10.0.0.1)’ can’t be established.
RSA key fingerprint is 92:0f:34:9d:a5:ea:65:70:a3:70:56:0f:4e:fa:6e:33.
Are you sure you want to continue connecting (yes/no)?

Om du svarar yes tar du precis samma risk som när du går fram till någon utanför Åhléns och frågar om han heter Adam. Du kanske har rätt och vid er nästa dejt (inloggning) kommer du inte att behöva ta ställning i frågan.

Men. Tänk dig att du vid dejt nummer tre föreslår att Adam ska komma över och käka middag. Vid utsatt tid ringer det på dörren men där står inte Adam utan någon helt annan lirare som du aldrig har träffat förut med blommor och en chokladask i handen.

$ ssh 10.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
09:c3:02:a4:50:0d:c4:d0:0b:03:be:98:5d:c8:00:8e.
Please contact your system administrator.
Add correct host key in /home/stef/.ssh/known_hosts to get rid of this message.
Offending key in /home/stef/.ssh/known_hosts:3
RSA host key for 10.0.0.1 has changed and you have requested strict checking.
Host key verification failed.
$

Hur handlar du nu? Om du var min kompis/dotter/syster skulle jag förstås rekommendera att du slog igen dörren alternativt sparkade icke-Adam i magen och sedan slog igen dörren.

Notera att den här händelsen är säkerhetsmässigt mycket värre än problemet ni hade vid det första mötet. Då fanns ingen möjlighet att avgöra om det var något fuffens, det var möjligt att det var okej. Nu är det tveklöst att något är i görningen.

Men, som felmeddelandet i OpenSSH beskriver, det är möjligt att nyckeln bara har ändrats, att icke-Adam gick till fel adress eller att du hade glömt att ta på dig glasögonen och inte känner igenom honom. Samtidigt kan det ju också vara så att liraren utanför dörren är en listig inbrottstjuv eller något värre. Det viktiga är att undersöka omständigheterna och fatta beslut utifrån dem och att inte bara chansa och släppa in icke-Adam utan vidare. Vid ert första möte var du tvungen, nu har du mer information.

Hur var det med herr Stanley då? Chansade han vid sitt första möte med Dr. Livingstone? Inte helt förstås, han hade säkerligen en uppfattning om hur doktorn såg ut redan innan han åkte. Blott en vag uppfattning om att det är en vit, skotsk herre runt 60 fungerade säkerligen ganska väl i Tanzania under 1800-talet. Jag har svårt att tänka mig att det drällde av dem.

Om vi inte vill lita blint på någon godtycklig person utanför Åhléns kan vi göra samma sak som Stanley. Ta reda på hur personen ifråga ser ut i förväg, helt enkelt. Eller för datorer, se till att du på förhand vet vilket fingerprint (SSH eller SSL-certifikat) den kommer att presentera. Då behöver du inte chansa.

Trevlig helg!

Update: om ni är intresserade av mer kan ni läsa Perspectives: Improving SSH-style Host Authentication with Multi-path Network Probing (pdf) eller Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf).


Stefan Pettersson