Post
by butte » Sat Sep 07, 2013 6:16 am
The upshot of this is that the opening post above poses what seems from files examined this morning to span India, China, Middle East, Eastern Bloc in the old sense, and Russia, and is active "in the wild" against OC installations having various vulnerabilities that are NOT part of OC itself. It does appear that the ones going in via /download/ are just not very bright, while those a couple of more IQ points above 3 have become mildly savvy to malice.
Having just emerged from winning split-second live combat with a slowly keyboarding hacker while I took command of permissions and eradicated live files and vaporized his toys, I can add something current about the particular kind of error noted at the outset above, eval(base64_decode([gibberish]. There were two files publically addressable via http, quaintly named mls.php and grocery.php, whose identical content was an abutted triplet of long ago deprecated "short-tag" php (beginning <? rather than <?php) strung together as "eval(base64_decode('[...]))); ?><? eval(gzuncompress(base64_decode([...]))); ?><? eval(gzuncompress(base64_decode([...]))); ?>" (respectively about 20%, 20%, and 60% of overall length) on a single line stretching to 10,920 bytes, both dated 2011 May 20. Those were injectors. The .htaccess had earlier been emptied to zero bytes on On 2011 Mar 28 (it was, of course, rearmed this morning.) Two batches of files, 43.7 mb of 3,166 files ranging 2012 Feb. 29 through 2013 Aug. 30, 167.6 mb of 9,998 files ranging 2011 May 20 through 2013 Aug 28, posed names such as "samsung-galaxy-fit-price-in-bangalore.html5" along with the potent handful of "protect.php.html3" and similar bearing among them such commentary as "with such comments inside as, "Injection attacks with similarsecure and if cached similaronce Takes a web pages by just adding one of protect," and "Similarecho obj- gtprinthello shows public, how-to-protect-from-sql-injection-in-php-based-web cached jun," and in some places rerouting to a website in "cz.cc" where strange things go bump in the night or day, alike. Those were double-nested in 777 ".name/" directories which most people would probably miss. The rafts of oddball .html[x] files largely related, in plain as well as intricate ways, to the raft of OC demo image names and were evidently used to force index.php?route into adventures. There were signatures of brute force attack (against barriers), and of mime attack (for private data). In comparison to another incident involving multiples of 40,000 files similarly hidden, this morning's bettered sociopathic village idiot had only 211.4 mb of only 13,164 files total, before adding a few dozen more files in little batches this morning while I watched. The singularly quaint aspect of this morning's incident was a set of files whose extensions were .html\' (backslash being the problem, not the letters or tic) -- which, of course, neither Windows nor Linux fielded very gracefully when I determined to archive and delete them (as it were, ve haff vays).
[While simmering down I'll probably add notes to that through the day.]
The Apache http traffic logs show extensive calls for the now deleted files, and show attempts at entry from cellphones, a popular hacking method in the Middle East and elsewhere. Many, not all, of the deleted files appear to have sprung from India.
Mercifully, the attacks' gibberish engine-distracting files did NOT trigger the safety-check algorithms into "The Letter" which Google WOULD send saying that searchability is shut down till it's cleaned up and resubmitted and then searchability starts all over, again. In the other instance noted above, that consequence had occurred, the algorithms triggered "The Letter" and Google took it off the rolls.
The OC /system/logs/ error log, small at cumulative 62 kb, ranged from 2012-11-29 3:49:14 through this morning, and the content is instructive. As vqmod had not yet been installed, there were no /vqmod/logs/ to examine.
There were few sessions, only 20 in all, all dated 2011 Nov 23-24, all now deleted. Runaway sessions (thousands of them, many times per minute and per second) tend to arrest system administrators' attention and to cause websites to be shut down for repair. Those can spring from hacking, from misconstructed feeds, goofy engines, and other causes.
All /system/cache/ files were flushed in order to remove any residual activity, during the melee and after it was done. That dir had been mis-set to 777 (now back, of course, to 755). The cache helped to perpetuate what was going on and mostly was reset the the prior few hours and days.
Mind what you archive onto your own machine, raw or inside .zip, so as not to put it back onto a server.
Check whether the root php.ini file, notwithstanding whether it has any effect on a given server or not, has been fiddled with after it was first put in place. Interception or on-screen perusal of thrown errors gives hints of server and website organization.
Double-check whether the root Google file is the proper number.
Be certain afterward to reset critical database parameters in a cold-bloodedly sudden switch including control panel and both config.php while all is safely dead in the water (with the shop in Maintenance mode meanwhile). The same holds for renaming /admin/ and /download/ if that is done. A basic means on many servers of passwording /admin/ (via control panel rather than via manually editing control files) requires that it not have its own .htaccess file (the one in root should suffice for what .htaccess itself does, while certain other .ht* files don't get along with it in the same directory).
[Still grumpy.]
Two, possible infection.
It's all good. Market is correct. Let's fix the issue first, then direct him to another web host!
