kim tiedemann bloghoved

Aften 2 - Hack 2: Cross site scripting på en portal

Jeg har tidligere skrevet, hvordan jeg på to aftener fandt to store sikkerhedshuller på to offentlige sites.

Det første site lækkede authentication cookien over http og dermed mulighed for, at en Man-In-The-Middle kunne aflæse cookien og overtage brugerens identitet.

Det andet site kan udsættes for et Cross site scripting angreb.

Cross site scripting (XSS)

Det går i al sin enkelthed ud på, at man ved at manipulere med input kan indsætte JavaScript på et site og dermed kan eksekvere JavaScript kode på sitet. Problemet skyldes at input parametre til en webside ikke saniteres og kontrolleres og dermed kan hackeren forsøge at manipulere parametrene til sitet og dermed prøve at få injectet noget Javacript.

Der er to typer cross site scripting: Reflected Cross Site Scripting hvor angrebet typisk udføres ved at sende links eller lignende til ofrene, som så ved at klikke på linket får aktiveret angrebet. Et stored Cross Site Scripting derimod er mere alvorligt, da serveren i modsætning til reflected gemmer angriberens data i databasen og dermed bliver langt flere brugere udsat for angrebet.

De første forsøg

Hvis et site har en søgefunktionalitet så er det et godt udgangspunkt at forsøge at sætte at reflected XSS angreb ind først. Det gjorde sig også gældende på dette site. Søgefunktionaliteten er implementeret ved, at der kaldes en url med en query parameter "SearchTerm", som indeholder søgeordet.

Jeg forsøger først at søge på

<i>rubbish</i>
. Dette medfører en fejl på sitet. Jeg prøver lidt forskellige kombinationer (med eller uden <, / og >) og alle medfører en fejl på sitet.

Herefter forsøger jeg bare at søge på rubbish. Det giver en fejlfri søgning. Jeg prøver herefter at se sidens kildekode og søger på rubbish, for at finde de steder på siden, hvor søgetermen benyttes.

Og voila: Den benyttes i noget JavaScript kode:

Illustration: Privatfoto

Nu har vi noget

Så kunne jeg bruge et søgekriterie, hvor jeg injectede noget JavaScript kode? Og ville det have en effekt. Ja for længere nede i JavaScript koden blev searchTerm skrevet ud i et html element:

Nu skulle jeg bare finde ud af, hvordan jeg kunne injecte JavaScript ind i variablen searchTerm. Da indholdet af variablen sættes server-side og jeg kan se, at den udskrives html encodet, så kan jeg jo bare indsætte ved at JavaScript encode mit JavaScript:

SearchTerm=rubbish\x3cscript\x3e%20alert(\x27pwnd\x20by\x20kbt\x20\u{1F4A9}\x27)%20\x3c/script\x3e

Ovenstående bliver i JavaScript til

rubbish<script>alert('pwnd by kbt [pile_of_poo]')</script>

Og det skrives ud i div tagget og dermed bliver det eksekveret af browseren. Og resultatet er en alert boks med indholdet pwnd by kbt [pile_of_poo] (jeg kan desværre ikke indsætte unicode karakterer i blogposten).

Hvad kan det bruges til

Man kunne jo sende et link til en masse potentielle brugere af sitet og håbe at de klikker på det. Hvis de samtidigt er logget ind på sitet, kan man altså udføre en masse handlinger på deres vegne. Hvis det havde været en webbank kunne man instruere browseren i at submitte en formular, der fx overførte penge. Hvis det havde været en webbaseret email løsning kunne man jo slette alle personens emails eller overtage kontoen.

Et af de mest grelle eksempler på XSS er Samy MySpace worm. Her brugte en ung mand XSS til at lave en orm, der sendte en masse venneforespørgsler af sted på det sociale site MySpace.

Hvordan kan man sikre sig?

Angrebet kan udføres fordi udviklerne af sitet ikke har været opmærksomme nok på at validere input parametre samt at sørge for den korrekte encoding af input parametre, som udskrives igen. I dette tilfælde havde udviklerne sikret, at man ikke kunne bruge < tegnet i søgestrengen. De havde også sørget for at html encode søgetermen inden den blev skrevet ud i "du har søgt på rubbish", men de havde glemt at JavaScript encoding er noget helt andet end html encoding.

Man kan bruge de forskellige frameworks måder at encode på. Fx understøtter ASP.NET MVC automatisk html encoding, så når en variabel skrives ud i html sikrer frameworket, at der automatisk encodes og dermed umuligt at injecte fx scripts. ASP.NET MVC understøtter også JavaScript encoding igennem brug af AjaxHelper klassen. Hermed sikres at det ikke er muligt at udføre ovenstående XSS angreb.

Epilog

Som jeg skrev i mit første indlæg så har jeg ikke udnyttet sikkerhedshullerne og har været i kontakt med ansvarlige for de to sites. XSS sårbarheden blev hurtigt fikset på Sundhed.dk og kan ikke længere udnyttes, men desværre er det endnu ikke lykkedes det andet site at rette op på fejlen.

Vi må som udviklere tænke sikkerhed ind i løsningen og de to viste sikkerhedshuller er ikke besværlige at sikre sig i mod. Vi skal tænke sikkerhed ind i vores kode reviews, så det bliver en naturlig del af Definition-of-done: Har vi husket at sanitere input parametre? Encoder vi korrekt når vi viser output på skærmen?

SSL everywhere

Hvorfor ikke bruge https over alt på vores sites? Specielt hvis vi tillader folk at logge ind og have personificeret indhold! Der eksisterer mange myter om SSL og rigtigt mange sidder stadig tilbage med indtrykket af, at det er dyrt at anskaffe og har så stor indvirken på performance, at det er nødvendigt at anskaffe dedikeret hardware til kryptering. Ilya Grigorik fra Google har lavet sitet Is TLS fast yet, hvor myterne aflives. Ved at bruge SSL overalt vil vi sikre vores brugeres privatliv og vi sikrer os i mod Man-In-The-Middle attacks, hvor indholdet fra vores site manipuleres på vej mod brugeren.

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Hans-Michael Varbæk

De 2 "store" sikkerhedshuller er meget normale på Danske hjemmesider. De rangerer dog ikke som "store" (høj el. kritisk risiko) på de fleste seriøse skalaer fra 1-5, hvor begge ville være en 3'er. (Moderat risiko.)

Selvfølgelig skal begge tages seriøst, da Man-in-the-Middle (MitM) angreb jo udføres på Internettet dagligt af vores tre-bogstavs-venner, men også af hackere på nogle netværk (ofte meget korte angreb).

Cross-Site Scripting i sig selv er meget underforstået af udviklere og virksomheder (mest pga. de fleste Proof of Concepts ligesom dit er en "alert box"), men det kan sagtens blive "weaponised" f.eks. som blev demonstreret for nyligt i Amsterdam: https://speakerdeck.com/varbaek/xssing-your-way-to-shell

Et stort sikkerhedshul er SQL Injection (Høj Risiko - 4), og et kontrol panel hvor du kan logge ind med root/root er Kritisk - 5. Med SQL Injection i et GET-forespørgselsparameter, hvor databasen kører som "administrator" (f.eks. 'root' brugeren), og som ikke filtrerer ord overhovedet kan dog godt betegnes som Kritisk - 5, da en angriber (script kiddie) vil kunne ekserkvere kode på selve serveren og derved overtage fuld kontrol.

Med XSS kan det godt blive gjort muligt at køre kode på serveren, men det kræver at man ved hvordan applikationen fungerer eller at man angriber brugerens browser, og at applikationen på en eller anden måde kan ændres nok til at kunne køre din egen kode (f.eks. PHP).

Kim Bjørn Tiedemann

Ja de er rimeligt almindelige i Danmark (desværre), men de ligger også nummer 2 og 3 på OWASP top 10 2013 og dermed et udtryk for, at OWASP ser dem som top 3 i forhold til kritikalitet. Reflected XSS på en offentlig portal med selvbetjeningsløsninger er kritisk, da vi ved at "almindelige" mennesker kan lokkes til at klikke på det meste og dermed kan vi aktivere en selvbetjeningsløsning på deres vegne.

Et Man-In-The-Middle angreb er heller ikke så svært at udføre. Jeg har en Pineapple Wifi og har for sjov sat den op på min arbejdsplads. I løbet af kort tid forbandt flere devices til den og jeg kunne, hvis jeg havde lyst, trace al deres trafik og køre sslstrip til at aflure deres usikre auth cookies.

Lars Tørnes Hansen

For nogen tid siden fik jeg fat i den her bog om sikkerhed:
"24 deadly sins of software security programming flaws and how to fix them"
af Michael Howard, David LeBlanc, John Viega
ISBN 978-0--07-162675-0
http://www.amazon.co.uk/Deadly-Sins-Software-Security-Programming/dp/007...

Jeg synes at den er et must-read, hvis man ikke ved så meget om emnet, hvilket jeg ikke gjorde før jeg havde købt og læst i den bog.

Hans-Michael Varbæk

@Kim:
På trods af Owasp siger at deres Top 10 er de mest kritiske sårbarheder, så overser du vidst at deres Top 10 dækker 90-99% af alle web applikations sårbarheder/sikkerhedshuller.

Se eventuelt følgende side:
http://www.cvedetails.com/vulnerability-list/vendor_id-74/opxss-1/PHP.html
De fleste af XSS sikkerhedshullerne ligger på moderat risiko skalaen, og ved ovenstående link er det endda problemer i selve PHP.

Bare fordi WiFi MitM angreb er lette at udføre, gør det ikke problemet mere kritisk. Til gengæld så er det da rart at vide din arbejdsplads ikke har nogen MDM (Mobile Device Management) løsning implementeret. (Som I burde have hvis din arbejdsplads tilbyder trådløse netværk for ansatte.)

Kim Bjørn Tiedemann

@Hans: Jeg forstår ikke helt hvor du vil hen med din første sætning. I følge OWASP så er top 10: The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.

Du skriver meget om PHP - heldigvis så er der meget få offentlige løsninger, der baserer sig på PHP og det er ikke en teknologi, som er særligt efterspurgt i det offentlige. Dit link viser hvor kritisk en XSS sårbarhed er i en applikation bygget på en PHP stak. OWASP kigger teknologineutralt og deres vurdering er stadig, at A2 Broken Authentication and Session Management og A3 Cross-Site Scripting (XSS) er meget kritiske.

Hvis et angreb er nemt at udføre, så er det også mere kritisk. Du åbner din applikation op for mange flere angreb, da der formentligt er flere som vil forsøge sig med angreb.

De devices som forbandt til min Pineapple WiFi var de ansattes private devices (samt gæster på den nærliggende cafe), som ikke er forbundet til vores interne WiFi netværk, men de forbinder jo fint til Pineapple'n pga dens Karma modul. Det var devices som var på mobilt netværk, men som "lige pludseligt" fandt deres favorit access point, som de gladeligt forbinder til. Der er et rimeligt simpelt angreb og sites der ikke beskytter deres brugeres data, når de er logget ind, er dårligt implementeret og sårbarheden er meget kritisk.

Hans-Michael Varbæk

@Kim: Det som jeg prøver at sige er, at din risiko vurderingsskala ligger alt for højt i forhold til at "alt er kritisk". Det er vigtigt at tage alle sikkerhedshuller seriøst, men at sige alt på Owasp Top 10 er kritisk fordi de siger det, uden at analysere hvor nemt det er, hvilken type data man får adgang til, og om man f.eks. kan ekserkvere kode på serveren, er lidt overdrevet.

Hvis du spørger rundt omkring, vil de fleste sikkert sige at SQL Injection ligger langt højere på risiko skalaen end XSS, på trods af sidstnævnte findes på ca. 51% af all hjemmesider. Set i perspektiv er SQL Injection kritisk eller høj risiko, mens XSS ligger nedenunder generelt på moderat og i sjældne tilfælde høj risiko.

De fleste udviklere jeg møder siger dog stik modsat desværre, at XSS er et lav eller ingen risiko problem, hvilket gør at de ikke fokuserer på at rette den type fejl som en af de første ting.

Hvis du på en hjemmeside, kun kan "XSS'e" dig selv (f.eks. ved at du logger ind på en profil hvor du kan ændre din addresse til XSS som kun du kan se, og som administratoren ser HTML encoded) er det langt fra kritisk, der ville jeg selv gå med på at det er lav risiko da ingen andre end dig selv er omfattet af problemet.

Det samme gælder reflected vs. stored XSS, da jeg ser stored (persistent) XSS som langt værre end reflected (non-persistent) XSS. I det her tilfælde kommer det dog an på hvem og hvor mange som er omfattet af f.eks. et Stored XSS sikkerhedshul. Hvis det kun er dig selv er det ikke så slemt igen.

Kim Bjørn Tiedemann

@Hans: Det site der lækker auth cookien og dermed tillader MitM angreb har endnu ikke rettet fejlen og derfor vil det være upassende for mig, at fortælle hvem de er og hvad man kan gøre. Men det er en offentlig løsning med selvbetjening, der gør Eve i stand til at gøre ting på vegne af brugeren. Det er kritisk ud fra OWASPs to kriterier: Technical impact og Business impact.

Det andet site med XSS er Sundhed.dk. Her kunne Eve med en snedigt udformet url tilmelde en bruger til organregisteret eller lignende. Bemærk at også sundhedsfagligt personale (som læger) benytter Sundhed.dk og er altså også sårbare for angrebet. Her tør jeg ikke tænke på, hvad man kan gøre og hvor nemt det er, at ramme denne gruppe med en phishing mail.

Jeg er enig i at der kræver en analyse af det som OWASP kalder business impact for at kunne vurdere en sårbarheds kritikalitet for et givent site. Det mener jeg nu også at have argumenteret for i begge blog indlæg samt i mine kommentarer, hvor jeg påpeger årsagerne til at jeg anser dem for kritiske. Det er vel også årsagen til, at du heller ikke bare kan sige, at injection er værre: Er en injection sårbarhed på en lille webshop værre end en auth cookie leak sårbarhed på et meget brugt site, der udstiller personlige informationer? For webshoppens ejer er det nok, men for os andre der kigger ude fra er det ikke.

Uffe Seerup

Det som jeg prøver at sige er, at din risiko vurderingsskala ligger alt for højt i forhold til at "alt er kritisk". Det er vigtigt at tage alle sikkerhedshuller seriøst, men at sige alt på Owasp Top 10 er kritisk fordi de siger det, uden at analysere hvor nemt det er, hvilken type data man får adgang til, og om man f.eks. kan ekserkvere kode på serveren, er lidt overdrevet.

Jeg tror at pointen er, at både SQL injection og script injection (XSS) er ganske alvorlige brister.

SQL injections er næsten altid alvorlige. XSS kan være (og er ofte) lige så alvorlige, hvor "alvorlighed" forstås som potentiale for kompromittering af site og/eller brugere)

Det afhænger af de underliggende lag af sikkerhed. Hvis fx. sitet ikke anvender "http only" for sessions cookies eller authentication tickets, så er XSS - specielt "stored XSS" meget, meget alvorligt: Det kan direkte bruges til at injicere et fuldautomatiseret angreb, hvor du som angriber kan hijacke alle eller en stor del af de besøgende på sitet.

SQL injections kan være mindre alvorlige, hvis der benyttes rollebaseret adgang (med "least privilege") til databasen og fx. stored procedures eller begrænsede views som forhindrer brede forespørgsler eller opdateringer. Chancen for at udviklerne har tænkt på disse dybe forsvarsmekanismer er dog ringe hvis de har kunnet lade SQL injections slippe igennem.

Der er i 2010'erne absolut ingen undskyldning for at lave et site med SQL injections: Værktøjer som med nær garanti forhindrer SQL injections er tilgængelige for alle udviklere (vi undtager lige de situationer hvor værktøjerne selv indeholder SQL injection muligheder som fx Ruby on Rails/ActiveRecord med PostgreSQL). Under fx .NET eller Java kan man bruge Entity Framework, Hibernate eller en anden ORM som "by design" beskytter mod SQL injections.

XSS kan være lidt sværere at beskytte sig mod. Som Kim beskrev i artiklen havde udviklerne faktisk tænkt over det, men havde overset en mulighed som ikke var åbenlys. Server side frameworks som fx. ASP.NET MVC er blevet så smarte, at de typisk vil HTML kode alt "dynamisk indhold" - medmindre at udvikleren specifikt overtager ansvaret for at indholdet i feltet skal sendes som "rå" HTML. Men med stadig flere client side frameworks som måske ikke har det samme sikkerhedsfokus bliver vi sat lidt tilbage dér.

Så på den måde kan du også se XSS som alvorligere end SQL injections: Der er begrundet håb om at SQL injections kan udryddes. Værktøjerne er på plads og der er (næsten) ingen grund til ikke at bruge dem, og de vil give fuld beskyttelse.

XSS kræver stadig konstant opmærksomhed, omtanke og godt håndværk. Og selv da kan der slippe eksempler igennem.

Janus Knudsen

Hej Kim

Interessante undersøgelser du laver der, men har du fået tilladelse fra ejerne af websitet inden du hacker dem?

Hvis du har ikke tilladelse så anses det som hacking og takseres herefter, så pas på, det kan hurtigt gå galt.

Jeg har selv været sigtet for hacking og det var endda på opfording i et forum hvor ejermanden ønskede et review af websitet (tilbage i 2002). Jeg udførte sqlinjections som lykkedes.

Anklageren fandt dog ingen grund til at gå videre med sagen, men jeg var hele møllen igennem med Rigspolitiets IT afd., afhøringer osv.

Kim Bjørn Tiedemann

Hej Janus,

Nej jeg har ikke bedt om lov. Jeg har heller ikke udnyttet hullerne, kun notificeret ejerne af de pågældende sites og efterfølgende her på bloggen.

Der er nok også en forskel i forhold til SQL injection, hvor du jo eksekverer kode direkte på "serveren" i forhold til XSS og lækket auth cookie, hvor angrebet først sættes ind, når du udsætter andre for det. Men jeg håber da at vi kan få en kultur, hvor det er ok at lede efter sikkerhedshuller, så længe vi opfører os ansvarligt og gør ejerne af sitet opmærksomme på det inden vi offentliggører det. Og jeg håber ikke at politiet banker på min dør en af de nærmeste dage :-)

Log ind eller Opret konto for at kommentere