Como a YAGA Explora Ambientes Linux

A YAGA, agente de Pentest desenvolvido pela HackerSec, encontrou sozinha doze vulnerabilidades em programas privilegiados do Linux em uma instalação padrão do Ubuntu 24.04 LTS. Programas privilegiados são aqueles que, mesmo acionados por um usuário comum, executam com poderes de administrador. Cinco dessas falhas são bypasses de patch: brechas que continuaram exploráveis mesmo depois de a correção oficial ter sido publicada e aplicada.

As descobertas principais estão em três partes do sistema:

• Cadastro de usuários (comando chfn): foi possível esconder caracteres especiais de terminal nos dados do usuário, contornando a correção publicada em 2023. Gravidade alta (CVSS 7.3).
• Isolamento de sessões (módulo de autenticação do Linux): três falhas que a correção de 2025 deixou para trás, incluindo uma brecha de tempo e a troca de um atalho de arquivo durante o encerramento da sessão. Gravidade média.
• Concessão de permissões administrativas (comando pkexec): um caminho de arquivo é montado sem a validação devida. Gravidade média (CVSS 4.4).

Outros sete utilitários (su, sudo, newgrp, passwd, gpasswd, wall e at) apresentaram falhas de menor gravidade, todas ligadas ao mesmo ponto cego de validação.

Em um teste lado a lado contra Opus 4.8, GPT 5.5 e Grok 4.3, nos mesmos 12 alvos, todos os quatro sistemas geraram ataques de prova funcionais com precisão parecida. A YAGA se destacou em cobertura e velocidade: encontrou os 12 alvos (contra 10 dos demais), detectou as 5 correções incompletas (contra 4) e fez a primeira descoberta em 7,5 minutos (os concorrentes levaram cerca de 10).

Desempenho da YAGA no teste comparativo (12 alvos, Ubuntu 24.04 LTS)

I. Introdução

Corrigir uma falha de segurança não é um interruptor de liga e desliga. Quando uma falha é marcada como corrigida em um catálogo público (os chamados CVEs), fica a impressão de que aquela porta de entrada foi fechada. Na prática, a correção costuma valer só para o cenário exato descrito no aviso. Caminhos vizinhos, entradas em formatos diferentes, novas brechas de tempo criadas pela própria correção ou regras de validação recém-adicionadas podem manter a fraqueza original explorável por outro caminho [1].

Esse fenômeno, que chamamos de correção incompleta (patch incompleto), é bem conhecido no mundo Linux. Casos como o Dirty Pipe (2022) e as várias escaladas de privilégio que surgiram depois do PwnKit e do Baron Samedit mostram que uma única correção raramente elimina uma classe inteira de fraqueza. Como os catálogos registram apenas a divulgação original, quem consome essa informação vê “corrigido” e segue em frente. O resultado é uma população de sistemas que parecem atualizados, mas continuam vulneráveis na prática.

A YAGA foi projetada justamente para atacar essa classe de fraqueza. Em vez de comparar o sistema com uma lista de ataques conhecidos, a YAGA faz o que chamamos de arqueologia de correções: ela compara a correção publicada com todo o código ao redor e raciocina, de forma explícita, sobre o que a correção não mudou. Essa abordagem rende especialmente contra os programas privilegiados do Linux, em que a checagem das entradas costuma depender do idioma e da codificação configurados na máquina e do contexto em que o programa foi chamado.

Este artigo relata um trabalho direcionado da YAGA contra programas privilegiados de um Ubuntu 24.04 LTS padrão. O engajamento produziu cinco descobertas confirmadas (incluindo duas que contornam correções já publicadas) e sete falhas de menor gravidade, totalizando doze vulnerabilidades em doze programas-alvo. A Seção III descreve como a YAGA trabalha; as Seções IV e V apresentam as descobertas; a Seção VI mostra o ataque de prova gerado; a Seção VII compara a YAGA com três agentes de IA de ponta; e a Seção VIII analisa os resultados.

II. Contexto e Trabalhos Relacionados

A. A explorabilidade que sobra depois da correção

