tisdag 4 januari 2011
XSS via PayPal-betalningar
Ibland händer sånt som man normalt bara skämtar om. Book injection förra månaden var en sådan grej. Nu visar det sig att meddelandefältet vid PayPal-betalningar tillåter JavaScript, dvs möjliggör cross-site scripting. Man slutar aldrig att förvånas.
söndag 2 januari 2011
Ny fuzzer hittar 100 buggar i WebKit, FF, IE och Opera
Michal Zalewski (@lcamtuf) släppte igår sin nya fuzzer cross_fuzz som har hittat hundratalet buggar i alla de stora webbläsarna. Den åstadkommer sin magi genom att parse:a DOM:en i en flik, samla info om alla objekt, ändra egenskaper och anropa funktioner, sen stänga det dokumentet och använda de insamlade referenserna i en ny flik. Webbläsarna får typiskt problem med sin garbage collection där objekt överlever fast de inte ska och så vidare. Läs om algoritmen och buggarna på hans blogg.
En allvarlig del i det hela är att teamet bakom Internet Explorer inte patchat de buggar som är av säkerhetskaraktär. På sex månader. Michal publicerar en logg där man kan följa den frustrerade diskussionen med IE-folket. Börja läs vid "1) July 26, 2010: original report to MSRC, noting multiple crashes and GDI corruption issues. Acknowledged, case 10205jr."
En allvarlig del i det hela är att teamet bakom Internet Explorer inte patchat de buggar som är av säkerhetskaraktär. På sex månader. Michal publicerar en logg där man kan följa den frustrerade diskussionen med IE-folket. Börja läs vid "1) July 26, 2010: original report to MSRC, noting multiple crashes and GDI corruption issues. Acknowledged, case 10205jr."
fredag 31 december 2010
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:
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:
- Uppgradera om ni använder jBCrypt < 0.3.
- 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å.
- Gawker kör åtminstone nu bcrypt vilket trots allt hedrar dem. Alla ni med vanliga lösenordshashar i databasen bör ta en funderare.
- 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!
onsdag 29 december 2010
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.
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:
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
måndag 27 december 2010
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.
söndag 26 december 2010
Å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:
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:
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?
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:
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
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!
Prenumerera på:
Inlägg (Atom)