We all know that WordPress is the primary and most popular CMS system used on the internet. We also know that security in WordPress is not always taken for granted. The WordPress CMS system can have different vulnerabilities in older versions, so it’s vital keep it up-to-date. We should also be on alert for new zero-day vulnerabilities and patch those systems that are affected.
Keep in mind that it’s not uncommon to see new zero-day vulnerabilities being discovered in newest versions of WordPress. We should also configure the WordPress system as securely as possible; there are multiple articles on the internet describing how to do that, so we won’t go into that in this article. Instead, we’ll describe basic principles of identifying vulnerabilities on WordPress.
How to Identify WordPress Vulnerabilities
Guessing the Admin Password
It’s very common that WordPress administrators assign weak passwords to the admin username. The admin web login page is usually located at the /wp-login.php URL as can be seen on the picture below:
If we try to enter the username admin and password admin, the password is of course invalid. Trying to hack the InfoSec Institute password is of course futile, since it uses strong passwords, but this might be relevant for other WordPress CMS enabled web sites.
There are various tools that we can use to automate the password dictionary or brute force attacks. One such tool on Windows is Cain & Abel.
Inputting Arbitrary Strings
Let’s take a look at the search form in which we can input some string to search for. In the picture below we can see that we searched for a string searchstring and no results including that search string were found.
But what happens if we search for something, which also uses some characters that are not allowed. Usually such characters are left/right arrows, apostrophes, etc.
Let’s input a string < b > into the search field and see what happens.
When we first look at the two pictures, we can’t see any differences, but if we look more closely, we can clearly see that the sentence “The search didn’t find any search page that matched the search query.” is written in bold on the latest picture. Also, the “You searched for:” field is empty. Why is that? It’s because we’ve searched for a string < b >, which wasn’t encapsulated, but directly inserted into the HTML code of the web page.
This happens when the programmer didn’t enclose the user input correctly. Since we’ve inputted special characters ”, which were inserted into the HTML code, that search string becomes part of the HTML code returned to the user.
The < b > in HTML language means that the web browser will mark every text from this string till the ending as bold. This is why the “You searched for:” string on the first picture was written in bold (we can only see part of the web page’s text written in bold, but actually the whole web page from that point on is bold now).
At first, that doesn’t seem like a serious vulnerability, but we’ve just gained a way to input arbitrary text into the HTML code of a web page. This means we can further attack the web page by constructing a special JavaScript code and inputting it into the search field. The JavaScript code will probably be executed upon sending the search query to the backend system.
What’s left for the attacker to do is to send a specially crafted link (that includes the malicious JavaScript code) in a URL link and sending it to the victim’s clients. When the users click on the link, the included malicious JavaScript will be executed and can possibly steal the user’s session cookies, which can enabled the attacker to login in the name of the user and further compromise the account.
This can also result in an SQL vulnerability if the target website uses the inputted string directly in an SQL query. If this is true, we can get access to the entire database used by the website.
Be sure to disable public access to indexes whenever possible. If your web server runs Apache or another OS that uses .htacess files, it’s simple to do. Find the .htaccess configuration file in your site’s main directory. That’s the directory that contains index.php. Insert the text Options -Indexes anywhere in the file.
Alternatively, if you can’t alter an .htaccess file, upload an index.html file into your main directory. You could make that web page have a similar look to your site’s PHP web pages and insert a hyperlink to your index.php file if you’d like. But obviously, in a site that uses WordPress as a CMS, visitors won’t see your index.html file unless they type a specific path to it in their web browser address bar. Alternatively, you could make your index.html file a 0 byte placeholder.
In case your web server ever has problems computing PHP files, it’s crucial to block directories that are only accessed by your server. If the PHP source code is ever displayed in a visitor’s web browser rather than the web page it’s supposed to render, they may find database credentials or in-depth information about the PHP/mySQL programming of your site. Your site’s wp-includes/ directory is the most important one to block. Find the .htaccess file there and insert:
RewriteRule ^(wp-includes)\/.*$ ./ [NC,R=301,L]
If there are or will be sub directories of wp-includes/, insert the following code for each one in the same .htaccess configuration file:
RewriteRule ^(wp-includes|subdirectory-name-here)\/.*$ ./ [NC,R=301,L]
WP-DB Manager is excellent for backing up your entire WordPress site, but it’ll also alert you to mySQL vulnerabilities and let you know when parts of your database are publicly accessible. Always be sure to properly back up the content of your site. In the worst-case scenario, at least keeping back ups will allow you to easily restore your site.
Google Hacking Databases
First, we should look in databases like GHDB (Google Hacking DataBase) accessible on Exploit Database and search for a keyword “wordpress” or something similar. If we do that, quite a few search queries pop-up as can be seen on the picture below:
There are three columns presented on the picture above. First, there is the Date column, which specifies the date of the saved search query into the GHDB. Then there is the Title column, which presents the actual query that we should input in Google Search Engine to search for some WordPress vulnerability. Then there’s also a Summary that provides enough information about what the Title column searches for on the internet.
The first example searches for files that contain info and use a search query filetype:avastlic. This isn’t directly connected to WordPress CMS systems, but the query was taken from some WordPress blog. An actual WordPress relevant entry is shown below, which searches for the files that contain WordPress passwords.
It uses the search query filetype:sql inurl:wp-content/backup-*, which looks for files ending with SQL extensions or containing the word wp-content/backup in the URL.
Let’s use the above search query to search for files that contain passwords via the Google search engine. We can see the results of a search query below:
Google found 7,170 results which we can check out to find some passwords in an SQL database dump. If we look over the results in those SQL databases we’re likely to find some usernames and passwords.
With this method, we can target specific WordPress installations that we want to check for files containing passwords. If we wanted to check whether we can access SQL databases on resources.infosecinstitute.com WordPress site, we could use the query shown on the picture below:
We added the site constraint in the search query to only check on a webpage resources.infosecinstitute.com. We can see that the search query didn’t return any results that could possibly include SQL dumped databases.
We can also try searching with different GHDB search queries on the interested site to see whether the site reveals any additional information about itself or maybe even reveals its password to admin login area.
What Can We Do?
We must and really should ask ourselves this question when developing a software product in whatever language. First, we must be aware of the kinds of vulnerabilities that are most likely to come up while developing in the chosen language. Thus, if we’re using PHP, it’s far more likely that something like SQL injection or XSS flaw will be present. Yet, if we’re writing in a programming language like C/C++, buffer overflows and format string vulnerabilities are far more likely.
Okay, but what can we actually do about it? First of all we must at least briefly understand the vulnerability that we’re dealing with (regardless of the fact that we don’t know if we’ve written a vulnerable code). The basic approach when defending against attacks is the following: never trust anything that comes from the user; even if the input data normally doesn’t come from a user (like a hidden form field), but can be changed by a user somehow, don’t trust it. This gives us a pretty good guideline when developing something.
We must then ask ourselves the following question: What input data can come from the user? This question is not as straightforward as it might seem when we first look at it. Sometimes it’s actually quite hard to determine what input data can come from a user, as many hidden features are often forgotten (like previously mentioned hidden form field in HTML).
The most important thing to do is that we check all input vectors for possible disallowed characters if such is detected, we can deny the input or encode the input string, for malicious strings we can check if some string is detected in input value.
In the end, it isn’t so important that we check and protect all input values, because we most certainly can’t do that, since we don’t know all possible input values. This is why, if we can check all input values that we know can come from a user, we’re actually doing quite a good job at preventing possible attacks from happening.
Recommended Plug-ins
There are a number of other WordPress plug-ins that I recommend you install and use. When used properly, they can harden your WordPress site very effectively.
1. Expoit Scanner
Every so often, run the Exploit Scanner plug-in to check for indications of malicious activity. Exploit Scanner doesn’t directly repair any issues, but it will leave you a detailed log to troubleshoot with. If you ever suspect cracking, that’s the time to run that plug-in, as well.
2. WP Security Scan
With Exploit Scanner, you can also use WP Security Scan. Not only will the plugin look for vulnerabilities, but it’ll also give you specific advice for blocking them.
3. Limit Login Attempts
Configure the Limit Login Attempts plugin to prevent brute-force attacks. With the plugin, you can set a maximum number of login attempts, and also set the duration of lockouts in between.
4. Block Bad Queries
Block Bad Queries will try to block malicious queries made to your site. It looks for “eval(” or “base64″ in request URIs, and also looks for request strings that are suspiciously long.
5. Antivirus
An anti-malware shield can be applied to your entire site with the AntiVirus plugin. It looks for viruses, worms, rootkits, and other forms of malware. Be sure to keep it updated!
Conclusion
We’ve seen the most basic hacking tricks that we can use when checking the security of a web application. When we’re working with WordPress, we can always check if the admin username is using some weak password. We can do that by hand or by automated tools like Cain & Abel, Hydra or Medusa.
Then we can try to input special characters into the input form fields, which can results in various vulnerabilities, like XSS and SQL vulnerabilities. For a deeper look into common web vulnerabilities, check out the CEH training course offered by the InfoSec Institute. I also suggested several plug-ins that can help improve the overall security of your WordPress site.
In the end, we can check if a WordPress website is revealing usernames or passwords by using some of the most common techniques that Google dorks can find in a Google Hacking DataBase. There’s also a tool able to do that automatically, called SearchDiggity.
The conclusion is: whenever you’re programming a web application, you should always remember to check all input values that came from a user. If they’re protected, the chances of your page getting hacked decreases significantly. You can also check out more about WordPress security vulnerabilities at CVE Details.
