Docker Host Security and Docker Forensics

What if we get a vulnerable WebApp (say RCE/CI) running on a Kubernetes pod ?

Actually, in this blog post, we will look into the answers to this question with the support of Attackdefense labs.

Kubernetes is a popular container orchestration platform. Containers are a technology that packages all the software and configuration required for applications and their dependencies to run together in a lightweight, portable, and self-sufficient manner. Containers offer advantages such as isolation, portability, and scalability, enabling applications to run seamlessly.

Kubernetes (often abbreviated as K8s) is an open-source platform originally developed by Google and currently managed by the Cloud Native Computing Foundation (CNCF). It is used to automatically deploy, scale, and manage large and complex applications running multiple containers. Kubernetes is widely supported by many major companies and organizations.

If a sensitive Web Application is running in a Kubernetes pod, it poses a significant security risk. Vulnerabilities such as Remote Code Execution (RCE) or Continuous Integration (CI) attacks can allow attackers to take control of the application and exploit the system.

In the case of an RCE vulnerability, attackers can interactively execute code on the target system. This enables them to run malicious code on the application server and make changes to the system as they please.

In a Continuous Integration (CI) attack, attackers target the application’s continuous integration process to bypass security measures. This could lead to the attacker interfering with the code base and making malicious changes.

These types of attacks can result in serious consequences, such as unauthorized access to customer data, service disruptions, data loss, or system integrity compromise.

Therefore, Kubernetes pods running sensitive Web Applications should undergo regular scanning for security vulnerabilities and weaknesses. Security measures must be implemented, and application updates should be carried out regularly. Additionally, proper management of access controls and privileges is of critical importance. Following a robust cybersecurity policy is essential to minimize security vulnerabilities.

Docker:ThreatScape

Weak Credentials: Abusing Portainer Tool

Portainer is an open-source container management tool used to simplify the management of Docker environments. It provides a user-friendly web interface that allows users to create, manage, and monitor Docker containers, images, networks, and volumes without the need for complex command-line tools.

The phrase “Weak Credentials: Abusing Portainer Tool” suggests that someone might be using weak login credentials to gain unauthorized access to a Portainer instance. This can be a significant security concern as it can lead to various malicious activities, such as:

1. Unauthorized access: Attackers can gain access to the Portainer dashboard, allowing them to control and manipulate Docker containers, networks, and other resources.
2. Container tampering: Once inside, attackers can modify or tamper with running containers, potentially leading to data loss, service disruptions, or the injection of malicious code.
3. Resource abuse: An unauthorized person can use the resources managed by Portainer to run unauthorized containers, potentially impacting the performance of legitimate applications and services.
4. Information disclosure: Attackers can access sensitive information stored in Docker containers or images exposed through Portainer.

To prevent such abuses, it’s essential to follow best practices for securing Portainer:

1. Strong Credentials: Ensure that you set strong and unique login credentials (username and password) for the Portainer admin account. Avoid using default or easily guessable passwords.
2. Use SSL/TLS: Enable HTTPS on the Portainer web interface to encrypt communications between the user’s browser and the Portainer server, preventing data interception.
3. Access Control: Assign appropriate roles and permissions to users in Portainer based on their responsibilities. Limit access to sensitive operations and data.
4. Network Security: Restrict access to the Portainer port (typically port 9000) through firewalls or security groups to allow only trusted IP addresses.
5. Regular Updates: Keep Portainer and all underlying components (Docker, operating system) up to date with the latest security patches.
6. Monitor Activity: Regularly monitor and review the logs and activities in Portainer to detect any suspicious behavior.
7. Backup Strategy: Implement a backup strategy for critical data and configurations managed by Portainer.

• Portainer management tool is running with default password
• Admin interface exposed on external interface

Let’s continue with Pentester Academy Labs

— — Weakest Link — -

I am starting the lab by clicking on “Run.” At the bottom of the lab, it provides a username and password. Using this login information, I access portainer.io.

Username: admin

Password: cassandra

What is porttainer.io?

Portainer.io is an open-source user interface for containerization technologies like Docker and Kubernetes. Containerization is a technology that enables applications to run in isolated environments, and Docker is one of the containerization tools.

Portainer.io provides a user-friendly web-based interface to manage and monitor containerization tools such as Docker and Kubernetes. With this interface, users can create, manage, stop, and remove containers effortlessly. Additionally, they can monitor application performance, connect containers to networks, view logs, and track basic resource utilization.

By using Portainer.io, users can interact with Docker and Kubernetes containerization platforms more efficiently and easily. Furthermore, being an open-source tool allows users to use it without paying any platform-specific fees. As a result, Portainer.io has become a popular choice for managing containers. However, before using Portainer.io, it’s essential to take security precautions and configure critical settings correctly since management interfaces like this can introduce potential security risks.

