Mi frustración es cada vez más alta porque acaba de suceder de nuevo. Si leyó mi análisis anterior titulado CVE-2022–29622: (In)vulnerability Analysis , puede sospechar a lo que me refiero. Misma historia, diferente víctima. Sin embargo, las fechas son importantes en este caso. Mi anterior análisis de invulnerabilidad es del 2022, hoy voy a analizar otro número del 2018.

Puede preguntar: "¿Por qué tienes que lidiar con algo de 2018?" ¡Excelente pregunta! Porque recientemente habilité Dependency Track para extraer información de vulnerabilidad del índice OSS de Sonatype.

Hoy, mientras hojeaba SCA para ver si teníamos algún componente vulnerable y, si lo teníamos, priorizar el trabajo de remediación. Me encontré con algo muy sorprendente. ¡¿Koa.JS tiene una vulnerabilidad crítica?! Después de mi habitual "#FFS, toda mi semana necesita reorganizarse", dije: "Respira hondo y mira de qué se trata esto. Recuerdas lo que pasó la última vez…”

Y así lo hice. En primer lugar, el título deja en claro que el "problema" se encontró en 2018. Ahora, ¿por qué tendría una vulnerabilidad en una biblioteca que aún se mantiene y sigo actualizando a la última versión? En este punto, la parte investigadora de mi cerebro entró en acción.

¿Qué sabemos/vemos en este punto?

1. Supuestamente hubo una vulnerabilidad en Koa en 2018 con una gravedad crítica asignada
2. Según Sonatype OSS Index y Dependency Track, el problema me afecta en 2022 mientras ejecuto la última versión de Koa

• Qué versiones de la biblioteca Koa.JS se vieron afectadas por la "vulnerabilidad"
• Si la “vulnerabilidad” está presente en el último Koa.JS

Análisis de problemas

Veamos de qué se trata la “vulnerabilidad”. Permítanme vincular rápidamente el problema relacionado #1250 de GitHub aquí. Copiaré y pegaré el ejemplo (¿PoC?) a continuación para que podamos analizarlo.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

“Como desarrollador de una aplicación o servicio web, puedo redirigir su navegador a donde quiera si visita mi sitio web”.

Eso es lo que significa el código anterior. En el PoC anterior no se presenta ningún vector de ataque para que un actor malicioso explote algo.

Si quisiera proporcionar un "PoC" adecuado para esta no vulnerabilidad (sí, lo acabo de decir), se vería así:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

Hablando de una vulnerabilidad XSS, si lo que ingresé como el valor del vectorparámetro se mostró en el contexto HTML de forma insegura, la aplicación que implementé sería vulnerable a Cross Site Scripting. (Más sobre esto más adelante)

Acercándonos a cómo Sonatype presentó esto y analizándolo un poco más:

¿"Redirección abierta que lleva a Cross-Site Scripting"? En primer lugar, no había una redirección abierta. Solo está abierto si lo abre y la diferencia entre los dos PoC (el original y el mío) lo muestra claramente. En el primero, no había vector de ataque, por lo que no había redirección abierta. Mi PoC tenía un vector de ataque, sin filtrado, por lo que había una redirección abierta. Pero, como puede ver, si había o no una redirección abierta dependía de mí, el desarrollador y no de Koa.JS. Aún mejor, si había una redirección o no también dependía de mí. Si incluí la entrada proporcionada por el usuario como/en la URL de redirección de una manera insegura también dependía de mí. ¿De qué vulnerabilidad Koa.JS estamos hablando entonces? Técnicamente, no había una vulnerabilidad y alguien aún le asignó una gravedad crítica. No exactamente profesional.

De todos modos, vamos a “explotar” dicha “vulnerabilidad” implementada por el PoC adecuado. Tenga en cuenta que tuve que cambiar el puerto de servicio de 3000 a 4444 porque ya tenía algo escuchando en el puerto 3000.

Podemos ver que el Locationencabezado de respuesta tiene el valor javascript:alert(1). Luego, el navegador redirige a…

¡Eh, estoy a salvo! No apareció ningún cuadro de alerta. Sí, podría ingresar https://google.comcomo el valor del vectorparámetro de consulta y ser redirigido a Google, por lo que mi aplicación (PoC) es vulnerable a la redirección abierta, pero no por Koa, sino porque pasé datos de usuario sin filtrar a ctx.redirect. No es algo que me preocupe, nunca haría esto.

Una cosa importante a tener en cuenta de los comentarios del problema en GitHub es lo siguiente:

