Bienvenido a nuestro blog.

Prevención de la apropiación total de la nube mediante ataques SSRF

Esta es la historia de un atacante que obtuvo acceso a los buckets de Amazon S3 de una startup, a variables de entorno y a varios secretos internos de la API, todo a través de un simple formulario que envía un correo electrónico. Aunque se trata de una historia real, mantendré en secreto el nombre de la startup.

Cómo entraron

Todo comienza con una aplicación PHP que envía un correo electrónico. Para cargar algunas de las imágenes de lujo en el correo electrónico como archivos adjuntos, la aplicación necesita descargarlas. En PHP esto es fácil. Se utiliza la función file_get_contents y ahí es donde empieza la diversión.

Por supuesto, algunas de las entradas del usuario para este correo electrónico no estaban totalmente verificadas o codificadas en HTML, por lo que un usuario podía incluir una imagen como <img src=’evil.com’/>. Ahora, en teoría, esto no es tan malo, pero tristemente esta función PHP es muy poderosa y puede hacer mucho más que cargar imágenes a través de Internet. También puede leer archivos locales y lo que es más importante: archivos a través de la red local en lugar de Internet.

En lugar de evil.com, el atacante introdujo una URL local especial. Puedes utilizar esta URL para obtener las credenciales IAM vinculadas al rol del servidor AWS EC2 que estás ejecutando con una simple solicitud GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

El resultado fue que el atacante recibió un correo electrónico que incluía las credenciales IAM para el servidor EC2 en un archivo adjunto en el buzón. Esas claves dan al atacante la capacidad de hacerse pasar por ese servidor al hablar con varios servicios de AWS. A partir de ahí todo va cuesta abajo...

¿Por qué es esto posible?

El sistema que carga estas claves IAM se llama IMDSv1 y Amazon lanzó una nueva versión en 2019 llamada IMDSv2. Con IMDSv2, necesita enviar una solicitud PUT con un encabezado especial para obtener sus credenciales IAM. Eso significa que una simple función de carga de URL basada en GET como file_get_contents ya no puede causar tanto daño.

No está claro cuál será la adopción de IMDSv2 a partir de 2023, pero está claro que Amazon sigue tomando medidas para aumentar su adopción y estamos viendo que IMDSv1 todavía se utiliza en la naturaleza.

El compromiso de las claves IAM lleva a más compromisos: Los buckets S3 podían ser listados y sus contenidos leídos. Para empeorar las cosas, uno de los buckets S3 contenía una plantilla cloudformation, que contenía variables de entorno sensibles (por ejemplo, las claves API de Sendgrid).

¿Cómo defiendo mi infraestructura de nube contra esto?

Ahora bien, ¿qué se podría hacer para evitar esta pérdida total de datos? Sus desarrolladores podrían ser muy cuidadosos y tener cuidado de utilizar una allowlist para las URLs que pasan a file_get_contents. Incluso podrían verificar que el contenido que reciben es una imagen si están esperando una imagen. Sin embargo, la realidad es que este tipo de errores son difíciles de evitar como desarrollador.

Sería mucho mejor asegurarse de que su infraestructura tiene defensas adicionales contra estos ataques. Nuestra nueva integración con AWS dentro de Aikido security te alertará si tu nube no toma activamente alguna de las siguientes medidas. Cada una de estas medidas por sí sola habría detenido este ataque en particular, pero recomendamos implementarlas todas. Utilice nuestra cuenta de prueba gratuita para ver si su nube ya está defendida contra estas amenazas. Vea cómo Aikdido protege su aplicación contra vulnerabilidades aquí.

Pasos a seguir:

1. Migre sus nodos EC2 IMDSv1 existentes para utilizar IMDSv2
2. No almacene ningún secreto en el entorno de sus servidores web ni en las plantillas de formación en la nube. Utilice una herramienta como AWS Secrets Manager para cargar los secretos en tiempo de ejecución.
3. Cuando asigne roles IAM a sus servidores EC2, asegúrese de que tienen condiciones adicionales, como restringirlos para que solo se puedan utilizar desde dentro de su red local de AWS (su VPC). El siguiente ejemplo permite a tu servidor leer desde S3, pero sólo si el servidor EC2 se comunica a través de un endpoint VPC específico. Eso sólo es posible desde dentro de su red, por lo que el atacante no habría sido capaz de llegar a los buckets de S3 desde su máquina local.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

