9 ms·

What permissions did the leaked tokens have? If they had write access, then leaked personal data is the least of anyone's worries. The real concern is how clos

What permissions did the leaked tokens have? If they had write access, then leaked personal data is the least of anyone's worries. The real concern is how close the hackers came to infiltrating the image source for virtually every modern microservices system. If you could put a malicious image in say alpine:latest for even a minute, there's no telling how many compromised images would have been built using the base in that time.

lugg 8y ago
Pretty sure (don't quote me) those are read only and repo specific but that could contain all sorts of juicy info depending how lax you are with security of configs in private repos. Even then just read access to code often allows enough info for leveraging/escalating privilege.
- buzer 8y ago
  When you connect your Github account to Docker Hub, that will give DH full access to all repos (https://i.imgur.com/4jJWrez.png https://i.imgur.com/4jJWrez.png). I'm not even sure if Github's permission model supports adding only read access to private repositories. I'm not 100% sure if Docker hub uses deploy keys for repos it has access to thru the integration, but at least previously there was an option to manually add one to repository if it couldn't access it otherwise.
  - rkrzr 8y ago
    > I'm not even sure if Github's permission model supports adding only read access to private repositories. Their newer GH apps permission model allows fine-grained access to only specific repos (and also only read access e.g.). However their older Oauth flow only allows full access to everything. And 99% of GH integrations still seem to use the older authentication method. This is also something that many CI providers suffer from. There are only few that already support GH apps.
  - martinlofgren 8y ago
    I tried to give an user read-only access to a private repository on GitHub a few weeks ago, and from what I could tell it isn't possible.
    - thinkmassive 8y ago
      Did you look under Settings > Collaborators?
      - martinlofgren 8y ago
        Yep, it's only possible to give full access there. No read only.
rectang 8y ago
Maybe some day we'll get serious about reproducible builds, since reproducibility can serve as a layer of defense against such compromises.
- ohyeshedid 8y ago
  Maybe I'm missing something, but reproducible builds wouldn't be that helpful here with write access to the source repo, no? Definitely wouldn't have helped prevent the compromise.
  - Svenstaro 8y ago
    True, but they allow you to find out whether any Docker images have actually been compromised.
- debiandev 8y ago
  Debian is already using reproducible builds.
tiew9Vii 8y ago
Yes, huge poisoning target enhanced by the fact images/tags are not immutable, you really have no idea what you are fetching straight from dockerhub, one pull of the same image/tag may be different to the next pull. Most people blindly fetch without verifying regardless with multiple images of varying quality for software packages.
- elcomet 8y ago
  How could one verify ?
  - bayareanative 8y ago
    You can't. Not without end-to-end integrity with nonrepudiation. Checksums aren't anywhere near enough. But that's Docker.. security optional and run random, untrusted code from the internet.
    - jhasse 8y ago
      > Checksums aren't anywhere near enough. Why not?
      - toxik 8y ago
        A checksum’s typical use is to detect transmission errors. A cryptographically secure signature is what’s needed.
        jhasse 8y ago
        If I hard-code the checksum, then the base image can't be tampered with at least.
        Robin_Message 8y ago
        You can tamper with data protected by checksums: they are not designed to be irreversible, just fast to calculate and good at detecting errors, not deliberate manipulations. Use proper cryptography and don't roll your own!
typpo 8y ago
Docker Hub's Github integration requires both read and write access for private repositories. In fact, if you want it to set up deploy keys I think it requires Admin access. See this issue: https://github.com/docker/hub-feedback/issues/873 https://github.com/docker/hub-feedback/issues/873
techntoke 8y ago
I'd like to mention that Docker recently changed their automated builds to require giving them access to GitHub instead of just using a webhook. Glad I disabled access but no telling how long this was undiscovered.
- jcims 8y ago
  Interesting. What’s their rationale?
  - techntoke 8y ago
    I don't know for sure, but I would image it has something to do with wanting to make a unified solution with how to manage things, but I see a lot of great options, such as setting up a free GitLab pipeline to build and push your image. You don't even have to use Docker with kaniko, if you want a Kubernetes-native image builder and there are great registries that can be deployed in Kubernetes like Harbor, with automated security scanning. This can all be done in GitLab as well with paid features. I also recommend checking out building and deploying rootless containers for builds.
maricn 8y ago
Is it unreasonable to request more information about the attack that can help us understand whether our builds and images were affected? We might've built and deployed images containing or receiving production secrets which could be compromised. This is very important information at the moment. 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-notification 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.

lugg 8y ago

Pretty sure (don't quote me) those are read only and repo specific but that could contain all sorts of juicy info depending how lax you are with security of configs in private repos. Even then just read access to code often allows enough info for leveraging/escalating privilege.

buzer 8y ago
When you connect your Github account to Docker Hub, that will give DH full access to all repos (https://i.imgur.com/4jJWrez.png https://i.imgur.com/4jJWrez.png). I'm not even sure if Github's permission model supports adding only read access to private repositories. I'm not 100% sure if Docker hub uses deploy keys for repos it has access to thru the integration, but at least previously there was an option to manually add one to repository if it couldn't access it otherwise.
- rkrzr 8y ago
  > I'm not even sure if Github's permission model supports adding only read access to private repositories. Their newer GH apps permission model allows fine-grained access to only specific repos (and also only read access e.g.). However their older Oauth flow only allows full access to everything. And 99% of GH integrations still seem to use the older authentication method. This is also something that many CI providers suffer from. There are only few that already support GH apps.
- martinlofgren 8y ago
  I tried to give an user read-only access to a private repository on GitHub a few weeks ago, and from what I could tell it isn't possible.
  - thinkmassive 8y ago
    Did you look under Settings > Collaborators?
    - martinlofgren 8y ago
      Yep, it's only possible to give full access there. No read only.

rectang 8y ago

Maybe some day we'll get serious about reproducible builds, since reproducibility can serve as a layer of defense against such compromises.

ohyeshedid 8y ago
Maybe I'm missing something, but reproducible builds wouldn't be that helpful here with write access to the source repo, no? Definitely wouldn't have helped prevent the compromise.
- Svenstaro 8y ago
  True, but they allow you to find out whether any Docker images have actually been compromised.
debiandev 8y ago
Debian is already using reproducible builds.

tiew9Vii 8y ago

Yes, huge poisoning target enhanced by the fact images/tags are not immutable, you really have no idea what you are fetching straight from dockerhub, one pull of the same image/tag may be different to the next pull. Most people blindly fetch without verifying regardless with multiple images of varying quality for software packages.

elcomet 8y ago
How could one verify ?
- bayareanative 8y ago
  You can't. Not without end-to-end integrity with nonrepudiation. Checksums aren't anywhere near enough. But that's Docker.. security optional and run random, untrusted code from the internet.
  - jhasse 8y ago
    > Checksums aren't anywhere near enough. Why not?
    - toxik 8y ago
      A checksum’s typical use is to detect transmission errors. A cryptographically secure signature is what’s needed.
      - jhasse 8y ago
        If I hard-code the checksum, then the base image can't be tampered with at least.
        Robin_Message 8y ago
        You can tamper with data protected by checksums: they are not designed to be irreversible, just fast to calculate and good at detecting errors, not deliberate manipulations. Use proper cryptography and don't roll your own!

typpo 8y ago

Docker Hub's Github integration requires both read and write access for private repositories. In fact, if you want it to set up deploy keys I think it requires Admin access. See this issue: https://github.com/docker/hub-feedback/issues/873 https://github.com/docker/hub-feedback/issues/873

techntoke 8y ago

I'd like to mention that Docker recently changed their automated builds to require giving them access to GitHub instead of just using a webhook. Glad I disabled access but no telling how long this was undiscovered.

jcims 8y ago
Interesting. What’s their rationale?
- techntoke 8y ago
  I don't know for sure, but I would image it has something to do with wanting to make a unified solution with how to manage things, but I see a lot of great options, such as setting up a free GitLab pipeline to build and push your image. You don't even have to use Docker with kaniko, if you want a Kubernetes-native image builder and there are great registries that can be deployed in Kubernetes like Harbor, with automated security scanning. This can all be done in GitLab as well with paid features. I also recommend checking out building and deploying rootless containers for builds.

maricn 8y ago

Is it unreasonable to request more information about the attack that can help us understand whether our builds and images were affected? We might've built and deployed images containing or receiving production secrets which could be compromised. This is very important information at the moment. 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-notification 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.