Hello, Your ideas are extremely valuable Walter. And even if I do not agree with your solutions to the letter, I love the fact that we are having technical discussions on the merit of individual rules.
Chaim seems to be on the same page with me on the idea of environment-specific rules and how to handle the enabling / disabling. And then the problem of the granularity of the files. There is a danger in overengineering things and making the configuration / tuning too complex. In that light, I think splitting makes sense, but ideally, we end up with xxx-standard.data xxx-paranoia.data However, you have a point that you can not alter the contents of these data files afterwards in a local setup in a safe way. So disabling Windows commands won't work unless we add specific data files with their own rules, which can then be disabled. I am really torn here. In my stated fear of overloading the paranoia project / pull request, I would appreciate to handle the big updates to individual rules in separate pull requests - if possible. If it has to be, we include it. Ahoj, Christian On Sun, Feb 07, 2016 at 03:46:32PM +0000, Chaim Sanders wrote: > I like the ideas. The first thing I’d note is that individuals are free to > exclude or remove entire files so as long as the PHP file is named > REQUEST-XYZ-PHP-XYZ people running ASP should get this hint (hopefully) > this is why we name them in this way. In terms of splitting the files, I > most certainly agree with the ‘critical’. Again I caution against > splitting data files TOO finely as it will get confusing to support your > own instance but this is just a minor issue. As for those parenthesis. You > are right and this is actually my fault. I added them to prevent false > positives being reported commonly on Cpanel. > > On 2/7/16, 8:58 AM, > "owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of > Walter Hop" <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on > behalf of mod...@spam.lifeforms.nl> wrote: > > >On 02 Feb 2016, at 09:25, Christian Folini <christian.fol...@netnea.com> > >wrote: > >> > >> Like the previous post on 950907 / 932100, this is controversial because > >> of possible false positives due to a data file with strings: > >> > >>http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk > >>vSmewhU_w&s=5&u=https%3a%2f%2fraw%2egithubusercontent%2ecom%2fSpiderLabs% > >>2fowasp-modsecurity-crs%2fv3%2e0%2e0-rc1%2frules%2fphp-function-names%2ed > >>ata > >> > >>http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk > >>qKjKQ1VqQ&s=5&u=https%3a%2f%2fraw%2egithubusercontent%2ecom%2fSpiderLabs% > >>2fowasp-modsecurity-crs%2fv3%2e0%2e0-rc1%2frules%2fphp-config-directives% > >>2edata > >> > >> Could these files be split in the manner explained in the message > >> before? > >> > >> After all, this rule scans input against strings like > >> dl, eval, exec, from, precision. > > > >I would advocate the same separation as in my previous post re > >os-commands. > >But we need a little more firepower for PHP in my opinion. > >A detailed approach could go like this... > > > >1) Have the user indicate with setvar if they want to protect PHP, and > >predicate the rules on that. All the non PHP shops will be solved from FP > >instantly! > > > >2) We need to review the current data file: > >- I’m missing some stuff there that I see in the wild every day such as: > >gzinflate, gzdecode, gzuncompress, strrev, zlib_decode… > >- I also see in some cases the parenthesis is added, like: /file(/ and > >/assert(/. This seems easy to evade. In PHP, calling “assert ($foo)” > >or “assert\t\t\t($foo)” is just as valid. In this case, it was probably > >done because those terms lead to FP. If so, we might move super common > >terms with relatively low attacker interest, like assert, to the paranoid > >list. But, in any case they should become more robust regexps like > >“\bfile\s*(“. > > > >3) Separate the data file. Start with a small > >“php-commands-critical.data” list. This should contain the usual suspects > >used for: > >- obfuscation: base64_decode, gzdecode, etc... > >- execution: passthru, proc_open, shell_exec, call_user_func, > >require_once, include_once... > >- IO: file_get_contents, file_put_contents, fopen, fwrite... > >- environment inspection and setting: error_reporting, function_exists, > >ini_set, auto_prepend_file, sys_get_temp_dir... > > > >If any of those strings is present, it’s certainly an attack, except for > >that single person who runs a PHP-related wiki. The list should only > >contain the real red flags, don’t try to cleverly prevent FP using > >complex regexps, and cannot contain any common English words (so > >unfortunately “require” and “include” are off limits...) > > > >4) Other functions could go in “php-commands-functions.data”. This list > >would be small and contain only *proper functions* having PHP syntax > >“function()” and have names often used in natural text. To prevent FP we > >look for the parenthesis. Let’s take example “system”, this is often > >found in natural text, but an attacker wants to do “system(“ so they need > >parentheses and a word boundary at the start. So a regexp might look like > >"\bsystem\s*\(“. Because we have the regexp, FP is lowered. It would > >still match stuff like “F*ck the system (yeah yeah)” > > > >5) Other PHP related terms could stay in “php-commands-common.data”. This > >would list the PHP commands and terms of lesser interest. > > > >6) We’ll have to review if there are terms which are so common in natural > >text that they’ll have to be moved to “php-commands-paranoid.data”. I > >think this list might be as small as possible. Maybe stuff like “dl”, > >“require”, “include”. It’s still likely to produce FP... > > > >7) String matching for PHP functions is not powerful enough. We need > >generic rules that prevent PHP evasion. I don’t remember seeing this in > >the wild, but an easy way to evade textual signature matches would be PHP > >variable functions > >(http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk > >vCjeQMDpQ&s=5&u=http%3a%2f%2fphp%2enet%2fmanual%2fen%2ffunctions%2evariabl > >e-functions%2ephp%29 For instance, you can do the following to get around > >the CRS: > > > >$aB_4c = 'fil' . 'e_get' . '_contents'; > >$aB_4c('...'); > > > >So we want a generic signature to detect variable function call syntax. > >Fortunately its syntax is very uncommon in natural text, so I’d advocate > >putting this rule in normal mode. > > > >Anyway my €0.02 or maybe a bit more :) > > > > > >_______________________________________________ > >Owasp-modsecurity-core-rule-set mailing list > >Owasp-modsecurity-core-rule-set@lists.owasp.org > >http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPkq > >emcgoEpA&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2fow > >asp-modsecurity-core-rule-set > > > ________________________________ > > This transmission may contain information that is privileged, confidential, > and/or exempt from disclosure under applicable law. If you are not the > intended recipient, you are hereby notified that any disclosure, copying, > distribution, or use of the information contained herein (including any > reliance thereon) is strictly prohibited. If you received this transmission > in error, please immediately contact the sender and destroy the material in > its entirety, whether in electronic or hard copy format. > _______________________________________________ > 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 -- 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
