Esta vulnerabilidad de alta gravedad afecta a la serie OpenSSL versión 3.0. Si está utilizando una versión anterior de OpenSSL (es decir, cualquier versión 3.XX) en su servidor o plataforma, este CVE no le afecta.
Si sus servidores web u otros sistemas usan OpenSSL versión 3.XX, debe actualizar a la versión 3.0.7 inmediatamente. El Proyecto OpenSSL lanzó una actualización que aborda una vulnerabilidad de alto nivel en la serie de la versión 3.0 de su biblioteca de código abierto y herramienta de línea de comandos. Si vio titulares similares durante la última semana, es posible que haya notado que había una vulnerabilidad crítica que dijeron que solucionarían en el lanzamiento de la versión 3.0.7 de OpenSSL el 1 de noviembre. Sin embargo, la buena noticia es que esta vulnerabilidad común exploit (CVE-2022-3602) se ha degradado a una vulnerabilidad de alta gravedad en su lugar.
Si el Proyecto se mantuviera en la clasificación crítica original, habría hecho de esta la segunda vulnerabilidad de gravedad crítica que han anunciado desde 2014 (cuando la organización comenzó a clasificarlos). ¿Recuerdas el error OpenSSL Heartbleed? Sí, esa fue la razón por la que OpenSSL Project comenzó a clasificar la gravedad de estas vulnerabilidades en primer lugar.
Ahora, no malinterprete lo que estamos diciendo: esta vulnerabilidad de OpenSSL sigue siendo un problema grave que debe abordar rápidamente. Sabiendo esto, pasaremos directamente a lo que necesita saber sobre CVE-2022-3602.
Una breve descripción de la situación
El 25 de octubre, el equipo del proyecto OpenSSL anunció el próximo lanzamiento de la versión 3.0.7 de OpenSSL. Esta es una versión de corrección de seguridad que pretende mitigar un problema de seguridad crítico que afecta a la serie OpenSSL versión 3.0.
Según el aviso oficial del 1 de noviembre, la preocupación es que se pueda desencadenar un desbordamiento del búfer después de que un atacante haya verificado la firma digital del certificado simplemente usando una dirección de correo electrónico maliciosa en el certificado. Esto podría ocurrir si el cliente TLS se conecta a un servidor malintencionado o si un cliente malintencionado se autentica en su servidor.
El problema aquí sería el riesgo de que su servidor se bloquee o que un atacante ejecute código malicioso de forma remota. Sin embargo, para que esto suceda, uno de dos factores importantes tendría que desempeñar un papel:
- La autoridad emisora de certificados necesitaría firmar un certificado malicioso, o
- La aplicación en sí necesitaría avanzar con la verificación del certificado a pesar de no poder rastrear un certificado final hasta la raíz de confianza de la CA.
El riesgo también se reduce porque muchas plataformas cuentan con protecciones contra desbordamiento de pila.
¿Qué tan mala es la situación?
Honestamente, es mejor de lo previsto originalmente. Hasta que publicaron el aviso de CVE después de las 11:00 a. m. (hora del este), OpenSSL originalmente clasificó la gravedad de esta vulnerabilidad como crítica, es decir, la peor de las peores situaciones. Para poner esto en perspectiva, OpenSSL clasifica los problemas en cuatro categorías de gravedad : crítica, alta, moderada y baja.
Entonces, ¿qué califica como una vulnerabilidad de alta gravedad?
“Esto incluye problemas que tienen un riesgo menor que el crítico, tal vez debido a que afectan configuraciones menos comunes, o que tienen menos probabilidades de ser explotables. Estos problemas se mantendrán en privado y darán lugar a una nueva versión de todas las versiones compatibles”.
Bueno, eso es un poco vago, pero seguro que supera la clasificación de gravedad crítica anterior, que incluía riesgos como divulgaciones de memoria del servidor y compromisos de claves privadas, además de mayores riesgos de ejecuciones remotas de código.
Pero todavía hay una gran complicación. En la perspectiva de la seguridad del sitio web, es algo que muchos servidores usan para permitir conexiones seguras entre partes (es decir, activar HTTPS). El problema aquí es que OpenSSL versión 3.0 tiene una vulnerabilidad que, si no se mitiga, pone en riesgo sus sistemas. Si esto sucede y no hizo nada para solucionarlo rápidamente, es probable que sus clientes no sean muy comprensivos.
¿Qué versiones de OpenSSL están afectadas?
Si está utilizando las versiones 3.0.0, 3.0.6 o cualquier otra de la serie OpenSSL, debe aplicar este parche de inmediato . En octubre, el Proyecto OpenSSL lanzó la versión 3.0.6 pero rápidamente terminó retrocediendo el lanzamiento (junto con la versión 1.1.1r) debido a un “informe de una regresión significativa”. En su lugar, decidieron seguir adelante con el lanzamiento de las versiones 3.0.7 y 1.1.1, las cuales se lanzaron hoy (1 de noviembre).
¿Están relacionados estos dos problemas de versión? No según el equipo del proyecto OpenSSL. Las versiones anteriores de OpenSSL no son susceptibles al mismo riesgo porque el problema de seguridad crítico (que se emitirá un CVE el martes) solo afecta a las versiones OpenSSL 3.0, lo que significa que las versiones afectadas incluyen:
- OpenSSL 3.0.0
- OpenSSL 3.0.1
- OpenSSL 3.0.2
- OpenSSL 3.0.3
- OpenSSL 3.0.4
- OpenSSL 3.0.5
- OpenSSL 3.0.6
Ejemplos de aplicaciones vulnerables que dependen de OpenSSL
Las aplicaciones y los sistemas basados en Linux (incluidos muchos servidores web) suelen depender de OpenSSL, algunos de los cuales incluyen las versiones vulnerables 3.XX. Aquí hay algunos ejemplos de algunas de estas distribuciones:
- Transmisión CentOS 9
- FedoraLinux 36
- Fedora cuero crudo
- Red Hat Enterprise Linux 9
- Ubuntu 22.04
Para ver una lista de otras vulnerabilidades recientes de OpenSSL que se han abordado, consulte su página de informes de vulnerabilidades de OpenSSL. También puede solicitar unirse a la lista de anuncios de OpenSSL si desea mantenerse al tanto de estos problemas y correcciones de seguridad.
Cómo comprobar si su sistema está utilizando una versión vulnerable de OpenSSL
Si utiliza la utilidad de línea de comandos de OpenSSL, puede comprobar fácilmente qué versión está utilizando. Simplemente cargue la herramienta OpenSSL y la versión debería mostrarse como su primera entrada. De lo contrario, también puede ver la información de la versión ingresando el siguiente comando (como se ilustra en la captura de pantalla a continuación):
openssl version
Leyenda de la imagen: una captura de pantalla de una versión vulnerable de la herramienta de utilidad de línea de comandos de OpenSSL que muestra la versión de OpenSSL que se ejecuta en un dispositivo.
Cómo mitigar este problema
Honestamente, la cura para este problema es bastante simple: actualice OpenSSL en su servidor a la versión 3.0.7. Sí, es realmente así de sencillo.
Por supuesto, si no tiene OpenSSL en su servidor porque está incluido con el software o la plataforma de un tercero, debe comunicarse con su proveedor lo antes posible para asegurarse de que se esté ocupando de todo.
Nota: No necesita actualizar su certificado SSL/TLS. La vulnerabilidad está solo en el software OpenSSL y no en el certificado en sí.
¿Por qué esta vulnerabilidad aparece ahora como alta en lugar de crítica?
Como casi todo en la vida, las cosas cambian. En el caso de CVE-2022-3602, continuaron analizando la vulnerabilidad después de hacer su anuncio previo inicial el 25 de octubre y determinaron que no era un riesgo tan grave como se anticipó originalmente:
“Nuestra política de seguridad establece que una vulnerabilidad puede describirse como CRÍTICA si ‘la ejecución remota de código se considera probable en situaciones comunes’. Ya no sentimos que esta calificación se aplicara a CVE-2022-3602 y, por lo tanto, se rebajó el 1 de noviembre de 2022 antes de ser lanzada a ALTA”.
Ahora, no me malinterpreten: sigue siendo malo y definitivamente es algo que debe abordar de inmediato al instalar la última versión de OpenSSL (3.0.7). Pero es bueno que no se piense que la situación es tan grave como se anticipó originalmente.
¿Por qué anunciar la vulnerabilidad antes de tiempo si el parche para solucionarlo no está disponible de inmediato?
Mark Cox, un evangelista de código abierto que trabaja con Red Hat y OpenSSL Project, dice que hacer este tipo de anuncio temprano es su política porque les da a las organizaciones tiempo para planificar con anticipación y reservar tiempo para abordar estos problemas. La idea aquí es que si lo sabe con anticipación, no tendrá que dejar todo en el último minuto para implementar las actualizaciones de inmediato.
Pero, ¿hacer un anuncio temprano no causa riesgos de seguridad? Después de todo, estos anuncios informan a los delincuentes que existe una vulnerabilidad confirmada que podrían aprovechar. Sí, eso es técnicamente correcto. Pero Cox comparte en su página de Twitter que este tipo de escenario no es probable: “Dada la cantidad de cambios en 3.0 y la falta de cualquier otra información de contexto, tal exploración es muy poco probable”.
Al igual que con cualquier cosa en Internet, siempre existe el riesgo de que alguien, en algún lugar, descubra cómo explotar las vulnerabilidades. Pero todos los ciberdelincuentes se preguntarán si vale la pena exprimir el jugo. Tendrían que pasar horas o incluso días tratando de determinar la vulnerabilidad y luego descubrir cómo explotarla. En ese momento, es probable que el parche ya esté disponible y aplicado.
Esta vulnerabilidad de OpenSSL no es la primera (y no será la última)
Como mencionamos anteriormente, CVE-2022-3602 no es la primera vulnerabilidad de gravedad que se identifica en OpenSSL. Vimos que hace años con CVE-2014-0160, o lo que se conoce más comúnmente como Heartbleed , fue otra vulnerabilidad crítica que asoló OpenSSL. No entraremos en todos los detalles técnicos sobre cómo funcionó, pero esta vulnerabilidad terminó permitiendo que se transmitieran claves de cifrado secretas y otros datos no cifrados (y potencialmente comprometidos).
Ahora que esta nueva vulnerabilidad (CVE-2022-3602) se ha degradado, solo sirve como un recordatorio de lo importante que es mantener sus sistemas parcheados y actualizados. De esta manera, a medida que los proveedores y otros implementen mitigaciones de vulnerabilidades, podrá mantener sus sistemas lo más seguros posible.
Neothek ofrece servicios de certificados SSL, web hosting, registro de dominios, correo electrónico, diseño de páginas web y diseño gráfico.
