Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2025-47827 — PoC e informe de vulnerabilidad para CVE-2025-47827. | Kitploit
Herramientas/GitHubGitHub/zedeldi/cve-2025-47827
Escalada de PrivilegiosMecanismos de PersistenciaAnálisis de VulnerabilidadesExplotaciónEvasión de IDS/IPSPost-ExplotaciónSeguridad de HardwarePapers e InvestigaciónAprendizaje y EducaciónAnálisis de FirmwareExplotación de Binarios
4214hace 10 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
GitHubzedeldi/cve-2025-47827

CVE-2025-47827

PoC e informe de vulnerabilidad para CVE-2025-47827.

Ver RepositorioSitio web

CVE-2025-47827

GitHub license GitHub last commit CVSS-8.4 CWE-347 CVE-2025-47827 ISN-2025-22 GHSA-pww7-j9v6-xc6j

Prueba de concepto e informe de vulnerabilidad para CVE-2025-47827.

Contenido

  • Descripción
  • Divulgación
  • Impacto
  • Detección
  • Mitigación
  • Binarios
  • Prueba de concepto
  • Recursos

Descripción

En IGEL OS anterior a v11, Secure Boot puede ser eludido porque el módulo igel-flash-driver verifica incorrectamente una firma criptográfica. En última instancia, se puede montar un sistema de archivos raíz manipulado desde una imagen SquashFS no verificada.

La verificación incorrecta de la firma criptográfica en el módulo del kernel de Linux igel-flash-driver en IGEL OS 10 permite que un actor malicioso eluda Secure Boot, arrancando el shim firmado por Microsoft 3rd Party UEFI CA, que luego carga GRUB y el kernel vulnerable, ambos firmados por IGEL Secure Boot Signing CA. Una vez que se ha cargado el kernel vulnerable y el initramfs integrado, se puede montar un sistema de archivos raíz malicioso desde la imagen SquashFS no verificada en el disco.

Como la llamada al sistema kexec_load está disponible en el kernel vulnerable, el kernel actualmente arrancado puede ser reemplazado por uno completamente no confiable, permitiendo prácticamente que cualquier sistema operativo arranque, siguiendo una cadena completa de confianza.

En versiones posteriores de IGEL OS, el módulo verifica correctamente la firma de la imagen SquashFS del sistema de archivos raíz. Sin embargo, tanto el kernel vulnerable como las versiones parcheadas están firmados con el mismo certificado, lo que permite que el mismo shim arranque tanto versiones vulnerables como parcheadas.

Proceso

Diagrama de proceso de arranque

Clasificación

La cadena vectorial inicial para CVE-2025-47827 fue AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, obteniendo una puntuación CVSS de 8.4 (alta).

El 14 de octubre de 2025, esto se cambió a AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, reduciendo la puntuación a 4.6 (media).

Además, la debilidad original se definió como CWE-347: Verificación incorrecta de firma criptográfica, pero MSRC le ha asignado CWE-324: Uso de una clave después de su fecha de expiración.

Divulgación

Tanto IGEL como Microsoft fueron contactados e informados sobre esta vulnerabilidad, el 6 de diciembre de 2024 y el 31 de marzo de 2025 respectivamente, antes de que los detalles se hicieran públicos el 29 de mayo de 2025.

Como IGEL OS 10 no tiene soporte y la vulnerabilidad no existe directamente en el shim, ninguna de las partes ha sugerido una solución. Microsoft respondió con lo siguiente:

Tras la investigación, hemos determinado que este envío no cumple con la definición de vulnerabilidad de seguridad para mantenimiento, ya que IGEL OS v10 ya no tiene soporte y el problema está en el módulo del kernel, no en el shim. Solo el shim está firmado por el certificado de MSFT.

IGEL publicó un aviso de seguridad para CVE-2025-47827 el 2 de junio de 2025.

El 13 de junio de 2025, reporté esto nuevamente a Microsoft y recibí la siguiente respuesta:

Aunque su informe incluía información útil, no cumple con el requisito de Microsoft como vulnerabilidad de seguridad para mantenimiento. El problema reportado está en el módulo del kernel y no en el shim, y solo el shim está firmado por el certificado de MSFT. kexec ya permite eludir Secure Boot por diseño (Ref: kexec Command Line in Linux - Linux Expert Better 2025).

Esto cumpliría con los criterios de mantenimiento de MSRC si el problema estuviera en un controlador/componente de arranque. Esta es una vulnerabilidad en el controlador del kernel de la distribución de Linux. Esto ocurre después de UEFI "ExitBootServices", lo que significa que no es una elusión de Secure Boot. El usuario solo tiene ejecución de código a nivel de SO, no de arranque.

Desde la publicación de varios artículos de noticias sobre esta vulnerabilidad, los mantenedores de shim se pusieron en contacto con Microsoft e IGEL para discutir una solución.

Después de que se alcanzó una solución, creé otro caso en MSRC el 20 de octubre de 2025, preguntando por la razón detrás de la demora en revocar estos shims, modificaciones a la cadena vectorial CVSS y CWE, y por qué su guía de actualización indicaba que la vulnerabilidad no se había divulgado públicamente. Recibí la siguiente respuesta:

La vulnerabilidad de IGEL que se corrigió no es una elusión de Secure Boot. Es una elusión de integridad del kernel específica de Linux y no afecta a Windows. Los shims de IGEL son antiguos y no admiten la nueva revocación basada en SBAT. Por lo tanto, Microsoft emitió las revocaciones para protegerse contra posibles exploits de otras vulnerabilidades que han sido protegidas por SBAT.

Jeffrey Sutherland, Principal Lead Program Manager, respondió en el PR para explicar que, debido a la falta de SBAT, los shims tuvieron que ser revocados por DBX, e IGEL solicitó tiempo adicional para evitar consecuencias no deseadas. También se disculparon por no mantener la comunicación entre el investigador y las partes involucradas, según lo requerido por Divulgación Coordinada de Vulnerabilidades.

Impacto

Una explotación de elusión de Secure Boot podría llevar al desarrollo de un bootkit/rootkit a nivel de kernel no detectado, lo que a su vez conlleva múltiples implicaciones, como:

  • Ejecución de código
  • Escalada de privilegios
  • Denegación de servicio
  • Fuga de información

Sin revocación o intervención manual, Secure Boot ha quedado inutilizado en todas las máquinas que confían en Microsoft 3rd Party UEFI CA, que es el valor predeterminado para la mayoría de los dispositivos al momento de escribir esto.

Kexec

Descargar herramienta