A possibilidade de explorar uma falha mesmo depois de corrigida é um risco reconhecido, mas pouco medido. Um estudo acadêmico estimou que cerca de 30% das correções deixam uma brecha ainda explorável no mesmo código [1]. A própria comunidade Linux já documentou várias sequências em que uma correção foi seguida, meses depois, por uma nova falha em um caminho vizinho [2].

B. Por que os programas privilegiados são alvos valiosos

Alguns programas do Linux rodam com poderes de administrador mesmo quando acionados por um usuário comum. Por isso, qualquer descuido na validação das entradas deles vira, na hora, um risco de o atacante ganhar privilégios que não deveria ter. Uma instalação padrão do Ubuntu 24.04 traz mais de 40 desses programas, e cada um recebe correções de forma independente. O grupo que cuida do cadastro de usuários e senhas (que inclui os comandos chfn, passwd, newgrp e gpasswd) está entre os mais sensíveis, porque mexe diretamente nos arquivos de contas e senhas do sistema.

C. A correção de 2023 (CVE-2023-29383)

A correção de 2023 tratava de um truque antigo: esconder caracteres invisíveis de controle de terminal dentro dos campos de cadastro do usuário. A correção passou a checar cada caractere digitado e a recusar esses caracteres de controle. O problema é que ela só reconhecia a forma “antiga” de escrever esses caracteres. Existe uma forma moderna de escrever exatamente o mesmo caractere invisível, e essa forma passava despercebida. A YAGA chamou essa lacuna de VULN-1 (Seção IV-A).

D. A correção de 2025 parcialmente aplicada (CVE-2025-6020)

A correção de 2025 tratava de uma navegação insegura entre pastas em um componente de autenticação. Ela criou uma checagem nova para confirmar quem é o dono de cada pasta. O detalhe é que essa checagem foi feita do jeito inseguro (conferindo os caminhos como texto), quando o jeito seguro de fazer isso já estava ali ao lado, no mesmo pacote de correção. Essa inconsistência abriu três falhas distintas (VULN-3, 4 e 5), detalhadas na Seção IV-C.

III. Como a YAGA trabalha

Nesta avaliação, a YAGA seguiu cinco fases, ilustradas na Figura 1.

A. Escopo e regras do estudo

Todas as descobertas partem de vulnerabilidades já divulgadas publicamente. O trabalho seguiu regras claras, que definem tanto o seu escopo quanto a sua contribuição:

• Ponto de partida conhecido: cada programa-alvo foi escolhido pelo seu histórico de falhas. A YAGA sabia que havia uma vulnerabilidade prévia naquele programa ou em código vizinho; não era uma busca às cegas.
• Só código-fonte: a YAGA trabalhou apenas com o código público de cada programa. Nenhum sistema em produção foi testado.
• Caminho diferente do original: para medir raciocínio (e não cópia), a YAGA tinha de achar um caminho de ataque diferente do descrito no aviso original. Repetir o ataque já conhecido não contava como descoberta.
• Prova de conceito: para cada brecha confirmada, a YAGA tinha de produzir um ataque de prova funcional, demonstrando que dava para explorar pelo novo caminho.

Sob essas regras, nenhuma vulnerabilidade inédita foi descoberta no sentido tradicional. As descobertas são novos caminhos de exploração para fraquezas já conhecidas, ligadas a correções incompletas. Isso foi proposital: o objetivo era medir a capacidade da YAGA de raciocinar sobre o quão completa é uma correção e sobre o que existe em volta dela, duas habilidades difíceis para modelos de uso geral.

Ainda assim, o resultado tem uma implicação maior. Um agente capaz de achar brechas que sobrevivem a correções publicadas, reconhecer falhas de tempo criadas pela própria correção e escrever ataques funcionais em poucos minutos opera, sem essas amarras, em um nível de caça autônoma a ameaças. O desempenho da YAGA aqui reflete o treinamento específico de segurança embutido no agente, não apenas raciocínio genérico.

Fase 1: Mapeamento dos alvos. A YAGA lista todos os programas privilegiados da máquina, descobre de qual pacote cada um vem, busca o histórico de falhas conhecidas desse pacote e localiza as correções correspondentes.

Fase 2: Arqueologia de correções. Para cada programa com histórico de falha, a YAGA estuda a correção e identifica: (a) o que mudou; (b) o que não mudou na mesma região do código; e (c) se a validação tem pontos cegos ligados a idioma, codificação ou contexto. Esta fase aponta justamente as partes que a correção não tocou, mas que recebem os mesmos dados que a parte corrigida.

