Hur man hackar emocore.se (XSS)

Hur man hackar emocore.se (XSS)

Märk väl att denna text endast är skriven i utbildningssyfte - jag uppmanar inte någon att hacka emocore.se eller någon annan sida. Jag kan inte heller garantera att dessa metoder fortfarande fungerar, då Joakim (användarnamnet på sidans skapare) arbetar hårt och aktivt för att hålla sidan i bra skick och är snabb med att täppa till säkerhetshål. Bra jobbat, Joakim!

Inledning:

emocore.se är en så kallad community där varje användare har en egen sida med möjlighet att ladda upp bild på sig själv, skriva en presentation och så vidare. I sin presentation har man möjlighet att själv skriva in texter och en del HTML-kod, men det finns flera filter för att minska säkerhetsproblemen med detta.

< och > filtreras inte per automatik bort, då de används i de HTML-taggar som sidan tillåter i presentationer. Vissa HTML-taggar ersätts med annan kod eller text för att inte utgöra några säkerhetsproblem. T. ex. <script som ersätts med &lt;script och <iframe som ersätts med &lt;iframe .

Vidare har många DHTML-objekt så kallade händelsehanterare, eller (eng.) event handlers, t. ex. "onload", "onmouseover", och så vidare. Jag förutsätter i fortsättningen att du som läsare är någorlunda bekant med hur dessa fungerar.

Det är i praktiken nästan omöjligt att täppa till alla säkerhetshål som uppstår när man över huvud taget tillåter enskilda användare att interagera med sidan och dess innehåll - vilket dessutom är själva poängen med en community.

Ber i förväg om ursäkt för slarv, snurrighet, eventuella fel osv. Jag har skrivit allt detta i efterhand och har fått tänka tillbaka ganska mycket, skriva om skript så att ni hänger med i utvecklingen och så vidare.

Hacket - tillvägagångssätt:

Jag började med att registrera en användare, surfa runt på sidan och bekanta mig med den lite. Detta är grundläggande och bör i de flesta fall vara första steget när man vill hacka en sida eller hitta dess säkerhetsbrister - bekanta dig med sidan och hur den bearbetar data, så kan du (med erfarenhet nog) lista ut många av de inre mekanismer som pågår.

I presentationen var jag fri att skriva in precis vad jag ville, till och med tecken som inte går att visa i vanlig text. Dessa sparades precis som de skrevs in i presentationen, men filtret tog bort och ersatte vissa strängar när presentationen visades. Jag började med att skriva in några olika HTML-taggar, lite olika HTML-relaterade tecken och så vidare, för att se hur filtret arbetade. < och > släpptes igenom, men vissa HTML-taggar eller tecken ersattes med annan text. Jag fortsatte med att fylla presentationen med alla DHTML-händelser jag kunde komma på:

onactivate
onblur
onclick
onfinish
onfocus
onkeydown
onload
onmouseover
onmouseup

+ ett helt gäng till.

Jag sparade det hela och besökte min egen presentation. Vad hade filtret gjort? Det hade lagt in ett mellanslag mellan "on" och namnet på händelsen i många fall. "onload" blev "on load", "onblur" blev "on blur", "onclick" blev "on click" och så vidare. Nästan alla de vanliga händelserna som går att utnyttja vid en XSS-attack filtrerades och skrevs om. Filtret hade dessutom bearbetat strängarna oavsett om de låg i HTML-taggar eller inte; det räckte alltså med att bara skriva "onload" var som helst i presentationen så ändrades det till "on load". Detta säger en del om hur simpelt filtret är, och får mig att tro att det i själva verket bara utgörs av en bunt funktioner som ersätter strängar med andra - dvs inte alls någon mer avancerad form av pattern matching.

T. ex. skulle filtret kunna se ut så här:


Men! "onfinish" rördes inte!

När inträffar onfinish då? Jo, onfinish inträffar när texten i en <marquee> slutat rulla. När den har loopat klart alltså. Vad gör filtret med <marquee>, tro? Tas det bort?

