-
-
Notifications
You must be signed in to change notification settings - Fork 401
curl
and wget
are matched in User-Agent header
#3189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
you are absolutely right. that's why we sadly had to remove this rules for our new deployment. I would really appreciate if we could remove them from our list... |
just as a reminder to address this problem: we still block curl and wget at PL2 coreruleset/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf Lines 1220 to 1239 in e36f27e
$ curl -s \
-H 'x-backend: nginx' \
-H 'x-crs-paranoia-level: 2' \
-H 'x-format-output: txt-matched-rules' \
'https://sandbox.coreruleset.org/'
932236 PL2 Remote Command Execution: Unix Command Injection (command without evasion)
949110 PL1 Inbound Anomaly Score Exceeded (Total Score: 5) it doesn't make any sense to me to block curl UA as a RCE injection. |
Rule 932236 was introduced in this commit and rule 932237 in this commit to address Shivam Bathla's bypass list. Maybe we can leave the rules as they are but work with an |
I am a wee bit reluctant to remove this. We're at PL2 and we're looking at RCE.
Given we're at PL2, I am reluctantly for solution 1: accepting the FP and let people deal with it via rule exclusions. |
we can't leave this rule as is. I get where you're coming from about accepting false positives at PL2, but I don't really see the point of matching "curl" and "wget" in the User-Agent as we do with this rule. Let's face it, anyone running CRS at PL2 in a real-world scenario would probably end up removing this rule anyone. Plus, we're trying to shield the app from things like |
Ah, and this bypass can't be solved so easy... It's not just changing the |
Maybe it could be solved if we worked with a generated regex instead of |
It could be a good approach! But I'm not a big fan of exceptions to be honest, they often leads to bypasses. Moreover, the problem is not only with curl and wget. I have also matches with the following UA:
just in the last 24h |
I agree that the exceptions lead to poor rules (based on rule architecture, MATCHED_VAR_NAME is often broken) and there is a substantial bypass problem. If you really think automated agents should not trigger alerts on PL2, then I think we need a separate rule for UA (and referrer perhaps) that has the same source, but uses |
To add some context: this issue was discussed at the April meeting. (Full discussion here, search for "UA problem goes first".) We agreed in April that this issue needs to be fixed. I agree with @theMiddleBlue that this rule cannot be left in its current state. Tools like curl, wget etc. are legitimate and many CRS users use them. I'm not sure the chain rule approach in #3190 is a good idea. I thought there was a |
The approach in #3190 isn't great, as it opens the door to evasions. I now think that there's no way around a separate rule for the Opinions? |
Just to make sure I get you correctly: You would use the entire Unix command list for Given we are stuck with 2 PRs (#3190 and #3276) touching on these rules and since we have been chewing on this problem for several months, I think the separate rule is the right way to address this. |
Yes, check all words but exclude |
I will work on this after #3276 is merged. |
Now that the PR is merged, I'll work on this before the feature freeze. |
The valid user agents for
curl
andwget
are matched by rules932236
and932237
in theUser-Agent
header.The text was updated successfully, but these errors were encountered: