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.
