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.

Hackers Using Insecure Magento Extensions to Access Magento Admin Login Page Without Knowing Normal Address

While reviewing the log files while cleaning up a hacked Magento website recently we ran across a reminder that a common security practice isn’t full proof. With the Magento software and some other software the software has a built in capability to use a non-standard address for the login page for the admin portion of the website. With other software that is commonly promoted security feature to be implemented with an add-on.

The value of that is limited as while there are widespread claims that there are frequent brute force attacks against admin passwords, in truth what is going on are dictionary attacks, which involved trying to log in using common passwords and that can easily be prevented from being successful by using a strong password. There is the possibility of some value of doing this in a far more limited situation where the hacker has access to valid login credentials for the website, but it turns out that there can be various ways to get access to login page without knowing that address.

In the logs of this hacked website we were seeing many POST requests to this address:

/index.php/magenotification/adminhtml_feedback/index/

When visiting the page we saw that the Magento admin login page was showing. In looking into if that all there was that we found that this is something that hackers are looking around with pages like that generated by various extensions.

Magento added protection against this issue with SUPEE-6788, which was part of Magento 1.9.2.2, but by default the protection is not enabled.

A Web Application Firewall (WAF) is Not the Way to Deal With the Reoccurrence of a Hack of a Website

These days quite a bit of our business dealing with the cleanup of hacked websites is re-cleaning websites after other security companies didn’t clean them up properly before us. Troublingly we recently noticed a company that offers to clean up websites, ASTRA Security, treating that as a normal result and using it to promote using web application firewall (WAF), which they also sell:

Even after clean up and restoring your site, the Magento admin hack may reoccur. The reasons could be a backdoor left by the attacker or simply a vulnerability that may be left unpatched. To avoid such scenarios it is highly recommended to use a WAF or security solution of some sort.

If there is still a backdoor on the website that means it hasn’t been cleaned up, since that would be something would be removed during the cleanup, which someone cleaning up hacked websites should understand.

Part of a proper cleanup is trying to figure out how the website was hacked, so if a vulnerability is left unpatched then things probably have not been done right either.

The providers of WAF’s don’t provide evidence that they provide effective protection against vulnerabilities, while we have seen plenty of evidence that they don’t provide it. It would be even more difficult for them to protect against exploitation of backdoors due to wide variety of their location and what is done through them, which someone cleaning up hacked websites should also understand.

The best way to handle a reoccurrence is to avoid one in the first place by hiring someone like us that will properly clean up the website. If you didn’t do that then the next best solution is to hire someone to re-clean it that will do things properly.

GoDaddy’s Idea of Securing Websites Actually Involves Leaving Them Insecure and Trying to Deal with the After Effects of That

Yesterday we discussed GoDaddy’s usage of misleading claims to try to sell overpriced SSL certificates. Based on that it probably wouldn’t be surprising to hear that they would mislead people in other ways about security and that is exactly what we ran across while looking into things while working on that previous post.  When we clicked on the “Add to Cart” button for one of their SSL certificates, at the bottom of the page we were taken to, there was a “malware scan and removal” service offered to “Secure your site”:

The description of that is:

Defend your site against hackers and malware with automatic daily scans and guaranteed cleanup.

It shouldn’t be too complicated to understand what is wrong with that, though as we mentioned earlier today there seems to be a lot of confusion when it comes to what security services and products do.

If a website is secure it wouldn’t have malware or some other hack on it to detect or remove, so either GoDaddy doesn’t understand what they are providing or they are lying about.

The problem we see so often with this sort of service is that people will fail to do the things that will actually keep websites secure because they believe a service like this will actually keep a website secure.

Trying to deal with the after effects of having a website hacked instead of actually securing it introduces a lot of issues. One of those being that if a hacker uses the hack to exfiltrate customer data stored on the website a cleanup isn’t going to undo that.

What is a lot more important to note is that everything we have seen from the underlying provider of GoDaddy’s security services, Sucuri, is that they are not good at detecting and cleaning up hacks of websites. Their scanner seems, to put it politely, incredibly crude. Their employees seem to lack a basic capability to understand evidence that a website is hacked. And in what is most relevant to this specific service, we recently we brought in on a situation where their scanner had failed to detect that a website was hacked and then they repeatedly incompletely cleaned up the website, leaving it in a hacked state for a while. It was only after we were brought in to clean things up properly (which Sucuri doesn’t appear to even attempt to do) that it was finally cleaned and stayed that way.

Monitoring For Malware and Other Website Hacks Won’t Prevent a Website from Being Hacked

In dealing with people with hacked websites we are often reminded that things that seem like they should be easy to understand about security products and services are often not for a lot of people. What plays at least some role in that, and maybe a lot, is that the security industry frequently makes misleading and outright false claims.

We recently had someone that contacted us about a hacked websites who seemed to be unaware that monitoring for malware or other types of website hacks would not prevent the website from being hacked or clean it up if it did get hacked. In their case they said they were relying on monitoring from SiteLock and Wordfence.

What monitoring tries to do is detect evidence of malware or another hack after it has occurred. Since it comes in to play after the hacking it wouldn’t be possible to stop it from occurring. Despite that we have seen providers of monitoring services promote them as being able to stop or protect a website from being hacked. Either these providers don’t understand what they are providing or are lying about it, neither of which is a good option.

If there were monitoring solutions that were effective at doing what they are actually trying to do they might be a good option as additional measure beyond doing the basics for high profile websites that are at elevated risk of being targeted by hackers. We have yet to see any such service that presents evidence, much less evidence from independent testing, that they are effective though, which seems like it should be a baseline for using such a service at all. What we have seen of monitoring solutions and other tools to detect malicious code in years of dealing with the cleanup hacked websites is that they have a limited, at best, ability to spot malicious code on a website.

For the average website what should be the focus is doing the things that will actually make websites secure instead of hoping that a security service is going provide even a fraction of what the extraordinary claims they often are promoted with would lead people to believe they are capable of.