WordCamp London 2019 - CLI Tools and Shells26 Apr 2019 · Comments: 0 · Tags: WordCamp, WordPress, PHP, WPScan, wpxf, sqlmap, nghttp, PsySH, 3v4l.org, WP-CLI, PowerShell
- CLI Tools and Shells
- Further Reading
WordCamp London (WCLDN) was held at the London Metropolitan University on 5th - 7th April 2019. The first day was to promote contributing to the WordPress project, followed by a two day conference. I attended both days of the conference.
The conference was comprised of three tracks which ran in parallel, each with talks lasting approximately 40 mins. I went to several talks over the two days and was very impressed with the quality of content and how well organised the event was.
I thought it would be interesting to take a look at some of the command line tools and shells that were referenced in the talks that I attended. This is not intended to be a deep dive but rather a brief summary of each tool/shell based on what I learnt at the conference and any hands-on experience I’ve gained since then.
CLI Tools and Shells
WPScan and WordPress Exploit Framework (wpxf)
WPScan is written in Ruby, it attempts to discover things such as the WordPress version and details of any installed plugins and themes. WordPress Exploit Framework is also written in Ruby, it is a framework for demonstrating exploits of known vulnerabilities, the purpose of which is to assist with penetration testing. Neither tool has to be run from the server on which a target WordPress site resides, they can both be run from anywhere.
I wanted to use both tools in conjunction to achieve the following workflow:
- Use WPScan to detect vulnerabilities in plugins.
- Search WordPress Exploit Framework for modules capable of exploiting the vulnerabilities discovered with WPScan.
- Use WordPress Exploit Framework to exploit the vulnerabilities where modules exist to do so.
NB: I never actually got to try step three because I didn’t have a WordPress site available to me with a vulnerability that was exploitable by the WordPress Exploit Framework. I’d like to explore the WordPress Exploit Framework in more depth in the future, what I really need is a sandboxed environment with an old version of WordPress installed and/or some old plugins.
These are just a few notes detailing how I went about achieving step two of the workflow…
The maintainers of WPScan (The WPScan Team) catalogue vulnerabilities found in WordPress core, plugins and themes in the WPScan Vulnerability Database. Each vulnerability recorded in the database has a unique ID. The default console output produced by WPScan includes the vulnerability name as recorded in the database but not the ID, however there is an option to output in JSON format which includes both the name and ID.
My plan was to extract the ID from WPScan for each vulnerability found and use this to search the WordPress Exploit Framework for modules capable of exploiting the vulnerability. I used PowerShell Core (6.2.0) to parse the JSON output. In the following example only one plugin was found to be susceptible to a vulnerability, PowerShell extracts the vulnerability ID, vulnerability name and the version of the plugin in which the vulnerability was addressed:
It was my hope that the WordPress Exploit Framework could be searched using the
WPScan Vulnerability Database ID but alas its search facility does
not support this (I’ve opened an issue).
However, there is another way… Behind the scenes each exploit module in the
WordPress Exploit Framework is a separate Ruby file. These usually (the project’s wiki, says it’s not a mandatory requirement) contain the relevant
WPScan Vulnerability Database ID (
WPVDB) within the
references section, EG:
The directory containing the exploit modules can be searched using a combination
sed. In order to do this, you must first obtain the installation
directory of the WordPress Exploit Framework. If you used the
gem package manager
to perform the installation then this can be achieved as follows:
Once in possession of the installation directory, you can search it for modules containing a
specific WPScan Vulnerability Database ID. The following example demonstrates a
search for modules containing ID 7652,
a single result is returned in the form of the module name
Creative Contact Form Shell Upload:
(NB: In my case the WordPress Exploit Framework directory was
/var/lib/gems/2.5.0/gems/wpxf-2.0.1, so that’s what
I’ve used in the example.)
sqlmap is a penetration tool intended to detect and exploit SQL injection flaws.
I installed sqlmap by cloning the project’s dev branch on Github (as per the instructions on the project’s website). I was somewhat surprised that the script failed to execute under Python 3:
I did a quick search of the project’s Github repo expecting to find a Python 2 to Python 3 roadmap (Python 2’s End Of Life date is 2020-01-01) but instead I found this which suggests that there is no intention to provide support for Python 3. Anyway, I digress, the bottom line is you need to use Python 2.
After dabbling with sqlmap for a bit it became apparent that in order to gain familiarity with it I really needed a sandboxed site with known SQL injection vulnerabilities… I found two such candidates, bWAPP (buggy web application) and WebGoat which appears to be more actively maintained. Time permitting I’d like to return to sqlmap at a later date and try it against one of the aforementioned frameworks.
nghttp is an HTTP/2 command-line client, it is part of the nghttp2 suite of tools which is produced by the nghttp2.org project.
During Tom J Nowell’s talk entitled
HTTP/2 Push for the Stars,
he explained how the HTTP/2 Server Push technique can be used to send website
assets to the user without waiting for the browser to request them. He went on
to discuss a couple of ways in which HTTP/2 Server Push can be tested, one of which
nghttp. The output of
nghttp lists all requested resources and
indicates which of those were pushed using an asterisk, he used his own website
as an example:
NB: The argument in the command above
-ans is an amalgamation of three short
-s. See the man page for an explanation of each (
When working with HTTP/2 you may encounter the abbreviations
h2 is HTTP/2 over TLS and
h2c is HTTP/2 over cleartext TCP. These are
identifiers as specified in the protocol’s RFC.
Browsers typically only support
Firefox Web Developer Tools - Console
Although I’d used Firefox’s Web Developer tools (
F12) many times, I’d never
PHP Interactive Shell
PHP ships with an interactive shell
which is accessed using the
-a parameter, EG:
This enables you to type PHP code, execute it and output the result, well, kind of…
It doesn’t actually output anything to the console unless you prefix your code
Furthermore, the more observant amongst you may have noticed that there’s no need to terminate each line with a semicolon.
3v4l.org - Online PHP Shell
3v4l.org is an online PHP shell which enables you to execute
PHP code against any version of PHP released since 4.3.0. It also acts as a
pastebin, once you press the
eval(); button the browser’s address bar is
populated with a unique link. I couldn’t find anything on the About page to
indicate if these links were subject to a retention period (EG deleted after
days). I wrote to the author to ask if there was a retention period to which
he replied there is not.
There is also an interactive shell, which at the time of writing (April 2019) uses PHP 7.3.0. The interactive shell is currently labelled as ‘beta’, it was only released in December 2018.
WP-CLI is the official command line interface for WordPress.
It’s possible to perform a complete installation of WordPress from the command line with the assistance of WP-CLI. These are the basic steps only, if deploying a publicly accessible WordPress site then always follow current best practices and security hardening steps. Some of the commands below require user interaction, so this snippet is not intended to be used in a non-interactive fashion.
A few notes about the above…
It was my intention to handle password input so that is was not captured in clear text in either the bash history log (
or MySQL history log (
- MySQL is intelligent enough to avoid logging the password within the
CREATE USERstatement, here’s an excerpt from the MySQL online docs: “mysql ignores for logging purposes statements that match any pattern in the “ignore” list. By default, the pattern list is “*IDENTIFIED*:*PASSWORD*”, to ignore statements that refer to passwords.”
- There are a couple of WP-CLI commands that require a password. To prevent these from being written to the bash history log a
--promptargument is used.
The last thing I want to mention about WP-CLI is its interactive REPL PHP console:
As well as executing general PHP code, you can interact with the WordPress
environment. For example you can call global WordPress functions:
The table below lists the talks I attended which inspired this blog post, it includes links to the tools as well as to the respective speakers websites.
|Going To The Dark Side, They Have Cookies||Tim Nash||WPScan, WordPress Exploit Framework, sqlmap|
|HTTP/2 Push for the Stars||Tom J Nowell||nghttp|
|An Introduction to WP-CLI||Pascal Birchler||WP-CLI|
|I Tried Writing Some Code... You Won't Believe What Happened Next!||Ross Wintle||Firefox Web Developer Tools - Console, PHP Interactive Shell, PsySH, 3v4l.org, WP-CLI|