Skip to content
This repository has been archived by the owner on May 14, 2020. It is now read-only.

SOAPUI SOAP Tx multipart/related call False Positive id: 920470 #1722

Closed
jeremyjpj0916 opened this issue Mar 13, 2020 · 4 comments · Fixed by #1734
Closed

SOAPUI SOAP Tx multipart/related call False Positive id: 920470 #1722

jeremyjpj0916 opened this issue Mar 13, 2020 · 4 comments · Fixed by #1734
Assignees
Labels
False Positive PR available this issue is referenced by an active pull request

Comments

@jeremyjpj0916
Copy link
Contributor

jeremyjpj0916 commented Mar 13, 2020

Description

I already have a pending PR to help with the fact multipart/related is not allowed:
#1721

But, another rule after the above one gets fixed will get hit, which is 920470,
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/master/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf#L870

This only allows (?:boundary|charset) options it looks like for MIME attributes. I think this can be expanded to: (?:boundary|charset|type|start) ( EDIT - Yeah this still didn't work for unblocking me... urgggg)?

Audit Logs / Triggered Rule Numbers

Audit log:

POST /api/test/ext/cimtest/XYZServices/v1 
HTTP/1.1Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type="text/xml"; start="<[email protected]>"; boundary="----=_Part_0_811603706.1584078662023"
SOAPAction: "urn:PegaRULES:SOAP:XYZServices:Services#ProcessGroupECMM"
Authorization: bearer XXXXXXXX
Host: gateway.company.com
MIME-Version: 1.0
Content-Length: 161250
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
X-Forwarded-For: xxxxxxxx
---YimwH2Cz---C--

------=_Part_0_811603706.1584078662023
...... (Redacted payload due to confidential stuff in here)
------=_Part_0_811603706.1584078662023--


---YimwH2Cz---D--


---YimwH2Cz---H--
ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[\w/.+-]+(?:\s?;\s?(?:boundary|charset)\s?=\s?['\"\w.()+,/:=?-]+)?$' against variable `REQUEST_HEADERS:Content-Type' (Value: `multipart/related; type="text/xml"; start="<[email protected]>"; boundary="----=_Part_0_811603706. (14 characters omitted)' ) [file "/usr/local/owasp-modsecurity-crs-3.2.0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "873"] [id "920470"] [rev ""] [msg "Illegal Content-Type header"] [data "multipart/related; type="text/xml"; start="<[email protected]>"; boundary="----=_part_0_811603706.1584078662023""] [severity "2"] [ver "OWASP_CRS/3.2.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [hostname "xxxxxxx"] [uri "/api/test/ext/cimtest/XYZServices/v1"] [unique_id "158407866551.291542"] [ref "v100,114t:lowercase"]

So how about modifying the rule to be like:

#
# Restrict which content-types we accept.
#

# Restrict Content-Type header to established patterns.
#
# This provides generic whitelist protection against vulnerabilities like
# Apache Struts Content-Type arbitrary command execution (CVE-2017-5638).
#
# Examples of allowed patterns:
# - text/plain
# - text/plain; charset="UTF-8"
# - multipart/form-data; boundary=----WebKitFormBoundary12345
# - multipart/related; type="text/xml"
# - multipart/related; start="<[email protected]>"
#
SecRule REQUEST_HEADERS:Content-Type "!@rx ^[\w\d/\.\-\+]+(?:\s?;\s?(?:boundary|charset|type|start)\s?=\s?['\"\w\d\.\-]+)?$" \
    "id:920470,\
    phase:1,\
    block,\
    t:none,t:lowercase,\
    msg:'Illegal Content-Type header',\
    logdata:'%{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-protocol',\
    tag:'OWASP_CRS',\
    tag:'OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE',\
    tag:'WASCTC/WASC-20',\
    tag:'OWASP_TOP_10/A1',\
    tag:'OWASP_AppSensor/EE2',\
    tag:'PCI/12.1',\
    ver:'OWASP_CRS/3.2.0',\
    severity:'CRITICAL',\
    setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

Or maybe that will cause problems w regex to because of 3 attributes deep? Unsure at the moment. EDIT - Yeah this still didn't work for unblocking me... urgggg

Your Environment

  • CRS version (e.g., v3.2.0): 3.2/master
  • Paranoia level setting: 1
  • ModSecurity version (e.g., 2.9.3): 3.0.4
  • Web Server and version (e.g., apache 2.4.41): NGINX
  • Operating System and version: Alpine Linux

Confirmation

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

@dune73
Copy link
Contributor

dune73 commented Mar 16, 2020

Thank you for reporting. I'm more and more seeing a need to review all the content-type rules in its own little project to overhaul them all. Thanks for the contribution.

@jeremyjpj0916
Copy link
Contributor Author

Not the best at fixing them but playing the role of QA and providing FP's is right up my wheelhouse, I can make small fixes 😄 .

@franbuehler
Copy link
Contributor

franbuehler commented Mar 16, 2020

I also see start-info in this multipart/related Content-Type.
And I see this is also a valid param: https://tools.ietf.org/html/rfc2387

So the full list would be: (?:boundary|charset|type|start|start-info) or (?:boundary|charset|type|start(?:-info)?).

I haven't tested that yet.

Example Request Header:
Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:a111aaa1-aa11-1a11-a11a-11a1111aa11a"; start="<[email protected]>"; start-info="application/soap+xml

And here I see more params like action:
https://issues.apache.org/jira/browse/CXF-6431

Example for action:
Content-Type: application/soap+xml; action="urn:hl7-org:v3:PRPA_IN201305UV02"; charset=UTF-8
Source: https://groups.google.com/forum/#!topic/ipf-user/evT5vZb42_w

@franbuehler
Copy link
Contributor

I'll open a PR with the following suggestion for rule 920470:

^[\w\d\/\.\-\+]+(?:\s?;\s?(?:action|boundary|charset|type|start(?:-info)?)\s?=\s?['\"\w\d\.\-\/+<>@:]+)*$

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
False Positive PR available this issue is referenced by an active pull request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants