Encontrando uma Senha de Root do Banco de Dados Deixada no Histórico do Shell

Shells interativos mantêm um registro do que foi digitado. O Bash grava cada comando em ~/.bash_history, e o builtin history imprime essa lista. O recurso existe para evitar que você digite os comandos de novo, mas tem um efeito colateral: qualquer coisa passada como argumento, incluindo uma senha, é registrada literalmente e permanece muito depois de o comando terminar de rodar.

O culpado clássico é o cliente MySQL. Escrever mysql -uroot -pR00t!Db_2026 shop entrega a senha ao programa na linha de comando. Não há espaço entre -p e o valor, então o token inteiro é a credencial. Essa linha agora está no arquivo de histórico, legível por qualquer um que depois opere como esse usuário. Algumas outras ferramentas têm a mesma falha, e é por isso que muitas delas agora avisam que fornecer uma senha na linha de comando é inseguro.

Do ponto de vista de um atacante, essa é uma das vitórias mais baratas disponíveis. Você não precisa ler um arquivo de configuração, escalar privilégios, nem quebrar nenhuma criptografia, basta rodar history e ler. Como sudo é um beco sem saída nesse cenário, o histórico é exatamente o tipo de artefato de baixo esforço e alto valor que um operador de verdade verifica primeiro depois de conseguir acesso a um host.

• Procurar a senha em arquivos. Ela nunca foi escrita em um arquivo aqui, o valor só apareceu em uma linha de comando, então history é a ferramenta certa, não cat.
• Recorrer ao sudo. sudo é um beco sem saída nesse cenário; a vitória está em ler o que já é legível, não em escalar privilégios.
• Interpretar errado onde a senha começa. O valor vem logo após -p sem espaço, R00t!Db_2026, e não o nome do banco shop que vem depois.
• Assumir que o histórico foi limpo. Operadores raramente limpam o histórico; a linha geralmente sobrevive até alguém apagá-la de propósito.

A causa raiz é colocar um segredo em uma linha de comando, ponto final. Padrões mais seguros mantêm a senha fora tanto da lista de processos quanto do arquivo de histórico:

• Use mysql -uroot -p sem valor para que o cliente peça a senha interativamente - ela nunca é digitada como argumento.
• Armazene as credenciais em um ~/.my.cnf protegido com chmod 600, ou use mysql_config_editor para mantê-las em um caminho de login criptografado.
• Prefira autenticação por socket ou por token, para que uma senha estática não seja necessária em consultas de rotina.
• Limpe periodicamente o histórico sensível e defina HISTCONTROL=ignorespace para manter comandos com segredos fora do arquivo de histórico.

Se uma senha apareceu no histórico ou na lista de processos, considere-a vazada e troque-a - limpar o histórico depois não desfaz uma leitura que já pode ter acontecido.