Docker customers in password reset race after ‘unauthorised access’ of customer database

Docker customers in password reset race after ‘unauthorised access’ of customer database

Docker users might have some catching up to do this morning after the vendor admitted sensitive data on up to 190,000 users could’ve been exposed after a customer database was hacked.

The potentially exposed data for a “small percentage” of these users includes usernames, hashed passwords and GitHub and BitBucket tokens for Docker autobuilds.

Affected users, and presumably anyone else with a well developed sense of paranoia, face resetting passwords, and combing their repositories for “unexpected actions”.

The exposure came to light late on Friday, when Docker announced “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.”

According to Docker, during the ”brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as GitHub and Bitbucket tokens for Docker autobuilds.”

Docker has advised users to change their passwords on Docker Hub, and any other accounts that used the same password. (While resisting the urge to point out using the same password for other accounts is, like, a really bad idea)

The firm has also revoked GitHub tokens and access keys where appropriate, which means autobuilds will fail. Since Docker Hub users tend to work for larger companies, this might have set quite a few into a state of frenzy, with production environments often coupled to this kind of process.

Users are asked to ”reconnect to your repositories and check security logs to see if any unexpected actions have taken place.” Users are warned they “may need to unlink and then relink your GitHub and Bitbucket source provider.”

Docker was at pains to say no “Official” Docker images were affected by the break. It added, in a FAQ on the breach, that only users affected by the breach had had their passwords reset, and token revoked. But even if you haven’t received a password reset email, changing passwords regularly never hurts.

Which should all be straightforward, unless of course, you no longer have access to the relevant email account – which does happen.

https://twitter.com/ErwinGeirnaert/status/1122766727845240832?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1122766727845240832&ref_url=https%3A%2F%2Ftweetdeck.twitter.com%2F

Some users couldn’t help but comment on the timing of the announcement of the breach – just days before the vendor’s annual shindig in San Francisco – meaning some users were no doubt scrambling to change passwords mid-transit. It could be worse though – no keynote speaker would want to start their speech with a security advisory.

https://twitter.com/lastlegion/status/1122146118429741058

It’s a measure of how far containers have been taken up by enterprises that a security issue causes widespread collywobbles amongst users. A vulnerability in the runc run time underpinning Docker and Kubernetes, amongst others, back in February allowed for “a break out from the container to gain root-level access on the host machine” and made for a fraught Monday as vendors rushed to issue patches.