LuxSci

WordPress as a launching pad for malicious attacks

Published: October 4th, 2017
For a deep dive, see our white paper: Securing WordPress

In our previous post, we described various techniques used to attack WordPress-based sites. In this post, we’ll give some examples of what happens after the vulnerabilities have been exploited to hack into a website. The purpose is to continue to reiterate the lessons that blogs such as ours (see here, here and here) provide to alert the medical industry, specifically, and business, in general, to security issues that can lead to breaches and loss of business, reputation, and income.

It is worth recalling that WordPress is the world’s most popular content management system (CMS) powering ~60% of websites worldwide (that are known to use a CMS), and ~29% of all web sites. While it is hard to find the statistics on how many websites related to the medical industry use WordPress, it is likely that these could well be a substantial percentage of the total given the ease of setup and use associated with WordPress. The fact that many of these are smaller sites, often without much IT support (much less security support) makes them all the more vulnerable. This makes education about the security aspects of WordPress all the more necessary.

WordPress is a launching page for malicious attacks

Despite the valiant efforts of the WordPress organization, vulnerabilities continue to exist and most exploits take advantage of the simplest techniques – infrequent updates of critical software, poor web site hygiene (easily broken passwords, retaining default options, turning off auto updates, etc.) and the use of vulnerable WordPress plugins and themes. (Hereafter, we also include plugins and themes when we talk of WordPress vulnerabilities, unless we need to specifically distinguish between these.) Sucuri.net, a website security company, noted that of the 11,485 infected websites that they analyzed in 1Q2016, 78% of these were built on WordPress of which ~56% were out-of-date (i.e., not running the latest version). The vulnerabilities were primarily in the plugins and themes.

While the image of a dedicated hacker probing for weaknesses is often true in the case of exploited zero-day exploits, automation is now the hacker’s preferred tool – and what better target with high yield than a concerted action against one of the world’s most popular web site software systems? The use of bots and botnets has added a whole new dimension to the scale with which any new or unpatched WordPress vulnerability can be exploited. Such mass actions take advantage of the fact that bots and botnets can very effectively look for multiple vulnerabilities on a site in one go and can exploit whatever they find. Again, Sucuri.net indicates that they clean up, in the course of their work securing compromised websites, ~132 infected files on average at each.

In many of the examples, below, we discuss how infected WordPress sites are leveraged to attack other sites, gain traffic for other sites, or host malicious and unwanted pages.  Targeted WordPress attacks using the same techniques are also often found exfiltrating all of the accessible data in compromised databases and servers.  For many organizations, a breach of this data is a worst case scenario.  Pains must be taken to harden all web sites, including WordPress, and implement a strong defensive face to attackers.

If you site is compromised, you data is breached

Setting up the malicious launching pad

A compromised WordPress site can be used to launch a variety of attacks against other targets. These include large scale, brute-force login attempts and denial-service attacks against other servers, emailing spam, storing content, etc. Many of these take place without the owner being aware that the site has been hijacked and is under the service of a third party.

The most common bot or botnet attack is the repeated brute force attempt at entry to a site using multiple username/password pairs at various WordPress administrative entry points such as login.php or the xml-rpc APIs. With the help of botnets, such probes can take place very efficiently and quickly. A single vulnerable site provides the opportunity to insert a web shell (see our previous post for a discussion), which allows complete administrative control over the site[1]. (Never discount the fact that at least one site in a thousand will use an easily guessable username and password combination for login.) Even after the entry vulnerability is fixed, the web shell will continue to provide an open backdoor to the site. Sucuri.net, in their 2016 survey, found 66% of compromised websites had such a hidden backdoor.

Another target for a bot or botnets is to search for incomplete installations of WordPress. These are cases where WordPress has been installed but the installation has not yet been configured. The attackers search for /wp-admin/setup-config.php and complete the installation with their own credentials.

A single physical server may host thousands of WordPress sites. If an attacker manages to comprise one site, it can the search for and compromise others that share some common settings on the same server .

Some examples of the sorts of attacks that can now be launched from a compromised web site are described below.

DDOS using Pingbacks

One attractive feature of WordPress as a blogging platform is the ability to receive a pingback, which indicates when someone has linked to your blog post.  When you receive a pingback, your WordPress software verifies that the link exists at the remote (linker’s) site by downloading the content. Using this feature requires your site to have enabled pingbacks, which is turned on by default when WordPress is installed. The technology used for pingbacks and xml-rpc, is also used to support various other useful functions such as mobile access to the WordPress site for administration. It is of course possible to turn off the pingback method while leaving the other xml-rpc methods available. However, many WordPress websites do not change the default installation settings, leaving the site available to be a launching pad for a subsequent DDOS attack.