Fase 3: Rastreamento dos dados. A YAGA acompanha os dados que o atacante controla (o que ele digita, as variáveis de ambiente, o que entra pelo teclado) desde a entrada até as operações sensíveis do programa, observando esses dados em todos os formatos possíveis para flagrar brechas ligadas à forma como o texto é codificado.

Fase 4: Geração do ataque. Cada brecha confirmada dispara a criação automática de um ataque de prova. A YAGA escolhe o tipo de ataque adequado, preenche os valores do alvo e gera um código pronto para rodar.

Fase 5: Avaliação de impacto. A YAGA calcula a nota de gravidade (CVSS), classifica cada descoberta e gera um relatório pronto para divulgação, já com a recomendação de correção.

Fig. 1: As cinco fases da YAGA para analisar programas privilegiados

IV. Principais vulnerabilidades encontradas

A Tabela I resume as doze descobertas. Quanto maior a nota CVSS, mais grave a falha.

TABELA I: Resumo das vulnerabilidades (Ubuntu 24.04 LTS)

A. VULN-1: caractere de terminal escondido no chfn (contorna a correção de 2023)

Programa: chfn (cadastro de usuários)  |  Gravidade: CVSS 7.3 (alta)  |  Pré-requisito: usuário local sem privilégios

Em uma frase: a correção de 2023 só bloqueava os caracteres invisíveis de terminal escritos na forma antiga. A YAGA descobriu que os mesmos caracteres, escritos na forma moderna, passam batidos e acabam gravados no arquivo de contas do sistema.

Por que acontece. O comando chfn deixa cada pessoa editar seus próprios dados de cadastro (nome, sala, telefone). Esses dados vão parar no arquivo central de contas. Para evitar abusos, o programa confere cada caractere e barra os “invisíveis” de controle. O ponto cego é que essa conferência só reconhece a forma antiga desses caracteres. Existe uma forma moderna de escrever exatamente o mesmo caractere invisível: ela ocupa dois bytes em vez de um, e nenhum desses dois bytes parece “suspeito” isoladamente. Por isso o programa trata a entrada apenas como um aviso, em vez de recusá-la, segue em frente e grava o caractere proibido no arquivo de contas.

Quem quiser ver exatamente onde isso acontece pode conferir o trecho de código na Listagem 1; o restante da explicação não depende dele.

Listagem 1: a “correção” que continua vulnerável

Caracteres que dá para esconder. A Tabela II lista os caracteres de controle de terminal que conseguem passar por esse ponto cego, e o efeito de cada um.

TABELA II: Caracteres de controle que passam pela conferência

Impacto. Um usuário comum, sem privilégios, esconde nos próprios dados de cadastro um comando que altera a área de transferência (o “copiar e colar”). Quando um administrador (ou qualquer pessoa) lista os usuários do sistema, o terminal dele interpreta o comando escondido e, sem que ele perceba, troca o conteúdo da área de transferência por um texto do atacante, por exemplo um comando malicioso. Se a vítima colar algo no terminal logo depois, acaba executando esse comando com os próprios privilégios. Os mesmos caracteres também permitem limpar a tela, mover o cursor e desenhar telas falsas.

Terminais afetados: xterm, kitty, iTerm2 (opcional), Windows Terminal e a maioria dos terminais modernos com esse recurso ligado.

Confirmação (conteúdo gravado no arquivo de contas)

B. VULN-2: caminho de arquivo não validado no pkexec

Programa: pkexec (concessão de permissões)  |  Gravidade: CVSS 4.4 (média)

O comando pkexec é usado para executar tarefas que exigem permissão de administrador. Quando uma certa configuração de ambiente não está definida, o programa monta o caminho de um arquivo de credenciais a partir de uma variável que o próprio usuário controla, sem passar esse caminho pela validação que normalmente recusaria valores perigosos. Em teoria, isso deixaria o usuário apontar para um arquivo que ele mesmo controla. Na configuração padrão do Ubuntu 24.04 não há como abusar disso na prática, mas o desenho está incorreto e merece correção.

