WordPress is a popular target for hackers because every website has something to offer them, and the returns on attacks are high.

 

Hackers gain something from every WordPress site

 

WordPress is the most popular CMS in the world, and a popular target for hackers too. The scale of the problem may make it seem like the hacks occur randomly and for random reasons. In reality, every website has something to offer hackers. The exact nature of the payoff also depends on the intentions of the hackers.

 

Hackers can be grouped into three categories, depending on the purpose behind their attacks:

White-hat hackers usually test a website or a computer system for vulnerabilities. They do not have malicious intent, and disclose vulnerabilities responsibly.

In the WordPress community, white hat hackers are either a part of a web security team, or are developers within the community who contribute by discovering vulnerabilities and helping protect the community against such risks.

Hacktivists, (who are ‘activists’ acting by means of hacking) target websites mostly to bring awareness to socio-political issues, but the means they pursue for these ends are questionable. This is why it’s difficult to categorise what they do. Most of the time, hacktivists deface websites, or publish sensitive information.
Examples for hacktivist defacing websites range from  Anonymous’ hack of the Phillipine Comelec that asks questions, to the defacement of the ISIS website with ads for performance-enhancing drugs. Hacktivists could also publish sensitive information. Examples of such attacks include the  Panama Papers leak, and the hack of the  CIA  and FBI websites that released officers’ personal information and put them in danger.

Since the classification of what hacktivists have to gain, and the means they use to achieve their ends can fall in gray areas, we’re going to exclude hacktivism from this article.

Black-hat hackers, who hack websites indiscriminately, purely because of more ‘materialistic’ gains. They exploit vulnerabilities to their own ends. Any website can be targeted by these hackers, since they are not looking to test a specific system for vulnerabilities, nor do they want to further a socio-political agenda.

 

What Black-hat hackers can gain from hacking websites

Black-hat hackers could gain one of three things from hacking websites:

  • Reputation
  • Access to resources
  • Information

 

Reputation

In terms of technical know-how, and the scale of the reputation they seek, black-hat hackers could be ‘script kiddies’, or ‘experienced hackers’.

‘Script kiddies’ depend on tools to perform hacks. While the scale of the havoc they wreak can vary in degree, they usually hack websites to be accepted, or to gain reputation among their peers. They usually don’t have criminal intent. However, the more they learn, the more they could move towards higher levels of experience and reputation.

Garnering reputation among other black-hat hackers depends not only on the technical know-how they have, but also on the damage they have the ability to wreak independently. This is when/why they move away from readily-available tools, and craft malicious code of their own that can bypass usual security measures on websites.

‘Experienced’ hackers look to earn a more ‘professional’ kind of reputation. You might know that there are black markets for the sale of illegal goods, but there are similar establishments for cybercrime too. One such black market/forum, was Darkode. Hackers have profiles on these websites and are ranked. These hackers look to earn higher ranks so that their ‘customers’ will pay more for their services, and their work will be recognized more.

How high a hacker’s rank is, on cybercrime forums, depends on:

  • The number of sites they’ve hacked.
  • How proficient they’ve been (the difficulty of the hack).
  • The reputation of the sites they’ve hacked.
  • How satisfied their customers are with their ‘service’.

In short, even if  your website has great security, it’s better for them: they get a better ranking if they succeed in hacking your site.

For example, if your site had tight security, and a hacker successfully retrieve contact information of all your customers, they only garner reputation and have no use for the information afterward. They could go ahead and publish it on the cybercrime forum so other hackers could use the information to send spam mail to your users, send them downloadable malicious code, or send them mails crafted for phishing.

 

Access to resources

The resources on your WordPress site include your site’s database, the server it’s hosted on, as well as the users and visitors to your site. Black hat hackers hack your website in order to gain access to these resources. Attackers have a number of ways that they could exploit your site’s resources:

  • They could plant malicious code on your site to do anything they need to do, without the action getting traced back to them. An example of this would be that of hackers planting malicious code on your server to send their spam mail to your site’s visitors. This would not only get your server blacklisted by mail servers, but also could lead to your WordPress site getting blacklisted by search engines (since it has malware).
  • They could use your site to perform Black Hat SEO practices that allow them to hijack your site’s traffic and redirect it to their own websites, or their customers’ websites. A common type of attack on WordPress sites that uses this technique is the WordPress Pharma hack.)
  • They might use malicious code on your site to trick the visitors of your site into downloading malicious software to their computers.
  • Cross-site scripting attacks  could be used to steal cookies from your site’s visitors and use their credentials.
  • They could use your server as a bot in a DDoS attack.
  • They could manipulate your site to trick users into entering sensitive information that could be used for phishing.
  • They could use ‘ransomware’, which is malicious software that doesn’t allow you access to your resources, your website, or important files on your website unless you pay up. Ransomware keeps popping up in tech news because of technology’s progression into the Internet of things (smart home appliances that can be connected to the internet). In the context of websites, ransomware could be used to either lock you out of your site, or encrypt all the data on your website until you meet the hacker’s demands. If you don’t give in to the hacker’s demands, they could keep all the data from your WordPress site to themselves until you do, or worse, delete it all. The only sensible way to protect yourself from such an attack, is to have a reliable WordPress backup solution that has updated backups of your site.

 

