Uma linha no sudoers pode entregar uma máquina inteira.

Least privilege não é dar uma permissão que parece pequena. É limitar o que aquela permissão realmente consegue fazer. E isso pode ser simples. Ou não.

Eu estava estudando sudoers, least privilege e alguns casos do GTFOBins quando resolvi montar um laboratório simples.

A ideia parecia completamente aceitável: um usuário precisa procurar arquivos no sistema, mas obviamente eu não quero dar acesso root completo pra ele. Ainda estou consciente, eu acho.

Então por que não liberar só o find? Afinal, é literalmente uma ferramenta para encontrar arquivos, e é útil pra caramba.

O que poderia dar errado?

Bom. É aí que começa o problema, rs.

Os exemplos são de um laboratório controlado e autorizado. O painel desta página é uma simulação: nenhum comando é executado no seu computador ou no servidor.

01 / A PERMISSÃO

Imagine só: é apenas o find.

Um usuário comum precisa executar find com privilégios elevados. Uma regra no /etc/sudoers poderia parecer assim:

usuario ALL=(root) NOPASSWD: /usr/bin/find

Olhando rápido, parece bem diferente de algo como:

usuario ALL=(ALL) ALL

Não entregamos sudo su. Não liberamos /bin/bash. Não demos controle irrestrito de todos os comandos.

É só o find. Uma linha. Parece uma implementação de least privilege.

Só que existe uma diferença importante entre “o programa serve para procurar arquivos” e “o programa só consegue procurar arquivos”.

O find não está na segunda categoria.

02 / A CAPACIDADE

O find consegue executar comandos.

Entre as funcionalidades do GNU find existe o -exec. Podemos procurar arquivos e executar alguma ação sobre o resultado:

find /tmp -name "*.log" -exec ls -lh {} \;

Até aqui, absolutamente normal. É uma funcionalidade legítima e extremamente útil.

O problema aparece quando voltamos para a nossa regra: o find pode ser executado como root. E ele também consegue executar outros comandos.

Juntando as duas coisas, no laboratório:

sudo find . -exec /bin/sh \; -quit

O -exec inicia o shell; o \; encerra essa ação na sintaxe do comando. O -quit faz o find sair depois que o shell terminar.

Uma busca que terminou em root.

Dentro do shell, executei:

id

E o resultado deixou de ser o usuário comum:

uid=0(root) gid=0(root) groups=0(root)

Os grupos exibidos podem variar conforme o ambiente. Aqui, o ponto é o uid=0.

Pronto. A regra que parecia liberar apenas uma ferramenta de busca acabou permitindo um shell privilegiado.

Sem CVE. Sem malware. Sem exploit misterioso do YouTube, kkk.

O find simplesmente fez exatamente aquilo que foi programado para fazer.

03 / O ERRO

Então existe uma vulnerabilidade no find?

Não nesse cenário. E essa distinção é provavelmente a parte mais importante do laboratório.

O find não “fez merda”. A política fez.

-exec é uma funcionalidade legítima. O erro foi colocar uma ferramenta capaz de executar comandos em um contexto privilegiado sem considerar as capacidades que ela expõe.

Isso muda bastante a forma de analisar uma entrada no sudoers. Não basta perguntar “qual programa estou liberando?”. A pergunta mais interessante é:

O que esse programa consegue fazer depois que eu entrego privilégios a ele?

Essa pequena mudança de lógica foi o que fez least privilege finalmente clicar pra mim.

04 / AUTENTICAÇÃO

Mas o problema não é o NOPASSWD?

Não é ele que cria essa capacidade. Esse detalhe é fácil de confundir.

Na nossa regra, NOPASSWD dispensa a autenticação para executar aquela entrada. Podemos remover:

usuario ALL=(root) /usr/bin/find

Agora a política exige autenticação — que pode já estar válida no cache do sudo. Legal.

Só que, depois dessa verificação, o sistema continua dizendo: “sim, você está autorizado a executar /usr/bin/find como root”. E as funcionalidades do find continuam lá.

A senha ajuda a verificar a identidade de quem está solicitando a operação. Ela não reduz o que a operação consegue fazer depois de iniciada. São problemas diferentes.

05 / OLHAR ALÉM DO NOME

É aqui que o GTFOBins fica interessante.

Foi estudando isso que o GTFOBins começou a fazer muito mais sentido pra mim. O projeto cataloga binários legítimos de sistemas Unix e comportamentos relevantes quando eles recebem determinadas permissões ou são executados em determinados contextos.

find é um exemplo. Mas a ideia vai muito além dele.

Um programa que você enxerga como leitor de texto pode chamar outros comandos. Um editor pode executar processos. Um interpretador pode interpretar muito mais coisa do que uma única tarefa. Uma ferramenta de transferência pode ler ou escrever locais que você não tinha considerado.

É quase como entregar uma chave pensando: “essa é a chave da gaveta”. Só que você nunca verificou quais outras fechaduras ela abre. Aí descobre que também abre a porta do prédio.

O objetivo não é decorar o GTFOBins inteiro.

Eu poderia tentar decorar dezenas de comandos: find faz isso, vim faz aquilo, less faz aquilo outro. Provavelmente esqueceria metade depois de algumas semanas.

E, sinceramente, não acho que esse seja o ponto. A informação específica pode ser consultada. O raciocínio precisa ficar.

