How I was in ModSecurity core rule set to find ReDOS vulnerabilities-vulnerability warning-the black bar safety net

This article tells me is how in the world well-known WAF rule set to find ReDOS vulnerabilities, if you are not yet familiar with regular expressions and ReDOS vulnerability, you can read my previous article: https://nosec.org/home/detail/2506.html the. Simple to say that the ReDOS vulnerability due to certain regular expressions when writing ignore safety, resulting in the match to search for some particular string will consume a lot of computing resources, resulting in a DOS attack effect. And now many WAF products are dependent on the regular expression of the flow to be filtered, upon which the regular expression there is a security problem, it is possible to make the WAF subject to ReDOS vulnerabilities.
Recently, I spent a lot of time to research the WAF of ReDOS vulnerabilities. And my goal is the world’s leading WAF products ModSecurity core rule set CRS, because it has a lot of regular expressions, just to exercise my around the WAF capabilities, two birds with one stone it!
CRS 29 configuration file, which contains a large number of regular expressions, I can not all manual tests, so I wrote a script to automate the process. Unfortunately the script is still in alpha stage, I can’t open it, but I want a good release time, believe that soon and we can meet.
In the use script to get some suspicious regular expression, I use regex101. com to remove the expression of the unwanted part, for example, the((fine)|(vulnerable))of(fine)delete
I also use RegexBuddy to analyze different exploits way, and finally with the Python interpreter to confirm the use of effective.
Now, let’s talk about what I found vulnerability points and their use.

Case#1
Expression: (?: (?:^ [“”\\]? [^“”]+[“”])+|(?:^ [“”\\]? [d"“]+)+)s
Use: “””“”“”“”“”“”" (approximately 1000")
Why is vulnerability?
This expression is made|the identifier of the connection of the two sub-expressions, and the two sub-expressions are based on^[”’\\]? At the beginning, and then at the end of the then pick on one or two special characters. The regular expression engine when processing will to traverse the two sub-expressions all possible, greatly consume computing resources.
And in the second sub-expression，^[”’\\]? And[d”’]+will match“, ‘ and the anti-quotation marks have a clear competitive relationship.
This((pattern 1)+|(pattern 2)+)+repetition operators are added to the nested mode it is clear in the processing of special strings will consume a lot of computing resources.

Case#2
Expression: for(?:/ [dflr].) %+[^ ]+ in(.) s? do
Weaknesses: for(?:/ [dflr].)* %
Use: for/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r
Why is vulnerability?
Let’s a step by step look at this expression for the special character string matching step
f
fo
for
for/
for/r
for/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r
My given string the latter part will be.* The match, but due to the end of the string is not%, the final will result in a match failure.
In this case, in order to successfully match, then the matching logic will miss the last character r to see the rest of the string is in accordance with:
for/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/r/
Of course, the match still fails. In General, the matching logic will constantly back until the back no retreat, completely fails to match. However, since there are two repeat operators of overlay applications, things become more complicated. And/r can either be.* Match, will be/[dflr]match…
I’m not sure if the run finished how many times the calculation, I use the RegexBuddy4 the upper limit is 10,00,000, clearly the true number far exceeds this value.

Case#3
Pattern: (?: s|/.**/|//.|#.) (.)
Trojan: ################################################
Why is vulnerability?
(?: s|/.**/|//.|#.)* Can be seen by the|character connected to four sub-expressions, wherein the 3 has.* This can match all the sensitive of the symbol. When the Regular Expression Engine the expression and the string to match the search, only the last sub-expression will match, but because of the lack of expression of the desired (), the match fails, then the Regular Expression Engine will become very crazy, but here also there is a repeat of the operators of the nested problem. Ultimately, each adding a#character, the required step of calculating the number of crazy growth.
This last case I was in 3 different rules are found.
In that I reported the above vulnerabilities to obtain the following CVE: the
CVE-2019-11387
CVE-2019-11388
CVE-2019-11389
CVE-2019-11390
CVE-2019-11391
Thank you for reading, I will continue to share more about the ReDOS of the study.