Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/freeipa-pentesting.md
carlospolop 466ebcbb16 f
2023-06-05 20:30:03 +02:00

21 KiB
Raw Blame History

Pentesting de FreeIPA

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Esta información fue tomada de los siguientes posts:

Información básica

Es una alternativa de código abierto al Active Directory de Microsoft Windows, utilizada principalmente como 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 de Kerberos del MIT. Utiliza el sistema de certificados Dogtag para la gestión de certificados de CA y RA, lo que le permite manejar la autenticación de multi-factor, incluyendo tarjetas inteligentes. SSSD se utiliza para integrar FreeIPA en el proceso de autenticación estándar de Unix.

Huellas

Archivos y variables de entorno

  • /etc/krb5.conf: El archivo krb5.conf contiene la información del cliente Kerberos requerida para inscribirse en el dominio. Esto incluye las ubicaciones de los KDC y los servidores de administración para los reinos de Kerberos de interés, los valores predeterminados para el reino actual y para las aplicaciones de Kerberos, y los mapeos de nombres de host en los reinos de Kerberos.
  • /etc/ipa/default.conf: Este es el archivo de configuración predeterminado para los servidores IPA, se utiliza para establecer valores predeterminados en todo el sistema que se aplicarán al ejecutar clientes y servidores IPA.
  • /etc/krb5.keytab: El archivo krb5.keytab es obligatorio en todos los hosts dentro del dominio. Es necesario como parte del proceso de autenticación al KDC.
  • KRB5CCNAME: Si se establece, esta variable apunta a la ubicación del archivo CCACHE Ticket que se utilizará para la autenticación.
  • KRB5_KTNAME: Si se establece, esta variable apunta a la ubicación del archivo Keytab que se utilizará para la autenticación.
  • KRB5_CONFIG: Si se establece, esta variable apunta a la ubicación del archivo de configuración de Kerberos.
  • KRB5_KDC_PROFILE: Si se establece, esta variable apunta a la ubicación del archivo de configuración de 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 de registro de seguimiento. Los registros de seguimiento pueden ayudar a iluminar las decisiones tomadas internamente por las bibliotecas de Kerberos.
  • KRB5_CLIENT_KTNAME: Esta variable establece el nombre del archivo de keytab del cliente predeterminado.
  • KPROP_PORT: Esta variable establece el puerto predeterminado para kprop.

Binarios

  • ipa: Este binario es el estándar para administrar un dominio FreeIPA. Se puede utilizar para administrar 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 enumera cualquier ticket Kerberos actual en uso, y a qué principios proporcionan acceso los tickets.
  • kpasswd: El comando kpasswd se utiliza para cambiar la contraseña de un principal Kerberos. kpasswd solicita primero la contraseña actual de Kerberos, luego solicita 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 cambia la caché de credenciales actual en uso.
  • 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 los recursos del dominio, un usuario debe tener un ticket Kerberos válido para ese recurso. Estos tickets pueden almacenarse en diferentes ubicaciones según la configuración del dominio FreeIPA.

Archivos de tickets CCACHE

Cuando los tickets se establecen para ser almacenados 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 de Kerberos. Estos archivos se suelen almacenar en /tmp y se limitan con permisos 600. Desde la perspectiva de un atacante, esto es importante por las siguientes razones:

  1. Los tickets válidos se pueden utilizar para autenticarse, sin necesidad de la contraseña en texto plano del usuario correspondiente.
  2. Los tickets CCACHE son altamente portátiles. Se pueden descargar y cargar en otro host sin necesidad de renovar o validar el ticket.

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

klist /tmp/krb5cc_0

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

export KRB5CCNAME=/tmp/krb5cc_0
klist

Unix Keyring

Los tickets CCACHE también se pueden almacenar en el keyring de Linux. El keyring vive dentro del kernel, y da 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:

  • KEYRING:nombre: Los tickets están delimitados a un keyring específico.
  • KEYRING:proceso:nombre: Los tickets están delimitados a un proceso id específico.
  • KEYRING:hilo:nombre: Los tickets están delimitados a un hilo específico.
  • KEYRING:sessión:nombre: 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 delimitó el ticket almacenado dentro del Unix keyring, puede ser difícil analizarlo. Sin embargo, el alcance predeterminado para los tickets CCACHE en el Unix keyring es KEYRING:persistent:uidnumber. Afortunadamente, si estás en el contexto del usuario, klist puede analizar esta información por nosotros.

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

Keytab

{% hint style="warning" %} Por lo general, cada host se despliega con una credencial de keytab para ese host que se puede usar para obtener un Ticket Granting Ticket (TGT) de caché de credenciales (CCACHE) válido para el propio host. {% endhint %}

Consiste en pares de principales Kerberos y claves cifradas 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 quedará invalidado.

Los archivos de keytab se pueden usar para obtener un TGT válido para el principal al que está delimitado. Este proceso de autenticación no requiere la contraseña, ya que contiene claves derivadas de la contraseña.

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

Los atacantes pueden reutilizar credenciales almacenadas en archivos de 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

Hoja de trucos

Puede 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" %} Se puede realizar la enumeración a través de ldap y otras herramientas binarias, o conectándose 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 clasifican en contenedores llamados "Grupos de Hosts" y "Grupos de Usuarios" 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 se pueden enumerar 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 (revisa 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 utilizar 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 equivalente a los administradores de dominio de AD. {% endhint %}

Hashes

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

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

Para crackear estos hashes:

• Si FreeIPA está integrado con AD, ipaNTHash es fácil de crackear: debes decodificar base64 -> volver a codificarlo como ASCII hex -> John The Ripper o hashcat pueden ayudarte a crackearlo rápidamente.

• Si se utiliza una versión antigua de FreeIPA, se utiliza SSHA512: debes decodificar base64 -> encontrar el hash SSHA512 -> John The Ripper o hashcat pueden ayudarte a crackearlo.

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

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 proporciona la capacidad de administrar permisos de sudo desde una fuente centralizada a través de las 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 atacante, podemos enumerar en qué hosts y usuarios se aplican estos conjuntos de reglas y qué comandos se permiten a través de las 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 de 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 rutas de ataque en todo 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 se puede encontrar un ejemplo simple de cómo abusar de algunos permisos para comprometer el dominio.

Linikatz

https://github.com/CiscoCXSecurity/linikatz

Escalada de Privilegios

Creación de usuario root

{% hint style="warning" %} Si puedes crear un nuevo usuario con el nombre root, puedes hacerse pasar por él y podrás SSH en cualquier máquina como root.

ESTO HA SIDO PARCHADO. {% endhint %}

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

Con este privilegio viene mucho poder diferente para afectar a los usuarios dentro del entorno. Usando este privilegio podemos crear un nuevo usuario dentro del dominio FreeIPA llamado _root._

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

Ahora podemos intentar SSH usando nuestra nueva cuenta de dominio root.

Como se muestra, esto deja al usuario en la cuenta root local. 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 root local.

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