Gårdagens trojan hos Expressen är ett aktuellt exempel på varför det argumentet inte håller.   Moderna sajter återpublicerar på olika sätt info som kommer från annat håll.

I det här fallet tycks det ha varit Expressens väderinfo-leverantör som varit den egentliga boven. Men, för den skrupellöse finns det en del pengar att tjäna genom trojaner och botnät, det kan lika gärna ha varit en betald annons som innehållit skadlig kod och som levererats via något av de externa annonsnätverk som Expressen använder.

Om du är i “det händer inte mig”-gruppen, dra upp huvudet ur sanden och installera virusskydd.  Nu.

(om du är i “jag kör mac/linux/löksoppa”-gruppen och tänker kommentera så har jag ett boktips hos Adlibris)

Ganska märkligt om Apple byggt sin lösning på det sättet, normalt har man en central databas som listar alla giltiga engångskoder så att man enkelt kan verifiera dem när de ska användas som betalning. Så fungerar tex skrapkoderna för att fylla på telefonkort och på det sättet behöver själva koden inte vara särskilt stark i sig.

Jag har inte sett någon officiell kommentar från Apple än.

Kanske är detta bara ytterligare ett exempel på att security by obscurity aldrig fungerar.

En snabb koll på svenska Tradera visar en del iTunes-presentkort att köpa till priser som tycks för låga.  Ett kort värt 200 USD (ca 1750 kr idag) säljs tex för 750 kr.  Koden levereras via email.

I kvällens mailskörd fann jag ett mail från Spotify som uppmanade mig att byta lösenord på mitt konto.

Hade de blivit hackade?  Nej.

Däremot har det funnits en svaghet i protokollet som används när användarens Spotify-klient pratar med Spotify-servern. Protokollet innehåller bland annat funktioner för att fråga servern om användarinformation. Med utgångspunkt från användarnamnet gick det att få fram fullständigt namn, adress och andra uppgifter, tex om användaren hade ett betalkonto eller inte. Det gick inte att läsa ut fullständig kontokortsinformation men de fyra sista siffrorna i en betalande användares kortnummer fanns tillgängliga.  Märkligt nog gick det också att läsa ut det “salt” som är en del i processen när användarens lösenord krypteras.  Detta skulle ha kunnat användas för att göra en brute-force attack och testa sig fram till rätt lösenord, för en användare i taget.

Den som designat protokollet måste ha haft en riktigt dålig dag, självklart ska de här delarna av användarinfo aldrig lämna servern.   Nu tycks det som att Spotify själva insett det redan i december och tagit bort de olämpliga delarna.

Att med brute force läsa ut alla användare och deras lösenord hade varit extremt tidsödande och det är inte sannolikt att det har skett.  När Spotifys VD, Daniel Ek, säger till IDG att “risken för den enskilde användaren är mycket liten” så har han antagligen rätt.

Frågan är varför de valde att meddela användarna nu, mer än två månader senare?   Förklaringen finns antagligen i programmet Despotify, som är en alternativ klient avsedd att kunna köras i tex Linux där ingen officiell Spotify-klient finns.  Despotify är open source, all källkod finns tillgänglig och i den hittar man också kommentarer om bristen i protokollet.

Min gissning är att Spotify tittat på källkoden, upptäckt dessa kommentarer och insett att det bara var en tidsfråga innan någon öppet skulle börja diskutera brister i Spotify. Det hade varit rejält dålig PR, man ville förekomma den diskussionen och gick därför själva ut med information.

Spotify har ingen lätt uppgift när de försöker få musikindustrin på sin sida och har inte råd med någon dålig publicitet.  Att själva ta initiativet och berätta om detta är ett försök att minimera skadan.

Det hade naturligtvis varit bättre om de informerat redan när de själva upptäckte och åtgärdade det potentiella problemet, men jag har viss förståelse för att de inte gjorde det.  Det var helt enkelt inte troligt att någon användare drabbats.

Tyvärr formulerar pressen sig ändå på ett sätt som ger intryck att tusentals användares information är ute i det fria.  Trist eftersom Spotify är ett fantastiskt bra sätt att (lagligt) hitta musik via nätet.

Läs också hos: Aftonbladet IDG IDG Expressen Affärsvärlden (som inte tycks ha förstått pressmeddelandet) och Sydsvenskan (som inte heller kan läsa innantill).  Spotify skriver förstås själva på sin blogg.

(Om man är mer konspiratoriskt lagd kan agerandet förstås vara ett sätt att svärta ner Despotify genom att antyda att de som ligger bakom Despotify skulle vara ansvariga för problemet.  Jag hoppas att så inte är fallet.)

Update: Despotify svarar hos IDG

1. Köp en lista med stulna men fungerande kortnummer.
2. Köp SMS i bulk av lämplig leverantör med hjälp av de stulna kortnumren.
3. Köp tillgång till några timmars användande av ett botnet
4. Använd botnetet för att generera fejkade röstnings-SMS, med avsändarnummer som originerar från “rätt” land
5. Vinn omröstningen

