CVE-2018-1263-Demo

Demo educativa di exploit per CVE-2018-1263 (RCE/LFI in phpMyAdmin). Include configurazione dell'ambiente vulnerabile tramite Docker e guida passo-passo all'attacco per apprendere lo sfruttamento delle applicazioni web.

La vulnerabilità è causata da un bypass di validazione nella funzione vulnerabile di controllo del percorso. Questa vulnerabilità consente a un attaccante remoto autenticato di eseguire codice PHP arbitrario sul server.

C'è un'inclusione di file in index.php di phpMyAdmin che può essere innescata fornendo un parametro chiamato target nell'URL e la porzione di codice che valida il parametro target è la seguente:

In questo codice, una volta che la condizione if è soddisfatta, esegue include $_REQUEST['target'];. Quindi dobbiamo solo aggirare la condizione if per eseguire ciò che vogliamo.

Osserviamo la condizione if

1. Le prime due condizioni affermano che il parametro target non può essere vuoto e deve essere una stringa.
2. La terza condizione impedisce al parametro target di iniziare con index.
3. La quarta condizione impedisce che il parametro target sia in $target_blacklist
   • La $target_blacklist è definita subito prima della condizione if e include import.php e export.php, il che significa che tutto tranne queste due pagine è consentito.
4. La quinta e ultima condizione è un controllo di whitelist per la validità della pagina utilizzando una funzione esistente nella classe Core: Core::checkPageValidity($_REQUEST['target']).
   • Come mostrato nel frammento di codice qui sotto, la funzione checkPageValidity rimuove tutto ciò che sta dopo ? da $page e verifica se è nella whitelist. La stringa dopo ? non fa parte del percorso dell'URL. Nello snippet è mostrata anche una whitelist di esempio.
   root@kitploit:~

   public static function checkPageValidity(&$page, array $whitelist = [])
   {
       // ...
       $_page = mb_substr($page, 0, mb_strpos($page . '?', '?'));
       // example $whitelist == array('db_sql.php', 'sql.php', ...)
       if (in_array($_page, $whitelist)) {
           return true;
       }
       // ...
       return false;
   } 
   

   • Il punto importante da notare qui è che l'attaccante ha il controllo completo di $page, poiché arriva direttamente da $_REQUEST['target'].

Come funziona l'attacco

Come accennato in precedenza, l'attaccante ha il controllo completo su $page nella funzione checkPageValidity tramite il parametro $_REQUEST['target'] nell'URL. Immaginiamo che l'attaccante invii qualcosa come quanto segue usando il parametro $_REQUEST['target'] verso $page

La funzione checkPageValidity esegue quindi quanto segue

1. Prima divide la stringa in corrispondenza di ? e assegna la prima parte a $page. Quindi in questo caso di esempio il valore di $page = db_sql.php.
2. Successivamente controlla se $_page, cioè db_sql.php, è nella whitelist o no. Poiché è nella whitelist, la funzione restituisce True e si torna a index.php

Poiché la condizione if in index.php ora è True, esegue la riga seguente come mostrato nello snippet di codice di index.php sopra

Cosa succede dopo:

• L'istruzione precedente include il valore non diviso di $_REQUEST['target'], il che significa che viene eseguito quanto segue
  root@kitploit:~

  GET /index.php?target=db_sql.php?/../../../../../../../../etc/passwd
  

• Poiché PHP converte magicamente il percorso in /../../../../../../../../etc/passwd senza controllare se db_sql.php esiste o no, /../../../../../../../../etc/passwd viene eseguito e il contenuto del file /etc/passwd viene inviato nella risposta all'attaccante.

Ora possiamo usare questo per eseguire l'inclusione di file locali o persino l'esecuzione remota di codice per ottenere una reverse shell. Ogni volta che eseguiamo una query in phpMyAdmin, viene creato un file di sessione e memorizzato nella directory /tmp con il contenuto della query. Il file di sessione è chiamato sess_< ID_SESSIONE >. L'ID di sessione può essere facilmente trovato nel cookie usando l'opzione di ispezione del browser.

Quindi, se eseguiamo la seguente query in phpMyAdmin

Verrà memorizzata nel file di sessione. Immaginiamo che il nostro ID di sessione per phpMyAdmin sia e15cffd3ab25a631136611fba9ca2042

Quindi, se attiviamo il seguente indirizzo nel browser

Allora phpMyAdmin proverà a caricare la pagina di sessione e, poiché la pagina contiene il codice PHP fornito tramite la query, il codice PHP verrà eseguito e in questo particolare esempio vedremo phpinfo nella pagina caricata dal browser. Usando questa tecnica possiamo eseguire qualsiasi codice arbitrario sul server remoto.

Come installare il componente vulnerabile

L'infrastruttura dell'exploit richiede una versione vulnerabile di phpMyAdmin e mysql. Useremo container docker per installare i componenti richiesti. Per la versione vulnerabile di phpMyAdmin useremo l'ambiente docker predefinito di Vulhub e per mysql useremo l'ultima versione ufficiale da dockerhub. Lo script di installazione è fornito come script yml di docker compose che si trova nel repository.

Supponiamo che la macchina in questione abbia docker e docker-compose installati. In caso contrario, fare riferimento alla documentazione di docker per installarli. Una volta installato docker, eseguire i seguenti passaggi per configurare il componente vulnerabile:

Per prima cosa clona il repository sulla macchina desiderata e spostati nella directory clonata

Quindi esegui lo script docker compose usando il seguente comando

Una volta terminato il processo di installazione, docker esporrà la pagina di phpMyAdmin sulla porta 8080 della tua macchina. Puoi verificarlo aprendo la pagina nel browser usando il seguente formato di indirizzo

Se il processo di installazione ha avuto successo, dovresti vedere una pagina come la seguente

Come eseguire l'attacco

Il seguente video è un tutorial su come eseguire l'attacco

Link al video: https://drive.google.com/file/d/1UbLGEwMYswdrRAOMJLd0mFHbsNl1aPvt/preview

Riferimenti

[1] https://www.exploit-db.com/exploits/44928

[2] https://github.com/vulhub/vulhub

[3] https://docs.docker.com/get-docker/