OneHourSiteFix Introduces Arbitrary File Upload Vulnerability on Websites Using Their Service

We are often brought in to re-clean malware infected or otherwise hacked websites after other security companies have failed to get things fully cleaned up. Recently though we were brought in to deal with a high profile website (one where we were later contacted by the FBI during their investigation in to it) where not one, but two companies had failed to do anything meaningful to clean it up. One of them, Sucuri, we already were well aware likely wouldn’t do a good job based on everything we had seen in dealing repeatedly in cleaning up after them. The other company is one that we don’t have as much experience with, though from everything we have seen it wasn’t surprising they hadn’t handled the situation well, but something we noticed makes them much worse since they are introducing a serious security vulnerability on their customers’ websites when they are supposed to be cleaning them.

The company’s name is OneHourSiteFix. Just the name indicates they likely don’t do a good job since you are unlikely to be able to properly clean up most websites in that time frame. As we mentioned in a previous post related to strange claims they make, it seems impossible they could do what they claim to do in that time frame seeing as they claim to:

manually analyse EVERY element of your site – every row in your database and every line of your files is checked and cleaned

In the case of the high profile website they don’t appear to have accomplished anything positive. They did add a couple of files that actually introduced a serious security vulnerability, which we will discuss in a bit.

Another instance of interaction with their work came a couple of months ago when we got sent this email from them:

Hi there,

We have cleaned and replaced the hacked version of this site. Also, we have placed the website behind an enterprise grade web application firewall to ensure this site has a high level of protection against future attacks

https://www.virustotal.com/#/url/9eb38ae785eeeca21b344ead39cf595b0bdb5f991c60c6ac630e6e628bc34678/detection

Could you please review and remove the blacklisting as soon as possible ?

We don’t blacklist websites nor do anything close that. Looking at our logs we found that they landed on our website on page titled Sucuri SiteCheck Scanner Falsely Claims Our Website is Defaced, which has nothing to do with us blacklisting websites. You would have to be very confused to believe otherwise based on that page, but they did.

They seem to make a fair amount of strange requests like that, considering a quick search pulled up them requesting blacklist removals for websites well after that removal had already occurred.

With that complete lack of attention to detail what else we noticed about them isn’t surprising.

OneHourSiteFix Makes Their Customers’ Websites Vulnerable

At the point we brought in to clean that high profile website there were still files from OneHourSiteFix on the website in a directory named appropriately “ohsf”. In that directory was another directory named “upload”. That directory in turn contained a file that allowed anyone to upload arbitrary files to the website. The file used to handle that was recently in the news for the real but overstated security risk introduced by it. In this case there were no restrictions on what types of files could uploaded through that or who could upload files, so a hacker could use that to place malicious .php files on a website and gain full access to the website, which seems like something that a company that is supposed to be cleaning a website shouldn’t be making possible (even if it is hopefully only temporary).

What was also interesting in this situation is that Sucuri flagged a number of the files in “ohsf” directory as being “malware” and removed them, but didn’t notice that file with a serious security issues.

The Poor Quality of Web Security Products and Services Can Lead To a False Belief That Websites Have Been Hacked

We think a baseline requirement for using any web security product or service that claims to protect websites should be that there is evidence that the service is effective. That would preferably be evidence from independent testing. What we have found though is plenty of products and services not only don’t provide that, but their marketing materials actually indicate that the services fail to secure websites. For example, SiteLock’s idea of security seems to revolve around dealing with after effects of websites being hacked instead of stopping them from being hacked in the first place, which isn’t security.

Even with what SiteLock claims to do instead of securing the website, they don’t provide evidence they are effective at it. We have seen plenty of evidence to the contrary. The latest example is also a reminder of another issue we sometimes see with security products and services, they lead to people falsely believing that their website has been hacked, so instead of securing a website they lead to people to believe that the website insecure. That might be good for security companies since it can mean more businesses dealing from dealing phantom hacks and more fear leading to more purchases of services that don’t have to work, but it, like so much else from the security industry, is bad for everyone else.

The other day we were contacted by someone using SiteLock’s services, for a second opinion on a claim from them that a website was infected with malware. We were sent the following screenshot from SiteLock’s website:

While that does claim that the website contains malware, the signature listed, SiteLock-HTML-SEOSPAM-fkl, seems to actually indicate that there was spam content detected. From what we have seen SiteLock labels any indication that a website has been hacked as malware. We don’t know if they don’t what malware actually refers to or if this is done to make what they are detecting sound more concerning than it really is, but it is sometimes very misleading. In this case they also make this sound very concerning by claiming the severity is “Urgent”.

