atarantini / wpbf

Remotely test password strength of WordPress bloging software

wpbf!

wpbf is a bruteforce tool to remotely test password strength, username enumeration and plugin detection on a WordPress site.

Description

The script will try to login into the WordPress dashboard through the login form using a mixture of enumerated usernames, a wordlist and relevant keywords from the blog's content. If a single username is given, the script will not search for additional usernames.

When a correct username/passwords matchs, it will be logged and show on the standard output.

For faster results you can spawn threads but BE CAREFULL not to flood/DoS the site. Default settings can be changed in "config.py" and "logging.conf" files.

The wordlist must have one entry per line, a small wordlist (wordlist.txt) and plugin list (plugins.txt) are provided for testing purposes.

Disclamer

This software is provided for educational purposes and testing only: use it in your own sites or with permission of the owner. I'm not responsible of what actions people decide to take using this software. I'm not not responsible if someone do something against the law using this sofware. Please be good and don't do anything harmful.

Features

• Username enumeration and detection (TALSOFT-2011-0526, Author's archive page and content parsing)
• Threads
• Use keywords from blog's content in the wordlist
• HTTP Proxy Support
• Basic WordPress fingerprint (version and full path)
• Advance plugins fingerprint (bruteforce, discovery and version/documentation)
• Detection of Login LockDown plugin (this plugin makes the bruteforce useless)
• Advanced logging using Python's logging library and logging configuration file

Requirements

• Python 2.6+ (maybe it runs in older versions, if you want to test please notify me)

Known issues

• False positives (in all passwords) with some uncommon WordPress versions or configurations

Usage

wpbf.py [-h] [-w WORDLIST] [-u USERNAME] [-s SCRIPTPATH] [-t THREADS] [-p PROXY] [-nk] [-eu] url

positional arguments:

url base URL where WordPress is installed (ex: http://www.myblog.com/)

optional arguments:

-w WORDLIST, --wordlist WORDLIST
	Worldlist file (default: wordlist.txt)
-u USERNAME, --username USERNAME
	Username (default: enumerate users)
-s SCRIPTPATH, --scriptpath SCRIPTPATH
	Relative path to the login form (default: wp-login.php)
-t THREADS, --threads THREADS
	How many threads the script will spawn (default: 5)
-p PROXY, --proxy PROXY
	HTTP proxy (ex: http://localhost:8008/)
-eu, --enumerateusers
	Only enumerate users
-eut, --enumeratetolerance ENUMERATETOLERANCE
	User ID gap tolerance to use in username enumeration
-nk, --nokeywords
	Skip search for keywords in content for the wordlist
-nf, --nofingerprint
	Skip WordPress fingerprint (version/full path)
-nps, --nopluginscan
	Skip plugins bruteforce, discovery and fingerprint
-ds, --dontstop
	Don't stop when password is found, continue with all pending tasks
--test	Run python doctests (you can use a dummy URL here)

For extended help, run "./wpbf.py -h".

Examples

Basic

It will use the default settings (you can change the default settings in config.py file):

$ ./wpbf.py http://www.mysite.com/blog/

Custom

Using username 'john', not using keywords in the wordlist and trough a local proxy:

$ ./wpbf.py --nokeywords -u john -p http://localhost:8008/ http://www.mysite.com/blog/

Aggresive

It will use default settings and spawn 23 threads:

$ ./wpbf.py -t 23 http://www.mysite.com/blog/

Username enumeration

Only perform a user enumeration:

$ ./wpbf.py -eu http://www.mysite.com/blog/

Output sample

Or how the script will behave in a normal run:

$ ./wpbf.py http://localhost/wordpress/
2011-06-18 19:11:41,461 - wpbf - INFO - Target URL: http://localhost/wordpress/wp-login.php
2011-06-18 19:11:41,463 - wpbf - INFO - Checking URL & username...
2011-06-18 19:11:45,073 - wpbf - INFO - Bruteforcing...
3 words left
2011-06-18 19:11:55,147 - wpbf - INFO - Done.
2011-06-18 19:11:56,641 - wpbf - INFO - Password 'qawsed' found for username 'admin' on http://localhost/wordpress/wp-login.php

Author

• Andres Tarantini ([email protected])

wpbf's Issues

Handle exceptions inside threads

When threads have exceptions (ex: Error 500) they usually stop working and the assigned job from the queue is not finished. If all threads experiment some exception the bruteforce become stalled.

Detect "Login LockDown"

When testing URL and Username, search for "Login LockDown" string in order to detect if the mentioned plugin is running.

Additional username detection

Some blogs only expose the username in this string:

<link rel="alternate" type="application/rss+xml" title="Blog title &raquo; RSS entries of AUTHOR" href="http://blogurl.com/?feed=rss2&amp;author=3" />

Check queue before adding new word

Before adding a new word to the queue, check if already exists.

Multiple target support

Support for multiple targets adding a new argument and passing a file name that must contain one URL per line. Another option can be a bundled shell script that launches wpbf from a file with one URL per line as a tool for masive, automated and regular testing.

Maybe a new argument to specify a log file where results are stored, or events to trigger when a password/plugin/vuln is found.

Parseable output in JSON format

Add new parameter (-o output.json) to store results in a parseable file (json or csv):

$ ./wpbf.com -o output.json http://localhost/wordpress/
2013-03-09 18:03:20,462 - INFO - Target URL: http://vulsai.com/
2013-03-09 18:03:20,475 - INFO - Checking URL & username...
2013-03-09 18:03:20,475 - INFO - Enumerating users...
2013-03-09 18:05:53,331 - INFO - Usernames: admin, andres
2013-03-09 18:05:55,216 - INFO - 89 plugins will be tested
2013-03-09 18:05:55,216 - INFO - Writing results to output.json...

Results may be grouped and look like:

{
    "users": [ "admin", "andres" ],
    "plugins": {
        "contact-form-7": { "version": "1.2.3" },
        "akismet": { "version": "0.1.7" }
    },
    "passwords": {
        "admin": "admin",
        "andres": "1234"
    }
}

More regexp

The code have some text matching with regexps and with "in", some re well writen, but some are a dirty thing. See how to do this matches in a more elegant way.

Request cache POST support

The simple dictionary based cache in Wp module only works for GET. All values passed via POST are ignored.

Clean unnecesary code

With the introduction of the Wp() class and URL basic filters, we don't need to take care about URL sanity in Wp() methods.

This line is removing a trailing slash and adding a new one, this can be avoided and it seem to be useless:

https://github.com/atarantini/wpbf/blob/master/wplib.py#L205

Remove that hack and re-check!

"https://" issue

If url start with "https://", I keep getting this error:
ERROR - URL Error on: http://https://xxxxxxx.xxx/wp-login.php

Change -eugt parameter name

Parameter name "eugt" is not an intuitive name, should be something like "eut".

Re-queue http error 500

Some tasks that perform network operations sometimes get 500 or timed-out; we can requeue ths tasks to try again later. If is implemented over WpbfWorker can act like a generic requeue method (only if the task is defined as requeueable).

Plugin detection

Use one of the available methods (ex: request /wp-content/plugins/PLUGIN-NAME and check for 404) with a list of known plugins. The list can be a external plain-text file so the user can update the list manually without editing Python files.

Stress & Benchmark

Select key pages (home, one post, one page, one tag, one category, one author, all current links in the home, etc) from the blog and request them X times timing each request. Then show a stats of each page and the sum of the time and average.

Refactor how "proxy" argument is treated

The argument "-p / --proxy" is managed in a unusual way (regardin all the other arguments). Normalization of this parameter is needed to mantain the code flat and clear.

Task re-queue (or enqueue within a task)

Sometimes a task fails and can must be requeued or a taks need to issue new tasks.

For example, when trying a login and get a request error we must requeue that task and do login again in order to assure that all words from the list get tested.

Other future implementation can be a tasks launching new tasks, like exploits tasks on specific plugins or additional data about certain type of discovery.

Make "params" parameter of Wplib::request() optional

The "params" parameter of the Wplib method "request" can be optional (defaulted to an empty list).

Check imports

Check that all imported modules are being used for something inside the script

Basic URL fix

Basic URL fix, add "http://" if not added, add "/" at the end of the URL, etc.

WordPress version detection

Usually the header of the templates have this tag:

<meta name="generator" content="WordPress 3.1.4" />

We can fech the version for there!

Full Path Disclosure

There is a common error in the way that coders of plugins and themes call some funcions (and don't check is the function is available). Calling certain files of plugins/errors we can know the full path where wordpress is installed.

This function should be part of "fingerprint".

Username enumeration gap tolerance

Add to the username enumeration a "tolerance" value to bypass gaps in user ID sequence.

This/Last year password generator append

Generate possible passwords with this year and last year, ex:

• admin
• admin2012
• admin2012
• domain
• domain2012
• domain2013
• user
• user2012
• user2015

Move filter_domain()

Move the filter_domain() funcion from the main script to an more adequate place

Add "--maxusers" parameter

Limit for the user enumeration

Remove WpWorker from wpbf.py

WpWorker should be in a wpworker.py file along with WpTasks and all specific tasks.

Rewrite README file in rst format

Rewrite README file in rst format

Fix keyword filter

Keywords that contain characters listed in "config.ignore_with" must be removed.

Log inside wplib

Extend the logger application-wide, this will ensure easy debuging when using external libraries or whatver will be included in the future.

Simple heuristics to Author's archive page enumeration technique

Enumerating users within the Author's archive page is done parsing the "title" tag, but sometimes the author's archive page is formated different. If the "title" tag is stored and them compared with other "title" pages the difference will be the username.

Refactor Wp/WpTask contructor arguments

Wp class should can take additional arguments so WpTask can call specific class without setters.

Enumerate from RSS link

There is a in the that can contain a username. Add as method of enumeration.

Task factory

Factory of tasks, posibly using reflection to automate/simplify task factory calling.