Container registries: typosquatting, layer poisoning, image signing y defense

2026-11-06 · 9 min de lectura

Los container registries son target cada vez más atacado: typosquatting de imágenes populares, layer poisoning, config misconfigs. Aprende patrones de ataque contra Docker Hub, ECR, GHCR, y defensa con cosign, Sigstore, SBOM y admission controllers.

Los container registries —Docker Hub, AWS ECR, GitHub Container Registry (GHCR), Google Container Registry (GCR), Azure Container Registry (ACR), Harbor, Quay— son el punto central del ecosistema de contenedores: millones de imágenes almacenadas, descargadas billones de veces. Y como centros neurálgicos, son objetivos de ataque cada vez más atractivos para supply chain compromises. Un atacante que logra publicar imagen maliciosa en un registry popular bajo nombre convincente puede comprometer miles de deployments de developers y organizaciones confiados en el ecosistema.

Esta lección cubre los vectores específicos de container registry attacks (typosquatting, layer poisoning, image signing bypass, misconfig de registries privados), casos reales documentados en 2022-2026, y defensas modernas con cosign + Sigstore, SBOM, admission controllers y vulnerability scanning. Complementa la lección de supply chain attacks (Tanda 5) con foco específico en el ecosistema container.

Es la quinta lección del bloque red team avanzado + supply chain de la Tanda 6.

Testing en registries propios o images propios. Publishing malicious images, incluso para research, viola ToS de Docker Hub y puede resultar en legal action.

El ecosistema registry#

Container registries: Docker Hub, ECR, GHCR, GCR, ACR, Harbor, Quay, plus mirror registries

Public registries#

Docker Hub: original, dominant. Oficial, community, verified publishers.
GitHub Container Registry (GHCR): integrated with GitHub Actions.
Quay.io (Red Hat): enterprise-focused, security scanning.
Container Registry Google (GCR) / Artifact Registry.
DigitalOcean Container Registry.

Private registries#

AWS ECR (Elastic Container Registry): integrated with EKS, lambda.
Azure Container Registry (ACR): integrated with AKS, Azure Functions.
Google Artifact Registry.
Harbor (CNCF): self-hosted open source.
GitLab Container Registry.

Cada uno tiene su modelo de auth, permisos, features (scanning, signing, caching).

Vectores de ataque#

Typosquatting#

Igual que npm/PyPI typosquatting (lección supply chain previa), pero en Docker Hub.

Patrones:

nginx vs ngnix vs nginix.
python vs pythn vs python-slim (legitimate distinction).
library/ubuntu vs library/unbuntu.
Vendor names: microsoft/sql-server vs microsoft-corp/sql-server.

Developers tired typeando docker pull image sometimes typo. Malicious image installs, user doesn't realize.

Layer poisoning / tag replacement#

Tag mutabilidad in Docker Hub permits compromise of accounts to push new version of existing image. Users doing docker pull nginx:latest get malicious version.

Mitigation: pin to specific SHA digests (nginx@sha256:...) not tags.

Backdoored official-looking images#

Attackers publish images with convincing descriptions, decent documentation, popular tags (latest, 1.0). Contains backdoor en runtime o build time. Users scanning Docker Hub for a tool find it, deploy.

Documented campaigns 2023-2025: crypto miners disguised as development tools, reverse shells en popular utility images, credential harvesters en database client images.

Image hijacking#

If company's Docker Hub account compromised, attacker pushes malicious images under official name. Users with existing deployments pull next version automatically, compromise.

Compromised build pipeline#

Image built via CI/CD. If pipeline compromised (prev. lecciones DevSecOps CI/CD), malicious code injected into built image. Published to registry, users consume.

Dependency image contamination#

Legitimate image uses FROM alpine:latest o similar. If base image contaminada o legitimate base compromised in upstream chain, derivatives all affected.

Registry misconfig#

Public access to private registries by error:

S3 buckets backing ECR without proper policies (historical, patched).
Harbor self-hosted con credentials default.
GitLab container registry con repositories públicos sin querer.

Content leak + potential upload if write access.

Credential harvesting#

If attacker gains read access to registry, can extract secrets embedded in images:

Build-time env vars.
API keys in config files.
SSH keys for deployment.
.env files committed.

Docker image layers accesibles via docker history + docker save + inspect.

Casos reales#

Documentados públicamente:

