Ironically, while we’ve all been discussing What constitutes ‘hacking’?, hackers have been trying to deface my site! Or at least that’s my diagnosis. Assuming my diagnosis is correct, likely culprits are script-kiddies going by the name ‘d3b~X’ involved in a site defacement game of some sort. Anyway, this is a typical ‘attack’ (there were many of these a day over several days. It’s stopped now. If these do not– I repeat do not add ‘rankexploits.com’ to any of the uri snippets and load them in a browser.)

I’ll post this both to show some readers the features of something that actually is hacking along but also to alert others who might be seeing suspicious activity learn of this particular hacking attack which exists out ‘in the wild’. I’ll call it the “nyet attack”.

The nyet attack typically start with someone trying to “PUT” an image file on the server:
108.61.14.235 - - [30/May/2014:02:00:26 -0700] "PUT /nyet.gif HTTP/1.1" 405 473 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)"
HTTP PUT requests are forbidden by my server. (In my opinion, they should be blocked by most servers. Almost no one running a web site wants to let the public “PUT” things on the server.)

Having tried to “PUT” the images, the script kiddies next try to “GET” the image to see if it’s there. “GET” is always allowed by servers. However, the “PUT” attempt failed, so my server responds with a ‘404’:
108.61.14.235 - - [30/May/2014:02:00:27 -0700] "GET /nyet.gif HTTP/1.1" 404 2357 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
Presumably, if the script kiddies had seen a “200” they would proclaim victory and report their hackage to Zone-H. org. As they saw 404, it appears they continue, submitting a half dozen or so requests in roughly 2 seconds:

108.61.14.235 - - [30/May/2014:02:00:27 -0700] "GET /components/com_jnews/includes/openflashchart/php-ofc-library/ofc_upload_image.php?name=a HTTP/1.1" 503 469 "-" "Mozilla/5.0"
108.61.14.235 - - [30/May/2014:02:00:27 -0700] "GET /administrator/components/com_acymailing/inc/openflash/php-ofc-library/ofc_upload_image.php?name=a HTTP/1.1" 503 469 "-" "Mozilla/5.0"
108.61.14.235 - - [30/May/2014:02:00:27 -0700] "GET /components/com_community/index.html HTTP/1.1" 404 680 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
108.61.14.235 - - [30/May/2014:02:00:27 -0700] "GET /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&action=upload HTTP/1.1" 503 680 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
108.61.14.235 - - [30/May/2014:02:00:28 -0700] "GET /index.php?option=com_media&view=images&tmpl=component&e_name=jform_articletext&asset=com_content&author= HTTP/1.1" 503 680 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
108.61.14.235 - - [30/May/2014:02:00:28 -0700] "GET /en/components/com_jnews/includes/openflashchart/php-ofc-library/ofc_upload_image.php?name=a HTTP/1.1" 503 469 "-" "Mozilla/5.0"
108.61.14.235 - - [30/May/2014:02:00:28 -0700] "GET /en/administrator/components/com_acymailing/inc/openflash/php-ofc-library/ofc_upload_image.php?name=a HTTP/1.1" 503 469 "-" "Mozilla/5.0"
108.61.14.235 - - [30/May/2014:02:00:28 -0700] "GET /en/components/com_community/index.html HTTP/1.1" 404 680 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
108.61.14.235 - - [30/May/2014:02:00:28 -0700] "GET /en/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&action=upload HTTP/1.1" 503 819 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)"
In the above, notice the script seems focused on the /en/ directory. This is not a consistent feature, it might look for in the main directory, or in ‘/forums/’,’/administrator/’, ‘/Configuration%20Management%20%20Release%20Engineering/’,’/archive/’,’/view/’ or any number of other directories. I don’t know how it guesses, but I suspect these are common directory names under some popular CMSs.

There are a few variations to look for. The script might substitute ‘%2E’ for ‘.’ or look for .txt files. The key is the “nyet”.

207.7.94.35 - - [30/May/2014:13:31:52 -0700] "PUT /nyet%2Egif HTTP/1.1" 405 473 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)"
207.7.94.35 - - [30/May/2014:13:31:52 -0700] "GET /nyet.gif HTTP/1.1" 404 2316 "-" "curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2"
207.7.94.35 - - [30/May/2014:13:31:52 -0700] "PUT /nyet%2Etxt HTTP/1.1" 405 471 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-LI; rv:1.9.0.16) Gecko/2009120208 Firefox/3.0.16 (.NET CLR 3.5.30729)"
207.7.94.35 - - [30/May/2014:13:31:53 -0700] "GET /nyet.txt HTTP/1.1" 404 677 "-" "curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2"


Notice my server returned a combination of “404” (missing resource) and “503” http responses.

The 503 responses spring from Dreamhost having coded some script to automatically block plugins that are known vulnerable and which are cause customers so much grief that Dreamhost itself is blocking requests to these plugins. In particular “ofc_upload_image.php” is blocked by Dreamhost. The specific reason is that it most likely that this image uploader suffers from the well know “timthumb” issue: that is users (and 3rd party hackers) could upload malicious scripts using that file. Once that was done, the hacker could take over your site. Dreamhost knows this and also knows that no one wants hackers to upload scripts that permit the hackers to take over sites. So, Dreamhost takes proactive steps to block these requests.

