Icke-ASCII blir '?' i lösenord hos Gawker

Jag har ägnat ett par dagar åt att rota i vettiga lösningar på lösenordshantering i kölvattnet av Gawker-hacket och alla de knäckta lösenordshasharna.

Individuell saltning av varje lösenord löser rainbow table-problemet. Men så länge användare tillåts ha korta lösenord (Amazon och Apple tillåter exempelvis sex tecken) så är ren brute force fullt möjligt. Och det blir inte bättre i takt med att datorer blir snabbare.

Bästa alternativen verkar vara Secure Remote Password protocol som jag skrev om i förrgår eller att nyttja maximal långsamhet i Blowfish, det vill säga bcrypt à la OpenBSD. Olle Segerdahl kommenterade bloggen med dessa tips i februari i år under mitt inlägg om genererade toString().

ДДДДДДДД == 簡簡簡簡簡簡簡簡 == ©©©©©©©©?
Joseph Bonneau, doktorand vid Cambridge, upptäckte att Gawker tolkar alla icke-ASCII-tecken i lösenord som likvärdiga. Dvs du kan logga in på ett konto som har lösenordet "ДДДДДДДД" med valfritt annat icke-ASCII-lösenord med samma antal tecken, t ex "簡簡簡簡簡簡簡簡" och "©©©©©©©©".

Problemet visade sig vara en bugg i jBCrypt innan v 0.3 där alla icke-ASCII-tecken byttes ut mot '?' innan hashning. Det finns beskrivet i en advisory från februari i år.

Fyra slutsatser:

1. Uppgradera om ni använder jBCrypt < 0.3.
2. Använd bara ASCII-tecken i era lösenord och låt istället längden ge er säkerhet mot brute force. Det är bra när ni är utomlands också.
3. Gawker kör åtminstone nu bcrypt vilket trots allt hedrar dem. Alla ni med vanliga lösenordshashar i databasen bör ta en funderare.
4. Om Gawker körde bcrypt redan i våras så var det särdeles dumt att inte uppgradera jBCrypt till 0.3 när patchen kom i februari. Om de driftsatte jBCrypt 0.2 efter hacket så var det ännu dummare. Men det sätter återigen fingret på ramverks- och bibliotekspatchning. Vem håller koll på alla säkerhetsuppdateringar i olika lib man har länkat in? "Ingen" är min gissning i de flesta fall.

Gott nytt år!

Secure Remote Password Protocol

Du ska logga in och etablera en symmetrisk sessionsnyckel.

Attackeraren känner till autentiseringsalgoritmen.
Attackeraren har ordbok och topplista på lösenord.
Attackeraren kan avlyssna all klient/server-trafik tills du har din symmetriska nyckel.
Attackeraren kan avbryta, ändra och förfalska klient/server-trafik.
Det finns ingen betrodd tredje part.
Du vill ha något säkrare än SSH och snabbare än ren Diffie-Hellman.
Du vill ha zero-knowledge password proof, dvs du visar aldrig lösenordet utan bevisar bara att du har lösenordet.
Du vill inte att en SQL injection ska ge attackeraren en vanlig lösenordshash (MD/SHA) att knäcka. Inte ens en statiskt saltad hash duger för dig.
Du vill använda ett enkelt lösenord.

Du vill ha ...
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Version 6, hårdgranskat, från Stanford. Så coolt att jag baxnar.

Avlyssna GSM med 4 billiga mobiler + laptop

GSM, eller 2G, har ju fått en hel del stryk på sistone, inte minst i somras på Defcon. Nu verkar spelet slutligen vara över för GSM-säkerheten. Åtminstone tills operatörerna gör förändringar.

Med hjälp av fyra stycken enkla mobiltelefoner för ca 100 kr styck och en laptop så visade man lajv att man kunde avlyssna GSM-samtal och sms på Chaos Computer Clubs (CCC) årliga kongress. Wired skriver om det här.

Steg 0 – lokalisera offrets geografiska område
Om vi tänker oss att vi ska avlyssna någon så börjar det hela med att komma tillräckligt nära geografiskt. Presentatörerna visade hur man med vanliga anrop på Internet kan ta reda på i vilken stad eller vilket område en mobil befinner sig. Det sker genom att operatörerna är ganska öppna med routing-information för att slussa samtal och sms rätt.

Steg 1 – hitta nätverks-id för offrets telefon
De fyra avlyssningsmobilerna uppdaterades med ny firmware för att kunna vidarebefordra den fullständiga GSM-trafiken till laptopen. Sen skickas trasiga sms till det telefonnummer man vill avlyssna. De trasiga sms:en kommer inte synas på offrets telefon men ger attackeraren chansen att ta reda på vilket nätverks-id offrets telefon har fått tilldelat av operatören. Det i sin tur är nyckeln till att veta vilken trafik som ska avlyssnas i GSM-nätet, nämligen all trafik till och från det nätverks-id:t.

Steg 2 – knäck kryptot
När nu offrets krypterade mobiltrafik kan avlyssnas så gäller att knäcka GSM-kryptot. Det görs genom att utnyttja brister i operatörens systemkommunikation med sina kunders mobiltelefoner. Den kommunikationen är nämligen känd hur den ser ut, t ex regelbundna "Är du där?"-meddelanden.

Attackeraren vet att meddelandet i klartext är "Är du där?" och har avlyssnat hur det ser ut i krypterad form (kryptotexten). Sen används en regnbågstabell (rainbow table) på 2 TB med förberäknade kryptotexter för olika nycklar. Inom 20 sekunder hittar man vilken kryptonyckel som används för offret och vips så kan man avlyssna trafiken. Observera att man utan besvär kan spela in den trafik som försiggår under de 20 sekunder man letar efter rätt nyckel. Varje kryptonyckel används typiskt för flera samtal eller sms i rad.

Åtgärder
Presentatörena på CCC gick igenom några enkla åtgärder som mobiloperatörerna bör vidta:

• Se till att routing-information inte är så enkelt tillgänglig via nätet
• Implementera den redan standardiserade ändringen att lägga till slump ("salta") systemkommunkationen till mobilerna så att kryptot blir svårare att knäcka
• Byt kryptonyckel varje samtal och sms istället för att återanvända den

Nytt om EMV-hacket

Ni minns säkert vårens snackis om Cambridge-hacket mot chipförsedda betal- och kreditkort och standarden EMV. Jag bloggade i alla fall om det:

• Hacket mot chipkort
• Svensk bank om hacket mot chipkort
• BBC-film med hacket mot chipkort
• PIN-kontroll online i Sverige?

Cambridge-gruppen har förstås forskat vidare och i somras publicerades "The Smart Card Detective: a hand-held EMV interceptor" (pdf).

