False Positive Seafile (Nextcloud alternative) Upload File

[Schroeffu]

Description

Seafile is an open source alternative to Nextcloud (and way more stable(!) + blazing fast ;) written in python/django, the CRS 3.3.0 is hitting false positives when uploading a file bigger than 3-5MB and also when trying to delete files.

I did resolve the issue by:

(updated as mentioned, putting DELETE in SecAction id 900200 rule)

<IfModule mod_security2.c>
  SecRuleEngine On

  ### Allow huge file size uploads in my seafile environment
  SecRequestBodyLimit 3010720000
  SecRequestBodyNoFilesLimit 3010720000

  ### SeaFile dealing with Mod Security false positives

  ### Make sure REST API DELETE and PUT is working, Seafile up/downloads are using REST API
  SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=GET HEAD POST OPTIONS DELETE PUT'"

  ### added in modsecurity.conf to make sure user files are not scanned
  SecRule REQUEST_FILENAME "@beginsWith /seafhttp/repo/" "id:1,phase:2,nolog,allow,ctl:ruleEngine=Off"

    <LocationMatch "/seafhttp">
      #Allow Upload File bigger than 2-5MB
      SecRuleRemoveById 200004 920450
      #Allow Uploads without Content-Type Header
      SecRuleRemoveById 920340
    </LocationMatch>
</IfModule>

Audit Logs / Triggered Rule Numbers

#Upload failed Part #1
May 28 23:44:30.835631 2021] [:error] [pid 1815521:tid 140292159448832] [client 31.18.248.40:55955] [client 31.18.248.40] ModSecurity: Access denied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/modsecurity/modsecurity.conf"] [line "88"] [id "200004"] [msg "Multipart parser detected a possible unmatched boundary."] [hostname "seafile.schroeffu.ch"] [uri "/seafhttp/upload-aj/2b27f7d1-3d83-48c7-80f6-ca3d004b3660"] [unique_id "YLFkO4GabnaHgvL-PBPj6QAAABM"], referer: https://seafile.schroeffu.ch/library/4551f3c5-bf6c-4720-b77a-7acbff5719ea/Dateien/

#Upload failed Part #2
[Fri May 28 23:54:15.343412 2021] [:error] [pid 1819770:tid 139823242995456] [client 31.18.248.40:10700] [client 31.18.248.40] ModSecurity: Warning. String match within "/proxy/ /lock-token/ /content-range/ /if/" at TX:header_name_content-range. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1106"] [id "920450"] [msg "HTTP header is restricted by policy (/content-range/)"] [data "Restricted header detected: /content-range/"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [tag "PCI/12.1"] [hostname "seafile.schroeffu.ch"] [uri "/seafhttp/upload-aj/8edf184d-22e8-46a5-9ecc-5fd90f132cd8"] [unique_id "YLFmg5iURb3zH47gxybUpAAAABM"], referer: https://seafile.schroeffu.ch/library/4551f3c5-bf6c-4720-b77a-7acbff5719ea/Dateien/
[Fri May 28 23:54:15.352826 2021] [:error] [pid 1819770:tid 139823242995456] [client 31.18.248.40:10700] [client 31.18.248.40] ModSecurity: Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. [file "/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "93"] [id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "seafile.schroeffu.ch"] [uri "/seafhttp/upload-aj/8edf184d-22e8-46a5-9ecc-5fd90f132cd8"] [unique_id "YLFmg5iURb3zH47gxybUpAAAABM"], referer: https://seafile.schroeffu.ch/library/4551f3c5-bf6c-4720-b77a-7acbff5719ea/Dateien/
[Fri May 28 23:54:15.353621 2021] [:error] [pid 1819770:tid 139822979012352] [client 31.18.248.40:10700] [client 31.18.248.40] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf"] [line "91"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0"] [ver "OWASP_CRS/3.3.0"] [tag "event-correlation"] [hostname "seafile.schroeffu.ch"] [uri "/seafhttp/upload-aj/8edf184d-22e8-46a5-9ecc-5fd90f132cd8"] [unique_id "YLFmg5iURb3zH47gxybUpAAAABM"], referer: https://seafile.schroeffu.ch/library/4551f3c5-bf6c-4720-b77a-7acbff5719ea/Dateien/

