PassRoleToNewLambdaThenTrigger
Lab: IAM vulnerable
Última actualización
Lab: IAM vulnerable
Última actualización
En este apartado se observará el ejemplo utilizando el laboratorio IAM vulnerable con el escenario privesc16. En este caso de explotación, el usuario de pruebas no tiene los permisos de invocar funciones lamba, solo mapear triggers a otro evento, en este caso a DynamoDB, por lo cual requiere que otro usuario actualice o que la base de datos se actualice para que funciones este caso de explotación.
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 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.
Usuario del laboratorio: privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-user con las políticas:
La cuenta de AWS debe contener un rol existente que incluya los permisos:
iam:AttachUserPolicy
dynamodb:GetRecords
dynamodb:GetShardIterator
dynamodb:DescribeStream
dynamodb:ListStreams
y las funciones de Lambda deben tener permitido asumir este rol.
La cuenta de AWS también necesita tener una tabla DynamoDB habilitada para transmisión.
Alternativamente, si no existe una tabla DynamoDB, este método de escalada de privilegios aún puede funcionar si el atacante tiene el permiso dynamodb:CreateTable.
Posterior mente generar llaves e acceso desde cuenta administrador para interactuar con el usuario en AWS CLI y configurar un perfil para el usuario privesc16-PassRoleToNewLambdaThenTriggerWithNewDynamo-user
Al momento de configurar el perfil, se tiene que tomar en cuenta la región, que sea la misma donde se encuentra la Base Dynamodb,
En este escenario, se tiene 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.
La función lambda en Python es la siguiente:
Para subir el archivo con el permiso lambda:Createfunction es necesario comprimir el archivo en formato zip con el nombre function.zip, después ejecutar el siguiente comando:
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.
Dado que el usuario actual 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.
Cuando otro usuario cambie, actualice o elimine datos de la base de DynamoDB, se ejecutará el trigger del lambda, a continuación se ejecutara un comando que actualiza la tabla simulando ser otro usuario AWS
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.