Delar av bankvärlden gillade inte den publikationen och skrev ett uppfordrande brev till universitetet. Nu har Ross Anderson svarat, punkt för punkt, under rubriken "Responsible disclosure and academic freedom" (pdf). Läsvärt.

Årskrönika 2010

Det är mellandagsrea och dags att summera ännu ett år inom applikationssäkerhetsscenen.

Jag börjar självklart med ...

OWASP AppSec Research 2010
Den stora händelsen för OWASP Sweden var förstås värdskapet för OWASP AppSec, den globala konferensen inom applikationssäkerhet. Två dagar med fem olika kurser och två dagar med tre parallella spår och en blandning av akademiska presentationer och industripresentationer.

Ärligt talat så höll det hela på att knäcka mig. Jag uppskattar min egen arbetsinsats till ~1000 timmar. Därtill kommer kommitténs hårda arbete – tack Mattias, Stefan, Martin, Alan, Carl-Johan, Michael, Kåre, Ulf och Predrag! Kate och Sebastien från OWASP är också väl värda sitt tack. På upploppet så drog jag in min flickvän Johanna och hennes kompis Marie också.

Men det var värt det. Att se det hela fungera och med 270 nöjda deltagare är en stor känsla. Dave Wichers, ansvarig för konferensfrågor i OWASP-styrelsens mejl efteråt var ännu större:

"I just wanted to thank you and your team for doing an AMAZING job at the OWASP Sweden conference. This was the best organized conference ever.
(...)
And financially it was outstanding as well! Looks like close to $100K to the good, which blows away any other European conference by far. OWASP really needs the funds as things have been very tight the past two years and this is extremely helpful to us."

Så, sponsorer, alla som var där och alla som hjälpte till – sträck på er! Vi gjorde det och vi har gjort något riktigt bra för OWASP-stiftelsen!

Applikationssäkerhet 2010
År 2010 har varit spännande på applikationssäkerhetsscenen. Min summering ...

Ny OWASP Top 10
Vi var med och spikade en ny OWASP Top 10. Många frågade sig varför den är så lik listan från 2007. Det frågar vi alla oss :/. Men jag känner faktiskt att nummer 1 – Injection – är på väg att blekna. Ett i många fall lätt problem att undvika och något som utvecklare har tagit till sig.

Största smällen enligt mig
Men jag tycker inte att OWASP Top 10 2010 har varit mest spännande utan faktiskt något som var på väg in på topp-tio-listan men som till slut ansågs sortera under det flummiga "A6. Security Misconfiguration". Vad? Jo, ramverkssäkerhet. Under 2010 så small det rejält i tre stora webbramverk:

• Spring MVC i juni
• Struts 2 i juli
• ASP.NET i september

Sanning och säga, det rörde sig ju om säkerhetsbuggar i ramverken och inget som de lokala utvecklarna kunde hållas ansvariga för. Samtidigt så satte det fingret på hur applikationslagret har blivit en allt viktigare komponent att hålla koll på. Ovanstående problem gick inte att lösa med någon normal patchhantering. Nej, utvecklarna fick kallas in oavsett tid på dygnet eller semesterplanering för att patcha, regressionstesta och driftsätta. Jag tror många säkerhetsansvariga har fått en del att fundera på sen dess. Vilka teknikval görs och av vem? Ska vi ha rutiner för "patchning" i applikationslagret? Vilka versioner av webbramverken (ofta flera) är i drift?

Säkerhetssansvariga + applikationssäkerhet = falskt?
I samband med ovanstående säkerhetsproblem i ramverk blev jag ganska ledsen över att vårt OWASP AppSec-erbjudande till SIG Securitys medlemmar bara lockade en enda person. Om någon förstår varför så får ni gärna berätta. Applikationssäkerhet och engagemang i utvecklingsavdelningen är en av säkerhetsfolkets viktigaste arenor när vi nu går mot 2011. Brandväggar, patchhantering, nätverkskonfiguration och policys i all ära men man måste också intressera sig för de applikationer som organisationen utvecklar och förvaltar.

SDLC till Sverige
2010 var också året då vi (= företaget jag arbetar på) började få flera frågor om hjälp med Security Development Lifecycle (SDLC). Flera stora svenska organisationer håller på att införa en SDLC och jag tror det kommer prägla 2011. Frågan är hur väl SDLC gifter sig med agila metoder och om säkerhets- eller utvecklingsavdelningen ska ha hand om SDLC-införandet och -förvaltandet?

Alla väntar på Internet Explorer 9
Microsoft gav sig återigen in i webbkriget med Internet Explorer 9 (än så länge beta). Kanske skönjer vi ett slut på ökenvandringen där webbutvecklare ägnade manmånader åt att få en i övrigt utmärkt app eller sajt att fungera i IE6-8. Om vi bara kan få alla stora organisationer att uppgradera till Windows 7 + Internet Explorer 9 under 2011 så går vi en lysande framtid till mötes, med stöd för HTML 5 och CSS 3.

Men är inte HTML 5 och CSS 3 en abyss av säkerhetshot? Jo, det finns mycket elände längs vägen framåt. Mario Heiderich underhåller en tämligen diger lista på problem som kan relateras till webbens sentida utveckling. Och den växer typ dagligen.

Samtidigt så är ju webben framtiden. Vi inom applikations- och webbsäkerhet ska baske mig se till att alla utvecklare kan skapa nya, grymma tjänster utan att behöva tänka på säkerhet 25 % av tiden. Webbläsar- och RFC-makarna är viktiga komponenter. Engagera er i de nya teknikerna. Läs specarna, ifrågasätt och rota runt. Sånt är vi bra på och bör bidra med.

Säkerhet 2010
Om vi blickar utanför applikationslagret så finns förstås en hel del intressanta säkerhetshändelser 2010.

Cyberkrig 1: Stuxnet
Stuxnet har goda chanser att gå till historien som 2010 års stora säkerhetshändelse. Kanske får vi aldrig reda på dess bakgrund eller syfte men bara det faktum att vi på allvar tror att en eller flera stater låg bakom det och att syftet var att sänka en kärnkrafts/-vapenindustri är nog för en Bondfilm. Cyberkrigföring har varit känt länge inom säkerhetskretsar men nu är det ett allmänt känt fenomen och något som försvarsmakter, politiker, industrier och polismyndigheter måste förhålla sig till.

Intressant nog så har Stuxnet inte på ett nog tydligt sätt väckt frågan om den många gånger skandalöst dåliga IT-säkerheten i vår infrastruktur, t ex elförsörjningen.

Cyberkrig 2: DoS mot Wikileaks
Alla denial-of-service-attacker mot Wikileaks och hur de flyttade runt sajten är en tekniskt och affärsmässigt mycket intressant resa. De jag pratat med tror Amazon primärt tänkte på alla förlorade dollar som låg i en upprörd amerikansk allmänhet mitt i julhandeln.

