Escalada de privilégios no Linux: vetores e hardening para defensores

Escalada de privilégios é o momento em que um ponto de apoio limitado num host Linux se converte em controle total. Para um blue team, é uma das fases mais determinantes de uma intrusão: um atacante que aterrissa como conta de serviço sem privilégios e depois vira root pode desativar o registro de logs, instalar persistência e mover-se lateralmente pelo parque. Este artigo adota uma abordagem de entender para defender. Descrevemos como a escalada funciona em nível conceitual, mapeamos as superfícies que os atacantes sondam e depois dedicamos a maior parte do tempo ao que importa para os defensores: a telemetria que revela as tentativas de escalada e o hardening que elimina a oportunidade pela raiz.

O que escalada de privilégios realmente significa

No Linux, a autoridade é expressa pela identidade de usuário e grupo, pelo UID/GID efetivo com que um processo é executado e por um conjunto de capabilities de kernel de granularidade fina. Um processo normalmente herda os privilégios da conta que o iniciou. Escalada de privilégios é qualquer técnica que permite que o código seja executado com mais autoridade do que lhe foi concedida. Existem duas grandes famílias. A escalada vertical vai de um usuário de baixo privilégio para um superior, geralmente root. A escalada horizontal move-se lateralmente para outro usuário do mesmo nível de privilégio para alcançar dados ou sessões. Ambas importam, mas a escalada vertical para root é a que os defensores mais temem, porque root pode reescrever as regras do sistema, incluindo os controles destinados a detectá-lo.

O modelo mental chave para um defensor é que a escalada raramente é um único exploit mágico. É quase sempre o abuso de um mecanismo legítimo configurado de forma frouxa demais: um binário auxiliar com poder em excesso, uma tarefa agendada que roda como usuário privilegiado, uma conta de serviço que pode editar a própria configuração. Quem entende o mecanismo consegue tanto detectar o abuso quanto remover a configuração frouxa.

Como a escalada funciona em alto nível

Um atacante que aterrissou num host realiza reconhecimento local para enumerar o que a identidade atual consegue alcançar. Ele procura arquivos que possa escrever e que processos privilegiados irão ler ou executar depois, programas que rodam com autoridade elevada mas aceitam entradas influenciadas pelo atacante, e software desatualizado com falhas conhecidas. A escalada em si é o momento em que uma entrada controlada pelo atacante cruza uma fronteira de confiança para um contexto privilegiado. Conceitualmente, todo vetor é uma variação de um mesmo tema: uma entrada de baixo privilégio que alcança um caminho de execução de alto privilégio. Sua tarefa defensiva é encontrar essas pontes e removê-las ou vigiá-las de perto.

Vetores comuns e a superfície de ataque

O sudo mal configurado é o achado mais comum em ambientes reais. Quando uma conta pode executar comandos específicos como root, e um desses comandos pode abrir um shell, ler arquivos arbitrários ou escrever em caminhos sensíveis, a fronteira desmorona. Curingas nas regras do sudoers e entradas NOPASSWD ampliam ainda mais a superfície.

Binários SUID e SGID rodam com os privilégios do dono do arquivo, independentemente de quem os inicie. Um programa SUID-root legítimo que possa ser induzido a executar outro comando, ou a ler e escrever arquivos como root, torna-se uma alavanca. A preocupação cresce quando binários próprios ou de terceiros carregam o bit SUID desnecessariamente.

Capabilities excessivas do Linux são um primo mais sutil. Um binário com cap_setuid, cap_dac_override ou cap_sys_admin detém uma fatia do poder de root sem o bit SUID, e elas passam facilmente despercebidas numa auditoria que só verifica os modos de arquivo.

Tarefas agendadas como jobs cron, timers do systemd e scripts de init frequentemente rodam como usuários privilegiados. Se algum script que elas executam, ou algum diretório no caminho até esse script, for gravável por um usuário menor, esse usuário pode influenciar o que o root executa. Permissões fracas de arquivos e serviços generalizam isso: uma unit de serviço gravável por todos, um arquivo de configuração que um serviço lê ao iniciar ou um diretório de bibliotecas no caminho de busca de um binário privilegiado são todos pontes de baixo para alto.

