AppArmor
WhiteIntel é um mecanismo de busca alimentado pela dark web que oferece funcionalidades gratuitas para verificar se uma empresa ou seus clientes foram comprometidos por malwares de roubo.
O principal objetivo do WhiteIntel é combater a apropriação de contas e ataques de ransomware resultantes de malwares que roubam informações.
Você pode verificar o site deles e experimentar o mecanismo gratuitamente em:
Informação Básica
AppArmor é um aperfeiçoamento do kernel projetado para restringir os recursos disponíveis para programas por meio de perfis por programa, implementando efetivamente o Controle de Acesso Obrigatório (MAC) vinculando atributos de controle de acesso diretamente aos programas em vez de aos usuários. Esse 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 perfis do AppArmor:
Modo de Execuçã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 por meio de sistemas como syslog ou auditd.
Modo de Reclamação: Ao contrário do modo de execuçã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.
Componentes do AppArmor
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: São programas em modo de usuário que fornecem uma interface para interagir e gerenciar o AppArmor.
Caminho dos Perfis
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ê substituir o caractere "/" por um ponto do caminho de cada binário listado, obterá o nome do perfil do apparmor dentro da pasta mencionada.
Por exemplo, um perfil apparmor para /usr/bin/man estará localizado em /etc/apparmor.d/usr.bin.man
Comandos
Criando um perfil
Para indicar o executável afetado, são permitidos caminhos absolutos e curingas (para expansão 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 (leitura)
w (escrita)
m (mapeamento de memória como executável)
k (bloqueio de arquivo)
l (criação de links rígidos)
ix (para 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} (adicionar #include <tunables/global> ao arquivo de perfil)
Regras de negação são suportadas para substituir regras de permissão.
aa-genprof
Para começar a criar um perfil facilmente, o apparmor pode ajudar. É possível fazer o apparmor inspecionar as ações realizadas por um binário e depois permitir que você decida quais ações deseja permitir ou negar. Basta executar:
Em seguida, em um console diferente, execute todas as ações que o binário costuma executar:
Em seguida, na primeira console pressione "s" e depois nas ações gravadas indique se deseja ignorar, permitir ou o que for. 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/outra ação
aa-easyprof
Você também pode criar um modelo de perfil apparmor de um binário com:
Note que por padrão, em um perfil criado, nada é permitido, ou seja, 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 aplicar o novo perfil com
Modificando um perfil a partir de logs
A seguinte ferramenta 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
Gerenciando um Perfil
Registos
Exemplo de registos AUDIT e DENIED do ficheiro /var/log/audit/audit.log do executável service_bin
:
Você também pode obter essas informações usando:
Apparmor no Docker
Observe como o perfil docker-profile do docker é carregado por padrão:
Por padrão, o perfil Apparmor docker-default é 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 de base, ou seja, #include <abstractions/base>)
Gravação em qualquer arquivo /proc não é permitida
Outros subdiretórios/arquivos de /proc e /sys têm acesso de leitura/gravação/bloqueio/link/execução negado
Montagem não é permitida
Ptrace só pode ser executado em um processo que está confinado pelo mesmo perfil apparmor
Uma vez que você executa um contêiner docker, você deve ver a seguinte saída:
Note que o apparmor até mesmo bloqueará privilégios de capacidades concedidos ao contêiner por padrão. Por exemplo, ele será capaz de bloquear a permissão de escrever dentro de /proc mesmo se a capacidade SYS_ADMIN for concedida porque por padrão o perfil apparmor do docker nega esse acesso:
Você precisa desativar o apparmor para ignorar suas restrições:
Note que por padrão 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 capacidadeSYS_ADMIN
--cap-add=ALL
dá todas as capacidades--cap-drop=ALL --cap-add=SYS_PTRACE
remove todas as capacidades e dá apenasSYS_PTRACE
Normalmente, 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 ocorre porque o apparmor do docker estará impedindo.
Exemplo
(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, obtemos um erro ao tentar alterar "/etc/" pois o perfil do AppArmor está impedindo o acesso de escrita ao "/etc".
Bypass do Docker do AppArmor1
Você pode descobrir qual perfil do apparmor está sendo executado por um contêiner usando:
Em seguida, você pode executar a seguinte linha para encontrar o perfil exato sendo usado:
Bypass do Docker AppArmor
No caso estranho em que você pode modificar o perfil do apparmor do docker e recarregá-lo, você poderia remover as restrições e "burlá-las".
Bypass do AppArmor
O AppArmor é baseado em caminho, isso significa que mesmo que ele esteja 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 será mais protegido pelo AppArmor.
Bypass do Shebang do AppArmor
Neste bug você pode ver um exemplo de como mesmo que você esteja impedindo o perl de ser executado com certos recursos, se você simplesmente criar um script de shell especificando na primeira linha #!/usr/bin/perl
e você executar o arquivo diretamente, você será capaz de executar o que quiser. Por exemplo:
WhiteIntel é um mecanismo de busca alimentado pela dark web que oferece funcionalidades gratuitas para verificar se uma empresa ou seus clientes foram comprometidos por malwares stealers.
O principal objetivo do WhiteIntel é combater tomadas de conta e ataques de ransomware resultantes de malwares que roubam informações.
Você pode acessar o site deles e experimentar o mecanismo gratuitamente em:
Last updated