Guy Nachson ha comentado recientemente una nueva técnica donde sin alterar ninguna línea de código, los atacantes se hacían con el control del gestor de paquetes (NPM) de la librería bignum. Esta librería se utiliza para la aritmética de precisión integral de Node.js utilizando OpenSSL.
¿Cómo se ha llegado a esto? y ¿es realmente una nueva técnica de ataque?
Spoiler: Aunque se hable de ataque, no se trata de una brecha de seguridad sino más bien de malas prácticas en el uso de S3.
Background
A raíz de la publicación de seguridad en GitHub advisory se ha visto que las versiones de bignum (desde la versión 0.12.2 hasta la 0.13.0, ambas inclusives) utilizan node-pre-gyp, una línea de comando que proporciona una forma de implementar módulos de nodo nativos con binarios precompilados. Dichos binarios se encontraban publicados en un bucket S3 que expiró y que ahora ha sido reclamado por un tercero. Una vez obtienen el control del bucket, sirven binarios que contienen malware, permitiéndoles extraer información de los usuarios.
Nota Antes de entrar en pánico, si utilizas la última versión, v0.13.1, no tendrás problemas ya que ésta no utiliza node-pre-gyp. Y un dato más, la versión 0.13.1 fue publicada ¡hace más de 3 años!. Si te ha pillado el toro, mejor mira los procesos de actualización y ciclo de vida que tienes para tus aplicaciones, así como las nuevas funcionalidades de S3. Probablemente es ahí donde tengas el problema.
Pero empecemos desde el principio y veamos cómo se ha llegado hasta ese punto:
¿Qué es un NPM (Node Package Manager)?
Un gestor de paquetes de node, o NPM, es la herramienta por defecto de JavaScript para compartir e instalar paquetes. Consta de dos partes:
- Una herramienta CLI para la publicación, manejo de dependencias y descarga de paquetes.
- Un repositorio en línea para publicar los paquetes de software que serán utilizados en projectos Node.js.
Y es a través del repositorio donde se ha producido el ataque. Estos paquetes se servían desde un bucket S3 de AWS.
¿Qué es un bucket de S3?
Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento en la nube. Se trata de un recurso virtual que actúa como un directorio donde poder almacenar objetos (datos y metadatos). Es probablemente uno de los servicios más populares en AWS y proporciona una solución escalable para el almacenamiento de objetos a través de API.
¿Por qué debería preocuparme?
AWS S3 proporciona diferentes permisos de acceso que, si se configuran incorrectamente, pueden dejar la puerta abierta a un acceso no autorizado, lo que potencialmente conduce a ataques maliciosos.
Imaginad qué ocurriría si tomamos un snapshot de una instancia EC2 y lo almacenamos en un bucket de S3. La información contenida en la instancia e incluso las claves que dan acceso a otros servicios o instancias también se almacenan en S3. Si no hay una configuración adecuada, podríamos dejar la puerta abierta a problemas.
¿Cómo se ha llegado a este punto?
Los buckets se crean para cubrir necesidades de almacenamiento y están asociados a un dominio específico. Cuando terminan de cumplir su propósito si no los gestionamos correctamente, podemos dar pie a casos como el que os estamos contando.
Vayamos con un ejemplo sencillo:
Imaginad que hemos creado un bucket S3 y tenemos la siguiente URL https://awscharlastenicas.s3.eu-south-1.amazonaws.com. Hemos decidido vincular esta URL a https://AWSTechTalks.com para no mostrar el link de S3 (pero sobre todo, para que los oyentes de este podcast puedan recordar una dirección de forma más sencilla). Esto lo podéis hacer añadiendo un registro CNAME en vuestro DNS lo que os permite asignar un alias a un nombre de dominio como el del ejemplo.
Después de unos años y tras un éxito en el canal, decidimos eliminar el bucket, pero se nos olvida quitar el registro de CNAME en Route53. Si un atacante se da cuenta de este error podría crear un nuevo bucket S3 con el mismo nombre y servir contenido malicioso desde el dominio AWSTechTalks.com.
En el caso de bignum los atacantes descubrieron que el bucket S3 había sido abandonado y dada la forma en la que operaba la librería, se convirtió en una mina de oro. Recordar que las versiones anteriores de bignum utilizaba node-gyp para descargar un archivo binario durante la instalación. Este archivo estaba inicialmente alojado en un bucket S3. A esto hay que añadirle que cada bucket en S3 tiene un nombre único a nivel global. Cuando se elimina el bucket, el nombre vuelve a estar disponible. Si un paquete apuntaba a un bucket como su fuente, el puntero seguirá existiendo incluso después de eliminar el bucket.
El resultado ya lo sabemos. Los atacantes colocaron un binario que realizaba las mismas actividades que el original, pero además añadieron un pequeño “complemento” que les permitiera extraer las credenciales de usuario. Esto lo hacían dentro del encabezado “user-agent” de una solicitud GET.
Fig. 1. Adaptación ataque bignum. Fuente: Checkmarx.com
¿Cómo obtienen información de buckets de terceros?
Lamentablemente en la red existen herramientas que permiten buscar buckets de S3 que sean públicos, como Grayhat Warefare, Bucket Finder, S3 Scanner, o S3 Inspector. Una vez localizados puedes crear tus propios scripts para buscar aquellos que tengan vulnerabilidades.
¿Realmente es un nuevo tipo de ataque?
Aunque lo parezca, no lo es. Hace unos años vimos una situación muy similar cuando algunos desarrolladores utilizaron un mirror del repositorio de yum entregado desde un bucket de S3. Cuando el proveedor dejó de dar soporte y eliminó el mirror, ocurrió lo mismo, alguien tomó el control de bucket y lo sustituyó por malware.
Para evitar que esto os ocurra, es recomendable:
1.- Revisar minuciosamente los registros DNS de tu organización cada vez que se termine un bucket de S3. Esto garantizará que no haya entradas DNS/CNAME que apunten a buckets de S3 inexistentes y que podrían ser explotados.
2.- Vaciar el bucket pero NO eliminarlo, así mantienes el nombre único global bajo custodia.
3.- Sigue las mejores prácticas para securizar tus buckets S3: Link1, Link2
En próximos blogs veremos cómo evitar alguna de estas situaciones. Hasta entonces, sed buenos!
Top comments (0)