El equipo detrás de la biblioteca criptográfica de código abierto ampliamente utilizada OpenSSL ha parcheado dos vulnerabilidades en el servicio que anteriormente había tomado la medida un tanto inusual de advertir previamente a los equipos de seguridad.
OpenSSL emitió un aviso a fines de octubre, diciendo que se estaba preparando para parchear una vulnerabilidad crítica, que habría sido la primera vulnerabilidad crítica revelada en la biblioteca desde Heartbleed.
Los recuerdos de Heartbleed llevaron a muchos a sospechar de un problema de importancia similar, pero en el evento, la revelación pasó sin causar un pánico generalizado, y el estado crítico inicial de la vulnerabilidad se redujo a alto.
La actualización de OpenSSL 3.0.6 a OpenSSL 3.0.7 corrige dos vulnerabilidades distintas de desbordamiento de búfer en las funciones de decodificación de Punycode. Estas vulnerabilidades se rastrean como CVE-2022-3602 y CVE-2022-3786 respectivamente.
CVE-2022-3602 permite que se active un desbordamiento de búfer durante el análisis de un certificado de seguridad de la capa de transporte (TLS) X.509 después de que se valide. Esto se debe a cómo se procesa Punycode al verificar los certificados.
Puede explotarse si un atacante puede crear con éxito una dirección de correo electrónico maliciosa para desbordar cuatro bytes controlados por el atacante en la pila, por lo que un atacante debe, por lo tanto, tener acceso a un certificado confiable para llevar a cabo un ataque exitoso. Explotado con éxito, puede provocar un bloqueo que cause la denegación de servicio y, potencialmente, la ejecución remota de código (RCE).
CVE-2022-3786 difiere ligeramente en que un atacante solo puede explotarlo creando una dirección de correo electrónico maliciosa para desbordar una cantidad arbitraria de bytes que contienen el carácter de punto. Explotado con éxito, puede provocar un bloqueo que provoque la denegación de servicio.
Yotam Perkal, director de investigación de vulnerabilidades en Rezilion, especialista en remediación de vulnerabilidades de software, dijo: “Teniendo en cuenta todos los factores, parece que la explotación de estas vulnerabilidades en la naturaleza para lograr la ejecución del código no es muy probable. Dicho esto, la explotación es posible y, por lo tanto, se recomienda identificar y parchear los activos vulnerables lo antes posible”.
El director de investigación de Rapid7, Tod Beardsley, agregó: “Estas divulgaciones de vulnerabilidades de OpenSSL, y las correcciones, no son, afortunadamente, tan malas como todas las especulaciones nos habrían hecho creer.
“Los proveedores y operadores deben actualizar sus dependencias en OpenSSL a 3.0.7 cuando sea práctico hacerlo, respetando los procedimientos normales de control de cambios y teniendo en cuenta el perfil de riesgo específico de esas organizaciones. Para la mayoría de las personas, esta no es realmente la situación de emergencia que todos esperábamos”.
Aquellos que deberían acelerar la actualización probablemente serán aquellos que ejecutan implementaciones de OpenSSL que se han configurado para autenticación mutua, donde tanto el cliente como el servidor proporcionan certificados proporcionados por OpenSSL para la autenticación, explicó Beardsley.
El investigador principal de seguridad de Cycode, Alex Ilgayev, dijo que a pesar de la degradación, habría muchas organizaciones que aún deberían tratar estas vulnerabilidades como críticas. “OpenSSL cita el uso de protecciones de desbordamiento de pila en el software moderno como una razón para la degradación. Sin embargo, muchas aplicaciones críticas no son modernas, como las que ejecutan cajeros automáticos, servicios públicos y otras infraestructuras críticas”, dijo.
Ilgayev explicó que, en última instancia, la conclusión más importante de este incidente para los profesionales de seguridad es la necesidad de mantener una lista de materiales de software (SBOM) completa y mantenida. “El parche OpenSSL 3.0.7 demuestra estos dos puntos debido a la ubicuidad de OpenSSL”, dijo.
“Las organizaciones sin SBOM han estado luchando para identificar el uso vulnerable de OpenSSL desde el anuncio de la semana pasada. Este es un problema de priorización que la mayoría de las organizaciones aparentemente estarían preparadas para resolver. Sin embargo, obtener la aceptación interfuncional para priorizar cualquier cosa que no sea inmediatamente urgente sigue siendo un desafío para la mayoría de los equipos de seguridad de aplicaciones”.
Pero los profesionales de la seguridad harían bien en considerar ir más allá de los SBOM para considerar un enfoque de lista de materiales (PBOM), ya que la ubicuidad de OpenSSL significa que se usa ampliamente no solo en el código fuente de una aplicación, sino también en la infraestructura utilizada para construirlo y entregarlo, dijo Ilgayev.
Los PBOM amplían el concepto de SBOM para reflejar mejor cómo se usan las dependencias en la actualidad, teniendo en cuenta el código de terceros que podría provocar una infracción, incluso si no está presente en la propia aplicación, y dónde se implementan realmente las dependencias en los entornos de tiempo de ejecución.
“Deberíamos tratar este ejercicio con seriedad para perforar agujeros y encontrar debilidades en nuestros SBOM y PBOM, ya que la historia reciente (Heartbleed, Struts, Jackson-databind, LodDash Log4Shell, Log4Text, etc.) demuestra que siempre hay otra dependencia importante en el horizonte, ”, dijo Ilgayev.