Docker Hub breach (2019): 190k user accounts affected, auth tokens exposed.
Siloscape (2021): Windows container escape malware distributed via container images.
Dero cryptominer (2023+): campaign distributing crypto miners via typosquatted images.
5 million downloads malware (2022): trend microscan reportó images maliciosos con millions de pulls accumulated.
Alpine Linux CVE-2018-1000039: no en registry sino en popular base image. Mostró impact de base image vulns.
Docker Scanning data disclosure (2023): metadata leak via scanning API.

Defensa#

Image signing con cosign + Sigstore#

Discutido en lección supply chain. cosign es standard emerging para signing container images:

# Sign
cosign sign --yes ghcr.io/myorg/app:v1.0

# Verify
cosign verify [email protected] \
  --certificate-oidc-issuer=https://github.com/login/oauth \
  ghcr.io/myorg/app:v1.0

En producción con Kubernetes: Sigstore Policy Controller valida signatures automatically at admission.

SBOM generation#

Software Bill of Materials por image. Tools: Syft (generate), Grype (scan). Enables rápida respuesta a CVEs.

syft ghcr.io/myorg/app:v1.0 -o cyclonedx-json > sbom.json
grype sbom:sbom.json

Vulnerability scanning#

Trivy (Aqua): comprehensive scanner.
Snyk Container: commercial.
Docker Scout: Docker's native.
Prisma Cloud / Qualys Container Security: enterprise.

Integrate in CI/CD: fail build si CVE crítica detectada.

Pin to digest#

Never :latest. Always @sha256:.... Immutable reference.

# Kubernetes manifest
image: nginx@sha256:a1b2c3...

Image provenance#

SLSA framework (lección supply chain). Verifiable provenance de building process.

Private registry hardening#

Access controls strict.
Audit logs monitored.
Vulnerability scanning integrated.
Image signing enforced.
Retention policies para cleanup.

Admission controllers Kubernetes#

OPA Gatekeeper: policies de qué images allowed.
Kyverno: alternative with image verification.
Sigstore Policy Controller: specific para signed images.

Reject images que no match criteria at deploy time.

Supply chain protection integrated#

Combine techniques:

SBOM generation en build.
Image signing con cosign.
Vulnerability scanning con Grype.
Admission control validate signatures + policies.
Regular image rebuilds con fresh base.
Monitoring de deployed images para new CVEs.

Platforms integrating all: GitHub Advanced Security, Chainguard, Rezilion.

Walkthrough: audit de container pipeline#

Para fijar el patrón, un flujo de audit contra container ecosystem:

Paso 1 — enumeration:

# Review Kubernetes deployments
kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}'
# Lista todas las images used

Paso 2 — image provenance check:

# Pin status
# Tags (nginx:latest) vs digests (nginx@sha256:...)?
# Grupo de imágenes with mismo pattern?

# Signatures
cosign verify nginx:latest
# Si no signed, red flag

Paso 3 — vulnerability scan:

trivy image nginx:latest --severity HIGH,CRITICAL
# Lista vulns + versions affected

Paso 4 — SBOM generation:

syft nginx:latest -o cyclonedx-json > nginx-sbom.json
# Detailed breakdown de software included

Paso 5 — image inspection:

# Build-time secrets?
docker save nginx:latest -o nginx.tar
tar -xf nginx.tar
# Review layers con tar + grep para secrets

# Via docker history
docker history --no-trunc nginx:latest

Paso 6 — admission controller check:

# En Kubernetes
kubectl get constraints --all-namespaces
# Verify Gatekeeper/Kyverno policies enforcing image security

Paso 7 — reporte: findings con prioritization. Image signing missing, no vulnerability scanning, admission control gaps, etc.

Rol del defender container-centric#

Para blue teams con arquitectura container-heavy:

Private registry con access controls strict.
Build pipeline security (lección DevSecOps previa).
Signing + verification mandatory en producción.
SBOM + vulnerability tracking continuous.
Image rebuild cadence regular (weekly/monthly).
Deprecated image detection: alert on pulls from deprecated/known-vulnerable.
Runtime security: Falco, Tetragon catching anomalies post-deploy.

Errores comunes#

docker pull image:latest sin verification.
No vulnerability scanning in CI.
Private registry credentials in Git.
Not pinning to digests.
No admission control en Kubernetes.
Base images never updated.
Build secrets persisted in image layers (reveal via inspect).

Preguntas frecuentes#

¿Docker Hub free tier es seguro para prod?#

Technically sí, pero: rate limits restrictive para prod, no SLA, publicly discoverable images. Mejor: private registry para internal images, Docker Hub para public base images.

¿Vale la pena Harbor self-hosted?#

Para orgs con compliance requirements o custom integration needs: sí. Harbor es mature, feature-rich. Cost: operational overhead.