Om man skulle vara en glad hacker, låt säga en rysk för exemplets skull, med ett bra kontaktnät, så kanske man inte ens behöver betala för punkterna 1 och 3 eftersom man kan få tillgång till det ändå.

Apropå ingenting alls, då. Resonemanget ovan är givetvis helt hypotetiskt och har förmodligen ingen verklighetsanknytning.

Att jag överhuvudtaget funderar över detta beror på att Per Hellqvist’s blogg ikväll ledde mig till Jonathan James som drar märkliga och felaktiga slutsatser. Jonathan skriver om att Verket för Högskoleservice blivit hackade.

Jonathan googlade efter andra sajter som sprider samma skadliga kod och hittade den bland annat på två kinesiska sajter som han konstaterar tillhör kinesiska myndigheter. Utifrån det drar han slutsatsen att kinesiska myndigheter ligger bakom attackerna och Per Hellqvist är snabb att påstå att Jonathan lett detta i bevis.

Det gemensamma i den senaste attackvågen är att man attackerar enkla, men vanligt förekommande, mål, närmare bestämt gamla sajter skrivna i ASP. Själva attackerna sker från botnets som inte diskriminerar några sajter, det är en fullständig bombmatta där man försöker göra en SQL injection och direkt går vidare till nästa sajt utan att analysera resultatet.

De två kinesiska sajter som Jonathan pekar ut är också skrivna i ASP. Den gamla fransiskanermunken William of Ockham skulle antagligen komma fram till en slutsats av detta faktum, men resultatet skulle inte bli detsamma som Jonathans. Det är helt enkelt inte mer sannolikt att dessa två sajter avsiktligt sprider den skadliga koden än att någon av de sajter jag räknade upp i början gör det.

Jag vet inte om Per Hellqvist och Jonathan James har en politisk agenda, men den här typen av propaganda och desinformation fyller ingen annan funktion.

Inget nytt i den delen, det handlar om hyfsat kända problem som “bara” drabbar den som envisas med att använda Internet Explorer. Det som är intressant och skrämmande är mängden sajter som laddar scriptet för den intet ont anande besökaren.

Bland de drabbade hittar man sajter från FN, flygbolag och ambassader. Resesajter, privata sajter, forum och många andra. Kort sagt, sajter som man besöker utan att ha anledning att tro att de vill skada ens dator. Vid en snabb kontroll igår hittade jag ett helt gäng svenska sajter som drabbats.

Det de här sajterna har gemensamt är att de är databasdrivna. Det innehåll som visas för besökaren finns inte lagrat som HTML-sidor i textfiler utan ligger istället i en databas. Det gör att sajternas “redaktörer” via ett administratörsgränssnitt enkelt kan uppdatera innehållet, lägga till artiklar eller ändra rubriker och texter.

Problemet är att om den illvillige hackern Filip Fjunmustasch lyckas ändra i databasen, så kommer hans ändringar att visas för sajtens besökare. Den snabbtänkte läsaren tycker nu förstås att den som äger sajten borde se till att Filip inte kan ändra i databasen. Det är så sant, men det är inte alla sajtbyggare som har tänkt så långt.

Bombmatta

Veckans angrepp är inte på något sätt riktat mot specfika sajter. Det är en bombmatta som lagts ut, praktiskt taget varenda sajt i världen har blivit utsatt för ett intrångsförsök men bara de sajter som varit sårbara har drabbats. Nu är det förstås inte fråga om en miljon kineser som manuellt suttit och besökt alla sajter i världen utan en programvara som systematiskt bearbetat alla sajter.

Den teknik som använts kallas SQL Injection och innebär att man som besökare på en websajt tillåts skicka ett SQL-kommando till sajten som glatt skickar det vidare till databasen utan att fundera över om det är klokt eller inte.

I de fall angreppet lyckats har javascript-kod lagts in i databasen och därmed visats för besökarna. De besökare som använt Internet Explorer har hämtat hem scriptet och i alltför många fall drabbats av elak kod som installerats i deras dator.

När jag skriver detta ser det ut att vara mer än 700 000 sajter som drabbats (en enkel google-sökning visar ett ungefärligt antal). Många systemadministratörer och webmasters torde ha slitit sitt hår de senaste dygnen. Hur många användare som fått sina datorer infekterade för att de besökt någon av dessa sajter vill jag inte ens tänka på.

Vad kan man då lära sig av detta?

Som användare kan du se till att inte använda en trasig webläsare. Oavsett vilken du föredrar ska du se till att den är uppdaterad, även en version som bara är några månader gammal kan innehålla säkerhetshål som Filip och hans kompisar redan hittat. Ett uppdaterat virusskydd hjälper också.

Om du varit med om att bygga någon av de drabbade sajterna så kanske du borde överväga att byta yrke. Eller om du trivs med det du gör, se till att lära dig allt du behöver för att göra ett bra jobb. Ta ansvar för vad du levererar.

(IDG har också rapporterat nu: här och här)

Spray har inte ens orkat använda en grundläggande hash för att lagra lösenordet.

(klicka på bilden för större version)

(edit: idg.se: Intrång på spray.se)

För tillfället är sajten nere och visar det här smått underhållande meddelandet:

Hackarna har dels lagt ut källkoden för själva sajten samt en kopia på databasen. De har anonymiserat användarinformationen med hänvisning till att det är användarna som drabbats av sajtens påstådda bedrägeri.

Dataintrång är ett brott och jag pratar hellre om hur man bäst skyddar sig mot det än om hur man utför brotten. Trots det tycker jag att det här hacket skulle kunna klassas som civil olydnad och det kan onekligen vara nyttigt ibland.

(edit: jag påstod först att det var VFH som hade utfört hacket, jag skyller på att jag inte hade fått dagens första kopp kaffe när jag först skrev detta)

Cross site scripting innebär att man lurar en vanligtvis pålitlig sajt att visa ett script för besökaren.

Ett exempel

Säg att jag besöker Facebook och hittar en sida eller funktion som är öppen för mina onda avsikter. Det kan finnas ett fält som jag som användare kan fylla i själv och vars innehåll visas för alla besökare till min Facebookprofil. Men istället för att ange de uppgifter som fältet är till för, så lägger jag in ett litet javascript som i sin tur laddar ett större script från en sajt jag har tillgång till.

När du senare besöker min sida kommer din webbläsare att ladda scriptet och köra den programkod som det innehåller. Beroende på vad jag förberett för elakheter och vilka säkerhetshål i din webbläsare mitt script kan upptäcka kan praktiskt taget vad som helst hända. Utan att du märker något kan scriptet installera program i din dator, radera filer eller sända dina privata filer till en server på nätet.

Osannolikt? Tyvärr inte. Facebook är kanske inte ett väl valt exempel, den är hyfsat säker mot cross site injection men ett par säkerhetshål upptäcktes där för bara några dagar sedan. Du besöker säkert många andra sajter och forum där besökare själva kan lägga in information och då finns en stor risk att exemplet blir verklighet.

Hur skyddar man sig?

Det enda du som användare kan göra för att skydda dig är att använda en modern webbläsare som uppdateras så snart något säkerhetsproblem blir känt (helst ska den förstås uppdateras innan hålet blir känt…). Du kan också stänga av scripthantering i din webbläsare, men det är inte ett särskilt praktiskt alternativ eftersom de flesta sajter helt enkelt inte fungerar då.

Hur skyddar jag användare på min egen sajt?

Om du själv bygger webbsajter så finns det en del att tänka på för att dina användare ska slippa bli utsatta för den här typen av problem.

Grundprincipen är att aldrig presentera information som användarna har matat in utan att först tvätta den ordentligt. För att bli av med giltiga html-taggar typ <script> kan man konvertera ‘<’ och ‘>’ till “&lt;” och “&gt;”. När webbläsaren presenterar detta kommer det att skrivas ut istället för att tolkas som en giltig html-tagg.

Exemplen nedan är inte på något sätt heltäckande, men det viktiga är att du förstår principen. Varje gång du presenterar information som en användare har lagt in måste du vara medveten om riskerna med cross site injection. Det “rätta” sättet att skydda dina användare kan variera med funktionerna på din sajt.

Om du använder PHP

I PHP finns några standardfunktioner som gör mesta av jobbet åt dig, men du måste förstås se till att använda dem. htmlspecialchars() och htmlentities() konverterar alla specialtecken i HTML, tex ‘<’ till “&lt;”. strip_tags() tar bort alla html-taggar ur strängen utom de man uttryckligen sagt är tillåtna. (funktionsnamnen här är länkade till php-dokumentationen)

Studera php-dokumentationen för att lära dig skillnaderna, men i de flesta fall klarar du dig bra med htmlspecialchars(). Använd den när du ska skriva ut data som användare har lagt in. T ex:

$stringFromTheUser = "<script>alert('elakt script');</script>";
echo htmlspecialchars($stringFromTheUser);


Om du använder ASP.NET

ASP.NET har ett inbyggt skydd mot olämplig inmatning, men du kan inte förlita dig enbart på det. Det kan också finnas tillfällen när du behöver stänga av det, beroende på vilken sorts information du faktiskt tillåter att användaren lägger in.

För att vara säker på att du har det inbyggda skyddet aktiverat, se till att du har attributet validateRequest satt till true i sidan:

<%@ Page validateRequest="true" %>


När du skriver ut information som en användare lagt in, använd HttpUtility.HtmlEncode() för att konvertera alla specialtecken:

string stringFromTheUser = "<script>alert('elakt script');</script>";
response.write HttpUtility.HtmlEncode(stringFromTheUser);


Läs även den här artikeln på MSDN, men ta tipsen om att använda unika funktioner i Internet Explorer med en nypa sajt. Även om de i vissa fall går att använda som både hängslen och livrem kan du inte basera säkerheten på att användaren ska använda en viss webbläsare.