smd_prognostics: monitor your Txp installation for suspicious activity

maverick · 2010-11-16 01:51:24

Bloke – a clarification — smd_prognostics is installed on both domains of the multi-site install.

domain 1 is showing x files being monitored of x number of total files. domain 2 is showing x files being monitored (same number as in domain1) of 0 files being monitored.

There are no files being shown. i.e. – literally the select box of files is not showing

update1: I hit save any way on domain2. now it reads that I’m monitoring 0 of 0 files.

update2: Now domain1 has 0 files being monitored.

Apparently hitting save on one domain changes the other domain.

fwiw

Last edited by maverick (2010-11-16 01:55:28)

Bloke · 2010-11-16 15:11:12

To continue the flurry of releases, v0.14 is out. Changelog:

Can now throw HTTP response code or a custom message / TXP form instead of ‘nice try’
Added independent forensic options for header spoofing/SQL injections
Wildcard ability for ignored files — so you can now monitor directories such as tmp for additions and perhaps specify *.tmp in the Ignore files box if you don’t want to be alerted about such files. The usual * and ? wildcards are supported
Added user check so you can now restrict the plugin to certain logins (thanks maverick)
Added TXP dir option which helps multi-site installations (thanks maverick)

Couldn’t find out why the ‘New version’ advice check is firing for Stuart and Mike. No matter what I do with my SVN installation — upgrade it, muck about with settings, whatever — I can’t make that piece of advice fire. When I get a chance later I’ll log into Mike’s server and see if I can figure out how things are different to my server and that should lead me to the solution.

In the meantime I thought I’d rush this one out so Bert has the option to pare back or customise the volume of forensics data from the (many) attacks he gets on PHPXref :-)

Last edited by Bloke (2010-11-16 15:13:27)

hcgtv · 2010-11-16 15:42:29

Bloke wrote:

In the meantime I thought I’d rush this one out so Bert has the option to pare back or customise the volume of forensics data from the (many) attacks he gets on PHPXref :-)

Upgraded to Textpattern 4.3.0 and version 0.14 of the plugin. I kept the same parameters in place for now, I’m liking frognostics and all the info it sends me on the attacks. I did get Alarms for all the files that changed and were added, I just acknowledged them.

Bloke · 2010-11-16 16:05:16

hcgtv wrote:

I kept the same parameters in place for now

Oki doke. As long as you checked all the settings were still the same on the screen and Saved them after upgrade, everything will continue to work. Some of the names of things have changed internally so some of your options may have flicked on or off during the upgrade.

I’m liking frognostics and all the info it sends me on the attacks

Me too. Had a really juicy one earlier with someone trying to install a c99shell-type script from your contact form.

But the plugin can trip out on legit content too — Mike tried to send me an e-mail last night and the plugin threw its toys out of the pram. Luckily I had forensics switched on so it sent me the message anyway along with all the other server info for me to analyse so I can try to reduce the false-negative rate. With the new HTTP response code headers in play and the forensics switched on I can now deliver a nicer message saying that the request has been quarantined but I still received it.

Alternatively for the ultimate low-radar approach I could set it to trigger a 200 (OK) request and defer processing to a TXP form. In that form I could analyse the content and server information further there to decide if the attack really was an attack or not, taking action accordingly. For example I could forward the request on to its intended destination and return a success message, or grind to a halt, select some pertinent data and stuff it aside for later analysis. Sky’s the limit here so the fact the plugin triggers an SQL injection warning need not be the end of the road.

hcgtv · 2010-11-16 16:46:28

Bloke wrote:

Alternatively for the ultimate low-radar approach I could set it to trigger a 200 (OK) request and defer processing to a TXP form.

Could you clarify these new settings:
Protect against SQL injection: Block, 200, 404, etc.

What happens when I set it to a status of 200 lets say? Does it still report on it and pass it over to Textpattern?

Bloke · 2010-11-16 17:07:40

hcgtv wrote:

What happens when I set it to a status of 200 lets say? Does it still report on it and pass it over to Textpattern?

When you set a status code from the list, the plugin simply does a redirect with the appropriate status code. So if you chose 403 you could create an error_403 Page template and display whatever you like to people there (though you would also get regular 403s being directed there too — I have some ideas about this which I may yet implement). With a status of 200 you’ll just get sent back to your home page I should think.

But before it redirects you, the plugin does the following:

If you have ticked the SQL Injection ‘Send Forensics’ box then forensics data is sent to the forensics e-mail address
If you have put a custom message in the ‘with’ box then that will be the message you will see as Body text in your page template (if you’ve chosen the Block option then that’s the only message you’ll see on a white background — the same as the ‘nice try’ in previous versions)
If you have used txp_form:some-form as your ‘with’ information then control is handed over to the nominated form. You can do whatever you like here: dump information, run some PHP, set a message depending on some server vars, show an image, use TXP tags, whatever you like. Then, as long as you don’t call exit() from inside your form, the contents of the parsed form will be returned to the plugin which will then pass that to the error page as Body text

It’s just a simple way to insert content into a custom error page really. A good usage of the txp_form might be if you have turned forensics off because you think it’s too intrusive. You could whack a little bit of PHP in your form that gathered less sensitive data or filtered the info somehow and fired off your own e-mail or a text message or whatever.

It could even look at the request headers and decide that smd_prognostics was being over-zealous and override its decision: perhaps set your own header() or grab the REQUEST_URI and forward the visitor there. Or you could just return nothing (exit) or return a message inside the error Page. It really is up to you.

I’m toying with the idea of allowing you to return a particular status code to the plugin (probably just a string like smd_false) that would tell the plugin it made a mistake and not to display the error page but process the request as normal. You still get the benefit of having the optional forensics sent and your own filtering or analysis done in your custom form, but it’d be simpler to override the smd_prognostics decision. It’s a piece of cake to implement but I gotta decide if that’s worth doing or if it opens up a security hole.

In the meantime, plenty to get your teeth into :-)

hcgtv · 2010-11-16 18:20:29

Bloke wrote:

In the meantime, plenty to get your teeth into :-)

Nice explanation, thanks.

When I finish up with something I’m doing now, I’ll dedicate a bit more time to understanding smd_prognostics and what I can do with it.

On PHPXref, I get a lot of script kiddies coming after the projects cross referenced there. When the new site is launched, I want to show the top exploits, a sort of radar warning to web publishers as to what’s making the rounds.

I’m so glad I’m running Textpattern, because if I placed any other script in the root, I think I would have been hacked years ago.

Bloke · 2010-11-16 19:27:06

hcgtv wrote:

I’m so glad I’m running Textpattern, because if I placed any other script in the root, I think I would have been hacked years ago.

:-)

On this topic, Steve brought my attention to something the other day — a kind of attack I’d not considered and it seems your script kiddies might be trying it in droves. Essentially it involves hitting the same ‘exploit’ over and over with identical or very similar data. Except it’s not an exploit as such against TXP or WP or in fact any front-end system because they’re mostly hardened against such things.

Instead, by using repetition and links to an external site that contains exploit code, they’re relying on you to launch it by doing something that most of us do regularly: check our web stats. 1000 GETs have been dutifully logged by your stats package, you view the stats and 1000 GETs are executed by virtue of that data occupying the number one slot in the list. That’s when the exploit code is deployed.

That’s why I partly hate shared hosting because things like cpanel jam so much crap into an account — and I only use about 6 of the apps — that they can’t all be secure. It only takes one person to use an app that’s not been hardened and all accounts on the shared box are compromised (which is what happened to Mr Potts I believe).

A sobering thought but hopefully smd_prognostics can offer some help by blocking this stuff before it reaches the stats packages.

maniqui · 2010-11-16 20:20:25

Hi Bloke,

Just started to play with this Cerberus of TXP gates.

Two quick questions:

1) Do you have any advice on a standard/basic/default set of files that should be monitored and which files doesn’t deserve that much monitoring? Common sense says that I should let smd_prognostics watch for PHP files, but don’t be too worried about .css, .ico or .txt files.
But then, does every PHP file in a TXP deserve to be checked?
What about JS files? Are there the target of common attacks?

2) Is there any chance to add the option to exclude symlinked folders/files that are are already included in their “physical” location? Or maybe, the “Exclude folders” option could also accept this kind of paths: txp/plugins/active, instead of just active (which will match any active/ folder).

Certainly, smd_prognostics makes it easier to check multiple sites running on a single TXP installation. And if you also include plugins (running from plugin_cache_dir) and pages/forms (created on filesystem via cnk_versioning), you cover a few more corners…

On a side note, I think it’s time for me to post a new thread or a TXP Tips with the results of my symlink-frenzy-for-an-agnostic-multi-install-setup-for-hardcore-TXP-developers R&D. Or something like that.

maverick · 2010-11-16 21:22:15

w/ CSS3 bringing animations/transitions/transforms, and media queries, plus the existing links to other files (nominally graphics), I’m wondering if css files might be worth keeping an eye on . . . .? Just thinking that someone might find a way to exploit them?

Then again, I’m not a hacker, so maybe it doesn’t pose a concern?

maniqui

This isn’t a permanent fix, but I was having problems at first with the symlinks as well – primarily because they allowed the themes show up over and over again.

However, I’ve excluded themes (and templates) for now; the remaining symlinks (the two js files, the css file, and the txp_img directory are pretty managable (imo) compared to the others. fwiw.

But out of the box exclusion of symlinks would be nice.

net-carver · 2010-11-16 21:57:21

Bloke wrote:

On this topic, Steve brought my attention to something the other day — a kind of attack I’d not considered and it seems your script kiddies might be trying it in droves.

Hi Stef. You are quoting me slightly out of context I think. I wasn’t saying they were trying that on Bert’s site (though they might well be), I was merely pointing out one possible avenue of exploits that had not previously occurred to me but that reading about the dark side had revealed.

You are right, however, that this brings the old ‘the-chain-is-only-as-strong-as-the-weakest-link’ idea into focus for web based software, and particularly so with shared hosting. It isn’t just what cpanel/stats packages/webmail scripts are doing, you also have the custom scripts/OSS packages that any one of the shared users on that box are running! I can’t even say that my own plugins have been audited for weaknesses :(

Bloke · 2010-11-16 22:45:47

maniqui wrote:

Do you have any advice on a standard/basic/default set of files that should be monitored

Yes. The .php are the obvious contenders — especially things like index.php and config.php which appear to be common targets. I would always include .js too since the script that hit our work server added a line to the end of most .js files which tried to download a Java app and run it on the local machine through a JVM loophole.

I contemplated not bothering with .css either but I guess there’s nothing to stop someone adding this rule to a default.css file:

body {
   background-image: url(http://evil.com/banner.jpg);
}

So perhaps it’s prudent to monitor them, though I’d say this is definitely secondary. Won’t affect your CSS served form the DB of course. Up to you for .txt and .ico files etc.

One thing you definitely should monitor though is file additions. Things like c99shell and its derivatives are just uploaded and stored in a remote corner of your site — sometimes in the tmp dir. A. T. Acker knows where they are and can just invoke http://site.com/textpattern/tmp/c99shell.php and then run amok from there. Monitoring file mods is important but additions are a very close second.

The trouble with monitoring additions is that the Exclude dirs aren’t monitored. That’s why I added wildcard support in v0.14. Monitoring additions also adds time and the worst part is that — while modifications are done in chunks — additions are currently processed every time. Take this example: you have a bunch of directories you are monitoring and your Files page says “You are monitoring 130 out of 500 files”. You elect to process the mods in chunks of 30 files every 10 seconds. What’s really happening is this:

it checks the first 30 files for mods
it grabs every remaining filename in your list of Folders to monitor
it looks at the remaining 370 filenames in the checksums file to see if there are any real files that are not in the list

It’s doing that every time it runs, advancing the mod pointer by 30 files each time but then checking all remaining (non-monitored) files. That’s quite an overhead and I’m trying to figure out how to reduce it without compromising security. I can’t process the remaining files in chunks because how will I know what’s different? There’s probably a way of doing it by simply hashing the remaining files or counting the number of files per directory and only bothering to look in detail if the counts differ. Will work on that over time.

2) Is there any chance to add the option to exclude symlinked folders/files that are are already included in their “physical” location? Or maybe, the “Exclude folders” option could also accept this kind of paths: txp/plugins/active, instead of just active (which will match any active/ folder).

The former should be possible if I can stat() each dir as I think it says whether it’s a symlink or a real dir. I could probably do the latter if I thought about it hard. Was on my hit list of things to think about a while ago but I forgot. Thanks for the reminder.

Steve

Yes, sorry, the post wasn’t clear. I didn’t mean that you’d said Bert’s site was being targeted — that’s something of which I’ve since come to the conclusion after looking at the volume of incredibly similar attacks coming through every few minutes.

Last edited by Bloke (2010-11-16 22:51:14)

Textpattern CMS

Textpattern CMS support forum

#37 2010-11-16 01:51:24

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#38 2010-11-16 15:11:12

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#39 2010-11-16 15:42:29

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#40 2010-11-16 16:05:16

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#41 2010-11-16 16:46:28

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#42 2010-11-16 17:07:40

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#43 2010-11-16 18:20:29

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#44 2010-11-16 19:27:06

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#45 2010-11-16 20:20:25

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#46 2010-11-16 21:22:15

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#47 2010-11-16 21:57:21

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#48 2010-11-16 22:45:47

Re: smd_prognostics: monitor your Txp installation for suspicious activity

Board footer