Information

As any website owner knows, information is probably the most important thing on a website. From your site’s data to your visitor’s data, all of the information on your website is unique to you, and is hence valuable.

Hackers could hack your site to retrieve information that belongs to your site’s visitors, such as their personal information(which includes contact information, photos, medical records and other information about their identity), or financial information.

Hackers could use this information in the following ways:

  • They could use it for their own purposes (such as to send spam mail). Sending spam mail from your website’s server could get it blacklisted by search engines, and other mail servers.
  • They could publish sensitive information from your site.
  • They could sell it to others looking for this kind of information.
  • They could also retrieve confidential information from your WordPress site (such as information about your investors), and ask you to pay a ransom to make sure it isn’t published, or sold.

 

Publishing sensitive information

Sensitive information on your website doesn’t have to just be related to the financial information … it could be anything that is specific to just your site, such as the personal information of your site’s users (like their email addresses), that could be used in line with malicious intent (to fulfill a job request, to damage the reputation of the company whose information they publish, to help other hackers send spam).

For example, a hacker could publish your users’ email addresses, to ruin your establishment’s reputation and the trust your customers have in you.

 

Selling sensitive information online

This is another dangerous way hackers target the information on your site.

While some hackers sell personal information of celebrities online (like in the case of Pippa Middleton’s iCloud photos that the hacker attempted to sell), in the past few years, a number of medical websites have been targeted.

This is because social security numbers, medical and healthcare information could prove to be more valuable in terms of identity theft than even financial credentials.

Hackers who sell financial information are in a race against time; they only get the best price for their hard work as long as the credentials are recent, and valid. If the people whose information was stolen, blocked their cards or switched banks, they don’t get paid. However, with identity-theft, the validity of the crime is much longer; and the payoffs for the buyer is considerably higher.

The parties that buy this information could use it to:

  • Create online loan applications
  • Create applications online for credit cards
  • Apply for prescription drugs
  • Create fake IDs

This poses a serious risk for any website, but especially for those that store any sort of user-information.

 

With reasons/aims like these, it’s no wonder that hackers continue to do what they do. They know that there is no such thing as a secure website, so any website can be hacked, and used to any end. The returns for them on hacking websites is high. This is why hackers who seek to obtain information or access to resources on your site make sure to keep their tracks hidden. They do this in order to utilise your site for as long as they can, and make sure to leave backdoors in inconspicuous file so that they can always gain access back to your site.

This is why the best way to stay safe is to have a solid disaster recovery plan in place. The prime element in such a plan, would definitely be a WordPress backup solution like BlogVault that is truly reliable, and an intelligent malware scanner+cleaner, like MalCare, that leaves no malicious code behind.

 

WordPress has become the most preferred content publishing platform online, and its popularity is continuously growing. For hackers, this means a bigger target with greater payoffs. Are you, as a WordPress site owner committing basic security mistakes that make it easier for them?

 

Common mistakes Website owners make

 

WordPress is the most popular platform to build websites on, and its popularity has only been growing. The CMS has something to offer anyone who has ever wanted to own a website. The WordPress community is supportive, and consists of developers who can build anything in code as well as code-averse site-owners who are given a world of add-ons to make their sites extensible, and more functional.

 

However, maintaining a WordPress site comes with a number of caveats, which are difficult to navigate. The case is worse for new site-owners, since committing a small mistake could knock their site offline, or make it vulnerable to hackers’ attacks.

 

Knowing the common mistakes made, and avoiding them, is key to keeping your WordPress site safer. This is why we’ve come up with a list of the basic security mistakes that WordPress site owners and users make. Are you making any of these mistakes currently?

 

1. Not updating WordPress and its add-ons

Now while the rest of our list talks about mistakes to definitely avoid committing, this issue is a little more complicated. This is why we’ve chosen to get this out of the way right in the beginning.

Everybody talks about keeping WordPress Core and add-ons (themes and plugins) up-to-date, for the sake of security, as well as to add new features to the site. However, you as a WordPress site owner, have one good reason for not doing so– incompatibility.

Your WordPress site could break because of:

Updating WordPress Core

There are two kinds of updates on WordPress Core that keep it up-to-date with the best features, and security measures on the web.

  • Major updates (like 4.5 or 4.6): These add new features and functionality to WordPress.
  • Minor releases like Release 4.5.1 and 4.5.2: These are dedicated to security patches, and bug fixes.

