){kind=link}
Pesquisadores de segurança identificaram nove vulnerabilidades graves no AppArmor, módulo de proteção nativo do Linux. As falhas existem no sistema desde 2017 e afetam mais de 12,6 milhões de servidores empresariais ativos ao redor do mundo. O conjunto de brechas recebeu o nome de CrackArmor.
O AppArmor funciona como uma camada de segurança dentro do Linux, definindo o que cada programa pode ou não fazer no sistema. Distribuições populares como Ubuntu, Debian e SUSE já vêm com ele ativado por padrão. Por isso, a exposição ao problema é tão grande.
smart_display
Nossos vídeos em destaque
Em detalhes, o problema não está no conceito por trás do AppArmor. A falha está na forma como o código do módulo foi implementado dentro do kernel. O modelo de controle obrigatório de acesso em si continua válido.
Como o ataque funciona
Para explorar as falhas, o invasor não precisa de senha de administrador. Uma conta local comum já é suficiente. A partir dela, o atacante escreve em pseudo-arquivos especiais dentro do kernel. Esses arquivos ficam no caminho /sys/kernel/security/apparmor/. Por meio deles, é possível carregar, substituir ou remover perfis de segurança sem autorização.
A falha é classificada como “confused deputy”. O termo descreve uma situação em que um componente do sistema age em nome de outro sem perceber que está sendo manipulado.
É como um invasor convencer o gerente de um prédio, que tem a chave mestra, a abrir cofres restritos que o invasor jamais poderia acessar sozinho. O AppArmor, nesse caso, executa ações maliciosas por acreditar que recebeu instruções legítimas.
O que um invasor pode fazer
As consequências variam e podem ser devastadoras. O invasor pode escalar seus privilégios até o nível mais alto de privilégios no sistema, o root.
No nível do espaço de usuário, o ataque envolve ferramentas comuns do sistema. O invasor carrega um perfil que bloqueia uma capacidade específica do comando sudo. Em seguida, manipula uma variável de ambiente chamada MAIL_CONFIG. Isso faz com que o sudo envie um e-mail como root usando o Postfix. O resultado é a obtenção de um shell com privilégios totais.
No nível do kernel, a exploração é ainda mais profunda. Uma falha do tipo use-after-free no componente aa_loaddata permite realocar uma página de memória liberada. Essa página pode ser usada para sobrescrever o arquivo /etc/passwd diretamente.
Esse arquivo é onde o Linux armazena as senhas de todos os usuários do sistema. Com isso, o invasor reescreve a senha do root para um valor que ele mesmo escolheu. Em seguida, usa o comando su, que permite trocar de usuário dentro do terminal, e entra no sistema com controle total.
Além da escalada de privilégios, o invasor pode travar o sistema inteiro. Perfis com subperfis muito profundos fazem o kernel entrar em loop recursivo durante a remoção. Esse processo esgota a pilha do kernel, que tem cerca de 16 KB em sistemas x86-64. O esgotamento causa um kernel panic e reinicialização forçada. Uma hierarquia de apenas 1024 subperfis já é suficiente para provocar a queda do sistema.
O atacante também pode bloquear serviços críticos. Carregar um perfil de “negar tudo” contra o SSH, por exemplo, impede qualquer acesso remoto legítimo. Remover perfis de serviços como rsyslogd ou cupsd elimina proteções contra atacantes externos.
Há ainda a possibilidade de vazar endereços da memória do kernel, o que quebra uma proteção importante chamada KASLR. Isso abre caminho para ataques remotos ainda mais sofisticados.
Por fim, o invasor pode escapar de contêineres. Ao carregar um perfil específico para o binário /usr/bin/time, usuários sem privilégios conseguem criar namespaces de usuário com capacidades completas. Isso contorna diretamente as restrições que o Ubuntu aplica para limitar o uso de namespaces.
Quem está em risco
Os sistemas afetados vão muito além de computadores pessoais. Infraestruturas corporativas, plataformas de nuvem, ambientes Kubernetes e dispositivos IoT estão todos na lista. As falhas existem no kernel desde a versão 4.11, lançada em 2017. Isso significa quase oito anos de exposição silenciosa.
A Qualys chegou ao número de 12,6 milhões de sistemas afetados por meio de sua ferramenta de gestão de ativos de cibersegurança. A empresa confirmou que seus próprios produtos e plataformas foram verificados e não estão vulneráveis.
Contexto geopolítico
O tipo de dano que o CrackArmor pode causar se encaixa no perfil de operações conduzidas por grupos patrocinados por estados. Esses grupos costumam priorizar destruição em vez de espionagem.
A CISA e o Departamento de Segurança Interna dos Estados Unidos já emitiram alertas para os setores de energia, saúde, água e defesa. O CrackArmor reduz drasticamente o esforço necessário para causar danos graves em infraestruturas críticas.
O que as empresas estão fazendo
A Qualys, empresa responsável pela descoberta, desenvolveu provas de conceito que demonstram os ataques em toda a cadeia de exploração. O código não foi publicado para não facilitar o trabalho de criminosos.
A divulgação foi feita de forma coordenada com as equipes de segurança da Ubuntu, Canonical, Debian, SUSE e com mantenedores do sudo, ao longo de vários meses.
Nenhum identificador CVE foi atribuído até agora. Isso acontece porque o processo de catalogação oficial só é concluído após a correção ser incorporada ao kernel estável, geralmente uma ou duas semanas depois. A Qualys alertou que a ausência de um número CVE não deve ser interpretada como sinal de baixo risco.
“O CrackArmor prova que até mesmo as proteções mais consolidadas podem ser contornadas sem credenciais de administrador”, afirmou Dilip Bachwani, CTO da Qualys. “Para os responsáveis pela segurança das empresas, aplicar correções não é suficiente. É preciso reexaminar toda a suposição do que configurações padrão significam para a infraestrutura.”
O que fazer agora
A recomendação das equipes de segurança inclui aplicar as atualizações de kernel disponibilizadas pelos fornecedores é o primeiro passo. Verificar quais sistemas ainda estão vulneráveis é o segundo.
Monitorar o diretório /sys/kernel/security/apparmor/ em busca de modificações suspeitas completa o conjunto mínimo de ações necessárias também é uma boa prática. Ambientes com contêineres e clusters Kubernetes merecem atenção redobrada.
Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.