Landing page for those who "accidentally" ran a container image from an org-squatted container registry location
APACHE-2.0 License
If you ran a container that displayed the following:
_ _ ___ _ _ _ ___ _
| | | |/ _ \| \ | | | / / | |
| |_| | | | | \| | |/ /| | |
| _ | | | | | < |_|_|
| | | | |_| | |\ | |\ \ _ _
|_| |_|\___/|_| \_|_| \_(_|_)
Not the container image you were expecting?
Relax, you have only been h0nX0r3d, not hacked.
For more information on why you are seeing this:
https://github.com/bgeesaman/registry-search-order
and you followed that link here, you might be wondering how and why that happened.
First things first: you have not been hacked, but you came very close. Your system either directly or indirectly ran this container, but I assure you, it's a benign image and only prints the message above.
One of a few things:
You searched an image on docker.io
or quay.io
that looked official but wasn't and used it.
You run RHEL/Centos/Fedora or a system with Podman installed that enables a "registry search order" capability, and you specified a shortened path like repo/image:tag
. Your configuration then landed on this image first instead of the desired image in a registry later in your search order. The containers-common
package on your system installed a file named /etc/containers/registries.conf
which specified a configuration with something like:
# Libpod/Podman/Fedora
[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']
# Centos 7
[registries.search]
registries = ['registry.access.redhat.com', 'docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.centos.org']
# Centos 8/RHEL 8
[registries.search]
registries = ['registry.redhat.io', 'quay.io', 'docker.io']
The registry search order feature is useful, but a horrible goose might prevent you from having a beautiful day in the village if they decide to "squat" on your organization name in another registry and "mirror" images of identical names and tags to run an image of their choosing and not the one you were expecting.
And that's how you might accidentally fall into this form of watering-hole attack and have untrusted code run on your machine or inside your cluster.
Oops. Not good.
After some inspiration from @raesene here, I decided to see how practical this form of attack would be and to use this mechanism to raise awareness of the issue and now this issue. This took the form of:
quay.io
that were available for common/popular organizations on docker.io/DockerHub
in case quay.io
comes first in your search order.registry.redhat.io/registry.access.redhat.com
on docker.io/DockerHub
in case docker.io
comes first.README
.Hence the horrible goose reference: HONK HONK HONK
Note: Neither House House nor Panic are in any way affiliated with this project, nor do they endorse it.
A few things:
docker.io
but not in quay.io
or vice versa, go ahead and register it with a reference back to your official registry location.org3
, be sure to register org4-org100
in both docker.io
and quay.io
to prevent user confusion and trust issues./etc/containers/registries.conf
registries.search
list to place your trusted registries first and consider removing all public registries from this list.docker.io/myorg/myimage:mytag
instead of myorg/myimage:mytag
mytag
, consider using the digest format: quay.io/myorg/myimage@sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
as it prevents both org-squatting and registry compromise situations.