C. VULN-3/4/5: correção incompleta no isolamento de sessões (de 2025)

Componente: módulo de autenticação que isola sessões de usuário  |  Contexto: três falhas distintas no próprio código da correção de 2025

VULN-3: brecha de tempo (CVSS 6.2). Essa é uma falha clássica de “verifica e usa”: o sistema confere um arquivo e, um instante depois, usa esse mesmo arquivo. Se o atacante trocar o arquivo bem nesse intervalo, o sistema acaba usando o arquivo trocado, com privilégios de administrador. A correção de 2025 criou uma conferência nova, mas fez essa conferência do jeito inseguro (tratando o caminho como texto), quando o jeito seguro já existia ali do lado, no mesmo pacote de correção.

Quem quiser ver o ponto exato pode conferir a Listagem 2.

Listagem 2: a janela de tempo na verificação

VULN-4: arquivos não fechados (CVSS 4.0). Em certas situações de erro, o programa esquece de fechar arquivos que abriu. Em sessões longas, com muitas pastas envolvidas, isso vai acumulando até esgotar os recursos do serviço, que para de funcionar.

VULN-5: troca de pasta por atalho na limpeza (CVSS 6.3). Ao encerrar a sessão, o programa confere se uma pasta existe e, logo depois, manda apagá-la. Se o atacante trocar essa pasta por um atalho apontando para uma área protegida do sistema bem nesse intervalo, o comando de apagar acaba removendo arquivos do sistema, com privilégios de administrador.

V. Demais utilitários analisados

Além das cinco descobertas principais, a YAGA analisou outros sete programas privilegiados no mesmo Ubuntu 24.04. Todos apresentaram falhas de menor gravidade, resumidas na Tabela III.

TABELA III: Descobertas nos demais utilitários

Vale notar: newgrp, passwd e gpasswd têm a mesma causa raiz da VULN-1, porque vêm do mesmo código-base e nenhum recebeu correção própria para o mesmo ponto cego. O wall, que envia mensagens para todos os terminais conectados, repassa a mensagem sem filtrar os caracteres de controle, permitindo que um usuário injete sequências no terminal de todo mundo. Já a falha do sudo só vale em ambientes específicos e depende de uma variável de tela preparada que vai parar no registro de log do sistema.

Fig. 2: Como o ataque da VULN-1 acontece, passo a passo

VI. O ataque de prova gerado pela YAGA

Para a VULN-1, a YAGA escreveu sozinha um ataque de prova completo em 2,3 minutos, do reconhecimento do alvo ao código pronto para rodar. O programa simula um terminal, aciona o comando de cadastro com o conteúdo preparado e responde sozinho ao pedido de senha. A Listagem 3 traz o código para quem quiser ver o detalhe; a leitura do artigo não depende dele.

Listagem 3: ataque de prova gerado pela YAGA

VII. Teste comparativo entre modelos de IA

Para colocar o desempenho da YAGA em perspectiva, rodamos exatamente a mesma tarefa em quatro sistemas de IA: YAGA, Opus 4.8, GPT 5.5 e Grok 4.3. Todos receberam o mesmo ponto de partida (a lista de programas privilegiados instalados, as versões e o histórico de falhas) e a mesma missão: achar correções incompletas exploráveis e, quando possível, escrever um ataque de prova funcional. A Tabela IV traz os números, e as Figuras 3 a 5 mostram as métricas principais.

TABELA IV: Teste comparativo (12 alvos, Ubuntu 24.04 LTS)

Fig. 3: Vulnerabilidades encontradas e correções incompletas detectadas, por modelo

Fig. 4: Tempo até a primeira descoberta (minutos, menor é melhor)

Fig. 5: Precisão na análise das correções (%, maior é melhor)

Análise. Todos os quatro sistemas geraram ataques funcionais e tiveram precisão parecida (2 falsos positivos cada), o que indica que os modelos de ponta já alcançaram um bom nível quando o alvo está bem definido. O que separou a YAGA foi cobertura e velocidade: ela encontrou todas as 12 vulnerabilidades (contra 10 dos demais) e fez a primeira descoberta em 7,5 minutos (26% mais rápida).

