AppArmor
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 es una mejora del kernel diseñada para restringir los recursos disponibles para los programas a través de perfiles por programa, implementando efectivamente el Control de Acceso Obligatorio (MAC) al vincular los atributos de control de acceso directamente a los programas en lugar de a los usuarios. Este sistema opera cargando perfiles en el kernel, generalmente durante el arranque, y estos perfiles dictan qué recursos puede acceder un programa, como conexiones de red, acceso a sockets en bruto y permisos de archivos.
Hay dos modos operativos para los perfiles de AppArmor:
Modo de Aplicación: Este modo aplica activamente las políticas definidas dentro del perfil, bloqueando acciones que violan estas políticas y registrando cualquier intento de infringirlas a través de sistemas como syslog o auditd.
Modo de Queja: A diferencia del modo de aplicación, el modo de queja no bloquea acciones que van en contra de las políticas del perfil. En su lugar, registra estos intentos como violaciones de políticas sin imponer restricciones.
Módulo del Kernel: Responsable de la aplicación de políticas.
Políticas: Especifican las reglas y restricciones para el comportamiento del programa y el acceso a recursos.
Analizador: Carga políticas en el kernel para su aplicación o reporte.
Utilidades: Estos son programas en modo usuario que proporcionan una interfaz para interactuar y gestionar AppArmor.
Los perfiles de AppArmor generalmente se guardan en /etc/apparmor.d/
Con sudo aa-status
podrás listar los binarios que están restringidos por algún perfil. Si puedes cambiar el carácter "/" por un punto en la ruta de cada binario listado, obtendrás el nombre del perfil de AppArmor dentro de la carpeta mencionada.
Por ejemplo, un perfil de apparmor para /usr/bin/man se ubicará en /etc/apparmor.d/usr.bin.man
Para indicar el ejecutable afectado, se permiten rutas absolutas y comodines para especificar archivos.
Para indicar el acceso que el binario tendrá sobre archivos, se pueden utilizar los siguientes controles de acceso:
r (leer)
w (escribir)
m (mapa de memoria como ejecutable)
k (bloqueo de archivos)
l (creación de enlaces duros)
ix (para ejecutar otro programa con la nueva política heredada)
Px (ejecutar bajo otro perfil, después de limpiar el entorno)
Cx (ejecutar bajo un perfil hijo, después de limpiar el entorno)
Ux (ejecutar sin restricciones, después de limpiar el entorno)
Se pueden definir variables en los perfiles y se pueden manipular desde fuera del perfil. Por ejemplo: @{PROC} y @{HOME} (agregar #include <tunables/global> al archivo del perfil)
Se admiten reglas de denegación para anular reglas de permiso.
Para comenzar a crear un perfil fácilmente, apparmor puede ayudarte. Es posible hacer que apparmor inspeccione las acciones realizadas por un binario y luego te permita decidir qué acciones deseas permitir o denegar. Solo necesitas ejecutar:
Luego, en una consola diferente, realiza todas las acciones que el binario normalmente realizará:
Luego, en la primera consola presiona "s" y luego en las acciones grabadas indica si deseas ignorar, permitir o lo que sea. Cuando hayas terminado presiona "f" y el nuevo perfil se creará en /etc/apparmor.d/path.to.binary
Usando las teclas de flecha puedes seleccionar lo que deseas permitir/negar/o lo que sea
También puedes crear una plantilla de un perfil de apparmor de un binario con:
Tenga en cuenta que por defecto en un perfil creado nada está permitido, por lo que todo está denegado. Necesitará agregar líneas como /etc/passwd r,
para permitir que el binario lea /etc/passwd
, por ejemplo.
Puede entonces hacer cumplir el nuevo perfil con
La siguiente herramienta leerá los registros y preguntará al usuario si desea permitir algunas de las acciones prohibidas detectadas:
Usando las teclas de flecha puedes seleccionar lo que deseas permitir/negar/cualquier cosa
Ejemplo de registros AUDIT y DENIED de /var/log/audit/audit.log del ejecutable service_bin
:
También puedes obtener esta información usando:
Nota cómo el perfil docker-profile de docker se carga por defecto:
Por defecto, el perfil docker-default de Apparmor se genera a partir de https://github.com/moby/moby/tree/master/profiles/apparmor
Resumen del perfil docker-default:
Acceso a toda la red
Ninguna capacidad está definida (Sin embargo, algunas capacidades provendrán de incluir reglas base básicas es decir, #include <abstractions/base>)
Escribir en cualquier archivo de /proc no está permitido
Otros subdirectorios/archivos de /proc y /sys tienen acceso de lectura/escritura/bloqueo/enlace/ejecución denegado
Montar no está permitido
Ptrace solo se puede ejecutar en un proceso que está confinado por el mismo perfil de apparmor
Una vez que ejecutes un contenedor docker, deberías ver la siguiente salida:
Note que apparmor incluso bloqueará los privilegios de capacidades otorgados al contenedor por defecto. Por ejemplo, podrá bloquear el permiso para escribir dentro de /proc incluso si se otorga la capacidad SYS_ADMIN porque por defecto el perfil de apparmor de docker niega este acceso:
Necesitas deshabilitar apparmor para eludir sus restricciones:
Note que por defecto AppArmor también prohibirá que el contenedor monte carpetas desde adentro incluso con la capacidad SYS_ADMIN.
Note que puede agregar/eliminar capacidades al contenedor de docker (esto seguirá estando restringido por métodos de protección como AppArmor y Seccomp):
--cap-add=SYS_ADMIN
da la capacidad SYS_ADMIN
--cap-add=ALL
da todas las capacidades
--cap-drop=ALL --cap-add=SYS_PTRACE
elimina todas las capacidades y solo da SYS_PTRACE
Usualmente, cuando encuentra que tiene una capacidad privilegiada disponible dentro de un contenedor docker pero alguna parte de la explotación no está funcionando, esto será porque apparmor de docker estará impidiendo.
(Ejemplo de aquí)
Para ilustrar la funcionalidad de AppArmor, creé un nuevo perfil de Docker “mydocker” con la siguiente línea añadida:
Para activar el perfil, necesitamos hacer lo siguiente:
Para listar los perfiles, podemos ejecutar el siguiente comando. El comando a continuación está listando mi nuevo perfil de AppArmor.
Como se muestra a continuación, obtenemos un error al intentar cambiar “/etc/” ya que el perfil de AppArmor está impidiendo el acceso de escritura a “/etc”.
Puedes encontrar qué perfil de apparmor está ejecutando un contenedor usando:
Luego, puedes ejecutar la siguiente línea para encontrar el perfil exacto que se está utilizando:
En el extraño caso de que puedas modificar el perfil de docker de apparmor y recargarlo. Podrías eliminar las restricciones y "eludirlas".
AppArmor es basado en rutas, esto significa que incluso si podría estar protegiendo archivos dentro de un directorio como /proc
, si puedes configurar cómo se va a ejecutar el contenedor, podrías montar el directorio proc del host dentro de /host/proc
y ya no estará protegido por AppArmor.
En este bug puedes ver un ejemplo de cómo incluso si estás impidiendo que perl se ejecute con ciertos recursos, si simplemente creas un script de shell especificando en la primera línea #!/usr/bin/perl
y ejecutas el archivo directamente, podrás ejecutar lo que quieras. Por ejemplo:
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)