Descripción
Burrito es un operador de Kubernetes de tipo Terraform Automation Collaboration Software (TACoS). En versiones anteriores a 0.13.0, `POST /api/webhook` acepta eventos de GitHub y GitLab sin firmar cuando las credenciales de un `TerraformRepository` omiten `webhookSecret` o lo definen con un valor vacío, incluidas las credenciales configuradas para la autenticación git y el sondeo (polling). `Credential.WebhookSecret` es opcional y `go-playground/webhooks` omite la verificación de la firma o del token cuando el secreto está vacío. Cualquier persona que pueda acceder al endpoint de `burrito-server` y conozca la URL de un repositorio rastreado puede falsificar eventos para crear o eliminar recursos personalizados `TerraformPullRequest` con los campos `Branch`, `Base` e `ID` elegidos por el atacante. En los eventos `pull_request` de GitHub, el controlador obtiene los archivos modificados usando el número real del pull request, pero no verifica que la rama indicada en el payload corresponda a ese pull request. Por lo tanto, combinar el número de un pull request real y existente con una rama existente no relacionada del mismo repositorio puede provocar la ejecución no autorizada de un `terraform plan` para las capas afectadas, usando las credenciales de git y de la nube almacenadas por el operador. El análisis del código también indica que el plan resultante podría publicarse en el hilo de comentarios del pull request real, exponiendo los cambios de infraestructura de otra rama y atribuyéndolos incorrectamente. La aplicación automática (auto-apply) está deshabilitada para estas capas temporales, por lo que esta vulnerabilidad por sí sola no puede forzar un `terraform apply`; la ejecución de código de proveedores y fuentes de datos durante el plan depende del contenido de la rama seleccionada. Este problema está corregido en la versión 0.13.0.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- burrito Afectadas: < 0.13.0
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en github.comgithub.com/padok-team/burrito/security/advisories/GHSA-7m68-72r6-3jx8
- Referencia en github.comgithub.com/padok-team/burrito/commit/1d48432a4a0126429c99f5fa42567bf3…
- Referencia en github.comgithub.com/padok-team/burrito/releases/tag/v0.13.0
Ver el texto original en inglés (CVE.org)
Burrito: Unauthenticated webhooks trigger unauthorized Terraform plans when webhookSecret is unset
Burrito is a Terraform Automation Collaboration Software (TACoS) Kubernetes operator. Prior to 0.13.0, `POST /api/webhook` accepts unsigned GitHub and GitLab events when a `TerraformRepository`'s credentials omit `webhookSecret` or set it to an empty value, including credentials configured for git authentication and polling. `Credential.WebhookSecret` is optional, and `go-playground/webhooks` skips signature or token verification when the secret is empty. Anyone who can reach `burrito-server`'s endpoint and knows a tracked repository's URL can forge events to create or delete `TerraformPullRequest` custom resources with attacker-chosen `Branch`, `Base`, and `ID` fields. For GitHub `pull_request` events, the controller fetches changed files using the real pull request number but does not cross-check the payload's branch against that pull request. Pairing a real, existing pull request number with an unrelated existing branch in the same repository can therefore cause an unauthorized `terraform plan` for affected layers using the operator's stored git and cloud credentials. Code analysis also indicates that the resulting plan can be posted to the real pull request's comment thread, exposing and misattributing another branch's infrastructure changes. Auto-apply is disabled for these temporary layers, so this vulnerability alone cannot force a `terraform apply`; plan-time provider and data-source code execution depends on the selected branch's contents. This issue is fixed in version 0.13.0.