Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/freeipa-pentesting.md

20 KiB
Raw Blame History

Pentesting de FreeIPA

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Esta información fue tomada de los posts:

Información Básica

Es una alternativa de código abierto a Microsoft Windows Active Directory, utilizada principalmente como una solución de gestión integrada para entornos Unix. Al igual que Active Directory, FreeIPA implementa una infraestructura completa de directorio LDAP respaldada por un Centro de Distribución de Claves Kerberos del MIT. Utiliza el Sistema de Certificados Dogtag para la gestión de certificados de CA & RA, lo que le permite manejar autenticación multifactor, incluyendo tarjetas inteligentes. SSSD se utiliza para integrar FreeIPA en el proceso de autenticación estándar de Unix.

Huellas Digitales

Archivos & Variables de Entorno

  • /etc/krb5.conf: El archivo krb5.conf contiene la información del cliente Kerberos necesaria para estar inscrito en el dominio. Esto incluye las ubicaciones de los KDCs y servidores admin para los reinos Kerberos de interés, valores predeterminados para el reino actual y para aplicaciones Kerberos, y mapeos de nombres de host a reinos Kerberos.
  • /etc/ipa/default.conf: Este es el archivo de configuración predeterminado para servidores IPA, se utiliza para establecer valores predeterminados a nivel de sistema que se aplicarán al ejecutar clientes y servidores IPA.
  • /etc/krb5.keytab: El archivo krb5.keytab es necesario en todos los hosts dentro del dominio. Es requerido como parte del proceso de autenticación al KDC.
  • KRB5CCNAME: Si está establecido, esta variable apunta a la ubicación del Ticket CCACHE que se utilizará para la autenticación.
  • KRB5_KTNAME: Si está establecido, esta variable apunta a la ubicación del archivo Keytab que se utilizará para la autenticación.
  • KRB5_CONFIG: Si está establecido, esta variable apunta a la ubicación del archivo de configuración Kerberos.
  • KRB5_KDC_PROFILE: Si está establecido, esta variable apunta a la ubicación del archivo de configuración del KDC, que contiene directivas de configuración adicionales para el daemon del Centro de Distribución de Claves.
  • KRB5RCACHETYPE: Esta variable especifica el tipo predeterminado de caché de repetición que se utilizará para los servidores.
  • KRB5RCACHEDIR: Esta variable especifica el directorio predeterminado para las cachés de repetición utilizadas por los servidores.
  • KRB5_TRACE: Esta variable especifica un nombre de archivo para escribir la salida del registro de seguimiento. Los registros de seguimiento pueden ayudar a iluminar las decisiones tomadas internamente por las bibliotecas Kerberos.
  • KRB5_CLIENT_KTNAME: Esta variable establece el nombre del archivo keytab del cliente predeterminado.
  • KPROP_PORT: Esta variable establece el puerto predeterminado para kprop.

Binarios

  • ipa: Este binario es el estándar para gestionar un dominio FreeIPA. Se puede utilizar para gestionar hosts, usuarios, reglas de sudo y mucho más.
  • kdestroy: El binario kdestroy se utiliza para destruir cualquier ticket Kerberos actual en la sesión del usuario.
  • kinit: El binario kinit se utiliza para establecer o renovar tickets Kerberos.
  • klist: El binario klist lista cualquier ticket Kerberos en uso actualmente, y a qué principios proporcionan acceso los tickets.
  • kpasswd: El comando kpasswd se utiliza para cambiar la contraseña de un principal Kerberos. kpasswd primero solicita la contraseña actual de Kerberos, luego pide al usuario dos veces la nueva contraseña, y se cambia la contraseña.
  • ksu: Ksu se puede utilizar como una alternativa al binario su, para cambiar el contexto de usuario actual.
  • kswitch: El comando kswitch cambiará la caché de credenciales en uso actualmente.
  • kvno: El binario kvno adquiere un ticket de servicio para los principales Kerberos especificados e imprime los números de versión de clave de cada uno.

