tisdag 24 augusti 2010

Säker interaktionsdesign

Via Twitter så snubblade jag över en tio-i-topp-lista på principer för säker interaktionsdesign.

Såna listor tenderar att bli både krystade och svävande men jag har haft ett intresse för hur interaktionsdesign påverkar säkerhet ända sen jag tillsammans med Viiveke Fåk införde profilen "Säkra, interaktiva datorsystem" på D- och IT-programmen i Linköping.

Därför gav jag mig i kast med att beskriva dessa tio principer på svenska. En grannlaga uppgift. Men det finns allt ett antal sanningskorn i det hela!


Path of Least Resistance
Se till att det bekvämaste sättet att arbeta med applikationen kräver minsta möjliga rättigheter.

Active Authorization
Se till att behörigheter bara kan delas ut med användarens aktiva samtycke.

Revocability
Erbjud användaren möjligheter att begränsa andras behörigheter till hans/hennes resurser.

Visibility
Se till att användaren känner till andras behörigheter till de egna resurserna, särskilt behörigheter som påverkar hans/hennes beslut.

Self-Awareness
Se till att användaren känner till sina egna behörigheter att använda resurser.

Trusted Path
Skydda användarens kontakt med (automatiska) system som ändrar behörigheter i hans/hennes ställe.

Expressiveness
Se till att användaren kan uttrycka säkerhetsregler i ord och termer som är anpassade till den typ av arbetsuppgifter som utförs i systemet.

Relevant Boundaries
Se till att distinktioner och begränsningar är relevanta för den typ av arbetsuppgifter som utförs i systemet.

Identifiability
Presentera systemets olika resurser och funktioner på ett särskiljande och sanningsenligt sätt.

Foresight
Tydliggör konsekvenserna av beslut som användaren förväntas ta i användandet av systemet.


Originalet och referenser hittar ni här.

lördag 21 augusti 2010

Säkrare SSL med Strict-Transport-Security

En riktig säkerhetssnackis har varit Strict-Transport-Security (STS) som motmedel mot ett flertal av de man-in-the-middle-attacker som presenterats mot SSL/HTTPS. Nu var det till och med tema i veckans Steve Gibson-podcast "Security Now!" så det är hög tid att skriva om det här.

Användarna accepterar varningar
Vem har inte sett sin webbläsare varna för ett felaktigt SSL-cert? Och vem har inte klickat vidare i övertygelse om att det ligger slarv bakom, dvs att driften inte köpt och driftsatt nytt cert i tid?

Jag har faktiskt bara träffat en IT-människa som verkligen bromsat in vid den där varningssidan och han var inte någon säkerhetskille. Det var en utvecklare "på andra sidan" mitt projekt som mejlade oss och cc:ade beställare och chefer för att påtala denna "show stopper". Han skulle göra ett anrop till vår testmiljö där vi självklart inte körde med ett skarpt cert. Vi fick mejla honom plus alla chefer och förklara att han fick göra ett säkerhetsundantag.

Men om vi bortser från denna enda person så är beteendet där ute att klicka sig förbi varningen. Folk i gemen har vant sig vid att webbsidor kan orsaka varningar men fungera bra. Så vad säger att internetbanken inte ska kunna uppvisa en sån varning? Vips så har vi sänkt ribban rejält för man-in-the-middle. Attackeraren behöver inte skapa ett SSL-cert signerat av en godkänd CA om offret ändå godkänner hans/hennes fulcert.

Strict-Transport-Security lovar "Inga fulcert"
Idén bakom Strict-Transport-Security är att webbservern kan publicera en header som säger:
"Jag levererar bara sidor över https och garanterar att jag inte kommer köra med ett ogiltigt certifikat. Om du skulle få svar på den här adressen med ett ogiltigt certifikat så ska du på inga villkor tillåta användaren att klicka sig vidare. Detta gäller i X sekunder framåt."