A manipulação de PATH e do ambiente explora scripts privilegiados que chamam programas auxiliares pelo nome em vez do caminho absoluto; se um atacante puder influenciar o caminho de busca, o auxiliar resolve para o binário dele. Por fim, vulnerabilidades de kernel e de serviços em software sem patch dão escalada direta, e más configurações de contêineres e namespaces, como um contêiner rodando como root com o sistema de arquivos do host ou o socket do Docker montado, permitem escapar para o host.

Detecção: a telemetria que revela a escalada

A fonte mais valiosa é o framework de auditoria do Linux, o auditd. Regras que observam execve, alterações em /etc/sudoers e /etc/sudoers.d/, escritas sob /etc/cron.* e /etc/systemd/, e o uso das syscalls setuid, setreuid e capset transformam a escalada silenciosa em eventos registrados. Marque essas regras com chaves para que seu SIEM possa alertar sobre elas. Uma rajada repentina de enumeração — muitos eventos execve de id, sudo -l, find / -perm e leituras de /etc/passwd em segundos — é um forte sinal comportamental mesmo antes da escalada.

O kernel emite um registro de auditoria quando setuid eleva o privilégio. Correlacione essa transição para root com uma linha de base de quais serviços fazem isso legitimamente; um processo inesperado que dá o salto merece investigação imediata. O sudo escreve no log de autenticação, então alerte sobre falhas, sobre o uso do caminho NOPASSWD por contas que não deveriam tê-lo e sobre qualquer comando executado como root que em seguida abra um interpretador de shell. No lado do EDR, procure cadeias pai-filho suspeitas, por exemplo um processo de servidor web ou banco de dados que inicia bash, sh, python ou nc, e uma conta de serviço não interativa que de repente obtém um TTY interativo.

O monitoramento de integridade de arquivos fecha o ciclo. Alerte sempre que o bit SUID ou SGID aparecer num binário, sempre que as capabilities de arquivo mudarem e sempre que arquivos de cron, units do systemd ou bibliotecas compartilhadas forem modificados fora de uma janela de mudança. Envie tudo isso de forma centralizada para que um atacante com nível root que apague os logs locais não consiga eliminar as evidências que já gerou.

Mitigação e hardening: primeiro o menor privilégio

Toda decisão de hardening flui do menor privilégio. Audite o sudoers e remova direitos abrangentes: conceda comandos específicos a usuários específicos, evite NOPASSWD a menos que uma automação de escopo estreito o exija, e nunca permita comandos que possam abrir um shell ou ler arquivos arbitrários salvo se essa for a intenção deliberada. Prefira sudo com restrições de argumentos a conceder um shell root interativo. Revise essas regras de forma agendada, pois elas se acumulam ao longo do tempo como exceções pontuais que nunca são removidas.

Execute os serviços como contas dedicadas e sem privilégios, uma por serviço, de modo que comprometer uma aplicação web não entregue ao atacante um shell em que qualquer outro serviço confie. Use as diretivas de sandboxing do systemd — NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes e um CapabilityBoundingSet restritivo — para reduzir o que um serviço comprometido pode fazer mesmo antes de considerar a escalada.

Hardening de sistema de arquivos, SUID e capabilities

Inventarie cada binário SUID e SGID da sua frota e justifique cada um. Remova o bit de tudo o que não precisa dele, e trate um binário SUID inesperado como um incidente. Monte os sistemas de arquivos que guardam dados graváveis pelo usuário ou temporários — /tmp, /var/tmp, /dev/shm e as partições de home — com nosuid, nodev e, quando prático, noexec, para que um arquivo SUID plantado simplesmente não carregue o privilégio. Audite as capabilities de arquivo com ferramentas que as listem por toda a árvore, e prefira capabilities a SUID apenas quando puder delimitá-las estritamente.

Tranque as permissões de tudo o que um processo privilegiado consome: os diretórios de cron, os arquivos de unit do systemd, a configuração de serviços e os diretórios no caminho de busca de bibliotecas e executáveis de qualquer binário privilegiado não devem ser graváveis por usuários menores. Em scripts privilegiados, chame sempre os auxiliares pelo caminho absoluto e redefina o ambiente, para que a manipulação de PATH não tenha nada a que se agarrar.

