smd_prognostics: monitor your Txp installation for suspicious activity

ruud · 2010-11-14 21:48:20

Not sure I follow. An admin-side “attack” is one that begins http://site.com/textpattern/some_file?attack=content. […] if $txp_user is set during an “attack” (primarily a save operation) don’t run the prognostics check.

But if you base that decision on whether $txp_user is set, then the assumption is that any potential damage happens after the authentication. In that case you can simply ignore all admin-side attacks, because $txp_user is not set, then the attack will lead simply result in a login form being returned to ‘evil person’. And if the authentication part of the code is vulnerable, you’d be too late if you base your decision on $txp_user being set or not.

Bloke · 2010-11-15 09:01:47

ruud wrote:

the assumption is that any potential damage happens after the authentication.

D’oh, of course you’re right. Told you I wasn’t following. Right, admin side injection will be gone in the next version Thank you for putting me straight.

Bloke · 2010-11-15 15:00:11

smd_prognostics v0.13 is released. In this version:

Fixed Alarms panel so it now always displays all alerts and doesn’t interfere with the file checking rotation
Fixed incorrect URL in acknowledge messages (thanks thebombsite) though multi-site installations may still be wrong
Removed dumb admin-side SQL injection (thanks ruud)
Added Check files between (thanks ruud)
Added TXP version advice (thanks ruud)
Tweaked injection detector for performance reasons
Refactored e-mail header code to save repetition

thebombsite · 2010-11-16 00:02:54

Well I see the Txp version advice is working Stef. I now get the message:-

A new version of Textpattern is available: 4.3.0

which is fine, but I assume it shouldn’t appear if you are already using 4.3.0 so I presume I am seeing it because I am on SVN?

Bloke · 2010-11-16 00:54:16

thebombsite wrote:

I presume I am seeing it because I am on SVN?

I guess so. Odd because the ‘version’ entry in txp_prefs should still be 4.3.0 even if running SVN. What’s your version string set to? And what version does it report at the bottom of the admin side in Classic? If either is 4.2.0 then that explains the message, but doesn’t explain how you could be running 4.3.0 unless the upgrade to the final 4.3.0 didn’t quite set everything it should.

Of course there’s also the possibility that my code is broken but I stole most of it directly from txplib_update.php so I thought it’d be robust enough. I’ll give this some testing tomorrow before I release the next version (sorry for the flurry of updates) which has another couple of useful options in it.

Last edited by Bloke (2010-11-16 00:54:48)

maverick · 2010-11-16 01:00:46

Like Stuart, I’m on svn. And am also getting the message abt. a newer version.

Diagnostics shows: Textpattern version: 4.3.0 (r3458). Also showing 4.3.0 at the bottom on the admin side in classic.

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

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.

Textpattern CMS

Textpattern CMS support forum

#31 2010-11-14 21:48:20

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#32 2010-11-15 09:01:47

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#33 2010-11-15 15:00:11

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#34 2010-11-16 00:02:54

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#35 2010-11-16 00:54:16

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#36 2010-11-16 01:00:46

Re: smd_prognostics: monitor your Txp installation for suspicious activity

#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

Board footer