Por Vinissius Fernandes
A escalação de privilégios na AWS consiste em ter permissões suficientes para acesso através de outras funções/usuários/grupos, podendo encadear escalonamentos até obter acesso administrativo a uma organização.
As ameaças decorrentes de incidentes de segurança são frequentemente ligadas a:
- Comprometimento de credenciais:, especialmente as que têm senhas de baixa entropia e/ou as que não são modificadas frequentemente;
- Vulnerabilidades:, por vezes sem correção. A falta de aplicação de patches resulta em muitas violações de segurança;
- Má configuração: das opções de segurança disponíveis;
- Malware:, que frequentemente emprega técnicas de evasão e furtividade, buscando roubar informações e/ou conceder acesso remoto ao atacante;
- Engenharia Social:, que é o resultado usual de deficiências na conscientização de segurança, permitindo que o conhecimento das pessoas seja comprometido.
Falando especificamente de má configuração, não é simples a solução deste processo, pois não é comum que uma equipe seja qualificada em cibersegurança. Nesses casos, ao realizar a implantação de alguma aplicação ou outra carga de trabalho, comumente buscando algum tipo de facilidade, é criado algum permissionamento falho.
Normalmente, o ataque a uma infraestrutura obedece a um processo conhecido como cyber kill chain, que abstraindo-se os processos de descoberta, pode ser resumido em:
O documento que a Cybersecurity Insiders publicou 2023, com nome “Cloud Security Report” (disponível em https://global.fortinet.com/lp-en-ap-2023cloudsecurityreport), expressa que, por diversas razões, 59% dos pesquisados consideram falhas de configuração como uma das grandes ameaças da segurança em nuvem:
É importante notar que apesar de aqui nos referirmos a 2023, a má configuração também foi considerada a principal ameaça em 2022.
Explorando IAMFullAccess
Para qualquer permissão dada, é necessário avaliar os riscos decorrentes, especialmente relativos à utilização de wildcards, como, por exemplo, na política gerenciada da AWS IAMFullAccess, que tem o código:
{
“Action”: [ “iam:*“, (…)],
“Effect”: “Allow“,
“Resource”: “*”
}
Observe que no código acima estão sendo permitidas (“Effect”: “Allow”) ações em qualquer recurso (“Resource”: “*”), o que não seria tão problemático se as ações fossem específicas. Mas há uma ação iam:* que dá erroneamente uma lista de permissões no IAM, que inclui algumas listadas abaixo:
- iam:CreateGroup, iam:PutGroupPolicy e iam:AttachGroupPolicy permitem manipular as permissões de grupo;
- iam:CreateUser, iam:ChangePassword, iam:AddUserToGroup, iam:PutUserPolicy e iam:AttachUserPolicy permitem operar as permissões de usuário;
- iam:CreateRole, iam:AttachRolePolicy e iam:CreateServiceLinkedRole para manusear permissões relativas a roles;
- iam:CreateAccessKey e iam:CreateLoginProfile para utilizar acesso programático;
- iam:CreateVirtualMFADevice, iam:EnableMFADevice para manipular autenticação em múltiplos fatores;
- Entre diversos outros.
Observe que quando se perde o controle das permissões atribuídas, aumentam-se os riscos de comprometimento. Este comportamento é, muitas vezes, inesperado em virtude da utilização exagerada de curingas (wildcards).
No exemplo a seguir, criaremos um usuário IAM com permissão iam:AttachUserPolicy, sendo excessiva e que exploraremos para conceder acesso administrativo ao usuário:
Note que a criação da configuração inicial foi realizada através de um usuário que possuía permissões administrativas, mas mostraremos quando será utilizado o usuário objeto desta escalação.
A imagem a seguir mostra a criação do usuário “escala”, que será usado adiante para a elaboração de privilégios:
Abaixo é mostrada a má configuração (misconfiguration) ocorrendo, quando é anexada ao usuário “escala” a política IAM FullAccess:
Para tanto, foi utilizado o comando:
aws iam attach-user-policy –user-name escala
–policy-arn arn:aws:iam::aws:policy/IAMFullAccess
Onde –policy-arn é o identificador da política aplicada.
A imagem abaixo mostra a criação de credenciais de acesso programático:
Na imagem abaixo, foram substituídas as credenciais administrativas originais pelas do usuário “escala”:
A partir desse ponto apenas o usuário “escala” será utilizado.
Perceba que o usuário “escala” tem permissões limitadas, tal qual demonstrado na imagem acima (não tendo acesso a serviços como S3 e EC2):
O usuário “escala” está anexando uma política de acesso administrativo (arn:aws:iam::aws:policy\AdministratorAcess) a si mesmo.
Uma vez que tenham sido dadas estas permissões administrativas, agora o usuário “escala” tem acesso a todos os serviços, incluindo S3 e EC2. Ou seja, a escalação de privilégios ocorreu com sucesso.
Novo processo de escalação de privilégios
Mais uma vez exploraremos uma escalação de privilégios similar. Entretanto, desta vez, com uma permissão também existente em iam:* denominada iam:CreatePolicyVersion, a qual permite criar uma versão nova de uma política.
Como decorrência do fato, a imagem a seguir ilustra que as políticas existentes ao usuário “escala” foram excluídas, e está atribuída uma política gerenciada chamada IAMFullAccess:
O usuário “escala”, apesar de existir, tem permissões limitadas, sem acesso a S3 e EC2, como demonstrado na imagem abaixo:
Na imagem acima verificamos que o usuário “escala” já está criado com:
- uma política atribuída ao usuário “escala” que contém o privilégio iam:CreatePolicyVersion;
- a chave de acesso que será utilizada a seguir já está criada e ainda está sendo utilizada no AWSCLI, conforme demonstrado na figura abaixo:
A seguir, tal qual demonstrado na imagem abaixo, foi criado um arquivo denominado PermiteAdmin.json.
E a partir desse arquivo, pode ser criada uma política gerenciada:
Na figura abaixo, foi executado o comando:
aws iam attach-user-policy –user escala
–policy-arn arn:aws:iam::742751911445:policy/PermiteAdmin
Onde –policy-arn é o identificador da política aplicada, conforme demonstrado na figura anterior.
Pelo console alteramos ligeiramente a política existente, para criar versões diferentes da mesma política. Note que uma das versões é marcada como “Default”:
A intenção do atacante é tornar a versão 1 padrão. Para tanto, é necessário descobrir o “VersionId” das políticas com o intuito de modificar a versão padrão:
A figura a seguir mostra a modificação da política padrão:
Após a realização dessa movimentação, o usuário “escala” pode executar os comandos relativos à S3 e EC2:
Conclusões
Para haver proteção contra esse tipo de escalação, é necessário manter-se atento aos riscos de atribuir excesso de privilégios. Recomenda-se utilizar políticas específicas possíveis, particularmente quando estas permitem acesso.
Não observamos um comportamento similar nas políticas que negam acesso, menos ainda ao que tange ações duplamente negadas com o termo NotAction.
Procure sempre atribuir aos usuários a mínima permissão possível, de forma que possam executar suas funções.
Além disso, exercite atenção redobrada ao atribuir um privilégio, procure utilizar “permission boundaries” para restringir o acesso que uma política gerenciada pode conceder a entidades IAM, como usuários (estes podem ou não ser federados), grupos e roles (estas podem ou não ser assumidas).
No nosso caso específico, tratamos de má configuração, mas a proteção contra as demais ameaças também é necessária. Ter uma equipe multidisciplinar e bem treinada nas soluções utilizadas é uma condição indispensável.
Referências
AWS Security Blog, “How to use the PassRole permission with IAM roles”, 2023. Disponível em: https://aws.amazon.com/blogs/security/how-to-use-the-passrole-permission-with-iam-roles/
Blog BeyondTrust, “Privilege Escalation Attack & Defense Explained”, 2023. Disponível em: https://www.beyondtrust.com/blog/entry/privilege-escalation-attack-defense-explained
Cybersecurity Insiders, “Cloud Security Report”, 2023. Disponível em: https://pages.checkpoint.com/2023-cloud-security-report.html
OWASP, “Testing for Privilege Escalation”, 2020. Disponível em: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation/.
RhinoSecurityLabs. “Intro: AWS Privilege Escalation Vulnerabilities”, 2018. Disponível em: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.
