You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Fix**: ModSecurity v3.0.12, ModSecurity v2.9.x is not affected
17
+
### Advisory
18
18
19
-
**Download**: TBD
19
+
ModSecurity / libModSecurity 3.0.0 to 3.0.11 is affected by a WAF bypass for path-based payloads submitted via specially crafted request URLs. ModSecurity v3 decodes percent-encoded characters present in request URLs before it separates the URL path component from the optional query string component. This results in an impedance mismatch versus RFC compliant back-end applications. The vulnerability hides an attack payload in the path component of the URL from WAF rules inspecting it. A back-end may be vulnerable if it uses the path component of request URLs to construct queries. Integrators and users are advised to upgrade to 3.0.12. The ModSecurity v2 release line is not affected by this vulnerability.
20
20
21
-
**Release Notes**: TBD
21
+
### Components affected with numbers
22
22
23
+
ModSecurity / libModSecurity v3.0.0 - v3.0.11
24
+
25
+
### Fixed version
26
+
27
+
ModSecurity / libModSecurity v3.0.12
28
+
29
+
ModSecurity v2.9.x is not affected by this vulnerability.
It can be argued wether the Integrity Impact should be lowered to "medium" instead of "high". After discussing this with our CNA NCSC Switzerland, we concluded to put it on "high". If set to "medium", the score drops to a "medium" level.
50
+
51
+
52
+
### CWE and CAPEC
53
+
54
+
* CWE-20: Improper Input Validation
55
+
* CAPEC-152: Inject Unexpected Items
56
+
57
+
In both taxonomies, CWE and CAPEC, we assigned very broad categories. None of the more detailed categories were really spot on.
58
+
59
+
### Longer description
60
+
61
+
The [OWASP CRS](https://coreruleset.org) team has discovered an unexpected behavior that can lead to a bypass in the [ModSecurity](https://owasp.org/www-project-modsecurity/) v3 release line (also known as libModSecurity).
62
+
63
+
For a given HTTP request, ModSecurity3 performs URL decoding on the request URL. For example, the percent-encoded character sequence “%3F” is decoded into a question mark character, “?”. ModSecurity later separates the URL path component from the optional query component, allowing for subsequent rule-based inspection of the path in isolation. ModSecurity performs this separation at the first question mark character encountered in the decoded URL as “?” denotes the start of the query component. Crucially, ModSecurity3 performs the URL decoding step before the URL path separation step.
64
+
65
+
It is thus possible for an attacker to craft a request URL that contains a percent-encoded question mark character (“`%3F`”) to trick ModSecurity into separating the URL into a path component at a position of the attacker’s choosing. This allows an attacker to place a payload in the path of a request URL following a “`%3F`” character sequence in order to bypass the scrutiny of all rules intended to inspect the URL path component. This is further facilitated by the fact, that the part after the “`%3F`” is not appearing as part of the `QUERY_STRING` variable.
66
+
67
+
The ModSecurity variables `REQUEST_FILENAME` and `REQUEST_BASENAME` are affected as these variables are intended to hold the URL path, in full or in part, for inspection. ModSecurity rules that inspect or make use of these variables are affected and may be rendered ineffective against exploits of this vulnerability. This includes a significant number of rules in OWASP CRS.
68
+
69
+
### The fix: Following the correct order of operations
70
+
71
+
Referring to the relevant RFC governing the use of URIs ([RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)) reveals that this is a known hazard. The RFC [explicitly states](https://datatracker.ietf.org/doc/html/rfc3986#section-2.4) that a URI must be separated into its component parts before performing URL decoding in order to avoid mistaking an encoded character for a component delimiter.
72
+
73
+
The fix was to modify the ModSecurity3 function that processes a request URI. The URL is not separated into its components before URL decoding is performed, removing the possibility of ModSecurity3 mistakenly using an incorrect delimiter character.
74
+
75
+
### Example bypass
76
+
77
+
Consider sending an HTTP request with the following URL, which includes an SQL injection payload in the path:
78
+
79
+
```
80
+
example.com/admin/id/1%3F+OR+1=1--
81
+
```
82
+
83
+
ModSecurity would perform URL decoding, which gives:
84
+
85
+
```
86
+
example.com/admin/id/1?+OR+1=1--
87
+
```
88
+
89
+
The appearance of a newly decoded question mark character tricks ModSecurity3 into believing that a query component is now present. ModSecurity3 now separates the URL path component from what it believes is a query component and sets the path-related variables like so:
90
+
91
+
```
92
+
REQUEST_FILENAME: /admin/id/1
93
+
REQUEST_BASENAME: 1
94
+
```
95
+
96
+
The SQLi payload is no longer present, despite being a valid part of the URL path. The payload will bypass the detection of rules that rely on inspecting ModSecurity3’s URL path variables. Unfortunately, the payload is also not visible as part of the `QUERY_STRING` variable.
97
+
98
+
As demonstrated, this is a serious issue and ModSecurity v3 users are strongly encouraged to update to the fixed release (v3.0.12) as soon as is practical.
99
+
100
+
### Workaround
101
+
102
+
While upgrading to receive the fix is strongly encouraged, if upgrading the ModSecurity engine is impossible for some reason then a workaround can be implemented.
103
+
104
+
ModSecurity3’s `REQUEST_URI_RAW` variable contains the full URI and is unaffected by the URL decoding step. Comparing it to the path-related variables from the previous example, the raw URI variable looks like so:
105
+
106
+
```
107
+
REQUEST_URI_RAW: /admin/id/1%3F+OR+1=1--
108
+
REQUEST_FILENAME: /admin/id/1
109
+
REQUEST_BASENAME: 1
110
+
```
111
+
112
+
As such, it is possible to use the `REQUEST_URI_RAW` variable to derive all other required variables correctly, including performing any required URL decoding. Note that the raw URI variable also includes the query component, if present, and so can be cumbersome and difficult to use.
113
+
114
+
Implementing such a workaround is likely to generate many new false positives with existing rules. For ModSecurity3 users, performing an engine update to receive the fix is likely to be a much more preferable and simpler solution.
115
+
116
+
### Exploitability
117
+
118
+
As with every WAF bypass, it takes an additional vulnerability in the back-end application for a successful attack. If the backend application uses path components as query parameters as is likely the case for an application with a layout as in the example presented under “Example Bypass”, then the application may be affected. This can be the case for SQL queries (SQL injection), but also an exploit via a Remote Command Execution (RCE) is possible in a similar constellation.
119
+
120
+
Again, the back-end must neglect input validation in order for this exploit to work out, but the additional security usually gained from a well-configured WAF is gone with this bypass.
121
+
122
+
### Timeline
123
+
124
+
_The timeline comes with a twist. Trustwave transferred the ModSecurity project to OWASP during the window between report and release of the fix. This means that the reporting organization became the new steward of the open source software in question before a fix was released by Trustwave. More to the point: OWASP CRS reported the problem and OWASP recruited the new OWASP ModSecurity team out of the OWASP CRS team._
125
+
126
+
* 2023-11-13 : OWASP CRS submits report to Trustwave Spiderlabs, includes SQLi proof of concept
* 2024-01-29 : NCSC-CH assigns CVE 2024-1019, advisory text and release notes are being prepared, planned release procedure is discussed with Trustwave Spiderlabs
144
+
* 2024-01-30 : OWASP ModSecurity Release 3.0.12
145
+
146
+
### Reporters
147
+
148
+
* Andrea Menin [@AndreaTheMiddle](https//twitter/AndreaTheMiddle)https://github.com/theMiddleBlue
149
+
* Matteo Pace [@M4tteoP](https//twitter/M4tteoP)https://github.com/M4tteoP
The OWASP ModSecurity team thanks the wider OWASP CRS team for their patience. Unfortunately, this fix took far longer than it should. We also thank Trustwave Spiderlabs, namely Martin Vierula, for the patch for this issue and the support with the release process. Harold Blankenship from OWASP Headquarters overlooked the transfer of ModSecurity and helped with the timely setup of a new OWASP project and GitHub organization. The OWASP project committee around Björn Kimminich fast tracked OWASP ModSecurity to production level. And finally NCSC-CH that supported us with the CVE process substantially. More than anything, Open Source Software is a team effort. Thank you all.
0 commit comments