Textpattern Forum

You are not logged in. Register | Login | Help

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

hcgtv
Member
From: Charlotte, NC
Registered: 2005-11-29
Posts: 2,154
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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?


txp:tag – Textpattern Tags ~ TxPlanet – Textpattern Planet

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,832
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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:

  1. If you have ticked the SQL Injection ‘Send Forensics’ box then forensics data is sent to the forensics e-mail address
  2. 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)
  3. 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 :-)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Offline

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

hcgtv
Member
From: Charlotte, NC
Registered: 2005-11-29
Posts: 2,154
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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.


txp:tag – Textpattern Tags ~ TxPlanet – Textpattern Planet

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,832
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Offline

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

maniqui
Moderator
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 2,976
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

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

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 751
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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.

Offline

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

net-carver
Admin
From: UK
Registered: 2006-03-08
Posts: 1,648

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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 :(


Steve
Textile | My plugins on GitHub | @netcarver

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,832
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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:

  1. it checks the first 30 files for mods
  2. it grabs every remaining filename in your list of Folders to monitor
  3. 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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Offline

#49 2010-11-19 12:07:36

roelof
Member
Registered: 2005-03-27
Posts: 645

Re: smd_prognostics: monitor your Txp installation for suspicious activity

Hello Steven.

I have a little problem.
On the first tab I made changes.
Then I do save and evrything is reverted to the old situation.
Also on the files tab I see a message that no files were selected.

Roelof

Offline

#50 2010-11-19 12:52:59

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,832
Website

Re: smd_prognostics: monitor your Txp installation for suspicious activity

roelof wrote:

On the first tab I made changes. Then I do save and evrything is reverted to the old situation.

Are you on 4.3.0? This plugin is not designed for anything less (you will see this behaviour on 4.2.0).

Also on the files tab I see a message that no files were selected.

Once you have set up your File locations to point to valid directories, when you visit the Files pane you need to select the files you wish to monitor and hit Save. The plugin does not automatically monitor files for you as it does not know exactly which files you care about!

Hope that helps.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB