MTOM requests fail (content-type XOP)

[npsferreira]

Hi all,

I´ve came across with this problem using the mod_security in Apache making requests with MTOM feature on. Tried to search any solution, but only found a similar thread with no solution for this in 2014. Any idea how to bypass the analysis of MTOM requests or if the MTOM request is already supported?

The error i get in the mod_security.log is this: Message: XML parsing error: XML: Failed parsing document. Message: Access denied with code 400 (phase 2). Match of "eq 0" against "REQBODY_ERROR" required. [file "D:/Apache2.2/conf/modsecurity.conf"] [line "56"] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed parsing document."] [severity "CRITICAL"]

Cheers.

[victorhora]

Ok, so my initial investigation on this issue leads to two limitations to explain why MTOM is not being properly handled by ModSecurity:

As a reminder, a vanilla XML/SOAP request would be something like this:

POST / HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 324

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPrice>
    <m:StockName>IBM</m:StockName>
  </m:GetStockPrice>
</soap:Body>

</soap:Envelope>

Which the XML parser of ModSecurity is able to easily understand it because the body would be filled only with XML data and rule ID 200000 would tell ModSecurity to use the XML body parser (ctl:requestBodyProcessor=XML) which hopefully would lead as here if XML parsing completes successfully.

The thing is that MTOM requests uses POST requests in the form of multipart/related[RFC2112] as described here: https://www.w3.org/TR/soap12-mtom/#xop-serialization

So MTOM requests would be something like:

POST / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
MIME-Version: 1.0
Content-Type: multipart/Related; boundary=MIME_boundary;
 type="application/soap+xml"; start="<claim@insurance.com>" 1 
Content-Length: 742

--MIME_boundary
Content-Type: application/soap+xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim@insurance.com> 2 

<soap:Envelope
 xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
 xmlns:xop='http://www.w3.org/2004/08/xop/include'
 xmlns:xop-mime='http://www.w3.org/2005/05/xmlmime'>
 <soap:Body>
 <submitClaim>
  <accountNumber>5XJ45-3B2</accountNumber>
  <eventType>accident</eventType>
  <image xop-mime:content-type='image/jpeg'><xop:Include href="cid:image@insurance.com"/></image> 3 
 </submitClaim>
 </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <image@insurance.com> 4 

...binary JPG image...

--MIME_boundary--

More MTOM examples here: https://en.wikipedia.org/wiki/XML-binary_Optimized_Packaging#Usage_in_SOAP_Web_services https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.webservices.doc/mtomxop/dfhws_attachments_and_SOAP.html

ModSecurity multipart parser, supports inspecting multipart/form-data which seems to be the roadblock for MTOM inspection here.

Trying to force inspection would lead to errors such as: Multipart: Invalid boundary in C-T (characters) or other Multipart parsing errors like the ones handled here.

So unless we could maybe force the XML payload to be inside a variable that ModSecurity can inspect (unlikely), I don't see other method that MTOM can be supported for inspection other than first adding support for an entirely new multipart handler.

[victorhora]

One of the possible workarounds for this issue would be adding a rule to ignore multipart/related requests to avoid that rule ID 200000 ends up blocking traffic due to the XML parser not working as expected for MTOM.

Alternatively, we could also think about updating rule 200000 from modsecurity.conf-recommended itself to take those cases into consideration by default.

Thoughts?

[defanator]

@zimmerle have you had a chance to take a look at this one?

[zimmerle]

Hi @defanator,

Unfortunately not at this exactly moment. Our efforts are dedicated to release version 2.x. Once the release is shipped we are going to make e re-prioritization of the opened issues.

[pi0tr90]

Hi @victorhora, Did you find a solution to this problem? I'm facing the same issue (with ModSecurity 2) and can't figure out what to do. Thanks

[paissad]

Hello, I'm facing the same issue as well. Is there at least any workaround that would let avoid the parsing of the messages of some content-type ? Or whatever else

Regards

[victorhora]

@pi0tr90 / @paissad unfortunately I'm not aware of any other method for proper inspection of MTOM requests without writing a new multipart handler or changing our current handler to take MTOM request into account.

As mentioned above, MTOM uses multipart/related [RFC2112] and ModSecurity accepts and understands the much more common multipart/form-data [RFC2388]. Everything else might not be inspected as shown here:

https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/msc_multipart.c#L83-L86 https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/msc_multipart.c#L779-L783

This is a feature that we like to add, but its not on the pipeline yet due to other more urgent fixes/improvements/features on the way...

As also mentioned above, a simple workaround for this issue would be adding or changing a rule to ignore multipart/related requests to avoid that rule ID 200000 ends up blocking traffic due to the XML parser not working as expected for MTOM.

Something like:

SecRule REQUEST_HEADERS:Content-Type @contains multipart/related "phase:1,id:666,t:lowercase,log,logdata:'ALERT:Ignoring inspection for multipart/related request',allow,"

Might do the trick. Just beware that MTOM requests will NOT be inspected by ModSecurity when placing such a rule. So you might want to do something more clever like changing the regex of rule ID 200000 to ignore multipart/related Content-Type or using something like skip / skipAfter so that other rules can still process the request.

[pi0tr90]

Hi @victorhora OK this is what I feared/guessed from my testing: you can let MTOM content through, but it won't be inspected. Too bad. Regardless, thank you for taking the time to reply on a 3+ yo issue, much appreciated! :)

[paissad]

@victorhora Thanks Thanks for the reply. I tried the following workaround (skip one SecRule rather than everything)

SecRule REQUEST_HEADERS:Content-Type @contains "multipart/related" \ "id:'666',phase:2,t:none,t:lowercase,log,logdata:'ALERT:Ignoring inspection for multipart/related request',pass,skipAfter:200002,severity:5"

Knowing that SecRule 200002 is

SecRule REQBODY_ERROR "!@eq 0" \ "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

But the issue is doing that workaround creates some regressions. For instance, the XSS injection attacks are not blocked anymore ... not even for normal SOAP requests (soap 1.1 & soap 1.2) ... but the MTOM is passing.

And if i remove my workaround, both XSS attacks and MTOM requests are blocked

How should i proceed in order to only skip 'multipart/related' parsing errors ?

Thanks in advance,

[paissad]

@victorhora Finally, i made it by doing the following workaround

SecRule REQUEST_HEADERS:Content-Type "@contains multipart/related" \ "id:'666',phase:1,t:none,t:lowercase,log,logdata:'ALERT:Ignoring XML Processing for multipart/related request',pass,severity:5,ctl:ruleRemoveById=200000"

[victorhora]

Thanks for sharing your rule with the community @paissad. I'm sure others will find useful until this new feature is added on a future release. :)

[studersi]

Could the workaround, suggested by @paissad, be abused to bypass the XML body parser by having the string multipart/related somewhere unexpected in the Content-Type header? A simple example that comes to mind would be a multipart/form-data request which contains multipart/related as part of the part boundary.

I think using @beginsWith instead of @contains should prevent this bypass technique.

[adrienyhuel]

Thank you for the workaround @paissad !

But now that xml parsing is skipped, modsecurity can't trigger the other rules, like SQL Injection detection. @victorhora : Can I ignore XML parsing, but still execute the other rules who inspect body content with regexes ?

[Doriangaensslen]

@paissad
Thanks for sharing your solution, this helped us not just to deactivate the rule

@studersi well thought. Indeed the beginsWith seems the more specific option.

@beginsWith worked in our case too