kpn-ciso/dra_writeupWriteup della vulnerabilità di stack buffer overflow di Oracle DSR (DRA) CVE-2014-6598
KPN è un operatore di telecomunicazioni con sede nei Paesi Bassi. Il CISO REDteam è stato introdotto nel 2013 ed è il team di ethical hacking di KPN. Questo team è coinvolto nei test di sicurezza delle applicazioni e dei servizi KPN per garantire che i dati dei nostri clienti siano al sicuro da accessi non autorizzati, modifiche e perdita di dati.
KPN gestisce la più grande rete mobile nei Paesi Bassi. Uno dei componenti della rete 4G gestita da KPN è l'applicazione Diameter Routing Agent denominata Oracle Diameter Signalling Router (DSR). Il Diameter Routing Agent (DRA) è un elemento funzionale in una rete 3G o 4G che fornisce capacità di instradamento in tempo reale per garantire che i messaggi vengano instradati tra gli elementi corretti di una rete. Il [3GPP] ha introdotto il DRA per gestire il volume crescente del traffico di segnalazione Diameter e la crescente complessità delle reti 4G LTE. Può essere distribuito sia come router core che instrada il traffico tra gli elementi Diameter nella rete domestica, sia come router gateway che instrada il traffico tra gli elementi Diameter nella rete domestica e in roaming. Il 3GPP specifica l'uso del protocollo Diameter per diverse interfacce, inclusa una (S6a) utilizzata per la comunicazione MME-HSS e per il roaming.
L'immagine seguente mostra una tipica implementazione del DRA in un ambiente LTE. Tutte le interfacce tra gli elementi sono interfacce S6a.
Oracle DSR è un cluster di macchine che esegue CentOS Linux e svolge la funzione DRA. Di solito è connesso a diversi MME e a un HSS nella rete LTE domestica, ma potrebbe anche essere connesso a partner di roaming tramite la rete IPX.
Utilizzando la piattaforma [Codenomicon] DEFENSICS, il KPN REDteam ha scoperto due gravi vulnerabilità nell'applicazione Oracle DSR versione 5.0:
dsr.La prima vulnerabilità consente a un attaccante remoto non autenticato connesso alla rete IPX di compromettere completamente il DRA e i suoi componenti. Quando un attaccante ottiene il pieno controllo del sistema DRA, è in grado di monitorare tutto il traffico instradato attraverso il DRA e possibilmente di infiltrarsi ulteriormente nella rete core dell'operatore di telecomunicazioni.
Oracle ha preso seriamente le vulnerabilità segnalate e il KPN REDteam ha collaborato strettamente con Oracle per risolvere questi problemi, come dichiarato anche nel loro avviso ai clienti:
"I recenti test di sicurezza hanno identificato due vulnerabilità di sicurezza nelle versioni del prodotto Oracle Diameter Signaling Router. Per proteggere la rete da potenziali exploit di queste vulnerabilità, Oracle raccomanda vivamente di applicare senza indugio le azioni descritte nel presente documento. Oracle riconosce a Frank Cozijnsen, Ethical Hacker, KPN CISO REDteam, la scoperta della vulnerabilità Diameter Stack descritta di seguito. Un ringraziamento speciale va a KPN per il supporto fornito durante la fase di analisi di Oracle. Nota: questi risultati saranno divulgati pubblicamente con il prossimo CPU di Oracle previsto per il 20 gennaio 2015."
I problemi riscontrati rappresentano una seria minaccia per gli operatori di telecomunicazioni che utilizzano il DSR di Oracle e potrebbero essere sfruttati da qualsiasi attaccante con accesso a una connessione IPX.
Il KPN REDteam testa prodotti e servizi prima che vengano distribuiti in reti di produzione. Nell'ambito di un progetto di aggiornamento, il KPN REDteam ha testato Oracle DSR versione 5.0 dal punto di vista della sicurezza. Il test di sicurezza includeva il fuzzing dell'implementazione DIAMETER di Oracle DSR utilizzando la [Codenomicon Diameter Server test Suite]. Come primo obiettivo di fuzzing è stato utilizzato il messaggio Capabilities Exchange Request (CER), che viene usato per verificare le capacità DIAMETER del server ricevente. Questo messaggio è stato scelto perché non viene inoltrato ad altri sistemi come l'HSS, ma viene gestito dal DSR stesso. Durante il fuzzing, sono stati notati diversi crash del processo "dsr" sulle blade Message Processor (MP) del DSR.
Utilizzando GDB con il plugin [PEDA], il crash è stato analizzato e alla fine è stato scritto un exploit remoto. Il crash è stato causato da una scrittura fuori dai limiti oltre la fine del buffer situato sullo stack. La scrittura fuori dai limiti ha corrotto lo stack con dati controllati dall'utente. Anche il puntatore di ritorno salvato, cioè l'indirizzo al quale il programma ritorna dopo l'uscita da una funzione, è stato sovrascritto. Quando questo puntatore di ritorno può essere controllato dall'attaccante, può portare all'esecuzione di codice arbitrario.
Il motivo principale di questo blog è spiegare come il KPN REDteam sia riuscito a superare le protezioni ASLR e NX presenti e a creare un exploit funzionante di esecuzione remota di codice. Normalmente i meccanismi di protezione ASLR e NX non rappresentano un grande ostacolo per gli attaccanti, ma il DSR gira su CentOS a 64 bit. Non esiste molta documentazione pratica sulla programmazione orientata al ritorno (ROP) su sistemi Linux a 64 bit protetti da ASLR.
Durante il debug si è notato che la libreria libc era sempre mappata allo stesso indirizzo nel processo dsr e che l'indirizzo non cambiava dopo un riavvio. Altre librerie erano mappate a indirizzi di memoria casuali nel processo dsr. Conoscere l'indirizzo di memoria di libc consente di utilizzare libc come fonte per i gadget ROP. Un'altra opzione è usare il binario dsr stesso come fonte di gadget ROP, ma la quantità di gadget utili in quel file è limitata.
Per bypassare la protezione NX si potrebbe usare la funzione mprotect() per rendere eseguibile lo stack e poter eseguire il nostro shellcode.
La funzione mprotect() richiede i seguenti valori nei registri corrispondenti:
Se tutti questi registri sono impostati, mprotect() può essere chiamato all'offset 0xe54b0 nella versione target della libreria libc.
La parte seguente del documento presuppone la conoscenza della ROP e del suo funzionamento. Su [shell-storm.org] c'è un buon esempio di creazione di una catena ROP su un sistema Linux a 32 bit. A causa dell'ASLR "parziale", la posizione dello stack stesso non era prevedibile. Sono stati utilizzati gadget ROP per memorizzare il valore del puntatore allo stack (%RSP) nel registro %RSI.
Il registro %RDI deve contenere l'offset di memoria della regione di memoria che deve essere resa eseguibile.