By clicking on the “Endpoints” tab, we can view the details of the endpoints.

Listing Docker Images ==> Images Tab

Starting Container with host filesystem mounted

Name:Test

Let’s select the image name.

On the left-hand side, under the “Containers” tab, we can see the container that we have created.

Listing files of host filesystem

ls -l /host/

breaking out of container

ps-eaf

chroot /host bash

In Portainer, when you use this command, it allows you to access and interact with the host’s filesystem from within the container. The “/host” directory represents the root filesystem of the host machine, giving you access to the host’s files and directories.

However, please note that running this command inside a container can be potentially risky, as it provides significant access to the host’s system. This level of access may violate the principle of container isolation, and it should be used with caution, especially in production environments.

Find The Process ID And Kill It

ps -eaf | grep "process_name | grep -v grep | awk '{ print $2 }' | xargs kill -9

When we look at Shodan, even by simply searching for “portainer,” we can see vulnerable devices and services

Reflects the statement about searching for “portainer” on Shodan and the potential visibility of vulnerable devices and services.

Or, CVE 2020–24263 demonstrates how critical the situation can be.

Misconfiguration: Exposed Docker Socket

The phrase “Misconfiguration: Exposed Docker Socket” refers to a security issue that arises when the Docker daemon’s socket is left exposed or accessible to unauthorized users due to incorrect or insecure configurations.

The Docker socket is a communication interface used by the Docker API to manage and interact with Docker containers and the Docker daemon itself. By default, this socket is located at /var/run/docker.sock on Linux systems, and it allows local access to Docker-related functionalities. Docker clients and tools communicate with the Docker daemon through this socket.

The exposure of the Docker socket to unauthorized users can lead to significant security risks:

1. Privileged Access: If the Docker socket is accessible to non-privileged users or remote entities, they can gain unauthorized control over Docker operations, including container creation, execution, and removal.
2. Container Escape: A malicious actor who gains access to the Docker socket may potentially exploit vulnerabilities to escape the confines of a container and access the host system, leading to a complete compromise of the system’s security.
3. Resource Abuse: Unauthorized access to the Docker socket allows attackers to run malicious containers or consume excessive resources, affecting the overall performance and availability of the host and other containers.

To prevent the misconfiguration of an exposed Docker socket, follow these best practices:

1. Secure Permissions: Ensure that only authorized users have access to the Docker socket. By default, only the root user and users in the docker group can access the socket.
2. Avoid Exposing the Socket Remotely: Do not expose the Docker socket to remote networks or the internet. It should only be accessible locally.
3. Use Docker Remote API with Caution: If the Docker remote API needs to be exposed for specific use cases, make sure to protect it with proper authentication and authorization mechanisms, such as TLS certificates and access control.
4. Regularly Update Docker: Keep your Docker daemon and related components up to date with the latest security patches and updates.
5. Audit System and Containers: Regularly audit your system and containers for security vulnerabilities and misconfigurations.

Remember that a misconfigured Docker socket can lead to severe security incidents, so it is crucial to implement proper security measures and adhere to best practices when managing Docker environments.

Let’s continue with Pentester Academy Labs — Misconfigured Docker Socket

Interacting with the TCP Socket

netstat -tnlp

The command “netstat -tnlp” is a network utility used to display network connections and listening ports on a computer. This command is available in Linux and Unix-based operating systems.

The parameters of the command are as follows:

• “-t”: Shows TCP connections.
• “-n”: Displays IP addresses and port numbers in numerical format (does not use DNS names).
• “-l”: Lists listening connections on the local address.
• “-p”: Shows which processes are using which connections and ports.

Using this command is quite useful to see which TCP connections and listening ports are active on the system and to identify the processes that are using these connections and ports. It can also be used to detect potential network issues and monitor network connections for security purposes.

Docker TCP Socket Confirmed

Configuring Docker Client to use TCP Socket

export DOCKER_HOST=”tcp://127.0.0.1:2375”

Listing Docker Images

Starting container with host file system mounted

docker run -it -v /:/host modified-ubuntu:latest bash

When you run this command, it will start an interactive terminal session inside the Docker container based on the “modified-ubuntu:latest” image. Additionally, the entire root file system of the host machine will be accessible inside the container under the “/host” directory. Please be cautious when performing such operations, as giving the container such extensive access to the system may pose potential security risks.

The process of Host file system

ps -eaf

Misconfiguration:Abusing Containerd

The phrase “Misconfiguration: Abusing Containerd” refers to a security issue that arises when Containerd, an open-source container runtime, is improperly configured, leading to its exploitation for malicious purposes.

Containerd is a core component used to manage container runtimes and is utilized by Docker for container creation, execution, and management. Containerd provides low-level container management and ensures secure container execution with isolation and performance.