The sample provided for the supposed issue doesn’t appear to be related to malware or spam. Instead it is just shows a link to another page on the website and harmless HTML code generated by the WPBakery Page Builder plugin for WordPress. We also didn’t find any other indications of a spam hack on the website, so this “Urgent” situation seems to really be a false positive.

Considering that their service is supposed to provide “security” by detecting and removing malware, the poor quality of their scanner makes it unlikely that they could even accomplish effective detection, much less effectively remove what they find.

This was apparently the third time that SiteLock had claimed that there was malware on the website, based on the quality of the claim in this instance, it seems unlikely it was the only false positive.

You Also Shouldn’t Be Relying On SiteLock to Clean Up Hacked Websites

Part of what makes us have such disgust at so much of what goes on in the security industry is that we see the damage that so many of the people and companies in it cause, over and over. Just yesterday we were discussing the mess caused on one website by Sucuri’s poor attempts to secure and clean the website. That isn’t an isolated incident with them and it isn’t justified in anyway, instead that is the type of company that shouldn’t even be in business since they either are simply unable to do the work they claim to be able to do or intentionally don’t things right. That not only harms their own customer, but they make everyone less secure by spreading false information and doing things that make all website less secure (like not determining how websites are hacked, so that unfixed issues can be resolved). They are not alone in this.

Just a couple of days ago we got yet another example of that type of issue with a company named SiteLock, which also isn’t an isolated incident when it comes to this particular company. In this case they were hired to clean up a hacked website. After the clean up, there were errors and the owner of the website was unable to edit the website (possibly because of the web application firewall that was put in place on the website, which isn’t an isolated issue with WAFs). When SiteLock was contacted about those errors they said that there now was more malware on the website and an additional fee was going to be needed over the $500 just paid, to deal with that.

If you just cleaned a website and there is immediately malware on it again, that means you didn’t get things properly cleaned up the first time, so charging more money to deal with that seems highly inappropriate to us. It certainly isn’t something we would do.

An easy way to avoid ending up in situation like this is to avoid hiring SiteLock. We can’t emphasize enough how many problems we have seen caused by this company that we have dealt with over the years that should have never happened if they had an interest in doing things right.

When Sucuri Doesn’t Really Protect Your Website It Shouldn’t Be Surprising Their Cleanups Cause Problems As Well

We recently had someone contact us who was looking for a service that would protect their website from being hacked and clean up the website if it did get hacked. There is what seems to be us to be an obvious issue with that, which is that cleaning up hacks wouldn’t be necessary if the website was being successfully protected from being hacked. It also seems like a bad idea to expect that if a company is providing a service where half of it doesn’t work that the other half will actually work well. When it comes to services that offer both of those things, our experience is that their providers usually are not just bad at both, but don’t even attempt to do the work that would be needed to do them properly.

As a case in point, we were contacted by someone last week that was using Sucuri’s service that provides both of those. The service failed to protect the website from getting infected with malware. Sucuri’s first clean up failed to stop it from getting infected again (or didn’t fully clean it up), which is not all surprising based on lots of previous instances we have been brought in to re-clean things after they failed to even attempt to do things properly.

After the second cleanup the website was broken. Once Sucuri fixed that issue, it was broken in another way, at which point the owner of the website contacted us.

There really isn’t any reason that anyone should be relying on Sucuri at this point (which was equally true years ago as well). They have shown they lack an even basic understanding of security and their own marketing material indicates they are not focused on providing effective protection. They fail to properly deal with hacked websites with even the most serious hacking issues or high profile websites (we were recently hired to re-clean a hacked website they failed to clean, for which the hack was being investigated by the FBI).

Your Web Host Might Cause Your Website to Be Broken In Trying to Secure It

A lot of our business cleaning up hacked websites involves people hiring us to clean up their website after someone else had been hired to do that but failed to even attempt to do things properly, so we are not surprised at most of what we see done instead of doing that, but there is the occasional exception.

We were recently brought in to clean up a website after a web host was supposed to have handled that, but they didn’t seem to have made much attempt at that. What we found was that they had failed at doing some basic things that should have been easier parts of the cleanup. That included failing to remove the malicious JavaScript code that they knew a web based scanner had (correctly) identified was on the website, despite the being added to files on the website in a non-obfuscated way, so a simple search of the files would have found it. They also had failed to enable the archiving of logging of requests to the website, which would have been done through cPanel and would have made would have made it easier to spot the malicious file that was allowing a hacker to continue to access the website.

What stood out was something they claimed they had done:

Another thing I did to help prevent this from happening again in the future, I created a two-user system for your WordPress admin. What this does is it assigns a front-end user that has just enough permissions for the site to display, but not enough for people visiting the site to make changes, without logging in. It also has a back-end user that applies whenever someone logs in, that has all permissions.

