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.

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.

If GoDaddy’s “Firewall Prevents Hackers” Why Would You Also Need Multiple Hack Cleanups?

We often get asked about whether people should use a service that claims to protect their website from being hacked. Part of our answer is that we have seen no evidence that these services actually provide that protection and plenty that they don’t, including being hired to clean up hacks on websites using those services.

That these services don’t work isn’t something that is really hidden, often the marketing material service for them suggests that they don’t really work. Take GoDaddy’s Website Security service. That service has three price tiers. With all three tiers, one of the bullet points is “Firewall prevents hackers.” In the lowest tier another bullet point is “Annual site cleanup and remediation” and in the other two it is “Unlimited site cleanups.”:

If the firewall prevents hackers, why would you need a hack cleanup?

Even if you want to give the benefit of the doubt to GoDaddy, that say they are thinking people would sign for the service when their website is already hacked or they are advertising hack cleanups, even though you wouldn’t need them, since they are confident the service works, it makes no sense that they wouldn’t offer unlimited hack cleanup with the lowest tier of the service as well, since even considering those possibilities, there would only need to be one hack cleanup.

That contradiction doesn’t just appear in that spot. In the textual information on the same page, they claim to take a “preventative approach” that “blocks attacks”, but immediately pivot to an indication that their service doesn’t accomplish that:

Take a proactive, preventative approach to the safety of your website. The Website Security firewall blocks attacks on your site while its malware scanner regularly searches your site for malicious content and alerts you if any is found. All you need to do is submit a malware removal request, and our expert security team will get to work cleaning* up your site.

What is completely missing from that page is any evidence, much less evidence from independent testing, that their service is effective at stopping attacks or detecting malware. Based on our experience having been hired to re-clean websites they were supposed to have protected and cleaned, the results of such testing probably wouldn’t be good.

GoDaddy Hosting phpMyAdmin on Server With “Broken Encryption” With F Grade From SSL Labs

One telling example of the web security industry’s lack of concern for security is how web host GoDaddy has continued to have rather poor security while first being partnered with one web security company, SiteLock, and then owning another one, Sucuri.

An example of that poor security came up a few months ago while we were dealing with a hacked website where Sucuri had not properly secured the website. We meant to post about that at the time, but then forgot about it until we were dealing with another hacked website with a GoDaddy connection worth posting about.

While working on the hacked website, we accessed the phpMyAdmin database administration tool that GoDaddy provided and found a situation we can’t recall seeing before with a web host. That would be the SSL encryption was “broken” on the server hosting phpMyAdmin.

If you access that in Google’s Chrome web browser the connection is listed as “Not Secure”:

You are warned that “Your connection is not fully secure” and that:

This site uses an outdated security configuration, which may expose your information (for example, passwords, messages, or credit cards) when it is sent to this site.

When looking at the Technical Details of that issue with Firefox, it states:

Broken Encryption (​TLS_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.0)

If you run that address through the SSL Labs tool, the server gets an F grade:

The domain name being used for that insecure server, secureserver.net, which isn’t an accurate name.

Hacker Impersonated GoDaddy When Hacking GoDaddy Hosted WordPress Websites

While working on cleaning up a hacked WordPress website recently we found a hacker had tried to disguise some of what they were doing by making it seem like it was coming from GoDaddy. GoDaddy, possibly not coincidentally, was the web host for the hacked website we were dealing with.

GD-Stats

The first element of this we found was a malicious plugin with the slug gd-stats. If you were looking at the Installed Plugins page in the WordPress admin area, you would see this information for that plugin:

That labels the plugin as being named GD-Stats and being from GoDaddy, Inc, though the link is to wordpress.com.

The description is weird:

Most leading CMS platforms like WordPress use Ajax in their architecture.

In looking to see if others had encountered a malicious plugin with the same name, we found a topic on WordPress’ forum from early in February where someone else hosted with GoDaddy had run into this:

This morning, I found that our WordPress website has been hacked by someone in Moscow. They uploaded the file “gd-stats.zip” then installed the plugin. Now when I go to our wordpress.org log in page, I put in my credentials, it takes me to a completely blank screen. When I went to our website, it doesn’t have the dashboard option available to log into. We’re hosted through GoDaddy. I’m waiting on their support team as well.

In a follow up they wrote this:

No it wasn’t Godaddy. It was from someone in Moscow who hacked our site at 4:30 AM. They installed the gd-stats.zip and the plug in but I finally got into our Godaddy account and deleted the plug in so we’re good now.

There was a reply from someone else with the same plugin, but no mention of the web host of the affected website.

For a hacker to add that plugin to the website they would already have to have access to the website in some way. In trying to determine what that was, we ran across a major problem, it appeared that GoDaddy had about a week before moved the website to a new cPanel account. That meant that among things, the last modified dates on malicious files were not meaningful, since it just listed the time of the move. It isn’t clear why that happened because of the partially unmanaged nature of the website at the time. Whatever was the case, the malicious plugin appeared to exist from before there was logging available that could have shed light on that. So we hit a dead end there.

Users Table

Another piece of the hack might help to further explain how the hack happened. In the WordPress database table storing the users of the website, _users, we found two non-legitimate Administrators accounts.

Both accounts were listed as being listed as being registered at 0000-00-00 00:00:00, which shows that they were not created through the normal registration process, since if they were, the time they were registered would be there.

Both of the accounts were also meant to look like they came from GoDaddy, with the usernames being:

  • gd_support
  • gd_sys_kafhi

Curiously the email address for them doesn’t use a GoDaddy-like domain, instead opting for wordpress.org.com:

  • gd_support@wordpress.org.com
  • gd_sys_kafhi@wordpress.org.com

Again we ran into a problem, since the logging isn’t available to see what it would show about how the hacker created those accounts.

There are several routes that could have occurred through. They could have been added through a SQL injection vulnerability on the website that allowed for adding things to the database, but most SQL injection vulnerabilities don’t permit that type of action, so that seems unlikely.

More likely would be that the hacker was able to get direct access to the database. That could be because of a security issue with the website, with the web host, or combination of the two. GoDaddy has had issues with improper security of database access, we posted about another hacked website where that came in to play in April.

February Time Frame

Looking at the session_tokens entries in the WordPress database’s _usermeta table, we found that one of those accounts was logged in to from a Russian IP address, 185.4.65.27, on February 4. That matches up with what was described in that WordPress forum topic.

Notifying GoDaddy

We are going to contact GoDaddy’s security team to let them know about this impersonation and maybe they can check if other websites they host still contain that plugin.