Docker Hub Hacked – 190k accounts, GitHub tokens revoked, builds disabled

  The following SSH key was added to the foo/bar repository 
  by myorg-dockerhub-user:

  Docker Cloud Build
  39:31:51:be:d6:00:c4:ef:c7:74:c2:16:66:33:93:06

  If you believe this key was added in error, you can 
  remove the key and disable access...

EDIT: it finally worked, 4th attempt, and very slowly. Looks like something isn't working 100% as it should

EDIT 2: aaaand I can't login now with the new password. A password reset did work, but it looks like their password database is under some stress at the moment.

But no, not Docker.

You're totally right; with as important as their registry is to well funded attackers, and as startup-y and "agile" as they are, and as godawful as the security practices are that underlie their tools and standards... they hadn't a chance. They still don't.

There is no reason to expect them to get better.

As I understand it, there's no element of signing from the actual devs of an image, just from the central trust service of Docker Hub.

There already have been questionable images hosted there ... just by users uploading compromised images. No hacking needed.

Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary player...

I do wish developers would be a little wiser around these things, especially when they see companies taking such huge amounts of capital. I found it quite depressing to watch the unquestioning way development communities assimilated the docker worldview.

Eh? Doesn’t let you use what without an account?

Anyone can pull images anonymously. An account is only for publishing.

NPM is bad because the Javascript ecosystem is fast-moving with loose builds that have thousands of dependencies that are all bundled and run insider consumer's browsers.

(Side note: this obviously wouldn't have prevented the current attack)

Even then just read access to code often allows enough info for leveraging/escalating privilege.

See this issue: https://github.com/docker/hub-feedback/issues/873

IMO, dockerhub should publish:

* exact time when attack happened, so we know exactly what builds might have pulled malicious images

* degree of access the hackers gained (whether it had ro or rw access, and to what exactly)

* mechanisms used for password/tokens/pii/etc. security (salt, encryption, hashing alg...)

* list of affected public accounts/images

Instead of last point, or complementing it, it would be useful if image providers would confirm on their official channels if their images were or weren't compromised, and which tags&shas are (un)safe to use.

EDIT: https://success.docker.com/article/docker-hub-user-notificat... is now updated with additional information:

Q: What happened?

There was a brief period of unauthorized access to a Docker Hub database. During this time some 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 users as well as GitHub and Bitbucket tokens for Docker autobuilds. All these tokens have been revoked.

Q: Were any of the Docker Official Images impacted by this incident?

No Official Images have been compromised. We have additional security measures in place for our Official Images including GPG signatures on git commits as well as Notary signing to ensure the integrity of each image.

By replicating the images (or packages) that you need into your own account, you can minimise the possibility of a bad actor replacing a well-known image with something untrusted.

An alternative is to side-cart a service like Notary (https://docs.docker.com/notary/getting_started/) in order to establish a chain of trust for images. If an image gets changed, Docker will refuse to use it and you will be warned that it is untrusted.

Biased opinion on an alternative registry:

- Cloudsmith: https://cloudsmith.io/l/docker-registry/

But you've got other options, such as:

- Self-hosted: https://github.com/docker/distribution)

- Cloud-specific (e.g. ECR, GCR, ACR, etc.)

- Sonatype Nexus: https://www.sonatype.com

- ProGet: https://inedo.com/proget

- Gitlab: https://gitlab.com

- Artifactory: https://jfrog.com/artifactory/

If you're missing the auto-build functionality, this can be achieved reasonably easily with any of the mainstream and awesome CI/CD services out there, such as:

- SemaphoreCI: https://semaphoreci.com/

- CircleCI: https://circleci.com/

- DroneCI: https://drone.io/

Disclaimer: I work for Cloudsmith, and still think Docker Hub is great. :-)

> I imagine it is a one way hash

All hashes are one way. If it's lossless and can be reverted, it's a compression algorithm or isomorphism or encryption or cipher or any of a number of other things, but not a hash.

> I don’t even know how it can get decrypted.

It is not decrypted, but brute forced. For example, even if you can't algorithmically figure out what the input to md5sum is that gives you '1f3870be274f6c49b3e31a0c6728957f', you could apply md5sum to every word in the dictionary in a matter of seconds and find out that 'apple', when md5summed, has that output. You would then have one possible password for that hash (though technically there are infinitely many inputs that have that output).

The only way we can know how computationally difficult it is to brute force the password hashes is if we know the following: 1) the hash algorithm used (and other inputs like cost factor) and 2) the entropy of the salt used. Those two together lets us calculate the amount of computation needed to try one brute force "guess". Individual password's difficulty to be brute forced can then be calculated from their entropy (e.g. 'apple' has less entroy than '2SEZb'), to determine the average number of inputs needed to be tried, multipled by the cost of each attempt. Given that difficulty, you can then estimate how long an attacker will take to find your password by estimating how much computational power they have at their disposal.

In general, if you randomly generate 10+ character passwords and docker used best practices, the answer is that any attacker will not get your password in under a thousand years, and if you use a password which has been leaked before or is a dictionary word (or simple variation), it can be found on the order of minutes to days.