When cleaning up a hacked website there are three main components to doing that properly. We often find that security companies don’t do two of those. One of them being trying to determine how the website was hacked. The other being getting the website secure as possible, which usually involves getting the software on the website up to date. If a company isn’t able to make sure the software is up to date, it seems likely they also are not familiar enough with the software that they should be dealing with hacked websites running it.
One well known company that usually skips doing those things is Sucuri. They promote as alternative to doing that securing, that you can rely on the virtual patching provided by their website application firewall (WAF). There are a number of reasons why that is bad idea, including that they don’t present any evidence, much less from independent testing, that their virtual patching is effective (they also don’t present any evidence that their service is effective at protecting websites in general). Probably the largest problem with relying on that though, is that it can be incredibly easy to go completely around their WAF, leaving websites that haven’t been properly secured wide open to being hacked.
Before we get in to that, what lead to us writing this post was our recent experience with their WAF making it harder to get a website secured.
We were recently brought in to upgrade a Joomla installation on a website that Sucuri cleaned but had failed to upgrade the software on it. When we went to do that upgrade we ran into an error, “ERROR: AJAX Loading Error: Forbidden”:
That error message doesn’t provide much information on what was going wrong and we would guess that others that run into it might get stuck at that point. In debugging that we found that when an AJAX request was made to /administrator/components/com_joomlaupdate/restore.php the response being received was this page:
At that point we could have contacted the person we were dealing with from the website and get them to try to whitelist our IP address, but there was a far quicker solution, simply bypassing Sucuri’s WAF, which can be incredibly easy to do.
Here’s is how Sucuri explains how their WAF works:
The reality is that all HTTP/HTTPS traffic does not have to begin where they show it beginning in that graphic, instead, if you know the IP address of the Original Host you can connect directly to it, bypassing the WAF entirely.
While in something we will get to in a moment, Sucuri refers to this IP address as being “hidden”, in reality it often isn’t hidden at all. In the case of the website we dealing with we just pulled up the DNS records for the website and the second IP address (after the Sucuri one) was the Original Host’s IP address (there was another equally easy method available as well). By simply associating that IP address with the domain name in a computer’s host file the Sucuri WAF can be bypassed.
From previous real world experience we can say that people will in fact rely on Sucuri’s WAF to keep them safe instead of keeping software up to date, which can leave people wide open to attack if someone just takes time to bypass the WAF. What makes that particularly problematic is that a website could appear to be secure for a long time, leading to people claiming that Sucuri’s solution is effective, and only later it becomes clear that things were not as how they seemed.
Here’s what makes this even more troubling, Sucuri is aware of the ability to bypass their WAF, but they either don’t understand that their attempt solution to stop that doesn’t resolve the issue or they don’t care that that what they are providing is fundamentally insecure.
The page Prevent Sucuri Firewall Bypass on Sucuri’s website begins:
If someone knows your hidden Hosting IP address, they can bypass our Firewall and try to access your site directly. It is not common or easy to do so, but for additional extra security, we recommend only allowing HTTP access from our Firewall.
The best way to prevent hackers from bypassing our Firewall is limiting their access to your web server. To do this, all you have to do is add restrictions to your
.htaccessfile so that only our Firewall’s IP will be able to access your web server.
As we already noted, the IP address isn’t necessarily hidden at all. Calling attempting to prevent the easy bypass as “additional extra security” as opposed to being essential, doesn’t provide much assurance that they actual are concerned about the security of websites using their service.
The larger issue here is that trying to restrict what IP address can access the Original Host directly isn’t very effective. That is because all someone has to bypass that restriction is to spoof a permitted IP address, which involves making it seem a request came from a different IP address than it really did. Either Sucuri doesn’t understand that or doesn’t care that their WAF is fundamentally insecure, neither of which should be true about a security company.
Their a major limitation with spoofing an IP address that is important to note though, which is that any response would not be sent back to the system sending the spoofed requests since the response would be sent back to the spoofed IP address. But with the kind of vulnerabilities we see actually being exploited on websites that often wouldn’t be an issue since the hacker doesn’t need to receive a response to gain further access to the website. Oncee they have access they could remove the IP address restriction or send any responses they need in way they can still access (say writing them to a file accessible through the website).
While we wouldn’t recommend using Sucuri’s WAF (or their services in general), if you are using it, restricting IP addresses as suggested in that previously mentioned article would provide better security when using their WAF.