Since we were previously discussing what constitutes a hack: Well, the above is a hack(in the ‘back’ tried to crack into the server sense not the “did something clever” sense). Key features that establish this as a ‘hack’:

1. They tried to upload material to my site. The “PUT” alone is evidence of this. Queries like “?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&action=upload” also look suspiciously like attempts to ‘upload’ material. No one believes that running a web server implicitly authorizes visitors to upload material.
2. These are not “obscure” uri’s I created but “hoped” no one would find. These are uri’s that point to nothing. They are guesses that would resolve to known vulnerable resources which would permit the person requesting to hack into the site if these resources were available on my site. (They aren’t available, but that’s another matter). No one believes that running a web server implictly authorizes anyone to guess uris the guesser thinks almost certainly does not exist particularly not if those uri’s match known vulnerability patterns.
3. This group is performing similar hacks elsewhere. Their successful hack attempts are archived to show the world they succeeded in uploading the image. They seem to sometimes deface homepages too. So we know these are attempts to upload because that’s what the group has been doing– and bragging about in public.

That pretty much shows how the above is a hack of the “tried to break into the server” sort. It’s not simple attempts to view material that is hosted on public facing servers– it represents attempts to upload stuff. ( I suspect it’s illegal. It’s unlikely I could catch these guys who may not be in the US in anycase. Also unlikely I could interest law enforcement in this activity.)

How to avoid getting hacked.
For those who might arrive here later through google, one might wonder: How did I managed to escape being hacked? Oddly, it’s partly luck, partly good planning and some degree of vigilance.

It’s worth pointing out that the people involved in this hacker/defacement game are skilled at defacing pages. If I had a vulnerable server or hosted vulnerable plugins, my ‘security’ would do little to stop this particular group. My security scripts do notice these attempts and do ban IPs that attempt this sort of thing Cloudflare thereby limiting a hacker to about 5 seconds of ‘wild guesses’ before being banned a Cloudflare. This does make it harder for many script-kiddies who program scripts to keep guessing and guessing potentially vulnerable uris for (I kid you not) hours on end. This does increase my security relative to the numerous unskilled script kiddies out there. (Unskilled script-kiddies greatly outnumber skilled ones. They can still succeed in hacking into a server and steps to prevent that are worth undertaking even if the protections can be out-manouvered by the hacker equivalent of ‘cat-burglars’.)

This particular group of hacker/defacers trying to upload ‘nyet.gif’ use lots of proxies and jump in fast. Their script appears to spend about 2 seconds using a particular IP and then return with a new and different one making new guesses. Each IP does get banned a Cloudflare for a few days and so becomes unavailable for use in an attack. This potentially makes it a bit harder for them to succeed in hacking (which I consider a good thing) but I wouldn’t be at all surprised if the group doesn’t use thousands of IPs. That means their IPs have plenty of time to make plenty of guesses.

I don’t delude myself that they could not succeed in finding a vulnerability if one existed. If I host a vulnerable plugin and the script-kiddies correctly guess and request it using a fresh IP during the few seconds before it gets banned at Cloudflare, I could get hacked. This is true for everyone.

So, why did this group of fairly skilled hackers fail to upload “nyet.gif?”

I avoided being hacked mostly by never installing the specific vulnerable plugins the hackers are hoping to exploit using their current script. They could guess anything directory they liked: that plugin is not to be found on my server. In addition, Dreamhost has taken some action to protect me from myself. Had I installed that plugin, I likely would have discovered it no longer worked: Dreamhost’s decision to block direct requests might have rendered it disfunctional. (If I were ignorant, I might have groused about the lack of functionality. )

I think Dreamhost itself forbids the ‘PUT’. But if they did not, it happens I also forbid “PUT” in .htaccess. That makes the ‘PUT’ attempts fail. With respect to site security, redundancy can be a good thing, especially when you aren’t sure whether your hosting company keeps up to speed on the list of vulnerable plugins or hacking behaviors being exhibited out ‘in the wild’.

Even more fortunately, developers writing plugins for WordPress are becoming more security minded. They tend to preface plugins with commands like
if ( ! defined( 'ABSPATH' ) ) die( "Aren't you supposed to come here via WP-Admin?" );
This prevents a plugin containing that bit of code from actually doing anything if called directly rather than through WordPress itself. Limiting use to ways that are intended reduces the potential for harm even if the plugin has some other vulnerability. Unfortunately, the practice of adding code to ensure the plugin is only functional if called through WordPress itself is not yet universal. But the fact the practice is increasing is one reason why people should update plugins regularly. I do update plugins as soon as newer versions are available.

With that, I’ll end my saga of describing something that really is a hack attempt and why it didn’t work (this time. I’ve got my fingers crossed that future attempts also won’t work.)

For those wanting discussions of temperatures: With any luck, Roy will announce temperatures soon and the next post will be about climate or weather. 🙂