Red

Así es como podría verse un servidor FreeIPA:

Autenticación

Dado que FreeIPA utiliza Kerberos para la autenticación, este proceso es muy similar a la autenticación en Active Directory. Para acceder a recursos en el dominio, un usuario debe tener un ticket Kerberos válido para ese recurso. Estos tickets pueden almacenarse en diferentes ubicaciones basadas en la configuración del dominio FreeIPA.

Archivos de Ticket CCACHE

Cuando se establece que los tickets se almacenarán como un archivo en disco, el formato y tipo estándar es un archivo CCACHE. Este es un formato de archivo binario simple para almacenar credenciales Kerberos. Estos archivos generalmente se almacenan en /tmp y tienen permisos 600. Desde la perspectiva de un atacante, esto es importante por las siguientes razones:

  1. Los tickets válidos pueden ser utilizados para autenticarse, sin necesidad de la contraseña en texto plano del usuario respectivo.
  2. Los tickets CCACHE son altamente portátiles. Pueden descargarse y cargarse en otro host sin necesidad de renovar o validar el ticket.

Analizar un Ticket CCACHE se puede lograr fácilmente de varias maneras diferentes. El método más simple es analizarlo con el binario klist.

klist /tmp/krb5cc_0

Para un atacante, reutilizar un Ticket CCACHE es muy fácil. Para reutilizar un Ticket CCACHE válido, exporte KRB5CCNAME al camino del archivo de ticket válido. El sistema debería reconocer la variable de entorno e intentará usar ese material de credencial al interactuar con el dominio.

export KRB5CCNAME=/tmp/krb5cc_0
klist

Unix Keyring

Los Tickets CCACHE también pueden ser almacenados en el keyring de Linux. El keyring reside dentro del kernel y ofrece a los administradores más control sobre la recuperación y uso de los tickets almacenados. Los tickets pueden ser delimitados de las siguientes maneras diferentes:

  • KEYRING:name: Los tickets están delimitados a un Keyring nombrado específico.
  • KEYRING:process:name: Los tickets están delimitados a un id de proceso específico.
  • KEYRING:thread:name: Los tickets están delimitados a un hilo específico.
  • KEYRING:session:name: Los tickets están delimitados a una sesión de usuario específica.
  • KEYRING:persistent:uidnumber: Los tickets están delimitados a un usuario específico independientemente de la sesión (por defecto).

Dependiendo de cómo el administrador haya delimitado el ticket almacenado dentro del keyring de Unix, extraerlo puede ser difícil. Sin embargo, el alcance predeterminado para los Tickets CCACHE en el keyring de Unix es KEYRING:persistent:uidnumber. Afortunadamente, si estás en el contexto del usuario, klist puede analizar esta información para nosotros.

Como atacante, reutilizar un Ticket CCACHE almacenado en el keyring de Unix es bastante difícil dependiendo de cómo esté delimitado el ticket. Afortunadamente @Zer1t0 de @Tarlogic ha creado una herramienta que puede extraer tickets de Kerberos del keyring de Unix. La herramienta se llama Tickey y se puede encontrar aquí.

Keytab

{% hint style="warning" %} generalmente, cada host se despliega con una credencial keytab para ese host que puede ser utilizada para obtener un Ticket Granting Ticket (TGT) válido del Credential Cache (CCACHE) para el propio host. {% endhint %}

Consiste en pares de principales de Kerberos y claves encriptadas que se derivan de la contraseña de Kerberos asociada con el principal. Dado que estas claves se derivan de la contraseña del principal, si esa contraseña cambia el keytab será invalidado.

Los archivos keytab pueden ser utilizados para obtener un ticket granting ticket (TGT) válido para el principal al que están delimitados. Este proceso de autenticación no requiere la contraseña, ya que contiene claves derivadas de la contraseña.