There are a couple of catches with these releases. For one, it can be cumbersome to keep up to date with all of them. Version 4.5, for example, was released on April 12, while 4.5.1 was released 14 days later, and 4.5.2 was released about 10 days after 4.5.1. Secondly, while WordPress Core upgrades are designed to be compatible with all the previous versions; (even the first one), it doesn’t always work out that way. So when WordPress site owners update their WordPress core, their site crashes.

Updating WordPress add-ons (plugins, themes, and widgets)

There a number of problems you could run into while updating WordPress add-ons. Since the developers could be pressed for time or not have the expertise, they can’t make sure that their updates are compatible with every single version of WordPress. As a result, they could be incompatible with previous updates of WordPress Core. Moreover, even add-ons that are coded to be backward compatible might not be developed with other add-ons in mind. Lastly, add-ons’ updates contain significant security patches and bug fixes, which change the way they work and hence cause conflicts. One example of this was the security patch for RevSlider (a premium carousel plugin), that changed the way the plugin worked.

As a result, updating even just one plugins could cause your site to break. If compatibility issues between WordPress Core and an add-on are a concern, the safest route to take, would be to ask the plugin developer to release an update for the plugin, while also looking for alternatives that work with your other add-ons.

The key to keeping your WordPress site secure, is to update every part of your WordPress site. The consequences to your site, its data, and your site’s visitors are all too great to not update.

 

2. Buying/using bad add-ons

As mentioned, WordPress add-ons don’t necessarily have the stringent code quality or security measures in place that WordPress Core does.This is why it’s important for WordPress users and site owners to pay attention to pick a good theme/plugin. Every good add-on has one basic characteristic– it has has good code. But even if you don’t know how to judge the code of a theme/plugin, there are a few characteristics which you spot:

  1. They’re available via a reputed source: This means they’re on the WordPress.org repository, or with well-known theme/plugin seller, like Themeforest, Elegant themes, etc. Just as with material goods, buyers should be wary of a premium theme being available on a questionable website at a huge discount.
  2. They have good reviews and ratings from genuine, long-time users.
  3. They’ve stood the test of time: The longer a theme or plugin has been available, the more bug fixes and security updates they should have.
  4. They get updated often and have been recently updated (in the past 2 months) from the developer’s side

Installing a bad theme/plugin could have a number of consequences for your site, whether in a way that affects function (such as slowing down your site), or in a malicious way, such as sending spam mail on your site’s behalf. Apart from all this, having an add-on with malicious code on your site causes search engines to mark your site as malicious, and hence blacklisted.

 

3. Using bad login practices

There are a number of simple login mistakes that WordPress site owners make, from sticking with easy to guess credentials, to staying logged in on their sites. This makes it easier for hackers, who usually use bots (just like search engine crawler bots), to look for websites with vulnerabilities.

Sticking with the default username (admin) reduces the time bots need to crack your login credentials, by 50%. Combining that with the use of a weak password only makes attacks on the login page (like a Brute Force attack, or a Dictionary attack) that much easier. Once the bots crack your login credentials, the hacker can login as you, and legitimately perform admin-level functions. This is why it’s important to enforce good login practices, and secure your WordPress login page. A couple of other simple ways (and there are more ways) to protect your login page are renaming the administrator account to reflect a different username. WordPress site owners have to look out for legitimate ways to harden their login page though– some widely recommended practices such as  moving your login page to a custom URL, are unnecessary, and can ruin your site’s user experience.

 

4. Making every contributor to the site an ‘administrator’

WordPress sites have different system users with different levels of access, in order to give the site owner the power to assign responsibilities to different users. This also serves as a way to give those with fewer responsibilities, the access to only specific areas they need access to. This principle (known as the Principle of Least Privilege), is one of the basic elements of security on any system.

WordPress has five different user roles:

  1. Super admin or Admin: Has full control over add-ons, content, files, and users on the site. (Super admin is someone who has Admin access over multiple sites, and controls the network administration for those sites too).
  2. Editor: Has full control over content and files, can publish anyone’s content, and is allowed to add script tags for formatting.
  3. Author: Can only create, modify, publish and delete their content.
  4. Contributor: Can only read, edit and delete content. No publication rights.
  5. Subscriber: Can only read content. No other rights

So say you run a successful news website or a blog with a regular guest blogger contributing once a month… You would best assign the guest blogger the role of  ‘Contributor’ or ‘Author’.

Assigning the ‘Admin’ role instead, however, will put your WordPress site at a greater risk. Just imagine what would happen if they deleted a post by another author, a plugin or even an Editor by mistake!

Giving users unrestricted access could also allow hackers to exploit your site more easily. A good example of this kind of damage, was how TechCrunch got hacked by OurMine, a commercial security group that hacks accounts to publicize their services. The site was hacked using one of its contributors’ accounts.

 

5. Being a hoarder

Keeping old add-ons and users presents a number of opportunities to hackers. As a site-owner, it is only natural to experiment with plugins and themes. In the process though, it is easy to forget about unused add-ons in your site’s repository. However, since you no longer use them, you also don’t update them. This opens up your site to a number of exploits.

