A Oupost24 realizou um teste de invasão para traçar o caminho que é feito num ataque de API e, com as informações obtidas, se tornar ainda mais capaz de prevenir esse tipo de ataque. Utilizando o que foi descoberto em ambos os estágios do teste, eles são capazes de entender como a aplicação funciona, tanto no front-end quanto no back-end. Juntando várias técnicas e ferramentas, a execução do código foi alcançada em um dos hosts mais vitais na infraestrutura da aplicação do cliente submetido ao teste, indo de 0 a 100, mesmo que o site apresentasse uma boa segurança no geral.
Teste de aplicação
De modo geral, a aplicação havia sido bem-feita. Não foram encontrados riscos altos de vulnerabilidade enquanto ela estava sendo acessada. Entretanto, foi identificado que a aplicação web executava uma variedade de informações relacionadas a transferência de dinheiro de banco para banco, usuário para usuário e usuário para aplicação. A transferência e troca de dinheiro era realizada por uma API; porém, o tipo de API e as informações sobre ela eram difíceis de descobrir apenas pela utilização web. Foi realizado um “fuzzing” contra a API para tentar quebrar a lógica da aplicação, mas isso não deu nenhum resultado, requerendo que os experts da Outpost24 cavassem mais fundo.
Enumerando um pouco o ataque da API
Movendo-se para a infraestrutura back-end, os especialistas começaram pela enumeração dos hosts que estavam no escopo. Como uma conexão interna foi usada, por meio da VPN, essa enumeração descobriu alguns serviços padrão que se pode esperar da infraestrutura interna de uma aplicação web, como: SSH, RPC, MySQL, HTTP, Load Balancers, e por último, Java RMI, que chamou a atenção.
Testar contra esses serviços mais comuns geralmente só entregam descobertas gerais, nada muito especial. Mas, as aplicações HTTP dentro do ambiente interno, revelou algumas informações valiosas que acabariam por funcionar como um trampolim que os apontavam para o serviço que precisavam atacar.
Navegando um pouco nos serviços HTTP com a infraestrutura interna no escopo, eles tiveram contato com a informação relacionada ao Sping Boot Actuator API. Cada href levaria para uma landing page acessível subsequente. Ao rastrear várias aplicações, foram apresentados links e descrições de dados que poderiam ser recuperados nos aplicativos HTTP internos. Clicar nesses links dentro da aplicação, eventualmente levaria a descoberta de informações relacionadas a API de pagamento discutida anteriormente.
Vale ressaltar que as aplicações HTTP rodando na infraestrutura interna estavam sendo executadas nos mesmos hosts que os conectores Java RMI. Usando a informação obtida do acesso a aplicação web, realizando coleta de informações dentro da rede interna, e enumerando as aplicações HTTP em dois hosts individuais, a Outpost24 foi capaz de determinar qual desses hosts eram responsáveis pelas chamadas e funções da API de pagamento. Eles foram capazes de descobrir que a aplicação de pagamento era a Pay Card Deposit Pay360.
A Pay360 é uma solução de pagamento integrada que aplicações web podem utilizar para enviar e receber fundos. Agora, o problema era: como quebrar o serviço para permitir o controle do host, ou, no mínimo, corromper o fluxo da aplicação para realizar ações maliciosas?
A melhor parte
Como mencionado, o Java RMI estava rodando em dois hosts que eram assumidamente responsáveis pelos pagamentos, feitos na aplicação web. Java Remote Method Invocation (RMI), é um mecanismo que permite um serviço residente em um host, como acessar ou invocar um objeto rodando em outro host. Ele é usado para construir aplicações distribuídas que fornecem comunicação remota entre os programas Java.
Foi descoberto que nenhum dos hosts requeiram algum tipo de autenticação para interagir com o Java RMI, permitindo a enumeração para ser executado contra os conectores, para obter informações relativas ao console JMX.
Já os Managed Beans (MBeans), são objetivos Java gerenciados que seguem o padrão de design estabelecidos na especificação da API JMX e, depois de ganhar mais conhecimento sobre o Java RMI e dos MBeans, uma pesquisa futura os guiou para uma ferramenta de ataque chamada Beanshooter, que ajuda a identificar vulnerabilidades comuns nos endpoints JMX. Utilizando-se dele, foi confirmado a falta de autenticação nos endpoints Java RMI, além de enumerar o MBeans com um registro JMX.
Depois disso, foi possível realizar vários ataques de desserialização, outras tentativas ysoserial foram efetuadas, com algumas resultando em erros de rastreamento, e outras em exceções ClassNotFound, sendo lançadas pelo serviço Java RMI.
O vetor de ataque final foi uma tentativa de carregar um arquivo .jar malicioso no registro MBean. Isso permitiria que os especialistas pudessem performar funções maliciosas no servidor ao utilizar um MBean. Inicialmente, eles tentaram fazer o upload direto e ativar o MBean malicioso por meio do conector Java RMI, porém, não foi possível. Ao invés disso, eles tentaram hospedar o MBean em servidor HTTP de teste dentro da rede interna e usar desconfigurações sem autenticação, para que a JMX API chamasse o servidor de teste e carregasse o .jar malicioso no registro MBean, método conhecido também como Carregamento Remoto. Uma vez feito isso, o MBean malicioso foi implantado, permitindo que eles pudessem rodar comandos maliciosos efetivamente por meio dele no host comprometido.
Neste ponto da avaliação, eles conseguiram trabalhar a Execução de Forma Remota como conceito de prova contra ambos os servidores de APIs de pagamento. Devido ao tempo, não foram realizadas nenhuma outra tentativa de locomoção lateral ou escalonamento de privilégios, mas foi provada que uma aplicação com milhares de usuários possuía uma falha em sua infraestrutura interna, que poderia permitir execução de códigos remotamente contra ambos os servidores que rodavam funções das APIs de pagamento.
Remediação de ataque
Em todos os casos de “pentest” efetuados pela Outpost24, eles também oferecem toda a informação obtida durante a avaliação, para que se possa trabalhar as falhas e garantir uma segurança ainda mais avançada. Uma configuração apropriada também é crucial para garantir a segurança das APIs de endpoints, como, por exemplo:
- Rodar serviços RMI sobre SSL/TLS para evitar ataques Man-in-the-Middle;
- Exigir autenticação para ambos os servidores e clientes;
- Rodar um gerenciador de segurança usando RMI;
- Garantir que o valor da propriedade do java.rmi.server.useCodebaseOnly seja verdadeiro. Estabelecer essa propriedade como falsa permite o carregamento de código remotamente, o que aumenta as chances de um risco de segurança ao sistema.
Pequenas mudanças de configuração podem fazer uma mudança significativa em garantir uma segurança geral em diversos sistemas, ainda assim, testes de penetração sempre podem identificar alguma coisa que passou despercebida.
Conte com a Outpost24 e M3Corp para garantir ainda mais segurança para os seus clientes!
Fale conosco e saiba mais sobre como funcionam os testes.
Fonte: https://outpost24.com/blog/Penetration-testing-to-prevent-API-attack
Posts recentes