Preventing malicious use of Weave Scope
It was reported this week that TeamTNT hackers are using Weave Scope to aid their intrusions. As Weave Scope is an administration tool it has powerful capabilities making it important for any installation to be secured. We’re going to cover both how Scope is used and how you can mitigate this risk by securing it in any Kubernetes installation.
Adding Policy as Code to GitOps Pipelines
Trusted Delivery with GitOps and Policy as Code
The Art of Modern Ops: Authorize better with OPA - security policy as code
Intezer and Microsoft reported this week that TeamTNT hackers are using Weave Scope to aid their intrusions. As Weave Scope is an administration tool it has powerful capabilities making it important for any installation to be secured. We’re going to cover both how Scope is used and how you can prevent it being misused by securing it in any Kubernetes installation.
There are two ways that Scope can be used by hackers.
1. Using it as a tool after an initial exploit
According to the Intezer report this is how Scope was used, they say “To install Weave Scope on the server the attackers use an exposed Docker API port and create a new privileged container with a clean Ubuntu image.”
2. Accessing an unsecured installation of Scope
As Scope has administrative capabilities it can be used to install other software and exploit the cluster.
Administration tools are a common path for malicious attackers to compromise a system. Of course, the reason is that in order to be useful as an admin tool they have many powerful capabilities and the elevated privileges that go with that. That’s why these admin tools have often made their way into the common hacker toolbox to be used maliciously. For example, Microsoft reported a similar use of the Kubeflow dashboard in June.
As part of Scope’s function, it enables users to manage and control both the running workloads and the underlying infrastructure. For example, Kubernetes deployments can be stopped and started, logs accessed and SSH sessions opened all from a unified web UI.
Figure 1: Scope used to create a SSH terminal session to a Kubernetes host machine
Scope’s visual interface also allows administrators to quickly map out and understand their infrastructure. This mapping of services and workloads is invaluable to legitimate users who want to make sense of a complex Kubernetes deployment and inspect their infrastructure.
Figure 2: Scope used to map out services and workloads on Kubernetes
However, these capabilities are also invaluable to malicious attackers, who need to quickly establish the network structure and topology of services and workloads to identify possible attack vectors.
Securing Scope in Kubernetes
When using Scope legitimately, there are several steps you can take to avoiding security vulnerabilities. Here are the four best practises:
- Don’t run Scope as a public service
The same recommendation goes for all administration tools, from the Kubernetes Dashboard to Scope. These services should never be exposed publicly. In order to restrict the Scope service, you should set it up to serve only from localhost.
- Don’t grant Scope admin permission
Scope can have access to every element of your infrastructure, including the ability to open terminal sessions straight into your underlying machines. This grants enormous power, and whilst acceptable for a development cluster, is a security risk for a production cluster. Instead, run scope in read-only mode which will restrict Scope to observability only, and disallow any changes to your cluster from the scope user interface.
- Make sure Scope access is authenticated
No matter how you deploy it, Scope access provides significant access to your Kubernetes cluster. It should be proxied behind an authenticating service that will ensure only authorised users can access it. You could for example use something like Caddy or Ambassador to ensure only authenticated users can access Scope. Many solutions can plug into your existing SSO provider, so that users can access Scope using their Google or Active Directory accounts.
- Block access to sensitive services at the network level
Just like blocking inbound SSH on port 22 for production deployments at the network level, you should block access to sensitive administrative services on your cluster at the network level as well. This will prevent badly configured services from being accessible and protect you from malicious or erroneous configuration.
Scope used by malicious actors
Scope can also be used by malicious actors without your knowledge. The same power that makes Scope an attractive tool for legitimate administrators enables malicious actors to control your Kubernetes cluster as well. If an attacker gets administrator access to your systems through other means, they could install Scope to enable them to visualize and control your systems.
It’s important to note that Scope cannot be installed unless you are an administrator. It requires attackers to gain privileged access through some other means before being installed.
There are many avenues for attackers to gain access to your system and install Scope. Recent attacks have used the Docker API. You should make sure to follow Docker API best security practices and recommendations. You should also close the Docker API ports from external access. Taking these steps will ensure attackers can’t surreptitiously install Scope and control your cluster.
As we’ve shown Weave Scope is a powerful tool that can be abused by malicious attackers. We hope this post has given enough information on how to secure it in production. If you’d like further technical details please get in touch via our Community Slack where we’d be happy to help. On the broader topic of security, a great starting point is the Kubernetes blog.