An Overview of Website Reinfection Vectors

The website security landscape is as complicated as it is treacherous. We often deal with clients who become reinfected over and over again. Once the attackers establish a foothold in an environment and recognize that a website is vulnerable, you can guarantee that they will be back to try to reinfect the website.

Our website firewall is designed to protect websites from attack and infection, but there are many different ways that attackers establish their presence into a compromised environment. A website firewall is but one aspect in a larger defense in-depth strategy to protect your website!

In this post I will review some of these other attack vectors and some ways that website owners can protect their sites from becoming reinfected.

First, let’s review how our web application firewall (WAF) works

Our firewall service acts as a reverse proxy. Essentially, it sits between the web server and acts as a sort of “gateway” for the traffic coming to your website. At its core it is a pretty straightforward concept: block bad traffic, allow good traffic. Attacks such as SQL injections, cross site scripting (XSS) and DDoS attacks will get blocked by our generic rules. Any known exploits against vulnerable website software such as plugins, themes and core files should also be blocked. However, our firewall is a very complicated product with a lot of different features! Let’s take a look at some of them:

Our firewall is designed to be platform agnostic. That is, it will work with any CMS platform. It doesn’t matter if your website is using WordPress, Magento, Joomla, OpenCart or any of the other CMS platforms available on the web; our firewall can be used to protect your website from attacks.

Different CMS platforms vary greatly from one another and work in very different ways. Since it is not specific to any platform, the basic firewall rules that apply across the board need to be generic enough to not interfere with the routine operations of normal website traffic. So, out-of-the-box it should be tailored to your website and the CMS it is based on to improve security!

Different CMS platforms have different admin panel URLs and the firewall needs to be configured to work with your website. Firewall options like the following:

Admin panel restricted to only Allowed IP addresses

Are not enabled by default for this reason. If you want the firewall to improve the security of your admin panel the URL should be added into the access control settings:

Moreover, if your website contains a vulnerable upload form or ability to upload potentially malicious content, then this needs to be enabled manually as well in the advanced security settings:

Stop upload of PHP or executable content

You and/or your website developer should review the security and access control settings within the firewall configuration to determine the most robust configuration that isn’t going to interfere with normal operations. If you aren’t sure how to do this, you can always submit a product support ticket and our analysts are happy to assist you with determining the optimum configuration for your website!

Exploring Different Attack Vectors

Websites can be attacked in many different ways. Not all malicious traffic is going to come through the firewall itself. Most notably, attacks can target the hosting IP itself, but there are many other aspects to the attack surface for an average website.

Bypass Prevention

One of the most overlooked aspects of our firewall is the presence of bypass prevention. Without adding some custom rules to the website’s .htaccess or NGINX configuration file the attackers can circumvent the firewall by attacking the host IP directly (if it is known). We need to ensure that all traffic coming to the website is being filtered by our firewall service. To do that this guide can be followed, or you can submit a ticket to our analysts to configure that for you!

Admin Panel Attacks

Attacks on website admin panels are tremendously common. By default admin login panels on CMS platforms are open to the world and at high risk of brute force attacks. Unless some third party security plugin or extension is installed on the website attackers will not face any issue trying thousands of passwords until they break their way in. It is one of the most common attacks that we see.

Many privilege escalation vulnerabilities have been found in the past. These allow  low-level “subscriber” accounts to maliciously execute “administrator” functions. Some vulnerabilities allow attackers to execute administrator operations without any account at all. It is crucial to keep all plugins, extensions and components up to date so that your website has minimal chance of being vulnerable in this way.

Our firewall should block these types of vulnerabilities, but we of course still recommend keeping your environment fully patched and up to date.

It is also very common for attackers to leave behind “rogue” admin accounts. This allows them to reinfect the website even after the malware is cleared from the website environment. These accounts must be removed in the wake of a compromise.

Our website firewall can go to great lengths to help protect your admin panel from abuse. As I mentioned earlier in this post, the firewall security and access control settings should be tailored to your specific website for optimum protection. We also have a WordPress hardening guide that covers some of the ways that WordPress website owners can help keep themselves safe even without our firewall.

Insecure Hosting Environments

Let’s take a look at some of the different ways that the hosting environment itself (rather than the websites) can lend itself to a compromise.

FTP/SFTP/SSH

