a mod_security rule is breaking one script on one account

[Metro2]

One of my customers has a shopping cart script which as an element that calls to to a "user_password.js" javascript file.

mod_security is preventing that file from operating, giving it a 406 denial.

I have discovered the mod_security rule that is causing this, the particular part highlighted in bold:

# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
        "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
       "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'" 

Is there any proper way for me to modify this so that it does not affect the cart script on this one account? I don't want to disable mod_security completely, and I'm not sure how crucial that particular rule is so I'm afraid to remove it. Is there a better option for me?

Thank you for any help, this problem is holding up an important job.

[Metro2]

The only thing I've been able to discover so far is that any time mod_security sees a call to user_password in a script, it denies access to it. Unfortunately the script my customer needs to use calls to a file names user_password.js , and mod_security is preventing it from being accessed.

Does anyone know of anything I can do?

[darren.nolan]

The only thing I've been able to discover so far is that any time mod_security sees a call to user_password in a script, it denies access to it. Unfortunately the script my customer needs to use calls to a file names user_password.js , and mod_security is preventing it from being accessed.

Does anyone know of anything I can do?

Remove the rule that causes the error. Of course by doing that you weaken your security setup by that little bit more.

It's a Security vs Usability debate that has been going since the dawn of time. I believe I have disabled that rule in particular for the same reason. I'd have to check for the specifics.

[Metro2]

Thanks for the reply Darren.

I tried removing little bits and pieces, rules here and there, only to find out that the only way to really get mod_security to grant access to files named user_password.js is to completely remove the entire blocks of SQL Injection protection.

I'd have to remove all of this:

# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
        "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
       "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'"

# SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \
        "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:user_(?:(?:object|table|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|substr(?:ing)?|table_name|mb_users|rownum)\b" \
        "capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950906',severity:'2'"

Which is a pretty major "weakening" of it. Like, to the point that there'd almost be no reason to keep running mod_security, since (if I understand correctly) those sections are what protect most database-driven PHP sites.

ugh...

[darren.nolan]

Yeap - it's how it happens.

This is why most PHP programmer actually build protection into their own to stop injection attacks either through URL or Form use.

Having said that - Joomla STILL after many crys on their forums is still wide open for such attacks.

I use a combination of mod_seucirty and suhosin to stop such things - without killing usability all together.

I found that mod_security with the default ruleset never stopped all attacks on Joomla site - suhosin was the margin of protection needed to fix it up.

Hurray for security.

[richenou]

hi
which ruleset of modsecurity (for Apache2.0) do you use pleasE? (where can I download it?)


I have some problems with this one for the administrator area( error 404) of joomla 1.5


I use this one:

<IfModule mod_security2.c>

#
# Mod Security2 Rules
# Modified September 17, 2007
# base on Kris S. - HostMerit.com's rules
# by Tim Schoondergang - TimmiT.nl
# mail: Tim.Schoondergang@TimmiT.nl
# For use on CPanel servers with Mod_Security2

[Infopro]

The only thing I've been able to discover so far is that any time mod_security sees a call to user_password in a script, it denies access to it. Unfortunately the script my customer needs to use calls to a file names user_password.js , and mod_security is preventing it from being accessed.

Does anyone know of anything I can do?

What script/cart is it? Can it be upgraded to solve this or this file be renamed and still work?

[Metro2]

What script/cart is it? Can it be upgraded to solve this or this file be renamed and still work?

It's a paid cart and I don't know if I should name it here, but I can answer your other two questions since I've sent a lot of related info to their support since I originally encountered this problem, and here is what I've found:

- Renaming the file can't be done because the use of it is so heavily encoded into the script.

- The developer says they will be providing a fix for this in a future upgrade, but there is no set date / ETA yet.

[Infopro]

How about setting those particular rules to log and pass then, might be possible to at least keep an eye on it that way. Remarking them out would get you going till the devs work out a fix for the cart of course. If its a paid cart and not publicly accessible you might be ok, short term although I'm not sure I'd want to chance it myself, depending on the situation. (backups might be a good thing to have if you disabled them and get hit.)

BTW, I did find a post on a forum for avactis stating they too are having this problem and would fix for next release. Of course that was posted in March.

[brianoz]

Mod Security rules can be disabled on a rule-by-rule basis for individual users. You can do it in .htaccess files.

The other option might be to use mod_rewrite to work around the problem named script, although the mod_security solution is probably the correct one.

[sneader]

Mod Security rules can be disabled on a rule-by-rule basis for individual users. You can do it in .htaccess files.

I'm going to start searching for the answer... but if you could provide an example, I would sure appreciate it !!!

- Scott

[sparek-3]

Notice that the rules in question in the first post have an ID:

msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007'

msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904'

For the first rule the ID is 950007 and the second rule's ID is 950904. In order for this to work each individual rule needs to have its own ID.

Now when you find an ID is being hit by a particular account you can remove that ID for that account with:

SecRuleRemoveById 950007 950904

Normally what I would do is I would add this to a modsec.conf file in the userdata directory for that account:

mkdir -p /usr/local/apache/conf/userdata/std/2/username/domain.com
vi /usr/local/apache/conf/userdata/std/2/username/domain.com/modsec.conf

(Use whatever text editor you prefer, I'm partial to vi)

Then in the modsec.conf file add:

<IfModule mod_security2.c>
SecRuleRemoveById 950007 950904
</IfModule>

Or if you just want to isolate this to a specific directory or path you can use:

<IfModule mod_security2.c>
<Location /path>
SecRuleRemoveById 950007 950904
</Location>
</IfModule>

excluding the <Location> container will disable these rules for the entire virtualhost.

Now include that file:

/scripts/ensure_vhost_includes --user=username

Replace username with the owner of the account and replace domain.com with the virtualhost servername for that account.

[sneader]

sparek-3, Thanks for the great info. I just shot you a PM also.

- Scott