Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!

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

Discussion in 'Security' started by fuzzylogic, Apr 1, 2018.

  1. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    93
    Likes Received:
    50
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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...
    Code:
    # 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)"
    
    Code:
    # 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 "^\#|\[(?:\'|\")?\#.*\]"
    
     
    cPanelMichael likes this.
  2. cPanelMichael

    cPanelMichael Technical Support Community Manager
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    44,802
    Likes Received:
    1,896
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hello @fuzzylogic,

    Thank you for sharing this information.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    93
    Likes Received:
    50
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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.
    Code:
    # 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"
    
    Code:
    # 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"
    
     
    #3 fuzzylogic, Apr 13, 2018
    Last edited: Apr 14, 2018
  4. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    93
    Likes Received:
    50
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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...
    Code:
    --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.
    Code:
    # 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"
    Code:
    # 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"
     
    cPanelMichael likes this.
  5. kevinlevin

    kevinlevin Member

    Joined:
    Oct 27, 2011
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    51
    cPanel Access Level:
    Root Administrator
    SA-CORE-2018-004 is out.
    Are those rules protecting against it or new ones should be implemented?
     
  6. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    93
    Likes Received:
    50
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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.
    Code:
    # 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"
    
    Code:
    # 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.
     
  7. fuzzylogic

    fuzzylogic Well-Known Member

    Joined:
    Nov 8, 2014
    Messages:
    93
    Likes Received:
    50
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    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.
    Code:
    # 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"
    
    Code:
    # 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"
    
     
    cPanelMichael likes this.
  8. DamienMcKenna

    DamienMcKenna Registered

    Joined:
    Oct 20, 2005
    Messages:
    1
    Likes Received:
    0
    Trophy Points:
    151
    Fantastic work, fuzzylogic! You might try creating a PR for the mod_security project to have the rules added to the next release.
     
Loading...

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice