151–160 of 269 posts
That's a nice summary. One thing I'm curious about is: > Data includes usernames and hashed passwords How are they hashed? And specifically, can we expect them to be already cracked?
Earlier quoted context omitted.
A checksum’s typical use is to detect transmission errors. A cryptographically secure signature is what’s needed.
If I hard-code the checksum, then the base image can't be tampered with at least.
Use proper cryptography and don't roll your own!
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 i…
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.
Though, as they say that passwords need changing, we can safely assume that their salting, hashing and work factor were insufficient and not following best practice. Just like the lack of 2FA.
Earlier quoted context omitted.
If I hard-code the checksum, then the base image can't be tampered with at least.
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!
Earlier quoted context omitted.
Hacking aside, Docker is an invitation to trouble. Anybody can publish a binary blob, and users are expected to blindly trust it. It's centralized. It doesn't have a context of "trustworthiness" yet I don't recall docker ever warning me that the image I'm downloading could have been the work of any person. Shortcuts all around -- kind of reminds me of MongoDB. Sad it's the primary player...
> It's centralized Actually only short names go to docker hub, one can setup their own registry and use it via dns names. Example: docker pull quay.io/letsencrypt/letsencrypt
Earlier quoted context omitted.
Many package managers that support git as source allow to pin to a specific commit sha. That's as far as I can see a quite secure way to keep using an uncompromised/verified version. It's not the most popular feature but people do it every now and then, probably it should be done more. I wonder if docker allows this and on the other hand if that's even feasible for say application images, given that applications must…
You can pull an image using the sha: docker pull ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2
To be fair, the docker.io/library/* images are signed but no other images are and there are a bunch of issues with how the signing policies work for users that want to enforce that some images must be signed.
Just wondering, genuinely out of curiosity - how does one get to this 5% number? If the attacker had access to the DB s/he had access to 100% user data right? Or did the get access to a partition of the user data? How is this even possible? Some very old backup that had only 5% of earliest users? Some log file which had plain-text creds of approx 5% users? Or did they discover the attack as it was happening and kicke…
Earlier quoted context omitted.
> It's centralized Actually only short names go to docker hub, one can setup their own registry and use it via dns names. Example: docker pull quay.io/letsencrypt/letsencrypt
Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.