Cloudways Isn’t a Great Option For Hosting a Magento Website if You Want to Be Able to Upgrade It

We were recently hired to do a Magento upgrade of a website hosted with a web host named Cloudways. Our experience with what they were providing and their support when what they provide doesn’t work was bad. That is despite claiming to provide the best managed Magento hosting platform:

Experience faster than ever Magento cloud hosting designed with a fully optimized stack for the best performance, reliability, and security, with 24/7 active support.

The most serious issues was the first big one we ran into. While working on the test of the upgrade, running the update command for Composer managed to cause the server to hang, and it had to be restarted. That shouldn’t happen and being able to run that command is a core part of the upgrade process, so that was a big problem. When the server was restarted, it had a different issue with hanging.

Cloudway’s support was no help in trying to understand what caused the initial hang or how it could be avoided. Instead, they simply suggested running it again and monitoring what happened.

Further usage of the command produced inconsistent results. In some cases, running it errored out and others ran without issue. That isn’t ideal when trying to handle doing an upgrade, where you are trying to carefully manage things.

Whatever is the underlying problem with their server environment and Composer, in our limited experience it didn’t just impact upgrades. After the upgrade, our client was trying to install a new extension through Composer and that also failed because a lack of “memory or swap”. Re-running the process later ran without issue.

An entry on Cloudway’s user suggestion forum indicates that people have been experiencing issues with taking basic actions through Composer since at least 2016.

Book Review: Web Security for Developers

The need for better security for websites isn’t debatable and No Starch Press, the publisher of the book Web Security for Developers, sums up the book in a way that suggests it can help developers to improve that:

Web Security for Developers will teach you how your websites are vulnerable to attack and how to protect them. Each chapter breaks down a major security vulnerability and explores a real-world attack, coupled with plenty of code to show you both the vulnerability and the fix.

The book unfortunately doesn’t really deliver on that. While the book provides an easy to read overview of web security, which could be a really useful resource, the author doesn’t really seem to have a great grasp of real world security. That leads to a situation where the advice provided is sometimes glaringly bad and basic security measures go mentioned.

As an example of the first issue, the author at one point claims that developers of lower-level software used to create websites “have strong incentive to stay on top of security vulnerabilities”:

Experts in their field write each of these dependencies, saving you the burden of having to write your own memory management or low-level TCP semantics. These experts also have a strong incentive to stay on top of security vulnerabilities and issue patches as they arise, so you should take advantage of the resources they provide!

If that were the case, then software wouldn’t be as insecure as it is. The author would seem to understand that, at least to a degree, as the very next paragraph mentions need to keep updating software to avoid some of the vulnerabilities that exist in the software:

A secure SDLC should include a process for reviewing third-party libraries and determining when patches need to be applied. This often needs to happen outside the regular development cycle, since hackers won’t wait until your next scheduled release date to begin trying to exploit a security vulnerability.

Elsewhere in the book, the developer appears to lack of basic understanding of how hackers have worked for years, as it suggests that security through obscurity is useful:

When someone publishes a zero-day vulnerability for a software component, hackers will immediately scan for web servers running the vulnerable software in order to exploit the security hole. To protect yourself from such threats, you should ensure that your web server doesn’t leak information about the type of software stack you’re running on.

In reality, hackers have long tried to exploit vulnerabilities in software without first trying to find out if websites are using the software.

As an example of the second issue, basic security measures going mentioned, the book is oddly silent on sanitization and validation. For example, in a section on SQL injection attacks, it suggests using parametrized statements to avoid that, which is good advice, but then moves on the to defense in depth, which involves:

When it comes to preventing SQL injection, defense in depth means using bind parameters, but also taking additional steps to minimize the harm in case an attacker still finds a way to successfully execute injection attacks.

In between those things, sanitization and validation would be an obvious measure to take with the user input involved, but it goes unmentioned.

You end up with a book that it would be very hard to recommend, as it likely is to lead developers to having a really poor grasp of security. If the book could be redone with a coauthor that has a better understanding of security, the book could be a useful resource.

