La seguridad en contexto: ¿Cuándo un CVE no es un CVE?

En Snyk, tenemos algunos principios generales que guían nuestro enfoque y nuestras decisiones de seguridad.

En primer lugar, es importante entender de quién nos estamos protegiendo, ya que esto influye en cómo debemos actuar. Por ejemplo, si nuestro artefacto es un servidor web, debemos protegerlo de usuarios no confiables. En cambio, si nuestro artefacto es un software de cifrado, claramente debemos protegerlo incluso de usuarios con acceso físico al sistema. En cada uno de estos casos, distinguimos claramente cuál es el límite de riesgo y dónde debemos centrar nuestra atención.

En segundo lugar, la configuración es parte de tu base de código. Si un actor malicioso tiene acceso a tu configuración, en esencia es lo mismo que si tuviera acceso a tu base de código.

Ante el tsunami de sistemas vulnerables causado por la reciente vulnerabilidad de Log4j 2.x (Log4Shell), como comunidad, quizá se nos pueda disculpar por buscar con aún más empeño otras posibles vulnerabilidades. Sin embargo, también podríamos aprovechar esta oportunidad para hacer una pausa y reflexionar antes de emitir un juicio sobre cada posible problema de seguridad que encontremos en nuestro código. Una mirada más serena también puede sugerir que no todos los problemas de seguridad deben clasificarse por igual.

Por ejemplo, podríamos analizar desde esta perspectiva la asignación reciente de CVE-2021-4104 a Log4j 1.x. Para explotarla, se necesita acceso directo a los archivos de configuración a fin de manipular los ajustes. Ahora están surgiendo debates similares en torno al proyecto Logback, así como ejemplos en la comunidad de Node.

Dejemos algo claro: exponer posibles vulnerabilidades sigue siendo algo bueno. Pero, en medio del pánico mediático, también es apropiado poner a prueba nuestro propio criterio y volver a establecer como comunidad en qué deberíamos enfocarnos. Generar otro tsunami de posibles vulnerabilidades puede causar más daño que beneficio: sobrecargar aún más a los equipos de seguridad, que ya están bajo presión, y enturbiar la situación, obstaculizando los esfuerzos de la industria por proteger el software de código abierto.

Analizar los CVE con criterio

Los debates que aparecen en los hilos anteriores plantean preguntas muy interesantes.

Por ejemplo, si para explotar una vulnerabilidad se necesita acceso privilegiado a los archivos de un sistema, ¿realmente es una vulnerabilidad? Casi cualquier software moderno que no sea trivial puede configurarse para funcionar de forma insegura. Por ejemplo, es perfectamente posible configurar sshd para permitir el inicio de sesión con contraseñas vacías. ¿Deberíamos considerar eso una vulnerabilidad nueva en sshd?

Uno de los mecanismos que utiliza nuestro equipo de seguridad es considerar la diferencia entre el comportamiento esperado y el inesperado. Si un software puede configurarse para ejecutar código remoto y esta función está bien documentada, ¿se trata de un comportamiento que introduce una debilidad que podría explotarse? Se podría argumentar que es un comportamiento esperado y que, en sí mismo, no constituye una vulnerabilidad de seguridad.

¿Deberíamos diseñar software sin modos configurables que sean inseguros? Puede parecer un objetivo encomiable, pero entra un poco en conflicto con la forma en que hemos diseñado software de código abierto durante los últimos 30 años o más. Los objetivos habituales de diseño del software de código abierto han sido ofrecer el máximo nivel de configurabilidad para cubrir todos los casos de uso. En los últimos años, los valores predeterminados de seguridad razonables se han convertido en un objetivo secundario; sin embargo, el principio siempre ha sido dar al usuario opciones para configurar el software como prefiera, de forma segura o no.

También vivimos en un mundo en el que es fácil que personas y empresas asignen CVE, y en el que estos aportan credibilidad y prestigio. Esta combinación particular puede dar lugar a asignaciones cuestionables. Por otro lado, contar con mecanismos sin fricciones para reportar posibles problemas de seguridad solo puede ser algo positivo, así que nos encontramos ante una especie de paradoja.

Como industria, cada vez somos mejores para identificar vulnerabilidades, mientras creamos mucho más software, por lo que es fácil ver el riesgo de saturación.

Identificar correctamente las vulnerabilidades del software, evaluarlas y ofrecer medidas de mitigación es un proceso que consume muchísimos recursos y, en gran medida, es manual, sobre todo en los casos complejos. Aunque los enfoques de ML son cada vez más útiles y la IA podría resultar aún más valiosa, en muchos casos (irónicamente) las computadoras no nos ayudan demasiado a diagnosticar.

Nota del editor (19 dic. 2021): Desde la publicación de este artículo, el proyecto Logback asignó CVE-2021-42550 al problema mencionado anteriormente. Por los motivos expuestos en esta publicación, Snyk no agregará un aviso sobre este problema por ahora. Seguiremos en contacto con la comunidad de Logback y esperamos llegar a un consenso mediante un diálogo abierto.

De cara al futuro

Los puntos de debate que se presentan aquí no buscan cambiar ningún CVE en particular, sino abrir una conversación sobre el futuro de la evaluación de vulnerabilidades y sobre qué consideramos inseguro ahora y en adelante. Crear software de código abierto potente y versátil, apto para casos de uso generales, inevitablemente implica ofrecer modos configurables que brindan distintos niveles de seguridad. Si queremos seguir haciéndolo, los usuarios también tienen la responsabilidad de conocer los riesgos de uso. Quizá la respuesta consista tanto en mejorar la documentación y la capacitación como en clasificar las posibles vulnerabilidades en casos de uso normales.

Nos encantaría conocer la opinión de la comunidad. Escríbenos en redes sociales (@snyksec) y conversemos.