There is a spare time activity which I enjoy in off hours. I go to reddit or twitter or some other site where web attack ideas are traded. I look for new exploits or evasions and try and run them against a local webserver to see if the OWASP ModSecurity Core Rules would block the payloads. Usually it does block them and I get a warm fuzzy feeling.
Sometimes, it does not block them though and the warm fuzzy feeling is replaced with the urgent need to open issues on the Core Rules github site.
Yesterday, Nick Galbreath (one of the speakers in the Tech Track I moderate at the Swiss Cyberstorm conference) published a list of new injection attacks he had seen mentioned in the last few weeks. Immediately, I felt the need for that warm fuzzy feeling and I launched a local reverse proxy server with the latest ruleset and derived a list of exploits out of Nick’s article (or rather the five articles he linked).
To make it clear, I do not have the backend software, that is usually being attacked. But that’s not a problem. I only want to see if ModSecurity and the CRS would block a request or not before it would reach the backend application. So I run Apache with the latest Core Rules in blocking anomaly scoring mode with a low anomaly scoring threshold of 5. A few weeks ago I switched from the stable OWASP ModSecurity Core Rules release 2.2.9 to the Core Rules 3.0 development tree. The coverage was good before, but the upcoming release will be even better; especially with the introduction of the paranoia levels. (See this video for an introduction of the concept).
While you can send the exploits from the browser, I have a habit to work from the shell and attack with curl. Depending on the level of the description of the attack, constructing the exact payload is at times tedious, but here it seemed simple enough. Within 5 minutes I was ready to strike and indeed, ModSecurity and the Core Rules stopped all 5 attacks in the default install. With anomaly scores from 5 to 25. Exactly the warm fuzzy feeling I was looking for.
Here are the details:
XSS in your XML
Rules triggered at PL 1:
920100 Invalid HTTP Request Line
920430 HTTP protocol version is not allowed by policy
941100 XSS Attack Detected via Libinjection
941160 NoScript XSS InjectionChecker: HTML Injection
Total Score : 15
Another XSS in your XML
Rules triggered at PL 1:
941100 XSS Attack Detected via Libinjection
941130 XSS Filter – Category 3: Attribute Vector
941150 XSS Filter – Category 5: Disallowed HTML Attributes
941160 NoScript XSS InjectionChecker: HTML Injection
941170 NoScript XSS InjectionChecker: Attribute Injection
Total Score : 25
CSV Injection
Rules triggered at PL 1:
932100 Remote Command Execution (RCE) Attempt
Total Score : 5
NoSQL Injection
Rules triggered at PL 1:
942290 Finds basic MongoDB SQL injection attempts
Total Score : 5
XXE Injection
Rules triggered at PL 1:
941100 XSS Attack Detected via Libinjection
941130 Attribute Vector (-> ARGS_NAMES)
941130 Attribute Vector (ARGS)
Total Score : 15
If you are interested to see the exact payloads, then you can check them out in this github issue.
Christian Folini Follow @ChrFolini Tweet