{"id":887,"date":"2016-07-26T08:49:31","date_gmt":"2016-07-26T06:49:31","guid":{"rendered":"http:\/\/www.netnea.com\/cms\/?p=887"},"modified":"2016-07-26T10:56:06","modified_gmt":"2016-07-26T08:56:06","slug":"having-fun-with-new-evasions","status":"publish","type":"post","link":"https:\/\/www.netnea.com\/cms\/2016\/07\/26\/having-fun-with-new-evasions\/","title":{"rendered":"Having Fun with New Evasions"},"content":{"rendered":"

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<\/a> would block the payloads. Usually it does block them and I get a warm fuzzy feeling.<\/p>\n

Sometimes, it does not block them though and the warm fuzzy feeling is replaced with the urgent need to open issues<\/a> on the Core Rules github site.<\/p>\n

Yesterday, Nick Galbreath (one of the speakers in the Tech Track<\/a> I moderate at the Swiss Cyberstorm conference<\/a>) published a list<\/a> 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).<\/p>\n

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 <\/a>for an introduction of the concept).<\/p>\n

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.<\/p>\n

Here are the details:<\/p>\n

XSS in your XML<\/strong>
\nRules triggered at PL 1:
\n920100 Invalid HTTP Request Line<\/em>
\n 920430 HTTP protocol version is not allowed by policy<\/em>
\n 941100 XSS Attack Detected via Libinjection<\/em>
\n 941160 NoScript XSS InjectionChecker: HTML Injection<\/em>
\n Total Score : 15<\/strong><\/p>\n

 <\/p>\n

Another XSS in your XML<\/strong>
\nRules triggered at PL 1:
\n941100 XSS Attack Detected via Libinjection<\/em>
\n 941130 XSS Filter – Category 3: Attribute Vector<\/em>
\n 941150 XSS Filter – Category 5: Disallowed HTML Attributes<\/em>
\n 941160 NoScript XSS InjectionChecker: HTML Injection<\/em>
\n 941170 NoScript XSS InjectionChecker: Attribute Injection<\/em>
\n Total Score : 25<\/strong><\/p>\n

 <\/p>\n

CSV Injection<\/strong>
\nRules triggered at PL 1:
\n932100 Remote Command Execution (RCE) Attempt<\/em>
\n Total Score : 5<\/strong><\/p>\n

 <\/p>\n

NoSQL Injection<\/strong>
\nRules triggered at PL 1:
\n 942290 Finds basic MongoDB SQL injection attempts<\/em>
\n Total Score : 5<\/strong><\/p>\n

 <\/p>\n

XXE Injection<\/strong>
\nRules triggered at PL 1:
\n941100 XSS Attack Detected via Libinjection<\/em>
\n 941130 Attribute Vector (-> ARGS_NAMES)<\/em>
\n 941130 Attribute Vector (ARGS)<\/em>
\nTotal Score : 15<\/strong><\/p>\n

If you are interested to see the exact payloads, then you can check them out in this github issue<\/a>.<\/p>\n

 <\/p>\n

Christian Folini Follow @ChrFolini<\/a> Tweet<\/a>
\n