Page 1 of 1

ModSecurity "feature" can trigger cxs report

Posted: 18 Feb 2011, 10:36
by ForumAdmin
After some extensive testing we've discovered a "feature" in ModSecurity where a cxs scan can report a seemingly non-existent script on a server which is being exploited.

The symptoms:

Code: Select all

Web upload script user: nobody (99)
Web upload script owner: ()
Web upload script: /home/user/public_html/store/admin
Remote IP: 1.2.3.4
Deleted: No
Quarantined: No


----------- SCAN REPORT -----------
(/usr/sbin/cxs --quiet --cgi --mail root /tmp/20100818-170732-TGxLlAoCYgoAAB6qgdMAAAAW-file-gIMTQs)

# Known exploit = [Fingerprint Match]:
'/tmp/20100818-170732-TGxLlAoCYgoAAB6qgdMAAAAW-file-gIMTQs
You will notice that the Web upload script owner is blank and on investigation /home/user/public_html/store/admin does not exist.

The cause:

ModSecurity processes Apache requests in phases. cxs is invoked in Phase 2 of this process where Apache has received the Request Body from the connected browser. What is happening is that at the point of interception by ModSecurity, Apache has not yet checked whether the called web script actually exists on the server (and would normally then return a 404 error).

ModSecurity then processes the Request Body from the HTML multipart/form-data sent by the connecting browser and creates a temporary file in /tmp/ for cxs to scan.

In the above example, that data contains an exploit and cxs correctly reports this and ModSecurity issues the appropriate error code back to the connecting browser (e.g. 403 or 406).

In summary:

Instead of allowing Apache to issue a 404 request to the non-existent script, ModSecurity intercepts the data before Apache performs that check and provides cxs with the data in the request to scan. There is no way around this at present. The only alternative would be to scan the data in Phase 3 (Request Response sent by Apache) which does work (a 404 is generated and so the data discarded). However, this allows genuine but vulnerable scripts on the server to be exploited as the check by ModSecurity is performed in this phase after the target script has been run, and so the exploit will have been successfully uploaded somewhere.

Further actions:

There's nothing we can do about this as it's a feature of the way ModSecurity works. In cxs, we could disregard any requests to scan data to scripts that do not exist, but this could possibly lead to a silent exploit of some kind being uploaded. So, for the instances where this occurs, we will introduce a warning notice in such alert reports that this may be a ModSecurity false-positive. This will appear in the next release of cxs.

Re: ModSecurity "feature" can trigger cxs report

Posted: 05 Mar 2011, 18:54
by mtbwacko
This is happening on a daily basis to our shared server and it appears to be targeting accounts with OSCommerce installed. One point I am not clear from the above description is the overall result of such an attempt. Can I assume that the intrusion is being prevented by cxs and I shouldn't worry about these emails?

Thank you in advance for a reply.

Greg

Re: ModSecurity "feature" can trigger cxs report

Posted: 05 Mar 2011, 20:48
by ForumAdmin
Can I assume that the intrusion is being prevented by cxs and I shouldn't worry about these emails?
Yes. So long as the script definitely doesn't exist, then it doesn't pose a risk as far as we are aware.

Re: ModSecurity "feature" can trigger cxs report

Posted: 06 Mar 2011, 00:24
by mtbwacko
Excellent. Thanks!

Re: ModSecurity "feature" can trigger cxs report

Posted: 15 Mar 2011, 11:07
by InetBiz
How was this setup in modsec2?

Re: ModSecurity "feature" can trigger cxs report

Posted: 20 Mar 2011, 09:53
by chirpy
InetBiz wrote:How was this setup in modsec2?
I don't understand the question. cxs was setup as per the installation instructions for ModSecurity.

Re: ModSecurity "feature" can trigger cxs report

Posted: 20 Mar 2011, 13:56
by xmanflash
Thanks for looking into this folks, I feel better now!

I have literally found these dodgy scripts in my /tmp folder, but I assume that they are not able to ever be run? All of mine have been generated by a php file that does not exist..

Can you shed any light on how a hacker is uploading the tmp file using a non existing script? How would I find out where this exploit resides when the user is missing (i am running suPHP) and the upload script is fake?

Thanks,
Pete