Description

K8s mounts the service account token as part of every pod by default. The service account token is a credential that can be used as bearer token to access k8s APIs and gain access to other k8s entities. Many a times there are no processes in the pod that use service account token which means in such cases the k8s service account token is an unused asset that can be leveraged by the attacker.

Attack Scenario

An attacker would check for credential accesses so as to do lateral movements. For e.g., in most k8s attacks, the attacker after gaining entry into the k8s pods tries to use service account token and gain access into other entities.

Sample Policy

apiVersion: security.kubearmor.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: ksp-wordpress-block-sa
      namespace: wordpress-mysql
    spec:
      severity: 7
      selector:
        matchLabels:
          app: wordpress
      file:
        matchDirectories:
        - dir: /run/secrets/kubernetes.io/serviceaccount/
          recursive: true
    
          # cat /run/secrets/kubernetes.io/serviceaccount/token
          # curl https://$KUBERNETES_PORT_443_TCP_ADDR/api --insecure --header "Authorization: Bearer $(cat /run/secrets/kubernetes.io/serviceaccount/token)"
    
      action:
        Block

Description

Changes to system binary folders, configuration paths, credentials paths needs to be monitored for change. With KubeArmor, one can not only monitor for changes but also block any write attempts in such system folders. Compliance frameworks such as PCI-DSS, SOX, NERC CIP, FISMA, HIPAA, SANS expect FIM to be in place.

Attack Scenario

An attacker might want to update the configuration so as to disable security controls or access logs.

Sample Policy

apiVersion: security.kubearmor.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: fim-for-system-paths
      namespace: dvwa
    spec:
      action: Block
      file:
        matchDirectories:
        - dir: /bin/
          readOnly: true
          recursive: true
        - dir: /sbin/
          readOnly: true
          recursive: true
        - dir: /usr/sbin/
          readOnly: true
          recursive: true
        - dir: /usr/bin/
          readOnly: true
          recursive: true
      message: Alert! An attempt to write to system directories denied.
      severity: 5
      tags:
      - NIST
      - PCI-DSS

Description

Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to adversary controlled web servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. Installation of a root certificate on a compromised system would give an adversary a way to degrade the security of that system.

Attack Scenario

Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.

Sample Policy

apiVersion: security.kubearmor.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: protect-trust-bundles
      namespace: dvwa
    spec:
      action: Block
      file:
        matchDirectories:
        - dir: /etc/ssl/
          readOnly: true
          recursive: true
        - dir: /etc/pki/
          readOnly: true
          recursive: true
        - dir: /usr/local/share/ca-certificates/
          readOnly: true
          recursive: true
      message: Credentials modification denied
      severity: 1
      tags:
      - MITRE
      - MITRE_T1552_unsecured_credentials

Description

You can use a security feature called "process isolation" or "process whitelisting" to set specific processes to be executed as part of a container or pod, and deny everything else. This can help to secure a containerized environment by limiting the processes that can run within it, and preventing unauthorized processes from being executed.

Attack Scenario

Attacker uses command injection techniques to insert binaries in the pods/workloads and then execute the binary. Process-Whitelisting will deny any unknown process from execution.

Sample Policy

apiVersion: security.kubearmor.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: allow-specific-process
      namespace: dvwa
    spec:
      action: Allow
      file:
        matchDirectories:
        - dir: /
          recursive: true
      process:
        matchPaths:
        - path: /bin/bash
        - fromSource:
          - path: /bin/dash
          path: /bin/ping
        - fromSource:
          - path: /usr/sbin/apache2
          path: /bin/sh
        - path: /usr/sbin/apache2
      selector: 
        matchLabels:
          app: dvwa-web
          tier: frontend
      severity: 1

Description

Pods/Containers might get shipped with binaries which should never used in the production environments. Some of those bins might be useful in dev/staging environments but the same container image is carried forward in most cases to the production environment too. For security reasons, the devsecops team might want to disable use of these binaries in the production env even though the bins exists in the container. As an example, most of the container images are shipped with package management tools such as apk, apt, yum, etc. If anyone ends up using these bins in the prod env, it will increase the attack surface of the container/pod.

Attack Scenario

Attackers use system tools such fsck, ip, who, apt etc for reconnaissance and to download its accessory tooling from the remote servers.

Sample Policy

This policy denies execution of package management tools such as apt, apt-get in the target pods.

apiVersion: security.kubearmor.com/v1
    kind: KubeArmorPolicy
    metadata:
      name: ksp-wordpress-block-process
      namespace: wordpress-mysql
    spec:
      severity: 3
      selector:
        matchLabels:
          app: wordpress
      process:
        matchPaths:
        - path: /usr/bin/apt
        - path: /usr/bin/apt-get
      action:
        Block