Stefano och Martin till Göteborg den 3/11

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

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.

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


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

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

1. Exposure (Discoverability)
2. Threat (Exploitability)
3. Risk (Impact severity)

Program Quality Bucket

1. Pulse (Vulnerability~Input, vulnerability per input)
2. Frequency (Window of exposure) (< 20 dagar sällan intrång, > 200 dagar får oftast intrång)
3. 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?

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:

1. 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.
2. Fler skrämmande "mainstream"-historier som utbildar. (tänk: Män som hatar kvinnor)
3. 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

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:

1. Upptäckande av händelse
   
2. Analys
   
3. Avgörande om ett angrepp pågår
4. Val av svarsmetod
5. 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

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

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:

1. Tappad smartphone leder till dataläckage. Siffror från storbrittaniens myndigheter: 2% av alla enheter 2008 borttappade
2. Data som delas utan vetskap och avsikt. Inom telefonen kan det ske genom delade resurser (adressbok, tangentbordscache); externt genom exempelvis geo-taggning av bilder.
3. 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

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

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:

1. 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.
2. Säker kod.
3. 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

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!

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:

1. @owasp :)
2. @theharmonyguy
3. @internot_
4. @securityninja
5. @_mwc
6. @0x6D6172696F (Mario)
7. @webtonull
8. @garethheyes
9. @jeremiahg
10. @WisecWisec

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

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

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)

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

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

1. The Image That Called Me (pdf) – om SVG-säkerhet
2. 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)

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:

• Site Security Policy (pdf)
• DOM Sandboxing (pdf)
• HTML5 Security (pdf)
• EcmaScript 5 Security (pdf)
• Enduser Warnings (pdf)

Facebook-inställning för HTTPS

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:

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

Mario Heiderich till OWASP Sweden 7/3

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

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

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

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

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

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.

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

Den svaga länken (rolig bild)

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

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

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

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