Jag skrev in <marquee>text</marquee> i presentationskoden, sparade och besökte min egen presentation. Alldeles riktigt rullade texten om och om igen över skärmen. Här hade jag en säkerhetsbrist; en möjlighet att köra Java-skript hos alla som besökte min presentation. Eller?

Jag testade; skrev in <marquee loop=1 onfinish="alert('du är bäst');"></marquee> i presentationskoden, sparade och besökte min egen presentation. Alldeles riktigt kom nu en fin meddelanderuta upp med texten "du är bäst". Jag svarade bara med att klicka "ok" - jag är ju trots allt ganska van att få höra detta. Notera för övrigt "loop=1", det är viktigt för att marquee:n ska sluta loopa. Man ställer alltså på det viset in hur många gånger den ska rulla innan onfinish körs. Utan loop-attributet slutar den aldrig, loop=1 så rullar den en gång, loop=10 så rullar den 10 gånger och så vidare. Om den får loopa för evigt (så som den normalt gör, utan loop-attributet) så inträffar aldrig onfinish. Vi låter den loopa en gång, sen inträffar onfinish och skriptet körs.

Ok, nu började det roliga. Vad ville jag göra? Jag ville inte förstöra sidans funktion - det är onödigt och elakt. Men jag ville ändå göra ett spännande och busigt hack, som på sin höjd kunde vara irriterande för andra.

Hmm, vad sägs om ett skript som kopierar sig själv till alla andra som besöker min presentation. Och som kopierar sig vidare till alla andra som besöker mina besökares presentationer. En så kallad "worm" - programkod som sprider sig själv vidare. Det låter som en kul idé. Men hallå, den måste ju göra något mer? Den kan inte bara sprida sig hejdlöst?

Ok, jag fick en idé. Kanske en tramsig och barnslig idé, men samtidigt var jag försiktig med att inte göra något som kunde förstöra sidans funktionalitet. Vad sägs om att skriptet efter ett visst datum och en viss tid byter namn på användaren (inte användarnamn, utan "riktigt namn") till "Göran Persson". Och att det byter e-mail på alla användare till en jag registrerat, om jag nu händelsevis skulle få för mig att jag har glömt lösenordet till alla infekterade användare på sidan. Funktionen för att återställa sitt lösenord kräver på emocore.se bara e-mail, så om alla har samma kan jag bara skriva in mailen jag registrerat och glatt se på när lösenorden rullar in.

Det kör vi på! Så får det bli! Let's börja!

Hacket - koden:

Till att börja med behöver vi ett skript som kan kopiera sig själv. Hur kan vi göra det? Vi besöker sidan där man skriver in sin presentationskod: http://www.emocore.se/sida/presentation

När du redan är inloggad behöver du inte göra mer än att besöka den här sidan, så kommer en ruta upp där du kan skriva in presentationstexten och klicka "Spara" för att spara den. Vad måste skriptet göra för att utföra detta?

Jo, så här gör vi:

När skriptet körs måste den ladda /sida/presentation på något vis. Vad sägs om en dold iframe? Det låter som en utmärkt idé för detta. En iframe som laddar /sida/presentation, skriver in sig själv i textrutan och klickar Spara. Vi börjar med koden för iframe:en.


Höjd, bredd osv är noll så att den absolut inte ska synas. Men hur får vi in den här iframen då? Något måste ju lägga in den i HTML-koden när skriptet körs?

Javisst, det ordnar vi. Eftersom <iframe är filtrerat och eftersom koden innehåller en del konstiga tecken så som <, > och " så kodar vi den i hexadecimal. Då blir den dessutom lite svårare att förstå.


... blir...


... i hexadecimal.

(Hajar du inte hur detta går till börja du läsa på lite innan du ger dig på XSS-attacker. Man tar helt enkelt ASCII-värdet för varje tecken i strängen, konverterar till hexadecimal, och lägger ihop det som en annan sträng.)

Enkelt VB-skript för att koda om en sträng till hexadecimal, för er superlata:


Ok, så skriptet som körs när onfinish inträffar måste alltså ta den här hex-strängen, koda av den till "riktig text" igen, och injicera den i HTML-koden. Minns Java-skripts funktion unescape(), som tar en sträng och ger en sträng. T. ex. unescape('abc_%41%42%43') som returnerar 'abc_ABC'.

