When new exploit to popular CMS's vulnerability appears, same day someone will send it all around the web, trying to compromise vulnerable systems. It is very interesting to watch how original PoC evolves into ready-to-use exploit, when attack first time met and what payloads were used.
Attack process can be roughly separated into two parts:
- Fingerprint the application
- Send exploit with expected result (e.g. execute command on server, upload web-shell etc.)
Some tools may skip first part and go directly to exploit phase, but in general they check at least CMS type, maybe version or maybe even ensure that it is a vulnerable version before sending any exploits.
If we are curious enough and want to monitor such attack attempts there are two approaches listed below:
- Deploy all kind of applications:
For each CMS we should deploy separate full-working application, database (if required), install all the dependencies etc. It is rather easy to deploy multiple applications with docker or similar solution, but the main disadvantages are: CMS will have real exploitable vulnerabilities, it would be necessary to re-install/upgrade application to change its version. However all the checks would pass and any tool will consider this CMS as valid. - Deploy Honeypot:
We deploy one system that will emulate multiple applications behavior. In this case exploits won't work, since there is no vulnerabilities related to particular application, but some tools may consider CMS as not valid, if emulation is not complete.
We will deploy Wordpress and Drupal honeypots for existing application using openresty (nginx modification with pre-compiled lua-modules) on Ubuntu 16.04.
Install Openresty
When OS is installed you can follow any of guides to install openresty provided with official website. In our case we will install pre-build packages for Ubuntu:
wget -qO - https://openresty.org/package/pubkey.gpg | sudo apt-key add -
sudo apt-get -y install software-properties-common
sudo add-apt-repository -y "deb http://openresty.org/package/ubuntu $(lsb_release -sc) main"
sudo apt-get update
sudo apt-get install openresty
Now we should be able to get Openresty welcome page, when request localhost via http (80 port).
For CMS detection I used wpscan and droopescan to get Wordpress and Drupal versions. The current results example is listed below and no version was detected:
# wpscan 172.16.9.0
[!] The remote website is up, but does not seem to be running WordPress.
# ./droopescan scan drupal -u http://172.16.9.0
[+] Expected folder returned status '404', expected file returned not found status.
[+] It is possible that http://172.16.9.0/ is not running drupal. If you disagree, please specify a --method.
Install honeybot
At first we need install and upgrade luarocks to be able to get lua-packages:
sudo apt-get install luarocks git-core
luarocks install luarocks
Next step - install wtf (Web Tailoring Framework). It allows us to include different lua-modules in request processing, in our case: two modules related to fake wordpress and drupal applications emulation.
luarocks install wtf
luarocks install wtf-plugin-honeybot-fake-drupal
luarocks install wtf-plugin-honeybot-fake-wordpress
Note: if you see errors during install, it would be necessary to log-out/log-in as current user, since new luarocks missing some dependencies in current PATH
Configure
Before changing any configuration let's clone demo policy in /etc/openresty folder:
cd /etc/openresty
git clone https://github.com/honeybot/wtf-demo-policy
Now we need to edit /etc/openresty/wtf-demo-policy/policy/demo.json to make it look like this:
{
"name": "demo",
"version": "0.1",
"storages": { },
"plugins": {
"honeybot.fake.wordpress": [{
"version": "3.9.2",
"path": "/usr/local/share/wtf/data/honeybot/fake/wordpress/"
}],
"honeybot.fake.drupal": [{
"version": "7.55",
"path": "/usr/local/share/wtf/data/honeybot/fake/drupal/"
}]
},
"actions": {},
"solvers": {}
}
Here you can specify CMS versions to emulate and name of policy that we will specify on next step in nginx configuration.
Add the line include wtf-demo-policy/nginx/bootstrap.conf; in http section and lines set $wtf_policies "demo"; include wtf-demo-policy/nginx/policy/proxy.conf; in location section of /etc/openresty/nginx.conf to make config look like this:
...
http {
...
include wtf-demo-policy/nginx/bootstrap.conf;
server {
...
location / {
set $wtf_policies "demo";
include wtf-demo-policy/nginx/policy/proxy.conf;
root html;
index index.html index.htm;
}
...
}
Restart openresty service:
systemctl restart openresty
Now application should work as honeypot with current application (welcome page). You can change it to any other application (e.g. add proxy_pass nginx directive to proxy requests to some other website or different local port). Also you can use separate lua module to store requests data in different databases, or change access_log nginx directive settings to store additional fields in access.log.
Verification
Lua packages add some tags related to CMS and send same static content that is relevant to particular Wordpress/Drupal versions set in policy configuration. This way most of scanners believe that they deal with real CMS and will try to send attack samples, perform bruteforce etc.
Now wpscan and droopscan detect our empty website as both Wordpress and Drupal application:
# wpscan 172.16.9.0
[+] URL: http://172.16.9.0/
[+] Started: Mon May 28 15:22:29 2018
...
[+] WordPress version 3.9.2 (Released on 2014-08-06) identified from advanced fingerprinting, meta generator, readme, links opml
[!] 55 vulnerabilities identified from the version number
[!] Title: WordPress 3.4.2 - 3.9.2 Does Not Invalidate Sessions Upon Logout
Reference: https://wpvulndb.com/vulnerabilities/7531
Reference: http://whiteoaksecurity.com/blog/2012/12/17/cve-2012-5868-wordpress-342-sessions-not-terminated-upon-explicit-user-logout
Reference: http://blog.spiderlabs.com/2014/09/leveraging-lfi-to-get-full-compromise-on-wordpress-sites.html
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5868
[i] Fixed in: 4.0
...
[!] Title: WordPress 3.7-4.9.4 - Escape Version in Generator Tag
Reference: https://wpvulndb.com/vulnerabilities/9055
Reference: https://wordpress.org/news/2018/04/wordpress-4-9-5-security-and-maintenance-release/
Reference: https://github.com/WordPress/WordPress/commit/31a4369366d6b8ce30045d4c838de2412c77850d
Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10102
[i] Fixed in: 3.9.24
[+] WordPress theme in use: twentyfourteen
[+] Name: twentyfourteen
| Latest version: 2.2
| Last updated: 2018-05-17T00:00:00.000Z
| Location: http://172.16.9.0/wp-content/themes/twentyfourteen/
| Style URL: http://172.16.9.0/wp-content/themes/twentyfourteen/style.css
| Referenced style.css: wp-content/themes/twentyfourteen/
/wp-content/plugins/theme-my-login/style.css
[+] Enumerating plugins from passive detection ...
[+] No plugins found
[+] Finished: Mon May 28 15:22:32 2018
[+] Requests Done: 49
[+] Memory used: 59.785 MB
[+] Elapsed time: 00:00:03
# ./droopescan scan drupal -u http://172.16.9.0
[+] No themes found.
[+] Possible interesting urls found:
Default changelog file - http://172.16.9.0/CHANGELOG.txt
[+] Possible version(s):
7.55
[+] No plugins found.
[+] Scan finished (0:01:03.745753 elapsed