Dear all, After last week's complaints, it seems only fair and suitable to follow up and contribute to the project. Here we go with something that has been in my drawer for too long.
The core rules have strong sides and weaker spots. One spot that I think is not very well developed is the whole http request splitting and header injection field. I have been bitten twice and decided to act and develop a set of new rules that would cover this attack vector in a generic way with the goal to bring these rules into the core rules. Achim Hoffmann joined me on this little project and while I coordinated a big test run, he wrote most of the rules / regular expressions. A generic attack / a prepared link which will result in a transparent redirect to an evil site in case the handler action.do is vulnerable. https://www.example.com/smartapp/action.do?param1=file&file=foo.txt%0D%0ARefresh:%201;%20url=http://www.evilsite.com&file_type=txt This may sound foolish, but I have had two customers falling for this sort of weakness. In the stable Core-Rules, ModSecurity will only trigger 981173 : Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded In fact this rule is a false positive, as this is no SQL injection going on, but at least it gave us a hint something is amiss. 981173 will result in a score of 5 points. In many if not most installations, a score of 5 is below the threshold / limit defined and the attack will thus pass the WAF. In the v3.0.0 dev branch, things are not much better with 950907 Remote Command Execution (RCE) Attempt bring triggered. The attack does a CR/LF and then brings an http response header. Both in a query string to be sent as part of a request. This should be quite easy to detect actually, and I think it can be done in a very generic way. Detecting and blocking results in a successful mitigation of the attack. So this pull request vs. v.3.0.0-dev extends the existing protocol attacks, that are listed in REQUEST-21-PROTOCOL-ATTACK.conf. In fact the existing 3 rules are fairly similar to the new ones I am proposing together with Achim, so there is a fair bit of redundancy (which adds to the score, which makes blocking all the more likely). Please see https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/255 for the rules, more detailed description and an assessment of the false positive rates for the various rules. 4 of them do quite OK in this regard. 950917 has a different milage though. It brings far more false positives and pushing it into an area of optional paranoid qould make sense, I guess. I would appreciate, if you could review the pull request and include it in the dev version 3.0.0. Obviously, I am open to update the rules, if you have any suggestions. Best regards, Christian Folini -- It's when they say 2 + 2 = 5 that I begin to argue. -- Eric Pepke _______________________________________________ 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
