Introduction
Inputting Arbitrary Strings
We all know that WordPress is the primary 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.
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 passwordadmin, 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 bruteforce 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.
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 webpage. This happens when the programmer didn’t enclose the user input correctly. Since we’ve inputted special characters ‘<‘ and ‘>’, which were inserted into the HTML code, that search string become 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 </b> 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 into 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.
Google Hacking Databases
First, we should look in databases like GHDB (Google Hacking DataBase) accessible on http://www.exploit-db.com 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 examples searches for files that contain info and uses 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 the 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 injectionor XSSflaw 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 ask then 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).
At 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.
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. At the end, we can check if a WordPress web site 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.
A family member linked me to this site. Thnx for the resources.
Feel free to surf to my homepage: http://www.logonow.com.au