Container Registry Exposure

What Is Container Registry Exposure?

A registry that allows anonymous pull hands your source, your config and your deployed artifact to anyone who guesses the repository name. Anonymous push lets an attacker overwrite the tag you are about to ship, and the pipeline notices nothing. You'll pull a production image, rebuild it with an implant, push it back under the same release tag, and task that implant inside the running service. Then you'll require authentication, scope push, mark release tags immutable, and verify the deployed image by digest rather than tag.

What You'll Learn in Container Registry Exposure

• Recognize that anonymous pull on a private repository hands an attacker your source, your configuration, and your build layers
• Trace a poisoned deployment to an attacker who rebuilt the production image and pushed it back under the same release tag
• Configure a registry policy that requires authentication to pull and scopes push to the repositories a pipeline actually builds
• Mark release tags immutable so an existing tag cannot be repointed at content nobody tested or reviewed
• Verify a deployed image by comparing its digest against the digest the pipeline recorded, since a tag moves but a digest cannot

Container Registry Exposure — Training Steps

1. Scan for a public repo

   Bob does not target Quenmoor by name. He scans self-hosted registries for ones that answer without a login, then enumerates their repositories to find one left readable. Quenmoor's registry answers, and one repository stands out.

2. A private repo left open

   Bob scans self-hosted registries for repositories he should not be able to reach. Quenmoor's registry answered him without asking who he was, and one repository stands out: an internal dispatch service.

3. Public, and writable

   This is an internal service, but its access policy is wide open. Bob reads the two settings that matter to him.

4. Pull it anonymously

   No credentials, no membership, no request for access. Bob points Docker at the registry and pulls the production image straight down.

5. Read their production config

   The image is not just code. It carries the configuration it runs with, baked into a layer. Bob starts a container from it and reads that file straight out.

6. Rebuild it with a backdoor

   Reading the image was theft; overwriting it is control. Because he pulled their real production image, Bob rebuilds straight from it and adds a single layer. This is the Dockerfile.

7. The layer he added

   Everything else is their image, unchanged. One RUN turns it into a foothold that ships with every deploy.

8. Tag it as their release

   Bob builds the poisoned image and tags it with the exact name Quenmoor deploys from, so the registry will treat it as the production release.

9. Push a poisoned tag

   Reading the image is theft. Overwriting it is control. Bob rebuilds the image with a backdoor in its entrypoint and pushes it back to the exact tag Quenmoor deploys from. The registry accepts it without asking who he is.

10. What the push bought him

    The next deploy rolled Bob's tag into production, and the layer he added phoned home from inside the running service. He does not have to reach Quenmoor from outside anymore: his code is the service.