Inom OWASP har dessa attacker väckt frågan om hur man effektivast skyddar sig mot DoS-attacker. För det är betydligt fler än Wikileaks som utsätts för DoS och DDos. Många gånger handlar det om utpressning men som i fallet med The Jester så är det hacktivism det handlar om. En enskild person med en politisk agenda kan få för sig att attackera valfria sajter och vi borde hjälpas åt att ta fram praxis för hur man skyddar sig.

Cyberkrig 3: DDoS mot Visa och MasterCard
Sen har vi ju LOIC-attackerna mot exempelvis Visa och MasterCard. Det kan närmast liknas vid massdemonstrationer på nätet som Richard Stallman skrev. Att kalla det för intrång eller attacker blir svårt. Det blir förstås en uppsåtsfråga eftersom samma typ av belastning uppstår under extrema nyhetshändelser såsom 9/11-bombningarna och tsunamin. Är man kriminell för att man hämtar en jpg med HTTP GET flera gånger? Kanske. Godtycke är dock det första jag vill bli av med i den frågan.

Gräv och du skall finna
Under 2010 skedde ett antal uppmärksammade hack som i princip byggde på att någon börjat gräva i ett hörn av tekniken och förstås hittat en massa säkerhetshål. Exempel:

• Handla med ett stulet chipkort utan att kunna PIN-koden
• Sätt upp din egen GSM-basstation och lura alla 2G-telefoner att du är deras operatör
• Hacka en bankomat, både remote och på plats

Hela stämningen i hackervärlden är ju just sådan. "Börja gräv någonstans och du skall finna säkerhetshål!" Black Hat och Defcon inspirerade mig till just det så jag har ägnat den senaste tiden åt att implementera lite ny säkerhetsteknik och köra den med webbläsare som påstår sig ha stöd. Mycket riktigt så hittar man problem. Allt sådant kan ni följa på min nya, engelskspråkiga blogg "Apps and Security".

Nya tag hos bankerna
Jag känner också av ett omtag hos de svenska bankerna. Sverige brukar framhållas som säkert jämfört med stora delar av omvärlden och jag är böjd att hålla med. Men för att hålla den ställningen så krävs omtag. Trojaner, man-in-the-browser och hack som det mot chipkort knackar på dörren konstant. Det skulle inte förvåna mig om de svenska bankerna lanserar nya säkerhetslösningar under 2011.

John 2010-2011
Jag brukar ju nämna några personliga saker i krönikan också. Sist skrev jag om planer på ett singelsläpp under våren men någon singel har ni nog inte sett till. AppSec-konferensen slukade mig helt och hållet. Men jag ger inte upp utan har tagit tjänstledigt i tre månader för att primärt arbeta med musiken. Jag ska också försöka ta tag i min sista forskningsartikel inför doktorsavhandlingen. Lustigt nog så vill chefer och bekanta gärna nämna det där doktorsarbetet som orsaken till min ledighet. För inte kan väl en vuxen man ta ledigt i tre månader för att hålla på med musik? Jo, det kan han. Och jag står för det också. Jag ska primärt ägna mig åt musik i tre månader. Read it and weep ;).

Men jag kommer ju inte lämna OWASP under dessa månader. T ex så är jag ansvarig för spåret "Browser Security" vid OWASP Global Summit 2011 som går av stapeln i Portugal 8-11 februrari. Workshop med Chromes, Firefox och IEs säkerhetsfolk plus en massa grymma webbsäkerhetsmänniskor inom och utanför OWASP. Vill ni haka på? Bara ni kan ordna €590 till boende och mat plus en flygresa till Portugal så är ni välkomna. OWASP är som vanligt helt öppet – det är bara att dyka upp och göra sin röst hörd! Hör av er så hjälper jag till med det praktiska.

OWASP Sweden 2011
OK, jag har varit rätt slutkörd under hösten och inte mäktat med att fixa alla de där seminariekvällarna som vi vill ha. Men kraften börjar komma åter och tillsammans med mina co-leaders Mattias och Robert samt ledningsrådet så har vi några event på gång i närtid. Om allt går som jag vill så kör vi "HTTP-säkerhet" med undertecknad, Daniel "Haxx" Stenberg och Martin Holst-Swende på programmet i slutet av januari. Sen har vi kontaktat Mario Heiderich (typ bäst i världen på HTML5-säkerhet) och kommer flyga in honom februari/mars.

Vi kommer också att ta in ett par nya personer i ledningsrådet precis som lovat tidigare. Fundera på om du vill vara med och planera vad som ska hända framöver. Eller kanske din kollega?

Sist men inte minst så öppnar vi som första chapter dörrarna till en ny diskussionslista – OWASP Sweden Discuss. Där kan man skicka lästips, diskutera applikationssäkerhet, bjuda in till intressanta event och till och med skicka ut jobberbjudanden. Det enda vi inte vill ha där är reklam eller gnäll över särskilda leverantörer och varumärken. Anmäl er bums.

Med det så önskar jag och OWASP ett gott nytt år. Vi ses 2011!

Hänglåset borta i FF4

Mozilla har tagit bort hänglåset som symbol för https i Firefox 4. Istället lanserar de en site identity button. Bra eller dåligt? Diskussionen går varm på mejlinglistor och bloggar.

Läs om det hela här:
https://support.mozilla.com/en-US/kb/Site%20Identity%20Button

Book Injection (helt otroligt)

Böcker om hacking innehåller förstås ... elak kod. Så boken "XSS Attacks: Cross Site Scripting Exploits and Defense" innehåller förstås cross-site scripting-kod. Vad händer när amazon.com vill visa lite av innehållet i sådana böcker och glömmer att html-koda det hela? Det kan ni ta reda på genom följande enkla steg (inget farligt sker så vitt jag vet):

1. Logga in på amazon.com (man måste vara inloggad för att få söka i böcker)
2. Sök efter "XSS Attacks"
3. Boken ska dyka upp som första träff, välj den (eller om du är inloggad så klicka här direkt)
4. Klicka på "search inside this book"
5. Sök efter '1000' (utan fnuttar)
6. Hovra muspekaren över första sökträffen (sidan 28)

Eller läs om det hela på http://drwetter.eu/amazon/.

(Bloggpost 100 i år – tjoho!)

CSRF via POST

Jag håller på att förbereda mig för en presentation på OWASP IBWAS'10 i veckan. En av sakerna jag tänkt visa är CSRF mot POST-metoder och det sessionslösa CSRF-skyddet "double submit".

CSRF
CSRF (cross-site request forgery) innebär att en attacksajt som lurar till sig icke ont anande surfare gör anrop in till en annan sajt och därigenom utnyttjar att offrets webbläsare automatiskt lägger till sessions-/autentiseringskakor i request:et. Det blir alltså ett legitimt anrop till servern utan att offret vet eller ser något.