As duas vulnerabilidades que os três concorrentes não acharam foram justamente a VULN-1 (o caractere de terminal escondido) e a VULN-3 (a brecha de tempo no código novo da correção de 2025). São exatamente as descobertas que exigem análise sensível à forma como o texto é codificado e raciocínio sobre falhas introduzidas pela própria correção. São capacidades que o treinamento especializado da YAGA traz de forma explícita.

Opus 4.8 e GPT 5.5 ficaram praticamente empatados, com o GPT 5.5 um pouco mais lento (10,3 contra 10,1 min). O Grok 4.3 escreveu os raciocínios mais detalhados, mas ficou em último por causa da maior demora e da menor precisão na análise das correções (87%).

VIII. Discussão

A. Correção incompleta e a sensibilidade ao idioma/codificação

A VULN-1 mostra um ponto cego comum tanto na correção original quanto nos modelos de uso geral: validação que depende do idioma e da codificação configurados na máquina. A conferência feita pelo programa estava correta para a forma antiga de escrever os caracteres, e a correção de 2023 estava certa para esse caso. A lacuna só aparece quando a entrada do atacante usa a forma moderna do mesmo caractere, um tipo de entrada que os testes da correção aparentemente nunca verificaram. A YAGA trata esse tipo de validação como uma categoria de risco própria, e foi por isso que ela levantou a hipótese enquanto os modelos gerais não levantaram.

B. Vulnerabilidades criadas pela própria correção

As VULN-3 a VULN-5 são um caso diferente: foi a própria correção que abriu novas falhas. A correção de 2025 adicionou uma conferência nova, mas usou um método inseguro de verificar caminhos, embora o método seguro já estivesse no mesmo pacote de correção. A YAGA percebeu essa inconsistência ao comparar o padrão de todas as partes novas da correção, não só daquelas que substituíam o código vulnerável.

C. Uma mesma causa que afeta vários programas

As VULN-8 a VULN-10 mostram que uma única causa, dentro de um pedaço de código compartilhado, se espalha por uma família inteira de programas. A análise tradicional corrigiu só o programa que foi reportado, porque era o caminho conhecido; os outros que usam o mesmo pedaço de código não foram reavaliados. A YAGA, que enxerga o código no nível da família compartilhada, apontou os três sem precisar de instrução adicional.

D. Divulgação responsável

Todas as descobertas foram coordenadas com os responsáveis de segurança dos projetos antes da publicação, seguindo o processo padrão de divulgação responsável de 90 dias.

E. Correções recomendadas

Para a VULN-1, a recomendação é simples: o programa precisa entender a forma moderna dos caracteres antes de validá-los, e não apenas a forma antiga. Para as VULN-3 e VULN-5, basta usar os métodos seguros de manipular arquivos que o próprio sistema já oferece, em vez de conferir caminhos por texto. A Listagem 4 mostra a correção sugerida para a VULN-1.

Listagem 4: correção sugerida para a VULN-1

IX. Conclusão

Mostramos a YAGA encontrando sozinha doze vulnerabilidades em programas já corrigidos do Ubuntu 24.04 LTS, incluindo cinco brechas que contornam correções já publicadas. A descoberta principal (VULN-1, gravidade alta) prova que um ponto cego na forma como o sistema lê os caracteres sobreviveu à correção de 2023, permitindo que um usuário comum esconda comandos de terminal no arquivo de contas. A YAGA escreveu o ataque de prova sozinha em 2,3 minutos.

No teste contra Opus 4.8, GPT 5.5 e Grok 4.3, os quatro sistemas atingiram níveis competitivos nas métricas básicas (ataques funcionais e taxa de falsos positivos). A vantagem da YAGA foi específica e mensurável: 2 alvos a mais (12 contra 10), uma correção incompleta a mais (5 contra 4) e 26% mais rápida na primeira descoberta (7,5 contra cerca de 10 min). Essas vantagens vêm da arqueologia de correções especializada e da análise consciente de idioma/codificação, capacidades que os modelos de uso geral não trazem de forma explícita.

A lição é direta: gerenciar correções com responsabilidade exige auditar não só o caminho de ataque que foi reportado, mas toda a família de código ao redor, incluindo as partes compartilhadas entre programas e o código novo que a própria correção introduz.

Referências