Docker Registries and their secrets

Never leave your docker registry publicly exposed! Recently, I have been exploring dockers a lot in search of misconfigurations that organizations inadvertently make and end up exposing critical services to the internet. In continuation of my last blog where I talked about how a misconfiguration of leaving a docker host/docker APIs public can leak critical assets, here I’ll be emphasizing on how shodan led me to dozens of “misconfigured” docker registries and how I penetrated one of them.

Refining Shodan Search

I tried a couple of search filters to find out publicly exposed docker registry on shodan -

1. port:5001 200 OK
2. port:5000 docker 200 OK

As docker registry by default runs on port 5000 (HTTP) or 5001(HTTPS) but this ends up giving more false positives as it is not necessary that people run docker only on port 5000/5001 and also “docker” keyword might occur anywhere -

Docker keyword in HTTP response

So in order to find any unique value in the docker registry which could help me in giving exact number of exposed docker registries, I set up my own docker registry (very nice documentation of setting up your own docker registry can be found in docker official site — here). I found that every API response of the Docker registry contains “Docker-Distribution-API-Version” header in it.

Docker-Distribution-API-Version Header

So my shodan search modified to Docker-Distribution-Api-Version 200 OK. 200 OK was intentionally put to only find unauthenticated docker registries (although this also has some false positives as many authentication mechanisms can still give you 200 status code).

Shodan shows around 140+ docker registries were publicaly exposed that don’t have any kind of authentication on it.

Penetrating Docker Registry

Now next job was to penetrate and explore one of the publicly exposed docker registries. What came to great help for me was again the excellent documentation put by docker on their official website — here.

1/ API VERSION CHECK
Making a curl request to the following endpoint and checking the status code provides the second level of confirmation whether docker registry can be accessed. Quoting from the official documentation of docker- “If a 200 OK response is returned, the registry implements the V2(.1) registry API and the client may proceed safely with other V2 operations”.

curl -X GET http://registry-ip:port/v2/

2/ REPOSITORY LIST
Now the next task was to list the repositories present in the docker registry for which the following endpoint is used —

curl -X GET http://registry-ip:port/v2/_catalog

Listing repositories

The following endpoint provided the list of tags for a specific repository —

GET /v2/<repo-name>/tags/list

3/ DELETE REPOSITORY
To delete a particular repository, you need the repository name and its reference. Here reference refers to the digest of the image. A delete may be issued with the following request format:

DELETE /v2/<name>/manifests/<reference>

To list the digests of a specific repository of a specific tag,(/v2/<name>/manifests/<tag>) —

Listing digest

If 202 Accepted status code is received that means the image has been successfully deleted.

4/ PUSHING AN IMAGE
Same here if the push operation is allowed, status code 202 will be received. The following endpoint is used —

POST /v2/<name>/blobs/uploads/

Conclusion

Shodan shows around 140+ docker registries that are publicly exposed that don’t have any kind of authentication on it. The later part of the blog shows how easy it is to penetrate into a docker registry and exploit it.

In all, the learning is to never expose your docker registry over the public. By default, it doesn’t have any authentication. Since docker registries don’t have a default authentication mechanism at least a basic auth could thwart some potential attacks. This can be mitigated by setting or enforcing basic auth over it and keeping the docker registry under VPN and preventing it from outside access. https://docs.docker.com/registry/deploying/#native-basic-auth

For any organization which is heavily using containers for running application and services and for organizations which are moving towards a containerized platform, should understand and evaluate the security risks around them majorly the misconfiguration present in docker. Proper security controls, audits, and reviewing configuration settings need to be carried out on a periodic basis.

Thanks for reading!

~Logicbomb ( https://twitter.com/logicbomb_1 )