Minio Information Disclosure in Cluster Deployment

Em implantações MinIO distribuídas (cluster), um endpoint interno de bootstrap devolve todas as variáveis de ambiente prefixadas com MINIO_ — incluindo MINIO_SECRET_KEY e MINIO_ROOT_PASSWORD — sem exigir autenticação. Qualquer atacante com acesso de rede a esse endpoint obtém as credenciais root do storage, o que na prática equivale a comprometimento total dos dados armazenados. O CVSS 7.5 (apenas C:H) já reflete bem o impacto: é um roubo de credencial limpo, sem necessidade de interação do usuário ou privilégio prévio, mas restrito a deployments em cluster e, na prática, a cenários onde esse endpoint interno acabou exposto para fora da rede de internode.

A falha está em minio/cmd/bootstrap-peer-server.go, no handler VerifyHandler do servidor REST de bootstrap (a API interna que os nós de um cluster MinIO usam para se verificarem entre si na inicialização). O handler chama getServerSystemCfg(), que executa env.List("MINIO_") para coletar todas as variáveis de ambiente com esse prefixo, monta um mapa envValues excluindo apenas as chaves presentes em uma lista de exclusão (skipEnvs), e serializa isso como JSON na resposta HTTP dentro da struct ServerSystemConfig (campo MinioEnv), junto com os endpoints do cluster.

O problema é duplo: primeiro, o endpoint de verificação de bootstrap não validava adequadamente o token interno de comunicação entre nós antes de responder — não havia checagem de autenticação suficiente para impedir que uma requisição externa recebesse a configuração completa. Segundo, a lista de exclusão (skipEnvs) não cobria as variáveis sensíveis por padrão, então MINIO_SECRET_KEY e MINIO_ROOT_PASSWORD (e potencialmente outras credenciais configuradas via env) iam para a resposta em texto claro. O CISA KEV classifica isso como CWE-200 (exposição de informação sensível a atores não autorizados); a advisory do fornecedor não atribui CWE.

O atacante não controla nenhum parâmetro de entrada complexo — o vetor é simplesmente conseguir fazer uma requisição HTTP ao endpoint de bootstrap do MinIO. O que ele ganha é a leitura integral do estado de configuração do nó.

O pré-requisito real é acesso de rede ao endpoint REST de bootstrap de um nó MinIO operando em modo distribuído/cluster (deployments standalone de nó único não são afetados, segundo a descrição do fornecedor, que fala explicitamente em 'cluster deployment' e 'distributed deployment'). Esse endpoint foi projetado para tráfego internode — ou seja, comunicação entre os próprios servidores do cluster — e não deveria estar acessível pela internet. A exploração massiva relatada ocorreu justamente em instâncias onde essa porta/endpoint interno ficou exposto publicamente, geralmente por erro de configuração de rede ou containers publicados sem segmentação adequada.

Não há necessidade de autenticação, interação do usuário ou conhecimento prévio de credenciais — é uma requisição direta ao endpoint vulnerável, que responde com o JSON contendo as variáveis de ambiente. A partir daí, o atacante tem MINIO_ROOT_PASSWORD/MINIO_SECRET_KEY e pode se autenticar normalmente na API S3 do MinIO com privilégio de administrador, lendo, alterando ou apagando qualquer objeto armazenado.

Há exploração ativa confirmada: a CVE está no catálogo KEV da CISA (adicionada em 21/04/2023, prazo de correção 12/05/2023) e pesquisadores da GreyNoise relataram, ainda em março de 2023, exploração em tempo real na internet, inclusive um caso em que código do SDK de browser do ChatGPT usava uma versão vulnerável do MinIO. Existem módulo Metasploit, template Nuclei e PoC pública, o que baixou bastante a barreira técnica para exploração automatizada em massa via scanning.

A correção do fornecedor é migrar para RELEASE.2023-03-20T20-16-18Z ou posterior, que corrige o handler de bootstrap para validar tokens internode antes de responder (commit 3b5dbf9..., PR #16853, 'allow bootstrapping to validate internode tokens'). Essa mesma release também trouxe correções para duas outras falhas de escalonamento de privilégio (Linux/macOS e Windows), então a atualização resolve mais de um problema de uma vez.

O próprio advisory do fornecedor (GHSA-6xvq-wj2x-3h3q) afirma explicitamente que 'não há workarounds conhecidos' — não existe flag de configuração ou paliativo oficial. O controle compensatório real, na ausência de atualização imediata, é de rede: garantir que a porta/API interna de bootstrap do cluster MinIO não esteja acessível fora da malha de comunicação entre os próprios nós (bloqueio por firewall/security group, segmentação, sem exposição para a internet). Isso reduz a superfície de ataque mas não corrige a vulnerabilidade em si — qualquer host com acesso à rede interna do cluster continua podendo explorar a falha antes do patch.

Rotacionar MINIO_SECRET_KEY/MINIO_ROOT_PASSWORD após a atualização é recomendável se houver suspeita de exposição anterior, já que a credencial pode já ter sido capturada antes do patch ser aplicado.

A GreyNoise mantém uma tag dedicada ('minio-information-disclosure-attempt') que rastreia IPs escaneando e explorando ativamente essa falha na internet — consultar esse feed indica se o endereço de origem de uma tentativa já foi visto fazendo scanning massivo desse endpoint. Em logs próprios, o sinal a procurar é requisições HTTP ao endpoint REST de bootstrap do MinIO (rota interna de verificação/bootstrap entre nós) originadas de IPs fora da rede interna do cluster — qualquer acesso a esse endpoint que não venha de outro nó legítimo do próprio cluster é suspeito. Não há um padrão de payload distintivo a procurar, já que a exploração é uma simples requisição GET/POST sem corpo malicioso; a anomalia está inteiramente na origem e no destino da conexão, não no conteúdo da requisição.