mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-16 14:52:43 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -7,7 +7,7 @@
|
||||
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 **acceder a una acción**:
|
||||
- Diferentes formas de **obtener acceso a una acción**:
|
||||
- Tener **permisos** para crear la acción
|
||||
- Abusar de los **triggers** relacionados con **pull requests**
|
||||
- Abusar de **otras técnicas de acceso externo**
|
||||
@@ -81,7 +81,7 @@ 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.
|
||||
> Tenga en cuenta que en varias ocasiones podrá encontrar **tokens de usuario de github dentro de los entornos de Github Actions o en los secretos**. Estos tokens pueden otorgarle más privilegios sobre el repositorio y la organización.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -143,11 +143,11 @@ Es posible verificar los permisos otorgados a un Github Token en los repositorio
|
||||
> [!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**.
|
||||
>
|
||||
> 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, solo puedes revisar las [técnicas de Post Explotación](#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Ejecución desde la Creación de un Repositorio
|
||||
|
||||
En caso de que los miembros de una organización puedan **crear nuevos repos**, 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 **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**.
|
||||
|
||||
### Ejecución desde una Nueva Rama
|
||||
|
||||
@@ -179,11 +179,11 @@ El desencadenador de flujo de trabajo **`pull_request`** ejecutará el flujo de
|
||||
<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 predeterminada** es para **contribuyentes de primera vez**, podrías contribuir **corrigiendo un error/tipografía válido** y luego enviar **otras 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.~~
|
||||
|
||||
Además, por defecto **previene permisos de escritura** y **acceso a secretos** en el 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 **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):
|
||||
|
||||
> Con la excepción de `GITHUB_TOKEN`, **los secretos no se pasan al runner** cuando un flujo de trabajo es desencadenado desde un repositorio **forked**. El **`GITHUB_TOKEN` tiene permisos de solo lectura** en solicitudes de extracción **de repositorios forked**.
|
||||
|
||||
@@ -196,18 +196,18 @@ Como el atacante también controla el código que se ejecuta, incluso si no hay
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
El desencadenador de flujo de trabajo **`pull_request_target`** tiene **permiso de escritura** en el repositorio objetivo y **acceso a secretos** (y no pide permiso).
|
||||
El desencadenador de flujo de trabajo **`pull_request_target`** tiene **permiso de escritura** al repositorio objetivo y **acceso a secretos** (y no pide 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/).
|
||||
|
||||
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**.
|
||||
Puede parecer que debido a 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**.
|
||||
|
||||
Y este tendrá **acceso a secretos**.
|
||||
|
||||
### `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`.
|
||||
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`.
|
||||
|
||||
En este ejemplo, un flujo de trabajo está configurado para ejecutarse después de que se complete el flujo de trabajo separado "Ejecutar Pruebas":
|
||||
```yaml
|
||||
@@ -226,7 +226,7 @@ El segundo consiste en **pasar** un **artifact** del código **no confiable** al
|
||||
|
||||
TODO
|
||||
|
||||
TODO: Verificar si al ejecutarse desde un pull_request el código utilizado/descargado es el de la fuente o el del PR bifurcado
|
||||
TODO: Verificar si al ejecutarse desde un pull_request el código utilizado/descargado es el de la fuente o el del PR bifurcado.
|
||||
|
||||
## Abusando de la Ejecución Bifurcada
|
||||
|
||||
@@ -234,7 +234,7 @@ Hemos mencionado todas las formas en que un atacante externo podría lograr que
|
||||
|
||||
### Ejecución de checkout no confiable
|
||||
|
||||
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 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 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**.
|
||||
|
||||
@@ -269,7 +269,7 @@ message: |
|
||||
¡Gracias!
|
||||
</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**.
|
||||
El código potencialmente **no confiable 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**.
|
||||
|
||||
> [!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).
|
||||
@@ -286,7 +286,7 @@ gh-actions-context-script-injections.md
|
||||
|
||||
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`**.
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
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)), imagina 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:
|
||||
|
||||
@@ -356,7 +356,7 @@ Si otros repositorios estaban utilizando **dependencias de los repositorios de e
|
||||
## Pivotar Repositorio
|
||||
|
||||
> [!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 **pivotar de un repositorio a otro** suponiendo que tenemos algún tipo de acceso al primero (ver la sección anterior).
|
||||
|
||||
### Envenenamiento de Caché
|
||||
|
||||
@@ -484,7 +484,7 @@ Un ejemplo se puede encontrar en el siguiente expandible:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
@@ -515,7 +515,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
```
|
||||
</details>
|
||||
|
||||
Como puedes ver en el código anterior, el registro de Github está alojado en **`ghcr.io`**.
|
||||
Como pudiste 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:
|
||||
```bash
|
||||
@@ -525,7 +525,7 @@ 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:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
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
|
||||
@@ -536,14 +536,14 @@ Incluso si **Github** intenta **detectar valores secretos** en los registros de
|
||||
|
||||
(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).
|
||||
|
||||
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 "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.
|
||||
|
||||
> [!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 GitHub el PR sería eliminado.
|
||||
|
||||
## Herramientas
|
||||
|
||||
Las siguientes herramientas son útiles para encontrar flujos de trabajo de Github Action e incluso encontrar vulnerables:
|
||||
Las siguientes herramientas son útiles para encontrar flujos de trabajo de Github Action e incluso encontrar algunos vulnerables:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
|
||||
Reference in New Issue
Block a user