When Containerd is misconfigured, it can create security risks and be vulnerable to abuse for malicious activities:

1. Container Escape: Misconfigured Containerd may allow attackers to break out of the container’s isolation and gain unauthorized access to the host system.
2. Unauthorized Access: Malicious actors can exploit misconfigurations in Containerd to gain unauthorized control over containers and container runtime functions.
3. Container Manipulation: Misconfigured Containerd might enable unauthorized manipulation of containers, potentially leading to data breaches or unauthorized data access.

To mitigate these risks, it is essential to follow best practices for configuring and securing Containerd. Regularly update Containerd and ensure that it is correctly configured with proper security measures to prevent potential abuse and unauthorized access.

Let’s continue with Pentester Academy Labs — Leveraging Cantainerd

ctr image list

The ctr image list command is used to list the images present in the containerd archive using the ctr command-line tool.

Containerd is a foundational component and container runtime used for running and managing containers. The ctr command allows interaction with containerd and can be used to perform various container operations.

When you run the ctr image list command, it will display a list of all images managed by containerd. This command is useful for viewing all the images that have been created and are available through containerd. Additionally, you can use other parameters of the ctr command to add more detailed information or apply filters to the listed images as needed.

Starting Container with host filesystem mounted

Starting Container in privileged Mode

Checking capabilities on container

cap_dac_read_search docker exploit

The “cap_dac_read_search” capability in Docker is a discretionary access control (DAC) mechanism that grants users permission to access specific files and directories.

Misconfiguration: Abusing runc Runtime

The phrase “Misconfiguration: Abusing runc Runtime” refers to a security issue that arises when the runc container runtime is improperly configured, leading to its exploitation for malicious purposes.

runc is an open-source container runtime used to spawn and run containers based on the Open Container Initiative (OCI) specifications. It is a fundamental building block for many container runtimes, including Docker and Containerd.

When runc is misconfigured, it can pose significant security risks and be vulnerable to abuse for malicious activities:

1. Container Escape: Misconfigured runc may allow attackers to escape the confines of a container and gain unauthorized access to the host system, potentially compromising the entire system’s security.
2. Privilege Escalation: If runc is not configured with proper security measures, attackers may escalate privileges and gain access to resources or actions beyond what they are entitled to.
3. Unauthorized Access: Misconfigured runc can enable unauthorized users to manipulate containers, potentially leading to data breaches, service disruptions, or unauthorized data access.

To mitigate these risks, it is crucial to follow best practices for securing runc:

1. Regular Updates: Keep runc and all container runtimes up to date with the latest security patches and updates.
2. Secure Configuration: Configure runc with the appropriate security options and apply the principle of least privilege to limit access and capabilities.
3. Isolation: Ensure that containers are properly isolated from each other and from the host system to prevent unauthorized access.
4. Access Control: Use strong authentication and access control mechanisms to restrict access to the runc runtime.
5. Audit and Monitoring: Regularly audit the system and monitor container activity for any signs of unauthorized access or abuse.

By adhering to these best practices and maintaining a strong security posture, you can minimize the risks associated with misconfigured and abused runc runtimes in containerized environments.

Let’s continue with Pentester Academy Labs — Low-Level Container Runtime

Generating dummy container specification

misconfiguration:Insecure Docker Registry

The misconfiguration “Insecure Docker Registry” refers to a situation where a Docker registry is not securely configured, potentially leading to security vulnerabilities and risks in the Docker environment.

When a Docker registry is insecurely configured, it means that the registry lacks proper security measures to protect the Docker images stored within it. This could result in several security issues:

1. Unauthorized Access: An insecurely configured Docker registry might allow unauthorized users to access sensitive Docker images, leading to potential data breaches or unauthorized data access.
2. Image Tampering: Attackers could modify Docker images stored in the insecure registry, potentially injecting malicious code or compromising the integrity of the images.
3. Man-in-the-Middle Attacks: Without proper encryption and authentication, attackers may perform man-in-the-middle attacks to intercept and tamper with image downloads.
4. Credentials Exposure: Insecure registries may lead to the exposure of sensitive credentials, such as authentication tokens or passwords, if they are transmitted or stored without encryption.

To avoid the misconfiguration of an insecure Docker registry, follow these best practices:

1. Enable Secure Communication: Use HTTPS (TLS/SSL) to encrypt communications between Docker clients and the registry. This prevents eavesdropping and man-in-the-middle attacks.
2. Authentication and Access Control: Implement strong authentication mechanisms for users accessing the registry, and enforce access controls to ensure that only authorized users can push and pull images.
3. Registry Storage Security: Protect the underlying storage of the Docker registry to prevent unauthorized access to image files.
4. Regular Updates and Patching: Keep the Docker registry software up to date with the latest security patches and updates to avoid known vulnerabilities.
5. Image Signing and Verification: Consider using image signing and verification mechanisms to ensure the authenticity and integrity of images.
6. Monitor Registry Activity: Regularly monitor the activity and access logs of the Docker registry to detect any suspicious or unauthorized behavior.

