A cura di: Manuel Roccon ( Team Hackerhood )
In questo articolo tratteremo una simulazione di pentest in laboratorio, iniziando esplorando la superficie di attacco per poi sfruttare alcune tipologie di vulnerabilità con alcune tecniche di penetrazione per arrivare all’escalation per ottenere i privilegi di root.
Essendo un test a scopo didattico, andremo poi a capire quali siano le vulnerabilità per cui si è riusciti a sfruttare e come evitare queste situazioni.
Tool utilizzati
· Nmap: tool per scansionare le porte, identificare i servizi e utilizzare il suo sistema di scripting per eseguire delle analisi di sicurezza su vari servizi
· Dirb: tool per eseguire il fuzzing http delle directory
· Nikto: vulnerability scanner che consente di individuare problemi di sicurezza negli applicativi web
· Burp Suite: utilizzato per fare fuzzing intensivo all’interno della web application
· Hash-identifier: tool per identificare il formato di un hash
· Hashcat: permette di eseguire il cracking degli hash
· Linpeas: è uno script che ricerca possibili percorsi per aumentare i privilegi su Linux/Unix
· Linux-privesc-check: Eseguibile che ha lo scopo di trovare configurazioni errate che potrebbero consentire agli utenti locali senza privilegi di aumentare i privilegi ad altri utenti o di accedere alle app locali (in questo caso è stato solo caricato ma il precedente ci aveva già dato le informazioni giuste)
· Metasploit: framework open source per lo sviluppo e l’esecuzione di exploits ai danni di una macchina remote
ANALISI
Iniziamo a scansionare porte e servizi.
Risulta aperta solo la porta http 80.
Individuiamo già la versione di Apache (2.4.6) e php (7.3.30)
Non si denotano delle vulnerabilità importanti che possiamo sfruttare, mentre di apache non abbiamo la fix attuale quindi dovremmo a tentativi nel provare le CVE della versione 2.4.6.
Ora ci concentriamo sull’unica porta aperta che conduce a un sito web.
Proseguiamo l’analisi usando Nikto per individuare eventuali tracce:
Dall’output individuiamo già alcune informazioni interessanti:
È presente una directory www, che in realtà è base url del portale; quindi, informazioni che abbiamo già ricavato e 1 directory dove è abilitato il listing di default di apache e un file che potrebbe essere interessante.
Andiamo ad analizzare:
I documenti appena trovati sono dei file di default lasciati nella home directory e quindi poco interessanti. Per una configurazione corretta nel server dovrebbe essere disabilitata tale listing (indexing).
Proviamo a eseguire del fuzzing nel percorso base del sito tramite dirb.
La scansione non restituisce particolari informazioni, notiamo anche che il listening è stato disabilitato nella directory www, per cui non possiamo esplorare il contenuto alla ricerca di file interessanti via browser.
Ora proviamo analizzare meglio il sito, notiamo subito che in alto a destra del menu è presente un bottone per eseguire qualche tipo di login.
Se cliccato porta a un form di login
Quindi, apriamo burp suite e facciamo transitare tutto il traffico web per poterlo analizzare.
Proviamo a inserire alcuni caratteri speciali nel tentativo di visualizzare qualche errore che conduca a un SQL Injection.
Quindi proviamo a includere alcuni caratteri particolari (es. ‘ ” #), caratteri usati in fase di costruzione della query lato back end per delimitare testo e variabili.
Il risultato però restituisce sempre che l’accesso è negato.
Proviamo osservare meglio tutte le pagine del sito e il codice sorgente.
Ci soffermiamo in una pagina dal menu PDF, in cui è possibile scaricare un PDF.
Analizzando il codice sorgente ci accorgiamo che il link al PDF non apre semplicemente un PDF nella directory pubblica, ma invoca una funzione javascript.
Torniamo in burp e verifichiamo la chiamata
In realtà viene aperta una chiamata parametrizzata a un file PHP GetPdfFromID.php, che si occupa invocare l’apertura del pdf, è presente in ID.
Proviamo a eseguire il repeater della chiamata come fatto precedentemente, inserendo un carattere speciale visto prima:
Ci viene restituito un errore, si tratta di un errore SQL.
È chiaro che input sta interferendo in qualche modo con la query e probabilmente non è stato sanificato.
Tentiamo di estrarre dei dati tramite UNION BASED SQL Injection, una tipologia molto comune assieme TIME BASED o ERROR BASED.
Cominciamo a determinare il numero di colonne su cui costruire la nostra query, il risultato si raggiunge iniettando “1 order by n#” dove n partirà da 1 e si fermerà quando viene visualizzato un errore SQL.
A numero 5 viene generato un errore. Quindi i campi della query sono 4.
A questo punto sapendo le colonne della query della tabella dove la query originale sta facendo la select, possiamo aggiungere una union con una seconda select che estrae esatto numero di colonne, in una di queste colonne ci facciamo restituire quello che cercheremo (nelle altre tre colonne possiamo mettere qualsiasi valore).
Cerchiamo di capire che database gira nel server.
In questo caso risulta MariaDB. Ora individuiamo le tabelle per capire quali potrebbe essere interessante leggere:
La risposta restituirà una serie di risultati. Individuiamo una tabella con nome users, potrebbe contenere delle informazioni utili per il form di login visto prima.
Verifichiamo le colonne di questa tabella.
Ok le colonne che ci interessano sono username e password, adesso estraiamo i dati.
Perfetto ora abbiamo username e password.
Purtroppo, la password non è in chiaro, andiamo a identificare che tipo di hash è tramite hash-identifier.
Sembrerebbe un MD5, proviamo a usare hashcat per craccare la password tramite il dizionario rockyou presente in kali linux.
La password è relativamente semplice, da notare che, anche se il processo sarebbe stato più lento, sarebbe stato possibile anche eseguire il modulo repeater tramite burp suite con lo stesso dizionario.
Ora proviamo ad accedere tramite il form visto prima.
Dopo aver eseguito il login vicino al banner centrale della home è comparso un tasto di modifica slide.
Proviamo a verificare di cosa si tratta:
È apparso un form con alcuni bottoni per la modifica e il caricamento delle immagini del banner.
È già presente anche un’immagine già caricata, che è quella della slide già presente, andando a ispezionare vediamo che punta in un percorso pubblico.
Sappiamo che il sito è scritto in php, proviamo a caricare un semplice file con all’interno un echo per vedere se viene eseguito e visualizzato.
Carichiamo il documento tramite il bottone aggiungi immagine e notiamo che si è aggiunta una slide. Verificando la chiamata da ispeziona elemento verifichiamo anche che viene invocato il file UploadSlideImg.php nella directory php.
Ritorniamo a ispezionare l’elemento appena caricato e possiamo verificare il percorso del file.
È stato caricato il file con l’estensione originale, quindi proviamo ad aprirlo.
Ok ora il codice php è stato eseguito.
Ora il nostro obiettivo è avere una shell e poter interagire con il sistema.
Proviamo a usare metasploit, creiamo un payload php da eseguire.
Ed avviamo un listener in ascolto sulla stessa porta nella macchina attaccante.
Ispezioniamo la pagina per andare alla ricerca dell’url e da browser apriamo il link.
Ok ora siamo connessi alla macchina.
L’unico limite è la durata dello script php, ma se non sono state messe limitazioni non dovrebbe terminare, altrimenti dovremmo provare a muoverci in un altro processo all’interno della macchina.
Ora avviamo la shell (apriamoci anche una shell interattiva).
Come si può vedere non siamo utenti privilegiati, ma abbiamo i permessi di apache.
Dobbiamo per forza scalare i privilegi. Proviamo a usare un modulo di metasploit per individuare alcuni exploit attivabili, senza nessun successo.
Facciamo upload di 2 tool utili (linpeas e linux-privesc-check) per individuare dei punti di accesso per tentare l’escalation di permessi e li copiamo in /tmp/ che generalmente tutti gli utenti hanno il permesso di farlo.
Impostiamo anche il permesso di esecuzione tramite chmod e avviamo il tutto.
Cerchiamo un po’ tra output apparso e troviamo che è stato configurato un eseguibile per cui qualunque utente può avviarlo con i permessi di root.
Ci soffermiamo un attimo sulla prima rilevazione.
Iniziamo ad eseguire vi come sudo avendo il permesso
Leggendo le specifiche di VI, sembrerebbe possibile lanciare dei comandi shell di linux
:!UNIX_command
Quindi avviamo la bash nel modo appena trovato.
A questo punto verifichiamo l’utente corrente ed effettivamente siamo root.
CONCLUSIONI
Questo test ci dimostra quanto errori di sviluppo e mancati controlli, oltre a configurazioni poco sicure dei server possano mettere a rischio la sicurezza di un’applicazione e il sistema stesso.
Ora però analizziamo nel dettaglio cosa ha causato tutto questo:
SQL INJECTION
Nel primo caso, il problema è dovuto al fatto che input non è stato filtrato a dovere, non vengono eliminati i caratteri che potrebbero interferire con la query SQL
Nel file GetPdfFromID.php usato per restituire il pdf, viene controllato solo se ID è vuoto e se è passato via chiamata post.
Se al parametro $id viene aggiunto questo altro pezzo alla query “1 and 1=0 union select null,null,null, concat (id,0x0a,username,0x0a,password,0x0a,admin) from users##” è possibile modificare il comportamento finale.
Vediamo nel dettaglio:
Alla query sottostante
$sql=”SELECT * FROM pdfs WHERE id=” . $id;
aggiungiamo la query descritta sopra, la query finale diventerà:
$sql=”SELECT * FROM pdfs WHERE id=1 and 1=0 union select null,null,null, concat (id,0x0a,username,0x0a,password,0x0a,admin) from users##”
Per cui verrà eseguita la union con la seconda query e stampato a video i risultati.
APPROFONDIMENTO
Il carattere # viene inserito per invalidare dal motore database tutto il contenuto successivo nel caso ci fossero altre condizioni di where dopo il parametro ID in cui iniettiamo altro pezzo di codice SQL, altrimenti la query darebbe un errore di sintassi e fallirebbe.
Esempio:
$sql=”SELECT * FROM pdfs WHERE id=” . $id . ” and name!=NULL”
$id = “1 and 1=0 union select null,null,null, concat (id,0x0a,username,0x0a,password,0x0a,admin) from users##”
Il risultato sarebbe:
$sql=”SELECT * FROM pdfs WHERE id=1 and 1=0 union select null,null,null, concat (id,0x0a,username,0x0a,password,0x0a,admin) from users## and name!=NULL”
Quindi il motore database elaborerebbe questa query
SELECT * FROM pdfs WHERE id=1 and 1=0 union select null,null,null, concat (id,0x0a,username,0x0a,password,0x0a,admin) from users
Se invece analizziamo come mai il login non ha dato errore tentando di inserire caratteri speciali.
Notiamo che è stata usata una funzione addslashes per aggiungere gli slash ai caratteri sotto riportati in modo da non far interferire questi caratteri con la query quando viene composta la query sql.
PASSWORD CRACKING
In questa vulnerabilità è stata sfruttata una password debole, assieme al sql injection per estrarre hash, tramite un software usato per decifrare hash debole usando un comune dizionario si è giunti a scoprire la password.
UPLOAD PHP
Verifichiamo il file UploadSlideImg.php che si occupa di caricare l’immagine nel sito.
In questo caso non è stata verificata l’estensione del file, permettendo di caricare dei file con estensione php direttamente in una directory pubblica del sito. Oltre tutto il file viene posizionato in una directory pubblicamente accessibile tramite path, motivo in più per cui è stata sfruttata.
PRIVILEGE ESCALATION
In questo caso è stato inserito nel file /etc/sudoers le istruzioni per permettere a tutti gli utenti della shell di eseguire VI come amministratore.
VI poi ha la possibilità di avviare una shell partendo dall’editor
REMEDIATION
Di seguito elencate le possibili mitigazioni e remediation ai problemi riscontrati.
· Sanificare tutte le request in entrata prima di usarle per comporre stringhe SQL
· Imporre password forti e algoritmi salted di cifratura
· Verificare il contenuto degli upload e posizionarlo in una directory che sia pubblica
· Evitare di impostare dei software in esecuzione come root per tutti gli utenti
Comments are closed