ModSecurity "feature" can trigger cxs report

Community forum to discuss cxs.
If you believe that there is a problem with your cxs installation and want support then, as a paid product, you should use the helpdesk after having consulted the documentation.
7 posts Page 1 of 1
ForumAdmin
Moderator
Posts: 1449
Joined: 01 Oct 2008, 09:24


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.
mtbwacko
Junior Member
Posts: 21
Joined: 01 Apr 2008, 21:37


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
ForumAdmin
Moderator
Posts: 1449
Joined: 01 Oct 2008, 09:24


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.
mtbwacko
Junior Member
Posts: 21
Joined: 01 Apr 2008, 21:37


Excellent. Thanks!
InetBiz
Junior Member
Posts: 16
Joined: 31 Aug 2009, 21:16


How was this setup in modsec2?
chirpy
Moderator
Posts: 3537
Joined: 09 Dec 2006, 18:13


InetBiz wrote:
How was this setup in modsec2?
I don't understand the question. cxs was setup as per the installation instructions for ModSecurity.
xmanflash
Junior Member
Posts: 30
Joined: 10 Mar 2009, 09:42


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
7 posts Page 1 of 1