Drupal core - Remote Code Execution - SA-CORE-2018-002 modsec rules

fuzzylogic

April 01, 2018 02:57

Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002 With the discovery of this Drupal vulnerability many cPanel accounts and/or servers will soon be at high risk of successful attack. Drupal have released updated versions of Drupal 7 and 8 which secure this vulnerability. They have also released patches for older vulnerable versions. But without an auto update feature many Drupal installations will remain vulnerable for a significant period of time. Here are 2 modsec rules (not written by me) designed to block attacks to this vulnerability which may reduce the number successful attacks...


# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback parameters
SecRule REQUEST_FILENAME "(index\.php|\/$)" "chain,id:3294,t:lowercase,t:none,t:utf8toUnicode,t:urlDecodeUni,t:urldecode,block"
                SecRule REQUEST_METHOD "^(GET|POST|HEAD)$" chain
                SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "^\#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process)$|\[(?:\'|\")?#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process)"


# GENERIC: Block all parameters starting with #
SecRule REQUEST_FILENAME "(index\.php|\/$)" "chain,id:3309,t:lowercase,t:none,t:utf8toUnicode,t:urlDecodeUni,t:urldecode,block"
                SecRule REQUEST_METHOD "^(GET|POST|HEAD)$" chain
                SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "^\#|\[(?:\'|\")?\#.*\]"

Comments

7 comments

cPanelMichael

April 03, 2018 12:23
Hello @fuzzylogic, Thank you for sharing this information.
0
fuzzylogic

April 14, 2018 04:07
Just as an update (or heads up) to this thread, a Proof of Concept exploiting this vulnerability was published 2 days ago. Automated attacks began within a few hours of that. After checking the 2 modsec rules posted above against the POC vector, they were fount to be ineffective due the the endpoint restriction (index.php or /) They have also been hardened against more evasion attempt methods. Below are two reworked version of these rules successfully tested against the POC vector. The ids have been increased by 1 each so that they can be added to WHM, then the old versions deleted. # GENERIC: Block all parameters starting with # or space# or containing [#...] Note: Will false positive ajax and json keys or values starting with # SecRule &ARGS_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3311,t:none,block" SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "^#| #|\[(?: )?#.*]" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:compressWhitespace"
# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback parameters SecRule &ARGS_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3295,t:none,block" SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder)|\[#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder)" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:removeWhitespace"
0
fuzzylogic

April 16, 2018 06:06
Here is another update to these rules. I noticed on another website a user reporting attack traffic using Content-Type multipart/form-data and using a file field to pass the exploit data... --9a3c9fb84c674844bcf0f0986b8890a1 Content-Disposition: form-data; name="mail[#type]"; filename="mail[#type]" markup
On testing I found that the previous rules I posted did not run the regex against this kind of post data. Problem was the file field name is not stored in the ARGS_NAMES variable but rather in the FILES_NAMES variable. So here are the next version of the rules, now also matching the file field value. They have again had their id incremented by 1. # GENERIC: Block all parameters starting with # or space# or containing [#...] Note: Will false positive ajax and json keys or values starting with # SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3312,t:none,block" SecRule ARGS_NAMES|FILES_NAMES|REQUEST_COOKIES_NAMES "^#| #|\[(?: )?#.*]" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:compressWhitespace"
# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback parameters SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3296,t:none,block" SecRule ARGS_NAMES|FILES_NAMES|REQUEST_COOKIES_NAMES "#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder)|\[#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder)" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:removeWhitespace"
0
kevinlevin

April 26, 2018 19:03
SA-CORE-2018-004 is out. Are those rules protecting against it or new ones should be implemented?
0
fuzzylogic

April 27, 2018 05:00
I have just finished testing these rules against the requests suggested by dreadlocked on twitter with poc by Blaklis on pastbin exploiting SA-CORE-2018-004 / CVE-2018-7602. GENERIC rule 3312 matched the querystring of the first request in the poc at ARGS_NAMES:q[%2523type] and ARGS_NAMES:q[%2523markup] SPECIFIC rule 3296 failed to match anything in the querystring (because #type and #markup were not in the specific list) So these rules need a rewrite, but the GENERIC rule would have protected against Blaklis's poc. So here are the next version of the rules, now also matching #type and #markup and adding querystring arg values for scrutiny. They have again had their id incremented by 1. # GENERIC: Block all parameters starting with # or space# or containing [#...] Note: Will false positive ajax and json keys or values starting with # SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3313,t:none,block" SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "^#| #|\[(?: )?#.*]" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:compressWhitespace"
# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback parameters SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3297,t:none,block" SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup)|\[#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup)" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:removeWhitespace"
Please note that other vectors are likely to be found, so the GENERIC rule is more likely to catch them sight unseen.
0
fuzzylogic

April 27, 2018 10:39
Just found a new SA-CORE-2018-004 / CVE-2018-7602 poc by alexandrezfs on github. Both 3313 and 3297 matched the first request of the poc. The second request was a non match for those rules but also has a usable signature of #options Many of the drupalgeddon2 requests had the signature of #value in the querystring also. So yet another rewrite of these rules is in order (to stay ahead of the next found vector) Have added the strings #value and #options to the SPECIFIC rule and have added the string /# to the GENERIC rule. They have again had their id incremented by 1. # GENERIC: Block all parameter names or get args starting with # or containing /# or space# or [#...] SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3314,t:none,block" SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "^#|\/#| #|\[(?: )?#.*]" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:compressWhitespace"
# SPECIFIC: Block #submit #validate #process #pre_render #post_render #element_validate #after_build #value_callback #process #access_callback #lazy_builder #type #markup #value #options parameters SecRule &ARGS_NAMES|&FILES_NAMES|&REQUEST_COOKIES_NAMES "@gt 0" "phase:2,log,chain,id:3298,t:none,block" SecRule ARGS_NAMES|ARGS_GET|FILES_NAMES|REQUEST_COOKIES_NAMES "#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup|value|options)|\[#(submit|validate|pre_render|post_render|element_validate|after_build|value_callback|process|access_callback|lazy_builder|type|markup|value|options)" "t:none,t:utf8toUnicode,t:urlDecodeUni,t:removeNulls,t:cmdLine,t:removeWhitespace"
0
DamienMcKenna

May 09, 2018 12:42
Fantastic work, fuzzylogic! You might try creating a PR for the mod_security project to have the rules added to the next release.
0

Please sign in to leave a comment.

Comments

Didn't find what you were looking for?