Men vår hex-sträng saknar ju %-tecken, eller? Javisst gör den det, men bara för att den ska vara så kort som möjligt. Vi kan lägga in %-tecknena samtidigt som vi läser in strängen!

Alltså, skriptet som körs när onfinish inträffar ska läsa in hex-strängen, lägga in %-tecken, koda av den och sedan injicera den i HTML-koden. Det kan vi göra med följande skript:


(Skriptet är så grundläggande att jag inte brytt mig om att kommentera det i detalj.)

Det itererar över strängen s, läser 2 tecken åt gången, lägger in % framför, och sätter ihop det till en annan sträng o. Sedan kör vi bara unescape() på o och vips så har vi den avkodade strängen, som vi lägger in i HTML-koden.

Snurrigt? Vänta bara!

Var är vi nu då? Jo, vi vill ha en marquee som kör skriptet ovan. När marquee:n slutat rulla så ska den koda av hex-strängen och lägga in den i HTML-koden. Vi lägger in skriptet ovan i onfinish:


Notera att jag lagt in "scrollamount=99" ovan. Det är hur snabbt marquee:n ska rulla - jag vill att den ska rulla förbi så snabbt som möjligt så att skriptet går igång så snabbt som möjligt. Finns även scrolldelay, men scrollamount räcker för oss.

Ok, lägger in koden i presentationen, sparar och kollar om det funkar.

Javisst! Klick-klick hör man när webbläsaren (i det här fallet IE7) gladeligen laddar iframe:n och dess innehåll. Allt utan att det syns!

Jaja, roligt roligt. Men det måste ju kopiera sig själv med! Så fort iframe:n laddats så ska den kopiera sig själv från presentationen, skriva in sig i besökarens presentation och spara den. Om den inte redan finns i besökarens presentation såklart - så att man inte kan bli "infekterad" flera gånger. Då kan vi använda oss av iframe:ens onload event. Men vadå, "onload" filtreras ju? Näförfan, vi kodar ju allting i hexadecimal! Filtret hajar inget och släpper igenom det.

Jag gick in på http://www.emocore.se/presentation och kollade källkoden. Vad heter form:en som innehåller textrutan och Spara-knappen? Och vad heter textrutan? Knappen då?

Kolla igenom källkoden så hittar du:


Namnet på spara-knappen behöver vi inte bry oss om, vi kör helt enkelt submit()-funktionen direkt på form:en så skickas den.

Jahapp, då har vi namnet och det då. Vad gör vi med onload-skriptet för iframe:n? Såhär gör vi:


(Notera namnet "minIframe". Det är namnet vi kommer använda på iframe:n, så att den kan leta upp sig själv och lägga in skriptet.)

Kort förklaring av funktionen indexOf():

indexOf() tar en sträng och returnerar ett heltal som indikerar var i strängen en annan sträng befinner sig, eller -1 om den givna strängen inte alls finns med. T. ex. 'abc123'.indexOf('c') ger 2, 'abc123'.indexOf('bc1') ger 1, 'abc123'.indexOf('z') ger -1.

Ok, skriptet ovan är alltså allt som behövs för att det ska kopiera sig själv från en presentation till en annan. Hur lägger vi in det?

1. Ta koden
   
   Kod:

   <iframe name="minIframe" src="/sida/presentation" width="0" height="0" frameborder="0" onload="SKRIPTETHÄR"></iframe>

   och ersätt SKRIPTETHÄR med skriptet vi skrev alldeles ovan.
   
   
2. Koda alltihop till en hex-sträng och gör som vi gjorde först:
   
   Kod:

   <marquee scrollamount=99 loop=1 onfinish="var s='HEXSTRÄNGENHÄR';var o='';for(var i=0;i<s.length;i+=2){o+='%'+s.substr(i,2);}document.body.innerHTML+=unescape(o)"></marquee>

   och lägg in den kodade hex-strängen istället för HEXSTRÄNGENHÄR.

Ok, dags att testa igen.