By adhering to these security practices, you can mitigate the risks associated with an insecurely configured Docker registry and enhance the overall security of your Docker environment.

Fingerprinting

Check images present on the registry

List tags for treasure-trove image

Checking manifest file for image

Let’s look at it on Shodan as well: docker-distribution-api-version.

Weak Credentials: Protected Docker Registry

“Weak Credentials: Protected Docker Registry” refers to a situation where a Docker registry is secured with strong authentication measures to prevent the use of weak credentials that could potentially be exploited by attackers.

Docker registry is a central repository used to store and distribute Docker images. Securing the Docker registry is crucial to prevent unauthorized access and ensure the integrity of the images stored within it.

When a Docker registry is protected with strong authentication, it means that the following security measures are in place:

1. Strong Passwords: Users are required to use strong and complex passwords to access the Docker registry. Weak passwords that are easily guessable are disallowed.
2. Multi-Factor Authentication (MFA): Where possible, MFA is implemented to add an extra layer of security. This typically involves a second authentication factor like a one-time code sent to the user’s mobile device.
3. Certificate-based Authentication: Certificates can be used to authenticate users and ensure secure connections between the Docker client and registry.
4. OAuth Integration: Integration with OAuth providers allows for a centralized authentication mechanism and can enhance security by leveraging existing user management systems.
5. IP Whitelisting: Access to the registry can be restricted based on IP addresses, allowing only trusted sources to interact with it.
6. Rate Limiting: Implementing rate limiting can prevent brute-force attacks by limiting the number of login attempts within a certain time frame.

Let’s continue with Pentester Academy Labs — Protected Docker Registry

Get requests failed due to untrusted server certificate

Launch Dictionary Attack

Wordpress is running on the targer server

Checking images present in registry

pull wordpress image

Running wordpress container and checking the web root directory

Docker Host Security and Docker Forensics are two important aspects of ensuring the security and integrity of Docker environments. Let’s take a closer look at each:

Docker Host Security:

Docker Host Security involves implementing various security measures to protect the host system where Docker is running. As Docker containers share the host’s kernel, securing the host is crucial to prevent potential attacks or unauthorized access to the entire system. Here are some key considerations for Docker host security:

• Regular Updates: Keep the host operating system, Docker daemon, and all related components up to date with the latest security patches and updates.
• Limited Access: Restrict physical and remote access to the Docker host to only authorized personnel.
• Host Firewall: Configure the host firewall to allow only necessary incoming and outgoing network traffic, limiting exposure to potential threats.
• Isolation: Ensure containers are properly isolated from each other and the host system using Docker’s security features like namespaces and control groups (cgroups).
• Least Privilege: Run Docker containers with the least privilege necessary, limiting access to only required resources and capabilities.
• Secure Docker Daemon: Configure the Docker daemon to listen on a secure socket or bind it to specific interfaces to minimize external exposure.
• Securing Docker Socket: Protect the Docker socket (/var/run/docker.sock) from unauthorized access and limit access to only trusted users or through a protected API.
• User Authentication: Use strong authentication methods for Docker clients and users accessing the Docker daemon.
• Container Image Security: Only use trusted and verified container images from reputable sources to minimize the risk of using potentially malicious images.

Docker Forensics:

Docker Forensics involves the process of investigating and analyzing Docker containers, images, and the Docker host to identify and understand potential security incidents, breaches, or unauthorized activities. Docker Forensics aims to gather evidence, reconstruct events, and support incident response efforts. Some key aspects of Docker Forensics include:

• Log Analysis: Analyze Docker logs to understand container activities, events, and potential anomalies.
• Image Verification: Verify the integrity and authenticity of container images used on the Docker host.
• Container Inspection: Inspect containers for any signs of tampering or unauthorized changes.
• Host Analysis: Examine the Docker host for signs of unauthorized access, security breaches, or malicious activities.
• Network Traffic Analysis: Monitor and analyze network traffic between containers and the host to detect any unusual or malicious behavior.
• Metadata Analysis: Examine Docker metadata to understand the container’s history and how it was created.
• Time Stamping: Record timestamps and sequence of events to establish the chronology of actions.

Docker Forensics plays a critical role in incident response and post-incident analysis, helping organizations understand and address security issues in Docker environments.

By focusing on Docker Host Security and Docker Forensics, organizations can strengthen the overall security of their containerized infrastructure and respond effectively to potential security incidents.

Reference:

Pentester academy

Attack-Defense Online Lab

Docker Security

Docker Security — OWASP Cheat Sheet Series