The author of the book describes a version hacksplaining.com:

Hacksplaining is now a book! Hacksplaining has partnered with No Starch Press put all your essential web security knowledge into dead-tree form.

Based on the book, that is a resource to avoid.

Sucuri Security’s Website Firewall (WAF) Caused Ecommerce Website to Lose Out on Sales

Security services like GoDaddy’s Sucuri Security not only often do a bad job at providing security, but they can also introduce other problems for those using them. One reoccurring issue we have run into is that these services have attached caching to cloud based website application firewalls (WAFs) that aren’t compatible with some of the websites using them.

That recently came up while we were working on a Zen Cart upgrade, where in addition to us having problems working in the admin area of the website, it was mentioned that people were unable to complete the checkout process and having items disappear from their shopping cart.

The people running the website didn’t have any idea of what was causing the problems, which isn’t a unique in this situation. It also is understandable, since there isn’t anything visible that would point to caching causing a problem and, and as was the case here, people running the websites often don’t even know that the caching was enabled.

In this case, it involved Sucuri Security’s WAF, which had put on to the website through another GoDaddy company, Media Temple.

Sucuri Security markets the caching as benefit of using their service, though it could be explained as much by it lowering their costs.

While they claim it is “Built for all platforms”, the reality is that it can cause serious problems. Sucuri Security could help to avoid that by not implementing it by default as they do and also implementing basic checking to make sure that it doesn’t get implemented on a website in a way that is known to not be compatible with the software running on it.

Review of Wordfence Response Shows It Is a Terrible Option For Getting a Hacked WordPress Website Cleaned Up

The popular WordPress security plugin Wordfence Security is marketed with the claim that it will protect websites from being hacked:

Powered by the constantly updated Threat Defense Feed, Wordfence Firewall stops you from getting hacked.

Despite that, the developer sells two very expensive services for dealing with websites that have been hacked while using that plugin. That seems like it should be a big red flag to avoid both the plugin and those services, but isn’t for many, which can have significant consequences. A recent review tells that story.

The review involves a website that was presumably hacked while using Wordfence’s plugin and then they were hired to deal with that:

Horrific (and non-existent) “emergency response”. We had two sites protected with the WordFence premium plugin. Both came up with white screens of death this morning, so we went to WordFence as a ‘trusted’ provider to hopefully help us get back online.

It isn’t actually clear based on the review that the website was hacked, as opposed to some other issue causing the website to be broken and have the “white screen of death shown”. Wordfence should have made sure that there really was a hack before taking any money to do a hack cleanup. We always do and we would recommend avoiding any provider that doesn’t.

Instead, they got this person to pay way too much for a hack cleanup through their Wordfence Response service:

We fell for their $950 (NINE HUNDRED AND FIFTY) dollar “emergency” response plan where they are supposed to dedicate some urgent resources for “mission critical” websites to get you back online fast.

That is significantly more than we charge for a WordPress hack cleanup and we are not the cheapest option.

For all that money, you are not getting a response in line with what is supposed to be provided. Instead, they only promise to get back to you within an hour and address the hack within 24 hours:

Wordfence Response is for mission-critical WordPress websites that require 24/7/365 security monitoring with a 1-hour response time and 24-hour remediation.

It usually only takes a few hours to handle a cleanup, so them getting it done within 24 hours isn’t a great result. Perhaps that is why they emphasize responding within an hour, since that makes it sound like a better service. The reviewer’s result, though, was worse than that:

It look over an hour for the representative to come back and tell us that because we had 4 other subdomains completely outside of public_html on the server, that we would have to pay FOUR MORE TIMES (yes, $4000 more) to get them to even start looking at it.

So it took over an hour to respond that the overpriced service was going to be even more expensive.

After agreeing to pay the outrageous sum, things didn’t even move forward:

SEVERAL HOURS LATER (now NINE HOURS) after the emergency ticket was crated, a new “Director of Information Technology” sends us an email that they can’t help us at all because there are plugins that have “obsufated code” in them and so they can’t help us. They don’t bother to even tell us what plugins (we suspect Membermouse, some plugins do this), or even offer to simply remove that plugin and continue their search and help.

Instead, they send that email and then ignore us. So now $5000 and 9 hours later we still have a broken site and no emergency response from Wordfence.

It isn’t uncommon to deal with legitimate obfuscated code on a hacked website. It makes things slightly more difficult, but when you are overcharging for hack cleanup to the degree Wordfence is, it wouldn’t be a real issue.

The description of their service has some other significant red flags. For example, here is how they describe the cleanup process:

When a security incident impacts your site, our team works directly with you and securely clones your site onto a forensic server. Safely away from your production website, our team analyzes the incident using tools, processes, and data that have taken years to develop. We find the attack vector, track down indicators of compromise, and remediate your site.

Beyond a slew of buzz-words, what they are describing is either not accurate or is going to produce bad results. Usually a key part of cleaning up the hack and trying to figure out how the website involves reviewing log files, so copy the website isn’t going to do anything for that. Also, they are not being honest about an important reality, which is often you can’t actually determine how the website was hacked or, to use their parlance, find the attack vector. Surely they must know that, but somehow as a security company they don’t feel that being honest with perspective customers is important. It really isn’t surprising to then hear the result once they have gotten people’s money.

Fresh Installs of WordPress Apparently Being Hacked Based on Public Disclosure From Let’s Encrypt

It’s long been a known issue that if you place a copy of WordPress on a publicly accessible website, but don’t configure it, hackers will eventually configure it, which gives them access to the website. This works because WordPress has no restrictions on configuring it once the files are loaded on the website and you can configure it with a database on another server, so you don’t need to have access to any existing logins for the website. This isn’t usually an issue since people upload WordPress and promptly configure it, but recent claims suggest that hackers have found a way to exploit this even in that type of situation.

Let’s Encrypt is a service that provides free SSL certificates. A message on their support forum described part of what appears to be going on here:

we found more sites, which was hacked very fastly after LE generated.
Our clients start installation after LE was green, but in meantime (max 15 minutes after LE) robot from 185.59.221.* come and use WP installation files to prepare hack. Days after – on all domain call malware script and start DDOS to IP from France. I think that it is because crt.sh is scanned.

A reply added further details and suggested that this part of a larger issue when it comes to hackers:

More likely they are directly polling the CT log servers, as the delay to detect new domains is much shorter. But yes, what you describe has been happening for a few years now. I see requests to paths like /.git/index within seconds of issuing new certificates!

The CT mentioned there refers to certificate transparency, which Let’s Encrypt describes this way:

Certificate Transparency (CT) is a system for logging and monitoring the issuance of TLS certificates. CT greatly enhances everyone’s ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, CT is rapidly becoming critical infrastructure.

A topic on the WordPress’ support forum includes more discussion of what is happening and a common denominator of a malicious file being added at /wp-includes/.query.php.

One solution to this would be for WordPress to change the installation process to require that the person doing the configuration has control of the website, say, by adding a file. That would make the installation more complicated, but that might not be a big issue these days, with many installs of WordPress being handled through automated systems.

Another possible solution would be for Let’s Encrypt to delay disclosing information on newly issued certificates, which would not only have an impact on this particular situation, but possibly work against what else they are trying to accomplish.

Among the promoted sponsors and funders of Let’s Encrypt shown on their homepage, is Automattic, the company closely tied to WordPress, and several web hosts that have an emphasis on WordPress:

 

A Malicious File in Your WordPress Site’s Uploads Directory Doesn’t Necessarily Mean It Is Infected

Before we take on a hack cleanup of a WordPress website, we always want to make sure the website is actually hacked. That is important for an ethical security provider because in many instances where there is a belief or a claim that a WordPress website is infected with malware or otherwise infected, that turns out to not be the case.

Recently we had someone contact us that had a security company connected with their web host tell them their website contained malware. When they asked their web host to recheck things, the web host didn’t find what the security company claimed was there, but did find another issue. We were then contacted about the situation and could identify that there wasn’t an infection, but instead, what looked to be a failed hacking attempt 7 years ago.

