Dear Christian,
Dividing the pm file into several parts for eliminating false
positive sounds good for me. Should there be another rule id for
carrying the pm file for being associated with the paranoia mode
one? Thanks!
--
BR, Morris
On Tue, Feb 2, 2016, at 04:17 PM, Christian Folini wrote:
> Hello,
>
> I'd like to discuss them here one by one.
>
> Controversial Paranoia Mode Candidate 950907 (2.2.X) / 932100 (3.0.0rc1)
> msg: Sytem Command Injection
>
> Rule in 2.2.9:
> SecRule
> REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*
> "(?i:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))" \
>
> "phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'8',capture,t:none,t:normalisePath,ctl:auditLogParts=+E,block,msg:'System
> Command
> Injection',id:'950907',tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched
> Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
> %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"
>
> Rule in 3.0.0rc1:
> SecRule
> REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/*
> "@pmf os-commands.data" \
> "msg:'Remote Command Execution (RCE) Attempt',\
> phase:request,\
> rev:'2',\
> ver:'OWASP_CRS/3.0.0',\
> maturity:'9',\
> accuracy:'8',\
> capture,\
> t:none,t:normalisePath,\
> ctl:auditLogParts=+E,\
> block,\
> id:'932100',\
> tag:'application-multi',\
> tag:'language-multi',\
> tag:'platform-multi',\
> tag:'attack-remote code execution',\
> tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION',\
> tag:'WASCTC/WASC-31',\
> tag:'OWASP_TOP_10/A1',\
> tag:'PCI/6.5.2',\
> logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
> %{MATCHED_VAR}',\
> severity:'CRITICAL',\
> chain"
> SecRule MATCHED_VARS "@rx
> [`;\|&\r\n].*?(\.exe)?(\s+[-/])?.+[&<>\|]*?" \
> "capture,\
> setvar:'tx.msg=%{rule.msg}',\
> setvar:tx.rce_score=+%{tx.critical_anomaly_score},\
> setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
>
> setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RCE-%{matched_var_name}=%{tx.0}"
>
>
> This rule is controversial for different reasons than the one in the
> previous post.
>
> It was a simple regex in 2.2.X. For 3.0.0 it has been enriched with a
> data file:
> https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/v3.0.0-rc1/rules/os-commands.data
>
> In a response to my blogpost
> https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/
> Chaim conceded the 3.0.0 version is still plagued by a lot of false
> positives. Obviously so, if you look at the commands. After all, unix
> commands are close to natural English for a good reason.
>
> Now Franziska (collaborating on the paranoia mode) and I wonder if
> it would not make sense to split
> os-commands.data into two or more files. The commands with few
> false positives would remain in the standard file, commands generating
> lots of false positives could then be moved into
> os-commands-paranoia.data and be referenced in a separate rule
> copying the behaviour of the standard rule.
>
> Thoughts?
>
> Christian
>
> --
> mailto:christian.fol...@netnea.com
> http://www.christian-folini.ch
> twitter: @ChrFolini
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> Owasp-modsecurity-core-rule-set@lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
