Ataques ao TomCat
Na nossa actualidade, os ataques informáticos andam sempre na ordem do dia e dificilmente existe um dia em que não sejam descobertas novas vulnerabilidades.
As plataformas web permanecem o vector preferencial dos cibercriminosos por serem de fácil acesso, e muitas das vezes sem as devidas actualizações e protecções.
Na Synetic tenho a missão de sensibilizar e aperfeiçoar as nossas técnicas em matérias de cibersegurança, testar e demonstrar diversas vulnerabilidades que vão surgindo para compreender o seu funcionamento e aconselhar contra-medidas de forma a minimizar o risco de uma organização ser comprometida.
Hoje pretendemos ver uma vulnerabilidade que tem pouco mais de um ano, ou seja dar uma vista de olhos sobre o CVE:2019-0232, que se trata de uma falha que afecta as versões do tomcat até à 9.0.17. Embora divulgada a 15 de Abril de 2019, ainda permanece com um grau de impacto de 8.1 (na escala de CVSS 2.0).
Então vamos lá! Será assim tão grave ou descabido rever algo que já tem um ano e que sabemos já ter um fix? Com uma pesquisa pelo Shodan e outras fontes de Open Source Intelligence, ficariam admirados com a quantidade de servidores que ainda usam versões do tomcat desatualizadas.
Esta falha especifica assegura que o Tomcat quando está instalado em sistemas Windows com a funcionalidade “enableCmdLineArguments” ativo, é possível explorar um bug na maneira como o JRE (Java Runtime Environment) passa os argumentos para a plataforma Windows.
Se é apenas quando esta funcionalidade está ativa, porque nos devíamos de preocupar? Porque muitos administradores de sistemas usam esta funcionalidade para ajudar nas suas tarefas de manutenção servlets e outras funcionalidades do servidor.
Mãos à obra, como é que a falha ocorre?
Ora vamos assumir que um servidor tem o “enableCmdLineArguments” ativo, e que a servlet cgi está ativa.
Para a execução de comando, o contexto (em contexto.xml) tem de ter privilégios de execução.
Como as manutenções nestes servidores são normalmente executados a partir de ficheiros de batch, podemos verificar se o nosso ficheiro de testes executa corretamente.
E aparentemente no browser, surge exatamente o que se pretendia.
O problema grave é que de qualquer parte da rede é possível obter o mesmo a partir da nossa máquina atacante, observamos que conseguimos o mesmo resultado.
A partir deste momento, este servidor está comprometido, mas iremos um pouco mais além na parte mais divertida quando passarmos um argumento no URL.
Iremos desenvolver um script em Python para nos auxiliar no processo
Neste script definimos os parâmetros iniciais para que não tenhamos de escrever sempre o caminho completo de onde se encontra o servidor (pelo IP) e o caminho da servlet do tomcat, ou seja “/cgi/test.bat”, bem como o sitio de destino onde todas as operações irão executar!
Com este código o ponto de “sys.argv[1]” permite-nos passar comandos, e serão esses os próximos passos, dado ser a única parte da nossa URL que será dinâmica e sofrerá alterações.
Para comprovarmos que conseguimos visualizar o output de funcionalidades por linha de comandos, iremos executar o cmd.exe do computador remoto recorrendo ao nosso código python acrescido dos argumentos que se vêm no print abaixo e visualizar as pastas do administrador de sistema.
Para este processo será necessário estarmos à vontade com comandos Windows para saber exactamente o que executar.
Ora por simples manipulação da URL, obtemos uma listagem da directoria do Administrador de sistema.
Como conseguimos chegar até aqui, podemos criar uma pasta no servidor da vitima.
Desenvolvemos um malware que irá gerar uma reverse Shell da meterpreter e colocámos o executável numa página web e usando a linha de comandos da vitima, fizemos com que o servidor descarregasse esse malware para a pasta que acabámos de criar:
O envio do malware é feito usando o BITSADMIN versão 3.0. Muitas outras formas de transferência poderiam ser usadas, mas decidiu-se usar esta por ser algo que já se encontra em desuso e pretendiamos mostrar que ainda funciona.
Uma vez com o nosso executável na máquina vitima, podemos simplesmente executá-lo enquanto o nosso Kali aguarda uma ligação.
Apesar de parecer que não acontece nada, o Metasploit já capturou esta ligação e deu-nos acesso total à maquina.
A partir deste momento, sem intervenção do utilizador no lado da vitima, é possível entrar no sistema e compromete-lo.
É do nosso conhecimento que muitas organizações não actualizam as suas plataforma com receio de que algo “deixe de funcionar”, o que pode levar a quebras como as deste exemplo, por isso a Synetic recomenda fortemente a actualizarem os sistemas de forma recorrente e que não alterem configurações de forma a terem os servidores com fracas configurações de segurança.
A facilidade de administração de um serviço nunca deverá ser usada como desculpa para aumentar o ciber-risco desnecessariamente.