Building highly interactive honeypots: CVE-2021-41773 case study

Every day, as we drink our coffee in the office, new vulnerabilities pop out, some of which are highly critical and need quick reactions. Exploiting some of these vulnerabilities is a cinch, like the one found in Apache HTTPD “CVE-2021-41773”, which is why they attract many attackers. In such situations, a precise solution is required to get information around the attack as quickly as possible. The gathered information can be used for different goals, for example, to assist security engineers in knowing the attack patterns to defend themselves against it, or maybe for security researchers to gather intel and knowledge as much as possible; therefore, they can share it publicly. One of those solutions is a honeypot. Essentially, a honeypot acts as a decoy-based intrusion detection system to help us detect attacks and their patterns, and defend ourselves against them. This post (or maybe a series of posts) will discuss how to build a highly interactive honeypot for a vulnerability immediately and analyze the generated logs after successful or unsuccessful attacks.

The approach

While numerous honeypot applications are available for free (like dionaea and cowire), these programs attempt to emulate a service and present the attacker with a fake service. Honeypots of this type are effective against autonomic attacks, but they fail to detect manual attacks or attacks with more than one stage. In addition, there are several techniques an attacker can use to uncover a honeypot.

The aforementioned approach has some shortcomings such as limited emulation on specific services and challenging customization. About customization, researchers find it a time-consuming task where in some specific scenarios, they cannot get the advantage of customizatoin. Moreover, it is good to point out that there is no honeypot for dozens of services.

To overcome these hardships, rather than trying to emulate every possible aspect of the faked system, we can grant access to a real system as it is easy, so the attacker has no way of knowing whether they are logged on to a honeypot or not. Securing a real system is not easy; however, it can be done using virtualization or containerization.

The honeypot is a vulnerable Docker container affected by the CVE-2021-41773. Instances of Filebeat and Auditbeat will collect the logs, and Elasticsearch will colorate them for us. Finally, Kibana can provide a visualized dashboard.

Vuleranble container

A path traversal vulnerability and exploit just dropped in the wild for a specific version of Apache (Apache/2.4.49). This vulnerability allows an unauthenticated attacker to execute a path traversal attack (and now shown RCE if MOD_CGI is enabled) to read files outside the virtual directory path bounds. .

To build a vulnerable container for these types of vulnerabilities, we need the source code of that specific vulnerable version. Luckily, there is a mirror of Apache HTTPD at here!. After downloading the source code, we compile the vulnerable version and build a docker image we can deploy quickly.

The assumption is you know how to install and use Docker; if you’re not familiar, please take a look at This Article!.

Let’s take a look at the content of the Dockerfile:

FROM ubuntu:20.04

MAINTAINER lopqto <[email protected]>

Install the required packages

RUN apt-get update && apt-get install -y
build-essential zlibc libapr1-dev
libaprutil1-dev libpcre3-dev zlib1g zlib1g-dev wget
subversion python3 autoconf libtool-bin

WORKDIR /honeypot

Download the vulnerable version

RUN wget https://github.com/apache/httpd/archive/refs/tags/2.4.49.tar.gz
&& tar -xvf 2.4.49.tar.gz

WORKDIR /honeypot/httpd-2.4.49/

Compile the vulenrable version

RUN svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr
&& ./buildconf
&& ./configure --prefix=/usr/local/apache2
–enable-mods-shared=all --enable-deflate --enable-proxy
–enable-proxy-balancer --enable-proxy-http
&& make && make install

RUN mkdir -p /var/www/html && mkdir /var/log/apache2/

Update the required permissions for www-data

RUN chown -hR www-data:www-data /var/www/html
&& chown -hR www-data:www-data /var/log/apache2/
&& chown -hR www-data:www-data /usr/local/apache2/logs/

USER www-data

WORKDIR /var/www/html

Run apache in foreground mode

ENTRYPOINT ["/usr/local/apache2/bin/apachectl", “-D”, “FOREGROUND”]

To build the vulnerable image:

docker build . -t honeypot:latest

Test the vulnerable container

The vulnerability requires specific permissions to be configured. Grab the default httpd.conf file and append these lines end of it:

<VirtualHost *:8080>
	DocumentRoot /var/www/html
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined

&lt;Directory /&gt;
	Require all granted
&lt;/Directory&gt;

</VirtualHost>

Then try to run the vulnerable container with the new config file:

docker run -p 80:8080 \
    -v $(pwd)/httpd.conf:/usr/local/apache2/conf/httpd.conf \
    apache:latest

Test the vulnerability by running:

curl http://localhost/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'echo;whoami'

You should see www-data in output.

Logging

The Elasticsearch ELK stack (Elasticsearch, Logstash, and Kibana) is an ideal solution for search and analytics platforms on honeypot logs.

There are various how-to’s describing how to get ELK running (see here and here for example), so I assume you already have a working ELK system.

HTTP requests logs

A logger with these advantages is needed:

  • No need to modify the container’s configuration
  • Prevent attackers from disabling the logger within the container