#Delete Files in WebUI/Android App
[Sat May 29 00:13:26.059649 2021] [:error] [pid 1830496:tid 140706484025088] [client 31.18.248.40:10652] [client 31.18.248.40] ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. [file "/usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "43"] [id "911100"] [msg "Method is not allowed by policy"] [data "DELETE"] [severity "CRITICAL"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"] [hostname "seafile.schroeffu.ch"] [uri "/api2/repos/4551f3c5-bf6c-4720-b77a-7acbff5719ea/file/"] [unique_id "YLFrBpl@0qltoPED9FBt@QAAAA0"]

Your Environment

• CRS version (e.g., v3.2.0): 3.3.0
• Paranoia level setting: default
• ModSecurity version (e.g., 2.9.3): 2.9.3
• Web Server and version (e.g., apache 2.4.41): 2.4.41
• Operating System and version: Ubuntu 20.04 Server, ModSec from Repo, CRS RuleSet 3.3.0 from latest Ubuntu .deb package
• Seafile Server Version: 7.1.5 (latest ist 8.x but not used yet)

Confirmation

[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

[airween]

Hi @Schroeffu,

first, thanks for your report.

A quick response to your issues:

#Upload failed Part #1

this is a known issue in mod_security, and there is an unapplied fix. This is not a CRS issue.

#Upload failed Part #2

Looks like the problem is the existence header with name Content-Range. We have to investigate this problem, but could you attach a detailed request, where we can see the headers? (Without any sensitive data, of course.)

#Delete Files in WebUI/Android App

You can extend the list of allowed methods in this rule, your crs-setup.conf. Uncomment this rule, and put the DELETE string after the OPTIONS.

[Schroeffu]

Hi @airween sorry didn't have the time yet, will come back here asap with an update

[Schroeffu]

Hi @airween , today i was getting confused because i couldn't reproduce the #Upload failed Part #2 issue, so here is the header log from 10 days ago initially the issue happened:

--460e2719-A--
[28/May/2021:23:54:15 +0200] YLFmg5iURb3zH47gxybUpAAAABM 31(...) 10700 75(...) 443
--460e2719-B--
POST /seafhttp/upload-aj/8edf184d-2(removed)?ret-json=1 HTTP/2.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: application/json; text/javascript, */*; q=0.01
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Disposition: attachment; filename="schroeffu_piwik_2021-05-10_22-39-20.sql.zip"
Content-Range: bytes 0-8388607/216723057
Content-Type: multipart/form-data; boundary=---------------------------42694884464261198072459645484
Content-Length: 8390322
Origin: https://domain.tld
Referer: https://domain.tld/library/4551f3c5-bf6c-4720-b77a-7acbff5719ea/Dateien/
Cookie: sfcsrftoken=Mp0ktQ(removed); sessionid=jc8f232(removed)
Te: trailers
Host: domain.tld

Does this help in any way?

Additionally, to kill all false positives when up/downloading unencrypted (php-)code files into Seafile user storage (domain.tld/seafhttp/repo/xyz), i was adding the following line into modsecurity.conf, is this the right way? Or is there a better way to exclude bodyscans when up/downloading via domain.tld/seafhttp/repo/* in Apache sites-enabled/domain.tld.conf ?

SecRule REQUEST_FILENAME "@beginswith /seafhttp/repo/" "id:1,phase:2,nolog,allow,ctl:ruleEngine=Off" Nevermind, i've added this line into sites-enabled/domaint.tld.conf

[Schroeffu]

just got another fp, the upload via Seafile desktop app seems not adding any Content-Type (i guess because seafile is running by block storage technology)

[Tue Jun 08 01:55:19.170971 2021] [:error] [pid 2280788:tid 140583163045632] [client 31.18.248.74:32344] [client 31.18.248.74] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "702"] [id "920340"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "domain.tld"] [uri "/seafhttp/repo/4551f3c5-bf6c-(removed)/block/fb94a8c(removed)"] [unique_id "YL6x57R7Z6mKY9SsQLQRhgAAAFU"]
[Tue Jun 08 01:55:19.315548 2021] [:error] [pid 2280788:tid 140583070856960] [client 31.18.248.74:32350] [client 31.18.248.74] ModSecurity: Request body no files data length is larger than the configured limit (131072).. Deny with code (413) [hostname "domain.tld"] [uri "/seafhttp/repo/4551f3c5-bf6c-(removed)/block/fb94a8c(removed)"] [unique_id "YL6x57R7Z6mKY9SsQLQRiQAAAFY"]

--bf26fe6b-A--
[08/Jun/2021:01:55:19 +0200] YL6x57R7Z6mKY9SsQLQRiQAAAFY 31.(removed) 32350 75.(removed) 443
--bf26fe6b-B--
PUT /seafhttp/repo/4551f3c5-bf6c-(removed)/block/fb94a8c(removed) HTTP/1.1
Host: domain.tld
Accept: */*
User-Agent: Seafile/7.0(removed)
Seafile-Repo-Token: 1da67(removed)
Content-Length: 6423822

Disarmed via:

    <LocationMatch "/seafhttp">
      #Allow Uploads without Content-Type Header
      SecRuleRemoveById 920340
    </LocationMatch>

[airween]

Hi @Schroeffu,

thanks for the details.

If I'm right, for your first comment today you don't need any help.

For the second issue: looks like you handle the issues perfectly, but let me clear the situation above. The first line shows the rule 920340 which does not have any disruptive action (disruptive actions which makes any intervention, eg deny, drop, etc). This rule just makes a warning.

The problem is that the configured limit for request body is smaller than your request. Just see the log:

...
Content-Length: 6423822

is greater than your config (131072 - which is the default).

Please increase this value if your clients send requests with size of this value. You can do this in the <Location> entry as you showed above, or generally in your modsecurity.conf. As you can see here, the name of the directive is SecRequestBodyNoFilesLimit.

Btw I'm not sure your workaround (put the SecRuleRemoveById) solved this problem.

[Schroeffu]

Thank you for all the explanations, I think I got it why to increase SecRequestBodyNoFilesLimit in this case, as you explained.

I think we can close this issue. Currently my Seafile is working as expected with all the adjustments discussed here :-)

thanks again!

[deniskonovalov64]

Hello, I faced the same problem, but increasing SecRequestBodyNoFilesLimit to 134217728 bytes did not help. SecRequestBodyLimit is set to the default value. (I want to say right away that I do not communicate well in English, I apologize if there are a lot of errors in the text). nginx version: nginx/1.21.4

2022/02/15 11:49:31 [error] 92792#92792: *48 [client 192.168.42.65] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/etc/nginx/modsec/coreruleset-nightly/rules/REQUEST-949-BLOCKING-EVALUATION.conf "] [line "139"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/ 3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic" ] [hostname ""] [uri "/seafhttp/upload-aj/228e006e-7578-467e-8ec1-d3124ab8c252"] [unique_id "1644886171"] [ref ""], client: , server: -,-, request: "POST /seafhttp/upload-aj/228e006e-7578-467e-8ec1-d3124ab8c252?ret-json=1 HTTP/1.1", host: "-", referrer: "-"

[fzipi]

Hi @deniskonovalov64 !

No need to apologize, if we don't understand, we will ask again :)

First, there is a lot of information disclosure in the log you pasted here. Can you clean it from names at least? Also, there should be more information about additional rules matching. Can you provide those in a new issue?

[deniskonovalov64]

Hello @fzipi, thanks for answering my question. Let me clarify a little what you mean by talking about a large number of disclosed information: DNS, hostname, internal IP addresses. Did I understand you correctly?
As soon as I understand what exactly should not be left in the logs, I will definitely publish it in a new issue.

[fzipi]

@deniskonovalov64 Please provide the following if possible:

• Full alert message (ideally send us the full audit log of the request)
• Web server and version or the platform you are using
• ModSecurity version
• CRS version

ATTENTION: When submitting logs, please remove all personal information like IP addresses, hostnames, passwords, etc.

[deniskonovalov64]

Got it, thanks @fzipi