Urchin är ett statistikverktyg för att analyera besökartrafik. Det köptes år 2005 av Google och är det program som ligger till grund för Google Analytics.
Nu har det kommit fram Urchin v5.7.03 verkar vara sårbart mot XSS-attacker och att det i vissa fall verkar att kringgå inloggningsskyddet. Ha.ckers.org har mer info och visar exempel på hur man kan länka in JavaScript från en extern sajt, till inloggningsformuläret i Urchin.
Vi jobbar med några servrar som det körs Urchin på och har kunnat bekräfta XSS-problemen. Här är ett exempel på en länk som jag lyckades köra (adressen och portnumret är påhittade)
Det här är inte speciellt dramatiskt egentligen, men lite kul med action. Någon postade för en stund sen en XSS-länk på den engelska delen av vår hemsida.
Jag visste att kommentarsfältet inte var skyddat mot HTML och har inte brytt mig om att fixa det förrän nu.
Attackvektorer
I kommentaren som postades låg följande html-tagg och det är alltså bara en test för att se ifall det gick att köra javascript genom kommentarerna på vår blogg.
På ha.ckers.org's XSS (Cross Site Scripting) Cheat Sheet kan man läsa att denna vektor inte fungerar på IE7 eller FF2 men på IE6 och Opera. Där finns även fler referenser till andra vektorer.
Hur man skyddar man sig mot XSS (med .NET)
Det enklaste alternativet är att låta validateRequest vara på slaget som det är som standard. Nackdelarna är att det då inte går att posta taggar över huvudtaget och att ett error visas. Läs mer om för-/nackdelar ValidateRequest här. I vår blogg som handlar om webbutveckling vill vi ju kunna tillåta html-kod från våra besökare, så vi har detta skydd avstängt.
Istället ser vi till att använda Server.HtmlEncode på all text som kommer från besökaren (det var detta jag just la till).
En bra effekt är att det numera går att skriva htmlkod i kommentarerna och den visas som den ska. Vissa har ju märkt att det inte fungerat så bra tidigare och vi borde ha fixat det för länge sen.
Testning tillåtet
Om nån är intressarad får ni gärna försöka att posta XSS till detta inlägget. Jag antar att det är omöjligt men vem vet om det finns någon obskyr metod som inte HTMLEncode klarar av att filtera.
Har även lagt in en liten funktion som ska göra om url till länkar. Där kan jag tänka mig att det kan gå att få in någon XSS-variant. Så här ser funktionen ut ifall nån vill prova att "hacka" den.
Säkerhetsexperten beni lämnade mig ett meddelande om att han har hittat 7 säkerhetshål i bloggplattformen Wordpress (senaste versionen 2.2.1).
Han har nu skapat en vänlig XSS-mask som fixar dessa hål. Jag har själv ingen Wordpress-blogg att testa på men jag litar på att beni's skript gör det han påstår.
Men nu när säkerhetshålen är publicerade är det alltså stor varning för att XSS-attacker, utförda av illvillingar kan ske. Vad gör man? Antingen avvaktar man och väntar på den officiella Wordpress-fixen, eller kör beni's skript för att fixa hålen med en gång. Se till att du tar en ordentlig backup innan.
Men dessa säkerhetshål kan en elak person bland annat, radera alla dina blogg-poster (inget roligt alls!), lägga till sig själv som användare eller annat otyg.
Om det är en bra idé att köra patchen kan jag inte svara på och jag ansvarar inte för några bieffekter som den kan ha på din blogg.
Uppdatering: Nu har Wordpress fixat säkerhetshålen. Benjamin Flesch (beNi) är imponerad att det bara tog 6 dagar. Han skriver att han inte är så nöjd med att Wordpress-teamet inte tackade honom officiellt, men nu ser jag att de har lagt till ett meddeladne i utannonseringen på deras blogg.
Communitysajten Lunarstorm har blivit attackerade av en XSS-mask och runt 5000 användare fick sina presentationer raderade. Dessa ersattes istället av en länk till den konkurrerande communityn Hamsterpaj. Skriptet la även in gästboksinlägg på nio utvalda profiler.
Via kommentarerna hos IDG hittade jag även en länk till gate 303 som också skriver om attacken och visar upp själva koden som användes.
Lunarstorm utvecklas i ASP.NET som är relativt känt för att ha bra skydd mot liknande attacker. När man studerar attackkoden ser man att _EVENTTARGET och _VIEWSTATE har modifierats. Kanske har Lunarstorms utvecklare varit oförsiktiga och stängt av validateRequest-attributet, men det kan ju inte jag svara på. Skulle vara intressant att höra mer om exakt hur denna attack kunde möjliggöras, så andra kan ta lärdom.
I februari i år hittade säkerhetsexperten beNi ett XSS-problem på Googles inloggningssida. Se en skärmdump på denna "säkra" SSL-sida kunde utnyttjas innan den tätades av Googles utvecklingsteam.
Google har enligt uppgift tackat beNi för hans upptäckt men han blev lite besviken på att man inte gjorde mer för honom. Jag förstår honom. Ett företag av Googles storlek borde kunna visa lite större uppskattning, mot de snälla hackers, som hjälper till att säkra deras applikationer helt av eget intresse.
Eftersom beNi inte kände sig nöjd med responsen från Google, väljer han nu att i framtiden inte kontakta dem innan han avslöjar fler brister.
Nu avslöjar han således bevis för hur en datorbrottsling skulle kunna komma åt alla kontakter i en användares Gmail-konto och även Google Authentication Token. Dessa finns att få tillgång till genom en sida som genererar ett prydligt XML-dokument. Riktigt skrämmande faktiskt. Om du är inloggad i Gmail så kan du prova att surfa till denna adressen så ser du själv.
BeNi fortsätter sedan med att visa hur dessa uppgifter kan utnyttjas. Till detta behövde han en ny XSS-brist hos Google. Läs mer på hans blogg för bilder och förklaring hur detta går till. Jag har även sparat en skärmdump på sista steget i demonstrationen, här ovan.
Så från och med nu vet vi att Gmail-uppgifter inte är säkra. Det räcker med ett litet XSS-hack för att komma åt alla Gmail-kontakter. Så när dett nu är allmänt känt så rekommenderar jag dig att vara försiktig med vilka länkar du klickar på som går till Google. Vid minsta tveksamhet om källans ursprung bör du inte klicka på länken.
Själv använder jag inte Gmail så mycket och har bara en kontakt där så det känns inte så farligt för mig. Men att även verifieringsnyckeln finns så lätt åtkomlig känns riktigt otryggt. Jag vill inte att någon ska kunna ta över min Google-inloggning och börja leka med mina Adsense-konton och andra tjänster som jag använder.
Månhus rapporterar att Expressen.se har gjort om designen på sin sajt men man är inte imponerade. Det påpekas att URL-strukturen har gjorts om och att många gamla adresser inte fungerar längre. Något som W3C rekommenderar att man inte bör göra.
Vidare kan man läsa hos Beta Alfa att den nya sajten inte är helt klar och att man siktar på att ha den färdig tills på tisdag. Efter detta ska man släppa nya delar och förbättringar. I kommentarerna kan man även läsa att man använder XHTML Strict fast sidan validerar ej. Och även att det numera finns en version anpassad för mobiler.
Vi har tidigare klagat lite på Expressens röriga design när vi skrev om Bildtkriget. Nu har man fått till ett något mer samlat intryck, även fast det är lite väl packat med information och för lite luft emellan. Enligt min personliga smak alltså.
I samma veva upptäckte vi även ett XSS-hål på Expressens sida. Den 23 februari mailade vi deras nyhetsredaktion för att meddela om bristerna. Vi fick tyvärr aldrig något svar så vi vet inte om detta kan ha varit till någon hjälp.
Nu är i alla fall sårbarheten fixat. Man har flyttat sidan. Kan också konstatera att de nya inloggningsfunktionerna håller en högre säkerhetsstandard.
Tidigare var det riktigt dåligt. Man avslöjade alldeles för mycket av sin interna struktur och det var lätt att förstå hur deras inloggningsfunktioner till bloggarna var uppbyggda. Här publicerar jag nu den XSS-attackvektor som jag fann på Expressen innan ombyggnaden.
Hoppas att det kan hjälpa andra utvecklare att inte göra samma misstag. Bristen var av väldigt vanlig typ och ledde till att vem som helst kunde köra egna Javascript på Expressens domän.
Under vår diskussion sa jag att det skulle vara intressant att veta hur säkerheten ser ut på den svenska webben. "beNi" som säkerhetsexperten kallar sig erbjöd sig att ta en koll på några sajter om jag skickade honom en lista. Jag tog några som var i färskt minne och har varit ganska aktuella på nätet det senaste.
Nu fick jag ett svar från beNi som har undersökt säkerheten på några av sidorna. Han orkade bara att undersöka DN, SvD och Twingly. De andra tre tyckte han laddade för långsamt för att han skulle orka jobba med dem (även fast han har en 6MBit-uppkoppling).
BeNi hittade en hel del osäkra sidor inom loppet av några minuter. Både DN och SvD innehåller luckor i säkerheten som man kan läsa i sammanställningen på hans blogg. Där finns även fem exempel på länkar som visar hur säkerhets-luckorna kan utnyttjas.
Exempel på säkerhetsluckor
De länkar han hittade på DN, SvD och Koll.se finns här under. Jag har även laddat upp skärmdumpar på hur sidorna ser ut när man besöker dem för tillfället. Observera att det inte är farligt att klicka på just dessa länkar. Men ser du några liknande länkar från en okänd källa så skulle jag definitivt avråda från att besöka dem.
Man kan alltså kontantera att Twingly klarade sig bra mot XSS-attacker. Sajten använder ASP.NET där mycket av skydden är inbyggda. Microsoft har som tur är insett att hoten är väldigt allvarliga och även gett ut speciella API:er som man kan skydda sina projekt med. Jag kommer att återkomma om dessa i senare artiklar.
För DN som använder Java och SvD som kör klassisk ASP gick det alltså inte så bra för i testet.
Utvecklare måste vakna
Det är lite pinsamt att se hur så här stora nyhetssajter inte har total koll på säkerheten. Webmasters måste vakna och förstå de nya hoten som hela tiden ökar mot webbplatser. Sajter med svagheter hotar inte bara den inre strukturen, utan själva grejen med cross-site-scripting är att det kan användas i attacker mot andra mål.
Uppdatering: Twingly indexerar XSS-länkar! Märkte just att en länk till det här inlägget dök upp på SvD. Det var inte min mening, men visar att Twingly inte verkar har något filter mot XSS. Eller så får vi hoppas på att de har kapat bort de sista querystringsen i länken. Hur som helst borde inte systemet godkänna den länk som jag kallar "säkerhetsproblem 5" här ovan. Att artikeln på SvD handlar om säkerhet och har överskriften "Jakten på trygghet gör oss otrygga" var ju endå lite ironiskt. Det visste nog inte vår tyska vän när han valde ut målet. Och jag hade inte sett innehållet när jag postade detta eftersom den riggade länken gömmer hela det riktiga innehållet. Nåväl, nu kanske SvD och Twinglys utvecklare får upp ögonen lite snabbare.
Uppdatering 2: Vi är glada att Primelabs (som utvecklar Twingly) har tänkt igenom XSS-hoten. Martins upplyser oss i kommentarerna om att deras system normaliserar urlerna innan de sparas. Vi vill också passa på att förklara att det inte är någon fara att surfa på någon av de webbplatser som har nämnts i denna artikel. Det finns dock en risk att utomstående sajter kan lägga ut länkar till DN och SvD som på något sätt kan vara ett hot mot säkerheten. Eller skicka länkar via email eller chatt-system. Det är också värt att påpeka att såna här sårbarheter är väldigt vanliga. Det visar inte minst det faktum att säkerhetsexperten beNi kunde hitta problem på två av de tre webbplatser han försökte med.
Uppdatering 3: Nu har tydligen DN också länkat till denna artikel genom Twingly. Det kan jag inte riktigt förstå eftersom XSS-länkarna till DN inte verkar ha alls samma adress. Länken "Säkerhetsproblem 2" går visseligen till nån inloggningssida som innehåller id-numret för den artikel. Det visar att Twingly har rätt stor dynamik på systemet för att länka rätt. Det är artikeln "Över 70 döda i nya bombdåd i Irak" som länkar hit. Nu ser jag ett litet problem med Twingly tjänsten. Hur får man bort länkar man inte vill ska hamna där? Måste man anmäler man dem som olämpliga? Ett enklare tillhandagångssätt för att ta bort sina egna länkar hade underlättat. Om ni på DN som kollar på detta imorgon läser detta så får ni gärna plocka bort länken. Den är ju inte direkt relevant i det sammanhanget. Om ni vill läsa andras funderingar om Twingly och relevans på nyhetssajterna så kan ni ju alltid börja på BetaAlfa.
Uppdatering 4: Jag beslutade mig för att ta bort länkarna tills vidare. Detta så att utvecklarna ska kunna få tid att lösa problemen i fred. Tror inte att dessa länkar skulle kunna användas till att ställa till någon speciell skada. Ville mest visa att man kan hitta dem på de flesta webbplatser och visa ett verkligt exempel. Sen var jag ju inte heller först med att publisera länkarna publikt. Ifall DN och SvDs utvecklare (SvD har hört av sig och tackat för mitt tips) vill ha länkarna så kontakta mig på info [at] codeodyssey.se. Annars bör ni kunna hitta dem i er besökarlogg.
Uppdatering 5: SvD har fixat problemen på sin sajt. Grattis till att det gick så fort, det var imponerande! Jag har lagt fram dessa länkar igen i utbildningssyfte till andra utvecklare. Ett annat skäl till att jag vill ha kvar länkarna är att jag vill studera hur sökmotorerna kommer att reagera på dem. Kommer de till exempel fortfarande fungera i de cachade versionerna hos Google? Det ska bli intressant att följa vad som händer.
Uppdatering 6: Vi är glada att lägga märke till att DN nu också har fixat säkerhetsproblemen. Båda sajterna lyckades alltså täppa igen hålen på bara 1-2 dagar vilket är riktigt bra.
Listan riktar sig främst till "black-hat"-optimerare som kan använda sårbarheterna för att injicera sin egen kod på url:erna för webbplatserna, och på så sätt kunna lägga in egna länkar och nyckelord. För att spamma sökresultaten alltså. Bredvid varje adress finns PR-värdet utskrivet så de lätt ska kunna välja ut mål som lönar sig.
Listan visar just nu framför allt tyska adresser men även en dansk webbshop finns med. Inga svenska adresser än så länge. Att listan toppas av det kända säkerhetsföretaget Verisign är minst sagt lite oroväckande. Just denna sårbarhet har jag inte haft möjlighet att bekräfta eftersom man måste be om tillgång från sajtägarna.
Många av de andra säkerhetshålen fungerar dock och personerna som driver sajten visar exempel på sårbarheter med reklaminlägg för deras egna tjänster de erbjuder att förklara hur man stoppar säkerhetsproblemen.
Eftersom XSS-kod är vanlig javascript så är svårigheten att skilja på elak kod från den ordinära. Varje kodbit kan även skrivas med stort antal variationer genom att t ex använda hexdecimala tecken som försvårar identifiering ytterligare.
Så länge sökmotorerna fortsätter att indexera dessa övertagna adresser så kommer problemen att fortsätta. Det är inte heller många sajtägare som ännu har fått upp ögonen för denna typ av attack. Risken att bli avstängd från sökmotorerna är så stor om du har sårbarheter som dessa och en illvillig person börjar att utnyttja dem för att sprida eget innehåll som visas under din domän.
Uppdatering: Jag blev just kontaktad beNI som äger sidan jag skrivit om. På hans begäran har jag gjort en översättning av inlägget till engelska.
Den norska webbläsarleverantören Opera meddelar nu att man släpper en patch som tätar igen säkerhetshålet i Adobes insticksmodul för PDF-filer. Ett bra initiativ eftersom det hjälper till att skydda de användare som ännu inte har uppdaterat till Acrobat Reader version 8.
Har ännu inte sett någon respons från de andra stora leverantörerna av webbläsare, hoppas att de också inser vikten av att hjälpa till att täta igen detta farliga hål.
Operas patch innehåller bara 5 rader kod, och stoppar javascript att fungera vid filändelsen .pdf:
opera.addEventListener('BeforeJavaScriptURL', function( e ) { var pathname=unescape(self.location.pathname.toLowerCase()); var hash=unescape(self.location.hash.toLowerCase()); if( pathname.indexOf('.pdf')>-1 && hash && hash.indexOf('javascript:')>-1 ) e.preventDefault(); }, false);
Idag skriver IDG.se artikeln "Pdf-filer är hackarnas nya farliga vapen - så skyddar du dig" och förklarar det nya säkerhetsproblemet som uppdagats. Adobe uppmanar användare att snabbast möjligt ladda hem den nya versionen Adobe Reader 8 (engelska), där problemet är löst. Den svenska versionen verkar precis vara släppt, när jag kollade för en liten stund sen hittade jag den inte. Att man lanserar den med sådan hast, är i så fall ett tecken på, hur allvarligt Adobe anser problemet vara.
Huvudproblemet kan visas genom exempel nedan. På följande sätt kan man köra vilken javascript-kod som man vill på klienten. Och detta medan användaren befinner sig på den domän där PDF-filen befinner sig. En öppen vektor för cross-site-scripting-attacker, nätfiske, stöld av sessionsvariabler och cookies eller för att sprida XSS-maskar med andra ord.
http://www.entersomedomain.com/thepdfyoufound.pdf#blah=javascript:alert("This is an XSS-attack example");
Detta fungerade så länge jag hade version 7.0.8 installerad, efter jag lagt in version 8 så fungerade inte attacken längre.
IDG skriver i artikeln att säkerhetshålet bara har upptäckts i Adobes insticksmodul, men andra uppgifter tyder på att set inte slutar där. Hac.kers.org har forskat vidare på sårbarheten och menar nu att det inte bara är genom en webbläsare som en attack kan ske. Det hela diskuteras vidare på Sla.ckers.org forumet och några begynnande exempel visar upp hur även PDF:er kan utnyttjas, som ligger på användarnas datorer. Farliga länkar kan sedan spridas via skräppost eller chatt-program.
Detta verkar vara ett av de farligaste säkerhetshålen som hittats på länge, och eftersom många användare kommer ha kvar version 7 eller äldre ett bra tag, så kan vi förvänta oss att det kommer skapa problem långt framöver. Är du en webbmaster som har många PDF-filer på dina sajter, och dessutom använder AJAX av någon form, bör du genast sätta dig in i vilka riskerna är. Läs även "What you need to know about the UXSS in the Acrobat Plugin" av Jeremiah Grossman.
