There are many common attack vectors that hackers use to attack a WordPress website. In this article we expose many of the common avenues for attack. By revealing these, you can help build your website’s defenses against WordPress attacks.
WordPress is the application behind more then 25% of all websites. Its ease of use and open source base make it such a popular solution. The numbers of installations keep growing; there are literally millions of WordPress installations. This popularity makes it a juicy target for bad guys aiming to use a compromised web server for malicious purposes.
Basic WordPress Security
There are many very good and detailed guides on securing a WordPress installation available, this post is not intended to repeat those. To get started securing a WordPress install try the excellent guide on the wordpress.org web portal http://codex.wordpress.org/Hardening_WordPress.
Information Gathering
The first step for hackers when looking at WordPress attacks involves gathering information about the target. The aim is to get a good understanding of how well maintained the site is, and identifying if the site is running the latest WordPress version is a good start.
WordPress Core Version
The two fastest ways to discover the core version of the WordPress site is to check the HTML source of the page for a meta generatortag in the HEAD of the source or the examplesite.com/readme.html file that is distributed as part of the core installation files.
This example is taken from the source of a default WP install of version 3.5.2 and twenty twelve theme. From the source HTML:
<meta name="generator" content="WordPress 3.5.2" />
If the meta tag has been disabled, the next place to check for this information is the existence of the /readme.html file from root of the install. This information file contains the version of WordPress right there at the top. This file is not required at all in the use of WordPress, and should be deleted to hide this critical information.
It is common to find the version of the installation through one of these two techniques. There are known security issues even in some of the most recent releases of WordPress core, so check the discovered version against the known vulnerabilities. Even if you are unable to find any good exploits for the version of WordPress core, knowing the installation is running anything older than the latest release indicates that the site may not be closely managed – in which case the chance of exploitation elsewhere has increased considerably.
Directory Indexing
Directory indexing is a function of the web server that allows you to view the contents of a directory in the web accessible path. Viewing the contents of a directory allows an unauthorised user to gather a lot of information about the installation such as which plugins and themes have been installed.
To check for directory indexing you can browse to folder locations and see if you get a response that includes “Index Of” and a list of folders / files. Common locations to check would be:
/wp-content/ /wp-content/plugins/ /wp-content/themes/ /uploads/ /images/
If you can browse /wp-content/plugins/ – the next step in information gathering phase where we attempt to find installed plugins and versions is becomes much easier!
WordPress Plugin Versions
In this step we are going to attempt to find as many plugins that are installed (whether they are enabled or not) as possible. Knowing which plugins are installed allows us to then try to determine whether it is vulnerable to known exploits.
- Passive analysis can be used to find plugins through regular HTTP requests to the WordPress site.
- Active analysis is more aggressive and usually involves using a script or tool to perform hundreds or even thousands of mostly invalid HTTP requests.
Review of the HTML source of the WordPress site can reveal installed plugins, through javascript links, comments and resources such as css that are loaded into the page. These are the easiest plugins to discover and require no aggressive testing of the target site. Even the HTTP headers can reveal information such as the X-Powered-By header that reveals the presence of the W3-Total-Cache plugin.
Since some plugins are not seen in the HTML source; to find all the installed plugins you have to get more aggressive. A number of tools can brute force known plugin lists from the path /wp-content/plugins/ * plugin to test * /. The web server response will usually reveal valid directories as opposed to unknown directories on the web server with its HTTP response code.
User Enumeration
Discovering the account names of the users of the site, allows you to then attack the passwords of those users through the WordPress login form.
In a default installation you should be able to find the users of a site by iterating through the user id’s and appending them to the sites URL. For example /?author=1, adding 2 then 3 etc to the URL will reveal the users login id either through a 301 redirect with a Location HTTP Header
wordpressexample.com/?author=1
Having valid user accounts will be very useful when it comes to brute forcing passwords. Automated user enumeration can be performed by the tools listed in the brute forcing section below.
Attack the Users
The most common WordPress Attacks brute forcing the password of an account to gain access to the back-end of the WordPress system.
Accounts with administrator level access are the most sought after due to the amount of mischief an admin user can get up to;, for example adding PHP command shells or malicious javascript directly through admin interface are common examples.
Brute Force wp-login
With the usernames we collected during information gathering we can get started (or just try admin). Take a look at the login form /wp-login.php, notice how failed logins confirm the username when an incorrect password is entered. This is very helpful to an attacker…. it is also makes things more user friendly for the end user who has forgotten his username and password. This “feature” has been debated and it has been decided to keep this response within the WordPress code.
Tools for breaking weak passwords
Brute forcing accounts of users is possible using a number of open source tools. In addition there are recent worm like scripts available that have been spreading through the WordPress interwebs, searching for and spreading to WordPress sites with weak admin passwords.
WPScan – http://wpscan.org
The WPScan tool is one of the best available when it comes to testing a WordPress installation from a blackbox perspective. It is able to brute force plugins, detect vulnerable themes, enumerate users and brute force accounts.
Here is example output from a test I ran with WPScan against a low end Digital Ocean VPS ($5 / month) where I had installed a default installation of WordPress.
ruby wpscan.rb -u 192.241.xx.x68 --threads 20 --wordlist 500worst.txt --username testadmin ********* SNIP ****************** [+] Starting the password brute forcer Brute forcing user 'testadmin' with 500 passwords... 100% complete. [+] Finished at Thu Jul 18 03:39:02 2013 [+] Elapsed time: 00:01:16
Lets review the output, 500 passwords tested against the ‘testadmin’ account (that was discovered during user enumeration). Those500 passwords were tested in 1 minute and 16 seconds! While the test was running the site was still responding; a web server administrator would have no idea the attack took place without some sort of security log monitoring system in place (OSSEC does this very well).
The ‘500 worst’ password list used above is from Skull Security. The site has a large number of password lists including the 60mb rockyou list that contains many more than 500 passwords!
Nmap NSE Script – http://nmap.org
Nmap the port scanner can do much more than just find open ports. Recent versions of Nmap come bundled with NSE scripts that can be used to test many different vulnerabilities; including enumerating users and brute forcing WordPress passwords.
nmap -sV --script http-wordpress-enum --script-args limit=25 PORT STATE SERVICE REASON 80/tcp open http syn-ack | http-wordpress-enum: | Username found: admin | Username found: testadmin | Username found: fred | Username found: alice | Username found: bob |_Search stopped at ID #25. Increase the upper limit if necessary with 'http-wordpress-enum.limit'
Output above shows an example run using the http-wordpress-enum NSE script to enumerate WordPress users.
PORT STATE SERVICE REASON 80/tcp open http syn-ack | http-wordpress-brute: | Accounts | testadmin:myS3curePass => Login correct | Statistics |_ Perfomed 113 guesses in 19 seconds, average tps: 6
Above is the results from brute forcing WordPress accounts using the http-wordpress-brute NSE script.
Now lets defend against these WordPress Attacks
Hopefully these tips, tricks and insights into the minds of hackers will help you better defends your WordPress site against hacks.