What the web host identified was the location of a file and some sort of malware identity label, which won’t mean much to a lot of people:

/home1/[redacted]//wp-content/uploads/2015/01/aboudrar.php_.pdf: SL-PHP-SHELL-lt.UNOFFICIAL FOUND

The first part of is the path to the website on the server:

/home1/[redacted]/

Next up is the location where WordPress stores files being uploaded:

/wp-content/uploads/

The next part is the year and month the file would have been uploaded if done through WordPress’ media uploader:

/2015/01/

In most situation where a website has been hacked, it is possible for an attacker to add files in any location on the website, so malicious files could be in that location. But the name of the file indicates that this was uploaded through and WordPress’ security came in to play. The file name is:

aboudrar.php_.pdf

The underscore in the inner file extension very likely would have been added by WordPress. The reason for that is in certain server configurations, the file is processed based on each file extension, instead of just the last. If the file was processed using the inner file extension, .php, then any code in the file could run. By adding the underscore, that is stopped from happening.

What looks to have happened based on that information, is that in January 2015 a malicious file was uploaded, but WordPress restricted it from being able to infect the website.

A takeaway from this is that bringing someone knowledgeable about security can avoid doing an unnecessary hack cleanup. Also, if a security company offering to do hack cleanups without first assessing the situation, you would be best off finding someone else to help you.

Backups Made With WordPress Plugins Might Not Back Up All of Your Website

When it comes to dealing with a hacked website, one of the recommended solutions is to revert the website to a clean backup. There are multiple possible issues with that, including not knowing whether a backup is clean or not, as well as that reverting to a backup doesn’t resolve the underlying issue that caused the hack in the first place.

Another problem we noticed while dealing with a recent clean up of a hacked WordPress website is that backup plugins for WordPress don’t necessarily backup of all the website if there is content that isn’t handled through WordPress. While that makes sense from the perspective of the backup plugin, it is something that is necessarily going to be thought by those using them, until they run into a problem that requires the backup.

Whether that situation applies to your website or not, it is a good idea to check to make sure that backups being made are complete, as you can also run into issues with backups being incomplete for other reasons.

Latest Versions of Moodle Contain Publicly Disclosed Authenticated SQL Injection and XSS Vulnerabilities

A week ago an authenticated SQL injection vulnerability and a cross-site scripting (XSS) vulnerability that exist in the latest version of Moodle was publicly disclosed. The post that was done in makes no mention of notifying the Moodle developers about the issue.

The vulnerabilities received more exposure in a article on a news outlet owned by the security company PortSwigger yesterday. Curiously, especially considering the owner of the news outlet, the post doesn’t address why the vulnerabilities appear to have been full disclosed, instead of being reported to developer first. That article does say that the author of it contacted Moodle:

The Daily Swig has reached out to Moodle to learn more and will update this article accordingly.

(That article also inaccurately states that the “bug appears to have been reported in a GitHub post from 2013”, when according the original post, that was when the vulnerabilities were introduced, not reported.)

So far the post hasn’t been updated with a response from Moodle.

We confirmed that the claims made about the authenticated SQL injection vulnerability and cross-site scripting (XSS) vulnerability are true with the most recent version of Moodle, 3.11.5. Based on when the vulnerabilities were introduced in to the code, they should also exist in the latest version of previous versions of Moodle that still receive security updates, 3.10.9 and 3.9.12.

To exploit this the attacker would need to be logged in to Moodle and be assigned to be a teacher of a course. The SQL injection vulnerability could be exploited to read the contents of Moodle’s database and the XSS vulnerability to cause malicious JavaScript code to be shown one pages on the website.

We contacted Moodle’s security team yesterday to make sure they were aware of this.

While we don’t know why the discloser appears not to have notified them, we found that the form they provide for reporting security issues problematic and could turn people away from reporting issue to them. As one example of that, the form includes several hard to understand items. Including one wanting to the know “Target”:

