OpenSSL es una biblioteca de software de código abierto ampliamente utilizada para implementar comunicaciones seguras a través de redes informáticas. ¿Qué tan ampliamente se usa? Bueno, lo más probable es que si alguna vez accediste a una página web HTTPS, lo hiciste a través de un cifrado OpenSSL. La biblioteca proporciona funciones criptográficas y protocolos para el cifrado, descifrado, autenticación y verificación de firmas digitales de datos. OpenSSL se puede encontrar casi en cualquier lugar donde sea necesario proteger servidores web, servidores de correo electrónico, redes privadas virtuales (VPN) y otros tipos de comunicación de red.
Al observar el párrafo anterior, debería quedar claro lo importante que es OpenSSL para el correcto funcionamiento de Internet. Es un componente crítico de la infraestructura de seguridad para muchos sistemas y aplicaciones informáticas. Ayuda a proteger los datos confidenciales del acceso no autorizado y ayuda a garantizar la integridad y autenticidad de las comunicaciones de la red. Es por eso que los mantenedores de la biblioteca se toman muy en serio las vulnerabilidades e intentan parchearlas lo antes posible. Es casi impensable imaginar que los atacantes obtengan acceso a las líneas de comunicación seguras de la infraestructura de la World Wide Web.
En este artículo, examinaremos las vulnerabilidades que provocaron el parche 3.0.7 de OpenSSL en octubre de 2022 y veremos qué podemos aprender de la forma en que los mantenedores de OpenSSL solucionaron el problema.
Las vulnerabilidades
El 25 de octubre de 2022, el Proyecto OpenSSL publicó un asesor advirtiendo que pronto llegará un nuevo parche para abordar algunos crítico vulnerabilidades. La etiqueta "crítica" implica que es probable que las vulnerabilidades sean explotables y que es probable el robo de claves privadas y/o RCE en los servidores afectados.
Una semana después, el 1 de noviembre de 2022, el Proyecto OpenSSL lanzó el nuevo parche, 3.0.7, y el vulnerabilidades específicas pretendían arreglar. Mientras tanto, la calificación de las vulnerabilidades se ha rebajado de crítica a "alta gravedad".
Entonces, ¿cuáles son estas vulnerabilidades?
CVE-2022-3602 – Desbordamiento del búfer de 509 bytes de dirección de correo electrónico X.4: en la verificación de certificados X.509, específicamente en la verificación de restricciones de nombre, puede ocurrir un desbordamiento del búfer de cuatro bytes. Un atacante que utilice una dirección de correo electrónico maliciosa puede desbordar cuatro bytes de la pila controlados por un atacante. Este desbordamiento del búfer podría provocar un bloqueo (que resulte en una denegación de servicio) o una ejecución potencialmente remota de código. Inicialmente, se clasificó como crítico, pero pruebas adicionales mostraron que numerosas plataformas utilizan protecciones de desbordamiento de pila para reducir el riesgo de ejecución remota de código.
CVE-2022-3786 – Desbordamiento del búfer de longitud variable de dirección de correo electrónico X.509: en la verificación de certificados X.509, específicamente en la verificación de restricciones de nombre, puede ocurrir un desbordamiento del búfer. Un atacante puede crear una dirección de correo electrónico maliciosa en un certificado para llenar la pila con cualquier cantidad de bytes que contengan el carácter ".", que es el número decimal 46. Podría ocurrir una falla como resultado de este desbordamiento del búfer (provocando un negación de servicio).
Sólo para reiterar cuán graves son estas vulnerabilidades.ies son, CISA, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU., publicó un asesor el mismo día que OpenSSL, animamosinvitar a los usuarios y administradores a revisar Documentación de OpenSSL y actualización, cuando corresponda, al nuevo parche 3.0.7.
Como se mencionó anteriormente, RCE (ejecución remota de código) en sistemas operativos o servidores de correo que ejecutan OpenSSL sería muy malo, por lo que tiene sentido revelar solo el vulnerabilidades una vez que se ha encontrado y ofrecido un parche adecuado.
¿Qué sucede después?
Tan pronto como se publicó el aviso inicial, la gente empezó a luchar. "Que no cunda el pánico" era una frase común en el momento mostrando cuán en serio la gente tomó la noticia de que OpenSSL tiene aspectos críticos vulnerabilidades.
Tan pronto como se publicó el aviso, todas las partes interesadas relevantes se esforzaron por descubrir qué versión de OpenSSL se usaba en su servidor, sistema operativo, aplicación, paquete, etc. Más allá del uso interno de OpenSSL, las personas también necesitaban averiguar si alguno de sus terceros Los proveedores de terceros o de servicios estaban utilizando una versión vulnerable de OpenSSL. En ese momento, si no estaba seguro de qué versión estaba usando o no estaba seguro de qué versión estaban usando sus proveedores y proveedores de servicios, se consideraba más seguro desconectar una aplicación en lugar de arriesgarse a un posible RCE.
Dado que el aviso dio el cronograma para el parche por adelantado, eso le dio a las personas tiempo para descubrir su propia infraestructura y la de sus proveedores y proveedores de servicios. La idea era planificar todo lo necesario en términos de infraestructura involucrada para que tan pronto como se lanzara el parche, se pudiera realizar la actualización, si fuera necesario.
¿Cómo lo manejarías?
Ahora digamos que usted es ingeniero en una empresa que, hasta donde usted sabe, utiliza OpenSSL en sus servidores. Tan pronto como aparezca el aviso, deberá determinar qué versión de la biblioteca está en uso y dónde (incluido cualquier código heredado si todavía se está ejecutando) y luego calcular lo mismo para cualquiera de sus proveedores o proveedores de servicios.
Aquí es donde un SBOM realmente podría ser útil. Un SBOM significa Lista de materiales de software y es una lista de todos los componentes y dependencias de software que componen un producto de software en particular. Un SBOM generalmente incluye información como los nombres y versiones de todos los componentes de software (vea adónde voy con esto), sus fuentes y licencias, y cualquier vulnerabilidad conocida o problema de seguridad asociado con cada componente.
Si usted, como ingeniero responsable que es, se aseguró de tener un SBOM actualizado para cada uno de sus productos, encontrar dónde estaba usando OpenSSL y qué versión estaba en uso habría sido una simple cuestión de ejecutar una búsqueda en el archivo SBOM. . Si también se aseguró de solicitar SBOM actualizados a cualquier proveedor o proveedor de servicios con el que estuviera trabajando su empresa, también podría haber realizado la misma búsqueda allí.
Como le dijeron que las vulnerabilidades solo afectaban a las versiones entre 3.0.0 y 3.0.6, todo lo que tiene que hacer es verificar qué versiones estaba ejecutando para saber qué aplicaciones debían eliminarse o actualizarse con el nuevo parche: 3.0.7. XNUMX.
Solo para mostrar cuán extensa es la lista de sistemas operativos y aplicaciones empresariales conocidos que utilizan OpenSSL, consulte esto lista publicado como un servicio público para que la gente supiera lo preocupadas que deberían estar.
¿Cómo puede ayudar un centro de seguridad basado en evidencia?
Como parte del cambiante panorama de la ciberseguridad, incluidas las de gran alcance vulnerabilidades, actualmente estamos presenciando la evolución de la seguridad de aplicaciones a la seguridad de la cadena de suministro de software. Se ha desarrollado una nueva generación de herramientas y tecnologías para intentar solucionar estos problemas. Al ofrecer una plataforma de garantía continua de seguridad de código basada en evidencia que puede garantizar la confiabilidad del ciclo de vida del desarrollo de software y de los componentes de software, las herramientas y soluciones automatizadas ayudan a las organizaciones a lograr un nuevo nivel de seguridad. El mapeo continuo de dependencias y vulnerabilidades hace que sea más sencillo remediar o aplicar parches cuando estén disponibles.
Escriba es un centro de seguridad de la cadena de suministro de software. Reúne pruebas y las presenta para cada compilación que pasa por su proceso de CI/CD. El objetivo de la solución de Scribe era facilitar el cumplimiento de las regulaciones y mejores prácticas de la UE y EE. UU. para mejorar la transparencia del software y fomentar la confianza entre los desarrolladores y los usuarios de software. La plataforma permite crear y compartir SBOM completos, así como otros conocimientos de seguridad. Además, la plataforma puede confirmar que la compilación que está viendo cumple con los requisitos del marco SSDF del NIST y del nivel 3 de SLSA. Ya no tendrás que buscar a tientas tratando de averiguar dónde estás usando qué versión de qué biblioteca porque tienes un almacén de evidencia con un SBOM para cada una de tus compilaciones. Ahora, descubrirlo es tan sencillo como buscar una frase concreta en un documento de texto.
Una última palabra: prepárese para la próxima gran divulgación de vulnerabilidades
La historia del proyecto OpenSSL sobre el parche 3.0.7 nos ofrece dos puntos de vista igualmente importantes sobre cómo abordar vulnerabilidades potencialmente críticas.
Desde el lado afectado, la empresa o proyecto que potencialmente se vio comprometido por estas vulnerabilidades, hemos informado con transparencia. No revelan inmediatamente información que pueda causar daño, pero sí revelan todo lo que pueden tan pronto como se dan cuenta de un problema. No solo eso, también ofrecen un cronograma para la solución, además de la mayor cantidad de información posible sobre el problema. Una vez que existe un parche o una solución, no tuvieron reparos en revelar exactamente qué estaba mal y cómo podría explotarse. Este tipo de transparencia fomenta la confianza. Los usuarios y clientes quieren saber y sentir que la empresa se preocupa más por ellos, o al menos tanto, como por sus resultados o por su consejo de administración.
En 2014, el proyecto OpenSSL fue víctima de un error crítico denominado 'sangrar': una falla crítica en la implementación TLS/DTLS de OpenSSL que hizo posible que un atacante obtuviera secretos como material de clave de cifrado, contraseñas y otra información confidencial de los servidores afectados. Heartbleed mostró lo que puede hacer una vulnerabilidad crítica en OpenSSL, ya que afecta a una amplia variedad de programas y distribuciones de Linux. Intentar identificar y reparar cada sistema vulnerable les dio a los equipos de seguridad meses de dolores de cabeza. Implementar una herramienta, como un SBOM, que podría agilizar y simplificar la actualización y parcheo de su software sería una gran ayuda para el equipo de ciberseguridad de cualquier empresa.
Desde el punto de vista de la remediación, saber exactamente con qué tiene que trabajar, qué versión de qué paquetes está utilizando y dónde es esencial para poder manejar cualquier emergencia potencial. Tomando Log4J como ejemplo, algunas empresas todavía están tratando de determinar si están afectadas o no por esta vulnerabilidad más de un año después de su descubrimiento.
El hecho de que no solo deba preocuparse por su software y sus servidores, sino también por los de cualquier proveedor externo que esté utilizando o cualquier proveedor de servicios con el que esté trabajando, incluso usando conexiones API, significa que nosotros, todos de nosotros, realmente necesitamos construir una red de confianza entre nosotros. Esa confianza debería depender en la medida de lo posible de pruebas contundentes. Cree y realice un seguimiento de sus propios SBOM y de los de cualquier empresa con la que tenga negocios, comparta esos SBOM y muestre buena fe al anunciar y corregir cualquier vulnerabilidad explotable de la que tenga conocimiento.
Se necesitaría que todos trabajemos juntos para llegar a un mundo en el que compartir dicha evidencia sea tan común como compartir las últimas relaciones públicas de la empresa en las redes sociales. Sin esta confianza, simplemente estamos preparando el escenario para que la próxima gran vulnerabilidad crítica rompa la infraestructura interconectada que todos trabajamos tan duro para mantener.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
