Detect CVE-2020-8557 using Falco

By Kaizhe Huang | Wednesday, July 15, 2020

CVE-2020-8557

The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail which acts as DoS attack.

Severity

Medium

Affected Kubernetes Versions

kubelet v1.18.0-1.18.5
kubelet v1.17.0-1.17.8
kubelet < v1.16.13

Detecting CVE-2020-8557 with Falco

Detecting exploitation attempts of this vulnerability is critical. Falco is the CNCF open source project for runtime threat detection for containers and Kuberenetes. You can use Falco to detect malicious activity both at the host and at the container level. Falco will generate security events when it finds abnormal behaviours, which are defined by a customizable set of rules.

One of the benefits of Falco is in leveraging its powerful and flexible rules language. Meanwhile, Falco comes with a handful out-of-box detection rules. Let’s see how we can detect when someone is trying to exploit CVE 2020-8557.

The vulnerability is due to the fact that the /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager. Usually when incompressible compute resource consumption like memory and disk hits the eviction threshold, the kubelet eviction manager will start evicting pods in order to preserve the availability of both the worker node and other pods running on the node. Meanwhile, /etc/hosts is also an important file to the system, As your machine gets started, it will need to know the mapping of some hostnames to IP addresses before DNS can be referenced. This mapping is kept in the /etc/hosts file. In the absence of a name server, any network program on your system consults this file to determine the IP address that corresponds to a host name. In the Falco out-of-box rules, there is one particular rule to detect any modification under /etc folder which includes /etc/hosts file.

- rule: Write below etc
  desc: an attempt to write to any file below /etc
  condition: write_etc_common
  output: "File below /etc opened for writing (user=%user.name command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)"
  priority: ERROR
  tags: [filesystem, mitre_persistence]

Or you can have this particular rule for the CVE:

- rule: Detect Write Below /etc/hosts
  desc: an attempt to write to /etc/hosts file (CVE-2020-8557)
  condition: open_write and container and fd.name=/etc/hosts
  output: "File /etc/hosts opened for writing (user=%user.name command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)"
  priority: ERROR
  tags: [filesystem, mitre_persistence]

When there is file write activity happen on the /etc/host file, the Falco rule above will be triggered and he output would be like following:

File /etc/hosts opened for writing (user=root command=bash parent=bash pcmdline=bash file=/etc/hosts program=bash gparent=<NA> ggparent=<NA> gggparent=<NA> container_id=384fc3447d54 image=kaizheh/nginx)

And when check the file size on the worker node, you will find the followings:

root@ip-172-20-48-137:/home/admin# find /var/lib/kubelet/pods/*/etc-hosts -size +1M
/var/lib/kubelet/pods/a8e75db1-b0cf-487a-ab5c-8041d33824f1/etc-hosts

The size of /etc/hosts file on the worker node is greater than 1M.

Mitigation Strategy

As the vulnerability is targeted at /etc/hosts file. A specific mitigation strategy is to apply the following AppArmor profile to your running containers:

#include <tunables/global>
 
profile cve-2020-8557 flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
 
  # accessing to network resources are subject to change per container
  network inet tcp,
  network inet udp,
  network inet icmp,
  deny network raw,
  deny network packet,
 
  file,
  Umount,
 
  # deny writes to /etc/hosts file
  deny /etc/hosts wl,
 
  # capabilities are subject to changes per container
  capability chown,
  capability dac_override,
  capability setuid,
  capability setgid,
}

The preceding AppArmor profile allows most of the activities from a container but deny writing to /etc/hosts file.

Conclusion

Prior to upgrading, it’s important to apply the mitigation strategy. In addition to preventing the vulnerability from being exploited, it is also important to detect or monitor any file write on the /etc/hosts file. Check out Falco and Sysdig Secure for more information to help mitigate the vulnerability.

References

https://github.com/kubernetes/kubernetes/issues/93032
https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/

← Previous

You are viewing documentation for Falco version: v0.30.0