Even the presence of firewall bypass prevention is not going to prevent attacks on the server itself, however. Most web servers allow for either FTP, SFTP or SSH traffic usually via ports 21/22. Most often this traffic is not restricted via IP address and is open to the world. This places these accounts at risk of brute force attacks and can be compromised, particularly if the passwords are weak. A compromised FTP/SFTP/SSH account will provide the attackers with complete control over the file structure and database.

Exactly how this traffic is handled varies from hosting provider to hosting provider. Typically they’d have some security software such as mod_security to help stem attackers, but no security is perfect. Some hosts require you to “unlock” FTP for a certain period of time, or allow only certain IP addresses to access the server using this method, but they are a small minority. Most often these network protocols are open to the world without any control from the hosting provider.

Make sure that all FTP or SFTP accounts have strong passwords. Ideally, the server should be restricted to only SSH key authentication and limited to only allowed IP addresses. This is markedly more secure than any password could ever be. However, depending on your host this may not be possible. If your website is hosted on an unmanaged Virtual Private Server (VPS) then the server security lands in your lap.

Cross-Site Contamination

One of the most frequent attack vectors that we run into is cross-site contamination. This is when multiple websites share the same hosting space. Using the default configuration settings in many environments will allow websites to infect each other and will all be as insecure as the weakest link. A single poor password on a single wp-admin panel can lead to an entire environment falling victim to a malware attack!

Insecure cPanel environments

Many website administrators have not one but many websites. These are often all configured as Addon Domains within a standard cPanel interface.

This is a popular way to add additional websites to your hosting plan because it is easy, convenient and (most of all) cheap! However, this is easily the most insecure way to host multiple websites. The problem with this configuration is that the website files for website A are going to be owned by the same user:group as websites B and C. The underlying PHP process will also run as the same user.

What does this mean? It means that if one website is infected then there is a huge risk that malware will spread to all the other websites hosted in the same cPanel. If website A is protected by our firewall but websites B and C are not then website A can still easily get infected.

If you are using cPanel with multiple websites, ideally these should be configured within WHM to each have their own separate, isolated cPanel environment.

Which brings us to our next attack vector…

Insecure WHM Environments

Another issue that we frequently see is cross site contamination through insecure WHM environments. Namely, WHM servers that do not have symlink protection enabled.

The default option for symlink protection is for it to be disabled. Enabling symlink protection will cause a modest performance decrease on the server but the security benefits far outweigh this cost. Having this option disabled renders the entire environment at risk of cross contamination, whether or not the file ownership and permissions are configured correctly and even if each website has a separate cPanel instance. The reason being is that attackers can move laterally through the network via the use of symbolic links. Some more aggressive infections (for example, the notorious AnonymousFox hack) specifically target this and actively exploit entire environments to spread malware, phishing and spam.

Compromised cPanel Account

We have seen some rather aggressive attacks that quickly reinfect cPanel environments. The way that they do this is very simple but effective!

If an attacker has write access to the files (ie: a compromised wp-admin administrator account with default WordPress settings) then they can edit the following files:

• .cpanel/contactinfo 
• /home/<user>/.contactemail

And place their own email inside. Once that is done all they need to do is request a password reset via email and voila! They’ve compromised the entire cPanel.

To maintain a secure WHM environment we recommend disabling password reset via email entirely!

Compromised Hosting Provider Account

Hosting accounts are not immune to compromise either, particularly if the password is weak or if two factor authentication (2FA) is not enabled. Most hosts provide a file manager type application to allow you to directly edit and modify files within the website environment. This is very useful for routine website administration and configuration, but like anything else, can also be misused by attackers to spread malware.

If your hosting provider account is compromised, the attackers can easily log in remotely and have full control over the environment. Most likely the attackers would start by uploading a webshell since their functionality far exceeds what most hosts provide to their clients.

Insecure Hosting Provider

Most hosting providers do a good job of maintaining their server security. They tend to have a dedicated security team making sure that all security patches and updates are installed to their servers and to ensure that the file/directory user:group permissions are all above board.

In some instances, however, we have seen hosting environments that have been completely misconfigured to give hosting accounts write access to all other hosting accounts on the server. Sometimes this has been a misconfiguration in the file structure. Other times, it is a misconfiguration in the database software. In either case it has led to repeated website compromises that had nothing to do with the website owners themselves at all.

Compromised Server

While thankfully rare, some exploits discovered in the past allow for full, remote takeover of a webserver at the root level. For example, in late 2019 a critical vulnerability was discovered in Exim, the default mail server software used in WHM and cPanel environments. This exploit allowed for both local and remote root-level privilege escalation. Many servers the world over, particularly poorly maintained VPS servers, were affected by this glaring flaw on the server backend. This left many website owners wondering how they were hacked in the first place.

