The Docker Hub Hack: The Quick Fix and the Long-Term Questions
This weekend we learned of a hack to Docker Hub that compromised 190,000 accounts, approximately 5% of users. Unfortunately, it’s not a surprise that a hack of this scope happened. And now here it is. A Docker Hub database has been raided — hashed passwords and access keys stolen. Here’s Docker’s post mortem.
“Change your creds” was the familiar declaration that followed on Twitter these past few days. Docker recommended all affected users (who were notified by e-mail) to take the following steps:
- Change your password on https://hub.docker.com.
- Check https://github.com/settings/security for suspicious activity.
- Reconnect OAuth for Automated Builds.
- Roll over affected passwords and API keys stored in private repos/containers.
Docker’s security position makes it a bit uncertain how exactly the threat to people’s accounts may be mitigated following the attack. Docker’s official images are signed. Docker does not provide an end-to-end, verified secure capability to sign unofficial images. But unofficial images are not — and therein lies the problem. The developer may choose to verify an image they downloaded but it is not required.
What’s concerning is what the hackers may have done once they got access, wrote Twistlock Chief Technology Officer John Morello. The attackers may have poisoned images in the database that was accessed, embedding malware that can then propagate, creating a possible ripple effect. Without more details from Docker, there is really no way to know.
It’s both a possible and realistic scenario that an attacker may have quietly poisoned images in them, “embedding malware that they hope propagates elsewhere as others on the Internet pull from these repos,” Morello wrote. It’s impossible to know. Depending on their popularity, this may result in a huge ripple effect or little at all.
Without signed images, developers have to verify the images themselves. Most choose not to verify at all.
And the problem is not limited to Docker Hub users. Security expert Kenn White pointed out this breach could affect a lot of corporate, private, GitHub accounts as well:
On the Docker breach: Even if your company doesn't rely on Docker Hub for production, if a developer in your org enabled auto builds and linked to GitHub via oauth for a personal project, when that oauth token is compromised, _all_ repos on GH they had access to are vulnerable.
— Kenn White (@kennwhite) April 27, 2019
On Hacker News, developers are noticing the problems that they now face. A commenter asked why can they only authorize their entire GitHub account. How is it that the authorization can’t be executed at the repository level?
The issue with GitHub is reflective of how services manage third-party access. The access tokens are delivered from the Docker Hub, via OAuth, which uses tokens to authorize the GitHub account. Only the GitHub account is authorized, not the repositories.
GitHub Apps does allow for per repository authorization. According to GitHub, “GitHub Apps are first-class actors within GitHub. A GitHub App acts on its own behalf, taking actions via the API directly using its own identity, which means you don’t need to maintain a bot or service account as a separate user.”
The process for sharing, and the degree to which access is granted, varies depending on the tools the developer or their organization are using. It comes down to the scope that is set in the authorization.
The real concern, for now, is what the hackers accessed. There has not been a detailed debrief on that aspect of the breach. The longer term issue is not so easy to fix. Docker’s security posture has been years in the making.
#9: Docker’s Inherent Lack of Security, the Black Hat View
Twistlock is a sponsor of The New Stack.
Feature image by OpenClipart-Vectors from Pixabay.
