How to handle these 404 errors that look like SQL errors / hacking attempts?

Question

I have an E-commerce site (built on OpenCart 2.0.3.1). I'm using an SEO pack plugin that keeps a list of 404 errors, so we can make redirects.

As of a couple of weeks ago, I keep seeing a LOT of 404s that don't even look like links:

999999.9 //uNiOn//aLl /**/sElEcT 0x393133353134353632312e39
999999.9 //uNiOn//aLl /**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39
999999.9 //uNiOn//aLl /**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39
...and so on, until it reaches:
999999.9" //uNiOn//aLl /**/sElEcT 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x3931

This isn't happening once, but 30-50 times per example. Over 1600 lines of this mess in the latest 404s report.

Now, I know how to make redirects for "normal" broken links, but I don't even know where to begin to fix this.

Any advice?

score 0 · Answer 1 · answered May 19 '17 at 21:08

0

If you can, set up a case insensitive filter where if the method matches "select", just straight drop the connection completely and IP Ban the offender.

Don't even return a reply. Chances are this is a bot that's doing the work and if it starts getting connection failures, it's a good bet it'll move on to someone else.

answered May 19 '17 at 21:08

whiskeyfur

111
3

- 1.) Any suggestions on the format? - 2.) Is there some chance that it could screw up the legitimate database queries? – TomJones999 May 19 '17 at 21:14
Let me ask this first: Are you looking at a web server log or the MySQL server log? The answer will differ there. Either way.. I'm going suggest updating opencart first. You're running on 2.0.3.1.. the latest version is 2.3.0.2, and is available here: https://www.opencart.com/index.php?route=cms/download – whiskeyfur May 19 '17 at 21:43
As for being a malicious bastard when it comes to security (which is the approach I take)... I usually have an apache front end that does nothing but reverse proxy and security. That way it handles ALL of my websites in one location so if I IP ban someone from one site, it hits everywhere. The servers that do the actual application work are configured to ONLY accept connections from the firewall or my administration machine. No where else. – whiskeyfur May 19 '17 at 21:45
I know it's an outdated version, we're keeping it (for now) due to compatibility reasons. I'm looking at the "404s Report" in the SEO plugin in admin panel, and then dumping the contents of the "oc_404s_report" database that's created by the plugin. – TomJones999 May 19 '17 at 21:46
Question... would you be interested in doing a consult on our site? And how much would your time be worth? – TomJones999 May 19 '17 at 21:47
I have a very limited travel range as well as having been out of the consulting business for a while, so I would have to pass. But thank you for asking. Just to give a ballpark figure though so you won't get hit with sticker shock, I can easily see someone charging upwards of 50-80 USD/hr for at least 5 hours of work, depending on workload and other factors. So anywhere from 250 to 400 USD total, maybe more, and that's not even getting into hardware costs which can run you an another 500-1000. VM's would make this cheaper though. – whiskeyfur May 19 '17 at 21:54
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/59029/discussion-between-tomjones999-and-whiskeyfur). – TomJones999 May 19 '17 at 22:30

score 0 · Answer 2 · answered May 20 '17 at 08:04

From the tool you are using you can only see the 404 Not Found errors. From the perspective of security these are the least of your concerns. This kind of activity is automated scanning of random sites for vulnerabilities in content management systems, webshops and similar platforms.

Mostly these are known vulnarabilities in outdated versions. There could have been a single PHP file that had a single variable from GET or POST data that hadn't been sanitized before used as a part of an SQL query. While these lines in your question seems to only SELECT information from the database and wouldn't per se cause any direct harm, the purpose can be collecting information of vulnerable sites before the actual strike.

The 404 Not Found error is an indication there wasn't even the file they were trying to exploit. If you were in danger, it would have been outside your filter, logged as a normal 200 response or possibly causing other problems like 500 Internal Server Error. You are looking at the right thing in a wrong place.

It's possible to automatically deny request that have "SELECT" or other possibly malicious keywords in the HTTP query. Then, you could apply a Fail2ban rule to block an IP after certain amounts of those request.

However, the first thing to do is to install all security updates. You mentioned you have OpenCart 2.0.3.1. That's currently a two years old version! Since that there's a lot of bugs fixed e.g. in 2.1.0.0 and an XSS issue in 2.1.0.2, current version being 2.3.0.2 from Aug 2016. At least some of the modules have known vulnerabities even after that. Compatibility isn't an excuse: you should first care about security and then fix the uncompatible components.

How to handle these 404 errors that look like SQL errors / hacking attempts?

2 Answers2