Yesterday it was revealed that a security researcher who goes by the name avicoder managed to get hold of Vine's source code by accessing their Docker registry. If you're not familiar with Vine, it's a video sharing site that allows users to upload 6 second videos that are very easy to share and re-share. The service was acquired by Twitter in 2012. The registry, which was supposed to be private, was accessible online and with an easy to guess URL.
Why is this bad? Because if you own the source code of a widely used public service, you can use it to do all sorts of nasties - from spoofing the site to get users to give you their details, to injecting malware into vine.co itself to plant it on users' devices via fake cookies or phishing links, to exfiltrating user data, etc. etc., so although Vine is "just a website where teenagers share 6 second videos", it can be used maliciously just like any service with millions of registered users.
It's important to understand that this "walk in through the front door" hack was not an exploit of vulnerabilities in Docker itself or in Docker images. It was enabled due to a simple user error whereby a service that was supposed to be private and protected, was instead public and completely devoid of access controls.
While this could have ended very badly - it didn't (at least as far as we know): No user data was exposed, Vine's source code did not fall into the wrong hands, and the big security hole was plugged within 5 minutes of avicoder showing Twitter what he was able to do. Twitter's response reflects exactly how companies should react to "white hats" (ethical hackers) exposing their vulnerabilities, and they even paid him $10,000 for helping them avoid a breach.
How Did He Do It?
The full account of how it was done (from the horse's mouth) is on avicoder's website. He started by looking for subdomains, which often host systems that support the main website. At one point, avicoder found https://docker.vineapp.com, which piqued his interest since he was familiar with Docker and knew it could contain images used for running the Vine website.
Behind this URL was a Docker private registry, but instead of being private, it was publicly accessible. Avicoder used simple Docker pull commands to pull several dozen images from the registry, and in one of them he discovered the Vine source code. Through it he was also able to see Vine's API keys as well as third party keys and secrets. When he ran the image locally, he immediately had a local version of Vine running on his machine!
Our Recommendations
As the headline of this blog says, this was a bad case of RTFM. You shouldn't be playing with technology without applying the vendor's instructions and basic security best practices. We're talking about the most basic security practices and controls:
- Keep private things private: If you're setting up a private registry, or file server, or web server, or any kind of resource that is not supposed to be accessible to the public, make sure it isn't. Not doing that is like leaving your front door wide open.
- Properly configure your Docker registry access control: Docker provides specific instructions and recommendations on setting up user authentication for private registries, including authentication via a central service. In this particular case Vine used an older V1 registry, and V2 registries provide better options for access control - but this is not really relevant to this case because it wasn't configured at all.
- Security through obscurity: If the URL of the subdomain hadn't been something so obvious as docker.vineapp.com, it would have been a lot harder to find. If you have to make a URL public but only want those who know about it to reach it, give it a less obvious name like 3235543.vineapp.com.
- Control Docker image proliferation: I don't know if an image with the entire source code of Vine was even supposed to be on that registry, even if that registry had been truly private. This is not how companies typically manage and store their source code, certainly not in more traditional SDLC environments. Regardless of all the other factors, putting your entire source code in a single image just sounds like a bad idea. Don't do it. It's also good practice to review your registry periodically and clean it up.
Vine (and Twitter) managed to avoid a serious breach thanks to a dilligent researcher and luck, but this was entirely avoidable and easy to fix. It demonstrates once more that organization are more often exposed as a result of user errors and negligence, and not necessarily malice.
It also shows that when adopting new technologies like Docker, which touches many users within the organization (especially developers), the entire environment needs to be configured according to security best practices, with automated configuration and enforcement - and this is where Aqua can help.
