Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Cadena de vulnerabilidades en FreeIPA permite que clientes anónimos creen credenciales de administrador reutilizables


Red Hat informó sobre una vulnerabilidad crítica en FreeIPA que, combinada con un fallo en 389 Directory Server, permite a usuarios no autenticados crear identidades de Kerberos y obtener privilegios de administrador. También se detectó un fallo separado en el comando idp-add que podría exponer variables de entorno, incluyendo contraseñas en instalaciones de contenedores. Se recomienda actualizar a FreeIPA 4.13.4 o restringir el acceso al servicio LDAP como medida temporal.





Red Hat afirma que un fallo en FreeIPA permite que un cliente que nunca haya iniciado sesión cree una identidad de Kerberos a su elección en el directorio y termine en el grupo de administradores.

FreeIPA es el sistema que determina quién puede iniciar sesión en un dominio Linux y mantiene todas las identidades en una base de datos 389 Directory Server a la que se accede a través de LDAP. El ataque requiere un segundo fallo en ese software de base de datos.

El proyecto FreeIPA ya ha solucionado su parte en la versión 4.13.4 [https://www.freeipa.org/release-notes/4-13-4.html]. Red Hat dice que reprodujo la cadena dos veces en una instalación predeterminada, la última vez en una máquina sin ningún tipo de acceso.

Red Hat rastrea el fallo de FreeIPA como CVE-2026-76578 [https://access.redhat.com/security/cve/CVE-2026-76578] y lo califica como crítico, con una puntuación CVSS de 9.8. La misma página indica que esa puntuación es preliminar y está sujeta a revisión.

Red Hat distribuye FreeIPA como su producto de Gestión de Identidades, donde el paquete se llama ipa.

FreeIPA incluye una regla de control de acceso, llamada ACI, que permite a un usuario gestionar su propio token de contraseña de un solo uso. La regla no requiere que el cliente haya iniciado sesión, ni limita qué más se puede escribir junto al token.

Eso solo se vuelve peligroso debido al segundo fallo. 389 Directory Server tiene un tipo de regla destinada a decir "solo el propietario autenticado de esta entrada". Compara el nombre del cliente con un valor almacenado como texto plano, y un cliente que no ha iniciado sesión tiene un nombre vacío, que coincide con un valor almacenado vacío.

Por lo tanto, un cliente anónimo puede crear una entrada de token dejando en blanco los campos de propiedad, pasar la comprobación de propiedad al ser "nadie", y escribir una identidad y contraseña de Kerberos junto a ella.

Red Hat califica el fallo del servidor de directorios, CVE-2026-76560 [https://access.redhat.com/security/cve/CVE-2026-76560], en 7.5, y afirma que Red Hat Directory Server no incluye ninguna regla de ese tipo por defecto. Por sí solo, el fallo solo importa donde una implementación haya escrito dicha regla.

FreeIPA es una de esas implementaciones. Su regla predeterminada es exactamente de esa forma, razón por la cual la cadena funciona contra una instalación intacta. Esa conexión es nuestra interpretación de dos avisos que describen las mitades por separado.

Red Hat también reprodujo el defecto del servidor de directorios por su cuenta, en una compilación simple de 389-ds sin partes de FreeIPA instaladas, y una prueba de control utilizando un valor que no estaba vacío fue rechazada correctamente. Eso sitúa el defecto en el motor de control de acceso más que en cualquier cosa que haga FreeIPA.

La técnica informada primero a Red Hat suplantaba la cuenta de administrador real creando un nombre de Kerberos que coincidía con ella. Una corrección anterior para CVE-2026-13097 bloqueó esa colisión pero dejó en su lugar la escritura no autenticada subyacente. El ataque ahora funciona bajo un nombre que el atacante elige en su lugar, dice Red Hat, "alcanzando el mismo resultado práctico".

Ese fallo anterior, corregido en FreeIPA 4.13.3 [https://www.freeipa.org/release-notes/4-13-3.html], era un problema diferente. La comprobación de que los nombres de Kerberos fueran únicos no permitía diferentes formas de escribir el mismo nombre, lo que permitía a un usuario con acceso de escritura crear una identidad de servicio que suplantaba una privilegiada existente.

Los dos proyectos describen el resultado de manera diferente. Red Hat lo llama membresía genuina en el grupo de administradores y credenciales de administrador reutilizables.

El proyecto FreeIPA lo plantea de forma más restringida, afirmando que la identidad inyectada no debe existir ya, que la corrección de CVE-2026-13097 evita que se tomen cuentas existentes, y que el ataque "puede ser utilizado como un trampolín" hacia privilegios administrativos.

Red Hat dice que ejecutó la cadena contra una imagen de contenedor de FreeIPA estándar que ejecutaba la versión 4.13.1 y comprobó los resultados con comandos estándar exclusivos de administrador en lugar de confiar en la salida del exploit. Ninguno de los avisos o informes de errores [https://bugzilla.redhat.com/show_bug.cgi?id=2519522] describe que el fallo haya sido utilizado en un ataque real.

Para implementaciones que utilizan identificadores de seguridad estilo Windows, Red Hat dice que el atacante también puede obtener un ticket de Kerberos que contiene datos de autorización, extendiendo así el acceso a los servicios HTTP y Dogtag del servidor. Dogtag es la autoridad de certificación integrada de FreeIPA.


Un segundo fallo independiente



Red Hat reveló un segundo fallo de FreeIPA junto a estos, CVE-2026-79678 [https://access.redhat.com/security/cve/CVE-2026-79678], que no tiene nada que ver con la cadena anterior. Califica este como importante, con una puntuación de 8.1.

El comando idp-add pasa dos valores que el llamador suministra, un nombre de organización y una URL base, a una llamada Python eval(). Esa llamada se ejecuta antes de la comprobación de permisos destinada a limitar el comando a los administradores del proveedor de identidad, por lo que cualquier cuenta en el servidor puede acceder a ella, independientemente de sus privilegios.

La llamada está limitada por un patrón que prohíbe los corchetes, lo que impide que se llame a cualquier función. Red Hat dice que "no es posible la ejecución de código".

Lo que un atacante puede hacer es leer las variables de entorno del proceso del servidor una por una observando el error que devuelve el servidor, y agotar la memoria del servidor con una expresión aritmética corta.

Cuán importante es esto depende de cómo se haya instalado FreeIPA, dice Red Hat. En una instalación normal basada en paquetes, el entorno del proceso contiene solo rutas y configuraciones documentadas. Las instalaciones en contenedores son diferentes.

La imagen oficial del servidor FreeIPA a menudo toma las contraseñas del Director Manager y del administrador como variables de entorno en el primer arranque, y esas contraseñas podrían quedar expuestas si permanecen después de que finalice la configuración.

Red Hat acredita a Gia Bui de Calif por informar la cadena de FreeIPA y el fallo del servidor de directorios, y acredita a Calif trabajando con Anthropic por el fallo de idp-add.


Qué pueden hacer los administradores ahora



La solución ha llegado a tres lugares diferentes en tres momentos distintos, por lo que la respuesta depende de qué pieza de software estés parcheando.

Componente | Qué instalar | Estado al comprobar
FreeIPA, del proyecto | FreeIPA 4.13.4 | Soluciona ambos fallos de FreeIPA. Las notas de lanzamiento no tienen fecha y no dicen qué versiones anteriores están afectadas.
389-ds-base en Red Hat Enterprise Linux y Red Hat Directory Server | El aviso para tu versión | Se publicaron catorce avisos el 8 de septiembre entre las 01:56 y las 05:07 UTC, enumerados en el registro de errores de 389-ds [https://bugzilla.redhat.com/show_bug.cgi?id=2519521]. RHSA-2026:64785 [https://access.redhat.com/errata/RHSA-2026:64785] cubre Red Hat Enterprise Linux 10 con 389-ds-base-3.2.0-10.el10_2. El aviso está calificado como crítico y cubre otros cuatro fallos de 389-ds además de este.
Paquetes ipa en Red Hat Enterprise Linux | Aún no listado | Los registros de errores de Red Hat para ambos fallos de FreeIPA no mostraban versión corregida ni aviso cuando fueron comprobados el 8 de septiembre.
389-ds-base en Fedora | Actualización aún en pruebas | El rastreador de Fedora estaba marcado como ON_QA cuando se comprobó el 8 de septiembre.

No apareció ningún aviso para Red Hat Enterprise Linux 9 simple en esa lista de catorce. Eso es lo que mostraba el registro de errores el 8 de septiembre, no una declaración de que la versión no vaya a tener corrección.

Hasta que haya un paquete corregido disponible, Red Hat sugiere dos pasos temporales para la cadena:

1. Restringe el acceso al servicio LDAP (normalmente los puertos 389 y 636) a hosts en los que confíes, utilizando reglas de firewall o segmentación de red.
2. Desactivar los binds LDAP anónimos bloquea este camino particular, dice Red Hat, pero comprueba primero que nada más en tu implementación los necesite.

Para el fallo de idp-add, no existe tal opción. Red Hat dice que ninguna configuración mantiene a una cuenta autenticada ordinaria alejada de ese código, y que se requiere un paquete corregido. Añade que cualquiera que ejecute instalaciones en contenedores debe verificar que la contraseña establecida en el primer arranque ya no esté presente en el entorno del proceso en ejecución.

El material publicado deja dos preguntas sin respuesta. Ni Red Hat ni el proyecto FreeIPA dicen si las actualizaciones de 389-ds, por sí solas, detienen el ataque de FreeIPA en un servidor cuyos paquetes ipa siguen estando desactualizados.

Y ninguno dice si la aplicación de una corrección elimina una identidad que un atacante haya creado previamente, o qué debería buscar un administrador para averiguarlo.

Ni los avisos ni los informes de errores publican reglas de detección o indicadores.

Fuente:
THN

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.