With the two options provided being “bugcrowd.moodle.com (testing site)” and “Other”. We are really in contact with developers about security issues in their software and we are not sure what that is supposed to refer to.

At the end of their form is a quite strange item for someone simply trying to report a security issue, you have agree to terms and conditions of a company named Bugcrowd:

It isn’t explained why you should be need to do that or why that third-party should be involved in trying to address something with Moodle.

We noted those issues when we notified Moodle and hopefully they will get things improved, so that people are more likely to report issues to them first instead of publicly disclosing them.

If you have a Moodle website that has been hacked, we offer a service to help address that.

This Doesn’t Inspire Confidence in cPanel’s Understanding and Handling of Security

One problem that companies in the web security space have to deal with is the large volume of inaccurate security advice that is out there, much it coming from people that you should be able to rely on, including web security companies.

One company that you would hope that you could rely to provide accurate security information would be company behind the widely used cPanel web hosting control panel. That isn’t the case with something we ran across recently.

The answer to a Q&A question, “What is the anonymousfox address on my system? ” on their website starts out:

Anonymousfox is a WordPress vulnerability where users are able to exploit vulnerable WordPress plugins to get access to the account’s files on the system. While not an issue with the cPanel software, the attacker can gain access to that particular cPanel account by editing the contact address file and then resetting the account’s password.

It isn’t a great sign that WordPress is miss capitalized there, but the rest of that doesn’t even make sense. If the vulnerability is in a WordPress plugin, then it isn’t a vulnerability with WordPress, but with the plugin. Also, what is described there sounds like it isn’t a WordPress specific issue, as it sounds like an attacker that gains access to the website can change a cPanel account file, which wouldn’t be something that would be WordPress specific.

Skipping past a paragraph you see this:

There are excellent forums posts that have additional details you may want to read at the following links:

 

https://forums.cpanel.net/threads/question-and-tips-about-anonymousfox.677765/

If you follow that link you will find a cPanel employee wrote this:

This kind of activity can be achieved by a compromised password, script or plugin used on the site. It isn’t just WordPress related. I would strongly suggest you not only enlist the services of a qualified system administrator to audit your installations and security but you must identify the point of entry or the issue will continue to occur.

If you read through the rest of the information on that page, other people are stating they ran into the issue despite not using WordPress, so it is hard to understand how that is being cited and yet the information in it was ignored and the information provided in the answer is incorrect in the way it is.

What seems of more concern is that someone with just access to a website in the cPanel account could edit that file, a concern that was raised in comments on that linked page.

Do You Need to Worry About Being Hacked if WordPress is Warning of Use of an “Insecure” Version of PHP?

Recently we had someone hire us to clean up a hacked WordPress website where one of their concerns in regards to dealing with the situation was that they were being warned by WordPress that they were using an “insecure” version of PHP:

What that referred to was use of version 5.6.x of PHP, which is no longer supported, with the website.

While it is a good idea to keep software up to date and use supported versions, it also important to understand what risk there are and are not, when not doing that. Software that is outdated is not necessarily any more insecure than up to date software (as up to date software can, and in a lot of cases does, have vulnerabilities as well). More importantly, software that is insecure is often not insecure in a way that is likely to lead to a website being hacked.

With PHP, you have to go back to May of 2012 for an instance where there was a vulnerability that was fixed, which then had widespread exploit attempts. Even with that, the vulnerability was only exploitable on a subset of PHP installs, due to only being an issue with one particular setup.

That doesn’t mean that you don’t need to keep PHP up to date, but it does mean that if your website is hacked, unless a new equally serious vulnerability has been found in PHP, then the PHP version likely wasn’t part of the cause of the hack. It also means that when dealing with a hacked website you don’t need to rush to change the PHP version. Which is a good thing, since switching to a newer version could cause software that isn’t designed for it, to break.

As part of our hack cleanups of WordPress website, we can handle getting the software used on the website compatible with the newer version of PHP and the PHP version brought up to date (to the extent that isn’t something that the web host has to handle), as we did that website.