English
Español
Français
Deutsch
日本語
한국어
العربيةAutoconcesión de invocación de Lambda mediante la política de recursos
Puede añadirse a sí mismo a la política de invocación de una función y activarla (se ejecuta como el rol de ejecución).
Concede escalada por sí solo.
lambda:AddPermissionPor sí solo, lambda:AddPermission puede añadirse a la política de invocación de una función y activarla (se ejecuta con el rol de ejecución). Con un alcance de recursos amplio, eso por sí solo llega a acceso para un principal externo o público.
Por qué es peligroso
Un principal puede llamar a lambda:AddPermission sobre una función privilegiada para añadirse a sí mismo (o a una cuenta externa) a la política de invocación de la función y después activarla. La función se ejecuta con su rol de ejecución, así que invocarla equivale a ejecutar código como ese rol: el premio no es la función sino el rol que cede y todo lo que ese rol puede alcanzar. El atacante reescribe la cerradura de invocación en lugar de poseer una concesión de invocación existente.
En términos de MITRE ATT&CK, esto corresponde a T1098, Manipulación de cuentas, en la táctica de escalada de privilegios. AWS lo registra en CloudTrail como AddPermission. La llamada aparece en CloudTrail pero se confunde con la administración normal, así que necesita una regla para destacar.
Detección
AddPermissionRequisitos previos
lambda:AddPermission sobre la función. El abuso supone además que ninguna barrera de SCP, límite o PrincipalOrgID bloquea la concesión excesiva, Y que invocar la función entrega realmente el rol de ejecución (código influido por el atacante, o la función filtra credenciales o salida); una invocación simple de código de confianza no lo hace.
MITRE ATT&CK
T1098 · Manipulación de cuentasTáctica
Escalada de privilegios
Un control que lo eliminaría: Restringe lambda:AddPermission a los propietarios de las funciones; deniega la escritura de políticas de invocación mediante una SCP; exige aws:PrincipalOrgID / SourceArn en las políticas de recursos de las funciones; aplica el mínimo privilegio al rol de ejecución.
Aplicarla o no depende de cómo se use el permiso en tu entorno, así que es una decisión de negocio y no una corrección automática. El mismo permiso puede ser imprescindible en una cuenta y puro riesgo en otra.
Pathbreak confirma si esta ruta se resuelve en tu cuenta, la clasifica frente a las demás según cuánto abre y usa tu modelo de amenazas y tu contexto de negocio para mostrar qué rutas merece la pena cortar.
Preguntas
¿Qué permite lambda:AddPermission?
Puede añadirse a sí mismo a la política de invocación de una función y activarla (se ejecuta como el rol de ejecución).
¿Puede lambda:AddPermission escalar privilegios por sí solo?
Sí. Concedido sobre un recurso lo bastante amplio, llega a acceso para un principal externo o público sin ningún otro permiso.
¿Cómo se detecta la autoconcesión de invocación de Lambda mediante una política de recursos?
Vigila AddPermission en CloudTrail. La llamada aparece en CloudTrail pero se confunde con la administración normal, así que necesita una regla para destacar.
¿Cómo se rompe esta ruta?
Un control que lo eliminaría es: Restringe lambda:AddPermission a los propietarios de la función; deniega las escrituras de políticas de invocación mediante SCP; exige aws:PrincipalOrgID / SourceArn en las políticas de recursos de las funciones; aplica mínimo privilegio al rol de ejecución. Aplicarla o no depende de cómo se use el permiso en tu cuenta, así que es una decisión de negocio y no una corrección automática.
¿De qué técnica de MITRE ATT&CK se trata?
T1098, Manipulación de cuentas, en la táctica de escalada de privilegios.
Rutas relacionadas
Referencias
Encuéntralo en tu propia cuenta
Ejecutamos un escaneo de solo lectura de una cuenta de AWS y te mostramos cuáles de estas rutas existen, ordenadas por radio de impacto, con el cambio que rompe cada una. Primeras rutas validadas en menos de una hora.