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 datacenters, 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.