Intruders may have used breach to access sensitive GitHub repositories
Docker, the company behind an open platform for building and running distributed applications, said on Friday that hackers had breached one of its databases, potentially giving them access to sensitive source code on the external repositories of up to 190,000 different customers.
Data stolen from the San Francisco-based container specialist included usernames and hashed passwords for around five percent of Docker’s customers, as well as GitHub and Bitbucket tokens for Docker autobuilds. (i.e. passwords that bridge Docker and external codebase repositories).
Docker is used by many of the world’s largest financial and technology companies, including Paypal and Visa, as well as blue chips like pharmaceutical giant GlaxoSmithKline. It is unclear which accounts were affected: Microsoft was among those making clear that its official files hosted in Docker Hub were not compromised.
The company rapidly scrambled to plug the breach, invalidating the passwords of those affected and deleting the subset of users’ GitHub tokens (used in place of a password when performing Git operations over HTTPS with Git on the command line or the API).
Docker Hacked: What Happened?
Docker said: “On Thursday, April 25th, 2019, we discovered unauthorized access to a single Docker Hub database storing a subset of non-financial user data. Upon discovery, we acted quickly to intervene and secure the site. Sensitive data from approximately 190,000 accounts may have been exposed.
“We are asking users to change their password on Docker Hub and any other accounts that shared this password. For users with autobuilds that may have been impacted, we have revoked GitHub tokens and access keys. This means your autobuilds will fail, and we ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place.”
“We are enhancing our overall security processes and reviewing our policies. Additional monitoring tools are now in place” Docker said, without adding further details.
Docker ran a Q&A for worried customers, saying no action was needed: it had invalidated passwords for the accounts affected (even if that may feel to users like the stable door being locked after the horse has bolted…)
“If you directly received an email from Docker about this incident, you may have been impacted. If you have received a password reset link, your password hash was potentially exposed”, the company noted.
Relinking Docker Hub (the company’s cloud-based service) to GitHub repositories is not a risk, the company said; it will just create a new read-only deploy key to your GitHub or Bitbucket source repositories.
Docker Hacked: Microsoft Responds
In a short blog post, Microsoft’s Steve Lasker, a programme manager at the company’s Azure Container Registry, said: “While initial information led people to believe the hashes of the accounts could lead to image:tags being updated with vulnerabilities, including official and microsoft/ org images, this was not the case.”
“Microsoft has confirmed that the official Microsoft images hosted in Docker Hub have not been compromised.”
He added: “As a cloud and software company, Microsoft has been transitioning official Microsoft images from being served from Docker Hub, to being served directly by Microsoft as of May of 2018. To avoid breaking existing customers, image:tags previously available on Docker Hub continue to be made available.”
“However, newer Microsoft images and tags are available directly from the Microsoft Container Registry (MCR) at mcr.microsoft.com. Search and discoverability of the images are available through Docker Hub, however Docker pull, run and build statements should reference mcr.microsoft.com.”
He added: “Leveraging community and official images from Docker Hub and Microsoft are a critical part of today’s cloud native development. At the same time, it’s always important to create a buffer between these public images and your production workloads. These buffers account for availability, performance, reliability and the risk of vulnerabilities. Regardless of which cloud you use, or if you are working on-prem, importing production images to a private registry is a best practice that puts you in control of the authentication, availability, reliability and performance of image pulls.”