Other Vectors of Compromise

Not all attack vectors are directly related to the websites or even the hosting environment. Let’s explore some other aspects of the attack surface!

Compromised Workstation or Browser

Another attack vector is the computer that you are sitting at this very second!

If a computer that is used to manage your website becomes compromised then it’s entirely possible for the attackers to use it as a reinfection vector. For example, if a keylogger trojan is installed into your workstation then it doesn’t matter how many times you change your website password, the attackers will always be able to authenticate into the environment. This is one of many reasons why enabling two factor authentication (2FA) on your administrator panel is highly recommended.

Malicious third party browser extensions have also been known to insert malicious javascript into WordPress posts and pages while the website administrator is logged into the admin interface and working on their website content.

Remote Database Administration

Most host environments do not allow for remote database administration, but there have certainly been instances where it has been enabled. This is particularly true of VPS servers that have not been configured properly.

Most often the database can only be modified through connections on the hosting server itself. However, if remote database administration is enabled this may allow the attackers to:

• Brute force the database password
• Remotely inject malware into the database

Sometimes web applications do require remote database administration. For example, if you wish to allow shopping cart or guestbook applications on other servers to access your databases. Typically, only the necessary IP address would be added to the allow list to do this. However, like all useful features, attackers can also abuse this by adding their own IP address to the allow list if they’re able to compromise the cPanel account. This can later be used to reinfect the website environment.

Compromised Repository

This is not as common on websites that use primarily open source code such as WordPress. However, it’s certainly not out of the realm of possibility that a software repository could be compromised and spread malware to any websites that deploy code from it.

It’s also worth mentioning that many extensions website owners use on their website are premium; that is to say, not open source and require payment to use. This software is developed by private companies and we have no way of knowing what goes on behind their closed doors, what their security policies are, or even if a compromise took place at all.

Nulled/Hacked Bootleg Extensions

To continue on the topic of compromised extensions or other software, this leads me to the topic of nulled/hacked extensions. Some premium extensions cost a fair bit of money and not all website owners have the income to shell out for certain software extensions. Instead of just using completely open source solutions some website owners take the naughty shortcut of downloading pirated versions of these plugins to use on their site.

As we have explored on our blog in the past this software almost always comes pre-loaded with backdoors, spam or other unwelcome guests.

Security Misconfiguration

Exposed sensitive files can also result in a website compromise. Certain files in CMS installations contain sensitive information like database credentials such as the following:

WordPress: ./wp-config.php

Joomla: ./configuration.php

Magento1: ./app/etc/local.xml

Magento2: ./app/etc/env.php

Drupal: ./sites/default/settings.php

Laravel Framework: ./.env

It’s not uncommon for website owners to create backups of these files on the server with names such as:

./wp-config.php.bak

This is a grave error as it exposes the database credentials to the world. Files with the .bak extension are not treated as PHP files and will be viewable in plain text to anybody poking around in places they shouldn’t be!

Phishing

Most often phishing attacks are seeking banking information, Facebook or Netflix logins. However, we have also seen phishing attacks that attempt to steal hosting account login information.

This is not the official GoDaddy website!

Thankfully, many hosting providers (and banks!) have taken the step of enabling two factor authentication (2FA) by default. This prevents any unauthorized user from logging into your account without physical access to your mobile device. This is a great step forward, although not all hosting providers have this feature enabled or even available.

Zero Day Exploit

And finally, every so often the discovery of a zero day exploit occurs in the wild. This is when a brand new vulnerability is discovered in a piece of software for which there is no available patch yet.

Depending on the type of exploit, our firewall may block it. For instance, SQL injections and cross site scripting attacks should be blocked no matter what. However, some more uncommon types of attacks may require the writing of a new firewall signature to block it. These new firewall rules need to be written by our engineers and go through quality assurance (QA) testing before they are deployed to our servers.

Security is an eternal game of cat and mouse between the defenders and attackers.

In Conclusion

As we have seen laid bare in this article: Website security is a complicated beast! There are many moving parts and the attack surface is broad to say the least. A website firewall is an excellent addition to any website owner’s security roster, but it should never be considered a panacea.

A proper everyday security posture is also an important procedure to be kept in mind to try to remain as secure as possible.

Remember, folks: There is no such thing as a perfectly secure system. Anybody who claims otherwise is either a liar or a fool.