Analizar un archivo keytab es muy fácil y se puede lograr de varias maneras. La forma más fácil de analizar un archivo keytab es con klist. La segunda manera utiliza una excelente utilidad de python que Cody Thomas ha creado. Su proyecto KeytabParser analizará el principal y sus claves encriptadas relevantes.

Los atacantes pueden reutilizar credenciales almacenadas en archivos keytab generando un Ticket CCACHE a través del binario kinit.

# Parse keytab
klist -k /rtc/krb5.keytab

# Get TGT
kinit -kt /etc/krb5.keytab host/bastion.westeros.local@WESTEROS.LOCAL

Cheatsheet

Puedes encontrar más información sobre cómo usar tickets en linux en el siguiente enlace:

{% content-ref url="privilege-escalation/linux-active-directory.md" %} linux-active-directory.md {% endcontent-ref %}

Enumeración

{% hint style="warning" %} Podrías realizar la enumeración a través de ldap y otras herramientas binarias, o conectándote a la página web en el puerto 443 del servidor FreeIPA. {% endhint %}

Hosts, Usuarios y Grupos

Es posible crear hosts, usuarios y grupos. Los hosts y usuarios se organizan en contenedores llamados “Host Groups” y “User Groups” respectivamente. Estos son similares a las Unidades Organizativas (OU).

Por defecto en FreeIPA, el servidor LDAP permite enlaces anónimos, y una gran cantidad de datos son enumerables sin autenticación. Esto puede enumerar todos los datos disponibles sin autenticación:

ldapsearch -x

Para obtener más información necesitas usar una sesión autenticada (consulta la sección de Autenticación para aprender cómo preparar una sesión autenticada).

# Get all users of domain
ldapsearch -Y gssapi -b "cn=users,cn=compat,dc=domain_name,dc=local"

# Get users groups
ldapsearch -Y gssapi -b "cn=groups,cn=accounts,dc=domain_name,dc=local"

# Get all the hosts
ldapsearch -Y gssapi -b "cn=computers,cn=accounts,dc=domain_name,dc=local"

# Get hosts groups
ldapsearch -Y gssapi -b "cn=hostgroups,cn=accounts,dc=domain_name,dc=local"

Desde una máquina unida al dominio podrás usar binarios instalados para enumerar el dominio:

ipa user-find
ipa usergroup-find
ipa host-find
ipa host-group-find

-------------------

ipa user-show <username> --all
ipa usergroup-show <user group> --all
ipa host-find <host> --all
ipa hostgroup-show <host group> --all

{% hint style="info" %} El usuario admin de FreeIPA es el equivalente a domain admins de AD. {% endhint %}

Hashes

El usuario root del servidor IPA tiene acceso a los hashes de contraseñas.

  • El hash de la contraseña de un usuario se almacena como base64 en el atributo “userPassword”. Este hash podría ser SSHA512 (versiones antiguas de FreeIPA) o PBKDF2_SHA256.
  • El Nthash de la contraseña se almacena como base64 en “ipaNTHash” si el sistema tiene integración con AD.

Para descifrar estos hashes:

• Si FreeIPA está integrado con AD, ipaNTHash es fácil de descifrar: Debes decodificar base64 -> recodificarlo como hex ASCII -> John The Ripper o hashcat pueden ayudarte a descifrarlo rápidamente

• Si se utiliza una versión antigua de FreeIPA, por lo que se usa SSHA512: Debes decodificar base64 -> encontrar el hash SSHA512 -> John The Ripper o hashcat pueden ayudarte a descifrarlo

• Si se utiliza una versión nueva de FreeIPA, por lo que se usa PBKDF2_SHA256: Debes decodificar base64 -> encontrar PBKDF2_SHA256 -> su longitud es de 256 bytes. John puede trabajar con 256 bits (32 bytes) -> SHA-256 se utiliza como la función pseudoaleatoria, el tamaño de bloque es de 32 bytes -> puedes usar solo los primeros 256 bits de nuestro hash PBKDF2_SHA256 -> John The Ripper o hashcat pueden ayudarte a descifrarlo

