coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6d2a959350
hacktricks/linux-unix/privilege-escalation/apparmor.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

10 KiB
Raw Blame History

Informações Básicas

AppArmor é um aprimoramento do kernel para confinar programas a um conjunto limitado de recursos com perfis por programa. Perfis podem permitir capacidades como acesso à rede, acesso a soquetes brutos e permissão para ler, gravar ou executar arquivos em caminhos correspondentes.

É um Controle de Acesso Obrigatório ou MAC que vincula atributos de controle de acesso a programas em vez de usuários.
O confinamento do AppArmor é fornecido por meio de perfis carregados no kernel, normalmente no boot.
Os perfis do AppArmor podem estar em um dos dois modos:

  • Execução: Perfis carregados em modo de execução resultarão na execução da política definida no perfil bem como na notificação de tentativas de violação da política (por meio de syslog ou auditd).
  • Reclamação: Perfis em modo de reclamação não executarão a política mas, em vez disso, notificarão tentativas de violação da política.

O AppArmor difere de alguns outros sistemas MAC no Linux: é baseado em caminho, permite a mistura de perfis de modo de execução e reclamação, usa arquivos de inclusão para facilitar o desenvolvimento e tem uma barreira muito menor de entrada do que outros sistemas MAC populares.

Partes do AppArmor

  • Módulo do kernel: Faz o trabalho real
  • Políticas: Define o comportamento e contenção
  • Analisador: Carrega as políticas no kernel
  • Utilitários: Programas de modo de usuário para interagir com 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 são restritos por algum perfil. Se você puder trocar 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 do apparmor para /usr/bin/man estará localizado em /etc/apparmor.d/usr.bin.man

Comandos

aa-status     #check the current status 
aa-enforce    #set profile to enforce mode (from disable or complain)
aa-complain   #set profile to complain mode (from diable or enforcement)
apparmor_parser #to load/reload an altered policy
aa-genprof    #generate a new profile
aa-logprof    #used to change the policy when the binary/program is changed
aa-mergeprof  #used to merge the policies

Criando um perfil

  • Para indicar o executável afetado, são permitidos caminhos absolutos e curingas (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 (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 com que o apparmor inspecione as ações executadas por um binário e, em seguida, permita que você decida quais ações deseja permitir ou negar.
Basta executar:

sudo aa-genprof /path/to/binary

Em seguida, em um console diferente, execute todas as ações que o binário normalmente executaria:

/path/to/binary -a dosomething

Então, na primeira console, pressione "s" e, em seguida, nas ações gravadas, indique se deseja ignorar, permitir ou qualquer outra coisa. Quando terminar, pressione "f" e o novo perfil será criado em /etc/apparmor.d/path.to.binary

{% hint style="info" %} Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/qualquer coisa. {% endhint %}

aa-easyprof

Você também pode criar um modelo de perfil apparmor de um binário com:

sudo aa-easyprof /path/to/binary
# vim:syntax=apparmor
# AppArmor policy for binary
# ###AUTHOR###
# ###COPYRIGHT###
# ###COMMENT###

#include <tunables/global>

# No template variables specified

"/path/to/binary" {
  #include <abstractions/base>

  # No abstractions specified

  # No policy groups specified

  # No read paths specified

  # No write paths specified
}

{% hint style="info" %} 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. {% endhint %}

Você pode então aplicar o novo perfil com

sudo apparmor_parser -a /etc/apparmor.d/path.to.binary

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:

sudo aa-logprof

{% hint style="info" %} Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/o que for necessário. {% endhint %}

Gerenciando um perfil

#Main profile management commands
apparmor_parser -a /etc/apparmor.d/profile.name #Load a new profile in enforce mode
apparmor_parser -C /etc/apparmor.d/profile.name #Load a new profile in complain mode
apparmor_parser -r /etc/apparmor.d/profile.name #Replace existing profile
apparmor_parser -R /etc/apparmor.d/profile.name #Remove profile

Registros

Exemplo de logs AUDIT e DENIED do executável service_bin no arquivo /var/log/audit/audit.log:

type=AVC msg=audit(1610061880.392:286): apparmor="AUDIT" operation="getattr" profile="/bin/rcat" name="/dev/pts/1" pid=954 comm="service_bin" requested_mask="r" fsuid=1000 ouid=1000
type=AVC msg=audit(1610061880.392:287): apparmor="DENIED" operation="open" profile="/bin/rcat" name="/etc/hosts" pid=954 comm="service_bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Você também pode obter essa informação usando:

sudo aa-notify -s 1 -v
Profile: /bin/service_bin
Operation: open
Name: /etc/passwd
Denied: r
Logfile: /var/log/audit/audit.log

Profile: /bin/service_bin
Operation: open
Name: /etc/hosts
Denied: r
Logfile: /var/log/audit/audit.log

AppArmor denials: 2 (since Wed Jan  6 23:51:08 2021)
For more information, please see: https://wiki.ubuntu.com/DebuggingApparmor

Apparmor no Docker

Observe como o perfil docker-profile do docker é carregado por padrão:

sudo aa-status
apparmor module is loaded.
50 profiles are loaded.
13 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/chromium-browser/chromium-browser//browser_java
   /usr/lib/chromium-browser/chromium-browser//browser_openjdk
   /usr/lib/chromium-browser/chromium-browser//sanitized_helper
   /usr/lib/connman/scripts/dhclient-script
   docker-default

Por padrão, o perfil do Apparmor docker-default é gerado a partir de https://github.com/moby/moby/tree/master/profiles/apparmor

Resumo do perfil docker-default:

  • Acesso a toda rede
  • Nenhuma capacidade é definida (No entanto, algumas capacidades virão da inclusão de regras básicas de base, ou seja, #include <abstractions/base>)
  • Gravar em qualquer arquivo /proc não é permitido
  • Outros subdiretórios/arquivos de /proc e /sys são negados acesso de leitura/escrita/bloqueio/link/execução
  • Montagem não é permitida
  • Ptrace só pode ser executado em um processo que está confinado pelo mesmo perfil apparmor

Depois de executar um contêiner docker, você deve ver a seguinte saída:

1 processes are in enforce mode.
   docker-default (825)

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 escrita dentro de /proc mesmo se a capacidade SYS_ADMIN for concedida porque, por padrão, o perfil apparmor do docker nega esse acesso:

docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined ubuntu /bin/bash
echo "" > /proc/stat
sh: 1: cannot create /proc/stat: Permission denied

Você precisa desativar o apparmor para contornar suas restrições:

docker run -it --cap-add SYS_ADMIN --security-opt seccomp=unconfined --security-opt apparmor=unconfined ubuntu /bin/bash

Observe que por padrão o AppArmor também proíbe o contêiner de montar pastas de dentro, mesmo com a capacidade SYS_ADMIN.

Observe 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

{% hint style="info" %} 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 ocorrerá porque o apparmor do docker estará impedindo. {% endhint %}

Fuga do AppArmor Docker

Você pode descobrir qual perfil apparmor está executando um contêiner usando:

docker inspect 9d622d73a614 | grep lowpriv
        "AppArmorProfile": "lowpriv",
                "apparmor=lowpriv"

Então, você pode executar a seguinte linha para encontrar o perfil exato sendo usado:

find /etc/apparmor.d/ -name "*lowpriv*" -maxdepth 1 2>/dev/null

No caso estranho em que você pode modificar o perfil do docker apparmor e recarregá-lo. Você pode remover as restrições e "burlá-las".