smd_prognostics: monitor your Txp installation for suspicious activity

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)

roelof · 2010-11-19 12:07:36

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

Bloke · 2010-11-19 12:52:59

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.

roelof · 2010-11-19 13:00:00

Hello,

Im sure. See this:
Textpattern versie: 4.3.0 (r3451)
Laatste update: 2010-11-07 11:14:11/2010-11-07 10:38:34

I set the file location but as I said as soon as I hit the save button everything gets reverted to the old situtation.

Roelof

Bloke · 2010-11-19 13:08:08

roelof wrote:

I set the file location but as I said as soon as I hit the save button everything gets reverted to the old situtation.

Weird. What version of PHP are you using? Might be a function mismatch somewhere that’s causing it the plugin to cry.

maniqui · 2010-11-19 13:08:49

roelof,

may it be that your “Prognostics folder” setting isn’t pointing to a writable folder?
This caught me the first times.

roelof · 2010-11-19 13:12:29

Hello,

PHP version : PHP versie: 5.2.4-2ubuntu5.12
All folders are 755

Roelof

Bloke · 2010-11-19 13:15:05

maniqui wrote:

may it be that your “Prognostics folder” setting isn’t pointing to a writable folder?

Ooh, yeah that also. Good catch. In theory, when you alter the location of the folder it checks if the folder you typed in exists and is writable. If one or more of those conditions are not met, the plugin will automatically revert your Prognostics dir setting back to what it was (and probably do it without warning). So make sure you have created the destination folder first before trying to change the setting.

I haven’t figured out the best way to offer advice on a per-setting basis yet — I experimented with the File locations setting so if you change it you’ll see a link + message appear below that setting, warning you about the change. But it’s a bit rubbish putting it there because you probably won’t see it so I should rethink that bit and also offer warnings elsewhere in the panel after Save. Thanks for the pointers.

So after you have tried to Save the Files, please use your FTP program to verify that the smd_prgnostics_checksums.txt file has been created in the place you have defined. If it hasn’t, check that the folder exists.

Last edited by Bloke (2010-11-19 13:16:35)

roelof · 2010-11-19 13:23:15

Oke,

I understand this.
Is 755 good for a folder. The files are now pointing to the root of my website so the folder exist.

Roelof

maniqui · 2010-11-19 13:33:59

Bloke wrote:

If one or more of those conditions are not met, the plugin will automatically revert your Prognostics dir setting back to what it was (and probably do it without warning).

Yes, when I installed it, I think this is what happened.
To be more precise:

I pointed “Prognostics folder” to a non-writable folder and hit “Save”
It reverted back and silently to /path/to/folder/textpattern/, if I recall correctly.

IMHO, it should “fail” better than that :)
I mean, reverting back to /path/to/folder/texpattern (at least on my install that’s what happened) is not only a bit confusing, but somewhat dangerous: the end-user may wrongly think that it should set the textpattern/ folder to be writable. Not good for a plugin that is taking care of our TXP babies :)

roelof · 2010-11-19 13:38:34

Oke,

Is 755 not writeable then ?

Roelof

roelof · 2010-11-21 11:26:32

Hello,

Nobody who can help me to get this plugin working ?

Roelof

Bloke · 2010-11-21 12:44:11

roelof wrote:

Nobody who can help me to get this plugin working ?

If you’ve checked everything that has been suggested so far then I don’t know if it’s possible to diagnose your problems without more information such as file paths and permissions, etc. Since it’s not advisable to post those, the only thing I can suggest is granting someone a login to your site.

P.S. I’ve improved the warnings in the next version of the plugin so it gives the usual flashy warning in the message area if things aren’t quite right.

Last edited by Bloke (2010-11-21 12:45:37)

Textpattern CMS

Textpattern CMS support forum

#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

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

Re: smd_prognostics: monitor your Txp installation for suspicious activity

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

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#51 2010-11-19 13:00:00

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#52 2010-11-19 13:08:08

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#53 2010-11-19 13:08:49

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#54 2010-11-19 13:12:29

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#55 2010-11-19 13:15:05

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#56 2010-11-19 13:23:15

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#57 2010-11-19 13:33:59

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#58 2010-11-19 13:38:34

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#59 2010-11-21 11:26:32

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#60 2010-11-21 12:44:11

Re: smd_prognostics: monitor your Txp installation for suspicious activity

Board footer