Seguindo um Ponteiro de Config até um Arquivo de Ambiente para Vazar um Token de Admin
O desafio
Você tem um shell no app01 como usuário nginx. A config do app não guarda o token de admin diretamente - ela o lê de um arquivo de ambiente em algum lugar do disco. Siga a trilha da config até esse arquivo e envie o token de admin.
O que você vai aprender
- Reconhecer quando um arquivo de config referencia um segredo em vez de guardá-lo
- Localizar um EnvironmentFile do systemd e o arquivo env que ele carrega
- Ler um arquivo env para extrair uma credencial como ADMIN_TOKEN
- Usar grep em /etc para encontrar um segredo quando o caminho não é óbvio
- Aplicar a correção: carregar segredos de um vault ou secret store com escopo definido em runtime
Habilidades testadas
Pré-requisitos
- Familiaridade com comandos básicos de shell (ls, cat, grep)
- Saber ler um arquivo de config em Python e uma unidade de serviço systemd
Como funciona
Aplicações maduras tentam não fixar segredos diretamente no código-fonte (hardcode). Em vez disso, o código lê um segredo a partir do ambiente do processo, e outra coisa, uma unidade systemd, um env_file do Docker, ou um wrapper de shell, é responsável por colocar esse valor no ambiente na inicialização. Neste desafio, config.py chama os.environ.get('ADMIN_TOKEN') e ainda deixa uma pista: SECRET_ENV_PATH = '/etc/acme/secret.env'. O segredo é real, está a apenas um arquivo de distância.
Essa indireção melhora a higiene no controle de versão, o repositório nunca contém o token, mas não ajuda em nada quando um atacante já tem acesso de leitura ao host. O arquivo env continua no disco em texto puro, e a unidade de serviço declara exatamente onde: EnvironmentFile=/etc/acme/secret.env. Quem conseguir ler esse caminho lê o token. Um ponto de apoio como o usuário do serviço geralmente é suficiente, porque o arquivo precisa ser legível por esse mesmo usuário para o serviço iniciar.
A habilidade exercitada aqui é encadear um artefato ao próximo: uma config que indica um caminho, uma unidade de serviço que confirma o caminho, e por fim o arquivo env que guarda o valor. Quando o caminho não está explícito, um grep recursivo como grep -r ADMIN_TOKEN /etc vai direto à linha. O token é guardado em texto claro porque a aplicação precisa enviá-lo literalmente, então ler o arquivo é tudo que é preciso.
Erros comuns
- Parar no arquivo de config.
config.pynão contém o token, apenas indica o caminho. Quem faz grep só no diretório da aplicação perde o segredo por completo. - Ignorar a unidade de serviço. A linha
EnvironmentFile=da unidade systemd é o indicador mais forte de onde o segredo é carregado; pular/etc/systemdsignifica apostar no escuro. - Assumir que /etc está fora de alcance. O arquivo env precisa ser legível pelo usuário do serviço, então um shell de baixo privilégio como esse usuário geralmente consegue lê-lo.
- Buscar pela palavra-chave errada. Procurar por
passwordencontra a senha do banco de dados, não o token de admin, faça grep especificamente porADMIN_TOKEN.
Como se proteger
Mover um segredo do código-fonte para um arquivo env em disco é uma meia-medida; a correção duradoura mantém o valor totalmente fora do sistema de arquivos do host:
- Busque o token na inicialização a partir de um gerenciador de segredos, um serviço de vault ou o secrets store do seu provedor de nuvem, e mantenha-o apenas na memória do processo.
- Se um arquivo env for inevitável, restrinja-o com
chmod 600e um dono dedicado para que um usuário de serviço comprometido não consiga lê-lo. - Delimite o escopo e rotacione o token para que um único vazamento seja de curta duração e de raio limitado.
- Audite leituras de caminhos de segredos e alerte sobre acessos de usuários ou processos inesperados.
Trate qualquer token que já tenha tocado um arquivo legível em um host compartilhado como já queimado: rotacione e reemita, já que apagar o arquivo não desfaz uma leitura que já aconteceu.