Välkommen till uppstartsmöte för OWASP East Sweden 3/10!

Härmed bjuder vi in till vårt första event i Linköping den 3:e oktober.

Vi har möjlighet att erbjuda dryck (öl, cider eller alkoholfritt) och macka samt lokal tack vare vår sponsor Knowit Secure AB.

När alla kommit på plats börjar vi med att presentera OWASP, vilka vi är och våra planer med OWASP East Sweden. Därefter kommer vi göra en snabb genomgång av ett av OWASPs mest kända projekt, OWASP Top 10, vilket listar de 10 allvarligaste riskerna i webbapplikationer.

Därefter fortsätter vi lättsamt med sk. brown bag sessions, där vi i grupp ser och diskuterar inspelade föreläsningar från t.ex. AppSec, Sec-T, Defcon etc. Vi tar gärna emot förslag på bra videos, till det här eventet eller framtida events. Vi avslutar därefter med diskussioner om vad ni tyckte om kvällen och era förväntningar på kommande event.

Tidsplan:
17:30 Mingel, dryck och macka
18:00 Presentation OWASP och OWASP East Sweden
18:30 OWASP Top 10 2013
19:00 Brown bag sessions
21:00 Diskussioner

Datum: 2013-10-03
Plats: Knowits lokaler i centrala Linköping, Platensgatan 8, högsta våningen

Anmälan sker på Eventbrite och är obligatorisk om man hoppas få sig en macka. Glöm inte att ange ev. matpreferenser.

http://owasp-east-sweden-start.eventbrite.com/

MVH David, Gustav och Åke

PS. Vi letar efter fler personer som vill vara aktiva att driva OWASP East Sweden. DS.

CommunityHack i Göteborg

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

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

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