kpn-ciso/dra_writeupAnálise da vulnerabilidade de estouro de buffer na pilha do Oracle DSR (DRA) CVE-2014-6598
A KPN é uma operadora de telecomunicações localizada nos Países Baixos. O CISO REDteam foi criado em 2013 e é a equipe de hacking ético da KPN. Essa equipe está envolvida em testes de segurança de aplicações e serviços da KPN para garantir que os dados dos nossos clientes estejam seguros contra acesso não autorizado, modificação e perda de dados.
A KPN opera a maior rede móvel dos Países Baixos. Um dos componentes da rede 4G que a KPN opera é o aplicativo Diameter Routing Agent chamado Oracle Diameter Signalling Router (DSR). O Diameter Routing Agent (DRA) é um elemento funcional em uma rede 3G ou 4G que fornece recursos de roteamento em tempo real para garantir que as mensagens sejam roteadas entre os elementos corretos em uma rede. O [3GPP] introduziu o DRA para lidar com o aumento do volume de tráfego de sinalização Diameter e a crescente complexidade das redes 4G LTE. Ele pode ser implantado como um roteador central que roteia o tráfego entre elementos Diameter na rede doméstica, ou como um roteador gateway que roteia o tráfego entre elementos Diameter na rede doméstica e de roaming. O 3GPP especifica o uso do protocolo Diameter para várias interfaces, incluindo uma (S6a) que é usada para comunicação MME-HSS, bem como para roaming.
A imagem abaixo mostra uma implantação típica de DRA em um ambiente LTE. Todas as interfaces entre os elementos são interfaces S6a.
O Oracle DSR é um cluster de máquinas rodando em CentOS Linux que executa a função DRA. Ele geralmente está conectado a diferentes MMEs e a um HSS na rede LTE doméstica, mas também pode estar conectado a parceiros de roaming através da rede IPX.
Usando a plataforma [Codenomicon] DEFENSICS, a equipe REDteam da KPN descobriu duas vulnerabilidades principais no aplicativo Oracle DSR versão 5.0:
A primeira vulnerabilidade permite que um atacante remoto não autenticado conectado à rede IPX comprometa completamente o DRA e seus componentes. Quando um atacante obtém controle total sobre o sistema DRA, ele pode monitorar todo o tráfego roteado através do DRA e possivelmente se infiltrar ainda mais na rede central da operadora de telecomunicações.
A Oracle levou as vulnerabilidades reportadas a sério, e a equipe REDteam da KPN trabalhou em estreita colaboração com a Oracle para resolver esses problemas, o que também foi declarado no aviso aos clientes:
"Testes de segurança recentes identificaram duas vulnerabilidades de segurança em versões do produto Oracle Diameter Signaling Router. Para proteger sua rede contra possíveis explorações dessas vulnerabilidades, a Oracle recomenda fortemente que você aplique as ações descritas neste documento sem demora. A Oracle reconhece Frank Cozijnsen, Ethical Hacker, KPN CISO REDteam pela descoberta da vulnerabilidade Diameter Stack descrita abaixo. Um agradecimento especial é estendido à KPN pelo seu apoio durante a fase de análise da Oracle. Nota: essas descobertas serão divulgadas publicamente no próximo CPU da Oracle, programado para 20 de janeiro de 2015."
Os problemas encontrados representam uma ameaça séria para as operadoras de telecomunicações que usam o DSR da Oracle e podem ser explorados por qualquer atacante com acesso a uma conexão IPX.
A equipe REDteam da KPN testa produtos e serviços antes de serem implantados em redes de produção. Como parte de um projeto de atualização, o Oracle DSR versão 5.0 foi testado sob uma perspectiva de segurança pela equipe REDteam da KPN. O teste de segurança incluiu fuzzing da implementação DIAMETER do Oracle DSR usando o [Codenomicon Diameter Server test Suite]. A mensagem Capabilities Exchange Request (CER), usada para verificar as capacidades DIAMETER do servidor receptor, foi usada como alvo inicial de fuzzing. Essa mensagem foi escolhida porque não é encaminhada para outros sistemas, como o HSS, mas é tratada pelo próprio DSR. Durante o fuzzing, várias falhas do processo "dsr" foram notadas nas blades Message Processor (MP) do DSR.
Usando o GDB com o plugin [PEDA], a falha foi analisada e, eventualmente, um exploit remoto foi escrito. A falha foi causada por uma escrita fora dos limites além do final do buffer localizado na stack. A escrita fora dos limites corrompeu a stack com dados controlados pelo usuário. Além disso, o ponteiro de retorno salvo, que é o endereço para onde o programa retorna após retornar de uma função, foi sobrescrito. Quando esse ponteiro de retorno pode ser controlado pelo atacante, isso pode levar à execução arbitrária de código.
A principal razão para escrever este blog é explicar como a equipe REDteam da KPN conseguiu passar pelas proteções ASLR e NX implementadas e conseguiu criar um exploit funcional de execução remota de código. Normalmente, os mecanismos de proteção ASLR e NX não são um grande obstáculo para atacantes, mas o DSR roda em CentOS de 64 bits. Não há muita documentação prática sobre Return Oriented Programming (ROP) em sistemas Linux de 64 bits protegidos por ASLR.
Durante a depuração, foi notado que a biblioteca libc estava sempre mapeada no mesmo endereço no processo dsr, e o endereço não mudava após uma reinicialização. Outras bibliotecas eram mapeadas em endereços de memória aleatórios no processo dsr. Saber o endereço de memória da libc permite usar a libc como fonte para os gadgets ROP. Outra opção é usar o próprio binário dsr como fonte para gadgets ROP, mas a quantidade de gadgets úteis nesse arquivo é limitada.
Para contornar a proteção NX, a função mprotect() pode ser usada para tornar a stack executável e poder executar nosso shellcode.
A função mprotect() precisa dos seguintes valores nos registradores correspondentes:
Se todos esses registradores estiverem definidos, mprotect() pode ser chamado no offset 0xe54b0 na versão alvo da biblioteca libc.
A parte seguinte do documento pressupõe conhecimento sobre ROP e como ele funciona. Há um ótimo exemplo de criação de uma cadeia ROP em um sistema Linux de 32 bits em [shell-storm.org]. Devido ao ASLR "parcial", a localização da própria stack não era previsível. Gadgets ROP foram usados para armazenar o valor do ponteiro de stack (%RSP) no registrador %RSI.
O registrador %RDI deve conter o offset de memória da região de memória que precisa ser tornada executável.
