7 ms·

I've found Docker's communication about this incident to be pretty poor. 1. The email they sent out didn't specify whether your account was included in the 5%

by rlt 8y ago

I've found Docker's communication about this incident to be pretty poor. 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.

pritambaral 8y ago
Not surprising given their past outlook towards security.
rlt 8y ago
Oh, and if anyone with write access to your repositories had their GH/BB account linked to their DockerHub account, your source code could be compromised. 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 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-restrictions https://help.github.com/en/articles/about-oauth-app-access-r...
- donmcronald 8y ago
  Signed commits would be useful, right? I don’t know much about GitHub permissions, but I’ve skimmed GitLab’s. Why would Docker hub have write access to the repo? Is there really no read only access for repos?
  - rlt 8y ago
    I think it's possible, but I'm not sure what DockerHub does. GitHubs OAuth tokens can't be restricted to be read-only or to specific repos (https://stackoverflow.com/questions/26372417/github-oauth2-token-how-to-restrict-access-to-read-a-single-private-repo https://stackoverflow.com/questions/26372417/github-oauth2-t...) but I think Deploy Keys can.
    - donmcronald 8y ago
      They have a lot of scopes compared to GitLab (https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/ https://developer.github.com/apps/building-oauth-apps/unders...). I find it crazy that anyone would click authorize on a 3rd party app with the repo scope without having a way to (easily) identify unauthorized commits.
      - Kalium 8y ago
        A lot of developers are in a hurry and interested mainly in getting their builds to work so they can move on to the thing they actually care about. They don't think about the potential consequences of the easiest thing they did to make it work. This is how a sizable number of security incidents happen. The easiest thing to do is reckless, so people do it.
- kelleyk 8y ago
  I haven't seen anyone mention that Docker Hub's automatic build integration requires either "Owner"-level permissions on your organization or "Admin"-level permissions on the individual repository. Based on the GitHub-side audit log, Docker Hub seems to be using this access to add deploy keys to your repository, but this isn't mentioned in the documentation (which is why we had to go spelunking in the audit log), and if you try to take a least-privilege approach and grant only the read-only access that Docker Hub should require, your GitHub repository will simply not appear in the list of available repositories when you try to configure an automatic build. Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.
tsbinz 8y ago
Where did they say it started Thursday? The blog post says it was discovered Thursday ...
- rlt 8y ago
  Good point. I probably assumed it due to the "brief period" language, but you're right, that's highly ambiguous. I've edited my comment.
tie_ 8y ago
I also find it frustrating that they are not stating when exactly did the breach occur. The message implies that they know, due to the "brief period" claim, but they are not explicitly stating one of the most important facts. No mention in the FAQ either. 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.
- randallsquared 8y ago
  Yeah, the ambiguousness of “brief” is what implies that they do not know, with certainty. It seems most likely to mean “we think it happened at or after time n, but haven’t looked at everything yet, so the belief might change”.
  - sundvor 8y ago
    Our whole lives are but brief glimpses on the grand scale of thing. :) This really highlights the value of locking down the base images used in our own pipelines.
Nicksil 8y ago
> They downplayed it as "brief", "non-financial user data", and "less than 5%" of users. This caught my attention, as well; rubbed me the wrong way.
pluma 8y ago
I'm not even sure if their disclosure meets the requirements of the GDPR, considering the breach involved user data.
oldjokes 8y ago
Companies seem to have realized that security incidents are more of a public relations issue than anything else after Equifax. Just lockdown as much info as you can, limit anyone talking about anything, spin spin spin. No reason to be more proactive than that, you only get punished for it.
nickjj 8y ago
I didn't even get an email from Docker but I still changed my password. Funny enough, I only found out about the issue from seeing it on HN the other day.
jnbiche 8y ago
Also, have they even released the hash algorithm or if it was salted?
jrochkind1 8y ago
> 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. 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.

by rlt 8y ago

pritambaral 8y ago

Not surprising given their past outlook towards security.

rlt 8y ago

Oh, and if anyone with write access to your repositories had their GH/BB account linked to their DockerHub account, your source code could be compromised. 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 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-restrictions https://help.github.com/en/articles/about-oauth-app-access-r...

donmcronald 8y ago
Signed commits would be useful, right? I don’t know much about GitHub permissions, but I’ve skimmed GitLab’s. Why would Docker hub have write access to the repo? Is there really no read only access for repos?
- rlt 8y ago
  I think it's possible, but I'm not sure what DockerHub does. GitHubs OAuth tokens can't be restricted to be read-only or to specific repos (https://stackoverflow.com/questions/26372417/github-oauth2-token-how-to-restrict-access-to-read-a-single-private-repo https://stackoverflow.com/questions/26372417/github-oauth2-t...) but I think Deploy Keys can.
  - donmcronald 8y ago
    They have a lot of scopes compared to GitLab (https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/ https://developer.github.com/apps/building-oauth-apps/unders...). I find it crazy that anyone would click authorize on a 3rd party app with the repo scope without having a way to (easily) identify unauthorized commits.
    - Kalium 8y ago
      A lot of developers are in a hurry and interested mainly in getting their builds to work so they can move on to the thing they actually care about. They don't think about the potential consequences of the easiest thing they did to make it work. This is how a sizable number of security incidents happen. The easiest thing to do is reckless, so people do it.
kelleyk 8y ago
I haven't seen anyone mention that Docker Hub's automatic build integration requires either "Owner"-level permissions on your organization or "Admin"-level permissions on the individual repository. Based on the GitHub-side audit log, Docker Hub seems to be using this access to add deploy keys to your repository, but this isn't mentioned in the documentation (which is why we had to go spelunking in the audit log), and if you try to take a least-privilege approach and grant only the read-only access that Docker Hub should require, your GitHub repository will simply not appear in the list of available repositories when you try to configure an automatic build. Lots of people may have exposed credentials to Docker Hub that can do much more than disclose proprietary source code.

tsbinz 8y ago

Where did they say it started Thursday? The blog post says it was discovered Thursday ...

rlt 8y ago
Good point. I probably assumed it due to the "brief period" language, but you're right, that's highly ambiguous. I've edited my comment.

tie_ 8y ago

I also find it frustrating that they are not stating when exactly did the breach occur. The message implies that they know, due to the "brief period" claim, but they are not explicitly stating one of the most important facts. No mention in the FAQ either. 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.

randallsquared 8y ago
Yeah, the ambiguousness of “brief” is what implies that they do not know, with certainty. It seems most likely to mean “we think it happened at or after time n, but haven’t looked at everything yet, so the belief might change”.
- sundvor 8y ago
  Our whole lives are but brief glimpses on the grand scale of thing. :) This really highlights the value of locking down the base images used in our own pipelines.

Nicksil 8y ago

> They downplayed it as "brief", "non-financial user data", and "less than 5%" of users. This caught my attention, as well; rubbed me the wrong way.

pluma 8y ago

I'm not even sure if their disclosure meets the requirements of the GDPR, considering the breach involved user data.

oldjokes 8y ago

Companies seem to have realized that security incidents are more of a public relations issue than anything else after Equifax. Just lockdown as much info as you can, limit anyone talking about anything, spin spin spin. No reason to be more proactive than that, you only get punished for it.

nickjj 8y ago

I didn't even get an email from Docker but I still changed my password. Funny enough, I only found out about the issue from seeing it on HN the other day.

jnbiche 8y ago

Also, have they even released the hash algorithm or if it was salted?

jrochkind1 8y ago

> 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. 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.