Forgetting to delete old users (especially contributors) long after they’re gone, allows hackers access your site legitimately after a previous hack (like a Brute Force attack). This is one of the ways WordPress site owners are hacked for a long time without even knowing about it.

 

6. Not checking past uploads

Similar to hoarding add-ons and users, WordPress site owners also fall in the trap of never cleaning out their Media Library, the uploads folder, or the includes folder.

Hackers know this too. This is why they could easily upload a hack-file that looks like an image, and execute a hack later. This is how a number of exploits on the TimThumb vulnerability were carried out.

This method could also be used to create a backdoor. So even if malicious code is removed, and the WordPress site is kept up to date, it will still be susceptible to hacks.

 

7. Not having a reliable backup solution to depend on

Having a backup solution for your WordPress site is paramount to security. Not only does having a clean backup of your WordPress site make it easier to restore your site in case of a hack or blacklisting, it also allows you to scan your site’s code for irregularities and fire-fight more efficiently. However, most WordPress site owners don’t realize that the solutions they’re relying on are not dependable, until it’s too late. Backups must be the perfect disaster recovery solution, so they should be fool-proof, and adhere to the best WordPress security practices. Not only should they be independent of the WordPress hosting service, but they should be independent of your site, be stored in multiple locations, and have both: WordPress files and database encrypted and backed up.

If your site encounters a problem caused by anything as disastrous as your hosting provider being hacked to the deletion of files, not having a good backup plan would lead to your site experiencing a long downtime or worse.

 

The mistakes listed in this article are basic, and yet widely committed by WordPress site owners. Keeping your WordPress site secure lies not in being sure of impenetrability (because there is no such thing as a perfectly secure site), but in making it harder for hackers to achieve their target.

 

If you commit, or have committed any of these simple mistakes in the past, the best way to ensure that there is no malicious code on your site, would be to invest in an intelligent auto hack cleaner for WordPress sites, like MalCare.

 

WordPress website owners are always cautioned to keep their installations of WordPress, plugins and themes up to date. But when a plugin hasn’t been maintained or updated from the developer’s end, potential exploits threaten everyone who has it installed.

Being someone who grew up in the 90’s, I still love video and audio cassettes. But as the world progressed to new technologies, the companies making the cassettes kept updating their technologies and methods too, and for good reason. No matter how I loved the uniqueness of magnetic tape, even I understood that it had its faults. It was time to move on.

 

The charm of old cassettes lingers

 

Most of the time, WordPress works in the same way too. The minute a problem is identified, developers work to release a fix for it, whether it’s an add-on or something on WordPress core.

This is why almost every piece of advice on the internet about ‘security practices for WordPress’ always first mentions that WordPress site users have to update every element on their site.

But what does one do when the technology itself isn’t updated, and after a vulnerability has been reported? The possibilities this opens up to hackers, are endless, which makes this a particularly alarming situation.

What makes it worse, is the fact that not many novice WordPress site owners know what to do when a plugin/theme/widget hasn’t been updated from the developer’s side. This became the most relevant, when El Rincón de Zerial’s security blog reported a cross-site scripting vulnerability in W3 Total Cache, at the end of September.

About W3 Total Cache

W3 Total Cache is a WordPress caching plugin that helps sites load faster. A website’s load time, as any website owner knows, affects its reputation, views, and business. The faster it loads, the better it is perceived by its visitors. This is why caching plugins are so widely used in the WordPress community.

W3 Total Cache in particular, had over 1 million active installs when the vulnerability was declared.

 

A screenshot of W3Total Cache from https://www.w3-edge.com
A screenshot of W3Total Cache from the W3 Edge website

 

This was because it had features that made it considerably better than other caching plugins, according to those who used it. Not only did the plugin caches every aspect of the WordPress site, from the HTML elements to objects in WordPress sites’ database, it also cached mobile cache well. Most other caching plugins only cached the HTML elements of a page, making their performance considerably lower.

The plugin, according to its page on the WordPress.org repository, has been used and trusted by companies websites AT&T, mashable.com, and pearsonified.com, amongst others.

About W3 Total Cache’s vulnerability

When the XSS vulnerability was reported, users of the plugin had already been complaining about support-related issues for six months, and had received no response  from the team that had developed it.

To add to this, the previous major ‘update’ to the plugin was only a simple change that made sure the plugin was compatible with the then latest versions of WordPress. Understandably there was concern over the potential damage this vulnerability could wreak if it was exploited.

But this wasn’t the first time the plugin had displayed vulnerabilities. Just as with any other plugin, W3 Total Cache had its share of loopholes, that were sometimes exploited, as with the case of other caching plugins like WP Super Cache too.

The good news

The silver lining in this situation, was the fact that the original developers of the plugin released an update six days after the vulnerability was disclosed. And not only did the update feature a patch for not just this exploitable loophole, but also another four more that were disclosed by SecuPress. Moreover, it also introduced a number of new features.