Many of those that use WordPress that are not even familiar with security would probably find that odd sounding. You normally don’t have to be logged in to WordPress to view the website and when not logged in, not surprisingly, you can’t make changes to the website, normally. This website was a run of the mill WordPress website, so that was all true for it.

When we went to see what had actually been done we found that there was only one WordPress user, so either they were not referring to a WordPress user or they hadn’t done what they said. One possible explanation was that they were referring to another database user with only read access, which would not really match what they described and seem like a bad idea as WordPress isn’t designed for doing something like that.

In checking into this we found they were referring to a database user and they had created a bit of a mess.

While it looks like they created a database user that was only supposed to be read only as the two database user name were identical save for a “ro” added to the end of one, that wasn’t actually what they had created. The read only user has the following privileges DELETE, INSERT, SELECT, UPDATE. As you might be able to guess from some of those names, that user doesn’t just have the ability to read things, but make significant changes.

It turns out though they didn’t set up a dual user situation, so only that user was being used. That was a problem since privileges the user was missing were needed by WordPress in the course doing normal functioning. In the error logging we could see this had caused actions trying to be taken by a security plugin to not work.

That seems like a good reason to be wary of having a web host clean up a hacked website, but tomorrow we are going to be discussing another recent instance where a prominent security company failed to clean up a website the first time, then on the second go around managed to break the website and then break it some more.

Making an Unnecessary Change to a Website That Breaks Updates is Not Good for Security

There is a nearly endless amount of bad security advice for websites, so someone has to try hard to make theirs stands out, but that is what something we happened to run across recently from a company named ENDURTECH did.

Their post, https://endurtech.com/setting-proper-chmod-permissions-for-wordpress-wp-config-php-and-htaccess/, suggested that you should change the permissions on a couple of WordPress files to the “proper” permissions:

Set CHMOD Permissions to 444 on the following files:

  • .htaccess
  • wp-config.php

Those are not the proper permissions (if they were, you would assume that WordPress would set them that way for you) and they don’t make sense from a security perspective seeing as permissions only come in to play if someone has access to the files. In a normal hosting setup the only people that would have access to the files would also have permission to change the files permissions, so if you where to change those as suggested there, which would restrict editing the files, then those with access could change the permissions to be able to edit the files again, so this doesn’t provide a real benefit for most websites.

Bad advice is very common, what made this stand out is what is stated before that in the post:

Please note that doing as suggested within this article will no doubt eventually cause issues with WordPress plugin updates and maybe even WordPress core updates.

This is because these files are no longer “editable“.  Great for security, bad for updates.

Just keep this in mind and visit your website from time to time to make sure that your updates are completing correctly

Keeping software updated will actually have a positive impact on security, so they are suggesting doing something that isn’t useful that by their own admission makes something useful harder, which is bad idea.

GoDaddy Says That Version of PHP for Which Support Ended 3 Years Ago Meets Their Stability and Security Requirements

You would think that if a web host owned a security company they would be better than other web hosts when it comes to security. With GoDaddy that isn’t the case, though that might be explained by the fact that the security company they own Sucuri, seems to be completely incompetent. As yet another example of the security issues with GoDaddy, while dealing with a support issue on a website hosted with them we found that they were making this claim about PHP 5.4 on the Programming Languages page of their control panel on the website we were working on:

PHP version 5.4 is available and meets our stability and security requirements.

Support for PHP 5.4 ended in September of 2015.

To make thing more confusing if you click the question mark icon next to radio selector to use that version of PHP on the page a message box appears that states:

Version 5.4 is no longer actively supported.

So is the first claim inaccurate or do they have really low standards for “stability and security”?

Bad False Positives from Wordfence Security and Quttera Web Malware Scanner WordPress Plugins

We often have people contact us that believe that a claim that their website has been hacked is false because they ran a scanner over and it didn’t find anything. We are not really sure why they don’t ask for the evidence behind the claim and try to see if they can confirm if that is accurate or not instead of running a scanner over the website, but considering they are not doing that it might not be surprising that they are instead doing something that is likely to not produce great results.

One problem is that the even if the scanner is effective at what is attempting to scan for, it may not be able to detect the type of issue that lead to claim that the website is hacked. Let’s say a web host detects a malicious file on the website, well that probably would be be something that a scan of the website’s pages from the outside would never detect.

