Website Security

Bitsight/Google Study Finds That Security Controls That Are Easier to Measures Are Being Handled Worse

Considering the poor state of security, better understanding where companies need to improve their security could be very useful. A big problem with doing that is how can you measure that. That appears to be a problem with a study released in December from Bitsight and Google. That is well summed up with this chart from the report listing how computer software companies did in handling various controls of the Minimum Viable Secure Product (MVSP) framework:

They did worst on security headers, which is additional data sent along with web pages by web servers to web browsers instructed them to do or not do things. That is something that is easy to measure since if the website is publicly available, anyone can check those in an automated way.

The controls where they did best are ones that seem hard to measure easily and from the outside. The study states that information for those controls comes from information that has “been publicly disclosed”:

Security Incidents and Data Breaches provide evidence
of security incidents that have been publicly disclosed
and insight into incident management practices.

That creates a huge blind spot, as anything that isn’t publicly disclosed wouldn’t be measured.

It seems reasonable to think that there is a correlation between doing better at measures with limited ability to measure and doing worse with measures that are easy to measure, based on the failure rates of the various controls.

Another problem with this approach is that security headers offer little security value, as attackers can simple ignore them. By comparison, data handling and incident handling are critical to security. Having a measurement system that is more accurate with much less important things could provide a rather skewed view of how well companies are handling security on an individual basis, but also in comparison to other companies.

MalCare Customer Indirectly Warns It Fails to Protect Websites From Being Hacked

We recently were contacted with a strange request. Someone was asking us for a refund for a hack cleanup plan. We don’t have any such plans. We provide onetime cleanups and we only charge after the hack cleanup is completed. It turned out that the person had somehow run across a two-year-old post of ours warning about a provider named Malcare, titled MalCare Review: It’s Obvious They Are Taking Advantage of Their Customers, and then contacted us as if we were Malcare.

The request for a refund mentioned things that were in line with what we were warning about two years ago. They wrote this in part:

Your plan was not working out as planned. I am still cleaning up a lot of damage since my site was hacked, I had to resort to a different plan.

And this:

Looking at the backup you had on your site, the database was filled with numerous users, of which I did not know. I had to clean up my database manually.

After dealing with that, we were curious to see if other of their customers have been complaining about their service recently. What we saw was that people are still being misled by them in to believing that their service offers things it doesn’t, while another of their customers who are not criticizing the service refuted that.

Here is part of one recent customer review:

Definitely a game-changer for our websites. Full removal of hacks and complete protection from current and future attempts.

The customer obviously doesn’t know that it will actually offer complete protection from future hacking attempts. The service can’t do that, but everything we have seen it won’t even do a good job of the protection it could possibly offer. Don’t take our word for that. Here was part of another recent positive customer review:

MalCare and the team behind it have gone above and beyond their stated service to help me restore my website from malicious hacks of my WordPress website. On more than one occasion they were able to scan and clean my site of infected files. Anyone who has a website knows how horrible it feels to learn that your site has been hacked.

Based on that, their website has been hacked at least once while using MalCare’s service. If that wasn’t the case, they wouldn’t have been cleaning it up multiple times, unless they failed to properly clean it up the first time.

Continuing to Run Drupal 7 Isn’t Making Your Website Insecure Contrary to Claims by Abbacus Technologies and Prodigitude

In June 2020, Drupal announced that the end of support for Drupal 7 was being delayed until November 28, 2022. In February of this year, it was delayed until November 1, 2023. It might get delayed further:

We will announce by July 2023 whether we will extend Drupal 7 community support an additional year. Factors that we will consider are community support, Drupal 7 usage, and active Drupal 7 maintainers. Current support is made possible thanks to the many Drupal 7 maintainers and companies that are paying to support Drupal 7.

Despite that, websites running Drupal 7 have recently been getting emails from spammers promoting hiring them to migrate Drupal 7 websites with misleading claims, including about the security of Drupal 7.

One of that we recently reviewed had a sender email address from the domain name drupalupdates.com, which redirects to the website of a company named TEN7. But clicking a link in the email instead took you to the website of Abbacus Technologies. The email starts out with this statement:

Upgrade your Drupal Site as Drupal will quit supporting lower versions

As we already mentioned, Drupal 7 continues to be supported for more than a year. Eventually all versions of Drupal will no longer be supported, so the argument that you should migrate from Drupal 7 because support will eventually end, would also be an argument for not using any version of Drupal (or any software for that matter)

The email goes on to say this:

Better security – Your store will be more secure as many security loop holes are being covered in this updates.

It is unclear what “security loop holes” refers to, as that isn’t security terminology, but Drupal 7 continues to receive security updates if there are vulnerabilities found. If they want to claim that Drupal 7 is insecure in comparison to Drupal 9, we would love to see what, if any, evidence they could present to back that up.

A second email that we recently reviewed came from a company named Prodigitude. They at least were partially honest about support not ending soon:

Drupal 7 will reach its end-of-life in November 2023 which will leave your website vulnerable to cyberattacks, amongst other dangers.

They though also claimed that migrating to the new version of Drupal would secure it:

With the migration, your website will have security measures in place to ensure your website isn’t in danger of malfunctioning or at risk of hacking.

There isn’t an ability to make a website impervious to hacking by migrating to the new version of Drupal. It could still get hacked even if Drupal is up to date, if say, an unfixed vulnerability is discovered by a hacker. There are other ways that a website can be hacked that can’t be prevented by the software running on the website. Among those, the underlying server could be breached.

