Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Para mais informações sobre este serviço AWS, confira:
Essas técnicas de escalonamento de privilégios vão exigir o uso de alguns recursos de função de passo da AWS para realizar as ações de escalonamento de privilégios desejadas.
Para verificar todas as ações possíveis, você pode ir para sua própria conta AWS, selecionar a ação que gostaria de usar e ver os parâmetros que está utilizando, como em:
Ou você também pode ir à documentação da API AWS e verificar a documentação de cada ação:
states:TestState & iam:PassRoleUm atacante com as permissões states:TestState & iam:PassRole pode testar qualquer estado e passar qualquer função IAM para ele sem criar ou atualizar uma máquina de estado existente, permitindo acesso não autorizado a outros serviços AWS com as permissões da função. potencialmente. Combinadas, essas permissões podem levar a ações não autorizadas extensas, desde manipulação de fluxos de trabalho até alteração de dados, vazamentos de dados, manipulação de recursos e escalonamento de privilégios.
Os seguintes exemplos mostram como testar um estado que cria uma chave de acesso para o admin usuário aproveitando essas permissões e um papel permissivo do ambiente AWS. Este papel permissivo deve ter qualquer política de alto privilégio associada a ele (por exemplo, arn:aws:iam::aws:policy/AdministratorAccess) que permite que o estado execute a ação iam:CreateAccessKey:
stateDefinition.json:
Comando executado para realizar o privesc:
Impacto Potencial: Execução e manipulação não autorizadas de fluxos de trabalho e acesso a recursos sensíveis, potencialmente levando a violações de segurança significativas.
states:CreateStateMachine & iam:PassRole & (states:StartExecution | states:StartSyncExecution)Um atacante com states:CreateStateMachine & iam:PassRole seria capaz de criar uma máquina de estado e fornecer a ela qualquer função IAM, permitindo acesso não autorizado a outros serviços AWS com as permissões da função. Em contraste com a técnica de privesc anterior (states:TestState & iam:PassRole), esta não se executa por si só, você também precisará ter as permissões states:StartExecution ou states:StartSyncExecution (states:StartSyncExecution não está disponível para fluxos de trabalho padrão, apenas para máquinas de estado expressas) para iniciar uma execução sobre a máquina de estado.
Os seguintes exemplos mostram como criar uma máquina de estados que cria uma chave de acesso para o admin usuário e exfiltra essa chave de acesso para um bucket S3 controlado pelo atacante, aproveitando essas permissões e um papel permissivo do ambiente AWS. Esse papel permissivo deve ter qualquer política de alto privilégio associada a ele (por exemplo, arn:aws:iam::aws:policy/AdministratorAccess) que permite que a máquina de estados execute as ações iam:CreateAccessKey e s3:putObject.
stateMachineDefinition.json:
Comando executado para criar a máquina de estados:
Comando executado para iniciar uma execução da máquina de estados criada anteriormente:
O bucket S3 controlado pelo atacante deve ter permissões para aceitar uma ação s3:PutObject da conta da vítima.
Impacto Potencial: Execução e manipulação não autorizadas de fluxos de trabalho e acesso a recursos sensíveis, potencialmente levando a violações de segurança significativas.
states:UpdateStateMachine & (não sempre necessário) iam:PassRoleUm atacante com a permissão states:UpdateStateMachine seria capaz de modificar a definição de uma máquina de estados, podendo adicionar estados extras furtivos que poderiam resultar em uma escalada de privilégios. Dessa forma, quando um usuário legítimo inicia uma execução da máquina de estados, esse novo estado furtivo malicioso será executado e a escalada de privilégios será bem-sucedida.
Dependendo de quão permissivo é o Papel IAM associado à máquina de estados, um atacante enfrentaria 2 situações:
Papel IAM Permissivo: Se o Papel IAM associado à máquina de estados já for permissivo (ele tem, por exemplo, a política arn:aws:iam::aws:policy/AdministratorAccess anexada), então a permissão iam:PassRole não seria necessária para escalar privilégios, uma vez que não seria necessário também atualizar o Papel IAM, com a definição da máquina de estados é suficiente.
Papel IAM Não Permissivo: Em contraste com o caso anterior, aqui um atacante também precisaria da permissão iam:PassRole uma vez que seria necessário associar um Papel IAM permissivo à máquina de estados além de modificar a definição da máquina de estados.
Os seguintes exemplos mostram como atualizar uma máquina de estado legítima que apenas invoca uma função Lambda HelloWorld, a fim de adicionar um estado extra que adiciona o usuário unprivilegedUser ao grupo IAM administrator. Dessa forma, quando um usuário legítimo inicia uma execução da máquina de estado atualizada, este novo estado malicioso e furtivo será executado e a escalada de privilégios será bem-sucedida.
Se a máquina de estado não tiver um papel IAM permissivo associado, também será necessário a permissão iam:PassRole para atualizar o papel IAM a fim de associar um papel IAM permissivo (por exemplo, um com a política arn:aws:iam::aws:policy/AdministratorAccess anexada).
Comando executado para atualizar a máquina de estados legítima:
Impacto Potencial: Execução não autorizada e manipulação de fluxos de trabalho e acesso a recursos sensíveis, potencialmente levando a violações de segurança significativas.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