By default, Apache stores the access logs inside /var/log/apache2/access.log and error logs inside /var/log/apache2/error.log. We need to export these logs from the container and store them inside an ElasticSearch instance. To do this, we will use Filebeat:

Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.

The main configuration file will look like this:

filebeat.config:
  modules:
    path: ${path.config}/modules.d/*.yml
    reload.enabled: false

output.elasticsearch:
hosts: ["${ELASTICSEARCH_HOST}:9200"]
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}

setup.dashboards:
enabled: true

setup.kibana:
host: “${KIBANA_HOST}:5601”
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}

And for the apache.yml we have:

- module: apache
  access:
    enabled: true
    var.paths: ["/log/access.log"]
  error:
    enabled: true
    var.paths: ["/log/error.log"]

Another option for this problem is to configure the containers to forward their Syslog data to the host, but this can be disabled if the attacker has root access, so it is not ideal.

Executaion logs

Docker runs on the same kernel as the host machine, so we can use kernel-level logging to see what is happening inside the container. An off-the-shelf solution is to use a Linux audit system and configure it to log execve and execveat system calls.

The Linux Audit system provides a way to track security-relevant information on your system. Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible.

The sad news is Linux audit system does not support kernel namespaces, so logs cannot be filtered for specific containers and the host machine. To make things easier, we defined a custom user inside the Dockerfile named www-data to filter out the related logs by this user.

USER www-data

To log the execution actions, we will use Auditbeat:

Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

The Auditbeat configuration file will look like this:

auditbeat.modules:
  • module: auditd
    audit_rules: |
    -a always,exit -F arch=b64 -S execve,execveat -k exec

output.elasticsearch:
hosts: ["${ELASTICSEARCH_HOST}:9200"]
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}

setup.dashboards:
enabled: true

setup.kibana:
host: “${KIBANA_HOST}:5601”
username: ${ELASTICSEARCH_USERNAME}
password: ${ELASTICSEARCH_PASSWORD}

Putting it all together

At this point, we have an ELK stack set up and running, Kibana dashboards ready to visualize the logs, a vulnerable container prepared to be exposed on the internet, a Filebeat instance ready to capture HTTP logs, and an Auditbeat instance to capture executed commands.

We can create a simple docker-compose.yml file to deploy the honeypot as fast as possible and make things much more manageable. To install the docker-compose, take a look at here!.

Content of the docker-compose.yml will be something like this:

version: "3.8"
services:
  honeypot:
    build: ./
    hostname: "honeypot"
    networks:
      - honeypot
    ports:
      - "80:8080"
    volumes:
      - logs:/var/log/apache2/
      - $PWD/httpd.conf:/usr/local/apache2/conf/httpd.conf

auditbeat:
image: docker.elastic.co/beats/auditbeat:7.15.0
hostname: “auditbeat”
user: root
pid: host
cap_add:
- AUDIT_CONTROL
- AUDIT_READ
networks:
- honeypot
volumes:
- auditbeat:/usr/share/auditbeat/data
- $PWD/auditbeat.yml:/usr/share/auditbeat/auditbeat.yml:ro
environment:
- ELASTICSEARCH_HOST=elk.host # Change
- KIBANA_HOST=kibana.host # Change
- ELASTICSEARCH_USERNAME=elastic # Change
- ELASTICSEARCH_PASSWORD=changeme # Change
command: ["–strict.perms=false"]
depends_on:
- honeypot

filebeat:
image: docker.elastic.co/beats/filebeat:7.15.0
hostname: “filebeat”
user: root
networks:
- honeypot
volumes:
- filebeat:/usr/share/filebeat/data
- $PWD/filebeat.yml:/usr/share/filebeat/filebeat.yml
- $PWD/apache.yml:/usr/share/filebeat/modules.d/apache.yml
- logs:/log/:ro
environment:
- ELASTICSEARCH_HOST=elk.host # Change
- KIBANA_HOST=kibana.host # Change
- ELASTICSEARCH_USERNAME=elastic # Change
- ELASTICSEARCH_PASSWORD=changeme # Change
command: ["–strict.perms=false"]
depends_on:
- honeypot

networks:
honeypot:

volumes:
auditbeat:
filebeat:
logs:

To bring up the honeypot stack, run the following command:

docker-compose up -d

That’s it :). Now, we can trace the logs with the help of Kibana and some beautiful dashboards.

Auditbeat executions Dashboard:

Filebeat Apache access and error logs dashboard:

Conclusion

We can build interactive honeypots for a variety of vulnerabilities in such a short period of time using containers. The ELK stack additionally provides us with some tools to gather valuable logs, manage records easier, and visualize them for better understanding. Spending time and effort, researchers can build honeypots to trace active threats and threat actors, such as miners, and share attack knowledge with other researchers. The information can be used to create threat feeds with a low likelihood of false positives. Additionally, engineers can use honeypots as a decoy system inside of an organization.

The project has been shared on Github. You can use it as a starting point. I hope you find it useful.

You’re more than welcome to share your thoughts and ideas. Feel free to ping me if you have questions about this topic.

Enjoy!

Read more

Article Link: Building highly interactive honeypots: CVE-2021-41773 case study « lopqto's adventures