Acerca de "The Kill Chain

The Kill Chain es una serie de historias reales de atacantes que llegan a las joyas de la corona de las empresas de software encadenando múltiples vulnerabilidades. Escrito por Willem Delbare, aprovechando sus diez años de experiencia en la construcción y el apoyo a startups SaaS como CTO. Los relatos proceden directamente de la red de Willem y todos han sucedido realmente.

La startup belga de SaaS Aikido Security ha recaudado 2 millones de euros en financiación inicial de inversores ángeles de renombre que apoyan su misión de simplificar la seguridad del software para los desarrolladores.

En los últimos años se ha producido un cambio en la industria del software hacia el desarrollo "a la izquierda", lo que ha hecho que la responsabilidad de la seguridad recaiga cada vez más en los desarrolladores. Por desgracia, las plataformas de seguridad de software actuales son difíciles de usar para los desarrolladores, lo que les hace perder mucho tiempo. Aikido Security se ha fundado para responder a este reto.

La ronda de pre-semilla tiene la suerte de contar con el apoyo de una serie de inversores (ángeles) cualificados. Syndicate One, Pieterjan Bouten (Showpad), Louis Jonckheere (Showpad), Christophe Morbee (Besox), Mathias Geeroms (OTA Insight) han decidido participar. Aikido Security tiene la suerte de poder contar con su apoyo y experiencia.

"Las herramientas de seguridad de software me han complicado la vida como director de tecnología"

afirma el fundador y director técnico de Aikido Security, Willem Delbare. "He probado muchos de ellos y todos adolecen de los mismos problemas. Te sobrecargan con falsos positivos, te bombardean con notificaciones y dificultan la clasificación. Para mí es agotador. Hemos decidido solucionarlo".

El equipo está formado por emprendedores experimentados que han creado productos de éxito en diversos sectores antes de unirse en Aikido Security. El equipo fundador está formado por Willem Delbare (Teamleader, Officient), Roeland Delrue (Showpad, Officient), Amber Rucker (Veriff, Cloudbees) y Felix Garriau (nexxworks, AREA42).

Aikido ha completado recientemente la versión alfa de su producto, que está probando activamente con clientes pioneros. La financiación permite a la empresa ampliar el equipo y completar las características del producto, además de ampliar su base de clientes.

Acerca de Aikido Security

Aikido Security es una plataforma de seguridad de software que da prioridad a los desarrolladores. Escaneamos su código fuente y la nube para mostrarle qué vulnerabilidades son realmente importantes de resolver. El triaje se acelera reduciendo masivamente los falsos positivos y haciendo los CVE legibles por humanos. Aikido simplifica el mantenimiento de la seguridad de su producto y le devuelve tiempo para hacer lo que mejor sabe hacer: escribir código.

Los archivos de bloqueo desempeñan un papel vital en la seguridad de la cadena de suministro de software mediante una gestión coherente de las dependencias. Especifican las versiones exactas de las dependencias utilizadas, garantizando la reproducibilidad y evitando cambios inesperados.

En un entorno de desarrollo vertiginoso repleto de bibliotecas de código abierto y paquetes de terceros, los archivos de bloqueo actúan como defensa contra los ataques a la cadena de suministro. Al bloquear las dependencias a versiones específicas, impiden las actualizaciones automáticas a versiones potencialmente comprometidas.

Muchos equipos de desarrollo pasan por alto los archivos de bloqueo y no aprovechan todo su potencial. Este artículo destaca la importancia de los archivos de bloqueo para garantizar la integridad y seguridad de los proyectos de software.

Archivos de bloqueo

Los archivos de bloqueo son archivos que capturan las versiones exactas de cada dependencia y sus subdependencias en un proyecto. Garantizan la uniformidad de las versiones de las dependencias en todas las instancias de un proyecto, lo que evita el "infierno de las dependencias" y los posibles riesgos de seguridad.

Los archivos de bloqueo son diferentes para cada idioma y pueden variar en función de los frameworks, pero en general siguen formatos similares.

Javascript - yarn.lock

lodash@^4.17.15:
  versión "4.17.21"
 resuelto "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz#acfcd7438b5d260f06a1d052c2a3b32ddc91c6b8"
 integridad sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw==