El problema surge del hecho de que Koa imprime un hipervínculo HTML en el cuerpo de la respuesta de redireccionamiento y eso puede desencadenar un ataque de secuencias de comandos entre sitios.

¡Ah, eso tiene un poco más de sentido! A ver si sigue siendo así.

No, ya no es el caso. No hay cuerpo de respuesta. Supongo que puedo concluir que esta "vulnerabilidad" no me afecta. Puedo ir y marcarlo como falso positivo en Dependency Track.

Análisis de contexto

Propongo que todos los profesionales de seguridad adopten el "Análisis de contexto" y lo realicen antes de informar "problemas". Deje que este sea otro ejemplo y le muestre cómo se hace. (Sin embargo, le recomiendo que lea CVE-2022–29622: Análisis de (in)vulnerabilidad , ya que explica mucho mejor la importancia del contexto).

1. Koa.JS listo para usar no lo redirige a ninguna parte. Por lo tanto, no hay ni hubo "redireccionamiento abierto" como lo indica Sonatype OSS Index.
2. Según el "PoC" proporcionado en GitHub, un desarrollador tenía la oportunidad de hacer algo estúpido que podría conducir a XSS. Pero, vea el #1 arriba. Koa.JS no realizó ninguna redirección por sí solo. Vea el #2 a continuación.
3. Un desarrollador debe haber implementado su aplicación de manera insegura para que la "vulnerabilidad" informada esté presente. Esto significa que Koa.JS, aunque podría haberlo hecho mejor, no podría llamarlo vulnerable. Es contextualmente inapropiado. La vulnerabilidad en cuestión solo podría estar presente en una aplicación web implementada de forma insegura .

Permítanme darles un ejemplo de cómo se manejan mejor situaciones como esta. Mire este problema que envié a Swagger Parser y cómo se comunicó. Analicemos el informe de problemas:

1. El título dice "Comportamiento inseguro del solucionador". No estoy hablando de LFI (Inclusión de archivos locales) en el título. Esto se debe a que, si bien existe la posibilidad de inclusión de archivos locales SI ESTOY MAL LAS COSAS, realmente depende de mí, como desarrollador, saber con qué estoy trabajando y cómo lo estoy haciendo. El comportamiento predeterminado era (quizás todavía sea) inseguro. Pero, la biblioteca por sí sola, sin mi participación no hará nada.
2. Luego, declaro claramente de qué versión de la biblioteca estoy hablando. Hago el contexto aún más claro al enumerar las condiciones bajo las cuales el comportamiento predeterminado inseguro de la biblioteca afectaría una aplicación. Esto deja bastante claro que la biblioteca en sí no es vulnerable, pero tiene un comportamiento inseguro que se puede mejorar para ayudar a los desarrolladores.
3. Entonces, ahora que se establece el contexto, proporciono un PoC funcional, un fragmento de código vulnerable (que escribí como un PoC, ¡no es parte de Swagger Parser!) y el resultado real de la explotación de una aplicación/servicio vulnerable que usa el biblioteca de forma insegura.
4. Investigué un poco y descubrí que, como desarrollador, puedo configurar la biblioteca de una manera que mitigue el problema. (hasta cierto punto) compartí esto con los desarrolladores. Si nada más, al menos pueden actualizar la documentación para crear conciencia.
5. Proporcioné contexto adicional, análisis y un ejemplo de cómo se podrían mejorar las cosas.

Conclusión

En primer lugar, Sonatype debería funcionar mejor con el índice OSS y asegurarse de que la información de la versión esté disponible para cada vulnerabilidad en la base de datos. Eso es lo mínimo. (Puntos de bonificación por eliminar por completo esta entrada específica de la base de datos).

Sospecho que Dependency Track sufre de FOMO, por lo tanto, está dispuesto a informar problemas basados ​​únicamente en la coincidencia del nombre del componente si el número de versión no está disponible. Entiendo hasta cierto punto que no se arriesgarían a pasar por alto una vulnerabilidad crítica. El problema de este comportamiento (falsos positivos) es que no fomenta la adopción del análisis de composición de software. Asustará a los desarrolladores como los falsos positivos del análisis de código estático. Contraproducente.

¡Contexto! ¡El maldito contexto, gente! Propongo:

1. "Análisis de contexto" para ser adoptado por todos los profesionales de seguridad y realizado antes de informar "problemas"
2. Distinguir “comportamiento inseguro” de “vulnerabilidad”
3. Comprender la diferencia entre una biblioteca de software y una aplicación/servicio