Jag gick in med två användare samtidigt, tömde bådas presentationer och lade sedan in koden i användare As presentation.

Sedan besökte jag användare As presentation med användare B. Klick-klick, klick-klick. Inget syntes såklart, men fungerade det? Jag gick med användare B till sidan där man redigerar sin egen presentation. Vips så låg skriptet nu där också! Häftigt, det kopierade sig själv. Det fungerar alltså. Skyndade mig att ta bort skriptet från båda användarnas presentationer så att inga fler skulle bli infekterade... än.

Jaha ok, den biten avklarad. Nu vill vi att skriptet byter namn på användaren till "Göran Persson" och ändra mail med. Det är så likt det vi gjort ovan att jag bara går igenom det snabbt:

Sidan för att ändra "riktigt namn" och e-mail (och andra liknande inställningar) är http://www.emocore.se/sida/info .

Vi vill ändra riktigt namn (elementet heter "u_real_name") och e-mail ("u_email"). Själva formen heter "setting_form". Vi gör en till iframe som går till den här sidan och lägger in namnet och e-mailen (om datumet har passerat en viss gräns) och sedan sparar det. Ett smått problem med detta är att när man ändrar sina inställningar så kommer det upp en meddelanderuta med texten "Sparat" i. Visst, det kan verka lite suspekt om man går in på någons presentation och får upp en ruta som det står "Sparat" i. Men whatever, det är en emo-fjortis-community (grrr) så ingen kommer haja nå't ändå. Inget jag orkade bry mig om, i alla fall.

Skriptet för att lägga in e-mail, byta namn osv:


Iframe #2:


Lägg ihop detta med första iframen:


Koda om hela skiten till en hex-sträng och lägg in den i marquee:n (den här hex-strängen har något modiferade skript för att resultatet ska bli så kort som möjligt):


Notera strängen "xrTJ6q2Fm" igen som jag lagt in även i marquee-skriptet, så att även om skriptet händelsevis skulle köras flera gånger så lägger den inte in fler och fler iframes. Jag har skrivit strängen på ett så konstigt vis för att den inte ska hitta sig själv i html:en innan den skrivit ut sig själv, och för att filtret, som förstör "<!--", inte ska reagera. Ni hajar säkert.

Resultat:

Så that's it. Jag kände mig ganska nöjd med skriptet, slängde in det i en användares presentation och snackade lite på "klotterplanket". Den första timmen gick det segt, kanske 20-30 användare som blev infekterade. Jag somnade efter sexet.. jag menar haxet, och återkom 4-5 timmar senare. Jag kollade igenom varenda jäkla användare jag kunde hitta efter infektion, och nästan alla jag kollade var infekterade. Jag skulle vid det här laget uppskatta det till att 4000-5000 presentationer infekterats. Bara att börja använda funktionen "jag har glömt mitt lösenord", så började lösenorden rulla in...

Tillägg:

Säkerhetshålet jag utnyttjar i artikeln ovan täpptes till 2008-06-02 på kvällen, så koden ovan utgör inget säkerhetsproblem längre. Det finns dock flera säkerhetshål kvar i presentationsfiltret, men dessa får ni hitta på egen hand!

För övrigt fungerar skriptet bara i Internet Explorer och inte Firefox eller Opera, något jag inte brydde mig om att åtgärda. Tillräckligt många användare använde sig av IE.

// M****n :-)

first, huh!


Trotts allt verkar de vara snabba på att åtgärda fel och buggar. Ni hackers kanske ska gå djupare än att haxxxa i pressen, om man ogillar emos vill man inte se dem skadas, man vill se dem utrotas.

Det är nog ganska vanligt med sådant här, så jag ska testa runt lite på andra sidor med ideerna jag fick av detta. Bra skrivet också.

Hur man som webbsideägare kan förhindra att en sådan attack sker:

Man kan sätta någon form av Captcha-validering så fort man vill ändra något i presentationen eller i användarkontot såsom email.
En captcha som ni kanske vet, kräver att en människa löser den, och det förhindrar att javascript eller trojaner går in och ändrar.

För att förhindra cookiestöld så kan man låsa cookien till IP-adress med hjälp av en hash + ett hemligt lösenord som bara servern känner till.

