fredag 24 september 2010

Mozillaprojekt om CA-cert-policy

I kölvattnet av alla SSL-/PKI-skandaler kring hantering av CA-cert (bloggpost 1, bloggpost 2, bloggpost 3) så har nu Mozilla startat ett projekt för att uppdatera sin certifikatspolicy för Firefox, Thunderbird med mera. Mozilla har som bekant en egen lista på godkända CA-cert och förlitar sig inte på operativsystemet som andra webbläsare. Det här kan vara chansen att göra något åt ett av de stora problemen med SSL.

Jag har gått med på mejlinglistan där det hela kommer att hanteras. Gör det ni med! Notera att Mailman i vanlig ordning skickar ut ditt valda lösenord i klartext i välkomstmejlet så använd ett slasklösen.

Föredrar man newsgroups så finns det med:

Twitter fortfarande sårbart

Jag vet inte om ni följer utvecklingen men Twitters XSS-fix var fel. Sen fixade de igen. Och den fixen var fel. Sen fixade de igen och idag kom folk fram till att det var fel på den fixen också.

Delar av historien här:

Alltså ... överge webbgränssnittet och ladda hem en klient tills vidare. T ex:

onsdag 8 september 2010

Samy Kamkar i Sthlm 4/10

Vi har bjudit in Samy Kamkar att hålla föredrag för OWASP Sweden måndag 4 oktober.

Samy gav cross-site scripting ett ansikte när han 2005 sänkte MySpace. Inom loppet av timmar infekterades miljoner MySpace-användares profiler med Samys skript vilket gjorde det till ett av världens snabbast spridda maskar/virus. För det fick han en treårig villkorlig dom och samhällstjänst.


Numer är Samy noga med att hålla sig på rätt sida om lagen men är fortfarande grymt duktig på att hitta säkerhetsproblem och presentera dem. Den 4 oktober har han lovat att både berätta hela historien bakom MySpace-masken och köra sin färska presentation "How I Met Your Girlfriend" från sommarens Black Hat-konferens i Las Vegas. Den senare innehåller:
  • phpwn – hacket mot PHP-sessioner
  • NAT Pinning
  • Geolocation via XSS
  • HTML5 anti-waf XSS
Föredraget är kostnadsfritt och öppet för alla medlemmar i OWASP Sweden. Medlem blir man genom att gå med på mejlinglistan. Anmäler sig till föredraget gör man på Eventbrite.

Missa inte det här föredraget. Vi ses där!

söndag 5 september 2010

#CmtyHack II är över

Community Hack II, gemensamt arrangerat av OWASP Sweden och FOSS Sthlm är över. Strax över 50 anmälda, sponsrad frukost, läsk/snacks och bio. Till det behöver man bara lägga skarvdosor och datorer för en trevlig helg.


Magnus och Ians workshop om låsdyrkning var mycket uppskattad. De hade med sig en rejäl uppsättning dyrkar, modifierade nycklar, lås och verktyg.


Större delen av helgen var förstås tillägnad fritt hackande på var och ens egna projekt. Folk labbade med DNSSec, mockramverk i Python, att försöka köra Linux på PS3, att utfärda e-leg på Linux, gå igenom challenges på hackthissite.org, buggfixa befintlig foss-mjukvara och så vidare.

Det fanns en hel del intressanta projekt att spana in och människor att umgås med. En del hade tagit med mer hårdvara än andra ...


Utsikten var det som sagt inget fel på heller ...


Arrangörerna (John, Daniel och Michael) vill tacka alla som kom, KTH för lokalen och allt det praktiska samt Spotify, Omegapoint och DQ Consulting för sponsringen.

Vi siktar på att köra Community Hack III i december. Stay tuned!

onsdag 1 september 2010

Community Hack II i helgen

I helgen så genomför OWASP Sweden och FOSS Sthlm gemensamt Community Hack II. Vi kommer hålla till i lokaler på KTH vid Valhallavägen. Bland projekten och aktiviteterna finns:
  • Låsdyrkning med Ian Vitek och Magnus Bråding (kl 9-11 lördag)
  • PDF Signature Verification i fria pdf-läsare
  • Applikations- och nätverksfuzzing
  • Bygga DNSSec
Vi kör kl 9-18 både lördag och söndag. Anmälan är fortfarande öppen på Eventbrite (anmäl dig senast fredag kl 12). Just nu är vi ca 35 pers som kommer.

Lokalerna erbjuder arbetsplatser, internetaccess, fåtöljhörna, projektor, ljudanläggning och till och med fin utsikt.


Vi har också tillgång till pentryt med matbord, kylskåp, kaffebryggare, mikro med mera. Spotify sponsrar med läsk och snacks hela helgen och DQ Consulting bjuder på frukost båda dagarna!


Lördag kväll går alla som vill på bio. Vi tänkte se filmen Salt och Omegapoint sponsrar med biljetter! Om ni ska med så måste ni vara anmälda senast onsdag 1/9 kl 18 (dvs idag). Sen bokar vi biljetter.

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"