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.
