Hello.

Recently we are seeing the following rule getting triggered by our software and it hasn't happended before in the past.

[Fri Feb 03 15:22:09 2012] [error] [client 208.180.nn.nnn] ModSecurity: Access denied with code 403 (phase 2). Pattern match "((ht|f)tps?:/|\\\\.\\\\./\\\\.\\\\.)" at ARGS:base. [file "/usr/local/apache/conf/modsec_rules/modsec/99_asl_jitp.conf"] [line "3929"] [id "390103"] [rev "1"] [msg "Atomicorp.com UNSUPPORTED DELAYED Rules - Virtual Patch: MyABraCaDaWeb base File Inclusion Vulnerabilities"] [severity "CRITICAL"] [hostname "www.bbbbbbbbbbb.com"] [uri "/wcm/index.php"] [unique_id "TyxQAdC0HLYAAA@1WaQAAAAN"]
[Fri Feb 03 15:22:09 2012] [error]

Doing some Googling on MyABraCaDaWeb, says that the server has this software package "MyABraCaDaWeb" installed on it, and it needs to be updated to the latest version. We don't have that installed. I'm thinking this is some false positive, but just want to make sure.

Has anyone else seen this??

Thanks for the question. This is not a false positive. A rule like this is triggered by the bad guys request, not by what is or is not installed on your system. Its the attack on the server that is detected, and the bad guy is looking for a vulnerable install of MyABraCaDaWeb. If you don't have it installed then you aren't vulnerable. If you do have it installed, you are not vulnerable to this attack because the rules are protecting you.

If you want to know why it may be a good idea for you to detect attacks against applications you may not have installed, please see this blog post:

https://atomicorp.com/company/blogs/231-tripwires.html

Hi Michael,

Thanks for the information, but the rule is triggered when we or our customers simply use our CMS to save data to the database. The URL will look something like this:

http://www.domainname.tld/index.php?config=edit&save=1

And unless I'm reading the rule wrong (which is highly possible),

SecRule ARGS:base "((ht|f)tps?:/|\.\./\.\.)"

This looks like it will trigger based on anything that has https or ftps in the the URL. (which by the way our customer does not).

Our CMS hasn't changed in a few years and this rule has not been triggered in the past, until just last week. That's the part that has me confused.

Thanks,
Peter

OK, I understand now. So if you believe you have a false positive, then we need some additional information. Please follow the process at this link to report the FP:

https://www.atomicorp.com/wiki/index.ph ... _Positives

Or log into the ASL GUI, and just click the False Positive button for the event.

For real time rules, we will release a fix the same day we get the report. For the delayed/unsupported rules you will see the update approximately 90 days after its released for the real time rules users.