Kernel, patching e controle de acesso obrigatório

O patching tempestivo remove as vulnerabilidades de kernel e de serviços que dão escalada direta; acompanhe sua exposição contra um feed de vulnerabilidades e priorize tudo que tenha uma falha pública de escalada local de privilégios. Além do patching, adicione camadas de controle de acesso obrigatório. O SELinux em modo enforcing ou um perfil AppArmor bem ajustado confina um processo ao que seu papel exige, de modo que mesmo uma escalada bem-sucedida para root dentro de um domínio confinado não possa reescrever livremente o sistema. Combine isso com hardening de kernel como kernel.yama.ptrace_scope, acesso restrito ao dmesg e módulos de kernel não usados desativados para remover classes inteiras de técnica.

Armadilhas comuns que os defensores devem evitar

A primeira armadilha é tratar o hardening como um projeto único. Regras de sudo, inventários de SUID e jobs cron derivam à medida que os sistemas mudam; sem reauditoria periódica, a superfície volta a crescer em silêncio. A segunda é monitorar apenas assinaturas de exploit conhecidas ignorando o comportamento — a escalada por má configuração não produz assinatura de exploit alguma, apenas uma linhagem de processos anômala e transições de privilégio. A terceira é manter os logs apenas localmente, que um atacante com nível root apaga; centralize a telemetria para que ela sobreviva ao comprometimento do host. A quarta é esquecer os contêineres: um contêiner que roda como root, recebe --privileged ou monta o socket do Docker concede, na prática, root no host, então aplique a mesma disciplina de menor privilégio dentro das imagens.

Checklist prático de hardening

Use isto como revisão recorrente. Menor privilégio: audite o sudoers, remova regras abrangentes e NOPASSWD, execute cada serviço como sua própria conta sem privilégios. Sistema de arquivos: inventarie e minimize SUID/SGID, monte as partições graváveis com nosuid,nodev,noexec, endureça permissões nos caminhos de cron, systemd e configuração. Capabilities: audite as capabilities de arquivo e remova as desnecessárias. Kernel: aplique patches numa cadência, ative SELinux ou AppArmor em modo enforcing, aplique sysctls de hardening de kernel. Detecção: implante regras de auditd para setuid, sudoers, cron e capset; monitore a linhagem de processos no EDR; ative o monitoramento de integridade de arquivos em caminhos privilegiados; envie todos os logs para um armazenamento central que o host não alcança. Contêineres: execute como não root, remova capabilities, nunca monte o socket do Docker em cargas não confiáveis.

Perguntas frequentes

É seguro remover binários SUID? Alguns binários de sistema realmente precisam do bit, como o passwd. A abordagem segura é inventariar cada arquivo SUID, mapeá-lo para uma necessidade justificada, remover o bit de tudo o que for injustificado e testar primeiro num ambiente de staging. Um binário SUID inexplicável tem muito mais chance de ter sido plantado por um atacante do que de ser legítimo.

Se eu rodo tudo em contêineres, estou a salvo da escalada de privilégios? Não. Contêineres são uma fronteira, não uma garantia. Um contêiner rodando como root com capabilities excessivas ou um socket do host montado costuma ser um caminho direto para root no host. Trate a configuração de contêineres com o mesmo rigor de menor privilégio que aplica aos hosts, e monitore a escalada também dentro dos contêineres.

Conclusão

A escalada de privilégios no Linux geralmente não é questão de exploits exóticos; é a consequência previsível de configuração frouxa acumulada — uma regra de sudo ampla demais, um bit SUID perdido, um caminho de cron gravável, um kernel sem patch. Isso é uma boa notícia para os defensores, porque significa que a superfície é enumerável e as correções são concretas. Combine menor privilégio disciplinado, hardening de sistema de arquivos e de capabilities, patching tempestivo e controle de acesso obrigatório para eliminar a oportunidade, e depois adicione camadas de auditd, monitoramento de linhagem de processos no EDR e monitoramento centralizado de integridade de arquivos para capturar o que restar. Revisada numa cadência em vez de tratada como algo pontual, essa postura defensiva transforma a escalada de uma inevitabilidade silenciosa num evento barulhento e detectável.