Encontre o Privesc IAM: Escalada com PassRole + Lambda
O desafio
Esta política IAM da AWS parece comum, mas uma permissão deixa o titular entregar um papel poderoso a uma Lambda que ele cria e executa - subindo de acesso limitado a administrador. Leia a política e digite a permissão exata que torna essa escalada possível.
O que você vai aprender
- Reconhecer iam:PassRole em Resource * como um primitivo de escalada de privilégios
- Rastrear como CreateFunction + InvokeFunction + PassRole se encadeiam em acesso admin
- Diferenciar statements bem restritos e inofensivos de um perigoso
- Explicar por que passar um papel é mais poderoso do que parece
- Indicar a restrição correta: um ARN de Resource restrito junto com uma condição PassedToService
Habilidades testadas
Pré-requisitos
- Como as políticas IAM da AWS (Statement, Action, Resource) são estruturadas
- O que é um papel IAM e como a Lambda o assume
- Leitura básica de JSON
Como funciona
Na AWS, o poder de um principal vem não apenas do que ele pode fazer diretamente, mas do que ele pode fazer outros serviços fazerem em seu nome. iam:PassRole é a permissão para entregar um papel IAM existente a um serviço que você está configurando. Sozinha, ela não faz nada, mas combinada com um serviço que executa código sob um papel passado, torna-se um dos primitivos de escalada de privilégios mais conhecidos na nuvem.
O statement DeployLambdas concede lambda:CreateFunction, lambda:InvokeFunction e iam:PassRole em Resource: "*". Esse coringa é a parte fatal: significa que o usuário pode passar qualquer papel da conta. Um atacante cria uma Lambda, usa iam:PassRole para anexar um papel de altos privilégios (por exemplo, um com AdministratorAccess) como papel de execução da função e então a invoca. O código dentro dela roda com as permissões desse papel, então o atacante agora executa ações arbitrárias como administrador, tendo partido de uma identidade limitada de desenvolvedor.
Os outros dois statements são iscas feitas corretamente: métricas somente leitura do CloudWatch e do Logs, e leitura/escrita em um único bucket S3 nomeado. Eles são restritos e inofensivos. A habilidade de auditoria está em perceber que o privesc não é nenhuma ação isolada da Lambda, mas o iam:PassRole que permite que uma função criada herde um papel poderoso. A resposta é iam:PassRole.
Erros comuns
- Apontar apenas lambda:CreateFunction. Criar uma função é inofensivo sem a capacidade de anexar a ela um papel poderoso.
- Escolher lambda:InvokeFunction. Executar uma função que você já controla não é escalada por si só.
- Marcar os statements somente leitura ou de S3. Eles são restritos a recursos específicos e não concedem nenhuma escalada.
- Não notar o Resource: * em PassRole. O coringa é o que permite ao usuário passar qualquer papel; um ARN restrito fecharia a brecha.
Como se proteger
Nunca conceda iam:PassRole em Resource: "*". Restrinja exatamente quais papéis podem ser passados e para qual serviço, de modo que uma função criada só possa rodar como um papel de privilégio mínimo.
- Restrinja
iam:PassRoleaos ARNs de papéis específicos que o usuário legitimamente precisa. - Adicione uma
Conditioncomiam:PassedToService(por exemplo,lambda.amazonaws.com) para que o papel não possa ser desviado para outro lugar. - Separe a permissão de criar/invocar funções da permissão de passar papéis sempre que possível.
- Execute access-analyzer / linting de políticas IAM no CI para sinalizar
PassRolecom recursos coringa.