Docker disclosed one of their Hub databases was hacked and a subset of non-financial data, including usernames, hashed passwords, and GitHub and BitBucket tokens, was stolen.
The number of users affected by the breach amounts to 190,000, or less than 5% of DockerHub users. Docker sent out an email with the usual recommendations to apply in such cases to affected users. Those include changing passwords on DockerHub and any other services that shared them. Additionally, affected users should review their GitHub and BitBucket access logs to make sure no suspect activities took place. To be on the safe side, Docker revoked all GitHub and BitBucket tokens and access keys for affected users, who will thus need to re-authorize their accounts.
To check GitHub security log, you visit your profile Settings page, then choose Security in the left-hand sidebar, which gives you a list of all recent accesses. Similarly for BitBucket, you visit your Account page, then select Audit Log in the sidebar.
As many Hacker News users remarked, a major source of concern is the fact DockerHub linked to GitHub and BitBucket accounts using oAuth, getting full read and write privileges to all repositories under those accounts. In fact, GitHub supports a more fine-grained mechanism to provide privileged access to repos on a individual basis through GitHub Apps, but that mechanism was not used in this case.
Docker has yet to provide a full post-mortem analysis of the accident, but made clear no official images were impacted. Official images are only a small portion of all images available through DockerHub, though, thus leaving open the possibility that any some images may have been tampered with and potentially injected malware, as Twistlock CTO John Morello wrote.
This raises the general issue of security when using Docker images. One concern raised by several Hacker News readers is the lack of end-to-end cryptographically-secure signing of Docker images. It is true, indeed, that Docker images are immutable and DockerHub enables the use of SHA-256 on their images, but this does not rule out the possibility an attacker could replace some images and modify their checksum in the database. So, each time a developer pulls a new image, they actually have no chance to actually know what they will be getting unless they have some alternative means of ensuring an image is legit. Lacking cryptographic support for image signing, a second-best approach is manually checking an image is legitimate the first time it is downloaded, then sticking with that version by specifying its SHA-256 tag when pulling it:
docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
Speaking of security when using Docker images, ensuring the authenticity of an image is just one piece of the puzzle and you should always check the images your are pulling do not contain any vulnerabilities in key components they require. InfoQ has recently covered the State of Open Source Security Report by security firm Snyk, which contains a thorough analysis of the risks involved in the use of Docker images and a number of best practices to follow. Additionally, do not miss this post by Snyk developer advocate Liran Tal with more details and advice about protecting your Docker images in the aftermath of the data breach.
InfoQ will continue to keep you updated on the consequences of this accident as soon as new information becomes available.