Sentinel Scripts and Calendar

Posted: Mon Jun 26, 2006 3:01 pm

I'm using Sweetphp's TotalCalendar software with my Ravennuke system and Sentinel PL9.

One of my users is getting booted by Sentinel for the following script:

Quote:

Date & Time: 2006-06-26 13:11:19 PDT GMT -0700 Blocked IP: xx.xxx.46.55 User ID: xxxx (xxxx)
Reason: Abuse-Script
--------------------
User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Query String: xxxx.org/rn/modules.php?name=Event_Calendar&file=nuke_loader&dir=admin&extra_file=manage_events
Get String: xxxx.org/rn/modules.php?name=Event_Calendar&file=nuke_loader&dir=admin&extra_file=manage_events
Post String: xxxx.org/rn/modules.php?name=Event_Calendar&file=nuke_loader&id=8&action=Save Changes&selectedRepMethod=4&eTitle=MHCC Century&eDesc=MHCC CENTURY WEEKEND (More info to come in July and August BikeAbouts)  September 9 & 10, 2006 <place w:st=\"on\"></place><city w:st=\"on\"></city>Saratoga Spa State Park( Forwarded For: none Client IP: none Remote Address: xx.xxx.46.55 Remote Port: 1265 Request Method: POST

Reading Sentinel it looks to me like he's getting hung up on:

Code:

 foreach($_POST as $secvalue) {


      if((eregi("<[^>]*onmouseover*\"?[^>]*>", $secvalue)) ||


      (eregi("<[^>]script*\"?[^>]*>", $secvalue)) ||


      (eregi("<[^>]*body*\"?[^>]*>", $secvalue)) ||


      //(eregi("\.\./", $secvalue)) ||


      (eregi("<[^>]style*\"?[^>]*>", $secvalue))) {


        block_ip($blocker_row);


      }

Am I reading it right that it would block the string "style"?

TotalCalendar uses the fckeditor and gives the users a nice big area to input the descriptions of events they are planning. I know a lot of them compose the events in Word and try to copy and paste it in. Word gives me heartburn with the way it composes html but that's a different issue. Is this just not going to work if I leave the scripting blocker turned on or should I tell the users they can't copy and paste from Word or am I totally off base on my diagnosis of the problem. Has this issue surfaced with the implementation of fckeditor more generally?

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

I haven't seen that issue. Have you tried the Paste from Word button? It removes a lot of the extraneous stuff Word adds.

Could it also be these non-standard tags?

Code:

<place w:st=\"on\"></place>


<city w:st=\"on\"></city>

Try it without that to see if it's blocked.

Posted: Mon Jun 26, 2006 8:30 pm

I will try your suggestions, thanks. I need some eregi lessons but it does look to me that the string "style" might be blocked.

One problem is that I have opened up calendar entries to users and I have little control over what they might copy and paste in there or how they do it. I just wind up unbanning them afterwards. Tomorrow I will cook something up in Word and try it a couple of ways.

Posted: Mon Jun 26, 2006 8:35 pm

For reference, in which file did you find that code?

registered · Posted: Tue Jun 27, 2006 6:22 am

YEs, you guys are correct. That is exactly what is stopping this. (Its in includes/nukesentinel.php, or are you asking which calendar file?) Personally, I think it is very poor architecture for TotalCalendar to be doing this on the GET string, but that is besides the point.

Unfortunately, removing that check opens you up. You may need to put a check in nukesentinel.php to not do that check if the module name is Event_Calendar.

Posted: Tue Jun 27, 2006 6:33 am

LOL, okay I want to understand more as usual Montego. First of all this is in the post string, not the get string. I can understand how you would want to filter out the script tag, you certainly don't want someone embedding a script. But why not a style? If it's a style from a css file wouldn't it have to be loaded on the web site itself and thus not a vulnerability? Or is the worry that they could load a style sheet from an external site? But I don't see how they'd do that (I'm debating myself). If it's an inline style ... well they couldn't put a script inside the style and what other harm could they do?

As we move more to wysiwyg editors aren't we going to be seeing more html, including styles inside what gets "posted" and are we going to have more and more fights with Sentinel? Kguske would know more about the editor issue I'm sure.

Posted: Tue Jun 27, 2006 7:04 am

