Nem 1.449 patches da Oracle impediriam ataque identificado pela Huntress

Um ataque investigado pela Huntress mostrou como hackers podem explorar funcionalidades legítimas de bancos de dados Oracle para executar código e roubar credenciais, mesmo em ambientes que estivessem com todas as atualizações de segurança disponíveis instaladas.

O caso chama atenção porque ocorreu no mesmo período em que a Oracle publicou uma atualização com 1.449 patches de segurança. Segundo Craig Savage, líder de cibersegurança da Spinnaker Support, nenhuma dessas correções teria impedido o ataque descrito pela Huntress, já que a invasão não dependia de uma vulnerabilidade corrigida pela fabricante.

A atividade foi identificada em julho, após a Huntress receber um alerta relacionado ao roubo de credenciais. O acesso inicial ocorreu por meio de uma vulnerabilidade de SQL Injection em uma aplicação web pública de uma organização não identificada.

Depois de obter acesso, os invasores adotaram uma técnica menos comum. Eles implantaram um toolkit de pós-exploração chamado khunt por meio de código Java carregado diretamente dentro do banco de dados Oracle.

A técnica é possível porque o Oracle Database possui uma Java Virtual Machine (JVM) integrada e permite armazenar código-fonte Java como um objeto do banco. No incidente, os invasores enviaram comandos CREATE JAVA SOURCE a partir de um servidor Tomcat, utilizando a conexão existente com o banco de dados.

O código malicioso foi então compilado diretamente dentro do Oracle Database e armazenado como um objeto de esquema. Segundo a Huntress, abordagens semelhantes já haviam sido descritas anteriormente, inclusive por meio de uma técnica conhecida como oraexec, mas seu uso documentado em ataques reais permanece incomum.

Savage destacou que a capacidade de criar e executar programas Java dentro do banco é uma funcionalidade legítima da plataforma Oracle, mas não deveria estar disponível para um servidor web em um ambiente de produção.

Segundo o especialista, a execução de Java deveria ser restrita ao usuário DBA, enquanto a capacidade de compilar código deveria permanecer desabilitada em servidores de produção e ser habilitada apenas durante períodos controlados de desenvolvimento ou manutenção.

Nesse cenário, mesmo que os invasores conseguissem enviar o código Java ao banco, o ambiente não estaria configurado para compilá-lo. Savage classificou o ambiente atacado como mal configurado e inadequadamente protegido, ressaltando que o incidente não representa uma violação da infraestrutura da Oracle.

O ataque também indica uma mudança relevante nas técnicas adotadas por grupos de cibercrime. Em vez de depender exclusivamente da exploração de vulnerabilidades de software, os invasores estão aprendendo como produtos corporativos funcionam e identificando funcionalidades legítimas que podem ser abusadas quando permanecem habilitadas ou configuradas de forma insegura.

O caso mostra que a aplicação de patches continua sendo uma medida essencial, mas não elimina riscos relacionados à configuração e ao controle de privilégios. No incidente investigado pela Huntress, restringir a execução e compilação de código Java no banco poderia ter interrompido a cadeia de ataque.