¿Chainguard Images reemplazan Docker Hub?#

Alternative: distroless + CVE-free bases. Marketing fuerte. Use case para orgs con strict security requirements. Mainstream adoption emerging.

¿Admission control slow-down deploys?#

Milliseconds added per admission check. Trade-off absolutamente worthwhile para prevent malicious images.

¿Container registry en air-gapped environment?#

Yes, support both cases. Pre-pulled images, local registries (Harbor, Zot). Common en regulated industries.

¿Dónde practico?#

El laboratorio armageddon de whoami-labs incluye setup container ecosystem: Harbor self-hosted con misconfigs, Docker Hub typosquatting examples, Kubernetes con y sin admission controllers. Practicas identification, exploitation, defense.

¿Vale la pena la cert CKA/CKS?#

CKA (Certified Kubernetes Administrator) + CKS (Certified Kubernetes Security Specialist) son referencia industria. CKS especialmente cubre image security, admission controllers, runtime security. Buen signal para employers.

¿Docker Trusted Content vs cosign?#

Docker Hub's own signing deprecated in favor of cosign/Sigstore. Standard emergente universal. OpenSSF support via Sigstore community.

¿Rebuild cadence para base images?#

Recommended: weekly for critical, monthly minimum. Base image updates incluyen security patches. Automated con tools como Dependabot, Renovate.

¿Distroless vs Alpine vs regular?#

Distroless (Google): no shell, minimum surface. Chainguard offers CVE-free. Alpine: small but musl libc can cause subtle issues. Regular (Ubuntu, Debian): familiar, full-featured but larger surface.

¿Attestations vs signatures?#

Signatures prove authenticity. Attestations include claims (SLSA level, vulnerability scan passed, etc.). Combined provide comprehensive provenance. Supported by Sigstore ecosystem.

¿Container runtime security overlap con registry security?#

Complementary. Registry security = pre-deploy. Runtime security (Falco, Tetragon) = post-deploy. Defense in depth strategy incluye both.

Resumen#

Container registries central del ecosystem: Docker Hub, ECR, GHCR, Quay, ACR, Harbor.
Vectores: typosquatting, layer poisoning, backdoored images, misconfig registries, credential harvesting en layers.
Casos reales: Docker Hub breach 2019, Siloscape, Dero cryptominers, multiples campaigns.
Defensa: cosign + Sigstore signing, SBOM generation, vulnerability scanning (Trivy, Snyk), pin to digests, admission controllers (Gatekeeper, Kyverno).
SLSA framework para provenance verifiable.
Chainguard, Rezilion platforms integrating approach moderno.

Impacto regulatorio#

Trends 2024-2026:

EU Cyber Resilience Act: software vendors incluyendo container images responsible for vulnerabilities throughout lifecycle. SBOM required.
US Executive Order 14028: SBOM mandatory para software sold to US government. Includes container images.
CISA SBOM guidance: CycloneDX o SPDX formats.
NIST SP 800-190: official container security guide.
PCI DSS 4.0: container security requirements expanded.

Para enterprises, compliance drives adoption de signing, SBOM, scanning. Developers unused to this overhead but industry maturing rápido.

Futuro: image provenance maduración#

Direction 2026-2028:

Universal cosign adoption: Sigstore standard de facto.
SBOM native en registries: todas las platforms exponen SBOM automáticamente.
Attestation chains: provenance desde source code hasta deployed container verifiable end-to-end.
AI-based vulnerability detection: ML identifying novel issues antes de CVE assignment.
Chainguard-style: distroless + minimal como default industry.

Los pentesters especializados en container security tienen demand creciente, especialmente combinados con cloud-native + Kubernetes expertise. Carrera atractiva con growth sustainable esperado durante años.

Las próximas lecciones del bloque entran en honeypots y deception (defense proactiva), OSINT avanzado y compliance con NIS2/GDPR, cerrando la Tanda 6 con balance entre offensive y defensive capabilities. Juntas, las 15 lecciones de esta tanda cubren el panorama completo de hardware/IoT, AI/LLM, red team avanzado, supply chain y compliance que define el estado del arte de seguridad ofensiva y defensiva en 2026 para profesionales que aspiran a los puestos mejor pagados del mercado actual en consultoría especializada o en roles internos de organizaciones grandes y enterprise con operaciones técnicas complejas y requirements regulatorios particularmente exigentes del sector específico.

Hay que recordar que seguridad en contenedores no es tema único sino parte de ecosistema mayor que incluye desarrollo, deployment, operaciones y gobierno integral de software corporativo moderno.