When a hacker sends you a pingback with a false linker address (which is the target of the attack), your pingback protocol will query that address to verify the existence of the linked-to post. Thus, if a hacker has found a large number WordPress sites that have enabled the pingback method, a target under DDOS attack can receive thousands of pingback requests from perfectly legitimate WordPress sites. The attack can be amplified by identifying a large file as the linked-to post. Very soon, the target can have it outgoing bandwidth and computing resources tied up.

WordPress now makes visible the IP addresses of the attacker (recorded as a part of the TCP handshake for the pingback message), and a WordPress site administrator can at least examine these to see where such requests are coming from.

The simplest solution to avoid being the unwitting partner in such DDOS attack is to selectively disable the pingback feature.

Search results hijacking

Google, using a proprietary algorithm, provides additional hyperlinks to related pages of a website on its search results page. Such sitelinks, which include small snippets of text (called “site metadata”) describing the page content, improves site navigation and gives prominence to your site as shown by the amount of space Google chooses to provide for it. For example, a search for our company Lux Scientiae shows the following result:

Imagine our horror if we were to discover one day, or have an enraged customer call us to say, that the site metadata was showing text related to pornography, designer shoes, or treatments for erectile dysfunction. It won’t happen to us, of course, as our site is well protected against such hacks – and, moreover, not built on WordPress. But vulnerable WordPress sites have been and are often so hacked.

Thus, the attacker gets prominence on the search page by piggy-backing on your carefully cultivated reputation and site ranking. And perhaps they even get some traffic to their site from those who follow such affected links deliberately or inadvertently. The effect of this, apart from loss of reputation and customers, is the potential to lose a coveted spot on the search results page, and possibly even getting a “This site may be hacked” entry on a Google search results page. Restoring your site ranking after such a loss of traffic can take much time and energy.

Sucuri provides a detailed description of how they found and cleaned a particular case of hijacked search results. Very briefly, the attacker managed to hide the remote location of the metadata snippets and redirection links in various files on the infected website. Some clever coding was used to ensure that these additions are only picked up by search engine crawlers, such as Googlebot, and not by normal visitors to the webpage. The actual metadata is not maintained locally, allowing the hacker to change the contents as needed. Once again, the site owner can remain oblivious to the attack until alerted by the negative feedback – typically much later – during which period the attacker gets a quick boost in his/her own traffic before moving on.

Search results poisoning

Ranking prominently, ideally first, on the first page of a search is the ultimate goal of search engine optimization (SEO) techniques used by many websites. It takes time and effort to achieve this, and thus one can understand the desire of malicious actors to take advantage of this to redirect traffic to their sites. A site’s search rank has historically been calculated based on, among other factors, two important things: how many sites link to it, and the rank of those sites themselves. Thus, many links to a site from other prominent sites boosts its ranking. A malefactor, therefore, attempts to get its links into as many prominent or highly ranked sites as possible.

The steps to falsely boost a site’s SEO rank on the back of a reputable site works as follows:

  • A malicious actor identifies sites which are vulnerable to certain attacks, such as Cross-site Scripting (XSS) and/or SQL Injection (SQLi). (We described these vulnerabilities in our earlier post.)
  • The malicious actor creates custom links to its site modified with keywords that are currently popular in search queries (such as topical news, celebrities, new products, etc.)
  • These links are injected into dynamic or user generated content (such as comments, reviews, etc.) at the hacked sites using one of the above mentioned vulnerabilities so that these links are indexed by search engines. If appropriately chosen, these popular keywords raise the site ranking of the malicious site.
  • When users search based on these keywords, such sites are prominently displayed. Clicking on such a search results causes a redirection to the malicious site. Once here, the user may inadvertently download malware. At best, the user is offered some product on sale.

Once again, the site owner may not even know that it has been exploited in this manner until a drop in its own ranking is noticeable.

Summing up

We have shared a few examples of how a hacked WordPress site can become an unwitting tool for attacks. There are many more examples, including sending spam, serving rogue advertisements, storing files illegally, exfiltrating sensitive data, installing cryptomalware, and meddling with other sites’ traffic analytics. All these often happen unbeknownst to the site owner, at least for a period. Such attacks are amplified by bots and botnets which search for vulnerabilities in thousands of sites over a short period, with each vulnerable site providing a launching pad for future attacks.

In most, the causes of exploit come down to an inability to keep WordPress (and its themes and plugins) up-to-date as well as not deploying other reasonably straightforward defenses. We shall outline these techniques in a future post.

Read Next: For a deep dive, see our white paper: Securing WordPress

[1] While not specific to WordPress, recent revelations on the recent Equifax breach state that over 30 web shells were placed on Equifax servers. At least one offer has been made to sell access to an Equifax server via a web shell.

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.