Malicious Base Images

What Is Malicious Base Images?

Anyone can publish to a public registry under a name close to one you trust. Without signature verification, a FROM line is just a string, and a build that resolves that string will run whatever it fetches. This exercise covers a hostile base image that reached production: watch an attacker plant it and collect what it sends home, then fix it with verified publishers, an internal mirror, and signature verification at pull time.

What You'll Learn in Malicious Base Images

• It resolves a name to whatever the registry serves, so without verification you are trusting a string rather than a publisher.
• It protects against the image changing after you vetted it, but not against pinning a hostile image in the first place. You still have to verify who published it.
• Scanning tells you about known vulnerabilities; a signature tells you the image came from the publisher you expect and was not substituted.
• That image was legitimate but out of date. This one was hostile from the start, so patching it is meaningless and the fix is about provenance.

Malicious Base Images — Training Steps

1. A name one character off

   Bob does not break into anything. He publishes. On a public image hub anyone can push a repository, and he has pushed one under a namespace that reads almost exactly like the official Node.js base image. Then he waits for a build, somewhere, to pull it by mistake.

2. Dressed to pass

   Bob's repository sits in the search results right under the real one, with the same tagline and a healthy pull count. The only difference is the part a hurried engineer skims past.

3. What he actually shipped

   Bob's lookalike is not a repackaged Node image with a fresh label. He built it from a real one and added a single line. This is the Dockerfile behind the base he published.

4. The line that does the work

   Everything above this line is an ordinary Node.js base. One RUN, dressed up with an innocent comment, is what turns it into a weapon.

5. Watch the payload fire

   The base looks and behaves like a normal Node.js image, so a build using it succeeds and an app on it runs. But a layer Bob added fetches and runs a payload the moment a container starts. He runs his own base once to confirm the payload still fires.

6. Use the way in

   A Marlspire build shipped on his base, and the implant it planted phoned home. Bob does not need to break in now: he already has a shell inside their production container. He tasks it to hand over what it can reach.

7. What made this possible

   One beat on the mechanism before the response begins.

8. The host reports a miner

   Marlspire runs endpoint monitoring on its container hosts. It does not care what the container is supposed to do; it reports what it saw.

9. Read the image's layers

   An image records how it was built, one command per layer. If a miner is installing itself, some layer had to run the command that fetched it. Alice reads the build history of the shipped image.

10. Where the base came from

    The poison is in the base, so the question is which base. Alice looks the two candidates up on the public hub, side by side.