ModSecurity "feature" can trigger cxs report
Posted: 18 Feb 2011, 10:36
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:
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.
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-gIMTQsThe 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.