Para extraer los hashes necesitas ser root en el servidor FreeIPA, allí puedes usar la herramienta dbscan para extraerlos:

Reglas HBAC

Estas son las reglas que otorgan permisos específicos a usuarios o hosts sobre recursos (hosts, servicios, grupos de servicios...).

# Enumerate using ldap
ldapsearch -Y gssapi -b "cn=hbac,dc=domain_name,dc=local"
# Using ipa
ipa hbacrule-find
# Show info of rule
ipa hbacrule-show <hbacrule> --all

Reglas de Sudo

FreeIPA ofrece la capacidad de administrar permisos de sudo desde una fuente centralizada a través de reglas de sudo. Estos conjuntos de reglas se pueden utilizar para restringir o delegar la capacidad de ejecutar comandos como sudo en hosts inscritos en el dominio. Como atacantes, podemos enumerar a qué hosts y usuarios se aplican estos conjuntos de reglas y qué comandos están permitidos a través del conjunto de reglas.

# Enumerate using ldap
ldapsearch -Y gssapi -b "cn=sudorules,cn=sudo,dc=domain_name,dc=local"
# Using ipa
ipa sudorule-find
# Show info of rule
ipa sudorule-show <sudorule> --all

Control de Acceso Basado en Roles

Cada rol contiene un conjunto de privilegios, y esos respectivos privilegios contienen un conjunto de permisos. Los roles pueden ser aplicados a Usuarios, Grupos de Usuarios, Hosts, Grupos de Hosts y Servicios. Para ilustrar este concepto, discutamos el rol predeterminado de "Administrador de Usuarios" en FreeIPA.

Como muestra la captura de pantalla anterior, el rol de “Administrador de Usuarios” contiene los siguientes privilegios:

  • Administradores de Usuarios
  • Administradores de Grupos
  • Administradores de Usuarios en Etapa

Podemos profundizar aún más y enumerar los permisos delegados a cada privilegio:

Como podemos ver, el rol de “Administrador de Usuarios” contiene bastantes permisos dentro del entorno. Comprender el concepto general y la estructura de roles, privilegios y permisos puede ser crítico para identificar caminos de ataque a lo largo de un entorno.

# Using ldap
ldapsearch -Y gssapi -b "cn=roles,cn=accounts,dc=westeros,dc=local"
# Using ipa binary
ipa role-find
ipa role-show <role> --all
ipa privilege-find
ipa privilege-show <privilege> --all
ipa permission-find
ipa permission-show <permission> --all

Ejemplo de Escenario de Ataque

En https://posts.specterops.io/attacking-freeipa-part-iii-finding-a-path-677405b5b95e puedes encontrar un ejemplo simple de cómo abusar de algunos permisos para comprometer el dominio.

Linikatz/LinikatzV2

Escalada de Privilegios

creación de usuario root

{% hint style="warning" %} Si puedes crear un nuevo usuario con el nombre root, puedes suplantar su identidad y serás capaz de conectarte por SSH a cualquier máquina como root.

ESTO HA SIDO CORREGIDO. {% endhint %}

El privilegio "Administradores de Usuarios" es muy poderoso (como su nombre indica):

Con este privilegio viene una gran cantidad de poder para afectar a usuarios dentro del entorno. Usando este privilegio podemos crear un nuevo usuario dentro del dominio FreeIPA llamado _root_.

Una vez que el usuario está creado en el dominio, podemos obtener un ticket para la cuenta con _kinit_.

Ahora podemos intentar conectarnos por SSH usando nuestra recién creada cuenta de dominio root.

Como se muestra, ¡esto conduce al usuario a la cuenta local de root! Así que simplemente creando un usuario de dominio para un usuario local, pudimos autenticarnos usando la cuenta root@WESTEROS.LOCAL y obtener el contexto de usuario de la cuenta local de root.

Para más detalles sobre esta vulnerabilidad, consulta https://posts.specterops.io/attacking-freeipa-part-iv-cve-2020-10747-7c373a1bf66b\

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: