AppArmor
PreviousAbusing Docker Socket for Privilege EscalationNextAuthZ& AuthN - Docker Access Authorization Plugin
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor é uma melhoria do kernel projetada para restringir os recursos disponíveis para programas através de perfis por programa, implementando efetivamente o Controle de Acesso Mandatório (MAC) ao vincular atributos de controle de acesso diretamente a programas em vez de usuários. Este sistema opera carregando perfis no kernel, geralmente durante a inicialização, e esses perfis ditam quais recursos um programa pode acessar, como conexões de rede, acesso a soquetes brutos e permissões de arquivo.
Existem dois modos operacionais para os perfis do AppArmor:
Modo de Aplicação: Este modo aplica ativamente as políticas definidas dentro do perfil, bloqueando ações que violam essas políticas e registrando quaisquer tentativas de violá-las através de sistemas como syslog ou auditd.
Modo de Reclamação: Ao contrário do modo de aplicação, o modo de reclamação não bloqueia ações que vão contra as políticas do perfil. Em vez disso, registra essas tentativas como violações de política sem impor restrições.
Módulo do Kernel: Responsável pela aplicação das políticas.
Políticas: Especificam as regras e restrições para o comportamento do programa e acesso a recursos.
Analisador: Carrega políticas no kernel para aplicação ou relatório.
Utilitários: Estes são programas em modo usuário que fornecem uma interface para interagir e gerenciar o AppArmor.
Os perfis do AppArmor geralmente são salvos em /etc/apparmor.d/
Com sudo aa-status você poderá listar os binários que estão restritos por algum perfil. Se você puder trocar o caractere "/" por um ponto no caminho de cada binário listado, você obterá o nome do perfil do AppArmor dentro da pasta mencionada.
Por exemplo, um perfil do apparmor para /usr/bin/man estará localizado em /etc/apparmor.d/usr.bin.man
Para indicar o executável afetado, caminhos absolutos e curingas são permitidos (para globbing de arquivos) para especificar arquivos.
Para indicar o acesso que o binário terá sobre arquivos, os seguintes controles de acesso podem ser usados:
r (ler)
w (escrever)
m (mapa de memória como executável)
k (bloqueio de arquivo)
l (criação de links duros)
ix (executar outro programa com o novo programa herdando a política)
Px (executar sob outro perfil, após limpar o ambiente)
Cx (executar sob um perfil filho, após limpar o ambiente)
Ux (executar sem restrições, após limpar o ambiente)
Variáveis podem ser definidas nos perfis e podem ser manipuladas de fora do perfil. Por exemplo: @{PROC} e @{HOME} (adicione #include <tunables/global> ao arquivo de perfil)
Regras de negação são suportadas para substituir regras de permissão.
Para começar a criar um perfil facilmente, o apparmor pode ajudar você. É possível fazer o apparmor inspecionar as ações realizadas por um binário e então deixar você decidir quais ações deseja permitir ou negar. Você só precisa executar:
Então, em um console diferente, execute todas as ações que o binário geralmente realizará:
Então, na primeira console pressione "s" e depois nas ações gravadas indique se você deseja ignorar, permitir ou qualquer outra coisa. Quando terminar, pressione "f" e o novo perfil será criado em /etc/apparmor.d/path.to.binary
Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/qualquer outra coisa
Você também pode criar um template de um perfil apparmor de um binário com:
Observe que, por padrão, em um perfil criado, nada é permitido, então tudo é negado. Você precisará adicionar linhas como /etc/passwd r, para permitir a leitura do binário /etc/passwd, por exemplo.
Você pode então impor o novo perfil com
A ferramenta a seguir irá ler os logs e perguntar ao usuário se ele deseja permitir algumas das ações proibidas detectadas:
Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/o que for
Exemplo de logs AUDIT e DENIED de /var/log/audit/audit.log do executável service_bin:
Você também pode obter essas informações usando:
Note como o perfil docker-profile do docker é carregado por padrão:
Por padrão, o perfil docker-default do Apparmor é gerado a partir de https://github.com/moby/moby/tree/master/profiles/apparmor
Resumo do perfil docker-default:
Acesso a toda a rede
Nenhuma capacidade é definida (No entanto, algumas capacidades virão da inclusão de regras básicas, ou seja, #include <abstractions/base>)
Escrita em qualquer arquivo /proc não é permitida
Outros subdiretórios/arquivos de /proc e /sys têm acesso de leitura/escrita/bloqueio/link/executar negado
Montagem não é permitida
Ptrace só pode ser executado em um processo que está confinado pelo mesmo perfil apparmor
Uma vez que você execute um contêiner docker, você deve ver a seguinte saída:
Note que o apparmor até bloqueará privilégios de capacidades concedidos ao contêiner por padrão. Por exemplo, ele será capaz de bloquear a permissão para escrever dentro de /proc mesmo que a capacidade SYS_ADMIN seja concedida porque, por padrão, o perfil do apparmor do docker nega esse acesso:
Você precisa desativar o apparmor para contornar suas restrições:
Note que por padrão AppArmor também proibirá o contêiner de montar pastas de dentro, mesmo com a capacidade SYS_ADMIN.
Note que você pode adicionar/remover capacidades ao contêiner docker (isso ainda será restrito por métodos de proteção como AppArmor e Seccomp):
--cap-add=SYS_ADMIN dá a capacidade SYS_ADMIN
--cap-add=ALL dá todas as capacidades
--cap-drop=ALL --cap-add=SYS_PTRACE remove todas as capacidades e dá apenas SYS_PTRACE
Geralmente, quando você descobre que tem uma capacidade privilegiada disponível dentro de um contêiner docker, mas alguma parte do exploit não está funcionando, isso será porque o apparmor do docker estará impedindo.
(Exemplo de aqui)
Para ilustrar a funcionalidade do AppArmor, criei um novo perfil Docker “mydocker” com a seguinte linha adicionada:
Para ativar o perfil, precisamos fazer o seguinte:
Para listar os perfis, podemos executar o seguinte comando. O comando abaixo está listando meu novo perfil do AppArmor.
Como mostrado abaixo, recebemos um erro ao tentar mudar “/etc/” já que o perfil do AppArmor está impedindo o acesso de escrita a “/etc”.
Você pode descobrir qual perfil apparmor está executando um contêiner usando:
Então, você pode executar a seguinte linha para encontrar o perfil exato que está sendo usado:
No caso estranho de você poder modificar o perfil do apparmor do docker e recarregá-lo. Você poderia remover as restrições e "contorná-las".
AppArmor é baseado em caminho, isso significa que mesmo que ele possa estar protegendo arquivos dentro de um diretório como /proc, se você puder configurar como o contêiner será executado, você poderia montar o diretório proc do host dentro de /host/proc e ele não estará mais protegido pelo AppArmor.
Em este bug você pode ver um exemplo de como mesmo que você esteja impedindo que o perl seja executado com certos recursos, se você apenas criar um script shell especificando na primeira linha #!/usr/bin/perl e você executar o arquivo diretamente, você poderá executar o que quiser. Ex.:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
