AWS - Step Functions Privesc
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Para más información sobre este servicio de AWS, consulta:
AWS - Step Functions EnumEstas técnicas de escalación de privilegios van a requerir el uso de algunos recursos de funciones de paso de AWS para realizar las acciones de escalación de privilegios deseadas.
Para verificar todas las acciones posibles, puedes ir a tu propia cuenta de AWS, seleccionar la acción que te gustaría usar y ver los parámetros que está utilizando, como en:
O también puedes ir a la documentación de la API de AWS y revisar la documentación de cada acción:
states:TestState & iam:PassRoleUn atacante con los permisos states:TestState y iam:PassRole puede probar cualquier estado y pasar cualquier rol de IAM a él sin crear o actualizar una máquina de estados existente, lo que permite el acceso no autorizado a otros servicios de AWS con los permisos del rol. potencialmente. Combinados, estos permisos pueden llevar a acciones no autorizadas extensas, desde manipular flujos de trabajo para alterar datos hasta filtraciones de datos, manipulación de recursos y escalación de privilegios.
Los siguientes ejemplos muestran cómo probar un estado que crea una clave de acceso para el admin usuario aprovechando estos permisos y un rol permisivo del entorno de AWS. Este rol permisivo debería tener asociada alguna política de alto privilegio (por ejemplo arn:aws:iam::aws:policy/AdministratorAccess) que permita al estado realizar la acción iam:CreateAccessKey:
stateDefinition.json:
Comando ejecutado para realizar el privesc:
Impacto Potencial: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas.
states:CreateStateMachine & iam:PassRole & (states:StartExecution | states:StartSyncExecution)Un atacante con states:CreateStateMachine & iam:PassRole podría crear una máquina de estados y proporcionarle cualquier rol de IAM, lo que permitiría el acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de privesc anterior (states:TestState & iam:PassRole), esta no se ejecuta por sí sola, también necesitarás tener los permisos states:StartExecution o states:StartSyncExecution (states:StartSyncExecution no está disponible para flujos de trabajo estándar, solo para máquinas de estados expresas) para iniciar una ejecución sobre la máquina de estados.
Los siguientes ejemplos muestran cómo crear una máquina de estados que crea una clave de acceso para el admin usuario y exfiltra esta clave de acceso a un bucket S3 controlado por un atacante, aprovechando estos permisos y un rol permisivo del entorno de AWS. Este rol permisivo debería tener asociada alguna política de alto privilegio (por ejemplo arn:aws:iam::aws:policy/AdministratorAccess) que permita a la máquina de estados realizar las acciones iam:CreateAccessKey y s3:putObject.
stateMachineDefinition.json:
Comando ejecutado para crear la máquina de estados:
Comando ejecutado para iniciar una ejecución de la máquina de estados creada previamente:
El bucket S3 controlado por el atacante debe tener permisos para aceptar una acción s3:PutObject de la cuenta víctima.
Impacto Potencial: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas.
states:UpdateStateMachine & (no siempre requerido) iam:PassRoleUn atacante con el permiso states:UpdateStateMachine podría modificar la definición de una máquina de estados, pudiendo agregar estados adicionales sigilosos que podrían resultar en una escalada de privilegios. De esta manera, cuando un usuario legítimo inicia una ejecución de la máquina de estados, este nuevo estado sigiloso malicioso se ejecutará y la escalada de privilegios será exitosa.
Dependiendo de cuán permisivo sea el Rol IAM asociado a la máquina de estados, un atacante se enfrentaría a 2 situaciones:
Rol IAM permisivo: Si el Rol IAM asociado a la máquina de estados ya es permisivo (tiene, por ejemplo, la política arn:aws:iam::aws:policy/AdministratorAccess adjunta), entonces el permiso iam:PassRole no sería necesario para escalar privilegios, ya que no sería necesario actualizar el Rol IAM, con la definición de la máquina de estados es suficiente.
Rol IAM no permisivo: En contraste con el caso anterior, aquí un atacante también requeriría el permiso iam:PassRole ya que sería necesario asociar un Rol IAM permisivo a la máquina de estados además de modificar la definición de la máquina de estados.
Los siguientes ejemplos muestran cómo actualizar una máquina de estados legítima que solo invoca una función Lambda HelloWorld, para agregar un estado adicional que añade al usuario unprivilegedUser al grupo IAM administrator. De esta manera, cuando un usuario legítimo inicia una ejecución de la máquina de estados actualizada, este nuevo estado sigiloso malicioso se ejecutará y la escalada de privilegios será exitosa.
Si la máquina de estados no tiene un rol IAM permisivo asociado, también se requeriría el permiso iam:PassRole para actualizar el rol IAM con el fin de asociar un rol IAM permisivo (por ejemplo, uno con la política arn:aws:iam::aws:policy/AdministratorAccess adjunta).
Comando ejecutado para actualizar la máquina de estados legítima:
Impacto Potencial: Ejecución y manipulación no autorizada de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