CSRF mot GET
Normalt snackas det ju om CSRF mot GET-metoder. Dessa kan göras med enkla img-taggar, typ:

<img src="http://www.google.com/search?q=OWASP" border="0" height="0" width="0" />

Den taggen på attacksajten kommer alltså att göra en Google-sökning på "OWASP" med offrets Google-identitet och inget syns. Skälet till att detta fungerar är att bilder får hämtas cross-domain och att webbläsaren inte har en aning om att den URL:en inte kommer returnera en bild.

Men de flesta känsliga requesten är POST (eller PUT/DELETE i dessa REST-tider) och kan alltså inte anropas med en img-tagg. En riktig formulär-POST skickar ju dessutom inparametrar i request-kroppen och kan därför inte ha dem uppradade på URL:en som i fallet ovan med ?q=OWASP.

CSRF mot POST
Kan man då göra CSRF mot POST-metoder? Japp. Tänk er en URL owasp.org/ws/oneliners som tar emot enradskommentarer av användare autentiserade till owasp.org. Då skulle attacksajten kunna innehålla följande formulär:

<form id="target" method="POST" action="https://owasp.org/ws/oneliners" style="visibility:hidden">
<input type="text" value="I hate OWASP!" name="oneLiner"/>
<input type="submit" value="Go" />
</form>

... och sen har följande JavaScript, i det här fallet byggt på JQuery:

<script type="text/javascript">
$(document).ready(function() {
$('#target').submit();
});
</script>

... vilket innebär att så fort ett offer surfar in på attacksajten så postar han/hon "I hate OWASP!" till one liners-URL:en.

POST-CSRF mot Twitter?
Går denna attack att genomföra mot stora kommersiella tjänster? Ja, det har gått men tjänsteleverantörerna har lärt sig och implementerat skydd, ofta det så kallade double submit-skyddet.

Ett CSRF-formulär som twittrar åt offret skulle se ut så här:

<form id="target" method="POST" action="https://twitter.com/status/update" style="visibility:hidden">
<input type="text" value="74691c4d14f2c70d0936e2478fb09f68d532282" name="authenticity_token"/>
<input type="text" value="This was sent via POST CSRF" name="status"/>
<input type="text" value="true" name="twttr"/>
<input type="text" value="true" name="return_rendered_status"/>
<input type="text" value="" name="lat"/>
<input type="text" value="" name="lon"/>
<input type="text" value="" name="place_id"/>
<input type="text" value="false" name="display_coordinates"/>
<input type="submit" value="Go" />
</form>

Som ni ser så finns det en intressant parameter authenticity_token. Utan att ha avkodat Twitters alla cookies så förmodar jag att det är ett double submit-skydd. För varje request till Twitter-sidan så skickas en kaka med ett slumpgenererat värde med. För att en POST ska godkännas så ska denna kaka ha samma värde som POST-parametern authenticity_token. Eftersom attacksidan aldrig kan läsa offrets Twitter-kakor innan requestet så kan den heller inte inkludera en korrekt authenticity_token. Svaret från Twitter blir:

403 Forbidden: The server understood the request, but is refusing to fulfill it.

Modern DoS för och emot Wikileaks

Wikileaks, #cablegate och hacktivism. Känsliga ämnen som jag undviker att ha en åsikt om, åtminstone med OWASP- eller konsulthatten på ;). Men det finns förstås en massa intressant säkerhetsteknik att titta på. I det här fallet belastningsattacker både för och emot Wikileaks (och Julian Assange).

De senaste två veckorna har världen i stort fått bekanta sig med två moderna former av denial-of-service – XerXeS och LOIC. Jag håller mig ju normalt till applikationslagret men det är klart att sånt här är intressant.

th3j35st3r (DoS emot)
Hacktivisten The Jester (th3j35t3r på Twitter) påpekade att hans/hennes belastningsattacker mot Wikileaks i samband med senaste släppet inte var en DDoS-attack, dvs inte en distribuerad belastningsattack med hjälp av zombie-datorer eller botnät:

Det var istället en DoS från en enda dator. Jag har alltid försökt skilja DoS och DDoS eftersom en bugg i ett protokoll, en webbserver eller en applikation kan möjliggöra en DoS-attack helt utan zombies.

The Jester – En hacktivist
The Jesters bio på Twitter lyder:
"Hacktivist for good. Obstructing the lines of communication for terrorists, sympathizers, fixers, facilitators, oppressive regimes and other general bad guys."

... och Jester omnämns typiskt "the infamous patriot hacker The Jester (th3j35t3r)".

Han (kan vara hon men hädanefter han) intervjuades av ethicalhack3r i somras. Mycket intressant att höra vad som driver en sådan här vigilant: http://www.ethicalhack3r.co.uk/security/interview-the-jester/

Jesters DoS-verktyg XerXeS
Så hur utför The Jester sina icke-distribuerade DoS-attacker? Jo, han har utvecklat ett verktyg kallat XerXeS. Jag fick tips av Pontus Engblom (tack!) om ett par videoklipp där Jester visar hur han mha XerXeS sänker två sajter han ogillar:


XerXeS DoS-attack från Infosec Island.


Nästa version av XerXeS från Infosec Island.

Att döma av dessa videoklipp så utnyttjar han buggar i webbservrar som Apache och IIS för att med en enda maskin sänka hela sajter.

XerXeS inspirerat av Slowloris?
RSnake och John Kinsella skrev ett verktyg kallat Slowloris som presenterades på Defcon 2009:



Slowloris gör partiella anrop till en webbserver och håller kopplingarna öppna, dvs avslutar inte anropet. Då och då fyller den på med nya HTTP-headrar för att hålla kopplingen öppen. På det viset konsumerar den sockets på servern. Över tid så kommer Slowloris få tag på fler och fler av webbserverns sockets och till slut tömma trådpoolen. Bam! Denial-of-service utan zombies. Pontus misstänker att XerXeS är byggt på Slowloris och jag håller med honom.

The Jester gripen?
Den 30 november så publicerade The Jester en bloggpost där han berättade att polisen har tagit sig in hos honom och beslagtagit hans utrustning och program vilket fanns beskrivet här:
http://www.th3j35t3r.net/2010/11/30/mondays-raid-search-and-seizure/

... men den sidan har tagits bort och går inte att komma åt via Googles cache heller. Oklart varför.


Low Orbit Ion Cannon, LOIC (DDoS för)
Belastningsattackerna för Wikileaks och Julian Assange (såsom de har tolkats i media i alla fall) har varit traditionella i bemärkelsen att de varit distribuerade, så kallade DDoS. Det moderna med dem har dock varit att de byggt på frivilligt deltagande mha systemet Low Orbit Ion Cannon, LOIC:

