Docker Hub images found to expose secrets and private keys

Numerous Docker images shared on Docker Hub are exposing sensitive data, according to a study conducted by researchers at the German university RWTH Aachen. Needless to say, this poses a significant security risk.

In traditional software development, programmers code an application in one computing environment only to find bugs or errors when it’s deployed in another environment. To solve this, developers bundle their application together with all its related configuration files, libraries, and dependencies required to run in containers hosted in the cloud. This method is called containerization.

Docker images are one of the most common methods used in containerization. Docker is an open-source project that automates the deployment of applications inside software containers. Docker Hub is a cloud-based repository which facilitates the widespread use and sharing of Docker images. Docker Hub comprises more than 9,000,000 images anybody can use.

Since containerization started out as a means for efficient development and cost savings and quickly ballooned into adoption and implementation, security was unfortunately a low priority in its design—as it often is in tech innovation.

The researchers analyzed 337,171 images from Docker Hub and 8,076 private registries and found that more than 1 in 12 of these images contained sensitive information, including private keys and API secrets. To be precise, they found 52,107 private keys and 3,158 leaked API secrets. This is not just a huge security risk, the researchers documented that the leaked keys were actually used in the wild.

The researchers discovered that some of the exposed keys were in use, which means elements such as certificates were also at risk. In fact, more than 22,000 compromised certificates were found to be relying on the exposed private keys. That includes more than 7,500 private and more than 1,000 public certification authority (CA) signed certificates.

Most of the secrets were found in images of single owners, which makes sense assuming users do not share their secrets intentionally. The researchers also found that image creators upload secrets to Docker Hub more often than to private registries (9% vs 6.3%). This could be an indication that private registry users have a better security understanding, maybe due to a deeper technical understanding required for hosting a registry.

To highlight the security implications around internet communications, the researchers found 216 Session Initiation Protocol (SIP) hosts used for telephony as well as 8,165 SMTP, 1,516 POP3, and 1,798 IMAP servers used for email. Since these hosts are susceptible to impersonation attacks due to their leaked private keys, attackers can eavesdrop, relay, or alter the sensitive data transmitted here.

All in all it poses a massive problem when image creators are unaware or careless about sharing secrets. Together these exposed secrets create a huge attack surface.

Mitigation

Secrets can be copied:

  • Actively, when copying secrets from their local file system into the image.
  • Passively, by using images with secrets included during creation of the image.

Both behaviors lead to compromised secrets and affect the security of both image creators and users, but they need a different approach for mitigation.

On the one hand, image creators and editors must be warned that they are uploading their secrets to publicly reachable Docker registries. On the other hand, when deploying containers based on downloaded images, users should be informed about included secrets, especially private keys, which might already be compromised, putting the authentication of deployed services at stake. When uploading or downloading an image, tools like TruffleHog or SecretScanner could then scan all layers of the image for included secrets.


Malwarebytes EDR and MDR removes all remnants of ransomware and prevents you from getting reinfected. Want to learn more about how we can help protect your business? Get a free trial below.

TRY NOW

https://blog.malwarebytes.com/feed/

Leave a Reply