The bad news

However, a number of users of the W3 Total Cache who updated their versions of the plugin have reported that it breaks their sites, or renders some features useless.

What to do in case of an outdated plugin

This brings us to the most important course of action. When faced with a plugin or theme that is obviously out of date:

  1. Disable the plugin/theme until an update addressing the vulnerability has been released
  2. If it’s not a premium plugin or theme, follow its support forum on WordPress.org
  3. If an update with the patch for the vulnerability takes more than 48 hours to come through since the vulnerability is announced, try and contact the developer informing them about the vulnerability and quoting your sources.
  4. In the meanwhile, try and find alternatives that are compatible with your site in order to keep your site fully functional.
  5. If the update takes more than a month to come through, you could ask the community if someone would like to adopt the theme/plugin. Obviously this procedure has steps that you will have to follow, after communicating the problem to both, the WordPress team, and the community.

This is why it’s important to always have a backup plan: you never know when a plugin is going to stop being updated.

After all, a number of contributors are developers who contribute to the community as a hobby. It takes a lot of time and effort to not only create a plugin, but to identify how to patch up vulnerabilities and do it according to the best security practices as well.
Moreover, when the plugin/theme is actually updated, you never know if it’s going to break your WordPress site. Reliable backup solutions that allow you to test your backups before they go live on your site, are not just an option in such cases… they’re a necessity.

 

When you run a WordPress website, it can be distressing and even annoying when visitors suggest that you might be hacked, based on their PC’s antivirus notifications. Here is why and how this happens.

One of the most harrowing experiences for any WordPress website owner, is that of getting hacked, especially when they don’t even know that they had been harboring malicious code. This is why it’s helpful to be aware beforehand, of the signs that your WordPress site has been hacked.

A very common sign of a hack nowadays, is that of visitors’ antivirus software (like Avast, Avira, Kaspersky, or Norton) flagging websites.

PC antiviruses can alert users of WordPress websites containing harmful code
PC antiviruses can alert users of WordPress websites containing harmful code

When this happens, it can be confusing to new website owners on WordPress because of the general idea that PC antiviruses can’t scan WordPress websites, and vice versa.

What most people don’t know, though, is that there are a number of PC antivirus softwares that also scan URLs of websites that users visit.

Most of the time this feature comes with the premium versions of antivirus software though.

Why do computer antivirus products scan websites?

First of all, these products don’t effectively scan the entirety of a WordPress website.

However, some antivirus solutions for personal computers have a feature called ‘URL Scanners’, to make sure that the user of the computer doesn’t get affected by malicious websites. These scanner check if URLs entered have been reported in the past for malicious code that could affect computers.

Avira Pro's URL Scanner protects users from malicious websites
Avira Pro’s URL Scanner protects users from malicious websites

Even innocent-looking websites could infect computers by an exploit called ‘drive-by-downloads’. These are malicious files that websites scam their visitors into downloading, such as a free game .exe file.

How do computer antivirus products scan websites for malware?

URL scanners examine web pages against a repository of reports of threats to see if they have had any instances of malware reported in the past.

Since companies producing antivirus softwares and security solutions need to keep updating their collection of malware signatures, their list is up to date. Resources like VirusTotal (a subsidiary of Google dedicated to scanning files and URLs), collaborate with these companies and aggregate the signatures to help keep the dataset relevant.

Signatures of antivirus solutions present on VirusTotal are updated every 15 minutes, so the latest datasets are always used. Since VirusTotal is also a free, online, public offering that helps scan files and URLs, every file and URL sent to VirusTotal is sent to antivirus and security companies to help them keep up to date. When a signature is detected by one of the PC antivirus solutions that collaborate with VirusTotal, it is, by default, sent to all the collaborators (67 in total for URL scanners), that do not detect the resource. These signatures are also stored in a database, that all premium collaborators are given access to.

What to do once a PC antivirus flags your website

Once your website has been flagged, it is best to take the following steps:

Step 1: Update your WordPress website

Outdated versions of WordPress core, themes, or plugins could all have vulnerabilities, one of which the hacker might have exploited. However, there are chances that updating these elements might break your site. This takes us to our next step.

Step 2: Invest in an intelligent WordPress malware scanner and cleaner

This step is crucial. Selecting a solution in this regard that works to efficiently scans for hacks and removes malicious code would save you a lot of trouble. However, it’s important to make sure that this solution doesn’t report false positives, and yet doesn’t miss any malware.

Step 3: Invest in a reliable WordPress backup solution

It is important that you invest in a robust, dependable WordPress backup solution. This way, once your site is clean, you can back your site up, before experimenting with updated versions of WordPress core, themes, or plugins that have lesser vulnerabilities.

 

It can be distressing to hear from visitors to your site that you might be hacked. However, hacks and malicious code cause more damage with time. It is important to act on this information as quickly as possible.

