A Ruby framework for developing and using modules which aid in the penetration testing of WordPress powered websites and systems.
What do I need to run it?
Ensure that you have Ruby >= 2.4.2 installed on your system and then install all required dependencies by opening a command prompt / terminal in the WPXF folder and running bundle install
.
If bundler is not present on your system, you can install it by running gem install bundler
.
Troubleshooting Installation
Debian Systems
If you have issues installing WPXF’s dependencies (in particular, Nokogiri), first make sure you have all the tooling necessary to compile C extensions:
sudo apt-get install build-essential patch
It’s possible that you don’t have important development header files installed on your system. Here’s what you should do if you should find yourself in this situation:
sudo apt-get install ruby-dev zlib1g-dev liblzma-dev
Install requirements and run:
sudo gem install bundler
sudo bundle install
sudo ruby wpxf.rb
Windows Systems
If you are experiencing errors that indicate that libcurl.dll
could not be loaded, you will need to ensure the latest libcurl binary is included in your Ruby bin folder, or any other folder that is in your environment’s PATH variable.
The latest version can be downloaded from http://curl.haxx.se/download.html. As of 16/05/2016, the latest release is marked as Win32 2000/XP zip 7.40.0 libcurl SSL
. After downloading the archive, extract the contents of the bin directory into your Ruby bin directory (if prompted, don’t overwrite any existing DLLs).
How do I use it?
Open a command prompt / terminal in the directory that you have downloaded WordPress Exploit Framework to, and start it by running ruby wpxf.rb
.
Once loaded, you’ll be presented with the wpxf prompt, from here you can search for modules using the search
command or load a module using the use
command.
Loading a module into your environment will allow you to set options with the set
command and view information about the module using info
.
Below is an example of how one would load the symposium_shell_upload exploit module, set the module and payload options and run the exploit against the target.
wpxf > use exploit/symposium_shell_upload
[+] Loaded module: #<Wpxf::Exploit::SymposiumShellUpload:0x3916f20>
wpxf [exploit/symposium_shell_upload] > set host wp-sandbox
[+] Set host => wp-sandbox
wpxf [exploit/symposium_shell_upload] > set target_uri /wordpress/
[+] Set target_uri => /wordpress/
wpxf [exploit/symposium_shell_upload] > set payload exec
[+] Loaded payload: #<Wpxf::Payloads::Exec:0x434d078>
wpxf [exploit/symposium_shell_upload] > set cmd echo "Hello, world!"
[+] Set cmd => echo "Hello, world!"
wpxf [exploit/symposium_shell_upload] > run
[-] Preparing payload...
[-] Uploading the payload...
[-] Executing the payload...
[+] Result: Hello, world!
[+] Execution finished successfully
For a full list of supported commands, take a look at This Wiki Page.
What is the difference between auxiliary and exploit modules?
Auxiliary modules do not allow you to run payloads on the target machine, but instead allow you to extract information from the target, escalate privileges or provide denial of service functionality.
Exploit modules require you to specify a payload which subsequently gets executed on the target machine, allowing you to run arbitrary code to extract information from the machine, establish a remote shell or anything else that you want to do within the context of the web server.
What payloads are available?
- bind_php: uploads a script that will bind to a specific port and allow WPXF to establish a remote shell.
- custom: uploads and executes a custom PHP script.
- download_exec: downloads and runs a remote executable file.
- meterpreter_bind_tcp: a Meterpreter bind TCP payload generated using msfvenom.
- meterpreter_reverse_tcp: a Meterpreter reverse TCP payload generated using msfvenom.
- exec: runs a shell command on the remote server and returns the output to the WPXF session.
- reverse_tcp: uploads a script that will establish a reverse TCP shell.
All these payloads, with the exception of custom
and the Meterpreter payloads, will delete themselves after they have been executed, to avoid leaving them lying around on the target machine after use or in the event that they are being used to establish a shell which fails.
How can I write my own modules and payloads?
Guides on writing modules and payloads can be found on The Wiki and full documentation of the API can be found at http://www.getwpxf.com/.
Changelog:
- Fix API compatibility in Estatik 2.2.5 shell upload
- Upgrade required Ruby version to 2.4.2
- Upgrade Nokogiri to 1.8.1
- Upgrade rubyzip to 1.2.1
- Upgrade Slop to 4.5.0
- Upgrade Typhoeus to 1.3.0
- Upgrade RSpec to 3.7
- Add new mixin to provide comment posting functionality
- Add new mixin for creating hash dump auxiliary modules
- Add support for multiple potential upload locations in the ShellUpload mixin
- Add Responsive Image Gallery <= 1.2.0 hash dump
- Add SQL Shortcode <= 1.1 hash dump
- Add JTRT Responsive Tables <= 4.1 hash dump
- Add Simple Events Calendar <= 1.3.5 hash dump
- Add Pootle Button < 1.2 reflected XSS shell upload
- Add Embed Images in Comments <= 0.5 stored XSS shell upload
- Add Qards local port scan
- Add WP Support Plus Responsive Ticket System < 8.0.8 shell upload
- Add Events <= 2.3.4 hash dump
Add Comment