This morning, Twitter disclosed that they had found vulnerability in their Docker installation, which allowed an external (albeit friendly) hacker to download Vine’s entire source code. The original article can be viewed here on Deccan Chronicle.
The Docker setup vulnerabilities in question is an internal system for Twitter, as reported by the article, which is primarily used by Twitter staff to manage Vine content.
Avicoder Discovers Twitter Docker Setup Fraught with Vulnerabilities
The security researcher, Avicoder, discovered that the particular Docker set up was rife with vulnerabilities. In addition, Twitter was not using the latest version of the Docker distribution, which means that the Docker Engine, Docker Registry, or other parts of the Docker ecosystem they were using could be obsolete and vulnerable.
According to the report, Avicoder was able to access Docker commands that were supposedly only available to internal use. In addition, he was able to “search and retrieve content from Twitter’s Docker setup.” The report went on to say: “The researcher even downloaded over 80 Docker images from Twitter’s Vine servers, only to realize that one of those server images contained the Vine’s entire source code.”
These are indeed grave risks that can severely impact a company’s business if your source code was freely accessible by a remote hacker.
How should an organization protect itself while still moving to embrace new technologies like Docker?
To be clear, this is not the failure of Docker. Rather, it is the failure of internal governance processes and capabilities.
When you are using open source software, or any software for that matter, you must ensure that you use the latest version, that proper patches are installed so attackers do not have an easy way in.
In this case, Twitter should have established a process to continuously verify if the versions of Docker Engine, Docker Registry are the latest. More importantly, if the checks fail, the governance process may also proactively stop the operation of the system. This is what is called a “fail-close” measure, which is recommended for security operations. Fail-close may be tough to do if the system is customer facing or handles transactions, but for an internal system like content management, fail-close is definitely the right way to go.
In addition, Twitter should have had stronger access management to the Docker environment. The attacker reported that he was able to access a range of Docker commands, which were supposed to be accessible only by internal staff.
Docker’s built-in access management is a bit challenging because it is either all or nothing. As a Docker user organization, you need to prepare a layer of fine-grained access control capability on top of Docker, which allows you to control who can access which Docker command.
Twistlock is enforcing such governance processes with many of our customers. Not only we check for versions and configurations of the host, the OS, the Docker Engine, and other parts of the Docker ecosystem, we also enforce least-privilege access rights across the organization with native LDAP groups and identities. In addition, we can proactively stop applications running on an obsolete or risky versions of Docker Engine, OS, or hosts.
Below are a few screen shots of the Twistlock console where customers can configure built-in vulnerability and configuration checks of your Docker setup, as well as configuring access policies to your Docker environment.
Figure 1: These built-in configuration checks ensure that you are using the latest version of the Linux kernel and Docker
Figure 2: Examples of user action logs on Docker systems and whether the action was denied or allowed Twistlock’s access control capability.
If Twitter had Twistlock installed, this attack would not have been successful, as Twistlock would have reported the use of the obsolete systems, regulated user accesses, and may also proactively failed the Vine content management system in question.
Twitter was brave enough to disclose this. How do you know you are not at risk?
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog
CVE-2018-1002105: Critical K8s VulnerabilityRead the Blog
Advanced runc Debugging for Fun and ProfitRead the Blog
Introducing Twistlock Support for AWS Lambda LayersRead the Blog
Cloud Native Security Intelligence: Integrating with AWS Security HubRead the Blog