Tex:

$password = "VqBINMGpCgyVZMqF0rRzrlU8NcxntqxJYCMgVuaIgW1XVuJkO gBt2v251bMk2BulkTZxCCb8zQlie3";

print "Set-Cookie: login=$session."#".md5_hex($session.$password.$ENV {'REMOTE_ADDR'})\n";

Varje gång man gör något så verifierar sidan att hashen i cookien stämmer:

$cookieval = cookie('login');
($session, $hash) = split("#", $cookieval);
if ($hash eq md5_hex($session.$password.$ENV{'REMOTE_ADDR'}) {
# Cookien är pålitlig
}
else
{
print "Content-Type: text/html\n\n<h1>Dont try to XSS here!!</h1>";
}
--------------------------------------------------------------------
Då har man så gott som komplett skyddat sig mot XSS så det är sedan fritt fram att tillåta hur mycket javascript och iframes man vill i presentationen m.m.
För att förhindra att någons presentation pajar hemsidan så kan man göra en lättare syntaxkoll av HTML-koden så att man inte skriver typ "<table" och så försvinner resten av hemsidan.

Hela idén med XSS går ju ut på att man ska defeata "SOP" (Same origin policy) som ser till att enbart den sida som sätter cookien kan läsa den, Javascript-Ajax kan bara kommunicera med samma sida som javascriptet finns på m.m.
Genom att se till att de kontroller som skyddas av Same Origin Policy även skyddas mot stöld (ex cookies) eller så förhindrar man att script postar till den kontrollen (tex man sätter Captcha på ändra-presentations-rutan) så ser man till att göra XSS värdelöst.

Eller hur XSS är värdelöst om man inte kan göra något med XSS:et ändå förutom typ alert('hej');

Starkt jobbat, det där om att koda om allt i hex kommer att användas i framtiden

Ot raderat. Om man inte har något att tilföra subject låter man bli att posta. Annars får man tillsägelser.

/Mod

Lustigt nog har jag för mig att jag mailade dem om liknande XSS-hål för ett tag sedan. Varför inte täta dem?

De har antagligen inte en hum om hur man gör, de verkar inte prioritera säkerheten på det stället iallafall.

Först vill jag tacka för en bra "guide".

För en webbplats... Rätta mig om jag har fel, men vore det inte bäst att köra serverside omkodning av all html till tecken (htmlspecialchars_decode() etc.), och koda sin egen stilformatering (tex. [ b ]..[ / b ] etc.)?

Nej, det behöver du inte göra.

Du kan istället "tillåta" XSS, men skydda de saker som påverkas av XSS. Se mitt föregående inlägg i den här tråden om hur man kan skydda känsliga formulär och cookies från XSS:ens inverkan.

XSS är ju bara ett sätt att kringgå "Same Origin Policy" genom att stoppa in innehåll på någon annans sida.

Genom att skydda de resurser som påverkas av XSS, tex ändra presentationsformulär, ändra lösenord, cookies m.m. så gör det inget om det råkar finnas ett javascript på en sida.

------

Jämförelse: Du bedriver en publik lokal. Varje gäst har sitt eget skåp där, med en nyckel som han/hon får av dig.
Istället för att förbjuda gästerna från att ta med sig dyrkverktyg (spärra XSS/javascript), så kan du installera dyrksäkra lås i skåpen (låsa cookies till IP och formulär med captcha), så gör det inget att de tar med sig dyrkverktyg (det gör inget om de skriver en XSS på sin presentation eftersom formulär och cookies är oåtkomliga för XSS:en).

(Dyrkverktyget är en analogi till XSS)

Bara tänk om någon kommer på något kraftfullare än XSS som går att skriva med bara vanlig HTML. Genom att skydda cookies och formulär så att det blir såpass säkert att man kan tillåta XSS, så är du skyddad mot framtidens attacker också... Någon kanske skriver en CSRF med en a href och skriver sedan "Klicka här för en fin film"...
Genom att skydda dina formulär med CAPTCHA och dina cookies med en IP-låst hash, så är du skyddad mot sådana attacker.