Apenas algumas horas após a equipe do Drupal lançar as atualizações mais recentes para corrigir uma nova falha de execução remota de código em seu software de sistema de gerenciamento de conteúdo, os hackers já começaram a explorar a vulnerabilidade em estado natural.
Anunciada ontem, a vulnerabilidade recém-descoberta (CVE-2018-7602) afeta o núcleo do Drupal 7 e 8 e permite que atacantes remotos atinjam exatamente o mesmo que o anteriormente descoberto Drupalgeddon2 (CVE-2018-7600) – permissão completa dos sites afetados.
Embora a equipe do Drupal não tenha divulgado nenhum detalhe técnico sobre a vulnerabilidade para impedir a exploração imediata, dois hackers individuais revelaram alguns detalhes, além de uma exploração de prova de conceito apenas algumas horas após o lançamento do patch.
Se você leu todas as notícias mais recentes sobre o The Hacker News, você deve estar ciente de como o lançamento do Drupalgeddon2 PoC explorou muita atenção, o que eventualmente permitiu que os invasores sequestrassem sites e disseminassem minas de criptomoeda, backdoors e outros malwares.
Como esperado, a equipe do Drupal alertou que a nova falha de execução remota de código, vamos referir-se ao Drupalgeddon3, agora está sendo ativamente explorada na natureza, novamente deixando milhões de sites vulneráveis a hackers.
Neste artigo, eu informei sobre o que é essa nova falha e como os invasores a exploram para invadir sites que usam versões não corrigidas do Drupal.
O processo de exploração da falha do Drupalgeddon3 é um pouco semelhante ao Drupalgeddon2, exceto que requer uma carga um pouco diferente para enganar sites vulneráveis e executar a carga maliciosa no servidor da vítima.
O Drupalgeddon3 reside devido à validação de entrada incorreta na API Form, também conhecida como “arrays renderizáveis”, que renderiza metadados para exibir a estrutura da maioria dos elementos da interface do usuário (interface do usuário) no Drupal. Esses arrays renderizáveis são uma estrutura de valor-chave na qual as chaves de propriedade começam com um sinal de hash (#).
Um usuário do Twitter com handle @_dreadlocked explica que a falha na Form API pode ser acionada por meio do parâmetro GET “destination” de uma URL que é carregada quando um usuário registrado inicia uma solicitação para excluir um nó; onde, um “nó” é qualquer parte do conteúdo individual, como uma página, artigo, tópico do fórum ou um post.
Como esse parâmetro de consulta GET “destination” também aceita outra URL (como um valor) com seus próprios parâmetros GET, cujos valores não foram higienizados, permitiu que um invasor autenticado induzisse os sites a executar o código.
O que eu entendi da exploração PoC lançada por outro usuário do Twitter, usando o handle @Blaklis_, é que os valores não-aprovados passam pela função stripDangerousValues () que filtra o caractere “#” e pode ser abusada codificando o caractere “#” no formulário de “% 2523”.
A função decodifica “% 2523” em “% 23”, que é a versão Unicode para “#” e será processada para executar código arbitrário no sistema, como um utilitário whoami.
No início, os desenvolvedores do Drupal estavam céticos quanto à possibilidade de ataques reais usando a vulnerabilidade do Drupalgeddon3, mas depois que surgiram os relatórios de ataques in-the-wild, o Drupal elevou o nível de perigo do problema para “Altamente crítico”.
Portanto, todos os administradores de sites do Drupal são altamente recomendados para atualizar seus sites para as versões mais recentes do software o mais rápido possível.