Another problem is lack of evidence that various scanners are actually effective at what they are attempting to scan for and from our own experience, plenty of evidence that they are not effective. One area where we have seen evidence of that going back many years is with really bad false positives that indicate that these scanners are incredibly crude, so crude in fact that if we weren’t well aware of how bad the security industry is, we would have a hard time believing that they were even occurring. Below are a couple of them in WordPress plugins that we recently ran across that show the current poor state of such tools.

Quttera Web Malware Scanner

The first comes from the plugin Quttera Web Malware Scanner, which has 10,000+ active install according to wordpress.org. In recent thread on the support forum for that someone mentioned getting a false positive for what is quite common code. The plugin will warn when matching “RewriteRule ^(.*)$ h” in a .htaccess file, which would match when do some fairly common rewriting of URLs. Just doing that rewriting is not in any way malicious. The developer’s explanation for that wasn’t that this was a mistake, but that:

We mark it as suspicious because there are multiple malware instances utilizing this technique to steal/redirect traffic from infected websites.

Simply because malware uses common coding isn’t a good reason to flag any usage of it and that will necessarily cause the results of a scanner to be of limited use.

Making it seem like the developer really doesn’t know what they are doing in general, the description for that detection is “Detected suspicious JavaScript redirection”, which makes no sense considering that type of code has nothing to do with JavaScript.

Wordfence Security

The second instance of this involves a much more popular plugin Wordfence Security, which has 2+ million active installs according to wordpress.org, that we have frequently seen people believe is much more capable than it really is (sometimes they ignored evidence right before their eyes to continue to believe that).

A thread on the support forum of the plugin Ultimate Member was recently started with:

Wordfence seems to think there is a malware URL somewhere in the file class-um-mobile-detect.php:

* File contains suspected malware URL: wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php

but on comparison, the file’s contents are exactly the same as the latest file offered on https://ultimatemember.com

Can someone comment?

In follow to a question by the developer of the mentioned plugin, the original poster wrote:

I’m using 2.0.23 but as I’ve said the file in question is identical to the one found in the latest version. So as I thought it is a false positive. Maybe Wordfence doubled up on UM after the latest malware exploit.

In reality it was just that Wordfence’s scanner incredibly crude as hinted at by another reply in the thread:

It is caused by the URL: “http://www.vonino.eu/tablets” which was reported to contain malware.

In my file, it’s only mentioned in a comment so I guess it’s safe.

What that is referring to is the following line in the file /wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php:

340
// Vonino Tablets - http://www.vonino.eu/tablets

Currently the domain vonino.eu is being flagged by Google as malicious:

That doesn’t in any way make a file that includes the domain in a commented out line in the code, which can’t run, in any way malicious. If the developer’s of Wordfence Security cared at all they could easily avoid that false positive, but considering they can get away with much worse it isn’t surprising they wouldn’t care about that. That also leaves more responsible plugin developers to have to deal with the fallout from those false claims.

The Developer of Cerber Security, Antispam & Malware Scan Gives Out Bad Advice To Push Their Plugin

When it comes the security industry around WordPress unfortunately there are many people that either don’t know what they are talking about or are intentionally peddling bad information to push products and services that provide little to no protection, while making things harder for companies that are actually doing the hard work to actually improve security.

We often run into examples of this even when we aren’t looking for them. We ran into another example just the other day when we went to look around for some information while working on a post about running into a problem with contact form due to WordPress’ REST API being disabled. That lead us to an example of someone at best not knowing what they are talking about when it comes to the basics of WordPress security while being the developer a security plugin, Cerber Security, Antispam & Malware Scan, that currently has 90,000+ active installs according to WordPress.org.

A big tell that developer doesn’t have a basic clue as to security surrounding WordPress is that a main feature of their plugin is blocking brute force attacks despite the fact that those are not happening. They also make this brute force related claim in the marketing materials for plugin:

By default, WordPress allows unlimited login attempts through the login form, XML-RPC or by sending special cookies. This allows passwords to be cracked with relative ease via brute force attack.

Saying that brute force attacks could crack a password relative ease is belied by the number of login attempts needed to actually test out all of the password combinations. Here is what we wrote about that previously:

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

The post that we had run across was “Why it’s important to restrict access to the WP REST API”. The post is riddled with errors, for example citing someone as having discovered a vulnerability they didn’t.

The general problem was that they were suggesting disabling the REST API, which not at all coincidentally they touted their plugin did, because there could be security issues with it since it is new. But that is true of anything. In reality the vulnerability they discussed in the post actually showed how WordPress does a good job in handling security in one important way, since the auto update mechanism that has been in WordPress 3.7 allows the vast majority of WordPress website to be updated to a new security release in a very short time. Normally WordPress checks for updates every 12 hours and that can be shortened when a security update is being released, so most of the websites would likely have been updated in around 12 hours. With this vulnerability there was no evidence of it being exploited until after it was disclosed that it had been fixed a week after the version that fixed it was released (while the information on this vulnerability was held back for a week, other security updates were mentioned when it was released).