Formellt ser svaret från servern ut så här (verkligt exempel från https://www.paypal.com/se):

shell> curl -i https://www.paypal.com/se

HTTP/1.1 200 OK
Date: Sat, 21 Aug 2010 19:47:14 GMT
Server: Apache
Cache-Control: private
Pragma: no-cache
Expires: Thu, 05 Jan 1995 22:00:00 GMT
Set-Cookie: [snip/]; domain=.paypal.com; path=/; Secure; HttpOnly
(... fler cookies ...)
Vary: Accept-Encoding
Strict-Transport-Security: max-age=500
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Servern kan också lägga till information om att regeln ska gälla alla subdomäner. Grammatiken ser ut så här:

Strict-Transport-Security =
"Strict-Transport-Security" ":" "max-age" "=" delta-seconds [ ";" "includeSubDomains" ]

Webbläsaren tillåter inga fulcert
Grunden till STS-funktionen är att en STS-medveten webbläsare (just nu bara Chrome och Firefox med NoScript) måste avbryta kommunkationen med en STS-sajt om certifikatet är ogiltigt. Det får inte finnas en chans för användaren att klicka sig förbi någon sorts varning. Tuffa tag helt enkelt.

Ett annat krav på en webbläsare som förstår STS är att den automatiskt gör om alla HTTP-anrop till HTTPS-anrop om det är en STS-sajt med giltig tidsstämpel. Det hindrar attacker i stil med SSLStrip.

Webbläsaren noterar servern som STS
När en STS-medveten webbläsare får en STS-header så måste den:
  • Lägga till servern till sin lista över kända STS-servrar
  • Uppdatera informationen om max-age och includeSubDomains om dessa fält skiljer sig från vad som sparats tidigare för den servern
Om webbläsaren får en HTML-kodad HTTP-header med STS, t ex ...

<META HTTP-EQUIV="Strict-Transport-Security" VALUE="max-age:0">

... så får den taggen inte användas. Annars skulle en attackerare kunna injicera STS-direktiv.

Server-konfiguration
Om man överväger att använda STS på sin server så är det några saker man ska tänka igenom.

Först är förstås hur bra man är på att sköta sina SSL-certifikat eftersom en STS-sajt helt enkelt inte kommmer att fungera om certet är ogiltigt. Har man ett kalendarium? Som fler än en person har ansvar för? Med rutiner som fortfarande funkar om tre år när certet går ut? Jag har mött alltför många organisationer som har dåligt samvete över sin obefintliga hantering av SSL-certifikat.

Sen måste man bestämma sig för en strategi för tidsstämplarna. Ska man alltid svara med ett fast tidsspann, t ex en vecka eller ska man svara med antal sekunder kvar tills certet går ut?

Svenska internetbanker kör inte STS. Än.
OK, tämligen få webbläsare har ännu stöd för STS men inget hindrar seriösa tjänsteleverantörer att implementera STS på sina HTTPS-servrar. Jag kollade de fyra stora internetbankerna. Ingen av dem kör STS. Än.

Tomma resultat för följande curl-anrop:

curl -i https://internetbank.swedbank.se/SecurityServer/SecurityServer | grep "Strict-Transport-Security"

curl -i https://internetbanken.privat.nordea.se/nsp/engine | grep "Strict-Transport-Security"

curl -i https://taz.vv.sebank.se/cgi-bin/pts3/wow/wo10.c1010.f001?I= | grep "Strict-Transport-Security"

curl -i https://secure.handelsbanken.se/bb/glss/servlet/prelogon?id=seprivsv | grep "Strict-Transport-Security"

tisdag 17 augusti 2010

Struts 2.2.1 släppt

Äntligen har Apache släppt Struts 2.2.1 med patchen för säkerhetshålet jag skrev om tidigare.

På projektets sida för offentliggöranden står att läsa:

The Apache Struts group is pleased to announce that Struts 2.2.1 is available as a "General Availability" release. The GA designation is our highest quality grade.
(...)
This release includes a number of new features and bug fixes since the 2.1.8.1 GA release, including important security fixes regarding remote server context manipulation by injecting OGNL expressions in request parameters.

Sammanfattning Black Hat och Defcon

Tillbaka till Sverige.
Tillbaka till jobbet.
Tillbaka till verkligheten.
Eller var det verkligheten vi lämnade i Vegas och bubblan vi återkommit till?

Här är mina intryck från världens största säkerhetskonferenser – Black Hat USA och Defcon.

Allt kan och ska hackas
Mina kollegor Michael Boman, Marcus Hartwig, Peter Swedin och jag träffade en hel del intressanta människor under de två konferenserna. En av dem – Jesse Ou från Cigital – sammanfattade intrycken väl: – It's all depressing, isn't it?! Everything gets hacked.

Black Hat är tämligen kommersiellt medan Defcon känns som en gräsrotsrörelse. Samtidigt har de ett gemensamt tema – allt kan och ska hackas. Känslan på Black Hat var att hacken syftade till att höja medvetenheten och på sikt säkerheten. Känslan på Defcon var snarare att det var coolt att knäcka system, punkt.

Hur som helst så är listan på de säkerhetshack som presenterades tämligen deprimerande:
Säkerhet i två världar
Det bestående intrycket är att IT-säkerhet är uppdelat i två världar.

Värld nummer ett där de flesta av oss arbetar. I den världen så betyder säkerhetsfunktioner, säkerhetsregler, säkerhetsrutiner och säkerhetsprinciper allt. Under sådan flagg säljer vi kunskap och system för att bygga och upprätthålla säkerhet.

Värld nummer två där en del av oss tillbringar fritiden men de flesta är åskådare. I den världen så kringgås säkerhetsfunktioner, säkerhetsregler, säkerhetsrutiner och säkerhetsprinciper konsekvent. Men där finns inga pengar att tjäna om man vill vara på rätt sida om lagen.

Vilken säkerhet efterfrågas?
Den säkerhet som kunder efterfrågar och säkerhetsföretag säljer har ganska lite att göra med hur system hackas. Hackerkulturen går ut på att inte acceptera specifikationer och garantier utan istället undersöka sanningen och röka ut säkerhetshålen som alltid finns där.

OWASP befinner sig i ett mellanläge. Med säkerhet i applikationsutveckling försöker man undvika att utgöra lågt hängande frukt. OWASP Top 10 ger tips om vanliga risker och misstag. OWASP ESAPI ger byggklossar för bättre säkerhetsfunktioner i webbsystem.

Men om vi efterfrågar riktig säkerhet så finns i dagsläget ingen annan väg framåt än tidskrävande, explorativ säkerhetstestning. Och det är det ingen som håller på med.

Förutom de som presenterar på hackerkonferenser förstås.

onsdag 4 augusti 2010

Fortfarande ingen patchad Struts 2

Apache-folket har skippat Struts 2.2.0 och röstar sen 17 juli om version 2.2.1 och ingen har sagt något där på 2,5 veckor. Under tiden är hundratals svenska webbapplikationer antagligen vidöppna för hack. Testbygge för 2.2.1 finns. Temporär fix har jag publicerat här.

Senaste releasen av Struts 2 är från september 2009. Kanske har den långa tiden kastat grus i release-maskineriet? Philip Luppens i teamet kommenterar det i alla fall så här:

"Guys, can we please get some more votes in? I cannot understand we cannot push out a simple release when all the work has been done ..."

söndag 1 augusti 2010

Android-malware utan permissions

Anthony Lineberry, David Richardson och Tim Wyatt höll en grymt intressant presentation och demo om Android-säkerhet. Otroligt hur de kunde kringå alla begränsningar som egentligen ska finnas för appar.

Lite om Androids säkerhets- och processmodell
Varje Android-app har en AndroidManifest.xml som deklarerar
pakettillhörighet, komponenter och tillstånd (permissions) som appen behöver på mobilen.

En körande app är en aktivitet som ligger på aktivitetsstacken. Aktiviteten på toppen är den som kör, de andra är i pausläge.

En applikation kan starta andra appar som då körs i appens process. Anroparen har dock inte alltid tillgång till den startade aktivitetens data eller tillstånd.

När man laddar ner en app från Google Market så får man först reda på vilka tillstånd den kräver. På det viset kan användaren undvika skumma appar. Men om appen inte kräver några tillstånd så laddas den hem direkt. Det låter intressant – vad kan en attackerare göra med noll tillstånd?

En hel del!

Reboot utan tillstånd
En app utan tillstånd får inte anropa REBOOT. Men det går att tömma ut Androids minnesresurser och tvinga fram en ombootning. Genom att skapa osynliga views. Efter 2001 st views som alla skapar globala referenser så får telefonen en SIGSEGV och bootar om.

Starta automatiskt vid boot utan tillstånd
Applikationer får inte begära att de ska startas vid omstart av telefonen. Specifikt så krävs receive_boot_complete-tillstånd. Men det tillståndet kollas inte!

Starta efter installation utan tillstånd
Applikationer får allmänt inte starta automatiskt efter nedladdning. Därför förväntar sig inte användaren det utan kommer att tolka det som att Android OS:et ber om uppmärksamhet om något händer direkt efter att han/hon laddat ner en app.

Tänk dig att du installerar en app från Google Market som automatiskt startar en phising-attack som begär ditt lösenord. Det kan man åstadkomma genom att utnyttja hur Google Analytics används. Analytics ska nämligen få logga vad och hur du har laddat ner. Kolla Googles dokumentation, kopiera koden och peka ut din egen phising-app.

Internetaccess utan tillstånd
En applikation måste be om tillstånd för att få kommunicera med Internet. Så kan attackerarens app göra det utan tillstånd? Jajamen. Låt oss börja med uppladdning av data.

Appen har inte uppladdningstillstånd själv. Men det har webbläsaren och appen har rätt att öppna sidor via webbläsaren. Risken är dock att användaren upptäcker det och stänger av ("Ehh ... varför drogs webbläsaren igång och gick till den där skumma sidan?"). Så hur gör attackeraren? Jo, han/hon gör alla uppladdningar när telefonens skärm är släckt! Och så fort uppladdningen är klar så går webbläsaren vidare till exempelvis google.com så att det inte ser skumt ut när användaren startar skärmen igen.

Nedladdning då?

Ja, det går ju att hämta med webbläsaren. Alla filer lagras då på SD-kortet och där får appen läsa utan tillstånd. Men det skapar en massa notifieringar som användaren kommer se i en lista plus att det blir skumma filer som skräpar.

Istället utnyttjar Androids funktionalitet för att mappa specialprotokoll med appar. T ex så startar geo:-protkollet Google Maps direkt. Attackeraren kan deklarera och mappa sitt eget protokoll (android:scheme="nethack" adroid:host="data") och anger sen bara nethack: istället för http i URL:en. Voilà -- nedladdning som skickar data direkt till appen!