0xEtern4lW0lf
Hack The BoxEasyLinux

Pilgrimage

6 min de leitura
#ImageMagick#CVE-2022-44268#CVE-2022-4510#binwalk#Git#SSH#Python#LFI

Introdução

https://app.hackthebox.com/machines/Pilgrimage Pilgrimage é uma máquina Linux da Hack The Box, classificada oficialmente como dificuldade Easy. O alvo utilizado neste writeup foi o IP 10.10.11.219. A máquina gira em torno de uma aplicação web que reduz o tamanho de imagens usando ImageMagick, que acaba sendo o vetor de acesso inicial, e evolui até uma escalada de privilégios explorando uma versão desatualizada e vulnerável do binwalk. IP: 10.10.11.219

Escaneamento

O primeiro passo foi escanear as portas abertas do alvo com o nmap: primeiro um scan rápido em todas as portas TCP, e em seguida um scan detalhado (-A) apenas nas portas encontradas.

ports=$(sudo nmap --open -p- -Pn --min-rate=1000 -T4 10.10.11.219 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) && sudo nmap -Pn -A -p $ports 10.10.11.219

O nmap identificou duas portas abertas: 22/tcp (SSH) e 80/tcp (HTTP). Na porta 80, também foi identificado um repositório .git exposto. Foi adicionado o domínio pilgrimage.htb ao arquivo /etc/hosts para acessar a aplicação corretamente.

Enumeração

Porta 80 (HTTP)

Aplicação Web Na página principal encontramos três abas: Home, Login e Register. Na aba Home há um campo de upload de imagem, que será o alvo da exploração mais adiante. http://pilgrimage.htb/ Foi feito o registro de um usuário qualquer e, em seguida, acessamos a página de dashboard, para onde aparentemente vão as imagens enviadas pelo usuário. No dashboard é possível ver o link direto da imagem enviada, o que já indica que as imagens ficam acessíveis publicamente após o processamento.

Repositório Git

Como identificado pelo nmap, a aplicação expõe o diretório .git, o que permite reconstruir o código-fonte da aplicação com uma ferramenta como o git-dumper.

git-dumper http://pilgrimage.htb/.git/ git

Com isso conseguimos os arquivos-fonte da aplicação (index.php, dashboard.php, login.php, register.php, entre outros), incluindo um binário magick (ImageMagick) usado pela aplicação para processar as imagens enviadas. index.php Ao analisar o código, vimos que no upload da imagem é verificado o campo MIME (aceitando apenas png e jpeg). Em seguida, a aplicação executa o binário magick para redimensionar a imagem pela metade (-resize 50%) e salva o resultado com um novo nome gerado por uniqid() no diretório /var/www/pilgrimage.htb/shrunk/. dashboard.php Há uma função que consulta um banco de dados SQLite, localizado em /var/db/pilgrimage, para montar a listagem de imagens exibidas na página. ImageMagick

Exploração

Leitura Arbitrária de Arquivos — ImageMagick (CVE-2022-44268)

A aplicação utiliza o ImageMagick para redimensionar as imagens enviadas pelos usuários. A versão em uso é vulnerável ao CVE-2022-44268, uma falha de leitura arbitrária de arquivos: basta embutir, em um chunk tEXt de um PNG, a palavra-chave profile apontando para o caminho de um arquivo do sistema. Quando o ImageMagick processa essa imagem (no caso, durante o redimensionamento feito pela aplicação), ele interpreta a string como um caminho de arquivo, lê o conteúdo e grava seu hash em hexadecimal dentro dos metadados (Raw profile type) do PNG de saída — que depois pode ser baixado e decodificado. Referência: https://www.metabaseq.com/imagemagick-zero-days/ Para gerar a imagem maliciosa foi usado o script generate.py, uma PoC pública para o CVE-2022-44268:

python3 generate.py -f "/etc/passwd" -o lfi.png

Em seguida, a imagem gerada foi enviada através do formulário de upload da aplicação e baixada de volta usando o link retornado pelo dashboard.

wget http://pilgrimage.htb/shrunk/655fa081e3693.png

Com o identify, do próprio ImageMagick, foi possível visualizar os metadados brutos (Raw profile type) embutidos na imagem baixada, que contêm o conteúdo do arquivo lido no alvo:

identify -verbose 655fa081e3693.png

Esse conteúdo está em hexadecimal. Bastou colar no CyberChef e aplicar a receita “From Hex” para decodificar e obter o conteúdo real do arquivo lido.

Obtendo Acesso via SSH

Aplicando a técnica para ler o arquivo /etc/passwd, identificamos a existência do usuário emily no sistema. Repetindo a mesma técnica de leitura arbitrária de arquivos, desta vez apontando para /var/db/pilgrimage — o banco SQLite usado pela aplicação (visto antes em dashboard.php) — conseguimos extrair o arquivo e, dentro da tabela de usuários, a senha em texto claro da emily. Com a credencial em mãos, foi possível autenticar via SSH:

ssh emily@10.10.11.219
abigchonkyboi123

Pós-exploração

Elevação de Privilégios

Já com acesso via SSH como emily, ao listar os processos em execução encontramos um script sendo executado periodicamente pelo usuário root. Analisando o script (malwarescan.sh), vimos que ele usa inotifywait para monitorar o diretório /var/www/pilgrimage.htb/shrunk/ em busca de arquivos recém-criados e os analisa em busca de conteúdo malicioso embutido, utilizando a ferramenta binwalk. Qualquer arquivo com assinatura suspeita (ex.: um executável embutido) é removido automaticamente. O binwalk instalado está na versão 2.3.2, vulnerável ao CVE-2022-4510: uma falha de path traversal no módulo de extração de sistemas de arquivos PFS que permite gravar arquivos fora do diretório de extração esperado. Ao construir um arquivo PFS malicioso, é possível fazer o binwalk, quando executado em modo de extração (-e), escrever um plugin malicioso em .config/binwalk/plugins, que é automaticamente carregado e executado pelo próprio binwalk — resultando em execução arbitrária de código como o usuário que roda a ferramenta (nesse caso, root). Foi utilizado um exploit público para o CVE-2022-4510, que manipula uma imagem existente injetando nela o payload malicioso do PFS. Quando o script do root processa esse arquivo com o binwalk vulnerável, o plugin malicioso é gravado e executado, entregando um shell reverso como root. Em seguida, deixamos um listener aberto na porta 443 para receber a conexão reversa e enviamos, via scp, a imagem manipulada para o diretório monitorado pelo script no alvo: /var/www/pilgrimage.htb/shrunk/.

scp binwalk_exploit.png emily@10.10.11.219:/var/www/pilgrimage.htb/shrunk/
abigchonkyboi123

Assim que o inotifywait detectou a criação do arquivo e o script rodou o binwalk vulnerável sobre ele, o plugin malicioso foi executado como root e o shell reverso foi recebido, completando a escalada de privilégios.

Anexos

Para automatizar todo o fluxo de exploração descrito acima — leitura arbitrária de arquivo via CVE-2022-44268 no ImageMagick, extração da credencial da emily a partir do banco SQLite e escalada de privilégios via CVE-2022-4510 no binwalk — foi escrito um script em Python, pilgrimage-getshell.py, anexado a esta página. Ferramentas utilizadas ao longo do processo:

  • nmap — escaneamento de portas e serviços
  • git-dumper — reconstrução do repositório .git exposto
  • generate.py (PoC do CVE-2022-44268) — geração das imagens PNG maliciosas para leitura arbitrária de arquivos
  • identify (ImageMagick) e CyberChef — extração e decodificação dos dados lidos
  • Exploit público do CVE-2022-4510 — geração da imagem PFS maliciosa para RCE via binwalk

Mitigação

  • Atualizar o ImageMagick para uma versão corrigida (posterior ao patch do CVE-2022-44268), que trata corretamente o processamento do atributo profile em chunks tEXt de PNG e evita a leitura de arquivos arbitrários do sistema.
  • Atualizar o binwalk para uma versão igual ou superior à que corrige o CVE-2022-4510, que resolve a falta de validação de path traversal na extração de sistemas de arquivos PFS.
  • **Nunca expor o diretório **.git em produção; bloquear o acesso via configuração do servidor web (nginx/Apache) ou removê-lo do diretório publicado.
  • Não reutilizar senhas em texto claro no banco de dados da aplicação; armazenar apenas hashes fortes (bcrypt/argon2) e nunca a mesma senha usada para contas do sistema (SSH).
  • Executar ferramentas de análise de arquivos (como o binwalk) em ambiente isolado/sandbox, sem privilégios de root, evitando que uma falha na ferramenta resulte em comprometimento total do host.
  • Restringir o diretório de upload para que arquivos processados não sejam automaticamente confiáveis, validando conteúdo real da imagem (e não apenas o MIME type) antes do processamento.