The developer though put forward a very different impression:

Unfortunately, the REST API bug had not yet been fixed. That leaves unprotected millions of websites around the world. It’s hard to believe but updating WordPress on shared hostings may take up to several weeks. How many websites have been hacked and infected?

That it may take several weeks to for WordPress on shared hosting to update is actually hard to believe, since it doesn’t appear to be true and no evidence was presented to back up a claim even they claim is counter-intuitive. The developer provides no evidence that any websites were hacked before the vulnerability was disclosed as having been fixed a week before, which as far as we are aware they couldn’t have since it doesn’t appear any were. That all probably shouldn’t be surprising since the developer apparently had never checked to see if brute force attacks were actually happening before building a plugin to protect against that.

For website where the auto update mechanism was disabled or didn’t work they did get mildy hacked due to this vulnerability, but that is the only vulnerability in more than a decade that we are aware of where there was any sizable number of websites hacked (in that time outdated WordPress installation have been frequently falsely blamed for the hacking of websites by security companies that either didn’t know what they were talking about or intentionally lying to get themselves press coverage). So disabling the REST API subsequent to this vulnerability being fixed has not actually improve the security of websites in any meaningful way.

There also was the issue of the developer conflating bugs and security vulnerabilities, which is important since having a lot of bugs fixed in something doesn’t mean that there was security risk.

The downside of disabling the REST API can be seen in that, like with the other plugin we mentioned in the post from earlier this week, this plugin can cause Contact Form 7 based forms to stop functioning. This exactly the kind of downside that often isn’t considered when people indiscriminately use WordPress security plugins and services without finding out first if there is any evidence that they provide effective protection. In this case what makes this stand out more to us is that our Plugin Vulnerabilities plugin, which is designed to help protect against a real issue, is much less popular than this plugin. It could be worse though, as another security plugin just designed to protect against brute force attacks has 2+ million active installs according to wordpress.org and it not only doesn’t protect against a real threat, but contains a security vulnerability of its own.

BitNinja Makes Up Zero-Day Attack

The terribleness of security companies never ends. The latest example of that is something we ran across today while looking in to a claim that outdated software was the cause of a security issue on a server. What had been pointed to as evidence of that was a report from a security company named BitNinja. That report was claiming that there was malicious activity based on emails being sent from software on a website, but based on the information provided there was nothing that we could see that would indicate if there really was an issue or if there was a false positive happening (it would seem that the company doesn’t have a good understanding of what information is important to determine that sort of thing).

In looking over BitNinja we quickly ran across evidence of them spreading false information, which happened to involve a topic we just discussed earlier today, exploitation of a recently fixed vulnerability in MODX. The title of a blog post on their website made a striking claim about that, “Critical zero-day vulnerability in MODX Revolution patched by BitNinja WAF”. A zero-day vulnerability refers to a vulnerability that is being exploited before the developer is aware of it, so they have had zero-days to fix it. That obviously is quite concerning since doing the security basic of keeping software up to date wouldn’t protect against and if there was a security system that could protect against such a situation it would be useful.

With a website that had been hacked through that vulnerability the attempts to exploit it on that website started about a week after the vulnerability was fixed, with the first attempts logged on July 19. There was nothing we saw in looking into the situation that would indicate that that this was a zero-day vulnerability.

BitNinja seems to either not have any idea what they are talking about or intentionally misleading people as their claim that this is zero-day vulnerability is based on spotting exploitation attempts two weeks after a fix for the vulnerability had been released:

At 26th July at 6 PM, the flow has been started according to our data. This botnet is really aggressive, as, in the first 6 hours, we detected almost 13.000 attacks!

They also were quite behind in even spotting the attacks, which doesn’t say great things about them either.

Blaming the Victim

Looking at their About Us page a couple of things stood out to us, one of them being them starting with a claim of near equivalency between hackers and people running web servers:

We believe every server owner is responsible for their servers. If they have been hacked – and used for cybercrime – the owner is almost as guilty as the hacker is.

There also is the basis of their business that doesn’t seem to be from a security background, but one of a web host not being able to maintain their servers:

We couldn’t ensure the security of our servers beyond applying continuous updates. To make matters worse, we started losing customers after a series of downtimes. We quickly realized that server security is not a question of a single component but is about several components working together to harden a server. This inspired us to create BitNinja, an all-in-one security solution designed for hosting providers.

They don’t make any claim to having security expertise on that page (not that it would mean much based on what we have seen of security companies making such claims).