{"id":219471,"date":"2019-06-20T12:54:29","date_gmt":"2019-06-20T10:54:29","guid":{"rendered":"https:\/\/www.intrinsec.com\/?p=219471"},"modified":"2019-06-20T12:54:29","modified_gmt":"2019-06-20T10:54:29","slug":"docker-leak","status":"publish","type":"post","link":"https:\/\/www.intrinsec.com\/en\/docker-leak\/","title":{"rendered":"Thousands of exposed docker images leak secrets on the Internet"},"content":{"rendered":"[et_pb_section admin_label=\u00bbsection\u00bb] [et_pb_row admin_label=\u00bbrow\u00bb] [et_pb_column type=\u00bb4_4\u2033][et_pb_text admin_label=\u00bbText\u00bb]\n

Docker is now mainstream, everywhere and has invaded every business regardless of the sector of activity. This massive adoption, although the Docker backend technology is nothing new, is due to its ease of use which, as we are going to see, can lead to leaks of secrets<\/strong> when the concepts are misunderstood.<\/p>\n\n\n\n

Docker is a containerization engine that allows you to package an application with all its dependencies. This template of ready-to-use application is called a Docker image<\/strong>. There are various types of images like web servers or databases. Images can stack and depend on each other. Images can be retrieved on public registries such as Dockerhub<\/strong><\/a>, which currently hosts more than 2.3 million of them<\/strong>.<\/p>\n\n\n\n

Like Github you can save your images for free at the expense of letting it publicly available to anyone and having to pay for a private hosting. There is also the possibility to maintain your own Docker personal registry<\/a>.<\/p>\n\n\n\n

Whether it is by unawareness of risk, accident or a budget wise decision, those public registries contain Docker images that shouldn't be left exposed. Many of them leak internal code, secrets or personal information. We estimate that roughly 10% of Docker images hosted on Dockerhub should not be publicly exposed as they are leaking sensitive data<\/strong>.<\/p>\n\n\n\n

For the rest of this blog post, image refers to Docker image.<\/p><\/blockquote>\n\n\n\n

Why analyze a Docker image?<\/h2>\n\n\n\n

The main purpose of analyzing images is to check the integrity and the version of its components, for potential CVEs, to use it safely.<\/p>\n\n\n\n

Checking the legitimacy is to avoid a malicious image. This is what happened in May 2017 when the same user has released 17 backdoored images on Dockerhub, which contained a cryptocurrency miner and has generated about $90,000 in value<\/a>.<\/p>\n\n\n\n

To check that there are no CVEs listed on the kernel or frameworks used, there are solutions such as Aqua, which also owns their own Docker registry, which will scan the images uploaded\/built by users.<\/p>\n\n\n\n

Our scope here is focused on data leakage of publicly exposed images. Code repositories monitoring to find secrets have been largely publicized after several cases such as 2016 Uber's data leak<\/a> whereas leaks from Docker images stay under the radar, hence this blog post. To be clear, the leak comes from misuse of users and not from Dockerhub or Docker platform as they prevent risks.<\/p>\n\n\n\n

What's inside a Docker image?<\/h2>\n\n\n\n

A Docker image is an archive containing, among other things, the filesystem necessary to make the application work. It is structured in layers representing each instruction given in the Dockerfile during the build of the given image.<\/p>\n\n\n\n

For example if I want to kwow the instructions made to build the mysql image:<\/p>\n\n\n\n

docker pull mysql && docker history mysql<\/code><\/pre>\n\n\n\n
To explore in details the image you can export it as a tar archive and dive into layers<\/p>\n\n\n\n
docker save mysql | tar xvf - --one-top-level=mysql && ls mysql\/*\/layer.tar<\/code><\/pre>\n\n\n\n
Fortunately a wonderful tool has been released, by Alex Goodman<\/a>, to explore each layer in an image, called dive<\/strong><\/a><\/code>. You can see what are the new files, those that have been edited or removed. In backend, dive<\/strong><\/code> also uses the tar archive of the image and proceeds on a differential of each layer.<\/p>\n\n\n\n
\"\"
Thanks to its nice UI, you can spot easily added\/updated\/removed <\/em>files<\/figcaption><\/figure>\n\n\n\n
What could go wrong?<\/h2>\n\n\n\n
Secrets embedded in code<\/h3>\n\n\n\n
The first bad practice is to embed secrets, like AWS key or Dropbox access token, inside your code. It is not relative to Docker but to secure development in general. When you copy your code inside the image you also copy the secrets and if the image go public your secrets too.<\/p>\n\n\n\n
\"\"
MongoDB database credentials inside code<\/figcaption><\/figure>\n\n\n\n
Remediation: Separate your secrets and configurations data from your code. Make the secrets as arguments or environment variables to be given when you run your image.<\/p><\/blockquote>\n\n\n\n
Secrets in environment variables<\/h3>\n\n\n\n
Ok so you have separated your secrets and configuration files from your code by setting them in environment variables. But you specify this environment variables in you Dockerfile and again anyone can see them, either by printing history of commands used to build the image or by printing environment variables inside a running instance of the image.<\/p>\n\n\n\n
Docker history # OR docker run printenv<\/code><\/pre>\n\n\n\n
\"\"
Sensitive environment variables accessible in image<\/figcaption><\/figure>\n\n\n\n
Remediation: Set sensitive environment variables when running your image with the option -e<\/code> or compiled in a file with --env-file<\/code>.<\/p><\/blockquote>\n\n\n\n
 A (secrets) file copied into you docker image<\/h3>\n\n\n\n
You now are using an environment file name .env<\/code> containing all your secrets, in your work directory to give at run command but you forgot to ignore it when using COPY<\/code> command in your Dockerfile (like copy your code to your image). So anyone can access those secrets which are copied in your docker image.<\/p>\n\n\n\n
\"\"
All kinds of secrets over here<\/figcaption><\/figure>\n\n\n\n
When you wildly copy your working directory, you can also copy the .git<\/code> directory or non-code data files that were not meant to be in the image.<\/p>\n\n\n\n