imágenes falsas
El popular paquete de NPM “pac-resolver” ha corregido una falla severa de ejecución remota de código (RCE).
El paquete pac-resolver recibe más de 3 millones descargas semanales, extendiendo esta vulnerabilidad a las aplicaciones Node.js que dependen de la dependencia de código abierto. Pac-resolver se promociona a sí mismo como un módulo que acepta archivos de configuración de proxy de JavaScript y genera una función para que su aplicación asigne ciertos dominios para usar un proxy.
Ser proxy o no proxy
Esta semana, desarrollador Tim Perry reveló una falla de alta gravedad en pac-resolver que puede permitir a los actores de amenazas en la red local ejecutar código arbitrario dentro de su proceso Node.js cada vez que intenta realizar una solicitud HTTP.
Al agregar soporte de proxy a su Kit de herramientas HTTP, Perry comenzó a auditar el código pac-resolver y se encontró con el problema de seguridad. Seguimiento como CVE-2021-23406, la vulnerabilidad tiene que ver con la forma en que el módulo procesa los archivos de configuración automática de proxy (PAC). Los archivos PAC constan de código JavaScript que especifica una configuración de proxy: qué solicitudes de red deben pasar por un proxy y cuáles deben salir directamente. Por ejemplo, en un archivo PAC, los administradores de red pueden especificar explícitamente un proxy de red a través del cual se debe enrutar todo el tráfico y mostrar los dominios que están exentos del requisito:
function FindProxyForURL(url, host) {
// Send all *.example requests directly with no proxy:
if (dnsDomainIs(host, '.example.com')) {
return 'DIRECT';
}
// Send every other request via this proxy:
return 'PROXY proxy.example.com:8080';
}
En el ejemplo anterior, las solicitudes de red a “example.com” evitarán el proxy, mientras que el resto del tráfico debe pasar por un servidor proxy.
Introducido originalmente como parte de Netscape Navigator 2.0 en 1996, el Estándar PAC sigue siendo relevante y de uso generalizado en la actualidad. Por ejemplo, Web Proxy Auto-Discovery Protocol (WAPD) utiliza servicios DNS y / o DHCP para localizar archivos PAC en una red e importar la configuración del proxy a una aplicación. Sin embargo, a medida que las configuraciones de proxy se hacen más grandes, el código JavaScript en un archivo PAC puede volverse cada vez más complejo y está idealmente diseñado para ejecutarse en un entorno virtualizado (VM).
Pocas líneas de JavaScript pueden pasar por alto la VM y conducir a RCE
Y ahí es donde comienza el problema.
Por ejemplo, un paquete de NPM relacionado llamado Pac-Proxy-Agent, que fue creado por el mismo autor y tiene más de 2 millones de descargas semanales, proporciona soporte de archivos PAC para aplicaciones Node.js. Pac-Proxy-Agent lo hace tomando la URL de un archivo PAC, recuperando el archivo y luego actuando como un agente HTTP de Node.js que maneja las solicitudes salientes para su aplicación. Pero Pac-Proxy-Agent falla en el sandbox de los archivos PAC correctamente porque usa el módulo vulnerable pac-resolver, que además se basa en “degenerator” para construir la función PAC.
Degenerator es otro paquete más del mismo autor que ayuda a transformar código arbitrario en una función de espacio aislado utilizando el módulo “VM” de Node.js. Pero el módulo de VM nunca fue diseñado para usarse como un mecanismo de seguridad, algo que es explícitamente deletreado
Refiriéndose a un descargo de responsabilidad en los documentos de Node que dice: “El módulo vm no es un mecanismo de seguridad. No lo use para ejecutar código que no sea de confianza”, Perry dijo en una publicación de blog, “Este es un error fácil de cometer: es un texto pequeño (francamente, debería ser el título de esa página y al lado de cada método) y MongoDB hizo el exactamente lo mismo también en 2019, con consecuencias aún peores “.
Perry explicó además que “esto crea un gran problema. Si bien VM intenta crear un entorno aislado en un contexto separado, hay una larga lista de formas sencillas de acceder al contexto original y salir de la zona de pruebas por completo … permitiendo el código dentro la ‘caja de arena’ para hacer básicamente cualquier cosa que le guste en su sistema “.
Con eso, Perry compartió un código de explotación de prueba de concepto que demuestra cómo un atacante puede salir de la máquina virtual:
“Eso es todo, esto es todo lo que se requiere para salir del sandbox del módulo VM. Si puede hacer que un objetivo vulnerable use este archivo PAC como su configuración de proxy, entonces puede ejecutar código arbitrario en su máquina”, explicó.
La vulnerabilidad afecta seriamente a quienes usan versiones de pac-resolver anteriores a 5.0.0, incluso de manera transitiva en su aplicación Node.js, y:
- Utilice explícitamente archivos PAC para la configuración del proxy o
- Leer y usar la configuración del proxy del sistema operativo en Node.js en sistemas con WPAD habilitado o
- Usar configuración de proxy (
envvars, archivos de configuración, puntos finales de configuración remota, argumentos de la línea de comandos) de una fuente que no es de confianza
Un atacante remoto puede, en cualquiera de estos escenarios, configurar una URL PAC maliciosa y ejecutar código arbitrario en una computadora cada vez que se realiza una solicitud HTTP utilizando la configuración del proxy.
La solución para pac-resolver en la versión 5.0.0 consiste simplemente en golpeando la versión del degenerador a 3.0.1. La corrección del núcleo entró en el propio degenerador e implementa una solución más fuerte. mecanismo de sandboxing a través del módulo vm2 para “evitar la escalada de privilegios de código que no es de confianza”.
Perry agradeció a Snyk por apoyar al desarrollador durante todo el proceso coordinado de divulgación de vulnerabilidades.
Los desarrolladores afectados deben actualizar a pac-resolver versión 5.0.0 o superior para corregir esta grave vulnerabilidad en sus aplicaciones.