Hacks catch WordPress site owners by surprise since they are carried out discreetly to exploit websites’ resources. The Pharma hack makes use of your website’s search rankings. Do you know how to get rid of it?

Over the past couple of weeks, we’ve been covering some of the ill-effects of being hacked, and how to recognise a hack. In that progression, one of the most discreet ways hackers use your site, is via Black Hat SEO techniques.  Black HAT SEO hacks make use of the legitimate links and content on your site, so cleaning them up requires expertise, and time.

What is Black Hat SEO?

In short, Black Hat SEO (also known as ‘spamdexing’) is an exploit of a vulnerability on your website where attackers target your highest-ranking pages. Hackers perform this bad SEO practice so their websites gain easy traction from your website’s search engine ranking.

Attackers first identify the high-ranking pages on your website. They then insert their links into those pages, and hence hijack these rankings to affect their websites. The malicious content isn’t seen on the front-end of the affected websites, but is visible to search engines.

However, in the long run, this poisons your site’s ranking.

The WordPress Pharma hack poisons your website search engine ranking
The WordPress Pharma hack poisons your website search engine ranking

Not only does your website rank lower… since these methods go against search engine guidelines, there is a high possibility of your website getting blacklisted too. This doesn’t matter to the hackers because they’re looking for a quick way to boost their website ranking instead of putting in the hard work for it. Once your website has been blacklisted, they’ll perform the same SEO hack on another website to maintain their ranking.

One of the most well-known ways Black Hat SEO affects WordPress sites, is via an exploit called the Pharma Hack.

What is the WordPress Pharma Hack?

The WordPress Pharma hack is an exploit of a website’s vulnerabilities to display pharmaceutical products along with the actual site’s pages or products on the search page. Since this is an exploit that uses Black Hat SEO, these pharmaceutical products don’t display on or affect the actual pages of the website. Instead, the website ranks lower on search engines’ results.

Why does it take so long to detect?

When we say that the spam links and content isn’t visible to users, we mean that it only shows up when someone looks for the site on Google. The description beneath the link to the website will show something related to the pharmaceutical products from the hacker’s site.

Even if you (the admin) of the site looks through the HTML source code, you won’t find the spam links or content.

This is because the malicious content is disguised and placed in your WordPress blog’s plugin folders, and in your database.

Since the exploit only affects the highest ranking pages and not all the pages on the site, it becomes more difficult to find.

How does it work?

Most of the time, hack files (malicious code) is encoded, or named to look like legitimate WordPress files. For example, if the Akismet plugin has hack files, they could be named “akismet.cache.php” instead of “akismet.gif”, “akismet.php” or “readme.txt” (which are the only three files that an uninfected Akismet folder has). Similarly, any file outside of the default files available with your original WordPress plugin install should be looked at closely, since they could be hack files.

With the WordPress Pharma hack though, the hack files are encoded (sometimes backwards), and are injected into the plugins folder.

The malicious code pings Google with requests for the list of highest ranking pages on your website. It then stores this information in its database, and targets them when it runs.

How to clean up the WordPress Pharma Hack

  1. Go through your plugins folder using your FTP client.
  2. Make sure your viewing options are set to show hidden files.
  3. Check directories of every active plugin on your website.
  4. Look for files that have encoded names.
  5. Once you find the hack files, it is important that you delete them. This will get rid of the symptoms of the hack. However, you will have to remove the malicious files in your database too in order to get rid of the hack from the root.
  6. Before you tamper with any database file, it is recommended that you backup your WordPress site so that any change you make to your site isn’t permanent. This way, even if you make a fatal mistake, you can rollback changes and go back to a working version of your site.
  7. Deleting the rogue functions in your WordPress database will need some technical expertise: you will have to access phpMyAdmin, and delete the database entries that contain malicious code. If this step is not done, the consequences of the hack will still prevail.
    The easier option to manually looking for and deleting presumed hack files, would obviously be to use an intelligent hack scanner and cleaner that doesn’t raise false alarms, and yet doesn’t miss malicious code.

 

Black Hat SEO hacks, and other SEO spam is difficult to remove from your site. What’s worse is that if you get blacklisted by search engines like Google for it, requesting for a review, and getting reviewed for this kind of exploit takes the longest time to process, out of all the types of hack review requests. This is why time is of the essence in attacks like the WordPress Pharma Hack.
Efficient hack scanning and cleaning systems that require technical assistance, take up to 12 hours to clean up malicious code, but the question is whether you can afford that time. This is why it’s important to use an efficient, automated malware scanner and hack cleaner.

XML-RPC is a WordPress API that allows WordPress site-owners functionality, while on-the-go. But how does it affect WordPress sites’ security?

XML-RPC attack_WordPress mobile

What is XML-RPC, and why is it such a big deal?

