Negli articoli precedenti abbiamo visto l’architettura del C2, in questo mostriamo alcune vulnerabilità facili da identificare.

Sebbene semplici, queste vulnerabilità permettono (o meglio lo permettevano) di arrivare ad installare shell PHP sul C2.

YAU – YET ANOTHER URSNIF

Questo è il sedicesimo di una serie di articoli, tutti raggruppati qui.

Credenziali di default

Nella root dei sorgenti è presente un file chiamato monitoring.sql.
Questo è usato per creare le tabelle del DB del C2, tra le varie operazioni fatte vi è anche quella di creazione dell’utente admin.

L’hash che si vede in figura è un MD5, da una semplice ricerca si individua la corrispondenza con la password admin123.
La coppia di credenziali admin/admin123 è stata usata a lungo per l’accesso alla console di amministrazione.
Da almeno un anno a questa parte, non viene più usata.
Gli autori di Ursnif si sono accorti delle tracce lasciate nel C2 da alcuni incauti analisti e come prima misura hanno cambiato la password di default.

Statistiche pubbliche

Come abbiamo visto nell’articolo precedente, il resoconto delle vittime per paese non è protetto da una chiamata a Visitor::pagesRequiresLogin, per cui è possibile visualizzarlo tramite l’url /index/external.

Esiste anche un controller (external) apposito che replica la stessa funzionalità, anch’esso non protetto da login.

Questo controller è visibile all’URL /external.

Sebbene le informazioni visualizzate siano limitate, queste pagine pubblicamente accessibili permettono di avere un’idea dell’impatto della campagna.
In base a questo, un analista può valutare la possibilità di procedere con altre azioni.

Creazione di utenti

Continuando a scrutinare il codice del C2, non passa inosservato che il metodo AuthController::register non è protetto da una chiamata a Visitor::pageRequiresLogin.

Questo metodo permette di creare un nuovo utente, non essendo protetto da autenticazione, basta invocarlo con delle credenziali a scelta.

curl -X POST -d 'login=username&password=password' http://evilursnifserver.xyz/auth/register

Una volta creata una nuova coppia di credenziali, la si può usare per accedere alla console di amministrazione.

Essere più stealth

Creare una nuova coppia di credenziali lascia una traccia evidente nel C2.
Non è raro vedere un intenso “traffico” nelle console di Ursnif, un metodo migliore consiste nel:

1. Creare una coppia di credenziali.
2. Loggarsi e salvare il cookie di sessione PHP.
3. Eliminare le credenziali appena create.
4. Continuare ad usare il cookie di sessione.

Se guardiamo il codice che cancella una coppia di credenziali, notiamo due cose: la prima è che viene fatta una cancellazione logica, per cui le credenziali rimarranno nel DB; la seconda, che la sessione dell’utente non viene invalidata, di fatto non effettuando un log out.

Se tramite strumenti automatizziamo i primi tre passi elencati sopra, possiamo avere accesso al C2 di Ursnif senza lasciare tracce nella GUI.
Nel database saranno sempre presenti le nostre credenziali ma è meno immegiato che vengano scoperte.

Directory listing in /upload

Come abbiamo visto quando abbiamo recuperato i sorgenti, il C2 di Ursnif è aperto a vari directory listing.

Il più importante è sicuramente quello sul repository GIT ma ve ne sono altri.

Uno è sulle cartelle temporanee create dagli editor: /.idea. Non abbiamo verificato se negli ultimi setup questa cartella sia ancora presente.

Un altro directory listing molto utile è in /upload. Qui sono mostrati i moduli, divisi per group id, caricati nel C2.
Come abbiamo visto negli articoli precedenti, questi verranno scaricati dalle vittime e decodificate.
In alcuni C2 recenti questi directory listing sono stati rimossi.
Sempre negli articoli precedenti abbiamo visto come usare ureq, ukey ed umod per il download e la decifratura dei moduli.

Upload di shell

Questa è forse la vulnerabilità più importante, richiede l’accesso alla console di amministrazione.

Diciamo subito che questa vulnerabilità è stata risolta intorno al 1 dicembre 2020 (quindi recentemente), molto probabilmente a seguito dell’utilizzo incauto di alcuni analisti che non hanno ripulito le proprie tracce.
La patch usata per risolvere questa vulnerabilità non è corretta al 100%, lasciando la possibilità di fare upload di file con estensione “.bin” in percorsi arbitrari.

Osserviamo il codice, prima della patch, del controller che gestisce l’upload dei moduli (vedi un articolo precedente per le funzionalità della console di amminsitrazione).

Si nota che:

• Viene creata una cartella in /upload/<group_id>. Siccome <group_id> è controllabile dall’utente, possiamo creare cartelle in percorsi arbitrari (eventualmente in più passi).
• Non sono fatti controlli sullo stato dell’upload dei file, possiamo quindi simulare un upload fallito per creare solo la cartella del punto sopra. Questo ci permette di creare percorsi arbitrari.
• Ogni file viene copiato in /upload/<group_id>/<nome_file>, le ultime due componenti sono controllabili dall’utente.
  Possiamo quindi uploadare file con nomi arbitrari, inclusa l’estensione PHP che ci permette di farli interpretare dal web server. Otteniamo così la possibilità di eseguire codice sul server.

Si tratta di una vulnerabilità piuttosto semplice, talmente semplice che probabilmente è stata usata nel modo più banale possibile: caricare in /upload/<group_id> una shell PHP preconfezionata.
Questo comportamento lascia tracce evidenti, infatti gli autori di Ursnif hanno introdotto i seguenti cambiamenti:

Questa patch controlla che il nome del file caricato termini con “.bin“.
Le funzioni PHP usate, gestiscono correttamente eventuali byte nulli nel nome del file.
Fatta eccezione di move_uploaded_file, la quale potrebbe essere usata per bypassare banalmente il controllo. Un file con nome “shell.php\0.bin” passerebbe i controlli e verrebbe copiato in “shell.php“.
Sfortunatamente Apache (web server usato nei C2 di Ursnif) non permette l’utilizzo di byte nulli nelle intestazioni HTTP (il nome del file è in un’intestazione della relativa parte MIME).

E’ interessante notare come questa vulnerabilità sia stata presente nel C2 di Ursnif da tempi immemori e come solo ultimamente sia stata patchata.
Questa risposta si è verificata proprio in seguito all’intensificarsi delle attività degli analisti nel C2 di Ursnif.