Recientemente se han identificado vulnerabilidades críticas en la biblioteca ruby-saml, utilizadas en los procesos de autenticación, que afectan a todas las versiones hasta la 1.17.0. Estas fallas de seguridad, clasificadas como CVE-2025-25291 y CVE-2025-25292, permiten a atacantes con una firma válida, creada con la clave adecuada, formar sus propias afirmaciones SAML. Esto podría habilitar intentos de autenticación como cualquier usuario dentro de una organización, facilitando potenciales ataques de toma de control de cuentas.
Se insta a los usuarios de ruby-saml a actualizar a la versión 1.18.0 para mitigar estos riesgos. Asimismo, bibliotecas que dependan de ruby-saml, como omniauth-saml, deben ser actualizadas para referirse a la versión corregida. Aunque GitHub actualmente no utiliza ruby-saml, había considerado reintroducirla como biblioteca de código abierto para la autenticación SAML. No obstante, al descubrirse una instancia explotable en GitLab, GitHub tomó medidas proactivas para proteger a sus usuarios, alertando a sus desarrolladores sobre dicha vulnerabilidad.
En el pasado, GitHub utilizó ruby-saml hasta 2014, momento en el cual se decidió cambiar a su propia implementación de SAML para incluir características adicionales. Sin embargo, tras detectar vulnerabilidades en su implementación interna, la compañía reconsideró ruby-saml. En octubre de 2024, una significativa vulnerabilidad de bypass de autenticación (CVE-2024-45409) alentó una investigación más exhaustiva de su seguridad. GitHub lanzó entonces un programa de recompensas por errores, otorgando a investigadores seleccionados acceso a entornos de prueba que utilizaban ruby-saml para autenticación.
Durante la revisión del código, se observó que ruby-saml utilizaba dos analizadores XML: REXML y Nokogiri. Mientras que REXML es implementado en Ruby, Nokogiri ofrece una API más usabilidad. La interacción entre ambos podría conducir a una verificación incorrecta de firma, resultando en un bypass de autenticación, debido a cómo ambos interpretaban el mismo input de manera diferente.
Descubrir esta vulnerabilidad implicó varios pasos: reconocer el uso dual de analizadores, comprender cómo podría ser explotada esta discrepancia, identificar casos reales donde ocurrieron diferencias en interpretación, y finalmente, crear un exploit funcional. Estos hallazgos sugieren que atacantes podrían aprovechar esta falla para hacerse pasar por otro usuario utilizando una firma correcta.
Se aconseja revisar los registros de inicio de sesión para detectar actividades inusuales desde direcciones IP no habituales. La protección contra el uso malicioso de esta vulnerabilidad requiere no solo actualizaciones de las bibliotecas afectadas, sino también continuo monitoreo y gestión cuidadosa de su uso en desarrollos de software.