The ‘XML-RPC’ is an API that enables developers create WordPress ‘apps’ (like clients, plugins and themes), that allow you to make remote HTTP requests to your WordPress site.

This means, as a WordPress site owner, if you used a plugin or client that had WordPress XML-RPC support, you would be able to perform a number of functions without actually logging in to your WordPress site.

Some of the functions you would be able to perform on your site with these plugins or clients would include:

  1. Post-related functions like creation, publication, edition and deletion
  2. Media-related functions that include uploading files, and viewing the media library
  3. User-related functions, such as editing your profile, getting a list of authors for a post, etc.
  4. Comment-related functions such as listing comments, and editing them

There are a number of Weblog Clients and WordPress plugins that allow you to do this. Some of the popular ones include the Jetpack plugin for WordPress.org, clients like rubypress, and WordPress Sharp; and even WordPress’ own app for both Android and iOS. Since all of these functionalities make life easier, WordPress has had XML-RPC enabled by default, since WordPress 3.5. (WordPress’ latest update was WordPress 4.6, so it’s been a while). Obviously these tools would still need you to input your WordPress admin username and password for them to work, so they seem safe.

How does it pose a security risk?

However,  anyone can use the XML-RPC API to make these requests. Using the API, a script can make multiple requests simultaneously to your site. This makes it a convenient choice for attackers who would want to launch a attacks against your site.

One application for this functionality, would be to try with different combinations of usernames and passwords while having substantially lower chances of getting detected. This makes XML-RPC  an ideal approach for Brute Force attacks.

Unlike hacks that focus on vulnerabilities in software, a Brute Force Attack aims at being the simplest kind of method to gain access to a site: it tries usernames and passwords, over and over again, until it gets in. Often deemed ‘inelegant’, they can be very successful when people use passwords like ‘123456’ and usernames like ‘admin.’

Even if you have passwords consisting of a minimum of 10-15 alphanumeric characters and special characters, there is one more threat – DDoS.

DDoS is a type of Denial Of Service (DOS) attack where many infected websites or systems are used to attack a single website and bring it down, by overwhelming the target website with requests. This results in the website’s server denying service, as a result of shutting down (… hence the term).

Actually, in March 2014, a number of WordPress sites experienced an attack involving ‘pingback’. Pingback, is an XML-RPC functionality (especially on WordPress), that allows you to see where links to your WordPress posts are used. This is done by the sites with shared links pinging the source of the link. The source site then replies (or pings them back) with the live link (so that if the post is taken down, it would show you a ‘404 error’, or if it’s been updated, the newer version of the post would be displayed). So when attackers used XML-RPC requests to perform the DDoS attack in 2014, they exploited the pingback functionality, and used thousands of other sites to ping victim sites. Once all the thousand sites starts pinging the victim site simultaneously, the server ran out of resources and the site went down.

Do you have to disable XML-RPC?

Well, it depends. WordPress identified the XML-RPC API abuse, and has made its laws stricter. Plugins like Akismet that help detect spam, have also gotten better at detecting attacks like the one involving pingback. But the bottom line is that there is no way to make your WordPress site 100% attack-proof.

So yes, an easy way to make your site safer, would be to disable the XML-RPC API. For this, one can use  security plugins, such as iThemes Security (formerly Better WP Security), or NinjaFirewall.

However, before making this choice,it is very important to understand that turning this API off can affect the functionality of some plugins and apps that you might be using in conjunction with WordPress. This will disable the WordPress mobile app and severely affect the functionality of plugins like Jetpack, from accessing your site.

This is why it’s always important to have several backups of your WordPress site before you test the change to see if you’re okay with it. If you’d rather keep the functionality on, you can choose from a previous version of your site, and roll back changes to a fully-functional version of your site.

Making an integral change to your site is never easy, but it’s always better when you have all the facts. Which choice have you gone with, on your WordPress site? Let us know in the comments!

Remote/Local File Inclusions are common attacks on WordPress sites. However, it is Arbitrary Code Execution, that actually does the real damage to your site. Inclusion attacks are generally used in tandem with Code Execution, and learning how they work is key to preventing them.

We’ve been in the WordPress site recovery business for a while now. Over the years, we’ve had a number of our customers come to us with questions about their websites when they noticed something weird, or in the most severe cases, when they lost admin access. We’d try to help out, and most of the time, discover that their site was hacked.

One of the most lethal ways WordPress sites get hacked, in our observation, has been via file inclusion and code execution.

We’ve covered the same attacks and their most well-known approached in a previous piece about the most common attacks on WordPress sites, but with this piece, we hope to help you understand it in a little more detail.

To understand how these attacks work, one of the first things you must be aware of, is they involve PHP code. This is because PHP is a language that servers run on, and it’s also what WordPress is built on. PHP files aren’t just files; they’re executable code. This means that if you have a PHP file and you just access it on your WordPress site, it runs the code it contains.

This is why File Inclusion and Code Execution attacks go hand-in-hand. Once an attacker gets an infected PHP file to your website’s server and runs it, they could use it to do anything with your website.

