cPanel whm-server-status FP report

_Issue originally created by user YbyMMbPh on date 2017-04-13 11:54:01. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/731._

Centos 6.9 cPanel 64.0.12 Modsecurity Version 2.9.0 CRS v3.0/master Default install, all config files included.

1). Cpanel’s WHM auto generates requests to /whm-server-status from 127.0.0.1 (triggers rule 920280, non-blocking, log only) Once every 5 minutes.

2). Also accessing WHM=>Server Status=>Apache Status page generates request to /whm-server-status from 127.0.0.1 (triggers rule 920280, non-blocking, log only)

3). WHM Plugin Munin-node auto generates requests to /whm-server-status?auto from 127.0.0.1 (triggers rule 920350, non-blocking, log only) Three times every 5 minutes.

Sample Log for variation 1) –daa60036-A– [13/Apr/2017:21:20:01 +1000] WO9e4SdWdpPd96Uh1H1uAAAAIs 127.0.0.1 32938 127.0.0.1 80 –daa60036-B– GET /whm-server-status HTTP/1.0

–daa60036-F– HTTP/1.1 200 OK Connection: close Content-Type: text/html; charset=ISO-8859-1

–daa60036-E–

–daa60036-H– Message: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file “/etc/apache2/conf.d/modsec_vendor_configs/myowaspcrs3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf”] [line “595”] [id “920280”] [rev “2”] [msg “Request Missing a Host Header”] [severity “WARNING”] [ver “OWASP_CRS/3.0.0”] [maturity “9”] [accuracy “9”] [tag “application-multi”] [tag “language-multi”] [tag “platform-multi”] [tag “attack-protocol”] [tag “OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST”] [tag “WASCTC/WASC-21”] [tag “OWASP_TOP_10/A7”] [tag “PCI/6.5.10”] Apache-Handler: server-status Stopwatch: 1492082401921587 5867 (- - -) Stopwatch2: 1492082401921587 5867; combined=2972, p1=533, p2=1922, p3=67, p4=205, p5=159, sr=124, sw=86, l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0. Server: Apache Engine-Mode: “ENABLED”

–daa60036-Z–

Sample Log for variation 2). –b54ce578-A– [14/Apr/2017:09:54:30 +1000] WPAPtkNV6ls4CvTJ-J1rTAAAAIc 127.0.0.1 44968 127.0.0.1 80 –b54ce578-B– GET /whm-server-status/ HTTP/1.0

–b54ce578-F– HTTP/1.1 200 OK Connection: close Content-Type: text/html; charset=ISO-8859-1

–b54ce578-E–

–b54ce578-H– Message: Warning. Pattern match “^/whm-server-status(\/?)$” at REQUEST_FILENAME. [file “/etc/apache2/conf.d/modsec/modsec2.user.conf”] [line “10”] [id “8888777”] [msg “Matched 127.0.0.1 and matched whm-server-status with or without trailing slash. Disabling rules 920280 and 920350. filename=/whm-server-status/”] Apache-Handler: server-status Stopwatch: 1492127670194792 5467 (- - -) Stopwatch2: 1492127670194792 5467; combined=1466, p1=601, p2=551, p3=58, p4=179, p5=75, sr=66, sw=2, l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0. Server: Apache Engine-Mode: “ENABLED”

–b54ce578-Z–

Sample Log for variation 3). –9636be5f-A– [13/Apr/2017:21:20:03 +1000] WO9e46ZgowLAX3XgFiBL0wAAAM0 127.0.0.1 32948 127.0.0.1 80 –9636be5f-B– GET /whm-server-status?auto HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Host: 127.0.0.1:80 User-Agent: munin/2.0.25 (libwww-perl/6.15)

–9636be5f-F– HTTP/1.1 200 OK Content-Length: 1256 Connection: close Content-Type: text/plain; charset=ISO-8859-1

–9636be5f-E–

–9636be5f-H– Message: Warning. Pattern match “^[\d.:]+$” at REQUEST_HEADERS:Host. [file “/etc/apache2/conf.d/modsec_vendor_configs/myowaspcrs3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf”] [line “793”] [id “920350”] [rev “2”] [msg “Host header is a numeric IP address.”] [data “127.0.0.1:80”] [severity “WARNING”] [ver “OWASP_CRS/3.0.0”] [maturity “9”] [accuracy “9”] [tag “application-multi”] [tag “language-multi”] [tag “platform-multi”] [tag “attack-protocol”] [tag “OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST”] [tag “WASCTC/WASC-21”] [tag “OWASP_TOP_10/A7”] [tag “PCI/6.5.10”] Apache-Handler: server-status Stopwatch: 1492082403357429 3781 (- - -) Stopwatch2: 1492082403357429 3781; combined=2207, p1=628, p2=1198, p3=53, p4=109, p5=147, sr=131, sw=72, l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0. Server: Apache Engine-Mode: “ENABLED”

–9636be5f-Z–

The following rule disables both rules for all variations of this request type.

# Rule to allow cPanel whm-server-status requests without log entry.
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" \
  "msg:'Matched 127.0.0.1 and matched whm-server-status with or without trailing slash. Disabling rules 920280 and 920350',\
  phase:1,\
  id:8888777,\
  t:none,\
  pass,\
  nolog,\
  chain"
    SecRule REQUEST_FILENAME "@rx ^/whm-server-status\/?$" \
      "t:none,\
      ctl:ruleRemoveById=920280,\
      ctl:ruleRemoveById=920350"

These false positives have a low impact (logged, non-blocking) to a large number of users (all cPanel admins). With this exclusion rule in place modsec hit logs in cPanel become much more usable and useful for finding new false positives and attack patterns. Not sure if it warrants a REQUEST-903.9003-CPANEL-EXCLUSION-RULES.conf file just for one rule. I have not yet been able to find any other FPs in cPanel or WHM interfaces.

I can see this FP has been raised before in #620 but I cannot see any rules addressing it in CRS v3.0/master.

[CRS-migration-bot]

User lifeforms commented on date 2017-04-19 16:27:22:

A new exclusion category, requiring a config setting, and requiring Nginx/IIS users to modify their included files, would be a bit too much of a big change for a 3.0.1 type release for my personal taste.

However we could also treat it as a more generic case of tools requesting http://127.0.0.1/ (which will surely happen with many more tools) and we might consider not triggering these rules when the remote address is 127.0.0.1 or ::1. If we’d add this as a chained check to the existing rules, we will solve these problems and we will surely catch more false positives. I think it’s benign to get HTTP calls from 127.0.0.1 with a numeric or empty host header. I think there is precedent for ignoring such requests in the CRS too, as Apache’s tooling already does requests to 127.0.0.1 to monitor its own status and we are already specifically excluding those. I just can’t find that CRS rule right now.

[CRS-migration-bot]

User dune73 commented on date 2017-04-19 15:27:08:

As this is technically meant to cover FPs, we’re even staying within the limits defined by our release policy. But what is even more important in my eyes is that we want to encourage the wider community to provide these rules and if we tell them to wait until the next major release, that’s not very contribution-friendly.