A Detailed Talk about K8S Cluster Security from the Perspective of Attackers (Part 2)
Introduction
The attacker's perspective on K8S cluster security (Part 1) summarizes the attack methods on K8S components, node external services, business pods, and container escape methods in the K8S cluster, corresponding to attack points. This article will continue to introduce attack points namely lateral attacks, attacks on the K8S management platform, attacks on image libraries, and attacks on third-party components.
K8S Cluster Attack Point
Attack point: Lateral attack
Attack other services
There are often some internal services exposed through ClusterIP in the cluster. These services cannot be scanned outside the cluster, but some sensitive services may be found in the internal pod through the information collection method mentioned above, such as by scanning ports. Or look at environment variables etc.
Earlier, we found the address of the mysql service in the environment variables of the target pod during an internal penetration test, as shown in Figure
And successfully logged in to the mysql database by trying a weak password:
Attack API Server
The communication between the pod of the K8S cluster and the API Server is verified by the token of the ServiceAccount. There is an attack point here. If the ServiceAccount of the pod is too large, it can communicate with the API Server with high authority, and it is possible to view some sensitive information of the cluster. Or perform privileged operations or even further control the cluster.
The token is saved in the /run/secrets/kubernetes.io/serviceaccount/token file of the pod by default. In an actual attack, the address of the API Server can generally be viewed directly in the pod through environment variables, as shown in Figure
Speaking of the intranet ip address, please add that if you want to attack the kubelet of the current node in the pod, the ip address of the docker0 bridge can generally be directly used: 172.17.0.1. Figure demonstrates accessing port 10250 of the current node kubelet within a pod:
Man-in-the-middle attack
A man-in-the-middle attack is a classic attack method. We know that in the K8S cluster, network plug-ins such as Flannel, Calico, and Cilium also need to be used to achieve network communication between pods. Is there any possibility of a man-in-the-middle attack in the network communication within the K8S cluster? The answer is possible.
In a K8S cluster with the default configuration, if an attacker obtains the authority of a pod, it is possible to hijack the DNS of other pods through a man-in-the-middle attack.
In addition, K8S has also exposed vulnerabilities of man-in-the-middle attacks in the early years, such as CVE-2020-8554 and CVE-2020-10749.
Attack Point : Attack the K8S management platform
In addition to the officially launched Dashboard, there are many K8S management platforms, such as Rancher, KubeSphere, KubeOperator, etc. K8S management platforms can attack the most common Dashboard unauthorized access, as well as weak password login.
The figure is the management interface of Rancher. If you successfully log in to the management background through a weak password, you can create a privileged container and escape afterward as if the Dashboard was not authorized.
Management platforms such as Rancher directly control the entire cluster. Once a security problem occurs, the harm is very serious. From a security point of view, the management platform should try to avoid being exposed to the external network.
Attack Point: Attack the mirror library
Upload malicious images
Uploading a malicious image is also called image poisoning, which means that an attacker uploads a malicious image to a public repository or the victim's local repository, and then disguises the malicious image as a normal image to guide the victim to use the image to create a container, thereby achieving intrusion. According to the purpose of intrusion, malicious images can generally be divided into two types: malicious backdoor images that invade the container and malicious EXP images that invade the host.
Malicious backdoor image
This type of malicious image is mainly used to control the container. Generally, after the victim uses the image to start the container, it will bounce a container shell to the attacker. In this case, the attacker may be deploying a mining program or attacking the business running in the container.
Malicious EXP image
Such malicious images are no longer satisfied with only invading the container because the exploit hidden in it is often to exploit the container escape vulnerability, which is intended to gain control of the host.
Using Nday to attack the mirror library
This refers to attacking the victim's local image repository, such as Harbor, Nexus, etc. There was a privilege escalation vulnerability in the Harbor mirror library, and the harm was very serious.
The following are the loopholes exposed by Harbor in the 6 years since the release of the statistics on the Internet for reference:
|
CVE number |
type |
Risk level |
|
CVE-2019-16097 |
escalation of rights |
medium risk |
|
CVE-2019-16919 |
escalation of rights |
medium risk |
|
CVE-2019-3990 |
Username enumeration |
medium risk |
|
CVE-2019-19025 |
CSRF |
medium risk |
|
CVE-2019-19026 |
SQL injection |
medium risk |
|
CVE-2019-19029 |
SQL injection |
medium risk |
|
CVE-2020-13788 |
SSRF |
medium risk |
|
CVE-2020-13794 |
Username enumeration |
medium risk |
|
CVE-2020-29662 |
unauthorized access |
medium risk |
|
CVE-2019-19023 |
escalation of rights |
medium risk |
|
CVE-2019-19030 |
enumerate |
low risk |
Among them, CVE-2020-13794 can enumerate user information, and hackers can further perform brute force cracking. Although it is not a high-risk vulnerability, it is considered to be the most influential vulnerability [2]. Coincidentally, in our previous penetration test, Just encountered the Harbor mirror library with CVE-2020-13794.
The following is a brief demonstration of the verification of the vulnerability:
- First, register two accounts cstest and cstest2 on Harbor,
- Then execute the following command on the local attack machine:
curl -X GET "http://[victim-ip]/api/users/search?username=_" -H "accept: application/json" --user cstest:Test123456- See that the ids and usernames of all users are returned:
Attack Point: Attack third-party components
Some third-party components are also used in the K8S ecosystem, such as service meshes, API gateways, etc. These components may also have vulnerabilities, such as the RCE vulnerability of the open source API gateway Apache APISIX, and the unauthorized access or RCE vulnerability of the service mesh Istio. This article is limited in space and will not be discussed in detail. Interested readers can find out by themselves.
Summarize
At present, cloud-native attack and defense technologies and products are in a stage of rapid development, and many excellent utilization tools and detection tools have emerged in the community. The emergence of these tools has greatly lowered the threshold for attacks, and as cloud security has received more attention, more and more new attack technologies have appeared. How to ensure security on the cloud has become a common concern in the industry.
This article (Part 1 and Part 2) systematically summarizes 12 common attack points in K8S clusters and discusses various risks in cloud-native scenarios based on practical experience. Compared with the traditional intranet scenario, it can be seen that the architecture in this scenario is more complex and the attack surface is more. In the face of such a complex cloud-native application security scenario, the relevant security personnel should first grasp the security system of the business architecture in the cloud scenario as a whole. Adhering to the defense concepts and principles of defense-in-depth and least privilege, we will build a more comprehensive cloud security protection system.
Post a Comment