File Inclusion and Code Execution attacks make your website a puppet in the hands of the attacker
File Inclusion and Code Execution attacks make your WordPress site a puppet in the hands of the attacker

WordPress plugins allow for File Inclusions in order to ‘include’ (or refer to) files on, or outside of the website’s server.

  • Any file that is included from outside your website’s server is said to be ‘remote’. This means even you, as the website admin, access your website remotely… since you’re not accessing it from within the server.
  • Any file that’s included from within your website’s server itself (like the files in your website’s database, or files like wp-config.) is known as a ‘local’ file.

The problem arises when plugins that allow website admins and users to access files (remotely, or locally) exhibit loopholes. These loopholes are exploited by hackers to include malicious files, that can be used to hijack the website’s server. However, simply including a static file (one that doesn’t execute code, e.g. a JPEG file) doesn’t cause damage. This is why most File Inclusion attacks involve PHP files.

Although both Remote and Local File Inclusion attacks have technical differences, both of them are used to perform Arbitrary Code Execution. This is what allows hackers to run their bad code on your server, and take control of it.

So in short, this is how these attack works:

  1. Access: First an attacker would need to get a vulnerable site to ‘include’ a malicious PHP file. This could be done directly (which would need access to your site’s server), or via a WordPress plugin that allows users to ‘include’ files from other locations. Obviously this is a very dangerous situation, especially for any website that allows files to be included without first validating the kind of files accepted.
  2. Execution: Once file is uploaded, the attacker could just access the file to execute it.

Remote File Inclusion

Websites that allow for Remote File Inclusion usually have a way to check where the file came from. Most of the time, they have a whitelist of websites; only files from these URLs are allowed, and others aren’t.

Here is the general process of an Remote File Inclusion attack:

The life-cycle of a Remote File Inclusion attack
The life-cycle of a Remote File Inclusion attack

 

One of the most famous examples of a Remote File Inclusion exploit combined with Arbitrary Code Execution, was that of a WordPress plugin called TimThumb. TimThumb was used to edit pictures on the fly, without having to open an image editor. Understandably, a lot of websites used it in implementing thumbnail-size images for their users’ avatars. TimThumb’s whitelist consisted of a number of image-hosting websites (like flickr.com and imgur.com). However, the vulnerability in the plugin was that it didn’t verify if the file URLs actually came from those locations: It only checked the words in the URL (or strings) to see if the images looked like they came from a whitelisted site.

Here’s how the TimThumb exploit took place:

A generic example to demonstrate how the TimThumb attack took place
A generic example to demonstrate how the TimThumb attack took place

Once the attacker executed the malicious file on the server, the damage caused depended on what the file was created to do. Since TimThumb was such a widely used plugin, millions of sites were affected.

Local File Inclusion

Local File Inclusion is a little more complex than Remote File Inclusion, because an attacker has to first create an executable, malicious file on the website’s server environment. This is mostly done by exploiting another vulnerability on the website (say one that allows SQL Injection), by which the hacker can access the website’s server. Once the hacker accesses the server, they can do anything, even override controls to make sure that a malicious file can be created on the server, or uploaded to it. The file can then be executed by just accessing it.

Recently, this vulnerability was observed on the Easy Forms for MailChimp WordPress plugin (v 6.0.5.5). The plugin allowed unlimited forms to be added to WordPress sites, of many different formats. However, the its vulnerability allowed an attacker to upload a PHP file using these forms. Once this was done, the file would get stored locally on the website. The attacker could then execute the arbitrary code.

Arbitrary Code Execution

A hacker’s aim in both File Inclusion attacks, is to execute arbitrary code on the website’s server.

Arbitrary Code Execution though, doesn’t have to only start with File Inclusion including files… in fact a lot of attacks (like Injection attacks) could be used in conjunction with running code arbitrarily.

One way that Arbitrary Code Execution was exhibited, was via WordPress plugins that cache dynamic content, like WP Super Cache. Plugins like these help reduce WordPress sites’ load times for visitors. One of the ways this is achieved, is by using special tags to tell the difference between static content (content on the site that doesn’t change), from dynamic content (that is executed server-side, and is interactive).

Here is how the attack worked:

How Arbitrary Code Execution took place in conjunction with SQL injection via a vulnerability on WP Super Cache
How Arbitrary Code Execution took place in conjunction with SQL injection via a vulnerability on WP Super Cache

While this is only one way hackers were able to execute code arbitrarily on the website’s server, there are a variety of ways to achieve the same result. The reason hacks have become more complex, is because hackers keep modifying how they way they exploit vulnerabilities.

There are a few ways to secure your site though. One way is to modify your WordPress site’s .htaccess files to prevent uploaded PHP files from being executed, and to update your themes and plugins. Another way is and to employ good security measures, like a WordPress firewall, or an intelligent antivirus.