Study: DevOps Servers In The Wild Highlight Infrastructure Security Needs

Source – tripwire.com

A mature DevOps practice involves applying multiple tools at different steps of the delivery pipeline, and a new study from IntSights focuses on these tools that may be open to attack on the Internet.

Each new tool added to your process can expand your attack surface area – and, in many cases, new development and delivery tools are being used without oversight from a security team. With complex tools being used in each DevOps step, potential attack vectors and the risk of compromise rapidly increase.

Under the assumption that the majority of DevOps tools are web-based, IntSights studied DevOps servers and software found accessible via the internet.

The research centered around a list of nearly 26,000 URLs and subdomains compiled by combining known DevOps tool names with the domains of different organizations, such as by searching for Jenkins automation servers under the hostname “jenkins.example.com.”

Every server that answered with a live and valid response was considered an open server and was then subjected to further investigation to determine what sort of security was present. No “fancy attack tools” were used. Only OSINT (Open Source Intelligence) tools and websites.

Are DevOps Tools Expanding Your Attack Surface?

The results show that 23.6 percent – or 5,967 out of 25,876 – of the URLs tested were accessible via the web, with a variety of access levels. In some cases, some software was totally exposed with no username and password combination.

In one example, a Jenkins server was available with multiple builds to investigate. Automated build tools often have hardcoded credentials or accidentally expose data via commands or output in log files, providing information for further attacks.

In another example, an open Elasticsearch server, which requires no authentication by default, was found. Elasticsearch is a distributed search and analytics engine and as such usually contains a wealth of information, such as logs and security data. In other words, it’s a goldmine for attackers.

In many other cases, some authentication security exists, but it is left up to the application. Default logins or weak password policy and enforcement may lead to easily guessable passwords existing for these DevOps tools.

While these results are not terribly surprising, they are a reminder of the importance of securing your toolchain and infrastructure.

We focus a lot on applying automated security within your process, ensuring that what you are delivering is secure, but the tools and servers running the tools also require inspection and monitoring.

How to Mitigate Exposure of DevOps Tools

There are some standard recommendations to mitigate exposure of DevOps tools. First of all, related to the basis behind the study, it’s best to remain hidden. Don’t use DevOps tool names or other obvious identifiers in your internet facing server names.

Without these, this particular study wouldn’t have gotten off the ground. Using non-default ports can help, but blocking external access or requiring a VPN to access your DevOps tools will minimize your attack surface area.

We always sing the praises of multi-factor authentication, and enabling MFA on your tools can help with weak password situations.

As for securing your DevOps tools and infrastructure, traditional security tools play a large role. Tripwire Enterprise contains DevOps specific policies for tools, such as Docker and Kubernetes, which can help ensure you are following best practice security standards in the configuration of these tools.

Continuous monitoring for changes to files and configurations helps maintain your security posture and provides early notification if a breach does occur. Vulnerability and network scanning with tools, such as Tripwire IP360, allows you keep a current view of what systems and services are accessible not to mention assists with detecting vulnerabilities and missing patches.

As you add new DevOps mechanisms from build and continuous integration tools, testing suites, security tools, and more, it is important to secure your tools and infrastructure to mitigate the added risks.