Asistí a una reunión del Grupo de Trabajo de Mensajería, Malware y Anti-Abuso Móvil (m3aawg.org) en Brooklyn, Nueva York. Esperaba un mejor clima para pasear por la ciudad, disfrutar de la conferencia y una amplia selección de comida en la zona. Estaba tan seguro de la claridad del cielo que ni siquiera me llevé nada de la lluvia. Y llovió toda la semana. Esto me obligó a quedarme en mi habitación de hotel con WiFi gratis y mi computadora portátil de trabajo. Decidí pasar este tiempo investigando Node.js y sus paquetes relacionados disponibles en https://www.npmjs.com .
Hay miles de paquetes de usuarios disponibles para descargar e instalar en su proyecto. Busqué en NPM nombres de paquetes populares como archivo, copia de seguridad, descarga o carga. La última búsqueda me mostró un proyecto llamado carga de archivos jQuery desde Blueimp. Su descripción parecía lo suficientemente interesante como para descargarla y explorarla.
Widget de carga de archivos para jQuery, con soporte para selección de archivos múltiples, arrastrar y soltar, indicador de progreso, validación y vista previa de imágenes, audio y video. Admite solicitudes entre dominios, un mecanismo parcial y renovable para descargar archivos con el cambio de tamaño de las imágenes en el lado del cliente. Funciona en cualquier plataforma de servidor (PHP, Python, Ruby on Rails, Java, Node.js, Go, etc.), que admite la carga de archivos estándar a través de un formulario HTML.
Comencé a mirar el código fuente del paquete y me concentré en un par de archivos PHP en el directorio server / php. Los archivos se llamaron upload.php y UploadHandler.php. upload.php llamado UploadHandler.php, donde se encontraba el código de carga del archivo principal. También noté que los archivos se cargaron en el directorio files / en la raíz del servidor web. Escribí un comando simple con curl y un script PHP primitivo que me confirmó que puedo cargar el archivo en el servidor y luego usarlo para ejecutar los comandos en el servidor.
$ curl -F "files=@shell.php" http://example.com/jQuery-File-Upload-9.22.0/server/php/index.php
Donde el archivo shell.php contiene:
<?php $cmd=$_GET['cmd']; system($cmd);?>
Al abrir una página en el navegador con el parámetro cmd = id del servidor de prueba, se devolvió el id del usuario desde el que se inició el proceso del servidor. Asumí que esta vulnerabilidad no pasó desapercibida y una búsqueda rápida en Google me confirmó que otros proyectos que usaban este código o sus derivados resultaron ser vulnerables. También hubo varios videos que muestran cómo atacar paquetes de software similares.
Notifiqué al autor de jQuery File Upload y comencé a documentar lo que encontré para asignar un número CVE. Pronto al día siguiente, un autor algo avergonzado me respondió, pidiendo más información, ya que no podía reproducir la vulnerabilidad en su entorno de prueba.
Después de comparar nuestras configuraciones de prueba por correo electrónico, descubrimos que los desarrolladores de Apache habían desactivado la compatibilidad con archivos .htaccess desde la versión 2.3.9. Resulta que esto se hizo para mejorar el rendimiento , por lo que el servidor no tiene que verificar este archivo cada vez que accede al directorio correspondiente. Además, este cambio también se realizó para evitar que los usuarios anulen las configuraciones de seguridad que se configuraron en el servidor.
Por lo tanto, Apache tenía buenas intenciones al deshabilitar .htaccess, pero sus cambios también pusieron en peligro a algunos desarrolladores y sus proyectos, en particular si contaban con la configuración de seguridad realizada en .htaccess.
En el caso de esta biblioteca, para manejar adecuadamente esta situación y corregir la vulnerabilidad de carga de archivos CVE-2018-9206, el desarrollador cambió el código para que solo permitiera descargar archivos de imagen.
Este problema es más de un proyecto.
También vale la pena señalar aquí que debido a los cambios en Apache, algunos de los 7,800 proyectos restantes pueden ser vulnerables a problemas de carga de archivos.
La mayoría de estos tenedores todavía tienen la vulnerabilidad original en su código. En algunos casos, la vulnerabilidad permanece incluso después de que el desarrollador editó el código original de Blueimp para incrustarlo en su proyecto, de modo que los proyectos aún son vulnerables a mi ejemplo de ataque con ligeras variaciones.
Esto significa que si alguno de estos proyectos se utiliza en producción, está expuesto a la vulnerabilidad de descargar un archivo con su posterior ejecución. Abre oportunidades para robar datos de la aplicación, inyecta malware, desfigura y otras oportunidades para dañar.
Desafortunadamente, no hay forma de determinar exactamente cuántos proyectos bifurcados de la carga original de archivos jQuery todavía se admiten activamente y aplicar los cambios realizados en el proyecto principal. Tampoco es posible determinar exactamente dónde se utilizan los proyectos bifurcados en la producción, si corresponde. Además, las versiones anteriores del proyecto también eran vulnerables a problemas con la descarga de archivos, hasta 2010.
Conclusión
Internet se basa en muchos mecanismos de seguridad para mantener nuestros sistemas, datos y transacciones seguros y protegidos. Si uno de estos mecanismos desaparece repentinamente, puede comprometer la seguridad de los usuarios y desarrolladores que confían en él.
Es una buena idea que los desarrolladores observen los cambios en los sistemas y bibliotecas en los que basan su proyecto. En este artículo, el mecanismo de seguridad que eliminó Apache no solo afectó la carga del archivo Jquery de Blueimp, sino también todas sus bifurcaciones y ramas. La vulnerabilidad afectó a muchos proyectos que dependen de ella, desde aplicaciones web independientes hasta complementos para WordPress y otros CMS.