Securing a Drupal 7 Website

If you do want to ensure that a Drupal 7 website is secure against threats in Drupal, you do need to promptly apply security updates. If you haven’t been doing that, we offer a subscription upgrade service, where it only costs $1 for the first month, as we are confident you will want to keep using the service.

While it isn’t necessary to migrate to Drupal 9 from 7 at this time, if you do want to do that, we offer a service for handling the migration.

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.

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:

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.

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.

VaultPress Didn’t Protect Website From Being Hacked

Recently we had someone hire us to clean up a hacked WordPress website that mentioned that they had thought that the VaultPress service for WordPress they were using would protect their website. As they were already aware by that point, it hadn’t turned out to be true.

It is understandable that they might think that since this is what you see when you visit the homepage of the VaultPress website:

But the feature set listed in the lower portion of the homepage doesn’t make any mention of a feature that provides any protection against hacks, instead it indicates that it might detect you have already been hacked:

While detecting the aftereffects of a hack can be useful, it won’t protect the website from being hacked. Also, they don’t put forward evidence, much less, evidence from independent testing, that shows that the service is actually able to effectively detect malware. We wouldn’t recommend using a service like that if they are not providing evidence to support their claims (which means we recommend not using most security services at this time).

In this situation, the owner of the website became aware that the website was hacked because the search results for the website showed pharmaceutical spam, not from VaultPress.

HostGator and SiteLock Use a Raft of Falsehoods to Sell Unnecessary Security Service

When it comes to the selling of web security services, it is common for those to be sold using with clear falsehoods. We recently highlighted an example of that with a service called Malcare. But the breadth of the falsehoods that were used recently to get $300 out of a customer of the web host HostGator for a SiteLock service stands out.

The customer contacted HostGator support about dealing with the website not showing up as being secure despite a SSL certificate being purchased. They weren’t sure if they were then dealing with someone from SiteLock or HostGator, which sounds a bit odd, since you wouldn’t think that you would contact your web host and be transferred to another company, but that has at least in the past been the case of web hosts, like HostGator, who are partnered with SiteLock. The conversation they then had was described to us and it sounds in line with what have heard in the past and seen when provided transcripts of the conversions.

They were told that the website contained malware, when they responded that was the old website at different web host (they replacing everything because of the website being hacked), they were told that the malware was tied to the domain name and redeployed to the new website to find vulnerabilities. They were told that a firewall needed to be put on the website, for $300, to stop the website from being infected the way the old one was and that the Google search results would be cleaned. As to evidence of the claim of malware, they were pointed the search results for the website, which showed pharmaceutical spam.

There are a lot of falsehood packed in there, which include:

Google’s search results are not real time, so spam pages showing up there doesn’t necessarily mean there is anything at issue with current state of a website, unless they are from a crawl just done. Spam pages are also different than malware.

Even if there were spam pages, they wouldn’t cause the website to not be listed as secure, since that isn’t impacted by that. Potentially a hack could cause pages to not be secure, if say, they added code to existing pages that accesses a website over HTTP instead of HTTPS.

SiteLock couldn’t clean up Google’s results. If the website is still hacked, then cleaning that up would eventually lead to Google’s results no longer showing the spam pages. If it is clean now, then they would just need to wait for Google to refresh them.

Malware isn’t tied to a domain name. If someone is flagging the website as containing malware, that could be tied to the domain name, but that isn’t tied to it being listed as secure as far as we are aware, as that relates to something else.

If there are vulnerabilities, you would want to fix them, not put a firewall around the website, since among other things, there isn’t evidence that firewalls like SiteLock’s would actually effectively protect against those vulnerabilities and plenty that they wouldn’t. Also, hackers are always trying to exploit vulnerabilities on websites, that has nothing do with a domain name being tied to malware.

So almost nothing they said was true and none of it actually addressed the issue that support was being contacted about in the first place. You might think that conduct like this would have some repercussions, but right now neither journalists nor government regulators have shown an interest in it.

A Web Browser Listing a Website as “Not Secure” Doesn’t Mean It has Been Hacked or Contains Malware

In dealing with hacked websites, a lot of what we do isn’t the work of the hack cleanup, but explaining things. Recently the issue of web browsers’ messages about websites being “Not Secure” came up during a cleanup. With that limited detail it is easy enough to assume, after having had your website hacked, that warning refers to a security issue relating to hacking, maybe malware, but it doesn’t.

What additional information, if any, is provided by the web browser when that warning is shown varies. Apple’s Safari web browser on Mac provides no additional information if you click on “Not Secure”. By comparison, the Mac version of Google’s Chrome web browser provides a pop-up that reads:

Your connection to this site is not secure

You should not enter any sensitive information on this site (for example, passwords or credit cards), because it could be stole by attackers.

What that is explaining is that by “Not Secure”, they mean that the connection between the website and the web browser is not encrypted, so information passing back and forth could possibly be read somewhere between the two. In a lot of cases this doesn’t really matter, since nothing sensitive is being shared between the two.

To stop the warning, the website should be accessed over HTTPS instead of HTTP. That generally involves setting up an SSL certificate and setting it so that requests to website are made over HTTPS instead of HTTP. Depending on the web host and software used on the website, that can be easily done and done for free.

It also worth noting that in most instances, from our experience dealing with lots of hacked websites, making a website secure in that way wouldn’t have an impact on whether a website is hacked, since the hacks do not involve taking advantage of that insecurity.