react@^17.0.1:
  version "17.0.2"
 resolved "https://registry.yarnpkg.com/react/-/react-17.0.2.tgz#cdc8d94b0d7091f440c51d1427ff2a3d6e14e664"
 integrity sha512-y8vQ43+qMOpbD/3k1Vw4E4i4UgFqxMwI0AZc5fxyIfZK4kHRZ5Klg5zh/5Nq1Nk3JZqf6byFAkyoGZkbSnYt9w==

Python - poesía.lock

[[package]]
name = "requests"
version = "2.25.1"
description = "Python HTTP for Humans."
category = "main"
optional = false
python-versions = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, <4"

[package.dependencies]
certifi = ">=2017.4.17"
chardet = ">=3.0.2,<5"
idna = ">=2.5,<3"
urllib3 = ">=1.21.1,<1.27"

Esta entrada especifica el nombre del paquete (click), los hashes aceptados y la versión exacta (8.0.3). Esta especificidad garantiza la coherencia de las instalaciones en los entornos de desarrollo, pruebas y producción.

Los gestores de paquetes generan archivos de bloqueo durante la instalación o actualización de dependencias. Es esencial enviar estos archivos al control de versiones junto con el código fuente del proyecto. Esta práctica garantiza que todos los colaboradores del proyecto utilicen dependencias idénticas, lo que reduce las incoherencias y hace que las compilaciones sean más predecibles.

Diferentes lenguajes y gestores de paquetes tienen sus propios formatos de archivos de bloqueo: Node.js utiliza package-lock.json para npm, Python utiliza Pipfile.lock para Pipenv, y Ruby utiliza Gemfile.lock para Bundler. El uso de archivos de bloqueo ayuda a mantener una base de proyecto coherente y segura, reduciendo los riesgos asociados a la gestión de dependencias.

Defensa contra los ataques a la cadena de suministro

Los ataques a la cadena de suministro en dependencias de código abierto son cada vez más comunes. Los atacantes pueden comprometer una biblioteca popular, inyectando código malicioso que se propaga a los proyectos dependientes. Los archivos de bloqueo ofrecen una sólida defensa contra estos ataques.

Al especificar las versiones exactas de las dependencias, los archivos de bloqueo evitan las actualizaciones automáticas a versiones potencialmente comprometidas. Esto es crucial cuando se identifican vulnerabilidades en las dependencias. Con los archivos de bloqueo, los proyectos permanecen estables con versiones seguras conocidas hasta que el equipo decide actualizar tras realizar pruebas exhaustivas.

A continuación se muestra un ejemplo de paquete-lock.json utilizado en proyectos Node.js para bloquear versiones de dependencias específicas. Esto garantiza que todo el mundo que trabaje en el proyecto instale exactamente las mismas versiones, fomentando la coherencia y la seguridad.

{
  "name": "my-project",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "my-project",
      "version": "1.0.0",
      "dependencies": {
        "lodash": "4.17.21",
        "axios": "0.21.1"
      }
    },
    "node_modules/lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "node_modules/axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "dependencies": {
        "follow-redirects": "^1.10.0"
      }
    },
    "node_modules/follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  },
  "dependencies": {
    "lodash": {
      "version": "4.17.21",
      "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "integrity": "sha512-v2kDE6syb5rK+X8bykjh3W7n4P3NV8axFypa8DwO8DK+RVZk9vft6xEhjxzIlc6DCwCPkMKSk4eQF6QNHOu9pw=="
    },
    "axios": {
      "version": "0.21.1",
      "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
      "integrity": "sha512-pbkHfFgC6F4ltGeoyTeHRtUkZo/FZ9EoElV3MzDLeO2uYxLqGm6Qcbx93jUOJISyYSC/tzjK4NHH3MAYsDKUTA==",
      "requires": {
        "follow-redirects": "^1.10.0"
      }
    },
    "follow-redirects": {
      "version": "1.14.1",
      "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
      "integrity": "sha512-0gh4nEbdUdDra9mJKpAB+Y4gG61sQiKsbiqS8c5LEnFOh8fbov3/xp0FnWE2+IxKTozhJSdEV8ujvQjU+Ub3dg=="
    }
  }
}

Qué hace este archivo

• Cerraduras Versiones específicas:
  Bloquea lodash en la versión 4.17.21 y axios en 0.21.1. Independientemente de cuándo o dónde instale este proyecto, se utilizarán estas versiones exactas, lo que evitará actualizaciones accidentales a versiones que puedan contener cambios de última hora o problemas de seguridad.
