Cómo Snyk Social Trends te ayuda a corregir vulnerabilidades de seguridad esenciales

Hace poco, Snyk agregó Social Trends a sus datos sobre vulnerabilidades. Este nuevo indicador te muestra qué vulnerabilidades son tendencia para que puedas priorizar mejor su corrección. Nuestro equipo de investigación descubrió que existe una fuerte correlación entre las vulnerabilidades que son tendencia en redes sociales y la existencia de exploits que pueden dañar realmente tu aplicación.

Tiene sentido práctico seguir las tendencias en redes sociales sobre vulnerabilidades de seguridad. Cuando una vulnerabilidad específica genera mucho interés en redes sociales —por ejemplo, en Twitter—, significa que muchas personas conocen el problema. Desde el punto de vista estadístico, también significa que hay más personas que quieren hacerte daño. Por eso, puede ser importante prestar más atención a las vulnerabilidades de tu sistema que son tendencia en redes sociales.

Veamos Snyk Social Trends (análisis de sentimiento sobre vulnerabilidades) en acción.

Un ejemplo de tendencia en Java

Creé una pequeña aplicación en Java basada en una versión obsoleta de Spring Boot, 2.2.0-RELEASE. Después de conectar el repositorio de GitHub a mi cuenta de Snyk, encontré la siguiente vulnerabilidad en el primer lugar de mi lista porque actualmente es tendencia en redes sociales.

Se trata de una vulnerabilidad de ejecución remota de código (RCE) en la versión integrada de Apache Tomcat que se incluye con el paquete de inicio específico de Spring Boot que uso. Al hacer clic en el botón de tendencias, encontré muchos tuits sobre esta vulnerabilidad específica y un exploit funcional publicado. Volveré a esto más adelante, pero primero explicaré la vulnerabilidad.

Explicación de la vulnerabilidad de ejecución remota de código CVE-2020-9484

Explicaré brevemente cómo funciona esta vulnerabilidad de RCE en Tomcat. Esta vulnerabilidad existe en todas las versiones de Tomcat, incluida la versión integrada que proporciona Spring Boot. También es bueno saber que ya hay una nueva actualización disponible para todas las versiones que corrige este problema.

Supongamos que usas PersistentManager con FileStore en Tomcat. PersistentManager administra la sesión. Una sesión permite conservar el estado entre las solicitudes del cliente al servidor. De forma predeterminada, Tomcat usa StandardManager, que mantiene las sesiones en memoria. Sin embargo, PersistenManager pasa las sesiones al almacenamiento si permanecen inactivas durante algunos segundos. Este almacenamiento puede ser un disco mediante FileStore o una base de datos mediante JDBCStore.

Con FileStore, Tomcat almacena las sesiones en una ubicación predefinida con el nombre <JSESSIONID>.session. Si la nueva solicitud con un ID de sesión no encuentra la sesión en memoria, PersistentManager busca las sesiones almacenadas en el disco y, si encuentra la sesión, deserializa el objeto almacenado y lo carga en memoria.

Pero ¿qué pasa si mi sesión tiene un valor como JSESSIONID=../../../../../../../foo/mysession? Debido a la vulnerabilidad de recorrido de directorios, Tomcat buscará mysession.session en el directorio foo. Si puedo subir un archivo a este sistema por algún motivo, puedo subir un archivo de sesión serializado. Después, puedo activar la deserialización asignando a mi JSESSIONID la ubicación correspondiente. La deserialización activa una ejecución remota de código malicioso, según el objeto serializado.

Si quieres saber más sobre por qué las vulnerabilidades de deserialización son peligrosas, lee la publicación del blog Serialización y deserialización en Java: explicación de la vulnerabilidad de deserialización de Java.

Para obtener más información sobre esta vulnerabilidad en Tomcat, este excelente artículo de redtimmy.com la explica con más detalle. Puedes encontrar una prueba de concepto del exploit en este repositorio de GitHub:  https://github.com/masahiro331/CVE-2020-9484

Cómo Snyk Social Trends te ayuda a enfocarte en lo importante

Podrías decir que esta vulnerabilidad requiere varias condiciones previas para que se pueda explotar.

1. Es necesario habilitar PersistentManager con FileStore

2. Los atacantes deben poder subir cualquier archivo

3. Debe haber un gadget disponible en el classpath para el ataque de deserialización

Algunas personas podrían decir que, debido a estas condiciones previas, en realidad no se pueden explotar muchos casos y descartarla. Sin embargo, debido a la gran atención que recibió en Twitter, la analicé detenidamente y vi que no era tan difícil cambiar el administrador de sesiones a PersistentManger con FileStore. Además, dada la cantidad de dependencias que uso en mi aplicación, es bastante posible que haya un gadget.

Así que, si alguien de mi equipo decide usar PersistentManger con FileStore por algún motivo, lo único que falta es permitir la carga de archivos arbitrarios. Dado que las brechas de seguridad casi siempre son una cadena de sucesos que lleva al desastre —y no un solo suceso o vulnerabilidad—, no creo que se pueda simplemente descartar una vulnerabilidad como esta. Sobre todo cuando hay correcciones disponibles.

Más importante aún, si una vulnerabilidad es tendencia, significa que mucha gente la conoce y habla de ella, incluidas personas con malas intenciones. Para mí, es una señal de que debo investigar esa vulnerabilidad aún más de cerca de lo que ya lo hago, para determinar si soy vulnerable ahora o lo seré en el futuro.

Incluir el indicador de tendencia en la interfaz de Snyk no solo destaca la vulnerabilidad, sino que también aumenta su puntuación de prioridad por ese motivo. Por eso, creemos que buscar en redes sociales para determinar la popularidad de una vulnerabilidad específica es una herramienta poderosa que me ayuda a evitar errores de seguridad evidentes y conocidos. Así que, cuando veas una etiqueta de tendencia, te recomendamos volver a revisar una vulnerabilidad que quizá habías ignorado.