A security flaw that provides a backdoor through which Docker containers can be compromised via unsecured remote connections may require IT teams to revisit their approach to DevSecOps.
At the core of the issue is a cryptomining worm discovered by Cado Security, which steals credentials from Amazon Web Services (AWS) that have been stored on a local PC. Once those credentials have been stolen, a team of cybercriminals dubbed TeamTNT scans the internet for misconfigured Docker containers to exploit using those credentials.
The trouble is that when it comes to remote connections most Docker containers are misconfigured, says Sergei Shevchenko, CTO of Prevasio, a provider of a service that employs machine learning algorithms to scan for vulnerabilities in containers.
In the name of simplicity, the default setting for Docker containers is to enable remote connections. Adding the code required to secure those connections requires a level of sophistication that many developers simply don’t possess, he says, noting that as such, it’s relatively trivial for cybercriminals to exploit that vulnerability. TeamTNT has been exploiting this vulnerability to run cryptomining malware on systems to generate digital currencies, which many IT organizations consider to be a nuisance crime.
However, Shevchenko says it’s relatively simple for cybercriminals to exploit this flaw to run malware that would “jailbreak” from a container, which could allow a cybercriminal to take over an entire host to replicate additional malware.
Shevchenko says this flaw is yet another example of a security sin of pride stemming from architectural arrogance. At the very least, there needs to be more focus on authentication to warn developers they have configured a Docker container in a way that enables insecure remote connections, says Shevchenko.
As the use of Docker containers becomes more widespread the number of security issues being discovered is increasing. Cybercriminals are beginning to focus more time and effort on Docker containers simply because they are seeing enough of them in production environments to make it worth their while to research potential exploits. At the same time, cybersecurity research teams are focusing on containers as the overall market continues to expand. The result is a steady stream of new vulnerabilities that DevSecOps teams need to monitor continuously.
In the meantime, the debate over container security continues. In theory, container applications are more secure than monolithic applications because it’s easier to rip and replace code that includes known vulnerabilities. In practice, the number of containers creates levels of dependencies that are difficult to monitor continuously. A compromised container could provide lateral access to sensitive data in ways no one in an IT team can easily see or much less expect.
The one thing that is certain is container security is different. Many of the technologies and assumptions that were made to secure monolithic applications simply don’t apply. It’s incumbent on IT teams to modernize the security tools and processes they have implemented alongside their tools and processes to modernize cloud-native application development using containers. Otherwise, it’s not a question of whether a container might be breached as much as it is how widespread that issue is likely to become.