Overview

Containers transformed the way enterprise applications get deployed. All the applications run on these lightweight images that hold the application code and its dependencies.  Containers bring efficiency and portability to applications. However, applications built using Docker Containers face security challenges. A single compromised container is a risk to the entire structure.  In this document, we discuss a detailed case study on how the container vulnerabilities are assessed and fixes are applied.

Container Security & Docker Security Case Study

Tech Vedika helped one of its customers in addressing a major container security vulnerability that allowed the docker containers to be compromised by allowing unknown, external users to use its cloud services for crypto mining.

Tech Vedika promptly identified the root cause during security scanning and fixed the vulnerabilities in a quick time. Tech Vedika team performed security analysis using container vulnerability tools for identifying areas that need remediation.

Container Security Assessment & Remediation

Static Code Analysis

  • Code-level security analysis was conducted using SonarQube
  • No issues were found.

Container Vulnerability Analysis

  • Containers and dockers were scanned for vulnerabilities using the Trivy tool.
  • The tool was executed in the dev environment and vulnerabilities were identified. The following table shows the critical and high vulnerabilities reported.
    LibraryVulnerability IDSeverityInstalled VersionFixed VersionDescription
    busyboxCVE-2022-28391CRITICAL1.34.1-r31.34.1-r5

    CVE-2022-28391 affecting

    package busybox 1.35.0

    –>avd.aquasec.com/nvd/cve-2022-28391

    libcrypto1.1CVE-2022-0778HIGH1.1.1l-r71.1.1n-r01.1.1n-r0

    openssl: Infinite loop in BN_mod_sqrt() reachable when parsing certificates

    –>avd.aquasec.com/nvd/cve-2022-0778

    libretls3.3.4-r23.3.4-r3
    libssl1.11.1.1l-r71.1.1n-r0
    libxml2CVE-2022-233082.9.12-r22.9.13-r0

    libxml2: Use-after-free of ID and IDREF attributes

    –>avd.aquasec.com/nvd/cve-2022-23308

    libxsltCVE-2021-305601.1.34-r11.1.35-r0

    Use after free in Blink XSLT in Google Chrome before 91.0.4472.164..

    –>avd.aquasec.com/nvd/cve-2021-30560

    ssl_clientCVE-2022-28391CRITICAL1.34.1-r31.34.1-r5

    CVE-2022-28391 affecting

    package busybox 1.35.0

    –>avd.aquasec.com/nvd/cve-2022-28391

    xz-libsCVE-2022-1271HIGH5.2.5-r05.2.5-r1

    gzip: arbitrary-file-write vulnerability

    –>avd.aquasec.com/nvd/cve-2022-1271

    zlibCVE-2018-250321.2.11-r31.2.12-r0zlib: A flaw found in zlib v1.2.2.2 through zlib v1.2.11 when compressing… –>avd.aquasec.com/nvd/cve-2018-25032
  • We took a replica of the gateway images and fixed those vulnerabilities.
  • After applying the fixes and upgrading the packages, the Docker image was created and tested again by re-running the container and running a vulnerability check.
  • When no vulnerabilities are found, the updates were deployed in production

Firewall Security

  • We found inadequate security measures at the Firewall which led to 3rd party malicious attacks.
  • OLS (OpenLiteSpeed) with ModSecurity WAF engine was installed and configured to enable security at the application firewall level
  • The following steps were followed to  configure Modsecurity WAF engine using OLS. The steps followed are:
    • Add App: Add an app in the virtual host in the external app section of the dashboard.
      Docker & Container Level Security Assessment & Compliance
    • Create proxy
      Docker & Container Level Security Assessment & Compliance
    • Enable Module in Virtual Host Modules Section
      Docker & Container Level Security Assessment & Compliance
    • Enable ModSecurity & Audit Logs: In the module parameter section of Virtual Host, the following commands were added to enable ModSecurity, ModSecurity rules and audit log.

      modsecurity on
      modsecurity_rules
      SecRuleEngine On
      SecDebugLog /tmp/app-auditlog-debug.txt
      SecDebugLogLevel 7
      SecAuditLogParts AB
      SecAuditEngine On
      SecAuditLog /tmp/app-auditlog.txt
      SecAuditLogType Serial
      SecAuditLogStorageDir /tmp/

      modsecurity_rules_file /usr/local/lsws/conf/owasp/modsec_includes.conf

Docker & Container Level Security Assessment & Compliance
Container Security Assessment Tools

Following are the container security tools used by Tech Vedika:

  1. SonarQube: SonarQube is an open-source, third-party platform for continuous analysis and inspection of code. This container security tool provides a detailed report of bugs, code vulnerabilities, code duplication, and other points to help maintain a clean, simple, and easy code for a longer lifetime of the project.
  2. Trivy: This is a straightforward and all-inclusive third-party tool that scans containers and artifacts for any vulnerability/ misconfiguration/ secret. It scans Infrastructure as Code (IaC) files and also exposes the vulnerabilities of Operating systems and language packages. It can also detect the probable configuration issues that are risky for the AWS workload. Trivy also scans hardcoded secrets like passwords, API keys, and tokens.
  3. ModSecurity WAF Engine: ModSecurity is an open-source Web Application Firewall (WAF) compatible across platforms. OWASP ModSecurity Core Rule Set (CRS) is a set of rules written in ModSecurity’s SecRules language to protect the application from general classes of vulnerabilities. This container security tool works in the background and scans all requests to the web server and related responses from the server. This process filters all malicious requests.
Common Container Vulnerabilities

The following are the common container-level vulnerabilities:

  1. Access Control Exploits: Neglecting the fundamental authentication and authorization to Docker exposes the entire system and makes it vulnerable to unauthorized access. The consoles should be configured using password policies to keep the AWS system secure.
  2. Isolation Flaws: The Isolation of containers makes them robust from a security standpoint. However, isolation alone does not guarantee container security, the containers should be secure by themselves. In case there is a compromised container, network segmentation prevents hackers from reaching the other containers.
  3. Untrusted Containers: Containers are portable and easy to use. It often happens that the hackers upload malware containers to public repositories. Hence, container security should be assessed beforehand. 
  4. Insecure Configuration of other components: The containers, the host Operating System, and the AWS accounts should be configured with the least privileges to secure the entire system. Docker commands should also be secured with passwords.
  5. Secret Management: Sensitive credentials, API keys, and tokens at every level should be equally protected. Hard coding and rotating credentials could be an expensive affair. Weak cryptography key generation, authentication, and incorrect use of cookies exploit the application.
  6. Container Image Vulnerabilities: The use of vulnerable container images leads to several security issues. It allows the malware to be installed and infect the community docker images.
Docker Security Best Practices

We recommend the following best practices for ensuring Docker Security:

  • Keep host machine and docker updated to the latest patch
  • Do not expose the docker daemon socket
  • Create users other than admin and root and give them permissions for different roles.
  • To prevent privileges escalation, never allow any privileges to the docker container
  • Disable inter-container communication (-icc=false)
  • Always use Linux Security Modules
  • Filesystem and volume should be in Read-Only format

Leave a Reply

Your email address will not be published. Required fields are marked *