Detect CVE-2020-8555 using Falco

This CVE is a Server Side Request Forgery (SSRF) vulnerability in kube-controller-manager that allows certain authorized users to leak up to 500 bytes of arbitrary information from unprotected endpoints within the master’s host network (such as link-local or loopback services).

An attacker with permissions to create a pod with certain built-in Volume types (GlusterFS, Quobyte, StorageFS, ScaleIO) or permissions to create a StorageClass can cause kube-controller-manager to make GET or POST requests without an attacker controlled request body from the master’s host network.

Severity: Medium

Affected Kubernetes Versions

kube-controller-manager v1.18.0
kube-controller-manager v1.17.0 – v1.17.4
kube-controller-manager v1.16.0 – v1.16.8
kube-controller-manager < v1.15.11

Detecting CVE-2020-8555 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. Let’s see how you can quickly and easily write rules to filter this kind of behavior, so we can detect when someone is trying to exploit CVE 2020-8555.

The vulnerabilities can be triggered when using the following storage volume types: GlusterFS, Quobyte, StorageFS, ScaleIO. We can detect if the StorageClass object is created with one of the volume types or if Pods created using one of the volume types.

Detect StorageClass object created

- list: affected_storage_provisioners
  items:
  - "kubernetes.io/scaleio"
  - "kubernetes.io/quobyte"
  - "kubernetes.io/glusterfs"
  - "kubernetes.io/storagefs"
- macro: affected_storageclasses
  condition: (jevt.value[/requestObject/provisioner] in (affected_storage_provisioners))
  append: false
- macro: storageclass
  condition: ka.target.resource=storageclasses
# Detect CVE-2020-8555
- rule: Vulnerable StorageClass Object Created
  desc: Detect a vulnerable StorageClass object is created
  condition: kevt and storageclass and kcreate and affected_storageclasses and\
    \response_successful
  output: "Vulnerable storage class is created successfully (user=%ka.user.name provisioner=%jevt.value[/requestObject/provisioner]\
    \ objectName=%ka.target.name)"
  priority: "WARNING"
  tags: [k8s]
  source: "k8s_audit"

And the output would be like following:

Vulnerable storage class is created successfully (user=admin provisioner=kubernetes.io/scaleio objectName=sio-small)

Detect Pods with Vulnerable Volume Types Created

- macro: affected_volumes_in_pod
  condition: jevt.value[/requestObject/spec/volumes] contains "scaleIO" or jevt.value[/requestObject/spec/volumes] contains "glusterFS" or jevt.value[/requestObject/spec/volumes] contains "quobyte" or jevt.value[/requestObject/spec/volumes] contains "storageFS"
# Detect CVE-2020-8555
- rule: Create Pod with Vulnerable Volume Type
  desc: Detect an attempt to start a pod with a vulnerable volume type.
  condition: kevt and pod and kcreate and response_successful and affected_volumes_in_pod
  output: "Pod started with vulnerable volume mount (user=%ka.user.name pod=%ka.resp.name ns=%ka.target.namespace images=%ka.req.pod.containers.image volumes=%ka.req.pod.volumes.volume_type)"
  priority: "WARNING"
  tags: [k8s]
  source: "k8s_audit"

And the output would be like following:

Pod started with vulnerable volume mount (user=admin pod=pod-0 ns=default images=k8s.gcr.io/test-webserver volumes=(scaleIO,hostPath))

Conclusion

Prior to upgrading, this vulnerability can be mitigated by adding endpoint protections on the master or restricting usage of the vulnerable volume types and restricting StorageClass write permissions through RBAC. In addition to preventing vulnerable volume types to be used, it is also important to detect or monitor pods or StorageClass objects created with vulnerable volume type. Check out Falco and Sysdig Secure for more information to help mitigate the vulnerability.