Riepilogo

La logica di validazione degli URL applicata quando si gestisce /appsuite/api/oxodocumentfilter&action=addfile presenta tre difetti che possono essere utilizzati per eseguire un attacco SSRF di tipo Time of Check Time of Use (ToCToU). Questo problema consente ad attori malintenzionati di eseguire richieste HTTP GET su servizi di rete interni e può portare alla divulgazione di informazioni protette.

Difetto #1: vulnerabilità Time of Check Time of Use (ToCToU)

La logica di validazione degli URL nel metodo URITools.getFinalURL implementato qui presenta una vulnerabilità ToCToU

URL u = new URL(url);
if (validator.isPresent()) {
    Optional<OXException> exception = validator.get().apply(u);
    if (exception.isPresent()) {
        throw exception.get();
    }
}

URLConnection urlConnnection = u.openConnection();

Nel codice sopra riportato, la risoluzione DNS del nome host dell'URL di input viene eseguita sia al momento del controllo (validator.get().apply(u)) sia al momento dell'uso (u.openConnection()) chiamando il metodo InetAddress.getByName. Quindi, se un attaccante può modificare il risultato della risoluzione DNS dopo il momento del controllo e prima del momento dell'uso, può bypassare il validatore. Questo singolo difetto è estremamente difficile da sfruttare a causa delle seguenti limitazioni:

1. Per impostazione predefinita, InetAddress.getByName memorizza nella cache i risultati della risoluzione DNS per 30 secondi se la risoluzione DNS ha successo e per 10 secondi se la risoluzione DNS fallisce.
2. L'intervallo di tempo tra validator.get().apply(u) e u.openConnection() è estremamente ridotto (meno di un millisecondo per gli URL normali). Il Difetto #2 viene utilizzato per bypassare questa limitazione.

Difetto #2: la lunghezza dell'URL di input non è limitata

Il validatore URL AddFileAction.validator implementato qui non valida la lunghezza dell'URL di input. Fornendo un URL di grandi dimensioni, l'attaccante può aumentare l'intervallo di tempo tra le chiamate al metodo InetAddress.getByName al momento del controllo e al momento dell'uso. Un intervallo di tempo maggiore consente all'attaccante di sfruttare facilmente il Difetto #1.

Difetto #3: il validatore URL accetta l'URL di input se la sua risoluzione DNS fallisce

Il metodo HostList.contains implementato qui restituisce false se la risoluzione DNS del nome host dell'URL di input fallisce.

// Need to resolve as last resort
try {
    return contains(InetAddress.getByName(toCheck), false);
} catch (UnknownHostException e) {
    // Cannot be resolved
    return false;
}

Il AddFileAction.validator chiama il metodo blackImageUrlHostlist.contains per verificare se il nome host dell'URL di input o l'indirizzo IP a cui risolve è nella blacklist. Se un attaccante fa fallire la risoluzione DNS del nome host, i controlli sull'indirizzo IP vengono saltati e l'URL viene accettato.

Strategia di attacco

Si consideri un nome host randomid.dns.pointer.pw con nameserver autoritativo controllato dall'attaccante. La strategia d'attacco consiste nel far fallire la risoluzione DNS di randomid.dns.pointer.pw al momento del controllo (validator.get().apply(u);) e farla riuscire al momento dell'uso (u.openConnection()). Ciò consente all'attaccante di bypassare i filtri della blacklist degli indirizzi IP ed eseguire una richiesta HTTP GET su qualsiasi indirizzo IP in blacklist. L'attaccante può seguire i seguenti passaggi per eseguire questo attacco:

1. Attiva la cache di InetAddress.getByName sul server eseguendo l'azione addfile con i dati della richiesta {"add_imageurl": "http://randomid.dns.pointer.pw"}. In questo momento, il server DNS autoritativo sarà configurato per far fallire la risoluzione DNS di randomid.dns.pointer.pw restituendo lo stato SERVFAIL. InetAddress.getByName memorizzerà nella cache questo risultato di fallimento per 10 secondi.
2. Annota l'ora in cui è stata ricevuta la risposta alla richiesta precedente. Questo è il tempo di inizio della cache.
3. Indica al server DNS autoritativo del dominio pointer.pw di restituire 127.0.0.1 per le richieste DNS di tipo A del nome host randomid.dns.pointer.pw.
4. Attendi per una durata specificata dal tempo di inizio della cache, in modo che nel passaggio successivo InetAddress.getByName restituisca la risposta memorizzata in cache (SERVFAIL) al momento del controllo e restituisca 127.0.0.1 al momento dell'uso (url.openConnection()).
5. Esegui la richiesta SSRF con il valore add_imageurl impostato al formato . Qui u{25MB} significa che la parte relativa al nome utente è una stringa di lunghezza 25 x 1024 x 1024 caratteri.

Passaggi per riprodurre

1. Installare golang da https://golang.org/dl/
2. Installare Open-Xchange e Documents in una macchina virtuale con almeno 4GB di RAM seguendo le guide https://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_Debian_9.0 e https://oxpedia.org/wiki/index.php?title=AppSuite:Documents_Installation_Guide#Debian_GNU.2FLinux_9.0_.28valid_from_v7.10.29
3. Scaricare ed estrarre il file poc.zip
4. Aprire il terminale / la riga di comando e impostare la directory corrente sulla cartella estratta di poc.zip
5. Eseguire il comando

 go run . -serverRoot="http://172.16.66.130" -username="testuser" -password="secret" -targetPath="appsuite/v=7.10.3-9.20200409.083030/apps/themes/logo.png" -targetPort="80" -payloadSize=25 -startSleepDuration=6600

dove 172.16.66.130 è l'indirizzo IP della VM