Dette indlæg er alene udtryk for skribentens egen holdning.

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

11 kommentarer.  Hop til debatten
Blogindlæg8. juli 2014 kl. 11:35
errorÆldre end 30 dage

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.

Artiklen fortsætter efter annoncen

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å

  1. <i>rubbish</i>

. Dette medfører en fejl på sitet. Jeg prøver lidt forskellige kombinationer (med eller uden ) 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:

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:

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

Ovenstående bliver i JavaScript til

  1. 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

11 kommentarer.  Hop til debatten
Fortsæt din læsning
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
10
13. juli 2014 kl. 10:50

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.

11
14. juli 2014 kl. 15:52

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 :-)

8
11. juli 2014 kl. 09:30

@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.

1
9. juli 2014 kl. 05:29

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).

3
9. juli 2014 kl. 09:00

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.

5
10. juli 2014 kl. 02:31

@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.htmlDe 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.)

6
10. juli 2014 kl. 09:59

@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.

7
11. juli 2014 kl. 08:32

@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.

9
11. juli 2014 kl. 09:58

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.

2
9. juli 2014 kl. 07:05

PS: Hvis de applikationer I udvikler har "bug bounty programs" vil jeg da hellere end gerne teste dem med henblik på Owasp Top 10 og "security best practice".