La semana pasada, el equipo del proyecto OpenSSL anunció el lanzamiento de la versión 3.0.7 de OpenSSL, que estará disponible el martes 1 de noviembre. La actualización es una corrección de seguridad para una vulnerabilidad crítica en OpenSSL 3.0.x, y se insta a los desarrolladores y organizaciones a que se aseguren de parchear cualquier instancia de OpenSSL 3 en su pila de software con carácter de urgencia. La vulnerabilidad afecta a la versión 3.0.x y no afecta a OpenSSL 1.1.1 ni a LibreSSL.
Los usuarios tienen visibilidad instantánea de las versiones de OpenSSL en sus organizaciones.
¿Qué es OpenSSL?
OpenSSL es una biblioteca de criptografía de código abierto ampliamente utilizada por aplicaciones, sistemas operativos y sitios web para asegurar las comunicaciones a través de Internet utilizando SSL (Secure Sockets Layer) y TLS (Transport Layer Security). OpenSSL existe desde 2012, con la versión 3 publicada en septiembre de 2021, y es una de las bibliotecas de código abierto más utilizadas en todo el mundo.
¿Qué versiones de OpenSSL son vulnerables?
Las versiones 3.0.0 y superiores de OpenSSL son vulnerables al fallo de seguridad crítico, que se parchea en la versión 3.0.7. La mayoría de las implementaciones de OpenSSL que se utilizan hoy en día emplean la versión 1.1.1 o 1.0.2; sin embargo, OpenSSL 3 se incluye en muchas versiones de Linux, como RedHat, Fedora, CentOS, Linux Mint y otras.
Los contenedores Docker suelen incluir alguna versión de OpenSSL, pero qué versión y si es vulnerable dependerá de la configuración original. La biblioteca también puede instalarse opcionalmente en dispositivos macOS y Windows, aunque por defecto los Macs ejecutan la biblioteca LibreSSL, que no está afectada. Las versiones vulnerables de OpenSSL también se utilizan en software de desarrollo popular como Gradle, herramientas de privacidad como TOR y plataformas de seguridad como Kali Linux.
Vulnerable
OpenSSL 3.0.x
No vulnerable
OpenSSL 1.1.1
OpenSSL 1.1.0
OpenSSL 1.0.2
OpenSSL 1.0.1
LibreSSL
¿Cuál es el riesgo de la vulnerabilidad crítica de OpenSSL 3?
Aunque por el momento hay pocos detalles sobre la vulnerabilidad y aún no se ha asignado un CVE, el proyecto OpenSSL afirma que una vulnerabilidad crítica afecta a configuraciones comunes que probablemente puedan explotarse. Además, los fallos con una calificación de gravedad "crítica" incluyen aquellos que pueden ser fácilmente explotados de forma remota o en los que la ejecución remota de código se considera probable.
No es la primera vez que OpenSSL sufre una vulnerabilidad crítica. En 2014, se descubrió la CVE-2014-0160, apodada Heartbleed, en OpenSSL v1.0.1. Heartbleed se debía a una sobrelectura del búfer en la extensión TLS Heartbeat, que permitía leer más datos de los que debían permitirse. En la práctica, el fallo podía explotarse para obtener contraseñas o claves de cifrado.
A pesar de que el parche estaba disponible el mismo día en que se reveló el fallo, muchos tardaron en aplicarlo. El fallo se utilizó para comprometer una serie de sitios web y robar datos sensibles, incluidos los números de la seguridad social de los contribuyentes canadienses. Incluso 5 años después de la revelación inicial, se estimó que más de 90.000 servidores seguían siendo vulnerables a Heartbleed.
Cómo preparar y parchear la vulnerabilidad crítica de OpenSSL 3
Al igual que en el caso de Heartbleed, que se explotó rápidamente, las organizaciones deben asegurarse de dar prioridad a descubrir y parchear la vulnerabilidad crítica de OpenSSL tan pronto como esté disponible la actualización a la versión 3.0.7, lo que se estima que ocurrirá entre las 13.00 y las 17.00 horas UTC del martes 1 de noviembre.
Los usuarios pueden realizar consultas para determinar qué puntos finales están ejecutando versiones vulnerables de OpenSSL en la consola de gestión. Los clientes deben consultar la documentación KB aquí.
Hay otro pequeño resquicio de esperanza en esta oscura nube. Este nuevo agujero sólo afecta a las versiones 3.0.0 a 3.0.6 de OpenSSL. Por lo tanto, es probable que los sistemas operativos y dispositivos más antiguos eviten estos problemas. Por ejemplo, Red Hat Enterprise Linux (RHEL) 8.x y anteriores y Ubuntu 20.04 no se verán afectados por él. Sin embargo, RHEL 9.x y Ubuntu 22.04 son una historia diferente. Utilizan OpenSSL 3.x.
Si eres un usuario de Linux, puedes comprobar tu propio sistema ejecutando el comando shell
#openssl version
En la portatil de unos de nuestros editores de SomosLibres.org está ejecutando Debian Bullseye, que utiliza OpenSSL 1.1, así que esta máquina es buena.
Pero, si estás usando algo con OpenSSL 3.x en -- cualquier cosa -- prepárate para parchear el martes 1 de Noviembre. Es probable que este sea un mal agujero de seguridad, y los exploits no tardarán en llegar. Querrás hacer que tus sistemas sean seguros lo antes posible.
Conclusión y Recomendación
Las organizaciones y los equipos de TI pueden llegar a cansarse de los avisos de parches. El descubrimiento de vulnerabilidades está en su punto más alto, y a pesar de la evidencia de que los atacantes explotan rutinariamente los defectos en el software y los sistemas operativos populares, la gestión de parches no siempre recibe el tiempo y los recursos que debería.
Aun así, una vulnerabilidad crítica en una biblioteca de software como OpenSSL, de uso tan generalizado y tan fundamental para la seguridad de los datos en Internet, es algo que ninguna organización puede permitirse pasar por alto o retrasar, como muchos aprendieron tras el fallo Heartbleed.
A medida que surjan más detalles en los próximos días, Estar atentos al anuncio sobre el parche. Prepárese y este atento para asignar los recursos necesarios para actualizar a 3.0.7 lo antes posible.
Fuente: somoslibres
