Drive

Come prima cosa, eseguo una scansione con nmap:

Risultano 3 porte aperte:

Utilizzando whatweb scan ottengo le seguenti informazioni:

Quindi, dopo la scansione, abbiamo scoperto che ci sono tre porte aperte: la buona vecchia porta 80 per HTTP, la classica 22 per SSH e una misteriosa 3000 dove si nasconde qualcosa di interessante. Ma ci arriveremo tra poco.
Ora passiamo alle cose del web. Per prima cosa inserisco "drive.htb" nel file /etc/hosts. Non c'è bisogno di sudare eseguendo scansioni fantasiose o gobuster perché, credimi, non ci sono percorsi segreti nascosti in attesa di essere scoperti.
Basta fare la solita esercitazione: registrati, crea un account sulla piattaforma ed effettua l'accesso. Nessun problema! Arriveremo presto alle cose succose.

Come possiamo notare è una sorta di clone di Google Drive, ma con una svolta nel sistema di prenotazione. Puoi caricare un file per persone specifiche e solo loro potranno vederli. Oppure puoi essere generoso e lasciare i file senza riserve affinché le persone possano catturarli da soli. È tutto piuttosto semplice, ma ecco il bello: c’è una subdola vulnerabilità in agguato.

Per arrivare al nocciolo della questione, avviamo Burp Suite 🔥 e iniziamo ad analizzare come funziona l'intera faccenda.

Analizzando il sito sembra che per accedere a un file tutto ciò che devi fare è inserire l'ID nell'indirizzo. Possiamo trarne vantaggio eseguendo il fuzz dell'URL per scoprire file nascosti che non sono riservati a noi!!
Per far sì che ciò accada, intercettiamo la richiesta e la inviamo al nostro fidato aiutante, Burp Suite Intruder.

Dobbiamo assicurarci di aver configurato queste impostazioni in modo che corrispondano alla tua strategia di fuzzing:

Ora è il momento del gioco! Premi "Avvia attacco" e lascia che i fuochi d'artificio abbiano inizio.

Dopo alcuni minuti di suspense, iniziano ad arrivare i risultati del nostro attacco. Ora, tutto ciò che dobbiamo fare è ordinarli per stato e tenere d'occhio i seguenti tre stati chiave:

     200: Bingo! Hai vinto il jackpot e hai accesso al file.
     401: Questo è ciò che stiamo cercando principalmente. Significa che l'accesso al file è stato negato.
     500: Niente da vedere qui, gente. Indica che non esiste alcun file con quell'ID.

Quindi, concentriamoci su quei 401. È ora di concentrarsi sulle vulnerabilità!

Abbiamo un elenco promettente con gli ID 101, 112, 79, 98 e 99. Questi file potrebbero potenzialmente contenere alcuni preziosi segreti. È ora di rimboccarci le maniche e trovare un modo per accedervi.
Inizia dando la priorità a questi ID e concentrati sui codici di stato 401. Siamo sulla strada giusta e, con un po’ di tenacia e creatività, scopriremo cosa è nascosto in questi file.
Quindi, dopo aver frugato un po', ci siamo imbattuti in qualcosa di interessante. Si scopre che c'è questo collegamento /block ed è un po' un punto debole nel sistema. Sembra che non importi chi possiede il file, quindi ho avuto un'idea folle: e se potessimo riservare file a cui non dovremmo accedere?

Effettivamente, inserendo nel collegamento /ID/block riesco a leggere il file. Nell'ID 79 riesco a trovare un username e una password che provo subito in SSH... entro!!!

L'utente però non ha una flag. All'interno della cartella home vi sono 4 utenti.

Sbirciando la cartella /usr/local/bin troviamo una cosa molto interessante "gitea"!! La seconda cosa molto interessante sono i file di backup del database. Questi possono essere tesori di informazioni e spesso sono una miniera d’oro per scoprire segreti e vulnerabilità.

Attraverso l'rsync scarico tutti i file presenti nella cartella backups e vado ad analizzarli. I file 7z sono protetti da password. Adesso provo a vedere il db.sqlite3 cosa mi riserva.

Come possiamo vedere ci sono gli utenti con le password cifrate.

Riesco a trovare la password di Tom. Vediamo cosa si cela dietro a questo utente.
Purtroppo provando la password ti Tom non sembra funzionare. Così provo ad analizzare Gitea.

Chissà quali segreti potrebbe nascondere? Diamo un'altra occhiata e vediamo se può portarci alla password sfuggente o a qualsiasi altra informazione preziosa.

Lanciando il comando gitea sotto /usr/local/bin troviamo che c'è configurato un server gitea su porta 3000 ma non accessibile all'esterno. Quindi dovremo utilizzare la nostra macchina per fare un ponte:

Abbiamo le credenziali di GITEA

Una volta entrati in GITEA entro nell'unico repo a cercare qualcosa di interessante.

Trovo il file backup.sh che contiene la password per scompattare i backup

A questo punto ho decifrato le password dei file 7z, dove sono presenti alcuni database SQLite e abbiamo giocato con Hashcat. Alla fine, ho scoperto che “johnmayer7” è la chiave magica della macchina.
Adesso è sufficiente un rapido salto SSH nella macchina utilizzando le credenziali di Tom per catturare la flag dell'utente.

Prima flag presa: 85a...........................048

Nessun privilegio sudo, ma c'è un file molto interessante doodleGrive-cli provo ad analizzarlo:

e questo è il risultato:

Ora entriamo nella parte difficile! Eseguire un'iniezione SQL su un binario è una vera sfida.
Iniziamo enumerando i file con impostazioni SUID e GUID interessanti.
Analizziamo il file doodleGrive-cli. È qui che entra in gioco Ghidra: è come la lente d'ingrandimento magica per i binari.
Testo il codice con "moriarty:findMeIfY0uC@nMr.Holmz!". Se dovesse emergere qualcosa di interessante, sono pronto ad esplorare ulteriormente.
Sembra che potremmo riuscire a sferrare un attacco RCE qui. La strada principale che sto esplorando, e forse l'unica adatta alla nostra situazione, è sfruttare la funzione load_extension in SQLite3.

Dopo alcuni test approfonditi, ho notato che l'applicazione filtra i caratteri "." e "/" da ciascun input e ha una lunghezza massima di input di 35 caratteri. Per aggirare la prima limitazione possiamo utilizzare la funzione char() per scrivere il nostro testo in ASCII. Per la seconda limitazione, devo mantenere il file a un solo carattere per risparmiare spazio.
Per iniziare, creerò un file C che contiene il codice per il comando. Nel mio caso, avevo bisogno di leggere la flag root, quindi ho eseguito un comando cat sul file root. Sfortunatamente, per qualche motivo non ho potuto eseguire una shell inversa o una shell root.

Adesso lo compilo con il seguente comando:

e poi rilancio il file doodleGrive-cli

A questo punto sarà sufficiente fare il cat di /tmp/a.txt per trovare la flag di root :-) 4eb...........................215