• Captura del árbol de relaciones:
  Incluye dependencias anidadas, como follow-redirectsutilizado internamente por axios.
• Admite herramientas de seguridad:
  Herramientas como Aikido utilizar este archivo de bloqueo para buscar vulnerabilidades conocidas. Dado que el archivo contiene URLs resueltas y hashes de versiones, los escáneres pueden:
  • Identificar con precisión los paquetes de riesgo.
  • Recomendar alternativas parcheadas o seguras.
  • Seguimiento de los cambios en las dependencias a lo largo del tiempo.

Riesgos de ignorar los archivos de bloqueo

Descuidar los archivos de bloqueo puede desestabilizar y comprometer los proyectos de software. Sin archivos de bloqueo, las versiones de las dependencias pueden variar de un entorno a otro, dando lugar a incoherencias que complican la depuración. Estas variaciones pueden provocar fallos elusivos, retrasar los proyectos y aumentar las cargas de mantenimiento.

Sin un archivo de bloqueo, el seguimiento de las dependencias se convierte en un reto. La ausencia de un registro claro dificulta la determinación de las versiones utilizadas, lo que complica la gestión de la cadena de suministro. En caso de vulnerabilidad, los desarrolladores tienen dificultades para identificar rápidamente las dependencias de riesgo, lo que retrasa los tiempos de respuesta.

Las actualizaciones automáticas plantean riesgos significativos cuando no existen archivos de bloqueo. Las actualizaciones incontroladas pueden introducir paquetes comprometidos, exponiendo los proyectos a brechas de seguridad. Incluso las bibliotecas de buena reputación pueden albergar amenazas ocultas, por lo que la supervisión de los archivos de bloqueo es crucial para mantener una base de código segura.

Buenas prácticas para el uso de ficheros de bloqueo

Integre los archivos de bloqueo en su flujo de trabajo de desarrollo para sacarles el máximo partido. La inclusión de archivos de bloqueo en el control de versiones establece una única fuente de verdad para las dependencias, promoviendo un entorno de desarrollo coherente. Este enfoque reduce las variaciones no deseadas y mejora la fiabilidad de la producción.

La actualización y revisión periódicas de los archivos de bloqueo es vital para la detección temprana de amenazas. Esta estrategia proactiva ayuda a los equipos a abordar rápidamente las vulnerabilidades, manteniendo una postura de seguridad sólida. Utilice herramientas de evaluación continua de dependencias para automatizar la detección de riesgos en la cadena de suministro de software.

Anclar las dependencias a versiones específicas en archivos de manifiesto añade seguridad. Esta práctica complementa los archivos de bloqueo y sirve como red de seguridad en caso de discrepancias. Educar a los equipos de desarrollo sobre la importancia de los archivos de bloqueo refuerza la gestión diligente de las dependencias, mejorando la seguridad general.

Actualización de dependencias con archivos de bloqueo

Mantener actualizadas las dependencias requiere combinar la automatización con una revisión exhaustiva. Las actualizaciones rutinarias de los ficheros de bloqueo deben formar parte de los ciclos de desarrollo, incorporando las últimas mejoras y correcciones de seguridad al tiempo que se mantiene la coherencia. Las actualizaciones periódicas minimizan las interrupciones inesperadas y refuerzan la seguridad.

Herramientas automatizadas como Dependabot ayudan a gestionar las actualizaciones generando pull requests para nuevas versiones de dependencias. Estas herramientas proporcionan una supervisión continua, lo que permite realizar actualizaciones a tiempo y que los equipos puedan centrarse en otras tareas. Sin embargo, es fundamental revisar los cambios para asegurarse de que satisfacen las necesidades del proyecto y evitar problemas.

También es esencial desarrollar un proceso manual de actualización del fichero de bloqueo. Despliegue las dependencias actualizadas en un entorno de prueba para evaluar el impacto y la compatibilidad. Este enfoque evita interrupciones y mantiene la coherencia, minimizando los riesgos derivados de los frecuentes cambios de versión.

La incorporación de archivos de bloqueo a su proceso de desarrollo refuerza su cadena de suministro de software frente a las cambiantes amenazas a la seguridad. La adopción de las mejores prácticas y el fomento de la concienciación sobre las dependencias dentro de su equipo son fundamentales para mantener una base de código sólida. ¿Está preparado para mejorar la seguridad de su cadena de suministro? Empiece gratis con Aikido y simplifique su viaje hacia la seguridad.