Problema 4494

El equipo de investigación de amenazas de Sysdig (TRT) observó recientemente un nuevo ataque que aprovechó credenciales de la nube robadas para atacar diez servicios de modelos de lenguaje grandes (LLM) alojados en la nube, conocido como LLMjacking. Las credenciales se obtuvieron de un objetivo popular, un sistema que ejecuta una versión vulnerable de Laravel (CVE-2021-3129). Los ataques contra sistemas de inteligencia artificial (IA) basados en LLM se han discutido a menudo, pero principalmente en torno al abuso rápido y la alteración de los datos de entrenamiento. En este caso, los atacantes pretenden vender el acceso LLM a otros ciberdelincuentes mientras el propietario de la cuenta en la nube paga la factura. Una vez obtenido el acceso inicial, exfiltraron las credenciales de la nube y obtuvieron acceso al entorno de la nube, donde intentaron acceder a los modelos LLM locales alojados por proveedores de la nube: en este caso, se atacó un modelo LLM Claude (v2/v3) local de Anthropic. Si no se descubre, este tipo de ataque podría resultar en más de $46,000 de costos de consumo de LLM por día para la víctima. Los investigadores de Sysdig descubrieron evidencia de un proxy inverso para LLM que se usa para proporcionar acceso a las cuentas comprometidas, lo que sugiere una motivación financiera. Sin embargo, otra posible motivación es extraer datos de entrenamiento de LLM. Amplitud de los objetivos ------------------ Pudimos descubrir las herramientas que generaban las solicitudes utilizadas para invocar los modelos durante el ataque. Esto reveló un script más amplio que podía verificar las credenciales de diez servicios de IA diferentes para determinar cuáles eran útiles para sus propósitos. Estos servicios incluyen: - AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter y GCP Vertex AI Los atacantes buscan obtener acceso a una gran cantidad de modelos LLM en diferentes servicios. En realidad, no se ejecutaron consultas LLM legítimas durante la fase de verificación. En cambio, se hizo lo suficiente para averiguar de qué eran capaces las credenciales y las cuotas. Además, también se consultan las configuraciones de registro cuando es posible. Esto se hace para evitar la detección al usar las credenciales comprometidas para ejecutar sus indicaciones. Antecedentes ---------- ### Modelos LLM hospedados Todos los principales proveedores de la nube, incluidos Azure Machine Learning, Vertex AI de GCP y AWS Bedrock, ahora hospedan servicios de modelos de lenguaje grande (LLM). Estas plataformas brindan a los desarrolladores un acceso fácil a varios modelos populares utilizados en la IA basada en LLM. Como se ilustra en la captura de pantalla a continuación, la interfaz de usuario está diseñada para la simplicidad, lo que permite a los desarrolladores comenzar a crear aplicaciones rápidamente. Sin embargo, estos modelos no están habilitados de forma predeterminada. En su lugar, se debe enviar una solicitud al proveedor de la nube para ejecutarlos. Para algunos modelos, es una aprobación automática; para otros, como los modelos de terceros, se debe completar un pequeño formulario. Una vez que se realiza una solicitud, el proveedor de la nube generalmente habilita el acceso con bastante rapidez. El requisito de realizar una solicitud suele ser más un obstáculo para los atacantes que un bloqueador, y no debe considerarse un mecanismo de seguridad. Los proveedores de la nube han simplificado el proceso de interacción con modelos de lenguaje alojados basados en la nube mediante el uso de comandos CLI sencillos. Una vez que las configuraciones y los permisos necesarios estén en su lugar, puede interactuar fácilmente con el modelo usando un comando similar a este: > aws bedrock-runtime invoke-model --model-id anthropic.claude-v2 --body '{"prompt": "\n\nHuman: story of two dogs\n\nAssistant:", "max_tokens_to_sample" : 300}' --cli-binary-format raw-in-base64-out invoke-model-output.txt ### Proxy inverso LLM El código de verificación de claves que verifica si las credenciales pueden usar LLM específicos también hace referencia a otro proyecto: OAI Reverse Proxy. Este proyecto de código abierto actúa como un proxy inverso para los servicios LLM. El uso de software como este permitiría a un atacante administrar de forma centralizada el acceso a múltiples cuentas LLM sin exponer las credenciales subyacentes o, en este caso, el grupo subyacente de credenciales comprometidas. Durante el ataque con las credenciales de la nube comprometidas, se observó que un agente de usuario que coincide con el proxy inverso de OAI intentaba usar modelos LLM. La imagen de arriba es un ejemplo de un proxy inverso de OAI que encontramos ejecutándose en Internet. No hay evidencia de que esta instancia esté vinculada a este ataque de ninguna manera, pero sí muestra el tipo de información que recopila y muestra. Cabe destacar especialmente los recuentos de tokens ("tookens"), los costos y las claves que potencialmente se están registrando. Este ejemplo muestra una instancia de proxy inverso OAI, que está configurada para usar varios tipos de LLM. No hay evidencia de que esta instancia esté involucrada en el ataque. Si los atacantes estuvieran reuniendo un inventario de credenciales útiles y quisieran vender el acceso a los modelos LLM disponibles, un proxy inverso como este podría permitirles monetizar sus esfuerzos. Análisis técnico ------------------ En este análisis técnico, exploramos cómo los atacantes navegaron por un entorno de nube para llevar a cabo su intrusión. Al emplear solicitudes de API aparentemente legítimas dentro del entorno de nube, probaron astutamente los límites de su acceso sin activar alarmas de inmediato. El siguiente ejemplo demuestra un uso estratégico de la llamada a la API InvokeModel registrada por CloudTrail. Aunque los atacantes emitieron una solicitud válida, establecieron intencionalmente el parámetro max_tokens_to_sample en -1. Este parámetro inusual, que generalmente se espera que active un error, en cambio cumplió un doble propósito. Confirmó no solo la existencia de acceso a los LLM, sino también que estos servicios estaban activos, como lo indica la ValidationException resultante. Un resultado diferente, como un error AccessDenied, habría sugerido un acceso restringido. Este sondeo sutil revela un enfoque calculado para descubrir qué acciones permitían sus credenciales robadas dentro de la cuenta en la nube. ### InvokeModel CloudTrail registra la llamada InvokeModel y a continuación se puede ver un ejemplo de evento malicioso. Enviaron una solicitud legítima pero especificaron que "max_tokens_to_sample" era -1. Este es un error no válido que provoca el error "ValidationException", pero es información útil para el atacante porque le indica que las credenciales tienen acceso a los LLM y que se han habilitado. De lo contrario, habrían recibido un error "AccessDenied". { "eventVersion": "1.09", "userIdentity": { "type": "IAMUser", "principalId": "[CENSURADO]", "arn": "[CENSURADO]", "accountId": "[CENSURADO]", "accessKeyId": "[CENSURADO]", "userName": "[CENSURADO]" }, "eventTime": "[CENSURADO]", "eventSource": "bedrock.amazonaws.com", "eventName": "InvokeModel", "awsRegion": "us-east-1", "sourceIPAddress": "83.7.139.184", "userAgent": "Boto3/1.29.7 md/Botocore#1.32.7 ua/2.0 os/windows#10 md/arch#amd64 lang/python#3.12.1 md/pyimpl#CPython cfg/retry-mode#legacy Botocore/1.32.7", "errorCode": "ValidationException", "errorMessage": "max_tokens_to_sample: rango: 1..1,000,000", "requestParameters": { "modelId": "anthropic.claude-v2" }, "responseElements": null, "requestID": "d4dced7e-25c8-4e8e-a893-38c61e888d91", "eventID": "419e15ca-2097-4190-a233-678415ed9a4f", "readOnly": verdadero, "eventType": "AwsApiCall", "managementEvent": verdadero, "recipientAccountId": "[CENSURADO]", "eventCategory": "Administración", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "bedrock-runtime.us-east-1.amazonaws.com" } }Lenguaje del código: Perl (perl) Ejemplo de registro de Cloudtrail AWS Bedrock no es compatible con todas las regiones, por lo que los atacantes llamaron a "InvokeModel" solo en las regiones compatibles. En este momento, Bedrock es compatible con us-east-1, us-west-2, ap-southeast-1, ap-northeast-1, eu-central-1, eu-west-3 y us-gov-west-1, como se muestra aquí. Hay diferentes modelos disponibles según la región; Aquí se incluye la lista de modelos compatibles con la región de AWS. ### GetModelInvocationLoggingConfiguration Curiosamente, los atacantes mostraron interés en cómo se configuró el servicio. Esto se puede hacer llamando a "GetModelInvocationLoggingConfiguration", que devuelve la configuración de registro de S3 y Cloudwatch si está habilitada. En nuestra configuración, usamos tanto S3 como Cloudwatch para recopilar la mayor cantidad posible de datos sobre el ataque. { "loggingConfig": { "cloudWatchConfig": { "logGroupName": "[REDACTADO]", "roleArn": "[REDACTADO]", "largeDataDeliveryS3Config": { "bucketName": "[REDACTADO]", "keyPrefix": "[REDACTADO]" } }, "s3Config": { "bucketName": "[REDACTADO]", "keyPrefix": "" }, "textDataDeliveryEnabled": true, "imageDataDeliveryEnabled": true, "embeddingDataDeliveryEnabled": true } }Lenguaje del código: Perl (perl) Ejemplo de respuesta GetModelInvocationLoggingConfiguration La información sobre los mensajes que se ejecutan y sus resultados no se almacena en Cloudtrail. En cambio, se debe realizar una configuración adicional para enviar esa información a Cloudwatch y S3. Esta comprobación se realiza para ocultar los detalles de sus actividades de cualquier observación detallada. OAI Reverse Proxy afirma que no utilizará ninguna clave de AWS que tenga habilitado el registro por razones de "privacidad". Esto hace que sea imposible inspeccionar los mensajes y las respuestas si están utilizando el vector AWS Bedrock. Impacto ------ En un ataque de LLMjacking, el daño se presenta en forma de mayores costos para la víctima. No debería sorprendernos saber que usar un LLM no es barato y que ese costo puede aumentar muy rápidamente. Teniendo en cuenta el peor escenario posible, en el que un atacante abuse de Anthropic Claude 2.x y alcance el límite de cuota en varias regiones, el costo para la víctima puede ser de más de $46 000 por día. Según los precios y el límite de cuota inicial para Claude 2: - 1000 tokens de entrada cuestan $0.008, 1000 tokens de salida cuestan $0.024. - Se pueden procesar un máximo de 500,000 tokens de entrada y salida por minuto según AWS Bedrock. Podemos considerar el costo promedio entre tokens de entrada y salida, que es $0.016 para 1000 tokens. Lo que lleva al costo total: (500K tokens/1000 * $0.016) * 60 minutos * 24 horas * 4 regiones = $46,080 / día Al maximizar los límites de cuota, los atacantes también pueden bloquear a la organización comprometida para que no use los modelos de manera legítima, lo que interrumpe las operaciones comerciales. Detección --------- La capacidad de detectar y responder rápidamente a amenazas potenciales puede marcar la diferencia a la hora de mantener una defensa sólida. A partir de información obtenida de comentarios recientes y las mejores prácticas de la industria, hemos destilado estrategias clave para elevar sus capacidades de detección: - Detecciones de registros en la nube: herramientas como Falco, Sysdig Secure y CloudWatch Alerts son aliados indispensables. Las organizaciones pueden identificar de forma proactiva comportamientos sospechosos mediante el monitoreo de la actividad en tiempo de ejecución y el análisis de registros en la nube, incluidas tácticas de reconocimiento como las empleadas en AWS Bedrock. - Registro detallado: el registro integral, incluido el registro detallado, ofrece una visibilidad invaluable del funcionamiento interno de su entorno en la nube. La información detallada sobre las invocaciones de modelos y otras actividades críticas brinda a las organizaciones una comprensión matizada sobre la actividad en sus entornos en la nube. ### Detecciones de registros en la nube El monitoreo de registros en la nube puede revelar actividad sospechosa o no autorizada. Con Falco o Sysdig Secure, se pueden detectar los métodos de reconocimiento utilizados durante el ataque y se puede iniciar una respuesta. Para los clientes de Sysdig Secure, esta regla se puede encontrar en la política de eventos notables de AWS de Sysdig. Regla de Falco: - rule: Bedrock Model Recon Activity desc: Detecta intentos de reconocimiento para verificar si Amazon Bedrock está habilitado, según el código de error. Los atacantes pueden aprovechar esto para descubrir el estado de Bedrock y luego abusar de él si está habilitado. condición: jevt.value[/eventSource]="bedrock.amazonaws.com" y jevt.value[/eventName]="InvokeModel" y jevt.value[/errorCode]="ValidationException" salida: Se realizó un intento de reconocimiento en Amazon Bedrock (usuario solicitante=%aws.user, IP solicitante=%aws.sourceIP, región AWS=%aws.region, arn=%jevt.value[/userIdentity/arn], userAgent=%jevt.value[/userAgent], modelId=%jevt.value[/requestParameters/modelId]) prioridad: WARNINGLenguaje del código: Perl (perl) Además, las alertas de CloudWatch se pueden configurar para manejar comportamientos sospechosos. Varias métricas de tiempo de ejecución para Bedrock se pueden monitorear para activar alertas. ### Registro detallado Monitorear el uso de los servicios del modelo de lenguaje (LLM) de su organización es crucial, y varios proveedores de la nube brindan instalaciones para agilizar este proceso. Esto generalmente implica configurar mecanismos para registrar y almacenar datos sobre las invocaciones del modelo. Para AWS Bedrock específicamente, los usuarios pueden aprovechar CloudWatch y S3 para obtener capacidades de monitoreo mejoradas. CloudWatch se puede configurar creando un grupo de registro y asignando un rol con los permisos necesarios. De manera similar, para iniciar sesión en S3, se requiere un depósito designado como destino. Es importante tener en cuenta que el registro de CloudTrail del comando InvokeModel no captura detalles sobre la entrada y salida del mensaje. Sin embargo, la configuración de Bedrock permite una fácil activación del registro de invocación del modelo. Además, para los datos de entrada o salida del modelo mayores a 100 kb o en formato binario, los usuarios deben especificar explícitamente un destino S3 para manejar la entrega de datos de gran tamaño. Esto incluye imágenes de entrada y salida, que se almacenan en los registros como cadenas Base64. Estos mecanismos de registro integrales garantizan que todos los aspectos del uso del modelo se controlen y archiven para su posterior análisis y cumplimiento. Los registros contienen información adicional sobre los tokens procesados, como se muestra en el siguiente ejemplo: { "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "[REDACTED]", "accountId": "[REDACTED]", "identity": { "arn": "[REDACTED]" }, "region": "us-east-1", "requestId": "bea9d003-f7df-4558-8823-367349de75f2", "operation": "InvokeModel", "modelId": "anthropic.claude-v2", "input": { "inputContentType": "application/json", "inputBodyJson": { "prompt": "\n\nHuman: Escribe una historia de un joven mago\n\nAssistant:", "max_tokens_to_sample": 300 }, "inputTokenCount": 16 }, "output": { "outputContentType": "application/json", "outputBodyJson": { "completion": " Esta es una historia sobre un joven mago:\n\nMartin era un niño común que vivía en un pequeño pueblo. Ayudaba a sus padres en su modesta granja, cuidando a los animales y trabajando en los campos. [...] La materia favorita de Martin era la transfiguración, el arte de transformar objetos de una cosa a otra. Dominó la materia rápidamente, asombrando a sus profesores al convertir ratones en copas y piedras en pájaros revoloteando.\n\nMartin", "stop_reason": "max_tokens", "stop": null }, "outputTokenCount": 300 } }Lenguaje del código: Perl (perl) Ejemplo de registro S3 Recomendaciones --------------- Este ataque podría haberse prevenido de varias formas, incluyendo: - Gestión de vulnerabilidades para prevenir el acceso inicial. - Gestión de secretos para garantizar que las credenciales no se almacenen sin cifrar y puedan ser robadas. - CSPM/CIEM para garantizar que la cuenta abusada tuviera la menor cantidad de permisos que necesitaba. Como se destaca en una investigación reciente, los proveedores de la nube ofrecen una variedad de herramientas y prácticas recomendadas diseñadas para mitigar los riesgos de ataques a la nube. Estas herramientas ayudan a las organizaciones a crear y mantener un entorno de nube seguro desde el principio. Por ejemplo, AWS ofrece varias medidas de seguridad sólidas. La arquitectura de referencia de seguridad de AWS describe las mejores prácticas para construir de forma segura su entorno de nube. Además, AWS recomienda utilizar políticas de control de servicios (SCP) para administrar de forma centralizada los permisos, lo que ayuda a minimizar el riesgo asociado con cuentas con permisos excesivos que podrían ser objeto de abuso. Estas pautas y herramientas son parte del compromiso de AWS de mejorar la seguridad y brindar a los clientes los recursos para proteger su infraestructura de nube de manera eficaz. Otros proveedores de nube ofrecen marcos y herramientas similares, lo que garantiza que los usuarios tengan acceso a medidas de seguridad esenciales para salvaguardar sus datos y servicios independientemente de la plataforma. Conclusión ---------- Las credenciales de nube y SaaS robadas siguen siendo un vector de ataque común. Esta tendencia solo aumentará en popularidad a medida que los atacantes aprendan todas las formas en que pueden aprovechar su nuevo acceso para obtener ganancias financieras. El uso de servicios LLM puede ser costoso, según el modelo y la cantidad de tokens que se le proporcionen. Normalmente, esto haría que un desarrollador intente ser eficiente; lamentablemente, los atacantes no tienen el mismo incentivo. La detección y la respuesta son fundamentales para abordar cualquier problema rápidamente. ### Direcciones IP de IoC 83.7.139.184 83.7.157.76 73.105.135.22883.7.135.97