Shulou(Shulou.com)05/31 Report--

How to build a Drupal Core RCE loophole honeypot, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

The Webhoneypot framework is written in Python 3 and requires docker and docker-compose to run. You can use JSON and the corresponding docker-compose file to configure the honeypot. The docker-compose file describes the container used for the honeypot and its settings, while the JSON file is used to configure how the framework detects attacks and takes snapshots of the honeypot.

The basic structure of the JSON configuration is as follows:

{"docker_compose_file": ". / docker-compose.yml", "pre_start": "...", "post_start": "...", "snapshot_path": ". / snapshots", "snapshots": [...], "detections": [...]}

The options for docker_compose_file are very simple. With the options pre_start and post_start, the user can execute the script before startup after starting the honeypot. I usually use it to adjust file permissions and file ownership in the Web root directory.

The main function of the framework is to create a snapshot of the honeypot after an attack is detected. Currently, you can create snapshots of directories or MySQL databases.

To take a MySQL snapshot, add the mysql_snapshot option under the snapshot. This will create an MySQL dump (https://hub.docker.com/_/mysql) of a standard MySQL container:

{"type": "mysql_snapshot", "mysql_container_name": "webhoneypot_mysql_1", "mysql_user": "root", "mysql_password": "Password123!", "mysql_restore_path": ". / mysql/config"}

The MySQL container from the docker library allows you to restore database dumps by placing files in the container's / docker-entrypoint-initdb.d folder. So the mysql_restore_path option should point to the mount point of the directory.

Another option is to use folder_snapshot to create a directory snapshot:

{"type": "folder_snapshot", "folder_path": ". / apache/html"}

This creates a ZIP archive of the specified folder and places it in the configured snapshot folder.

To detect attacks, the webhoneypot framework currently supports only folder_changed and file_contains.

The detection method folder_changed can detect any file changes compared to the initial snapshot:

{"type": "folder_changed", "folder_path": ". / apache/html", "ignore_files": ["folder_to_ignore/"]}

The folder_path option must match the option specified in the folder_snapshot block. To reduce interference, some files or folders can be ignored.

The second detection method, file_contains, detects whether the specified file contains a specific string or regular expression:

{"type": "file_contains", "file_path": ". / nginx/logs/access.log", "pattern": "pattern to search"}

To run the script, simply clone the repository and run webhoneypot.py:

$git clone https://gitlab.com/SecurityBender/webhoneypot-framework.git & & cd webhoneypot-framework$. / webhoneypot.py-h usage: webhoneypot.py [- h]-c CONFIG optionManagement script for docker-based web application honeypotspositional arguments: option the honeypot option Can be [start | stop | init | update | reset] optional arguments:-h,-help show this help message and exit-c CONFIG,-- config CONFIG the honeypot configuration file

The script mainly supports the following five options:

Start: start the honeypot container

Stop: stop the honeypot container

Init: initialize the honeypot (for example, first time setup) and create an initial snapshot

Update: update the honeypot and create a new initial snapshot

Reset: snapshot honeypot to detect changes and restore the initial snapshot

Capture CVE-2019-6340 in the wild

With the above foundation, we can now build and configure Drupal honeypots to try to capture CVE-2019-6340 in the wild. CVE-2019-6340 is a RCE vulnerability in Drupal core that allows an attacker to execute arbitrary commands on the host system.

Configure the honeypot

I have made a configuration for building Drupalgeddon2 honeypots. You can find it on GitLab. Let's clone it and prepare for CVE-2019-6340.

$git clone https://gitlab.com/SecurityBender/webhoneypot-drupal.git$ cd webhoneypot-drupal

We have multiple directories and files in the directory:

Webhoneypot-drupal/ ├── apache/ │ └── Dockerfile ├── nginx/ │ ├── config/ │ │ └── default.conf │ └── Dockerfile ├── docker-compose.yml ├── drupal.json └── drupal.sh

The apache and nginx directories contain data and configuration files for Apache and nginx containers, respectively. The most important files are docker-compose.yml and drupal.json.

Docker-compose.yml contains all the information to start the necessary containers:

Version: '2'services: apache: build: apache/ volumes: -. / apache/html:/var/www/html -. / apache/tmp:/tmp networks:-webhoneypot nginx: build: nginx/ volumes: -. / nginx/config/default.conf:/etc/nginx/conf.d/default.conf:ro -. / nginx/logs:/var/log/nginx ports: -"80:80" networks:-webhoneypot depends_on:-apachenetworks: webhoneypot: driver: bridge

In this setup, we have an Apache container that hosts and runs Drupal and a nginx used as a reverse proxy. We mount the html and tmp directories to the Apache container to access them from the host and let us take snapshots and restore them. For the same purpose, we also mounted the log directory to the nginx container.

The main configuration is done in drupal.json:

{"docker_compose_file": ". / docker-compose.yml", "pre_start": "," post_start ":". / drupal.sh "," snapshot_path ":". / snapshots "," snapshots ": [{" type ":" folder_snapshot "," folder_path ":". / apache/html "} {"type": "folder_snapshot", "folder_path": ". / apache/tmp"}, {"type": "folder_snapshot", "folder_path": ". / nginx/logs"}], "detections": [{"type": "folder_changed" "folder_path": ". / apache/html", "ignore_files": ["sites/default/files/php/twig/"]}, {"type": "folder_changed", "folder_path": ". / apache/tmp" "ignore_files": []}, {"type": "file_contains", "file_path": ". / nginx/logs/access.log", "pattern": "node/1\\? _ format=hal_json"}]}

First, we use docker_compose_file to specify the file used to create, start, and stop the docker container through docker-compose. Each time the container is started, a drupal.sh is executed to adjust the owner and permissions of the. / apache/html (Web root) directory and clear the nginx access log. In addition, we configured the honeypot to take snapshots of the. / apache/html,./apache/tmp and. / nginx/logs directories after each reset. I noticed that a lot of drupalgeddon2 took advantage of the drop file in / tmp, so I added it.

The most important thing is the detection part. You may see that we want to detect changes in the. / apache/html and. / apache/tmp directories. All files different from the initial snapshot were detected. Because Drupal stores some of the generated files in sites/default/files/php/twig/, we ignore any changes to that directory. Another option for detection is to check whether the file contains a specific regular expression. In this case, we monitor the typical CVE-2019-6340 url in the nginx access log.

Run the honeypot

After configuring the honeypot, let's get the vulnerable Drupal version (for example, 8.6.9) and extract it to the. / apache/html directory:

$wget-Q https://ftp.drupal.org/files/projects/drupal-8.6.9.zip$ unzip drupal-8.6.9.zip-d. / apache/$ mv. / apache/drupal-8.6.9. / apache/html

Now let's clone the Webhoneypot framework and initialize the Drupal honeypot. Initialize the script with. / webhoneypot.py-c.. / webhoneypot-drupal/drupal.json init, which will launch and build the required containers.

$. / webhoneypot.py-c.. / webhoneypot-drupal/drupal.json init2019-04-07 15 Starting docker compose 11 DEBUG-Starting docker compose / opt/webhoneypot-drupal/docker-compose.yml... Creating network "webhoneypot-drupal_webhoneypot" with driver "bridge" Building apache [...] Building nginx [...] Creating webhoneypot-drupal_apache_1. DoneCreating webhoneypot-drupal_nginx_1... DonePress any key if honeypot setup is finished

When the initial startup is successful, we can access the Drupal instance through the public IP address. Configuration (enabling RESTful services, etc.)-harder than I thought-when we're done, we press enter, and the script starts creating an initial snapshot of the honeypot.

2019-04-07 15 initial 23Create folder backup of 23604-DEBUG-Creating snapshot "initial"... 2019-04-07 15 purge 2323621-DEBUG-Create folder backup of "/ opt/webhoneypot-drupal/apache/html" to "/ opt/webhoneypot-drupal/snapshots/initial/_opt_webhoneypot-drupal_apache_html.zip"... 2019-04-07 15 purge 2314775-DEBUG-Create folder backup of "/ opt/webhoneypot-drupal/apache/tmp" to "/ opt/webhoneypot-drupal/snapshots / initial/_opt_webhoneypot-drupal_apache_tmp.zip "... 2019-04-07 15 Create folder backup of 23 purl 48787-DEBUG-Create folder backup of" / opt/webhoneypot-drupal/nginx/logs "to" / opt/webhoneypot-drupal/snapshots/initial/_opt_webhoneypot-drupal_nginx_logs.zip "...

Test honeypot

Everything is working well, now let's test it. I got a POC from @ leonjza and ran it:

$python3 poc.py http:/// "id" CVE-2019-6340 Drupal 8 REST Services Unauthenticated RCE PoC by @ leonjzaReferences: https://www.drupal.org/sa-core-2019-003 https://www.ambionics.io/blog/drupal8-rce[warning] Caching heavily affects reliability of this exploit.Nodes are used as they are discovered, but once they are done You will have to wait for cache expiry.Targeting http://37.120.165.218/...[+] Finding a usable node id... [x] Node enum found a cached article at: 1, skipping [+] Using node_id 2 [+] Target appears to be www-data gid=33 (www-data) groups=33 (www-data)

POC was successfully executed. Now let's see if our tests are normal:

$. / webhoneypot.py-c.. / webhoneypot-drupal/drupal.json reset2019-04-07 17 DEBUG 04 Stopping docker compose 11767-DEBUG-Creating snapshot "20190407" 170411 ". [...] 2019-04-07 17415-DEBUG-Stopping docker compose / opt/docker/webhoneypot-drupal/docker-compose.yml... Stopping webhoneypot-drupal_nginx_1. DoneStopping webhoneypot-drupal_apache_1... DoneRemoving webhoneypot-drupal_nginx_1... DoneRemoving webhoneypot-drupal_apache_1... DoneRemoving network webhoneypot-drupal_webhoneypot2019-04-07 17 Pattern 05VOV 08442-INFO-Pattern "node/1\? _ format=hal_json" detected in fileholders 2019-04-07 17VO5VOV 08443-DEBUG-Restoring snapshot "initial"... [...]

This is a real-world Drupal honeypot used to detect CVE-2019-6340 attacks.

Warning

A compromised honeypot can be used for many other illegal purposes (such as cryptocurrency mining, sending spam, DoS, etc.). I strongly recommend that you set up a regular cronjob (every 15 to 30 minutes) to reset the honeypot. In addition, you can also block certain outgoing connections by limiting the CPU time of the container, or through the host firewall.

After reading the above, do you know how to build a honeypot with Drupal Core RCE vulnerabilities? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.