Wordpress 4.9.8 Exploit

[Demeter Exekutor]

WordPressis the application behind more than 30% of all websites. Its ease of use and open source base are what make it such a popular solution. The number of installs continues to grow; there are now an estimated 75 million WordPress sites. This popularity makes it a target for bad guys aiming to use a compromised web server for malicious purposes.

There are very good guides on securing a WordPress installation available. This article does not intend to repeat those. To get started securing a WordPress install, try the excellent guide on wordpress.org or this comprehensive guide on the OWASP site.

Keep in mind, in a managed WordPress hosting service, some of these attacks (and mitigations) will be the responsibility of the hosting provider. If you are self hosting, then security and maintenance are your responsibility. Ready to start? Let's grab our hoodie and start hacking.

Put yourself in the Attackers' mindset. The first thing we want to do is discover as much technical information regarding the site configuration as we can. This will help us when we move onto the actual attacking or exploitation phase.

Enumeration or reconnaissance can be conducted stealthily using regular web requests to gather technical information about the site. Or it can be performed more aggressively by brute forcing web paths to detect the presence of plugins and themes. To begin with, we want to get an idea of how well maintained the site is. Determining whether the site is running the latest WordPress core version is a good start.

If the meta tag has been disabled, check for the presence of /readme.html from root of the install. Early versions of WordPress had the version right there at the top of the ReadMe file, newer versions of WordPress have removed the version from the file.

An attacker finds a site with an older WordPress Core version, and as a result, this may be directly exploitable via a security vulnerability in the WordPress core. And, it is a clear indication the site is not being well maintained.

During WordPress Plugin Enumeration we attempt to find as many installed plugins as we can (even those that are disabled). Knowing the installed WordPress plugins may allow us to identify the version, and research whether it is vulnerable to known exploits.

Reading through the HTML source of the WordPress site can reveal installed plugins through javascript links, comments and resources such as CSS that are loaded into the page. These are the easiest plugins to discover and require no aggressive testing of the target site. Even the HTTP headers can reveal information, such as the X-Powered-By header that reveals the presence of the W3-Total-Cache plugin.

Some plugins do not leave traces in the HTML source. To find all the installed plugins you have to be more aggressive. A number of tools can brute force known plugin lists from the path /wp-content/plugins/ * plugin to test * /. The web server response will usually reveal valid directories (often with HTTP 403) as opposed to unknown directories on the web server with its HTTP response code.

In the readme.txt we can see the version of the plugin. Compare this against known exploits and we can get a good idea if the site is vulnerable without actually throwing the exploit.

As with plugins, WordPress themes can contain vulnerabilities that might expose the site to compromise. Themes are collections of PHP code with HTML and CSS resources. More complex themes have more included components and are more likely to introduce security vulnerabilities.

Enumeration of the theme is conducted similarly to detecting the plugins. The theme path is often visible in the HTML of the page source. The CSS file getting loaded from the theme will often reveal the path.

An important consideration when testing for vulnerable WordPress Themes (and plugins) is a theme that is installed yet not active may still have code that is accessible and vulnerable. This is why brute force testing for theme paths is an important step when assessing an unknown WordPress installation.

If we can gather valid usernames, then we can attempt password guessing attacks to brute force the login credentials of the site. Getting access to an administrator account on a WordPress installation provides the attacker with a full compromise of the site, database and very often remote code execution on the server through PHP code execution.

These user enumeration techniques have been reported to WordPress.org as security vulnerabilities, however, the developers do not classify the user name as sensitive and are willing to accept the risk over the increased usability. Such as advising the users when the user is wrong vs the password being wrong.

In a default installation you should be able to find the users of a site by iterating through the user id's and appending them to the sites URL. For example /?author=1, adding 2 then 3 etc to the URL will reveal the users login id either through a 301 redirect with a Location HTTP Header

Using a json endpoint it may be possible to get a list of users on the site. This was restricted in version 4.7.1 to only show a user if configured, before that all users who had published a post were shown by default.

In this phase, we move into testing network services rather than direct testing of the WordPress installation. Port scanning is the standard technique for the discovery of network services running on the server.

Any of the services may allow access or control of the server through either a security vulnerability or a compromised password. Port scanning can be conducted using the excellent Nmap Port Scanner or an alternative security tool.

Carrying on from our enumeration of network services using the port scanner, we could run vulnerability scans against the discovered services to identify exploitable services or other items of interest.

The Greenbone Vulnerability Manager (GVM) (previously known as OpenVAS) is one option, this is an open source vulnerability scanner that can be installed locally or enterprise appliances are also available from Greenbone Networks. We also host the open source OpenVAS scanner for testing internet accessible targets as part of our security testing platform.

Nikto is another vulnerability scanner that focuses on the discovery of known vulnerable scripts, configuration mistakes and other web server items of interest. The Nikto tool has been around for many years yet still has a place in the penetration testers toolbox.

Tools such as this throw tens of thousands of tests against target in an attempt to discover known vulnerabilities and other low hanging fruit. It is a noisy process filling the target system logs with 404's and other errors. Not recommended if you are going after a target ninja style (pentest / red team).

Many WordPress sites opt for third-party services to help protect the site from attacks by using a web-based firewall proxy. A service such as Sucuri or CloudFlare sits between the users' browser and the WordPress site. Attacks launched at the site can be detected and blocked by the firewall.

The firewall proxies the traffic by using DNS. The sites DNS is pointed at servers belonging to Sucuri or CloudFlare so the user (or attacker) will resolve the hostname and connect to the IP of the Firewall system.

If we determine the real IP address of the server and add an entry to our hosts' file, we can bypass the firewall and go directly to the webserver hosting the site. This is significant if the site is not well maintained and relying on the protection of the firewall. For example, a vulnerable plugin may be present but being blocked by the firewall. We bypass the firewall, exploit the vulnerable plugin and the server.

Once you have an IP address that you suspect could be the IP address, add it to your /etc/hosts file with the sites hostname. This will force your system to bypass DNS and go directly the IP address. If the site loads, there is a good chance this is the correct IP address.

WPScan is a popular WordPress security testing tool that ties many of these simple enumeration techniques together. Enabling users to quickly enumerate a WordPress installation, it has a commercial license restricting use for testing your own WordPress sites and non-commercial usage.

Nmap comes bundled with NSE scripts that extend the functionality of this popular port scanner. A few of the Nmap NSE scripts are particularly helpful for enumerating WordPress users, plugins, and themes using the same techniques we have previously discussed.

The most common attack against the WordPress user is brute forcing the password of an account to gain access to the back-end of the WordPress system. Other ways a password can be compromised include sniffing the password in clear text over a HTTP login session or even getting the credentials from a key logger on the workstation of the WordPress administrator.

Accounts with administrator level access are the most sought after due to the amount of mischief an admin user can get up to; adding PHP command shells or malicious javascript directly through the admin interface are common examples.

With the usernames we collected during information gathering, we can get started (or just try admin). Take a look at the login form /wp-login.php, notice how failed logins confirm the username when an incorrect password is entered. This information is helpful to an attacker. It also makes things more user friendly for the end user who has forgotten their username and password. This "feature" has been debated, and it was decided to keep this response within the WordPress code.

Brute forcing accounts of users is possible using a number of open source tools. Additionally, there is worm like scripts available that have spread through the WordPress ecosystem. These search for and spread to WordPress sites with weak admin passwords.

3a8082e126