Agora, quando vejo uma entrada no sudoers, minha primeira pergunta não é mais “pra que normalmente usamos esse programa?”. É “quais capacidades ele possui quando executado como root?”. Essa pergunta continua funcionando mesmo quando eu nunca vi aquele binário antes.

06 / A NECESSIDADE REAL

“Então não posso liberar nada no sudoers?”

Também não. Senão a conclusão seria: “acabou, pessoal, removam o sudo, desinstalem Linux e vamos voltar pro Windows”. Seria um pouco dramático.

A questão é descobrir qual é a necessidade real. Imagine que alguém diga: “esse usuário precisa usar less como root porque precisa visualizar um log”.

Espera. O objetivo é usar less? Ou o objetivo é ler aquele arquivo?

Parece uma discussão semântica idiota, mas muda completamente a solução.

Se o usuário só precisa ler /var/log/minha-app.log, talvez possamos conceder acesso justamente a esse recurso. Dependendo do cenário, isso pode ser feito com permissões tradicionais, um grupo apropriado ou uma ACL.

sudo setfacl -m u:usuario:r /var/log/minha-app.log

Agora entregamos a capacidade que ele realmente precisava: ler o arquivo. Não precisamos transformar uma ferramenta inteira em uma operação privilegiada.

Corrigiu? Testa de novo.

Depois de remover a autorização para o find e ajustar a leitura do log, eu quero confirmar duas coisas: o usuário consegue fazer o trabalho dele e não consegue mais abrir aquele shell privilegiado.

cat /var/log/minha-app.log
sudo -l
sudo find . -exec /bin/sh \; -quit

A leitura deve funcionar. O sudo -l não deve mais mostrar a permissão antiga, e a tentativa com find deve ser negada. Vale conferir outras regras e grupos: remover uma linha não ajuda se outra entrada ainda libera o mesmo acesso.

07 / QUANDO ROOT É NECESSÁRIO

Às vezes precisamos, sim.

Least privilege não significa fingir que administração de sistemas não existe. Nesse caso, a ideia continua sendo reduzir capacidades.

Em vez de entregar uma ferramenta extremamente flexível, podemos criar uma operação muito mais restrita: um script administrativo específico, controlado pelo root, que execute apenas uma determinada tarefa.

Isso ainda exige cuidado. Se o usuário consegue editar esse script — ou substituir o arquivo pelo diretório onde ele está —, acabou a brincadeira. Se consegue controlar livremente os argumentos enviados para outro comando, talvez exista uma rota de escape. Caminhos, variáveis de ambiente e dependências também entram nessa conta.

Segurança tem essa pequena mania inconveniente de fazer uma solução simples gerar três novas perguntas.

Mas a direção é diferente. Em vez de “toma esse programa poderoso e usa só a parte que eu estava imaginando”, passamos para “toma exatamente a operação que você precisa executar”.

Uma linha não significa pouco privilégio.

A parte mais interessante desse laboratório foi perceber como uma configuração pode parecer restritiva. Nossa regra é minúscula. Visualmente, parece muito mais segura do que entregar acesso completo.

Mas quantidade de caracteres não mede superfície de ataque. Uma única entrada pode expor uma capacidade extremamente poderosa. Uma configuração mais longa pode ser muito mais restritiva se controlar corretamente recursos, parâmetros e operações.

Entregue somente as capacidades necessárias para aquela tarefa — não uma ferramenta inteira esperando que o usuário utilize apenas a capacidade que você tinha em mente.

Um teste mental que passei a usar.

Hoje, quando vejo uma permissão privilegiada, tento imaginar que o usuário vai fazer exatamente o contrário do que eu esperava. Não necessariamente porque ele é malicioso. Pode ser um atacante usando aquela conta, um processo comprometido ou simplesmente alguém curioso.

A intenção de quem escreveu a configuração não é uma barreira de segurança. Se minha regra depende de “ninguém vai tentar usar essa outra função”, eu provavelmente ainda não terminei de desenhar a regra.

Afinal, o que revisar no sudoers?

Vale investigar se a ferramenta consegue iniciar processos, executar comandos, abrir shells, escrever arquivos, carregar configurações ou plugins, interpretar código, controlar caminhos arbitrários ou modificar algo que depois será executado por um processo privilegiado.

Não significa automaticamente que o programa seja inseguro. Significa que essas capacidades fazem parte do privilégio que você está concedendo. O GTFOBins ajuda a acelerar essa análise, não a substituir entendimento.

08 / O QUE FICOU DO LAB

Eu comecei querendo entender sudoers.

Saí entendendo melhor uma coisa um pouco maior.

Least privilege não é uma propriedade do tamanho da regra. Também não é olhar para uma ferramenta, pensar no uso mais comum dela e concluir que aquele é o único privilégio sendo concedido.

Porque às vezes você acha que está entregando a chave de uma gaveta. E descobre, um comando depois, que entregou a chave do prédio.

Perguntas rápidas

Pra continuar investigando

• find no GTFOBins ↗As capacidades do binário em diferentes contextos.
• Manual do GNU Findutils ↗A sintaxe e o comportamento do -exec.
• Manual do sudoers ↗Regras, autenticação e correspondência de comandos.
• Manual do setfacl ↗Entradas de ACL e máscara de permissões.
• O primeiro registro deste laboratório →A publicação anterior, com o vídeo.

Ambiente de laboratório: não teste técnicas de escalação de privilégios em sistemas sem autorização.