Why Exploiters Should Optimize Their Code
by greg
As far as Internet "bad actors," or "exploit bots," or simply "assholes" running code that tries to exploit websites for "shits 'n giggles" (or whatever reason) - by which I mean those who are simply looking to disrupt and to "hack" sites that have WordPress installed to take over admin accounts or to delete content - I have some things to say.
First, and foremost, I am not discussing those who would want to remotely (or otherwise) install malware or ransomware, but those actors who regularly use Hypertext Transfer Protocol (RFC 2616 et.al.) directly to try to exploit websites.
Like this:
You should all know what I mean. (If not, keep reading 2600 Magazine...)
If one has WordPress installed, that may be a legitimate request, but if one does not have a WordPress website (like my pathetic little static site), such a request should not happen.
Thing is, they do. They occur, literally, about one thousand times per month. That ain't the problem, per se, as my sites don't care. To it, it's just a 404 - which I make the response just a few bytes directly by Apache's .htaccess file.
The thing is, multiply that by one billion websites and the entire Internets slow down.
Get it?
Obviously, WordPress is not the only code being exploited every second of every day over the entire Internets. I am using that as just one example. I am not mentioning the 2,000 or so other "CMS" software with exploits...
A few thousand, few byte, 404 errors per month? Yes, no big deal. But it's more than that.
1.) Exploit code does not just try for that one file, they try for dozens of path variations.
2.) Exploit code does not use a single IP address or User-Agent string.
3.) Exploit code does not give up. Ever.
All this means is that one cannot block them easily. Deny by IP? Losing battle. Deny by request strings? Losing battle.
Again, I am thinking of just WordPress shit. (If you have WordPress, more on that later.)
The simplest blocking mechanism is this Apache configuration:
That won't cover all, but it is the basic example to stop 90 percent of WordPress exploits upon first request before loading one's own massive 50 MB+ CMS! (One can see how just a few more strings in the match list can help.)
Now, to the point of this article, an appeal to exploit code authors. Yes, that is exactly what I am doing.
This appeal is based on one simple little obvious fact: "GET / HTTP/1.1" and then look at the results and see if any WordPress signature is there! And there will be! For WordPress informs everyone that it is a WordPress site!
Therefore, to all WordPress exploit coders, just check the root page and if WordPress is not indicated, stop further requests and move on to your next target!
Let me add here a log excerpt of an example of some WordPress exploit code. Instead of wasting 2600 Magazine's valuable space, I will not excerpt the entire log blurb but the files requested - each request just one or less seconds apart:
Let me remind you that this happens thousands of times per month on just my no good, static website. But who cares, right?
You need some math: billions of websites every second of every day.
Ignoring all other exploitable web code...
Here is the crux of the title to this article:
I appeal to all WordPress exploit coders to please check the root page and, if WordPress is not indicated, move on to your next target!
My criticism is, are you coders or are you assholes?
Fine with your exploit coding! Just, please, for the sake of the world, do it right! Blind requests like the above example, is... simply pissant amateur coding.
None of you are hackers. None of you are doing anything but declaring, "I am an Idiot Script Kiddie." Grow up.