THM-Steel_Mountain-CVE-2014-6287

Un write up sulla macchina Steel Mountain di TryHackMe.com e exploit per CVE-2014-6287

Crediti

Non prendo alcun credito per la scoperta e lo sfruttamento originali di questa vulnerabilità. Grazie alle seguenti persone!

Scoperta:
Daniele Linguaglossa

Autore del modulo Metasploit:
Muhamad Fadzil Ramli

Stanza e autore di TryHackMe:
https://tryhackme.com/room/steelmountain
https://tryhackme.com/p/tryhackme

Riferimenti:
https://nvd.nist.gov/vuln/detail/CVE-2014-6287
https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/http/rejetto_hfs_exec.rb
https://subscription.packtpub.com/book/networking_and_servers/9781786463166/1/ch01lvl1sec20/vulnerability-analysis-of-hfs-2-3 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6287 https://www.tutorialspoint.com/pascal/pascal_functions.htm

Se vedi qualcosa, dì qualcosa!

Non sono affatto un professionista della sicurezza esperto. Ciò significa che potrei fornire alcune informazioni errate. Se sei un professionista esperto/ricercatore con esperienza e vedi qualcosa di errato, per favore informami così posso tornare, studiare ciò che ho sbagliato e fornire le informazioni corrette. Questo è vantaggioso sia per me che per altri ricercatori alle prime armi che potrebbero imbattersi in questo write up. Se trovi informazioni errate che ho scritto, contattami a [email protected] così posso correggerle. Grazie!

Vulnerabilità

Rejetto file server (noto anche come HFS) è un programma di condivisione file utilizzato per pubblicare e condividere file attraverso una rete. Nella versione 2.3, c'era una vulnerabilità che permetteva a un attaccante di eseguire comandi di sistema inserendo un byte nullo nel parametro di ricerca come descritto in CVE-2014-6287. Il codice non elabora correttamente un byte nullo con la sua configurazione regex (Espressione Regolare) e quindi porta a una vulnerabilità di esecuzione di codice remoto.

La vulnerabilità si trova nella funzione findMacroMarker che ha origine dal file parserLib.pas. .pas è l'estensione del file per il linguaggio di programmazione Pascal. Al momento della scrittura, non ho mai programmato in Pascal. Diamo un'occhiata allo snippet di codice e analizziamo cosa fa!

function findMacroMarker(s:string; ofs:integer=1):integer;
begin result:=reMatch(s, '{[.:]|[.:]}||', 'm!', ofs) end;

La prima riga di codice è una dichiarazione di una funzione chiamata findMacroMarker che accetta due parametri. In Pascal, il tipo di dato dei parametri deve essere dichiarato, quindi s:string significa che la variabile s è una string, lo stesso vale per la variabile ofs con un tipo di dato integer. A destra dei parametri, vediamo un carattere due punti seguito da integer. Questo è noto come tipo della funzione. Il punto e virgola segna la fine di quella riga di codice. La prima parola nella riga successiva è begin. Questo dice al compilatore dove inizia la funzione. Proseguendo, vediamo una variabile chiamata result seguita dall'operatore di assegnazione :=. La variabile result viene assegnata alla funzione reMatch. Non sono riuscito a trovare nulla su reMatch su internet, quindi presumo sia una funzione personalizzata scritta da qualche altra parte in HFS. Fortunatamente per noi, la funzione è autoesplicativa. è chiaramente un'abbreviazione per "regular expression match" (corrispondenza di espressione regolare) seguita dal pattern regex che sta cercando, il quale è gestito nei parametri della funzione così come nei parametri variabili iniziali definiti nella prima riga di codice. Alla fine della seconda riga, la parola viene usata per definire la fine della funzione per il compilatore.

La vulnerabilità si trova nel pattern regex come descritto sopra nella funzione reMatch. La regex non riesce a gestire correttamente un byte nullo %00. Quando passiamo un comando di sistema con un byte nullo preposto, la funzione incontrerà il bug ed eseguirà il comando sul computer host. Per sfruttare questa vulnerabilità, tutto ciò che dobbiamo fare è passare il byte nullo nel parametro di ricerca di una richiesta GET seguito da {.exec|codice.} (codice è il comando che vuoi eseguire) tramite l'URL in questo modo:
http://(Indirizzo-IP/NomeDominio)/?search==%00{.exec|ComandoQui.}.

Analisi

Iniziamo con una scansione delle porte tramite rustscan. Preferisco rustscan per avere una rapida visione della superficie d'attacco.

Abbiamo un bel numero di porte aperte qui. Adesso scaveremo più a fondo con nmap e scopriremo quali servizi sono in ascolto su questa serie di porte per trovare il nostro servizio sfruttabile.

Abbiamo un servizio chiamato Microsoft Windows RPC in esecuzione sulle porte più alte. RPC sta per "Remote Procedure Call" (chiamata a procedura remota). Ciò consente ai processi Windows di comunicare attraverso una rete o internamente all'interno del computer stesso. Proseguendo, abbiamo alcuni server web diversi in esecuzione sulle porte 80 e 8080. Sulle porte 5985 e 47001, è presente Microsoft Httpapi Httpd che permette alle applicazioni di comunicare su HTTP senza la necessità di Microsoft IIS (Internet Information Server). Nmap rileva un potenziale server web in esecuzione sulla porta 3389, tuttavia non sono riuscito a connettermi via HTTP o SSL. Connettiamoci al server web sulla porta 80 poiché è la porta standard per il protocollo HTTP.

Sulla porta 80, ci viene presentata una pagina web che mostra il logo dell'azienda Steel Mountain e una foto etichettata "Employee of the month". Se apriamo gli strumenti di sviluppo web, possiamo vedere che la foto è denominata BillHarper.png, il che ci dà la risposta alla nostra prima domanda. Connettiamoci agli altri servizi in ascolto e vediamo cosa possiamo trovare.

Quando ci connettiamo al servizio sulla porta 5985, otteniamo un codice di errore HTTP 404. Il codice di errore 404 significa che il server non può trovare la risorsa richiesta. Non c'è nulla di interessante qui. Passiamo al successivo.

SÌ! Questo sembra interessante. Sulla porta 8080, abbiamo una sorta di servizio di condivisione file. Diamo un'occhiata in giro per vedere se possiamo trovare ulteriori informazioni su questo servizio. Se guardiamo nell'angolo in basso a sinistra, possiamo vedere un nome e quello che sembra essere un numero di versione come questo: HttpFileServer 2.3. Approfondiamo ulteriormente.

Se clicchiamo sul link etichettato HttpFileServer 2.3, veniamo reindirizzati a una pagina web con il nome del software in esecuzione sulla porta 8080. In questo caso, abbiamo Rejetto HFS HTTP File Server. Controlliamo l'altra porta sulla 47001 per coprire tutte le possibilità. Se non troviamo nulla di utile, possiamo tornare a Rejetto e iniziare a cercare CVE noti.

Sembra che abbiamo un altro 404 sulla porta 47001. Iniziamo a cercare CVE per Rejetto HFS 2.3.

Una rapida ricerca rivela che abbiamo una voce CVE nota per HFS 2.3. Ci allontaneremo dalla guida di THM e resteremo fuori dal Metasploit preconfezionato. Ho codificato un exploit che ci darà una shell. Per usarlo, devi andare su revshells.com, inserire le informazioni di rete corrette e selezionare PowerShell #3 (Base 64). Quando hai il payload, copialo e incollalo nella variabile payload alla riga 13 ed esegui l'exploit. Un listener si aprirà automaticamente e dovresti avere accesso al sistema. Nota: potrebbe essere necessario eseguire l'exploit più volte per catturare la shell.

Boom! Siamo nel sistema e, come bonus, abbiamo una shell PowerShell. Ciò significa che avremo accesso ai cmdlet .NET. Possiamo essere molto più pericolosi con questo rispetto alla shell standard del prompt dei comandi. Passiamo ora all'elevazione dei privilegi. La guida di THM ci fornisce uno strumento utile chiamato PowerSploit che ha uno strumento per enumerare la macchina alla ricerca di potenziali vettori di elevazione dei privilegi. Caricheremo PowerUp.ps1 sulla macchina e lo useremo per ottenere il controllo della macchina.

Per prima cosa, avviamo un semplice server HTTP nella directory che contiene il nostro file PowerUp.ps1 sul nostro sistema. Successivamente, sul sistema di destinazione, usiamo il cmdlet Invoke-Webrequest per prelevare il file dal nostro server alla macchina di destinazione. Ora installeremo e eseguiremo uno dei cmdlet forniti con PowerUp.

Per installare PowerUp.ps1, esegui questo comando: . .\PowerUp.ps1. Successivamente, dovremo usare il nostro nuovo cmdlet Invoke-AllChecks. Dopo averlo eseguito, ci viene presentata una miriade di output. L'ho ridotto a quello importante che ci interessa. Possiamo vedere che PowerUp ci ha detto che abbiamo i permessi per modificare il file. Controlliamo i servizi in esecuzione in modo da poterlo fermare se è in esecuzione. Dobbiamo farlo perché non possiamo fare nulla con il file se è in uso da un servizio.

Usando il cmdlet Get-Service, ci viene presentata una lista di servizi presenti sulla macchina. Poiché il nostro servizio di destinazione è in esecuzione, dovremo fermarlo in modo da poter modificare e sovrascrivere il binario.

Per fermare il servizio, usiamo il cmdlet Stop-Service seguito dal nome del servizio. Ora dobbiamo ricontrollare che il servizio sia fermo con il cmdlet Get-Service. Come mostrato sopra, possiamo confermare che il servizio si è effettivamente fermato. Spostiamoci nella directory che contiene il nostro binario di destinazione. La directory è C:\Program Files (x86)\IObit\Advanced SystemCare.

Prendi nota della dimensione del file del binario che si trova a sinistra del nome del binario nella colonna più a destra.

Crea un payload meterpreter e ospitalo con il modulo del server web Python come abbiamo fatto prima.

Avvia un listener meterpreter usando le stesse informazioni di rete che hai usato per creare il payload.

Usa il cmdlet Invoke-Webrequest per prelevare il nostro payload meterpreter sulla macchina di destinazione dal nostro sistema. Assicurati di chiamarlo ASCService.exe in modo da poter sfruttare i permessi deboli sui file e sovrascrivere il binario normale con il nostro binario malevolo.

Conferma che il binario è stato sovrascritto elencando la directory e controllando se la dimensione del file è cambiata. In questo caso, è passata da un numero a 6 cifre a un numero a 5 cifre, il che conferma che abbiamo caricato con successo il nostro binario malevolo!

Quando il binario malevolo ha sostituito quello normale, tutto ciò che dobbiamo fare è riavviare il servizio con il cmdlet Start-Service. Quando lo facciamo, la macchina eseguirà il nostro payload e ci darà una shell meterpreter! Possiamo eseguire getuid in meterpreter per verificare se abbiamo NT AUTHORITY/SYSTEM. Quando eseguiamo getuid, possiamo effettivamente vedere che abbiamo posseduto questa macchina! Che tu abbia una giornata fantastica!