Image causes interception (930110 -> /../ in binary)

[yuynagforhacker]

Hi:
Recently, there has been a problem that has been bothering me. When I upload the image, the image binary exists ../ and I know this is not compliant, but there is no way to make smart judgments. This has affected my business and needs help. thanks

[lifeforms]

You are touching on a problematic rule in my opinion. I also have regular trouble with this rule and I wonder if we can make it better.

Is it possible for you to share the image, so we can see the surrounding bytes? If it's private, please don't post it on Github. But if it's okay, it could help us to improve the rule.

Also, can you post the relevant part of your audit log? (Often in /var/log/modsec_audit.log)

[yuynagforhacker]

Of course, but because the picture is too large, the overall binary is too much to copy, the points involved in the binary can be copied, and my audit is fully recorded (from A to Z) and UTF-8
Matched Data: ../ found within REQUEST_BODY: ......\u0013�=\n�../\u001b���\u0001h\u0005��!��.....

[dune73]

What rule are we talking about exactly?

[yuynagforhacker]

"message": "Path Traversal Attack (/../)"
"file": "/usr/local/nginx/conf/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"
"lineNumber": "55"
"ruleId": "930110"

[yuynagforhacker]

Is it because I am using UTF-8 encoding?

[dune73]

Thanks. No, I presume this is just a question of statistics. It's only 4 characters and you have a large binary file...

[dune73]

@lifeforms : Do we really need to check REQUEST_BODY here? We ignore the query string, but we inspect the request body. Does not make much sense.

@yuynagforhacker : Are you familiar with writing rule exclusions?

SecRuleUpdateTargetById 930110 !REQUEST_BODY

entered in the config after the CRS include should do the trick.

[yuynagforhacker]

So there is actually a problem here. Can I exclude it according to the file type of POST? For example, all images will not be detected, not a single rule, because I believe that all rules have probabilistic false positives.

[dune73]

Sure. Such an exclusion is possible. But you will need to write it yourself.

You may find my tutorials at https://netnea.com a helpful resource when tuning away false positives.

[yuynagforhacker]

OK, thanks.

[dune73]

You are welcome. I'm reopening the issue, so we can solve it for good. :)

[lifeforms]

I really hate that this rule has REQUEST_BODY and not ARGS. It makes it almost impossible to write a good exclusion.

This is also not the first complaint by a user about it, so I think we should slate it for 3.2.

I had already made an issue to discuss the problems with this rule: #597 so we can close this one.

Thank you for bringing it to our attention again @yuynagforhacker :D

[dune73]

ACK

[yuynagforhacker]

Thanks all.
At present, if there is no false positive after the rule is corrected, replace ..\ ../ with \..\ /../. Of course, I believe there will be a better solution, and any regular expressions may be triggered.

[yuynagforhacker]

Another problem that has appeared today is also about pictures. I don't know if it is related to photoshop. The rules that trigger are as follows:

"file": "/usr/local/nginx/conf/owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf",
    "data": "Matched Data: <? found within RESPONSE_BODY: �PNG\r\n\u001a\n",
    "lineNumber": "90",
    "ruleId": "953120"

Since php is not used in my server, this rule is currently closed. This rule blocks most of my business images and is shared with everyone here.

塒NG
�
   
IHDR  �? ����   埯慖   �tEXtSoftware Adobe ImageReadyq蒭<  �"iTXtXML:com.adobe.xmp     <?xpacket begin="锘? id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27        "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#" xmp:CreatorTool="Adobe Photoshop CS6 (Windows)" xmpMM:InstanceID="xmp.iid:F48EE09FFC5111E89EF4B496466E1A22" xmpMM:DocumentID="xmp.did:F48EE0A0FC5111E89EF4B496466E1A22"> <xmpMM:DerivedFrom stRef:instanceID="xmp.iid:F48EE09DFC5111E89EF4B496466E1A22" stRef:documentID="xmp.did:F48EE09EFC5111E89EF4B496466E1A22"/> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?>宖曳  >�IDATx陟菹?I?鱿#唱 4z

[lifeforms]

Hi @yuynagforhacker, that's one of the things I'm thinking of :) We will be discussing it in the existing issue #597 so if you are interested please follow that bug!