Du kan ställa in din LOIC att använda hivemind (ungefär flockbeteende) där du upplåter din LOIC till en central administratör och på så sätt kan ingå i distribuerade attacker. Din maskin kommer då att på administratörens begäran skicka en flod HTTP-, TCP- och UDP-anrop till offret och tillsammans blir det för mycket. Gizmondo har en bra genomgång av LOIC.

LOIC finns tillgängligt för Windows, MacOS och Linux. Jag skulle dock råda er att kolla upp vilken version ni laddar ner eftersom det har funnits infekterade varianter ute. Självklart kan LOIC användas för belastnings-/lasttester mot egna sajter så jag ser det inte som ett verktyg skilt från fuzzers och liknande. Men snacket kring LOIC har starka drag av hacktivism. Ett exempel är följande YouTube-reklam för att delta i veckans attacker mot Visa/MasterCard:


(OBS, ovårdat språk och en uppmaning till hacktivism i en känslig fråga)



Vad leder detta till?
Vad leder denna nya tidens hacktivism till? Ptja, det är förstås både en fråga om det öppna, fria, halvanonyma Internet och en fråga om säkerhet. För hur man än ser på Wikileaks och de aktuella DoS-attackerna så har människan gått en lång, krokig väg fram till de rättssamhällen och demokratier som finns i den fysiska världen idag (låt vara alla de skavanker som fortfarande behöver rättas till). Motsvarande rättsäkerhet och demokrati finns ännu inte på nätet. Istället är det en ganska oigenomtränglig kamp mellan stater, storföretag och aktivister. Samtidigt blir mer och mer information tillgänglig på gott och ont (integritet vs information wants to be free).

Personligen hoppas jag åtminstone att få slippa "logga in" på Internet i framtiden.

WebSockets får stryk, stängs av i FF och Safari?

Det har uppstått problem med HTML5 WebSockets vilket har fått Mozilla och Apple att droppa det tills vidare, åtminstone i default-inställningarna för Firefox och Safari.

Mozilla: "Combining the impact of the risk with the fact that the protocol is going to evolve and invalidate any shipped implementation anyhow, we intend to disable by default our Websockets implementation for Firefox 4.0 via a new configuration item."
http://www.ietf.org/mail-archive/web/hybi/current/msg04986.html

Apple: "Given the security issues identified by the paper from Adam and company, we would even consider disabling WebSocket entirely in future releases until there is a more robust handshake."
http://www.ietf.org/mail-archive/web/hybi/current/msg04782.html

Problemen beskrivs i artikeln "Transparent Proxies: Threat or Menace?"
Sammanfattning: Browsers limit how web sites can access the network. Historically, the web platform has limited web sites to HTTP, but HTTP is inefficient for a number of applications—including chat and multiplayer games—for which raw socket access is more appropriate. Java, Flash Player, and HTML5 provide socket APIs to web sites, but we discover and experimentally verify attacks that exploit the interaction between these APIs and transparent proxies. Our attacks poison the proxy’s cache, causing all clients of the proxy to receive malicious content supplied by the attacker. We then propose a revised version of the HTML5 WebSocket handshake that resists these (and other) attacks.
http://www.adambarth.com/experimental/websocket.pdf

Ny intressant säkerhetsbok

Nu är den nya boken ...
Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-'
... här:

• http://www.net-security.org/secworld.php?id=10230 (om boken)
• http://www.amazon.com/exec/obidos/ASIN/1597496049/helpnetsecuri-20 (beställning)

Den är på min önskelista för julen och på min att-läsa-lista för mellandagarna. Jag är bekant med författarna och de kan sina grejer.

Phrack #67 ute

Kulttidningen Phrack Magazine har precis kommit i nytt nummer. Förra numret kom för 1,5 år sen. Håll till godo, #67:
http://phrack.org/issues.html?issue=67

DZone presenterar OWASP

Nu presenteras OWASP och OWASP Top 10 i DZones Javalobby. Oerhört kul att vi når ut till utvecklare! Nu väntar jag bara på att senaste Top 10 presenteras på MSDN också :P.

Testa säkerheten i din webbläsare

Säkerheten i webbapplikationer är som bekant helt beroende av säkerheten i webbläsaren, både läsarens stöd för säkerhetsfunktioner och läsarens avsaknad av säkerhetsbuggar.

Det finns ett intressant testverktyg på nätet – Browserscope Security Test. Där kan du enkelt testa hur väl din webbläsare stödjer säkerhetsfunktioner såsom Strict Transport Security och om den skyddar mot kända hack såsom JSON hijacking.

Det finns också en sammanfattning av hur olika webbläsare klarar sig:

• Bäst just nu är Chrome 6 som godkänt på 15 av 16 test.
• Firefox 3.6 får bara 10 av 16 men med den senaste versionen av NoScript så når Firefox 14 av 16.
• Safari 5 får 13 av 16.
• IE 8 får 10 av 16 men IE 9-betan når 12 av 16.
• Opera får 9 av 16.

/John Wilander, chapter co-leader

Lura filtret med Unicode-ekvivalenter

Gareth Hayes, en av världens vassaste på JavaScript-hacking publicerade idag en uppslagningstabell för Unicode-ekvivalenter i JavaScript. Den kan användas för att gå förbi filter, för att skapa icke-alfanumerisk (obfuskerad) JavaScript och kanske till och med för homograf-attacker. Hela tabellen som JavaScript-struktur nedan – bara att börja fuzza.


Kolla också hans översättningsverktyg Hackvertor:
http://hackvertor.co.uk/hvurl/1o


var lookup={
"A":["00C0","00C1","00C2","00C3","00C4","00C5","0100","0102","0104","01CD","01DE","01E0","01FA","0200","0202","0226","023A","0386","0410","04D0","04D2","04D4","1E00","1EA0","1EA2","1EA4","1EA6","1EA8","1EAA","1EAC","1EAE","1EB0","1EB2","1EB4","1EB6","1F08","1F09","1F0A","1F0B","1F0C","1F0D","1F0E","1F0F","2C2D","2C6F","A656","FF21","1D400","1D434","1D468","1D49C","1D4D0","1D504","1D538","1D56C","1D5A0","1D5D4","1D608","1D63C","1D670","1D6E2","1D71C","1D726","1D756","1D790"],
"C":["00C7","0106","0108","010A","010C","0187","023B","1E08","2102","A73E","FF23","1D402","1D436","1D46A","1D49E","1D4D2","1D56E","1D5A2","1D5D6","1D60A","1D63E","1D672"],
"E":["00C8","00C9","00CA","00CB","0112","0114","0116","0118","011A","018E","0204","0206","0228","0246","0388","042D","0464","04EC","1E14","1E16","1E18","1E1A","1E1C","1EB8","1EBA","1EBC","1EBE","1EC0","1EC2","1EC4","1EC6","1F18","1F19","1F1A","1F1B","1F1C","1F1D","2130","FF25","1D404","1D438","1D46C","1D4D4","1D508","1D53C","1D570","1D5A4","1D5D8","1D60C","1D640","1D674","1D6E8","1D720","1D72E","1D75A","1D768","1D794","1D7A2"],
"I":["00CC","00CD","00CE","00CF","0128","012A","012C","012E","0130","0132","0197","01CF","0208","020A","0406","040D","0418","04E2","04E4","1E2C","1E2E","1EC8","1ECA","2110","2C0B","FF29","1D408","1D43C","1D470","1D4D8","1D540","1D574","1D5A8","1D5DC","1D610","1D644","1D678","1D724","1D75E","1D798"],
"D":["00D0","010E","0110","0189","018A","018B","1E0A","1E0C","1E0E","1E10","1E12","A779","FF24","1D403","1D437","1D46B","1D49F","1D4D3","1D507","1D53B","1D56F","1D5A3","1D5D7","1D60B","1D63F","1D673","1D6E5"],
"N":["00D1","0143","0145","0147","014A","019D","01F8","0220","1E44","1E46","1E48","1E4A","2115","A790","A7A4","FF2E","1D40D","1D441","1D475","1D4A9","1D4DD","1D511","1D579","1D5AD","1D5E1","1D615","1D649","1D67D","1D728","1D72B","1D762","1D765","1D79C","1D79F"],
"O":["00D2","00D3","00D4","00D5","00D6","00D8","014C","014E","0150","019F","01A0","01D1","01EA","01EC","01FE","020C","020E","022A","022C","022E","0230","041E","04E6","04E8","04EA","1E4C","1E4E","1E50","1E52","1ECC","1ECE","1ED0","1ED2","1ED4","1ED6","1ED8","1EDA","1EDC","1EDE","1EE0","1EE2","2C9E","A668","A66A","A66C","A74A","A74C","FF2F","1D40E","1D442","1D476","1D4AA","1D4DE","1D512","1D546","1D57A","1D5AE","1D5E2","1D616","1D64A","1D67E","1D6C0","1D723","1D72A","1D72D","1D75D","1D764","1D766","1D797","1D79E","1D7A0"],
"U":["00D9","00DA","00DB","00DC","0168","016A","016C","016E","0170","0172","01AF","01D3","01D5","01D7","01D9","01DB","0214","0216","0244","0423","04AE","04B0","04EE","04F0","04F2","1E72","1E74","1E76","1E78","1E7A","1EE4","1EE6","1EE8","1EEA","1EEC","1EEE","1EF0","FF35","1D414","1D448","1D47C","1D4B0","1D4E4","1D518","1D54C","1D580","1D5B4","1D5E8","1D61C","1D650","1D684"],
"Y":["00DD","0176","0178","01B3","0232","024E","1E8E","1EF2","1EF4","1EF6","1EF8","1EFE","FF39","1D418","1D44C","1D480","1D4B4","1D4E8","1D51C","1D550","1D584","1D5B8","1D5EC","1D620","1D654","1D688","1D6F6","1D730","1D76A","1D7A4"],
"G":["011C","011E","0120","0122","0193","01E4","01E6","01F4","1E20","A77D","A77E","A7A0","FF27","1D406","1D43A","1D46E","1D4A2","1D4D6","1D50A","1D53E","1D572","1D5A6","1D5DA","1D60E","1D642","1D676","1D6E4"],
"H":["0124","0126","021E","0389","1E22","1E24","1E26","1E28","1E2A","1F28","1F29","210B","210D","2C67","A78D","FF28","1D407","1D43B","1D46F","1D4D7","1D573","1D5A7","1D5DB","1D60F","1D643","1D677","1D722","1D75C","1D796"],
"J":["0134","0248","FF2A","1D409","1D43D","1D471","1D4A5","1D4D9","1D50D","1D541","1D575","1D5A9","1D5DD","1D611","1D645","1D679"],
"K":["0136","0198","01E8","1E30","1E32","1E34","2C69","A740","A742","A744","A7A2","FF2B","1D40A","1D43E","1D472","1D4A6","1D4DA","1D50E","1D542","1D576","1D5AA","1D5DE","1D612","1D646","1D67A","1D725","1D75F","1D799"],
"L":["0139","013B","013D","013F","0141","023D","1E36","1E38","1E3A","1E3C","1EFA","2112","2C60","2C62","2CD0","A746","A748","A780","FF2C","1D40B","1D43F","1D473","1D4DB","1D50F","1D543","1D577","1D5AB","1D5DF","1D613","1D647","1D67B","1D760"],
"R":["0154","0156","0158","0210","0212","024C","1E58","1E5A","1E5C","1E5E","211B","2C64","A75A","A782","A7A6","FF32","1D411","1D445","1D479","1D4E1","1D57D","1D5B1","1D5E5","1D619","1D64D","1D681"],
"S":["015A","015C","015E","0160","0218","1E60","1E62","1E64","1E66","1E68","2C7E","A784","A7A8","FF33","1D412","1D446","1D47A","1D4AE","1D4E2","1D516","1D54A","1D57E","1D5B2","1D5E6","1D61A","1D64E","1D682"],
"T":["0162","0164","0166","01AC","01AE","021A","023E","1E6A","1E6C","1E6E","1E70","A786","FF34","1D413","1D447","1D47B","1D4AF","1D4E3","1D517","1D54B","1D57F","1D5B3","1D5E7","1D61B","1D64F","1D683","1D6F5","1D72F","1D769","1D7A3"],
"W":["0174","1E80","1E82","1E84","1E86","1E88","2C72","FF37","1D416","1D44A","1D47E","1D4B2","1D4E6","1D51A","1D54E","1D582","1D5B6","1D5EA","1D61E","1D652","1D686"],
"Z":["0179","017B","017D","01B5","0224","1E90","1E92","1E94","2C6B","2C7F","A762","FF3A","1D419","1D44D","1D481","1D4B5","1D4E9","1D585","1D5B9","1D5ED","1D621","1D655","1D689","1D6E7","1D721","1D75B","1D795"],
"B":["0181","0182","0243","1E02","1E04","1E06","212C","FF22","1D401","1D435","1D469","1D4D1","1D505","1D539","1D56D","1D5A1","1D5D5","1D609","1D63D","1D671","1D6E3","1D71D","1D757","1D791"],
"F":["0191","1E1E","2131","2132","A77B","FF26","1D405","1D439","1D46D","1D4D5","1D509","1D53D","1D571","1D5A5","1D5D9","1D60D","1D641","1D675","1D7CA"],
"M":["019C","1E3E","1E40","1E42","2133","2C6E","FF2D","1D40C","1D440","1D474","1D4DC","1D510","1D544","1D578","1D5AC","1D5E0","1D614","1D648","1D67C","1D727","1D761","1D79B"],
"P":["01A4","1E54","1E56","2119","2C63","A750","A752","A754","FF30","1D40F","1D443","1D477","1D4AB","1D4DF","1D513","1D57B","1D5AF","1D5E3","1D617","1D64B","1D67F","1D72C","1D767","1D7A1"],
"V":["01B2","0245","1E7C","1E7E","1EFC","A75E","FF36","1D415","1D449","1D47D","1D4B1","1D4E5","1D519","1D54D","1D581","1D5B5","1D5E9","1D61D","1D651","1D685"],
"X":["1E8A","1E8C","FF38","1D417","1D44B","1D47F","1D4B3","1D4E7","1D51B","1D54F","1D583","1D5B7","1D5EB","1D61F","1D653","1D687","1D6F8","1D732","1D76C","1D7A6"],
"Q":["211A","A756","A758","FF31","1D410","1D444","1D478","1D4AC","1D4E0","1D514","1D57C","1D5B0","1D5E4","1D618","1D64C","1D680"],
                0:["0030","0660","06F0","07C0","0966","09E6","0A66","0AE6","0B66","0BE6","0C66","0CE6","0D66","0E50","0ED0","0F20","1040","1090","17E0","1810","1946","19D0","1A80","1A90","1B50","1BB0","1C40","1C50","A620","A8D0","A900","A9D0","AA50","ABF0","FF10","104A0","11066","1D7CE","1D7D8","1D7E2","1D7EC","1D7F6"],
1:["0031","0661","06F1","07C1","0967","09E7","0A67","0AE7","0B67","0BE7","0C67","0CE7","0D67","0E51","0ED1","0F21","1041","1091","17E1","1811","1947","19D1","1A81","1A91","1B51","1BB1","1C41","1C51","A621","A8D1","A901","A9D1","AA51","ABF1","FF11","104A1","11067","1D7CF","1D7D9","1D7E3","1D7ED","1D7F7"],
2:["0032","0662","06F2","07C2","0968","09E8","0A68","0AE8","0B68","0BE8","0C68","0CE8","0D68","0E52","0ED2","0F22","1042","1092","17E2","1812","1948","19D2","1A82","1A92","1B52","1BB2","1C42","1C52","A622","A8D2","A902","A9D2","AA52","ABF2","FF12","104A2","11068","1D7D0","1D7DA","1D7E4","1D7EE","1D7F8"],
3:["0033","0663","06F3","07C3","0969","09E9","0A69","0AE9","0B69","0BE9","0C69","0CE9","0D69","0E53","0ED3","0F23","1043","1093","17E3","1813","1949","19D3","1A83","1A93","1B53","1BB3","1C43","1C53","A623","A8D3","A903","A9D3","AA53","ABF3","FF13","104A3","11069","1D7D1","1D7DB","1D7E5","1D7EF","1D7F9"],
4:["0034","0664","06F4","07C4","096A","09EA","0A6A","0AEA","0B6A","0BEA","0C6A","0CEA","0D6A","0E54","0ED4","0F24","1044","1094","17E4","1814","194A","19D4","1A84","1A94","1B54","1BB4","1C44","1C54","A624","A8D4","A904","A9D4","AA54","ABF4","FF14","104A4","1106A","1D7D2","1D7DC","1D7E6","1D7F0","1D7FA"],
5:["0035","0665","06F5","07C5","096B","09EB","0A6B","0AEB","0B6B","0BEB","0C6B","0CEB","0D6B","0E55","0ED5","0F25","1045","1095","17E5","1815","194B","19D5","1A85","1A95","1B55","1BB5","1C45","1C55","A625","A8D5","A905","A9D5","AA55","ABF5","FF15","104A5","1106B","1D7D3","1D7DD","1D7E7","1D7F1","1D7FB"],
6:["0036","0666","06F6","07C6","096C","09EC","0A6C","0AEC","0B6C","0BEC","0C6C","0CEC","0D6C","0E56","0ED6","0F26","1046","1096","17E6","1816","194C","19D6","1A86","1A96","1B56","1BB6","1C46","1C56","A626","A8D6","A906","A9D6","AA56","ABF6","FF16","104A6","1106C","1D7D4","1D7DE","1D7E8","1D7F2","1D7FC"],
7:["0037","0667","06F7","07C7","096D","09ED","0A6D","0AED","0B6D","0BED","0C6D","0CED","0D6D","0E57","0ED7","0F27","1047","1097","17E7","1817","194D","19D7","1A87","1A97","1B57","1BB7","1C47","1C57","A627","A8D7","A907","A9D7","AA57","ABF7","FF17","104A7","1106D","1D7D5","1D7DF","1D7E9","1D7F3","1D7FD"],
8:["0038","0668","06F8","07C8","096E","09EE","0A6E","0AEE","0B6E","0BEE","0C6E","0CEE","0D6E","0E58","0ED8","0F28","1048","1098","17E8","1818","194E","19D8","1A88","1A98","1B58","1BB8","1C48","1C58","A628","A8D8","A908","A9D8","AA58","ABF8","FF18","104A8","1106E","1D7D6","1D7E0","1D7EA","1D7F4","1D7FE"],
9:["0039","0669","06F9","07C9","096F","09EF","0A6F","0AEF","0B6F","0BEF","0C6F","0CEF","0D6F","0E59","0ED9","0F29","1049","1099","17E9","1819","194F","19D9","1A89","1A99","1B59","1BB9","1C49","1C59","A629","A8D9","A909","A9D9","AA59","ABF9","FF19","104A9","1106F","1D7D7","1D7E1","1D7EB","1D7F5","1D7FF"],


"-":["002D","058A","05BE","1400","1806","2010","2011","2012","2013","2014","2015","FE58","FE63","FF0D"],
"|":["FE31","FE32"],
"'":["2019","201A"],
'"':["201D","00BB","301E","301F","201E","FF02"],
">":["203A","2992","2994","3009","300B"],
"]":["2046","27E7","298C","298E","2990","301B","FF3D"],
")":["208E","207E","2769","276B","2986","FE5A","FF09","FF60"],
"}":["2775"],
"(":["207D","208D","2768","276A","2985","FD3E","FE59","FF08","FF5F"],
"[":["2045","27E6","298B","298D","298F","301A","FF3B"],
"<":["2329","276C","276E","2770","27E8","27EA","2991","29FC","3008"],
"{":["2774","2983","FE5B","FF5B"],
"!":["00A1","055C","07F9","203C","2048"],
"#":["FE5F","FF03"],
"%":["066A","FE6A","FF05"],
"&":["FE60","FF06"],
"*":["204E","2051","FE61","FF0A"],
",":["055D","060C","07F8","1363","1802","1808","3001","A60D","FE10","FE11","FE50","FE51","FF0C","FF64"],
".":["0589","06D4","0701","0702","1362","166E","1803","1809","3002","A60E","FE12","FE52","FF0E","FF61"],
"/":["FF0F"],
":":["0703","0704","0706","0707","0708","0709","1364","1365","1366","1804","204F","205D","FE13","FE55","FF1A"],
"\\":["FE68","FF3C"]
}

Firesheep, så funkar det

Jag blev idag intervjuad av TV4-nyheterna om cookie-sniffaren Firesheep, en plug-in till Firefox som sniffar upp sessionskakor för populära tjänster på det nätverk man är kopplad till. Intervjun var med som ett inslag i 19-nyheterna också.

Installera och testa Firesheep
Det var lite trassel att få Firesheep att funka så jag tänkte jag postar det här för er som vill testa. Observera att jag inte går i god för programmet. Det kan visa sig vara en elak bakdörr.

1. Se till att du har Firefox 3.6.* och minst 3.6.10, t ex 3.6.11. Inte 4 beta om du inte vill experimentera.
2. Ladda hem Firesheep från GitHub.
3. Öppna xpi-filen med Firefox och installera.
4. Starta om Firefox om den kräver det.
5. Nu ska du ha en Firesheep-vy som en kolumn i vänsterkanten. Om inte så Visa -> Sidofält -> Firesheep.
6. Under Inställningar -> Sekretess: Stäng av ev privat surfningsläge, tillåt cookies och tilllåt tredjeparts-cookies.
7. Slå på Firesheep med knappen "Start Capturing".
8. Öppna en annan webbläsare, t ex Chrome.
9. Logga in på Facebook, Twitter eller Flickr i Chrome.
10. Kolla Firesheep-vyn i Firefox. Där ska dina olika konton ha dykt upp.
11. Dubbelklicka på något av dina konton i Firesheep och vips så har du genomfört en session hijacking.

Om du nu suttit på ett öppet trådlöst nät så hade alla andra aktiva sessioner dykt upp i din Firesheep-kolumn. Notera att det är olagligt att utnyttja andras sessioner utan tillstånd. Att avlyssna nätverket och titta på listan är dock helt OK.

Förkonfigurerade tjänster som Firesheep sniffar

Följande tjänster/domäner är förkonfigurerade i Firesheep:

• Amazon.com
• Basecamp
• bit.ly
• Cisco
• CNET
• Dropbox
• Enom
• Evernote
• Facebook
• Flickr
• Foursquare
• GitHub
• Google (dock ej GMail numer)
• Gowalla
• Hacker News
• Harvest
• Windows Live
• New York Times
• Pivotal Tracker
• ToorCon: San Diego
• Slicehost SliceManager
• tumblr.com
• Twitter
• Wordpress
• Yahoo
• Yelp

Den underliggande sårbarheten
Vad är då sårbarheten? Jo, tjänster såsom Facebook krypterar bara trafiken vid inloggning (ditt lösenord är alltså skyddat). Efter det så går Facebook tillbaka till okrypterad trafik. Din sessions-cookie är det som Facebook identifierar dig med efter inloggning och den skickas i klartext vid varje anrop till Facebook. Det är den trafiken som Firesheep avlyssnar och plockar upp sessions-info från.

Med din sessions-cookie i min webbläsare så är jag lika inloggad som du är.


PS.
Eftersom det valsat runt så mycket felaktig information så vill jag poängtera två saker:

1. Firesheep är en plugin till Firefox, dvs ett tilläggsprogram. Det hela handlar alltså inte om något säkerhetshål i Firefox. Det vore lika dumt som att påstå att Windows har problem för att någon skrivit en nätverksskanner som körs på Windows.
2. Offret kan surfa med valfri webbläsare – Safari, Internet Explorer, Opera, Firefox, Chrome och så vidare. Session hijacking med hjälp av cookies är inte begränsat till en viss webbläsare.

DS.

/John Wilander, chapter co-leader

500 medlemmar, ny organisation

OWASP Sweden har nu 500 medlemmar. Vilken kraft!

I samband med det och det faktum att vi faktiskt blivit tre år gamla så kommer vi omorganisera lite.

Tre ledare
Till att börja med så kommer ledarskapet bli tredelat:

• John Wilander, co-leader
• Mattias Bergling, co-leader
• Robert Malmgren, co-leader

Mattias och Robert har varit med och drivit chaptret sen starten och Mattias har varit budgetansvarig för AppSec-konferensen i somras. De kommer börja blogga här tillsammans med mig så vi kommer försöka skriva under våra inlägg.

Medlemmar kan söka till ledningsrådet

Sen vill vi också förnya ledningsrådet "OWASP Sweden Board". Därför kommer inom kort en inbjudan skickas ut till alla medlemmar där man får höra av sig med intresse att vara med. Vi vill vara en välkomnande och öppen community och jag hoppas verkligen att det finns en eller två nya som vi kan ta med i ledningsrådet.

Eder ...

/John Wilander, chapter co-leader

IE eller FF om banken får välja

Säkerheten på webben är starkt beroende av säkerheten i våra webbläsare. Bankerna borde verkligen push:a sina kunder att uppgradera och uppdatera.

Glädjande nog är det bara en av de större bankerna, nämligen Handelsbanken, som fortfarande officiellt stödjer Internet Explorer 6. Förutom Microsofts webbläsare så verkar det vara Firefox som gäller, även på Mac.

För Linuxfolket ser det riktigt skralt ut. En eloge till Skandiabanken där. Å andra sidan skriver Skandiabanken inget om Windows 7 så man undrar hur ofta sidorna uppdateras.

	Handelsb.	Nordea	SEB	Skandiab.	Swedb.
Windows	IE 6-8, FF 3.5.2+	IE 7-8, FF 3.5	IE 8, FF 3.6	IE 7-8, FF 3.5-3.6	IE 7+, FF 3+, Chrome 4+
Mac OS	FF 3.5.2+	FF 3.5, Safari 4	FF 3.6, Safari 4	FF 3.5-3.6	FF 3+, Safari 3+, Chrome 4+
Linux (Ubuntu)	Inte med e-leg	Ingen info	Ingen info	FF 3.5-3.6	Ingen info

Länkar:

Handelsbankens krav

Nordeas krav

SEBs rekommendationer

Skandiabankens stöd

Swedbanks rekommendationer

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.

https://lists.mozilla.org/listinfo/dev-security-policy

Föredrar man newsgroups så finns det med:

http://mozilla-xp.com/mozilla.dev.security.policy/

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:

http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html

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

http://www.tweetdeck.com/

http://iconfactory.com/software/twitterrific

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!

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

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.

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.

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"

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.