Sorry about the GET vs. POST! I didn't read it carefully enough. Embarassed

style is not allowed for user input because it can open up, I believe, to XSS style attacks. BUT, I am sorry to say, you will have to ask the experts on that (Raven and BobMarion). I would have to guess it has something to do with being able to pull in "images" from anywhere, and they may not really be images????

Quote:

As we move more to wysiwyg editors aren't we going to be seeing more html, including styles inside what gets "posted" and are we going to have more and more fights with Sentinel? Kguske would know more about the editor issue I'm sure.

I say the following without alot of "thought": it is definitely going to be a problem! Even if the editor is coded well enough to also check for XSS and other style of exploits, one can still bypass the editor with a direct get/post attack.

What we may have to investigate further, is the actual kses functions to see if they are appropriately validating the style tags, but doubtful, because it would have no idea if an image is really an image.

Don't know how to resolve this except cut off the hands of every hacker in the world and see if that would deter new ones from getting "into the trade"...

Posted: Tue Jun 27, 2006 9:11 am

I've been trying to duplicate the problem all morning and getting nowhere. I don't have event calendar at my test site and I don't want to mess with my production site and sentinel isn't working right on my localhost so that makes it all the more complicated. But I did try submitting news after copying and pasting in from word. Kguske is of course perfectly right that the "paste from word" option cuts out a lot of junk that Word would otherwise include (unnecessary styles etc.).

But I have been unable to get Sentinel to choke on the post strings. It appears to me that the codes are somehow encapsulated and not exposed to the Sentinel filters, the exact mechanism by which I don't understand. I put some echoes into sentinel to show the get and post strings as well as the $secvalue down where it does foreach ($_Post ...)

Here's what shows on my screen after submitting a simple news article with a few bolds and centers in it from word:

Quote:

query string name=Submit_News
get string name=Submit_News
post string subject=this is any story&topic=1&story=

This is bold

This is centered

This is from word

This should be enough
&storyext=&op=Ok!
this is any storysecvalue
1secvalue

This is bold

This is centered

This is from word

This should be enough
secvalue
secvalue
Ok!secvalue

The bolded text shows as bold but the centered isn't centered.

And here's the view source (sorry it's a bit much but such a lot of info in there):

Quote:

query string name=Submit_News get string name=Submit_News post string subject=this is any story&topic=1&story=This is bold                  
 
This is centered 
 
This is from word
 
This should be enough&storyext=&op=Ok! this is any storysecvalue 1secvalue This is bold                  

 
This is centered 
 
This is from word
 
This should be enoughsecvalue secvalue Ok!secvalue

So you can see that there's lots of style codes in there but Sentinel isn't objecting.

In short I'm not sure why that event calendar entry was blocked and it appears that the wysiwyg editor generally gets past Sentinel (or we would have seen a lot of problems earlier than this).

Posted: Tue Jun 27, 2006 8:34 pm

By any chance were you logged in as admin when you were doing these style checks? Take a closer look at the top of the Scripting attack code in nukesentinel.php. Wink

But, if that isn't it... we've definitely got some analysis to do... Sad

Posted: Wed Jun 28, 2006 7:16 am

Montego: no, I thought of that and was going back and forth between the plain user id. I also looked to make sure that I didn't have my IP address on the don't ban list.

As you know, testing this stuff can be a pain. Having the diagnostics in Sentinel for instance and dumping them to the screen stops the graphics in the login screen from working so you can't easily go back and forth between users without editing in and back out the diagnostics. It's another topic but I've been thinking how nice it would be if we had some kind of global diagnostics switch in Nuke (not just display errors which often doesn't work for me) and built certain variable and SQL "dumps" into the code to be triggered when diagnostics were on. End of digression.

Posted: Wed Jun 28, 2006 9:32 am

A good idea to have global diagnostics. Other great open source applications have that capability, and it shouldn't be too hard to implement. I think we should add it to the RN list.

Posted: Thu Jun 29, 2006 6:37 am

Quote:

Montego: no, I thought of that and was going back and forth between the plain user id. I also looked to make sure that I didn't have my IP address on the don't ban list.

Uuughhh... well, that is disconcerting. I have just PM'd you.

kguske: I agree. Do you mind adding it? thx.

Posted: Thu Jun 29, 2006 7:01 am

It's been added to our issues list.