Unauthorized access to Docker Hub database
success.docker.com
success.docker.com
1. The email they sent out didn't specify whether your account was included in the 5% of compromised users, or whether you had linked GitHub or BitBucket accounts that they unlinked. The only way to know seems to be if you still have a linked GH/BB account then you're (probably?) ok.
2. They mention you should "check security logs to see if any unexpected actions have taken place" and linked to GH/BB security audit log pages, but I don't believe that's sufficient, you also need to check for rogue commits.
3. They haven't said when the breach occurred, so there's no way of knowing how far back to look. They "discovered" it on Thursday, and say it was a "brief period", but that's meaningless.
4. They downplayed it as "brief", "non-financial user data", and "less than 5%" of users. I care more about the integrity of source code and builds than any financial information I might have given to Docker.
I can sometimes forgive companies for breaches like this, if they own up to it and do an excellent job of communicating what happened, how, when, what the impact and mitigations are, both internally and for their customers. That was not the case here.
EDIT: they discovered the breach Thursday, but still haven't given a timeframe for when it may have first occurred.
AFAIK the only way to check is to ask every person who has write access and hope they tell the truth.
Honestly, everyone should probably check their repos for recent activity / commits.
We need more fine-grained permissions for things like this. Principle of Least Authority, people.
Now is a good time to review authorized application https://github.com/settings/installations and if you're part of a GitHub organization I highly recommend setting up OAuth application restrictions https://help.github.com/en/articles/about-oauth-app-access-r...
This is how a sizable number of security incidents happen. The easiest thing to do is reckless, so people do it.
Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.
I've edited my comment.
I'm guessing that they are either not quite certain about the exact timing and duration, or that the brief period was actually embarrassingly long. Otherwise, that's one of the most important facts that anyone would communicate.
This really highlights the value of locking down the base images used in our own pipelines.
This caught my attention, as well; rubbed me the wrong way.
Funny enough, I only found out about the issue from seeing it on HN the other day.
It does not seem to me obvious how one would go about determining with confidence that "no unexpected actions have taken place", in really either of these venues, and the process of doing so does not seem trivial.
This is what makes it scary, indeed, and I agree the advice glosses over it as if it is obvious and easy how to do this.
I can understand why you'd want to cover your ass in this type of situation. However, I think keeping these things secret leads to more harm over time as people brush off weaknesses in their own systems for lack of concrete examples of where it caused harm.
Was an employee careless with credentials? Was some service not updated? Was it a typical attack like a SQL injection that caused the leak? Having more real world info helps people model threats better.
It means essentially an automated build that kicks off on a Git commit, but that doesn't require app access to your repo or organization like they now require.
This may well be a moot point; I think if you really wanted to be sure of what you were including in your code you would pull down tarballs and validate checksums for all dependencies before building on a secure network.
Typically Docker would only be held liable if misconduct can be proven. Incompetence is typically not enough (which is why e.g. Equifax is not liable for the damages following their hack).
I do think these laws need to tighten up for security-related incidents, but right now, it is what it is.
[warning: autoplaying sound]
https://finance.yahoo.com/news/people-successfully-suing-equ...
> ...the judge noted that Equifax had a duty to safeguard information, failed to heed warnings from the Department of Homeland Security, and “willfully” violated the Fair Credit Reporting Act and state regulations.
IMO, ignoring government warnings and violating regulations is much different than failing to stand up to an attack.
I would be very resistant to making "being hacked" a crime - in almost all cases, the hackee is the victim of an attack. If you feel the need for legal action, we should increase our "anti-hacker" laws and enforcement.
We don't fine banks for being robbed. It's the robbers fault something bad happened, not the bank's.
EDIT: formatting
No, we don't fine banks for being robbed. However, if the bank had clearly insufficient security on their vault, was notified of this being a problem, and made zero efforts to fix the problem then yes they should be held liable.
The comparison seems specious - the customers of the bank don't lose their money when a bank is robbed. The security is for its own benefit.
Still, your point stands.
> 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.
Implement PGP/GPG signed commits in your organization.
Learn how to create docker images from scratch. (my own very basic tutorial on this is here: https://write.as/aclarka2/create-a-centos-7-docker-image-fro... )
Why can't I use my Github account to login (which already has 2FA turned on)?
I have felt quite unsatisfied with the security of docker hub since I created my first account, but after this issue, I can say that I'm seriously scared for it.
From now on, I'll use my own Alpine base image from "scratch" instead of the one on hub ;P
The first guys to implement a container hosting and building solution that is verifiable will dethrone docker.
I hope docker does this themselves, mainly because that will be the fastest route to this happening.
https://github.com/goharbor/harbor/blob/master/docs/use_nota...
Unfortunately the interface isn't great if you aren't used to it, but because it's integrated into the build system of the entire distribution you get automated rebuilds when your container image's dependencies change for free.
[Disclaimer: I work for SUSE and am an active openSUSE contributor.]
I want Docker to succeed as a company but they just haven't made a compelling case for me to give them money yet. I guess they are focused on servicing larger companies.
That they know of. Not sure if I will keep highlighting this.
Technically, a customer didn't have a breach/leak that may have resulted in data being exfiltrated, but they also cannot rule it out, and as they've explicitly trusted docker, is that an event that should trigger a chain of official reports?