Preparación eficaz contra la vulnerabilidad de OpenSSL 3.x
Actualización (1 de noviembre de 2022): La distribución de contenido de Akamai a través de HTTP y HTTPS no se ve afectada por esta vulnerabilidad, ya que los servidores utilizan una versión no afectada de OpenSSL. Además, los sistemas de Akamai utilizan mecanismos de protección de pila estándar del sector que mitigarían el vector de ataque descrito. Akamai está aplicando parches a los sistemas internos potencialmente afectados, pero no prevemos que estos esfuerzos provoquen tiempos de inactividad para nuestros clientes.
El 25 de octubre, el equipo del proyecto OpenSSL anunció una corrección de seguridad para una vulnerabilidad crítica en OpenSSL versión 3.x. La publicación del parche está programada para el 1 de noviembre de 2022, entre las 13:00 y las 17:00 UTC.
Este anuncio ha dado mucho que hablar debido al uso extensivo de OpenSSL. Con este artículo, esperamos ir al grano y proporcionar información y consejos sobre cómo detectar y mitigar la amenaza sin especulaciones. En la primera parte de la publicación se describe OpenSSL y el alcance de la vulnerabilidad. En la segunda parte se describe cómo se utiliza OpenSSL en las aplicaciones y se proporcionan herramientas para detectar activos vulnerables. No dude en saltar directamente a estas utilidades, si lo prefiere.
Nota: Esta publicación del blog cubre un incidente en evolución y se actualizará a medida que se recopile más información y se publique la corrección.
¿Cuál es el alcance de esta vulnerabilidad?
Esta vulnerabilidad ha causado preocupación en la comunidad de seguridad porque no es habitual que el equipo de OpenSSL califique una vulnerabilidad como crítica, que posteriormente se degradó a "alta". Desde la introducción de estas etiquetas de vulnerabilidad tras Heartbleed (una vulnerabilidad que conduce a filtración de memoria y posible revelación de claves), solo ha habido otra, CVE-2016-6309 que se clasificó como "crítica".
Según los requisitos del equipo de OpenSSL, para que se considere crítica, una vulnerabilidad afecta a configuraciones comunes y es probable que sea aprovechable. Un ejemplo de tales vulnerabilidades podría incluir "la divulgación significativa del contenido de la memoria del servidor (que podría revelar detalles del usuario), vulnerabilidades que se pueden aprovechar fácilmente de forma remota para poner en peligro las claves privadas del servidor o cuando la ejecución remota de código se considera probable en situaciones comunes".
Teniendo en cuenta lo común que es la biblioteca OpenSSL, una vulnerabilidad en ella puede ser perjudicial. Sin embargo, aunque la concienciación es necesaria, todavía no hay motivos para entrar en pánico. OpenSSL es muy común, pero su versión más extendida es 1.X.X, y la vulnerabilidad solo afecta a las versiones 3.0.0 y posteriores de OpenSSL (publicada hace poco, en septiembre de 2021). Por lo tanto, la vulnerabilidad probablemente sea menos común que la distribución de la propia biblioteca OpenSSL.
Hemos ejecutado nuestras herramientas de detección en algunas de nuestras redes gestionadas y hemos aprendido lo siguiente:
Aproximadamente el 50 % de los entornos supervisados tenían al menos un equipo con al menos un proceso que depende de una versión vulnerable de OpenSSL.
De esas redes, el porcentaje de equipos de la red que dependían en cierta medida de una versión vulnerable de OpenSSL variaba del 0,2 % al 33 %.
La cobertura media era del 6,1 % y la media era del 11,3 % con una desviación estándar del 11,6 %.
Estas estadísticas no tienen en cuenta el uso de OpenSSL no vulnerable. La única métrica son los equipos con al menos un proceso que depende de una versión vulnerable de OpenSSL (3.0–3.6). Tampoco se tuvieron en cuenta otros procesos que se ejecutaban en el mismo equipo.
¿Qué es OpenSSL?
OpenSSL es un kit de herramientas de software de código abierto y, como tal, las versiones de OpenSSL son básicamente versiones del código fuente. Sin embargo, lo que significa para la detección es que hay muchas formas en las que una aplicación puede cargar OpenSSL o depender de OpenSSL, de ahí el nivel crítico de la vulnerabilidad.
En primer lugar, debemos definir los tres componentes de OpenSSL.
libcrypto : una biblioteca criptográfica con implementación de muchos protocolos (por ejemplo, AES, RSA, ChaCha, etc.)
libssl : una biblioteca que implementa todos los protocolos TLS hasta TLSv1.3
openssl : una utilidad de línea de comandos para diversas operaciones (por ejemplo, la generación de certificados)
Para que una aplicación dependa de OpenSSL, tiene que llamar a alguna lógica de código de libcrypto o libssl (openssl en sí es una aplicación que depende de ambos).
Mitigación de la vulnerabilidad de OpenSSL
El primer paso para mitigar la amenaza de OpenSSL consiste en detectar los activos vulnerables. Aunque este consejo es común, rara vez va acompañado de métodos prácticos. A continuación proporcionamos una lista de aplicaciones vulnerables conocidas, así como un método general para encontrar aplicaciones vulnerables en su red.
Segmentación: mitigación previa y posterior a la aplicación de parches
Aunque la aplicación de parches podría no ser posible inmediatamente, dado que la mayor parte de la dependencia de OpenSSL proviene del software de los proveedores (que necesitan aplicar la corrección ellos mismos), todavía podemos aprovechar la visibilidad que podemos obtener de la detección. Podemos utilizar la segmentación y el enrutamiento para reducir la propagación que un atacante podría lograr al aprovechar la vulnerabilidad.
Podemos imponer más restricciones a los activos orientados a Internet mediante una zona DMZ (más estricta).
Podemos crear más segmentación en todo el dominio para que un equipo interno vulnerado no se pueda utilizar para propagar el daño a toda la red. Esto también se puede utilizar para reducir la superficie de ataque de un equipo vulnerable a solo la parte de la red con la que realmente necesita comunicarse.
Además, podemos aprovechar esta visibilidad y detección para crear un plan de acción de aplicación de parches, y garantizar que no se omite nada. Una vez publicados los parches y finalizado el proceso de aplicación de parches, podemos volver a ejecutar la lógica de detección y comparar los resultados. Lo ideal es que no nos queden equipos vulnerables.
¿Qué aplicaciones conocidas son vulnerables?
BoringSSL (que se utiliza en Google Chrome) y LibreSSL son dos bibliotecas que se basan en el código OpenSSL y que aún no están afectadas por la próxima vulnerabilidad.
Con la biblioteca OpenSSL se incluyen diferentes distribuciones de Linux. Si ejecuta un entorno Linux, es posible que desee comprobar si está utilizando una de las siguientes versiones, que se incluyen con el código OpenSSL vulnerable.
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
Si está utilizando una distribución de Linux que no está en la lista, no se garantiza su seguridad frente a vulnerabilidades. Si ha actualizado activamente la biblioteca (como parte del comando upgrade de un administrador de paquetes, por ejemplo), también será vulnerable. Puede escribir "openssl version" en el terminal para obtener la versión de la biblioteca.
Docker también ha publicado su comunicado para la próxima versión, en el que estiman que unos 1000 repositorios de imágenes podrían verse afectados en varias imágenes Docker Official Images y Docker Verified Publisher Images. Esto incluye imágenes basadas en variaciones de las distribuciones de Linux mencionadas anteriormente.
También hay algunos marcos que podrían verse afectados. Node.js v18.x y v19.x utilizan OpenSSL 3 y, por lo tanto, se supone que están afectados por la vulnerabilidad. Anunciarán las nuevas actualizaciones en esta publicación de blogDLL proxying de itm4n’s.
Otro lenguaje de programación que hizo que a los desarrolladores les diera un brinco el corazón es Golang. Las bibliotecas de Go están vinculadas estáticamente, lo que podría haber requerido que los desarrolladores de Go volvieran a compilar su software. Cuando el equipo de Golang anunció nuevas versiones menores que incluían correcciones de seguridad en la misma fecha que el próximo parche de OpenSSL, la gente relacionó ambas fechas y asumió que estaban relacionadas. No se preocupe: fue una falsa alarma. Las versiones de Golang no están relacionadas con la próxima vulnerabilidad.
Es probable que la lista de aplicaciones vulnerables crezca en los próximos días, por lo que actualizaremos esta publicación en consecuencia. En las siguientes secciones se proporcionan métodos y herramientas de detección para ayudarle a averiguar qué aplicaciones de su entorno utilizan OpenSSL 3 y, por tanto, también son vulnerables. Si lo prefiere, puede saltar directamente a los mecanismos de detección.
Método general para detectar aplicaciones que utilizan OpenSSL 3
Nota: En esta sección se presentan los detalles internos de cómo utiliza una aplicación OpenSSL. Si simplemente le interesa la detección, puede saltar directamente a nuestras reglas de YARA o consultas de OSQuery.
OpenSSL se puede vincular a una aplicación tanto estática como dinámicamente. Con la vinculación estática, el código fuente de OpenSSL se incluye como parte del código de la aplicación, y ambos se compilan juntos en el mismo binario. Con la vinculación dinámica, OpenSSL se compila por separado en una biblioteca compartida (libssl.dll y libcrypto.dll en Windows; libssl.so y libcrypto.so en Linux). A continuación, el código de la aplicación tiene referencias a la biblioteca compartida, que el sistema operativo resuelve cuando carga la aplicación.
¿Cómo se traduce esto en la detección? Prácticamente, un método para detectar binarios compilados estáticamente será suficiente. ¿Por qué sucede esto? Porque si una aplicación en ejecución carga dinámicamente OpenSSL, o incluso si carga dinámicamente una biblioteca que a su vez carga dinámicamente OpenSSL (y así sucesivamente), eventualmente alguna biblioteca de OpenSSL compilada estáticamente se cargará. Puesto que toda la carga dinámica se produce en el contexto del mismo proceso, solo tenemos que revisar la lista de bibliotecas cargadas en cada proceso y encontrar la que está compilada estáticamente.
Por lo tanto, necesitamos averiguar qué aspecto tiene un código OpenSSL compilado estáticamente. Afortunadamente, es bastante sencillo. Todas las compilaciones estáticas de OpenSSL contienen una cadena de versión, que tiene el siguiente aspecto: OpenSSL 3.0.6 11 Oct 2022, donde 3.0.6 es el número de versión. Detectar esta cadena es bastante sencillo y se puede hacer con Regex o YARA.
Esto, sin embargo, puede no ser una correspondencia perfecta. Puesto que OpenSSL es un código abierto, los usuarios pueden cambiar fácilmente la lógica de control de versiones para que se adapte a sus necesidades (y, por lo tanto, hacer que nuestra detección no surta efecto). Hemos visto que esto ha sucedido en una única ocasión (con Cisco, que utilizó la cadena CiscoSSL 1.1.1k.7.2.225 en su lugar), pero también podría suceder con otros proveedores.
¿Qué debo hacer ahora?
Aunque no sabremos mucho hasta que se publique la corrección, hay algunas cosas que los defensores pueden hacer de forma preventiva para estar preparados para la aplicación del parche. Nuestro equipo ha creado algunas utilidades que puede ejecutar en su entorno para obtener visibilidad y facilitar la mitigación. Los clientes de Akamai Guardicore Segmentation con la función Insight habilitada pueden ejecutar fácilmente esta lógica en su entorno.
reglas de YARA
La regla principal que podemos escribir es para la cadena que hemos mencionado anteriormente. Por brevedad, limitaremos nuestra detección únicamente a las versiones reales de OpenSSL que se ven afectadas por la versión, pero podemos modificar fácilmente nuestros criterios.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
En caso de que no queramos depender de la cadena, también podemos buscar la aplicación principal que depende de OpenSSL, pero analizar las importaciones del ejecutable. Sin embargo, este es un método menos infalible y debería tratarse como tal.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
Con las consultas anteriores, también podemos aprovechar la tabla YARA de osquery para ejecutar esas reglas en todos los procesos en ejecución.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
Por supuesto, también puede incluir otras reglas de YARA que hemos mencionado o añadir más o menos filtros para reducir o ampliar el número de archivos comprobados.
Resumen
El equipo de OpenSSL ha adoptado un enfoque interesante informando a los equipos de seguridad de la próxima versión de la corrección. Este anuncio ha dado tiempo a los defensores para preparar y asignar los activos críticos que están en cola para la aplicación de parches. En esta entrada del blog, hemos intentado ayudar a hacer exactamente eso: localizar las aplicaciones y los activos que se deben tener en cuenta el día de la aplicación parche.
Esta es una historia en constante evolución y actualizaremos esta entrada del blog a medida que se vaya publicando nueva información, así que no olvide volver a visitar esta sección para obtener información sobre las actualizaciones. También puede seguirnos en Twitter para obtener más actualizaciones en tiempo real.