Using Shape IBD to protect OIDC IdP from Bot Attacks in Open Banking scenarios
Introduction Open Banking implementation standards reserve ample space for describing security controls that need to be in place to secure the access to APIs, with particular focus on end-user consent management. The mechanisms ensuring end-users can securely give banks their consent for third party fintechs to perform banking operations on their behalf, are the bedrock of Open Banking standards. The banks are required to put in place Strong Customer Authentication (SCA) methods allowing the end-user to login to the OIDC IdP/ OAuth Authorization Server to give their consent for the access token to be generated. This implies the existence of a login form, most often reinforced with multi-factor authentication methods. While these methods provide a good measure of defense against less sophisticated threats, bot networks are still capable of being platforms for launching application denial of service or advanced financial fraud attacks so warding off bots allows the defense to keep one step ahead of the attackers. Shape represents best-in-class bot defense available in the market today, relying on a managed service model backed by advanced AI/ML models and dedicated SOC teams. Integrated Bot Defense (IBD) is the first self-service offering from Shape, encapsulated in an easy-to-use form factor. Customers don't need to route their traffic to Shape cloud, IBD integration with Shape backend systems relying instead on API calls. Also, customers can manage the entire onboarding process through the self-service dashboard available on F5's Cloud Services portal, allowing quick addition of new applications to be protected. IBD supports BIG-IP as an insertion point in the customer environment, with more methods to be added. To assist with BIG-IP deployment of IBD, the onboarding process is making available for download a per-application customized iApp template that doesn't require deep BIG-IP expertise to install and provides a wizard-like way of configuring IBD. Setup The high-level diagram of the lab used to simulate an Open Banking deployment is shown below, along with the roles performed by each element: The Open Banking workflow for an authorized end-user is described below: The user logs into the Third Party Provider application ("client") and creates a new funds transfer The TPP application redirects the user to the OAuth Authorization Server / OIDC IdP - PingFederate The user provides its credentials to PingFederate and gets access to the consent management screen where the required "payments" scope will be listed If the user agrees to give consent to the TPP client to make payments out of his/her account, PingFederate will generate an authorization code (and an ID Token) and redirect the user to the TPP client The TPP client opens an MTLS connection to the IdP, authenticates itself with a client certificate, exchanges the authorization code for a user-constrained access token and attaches it as a bearer token to the /domestic-payments call sent to the API gateway over an MTLS session authenticated with the same client certificate The API Gateway terminates the MTLS session and obtains the client certificate authenticates the access token by downloading the JSON Web Keys from PingFederate, checks the hashed client certificate matches the value found in the token and grants conditional access to the backend application. The App Protect WAF and DoS modules perform advanced security checks before releasing the request to the backend server pod. OpenBullet2 launching credential stuffing attacks Integrated Bot Defense installation To install IBD, login to your F5 Cloud Services account, select Integrated Bot Defense and click on Add Application button. Select BIG-IP as the insertion point and click Next. Ensure Web App application type is selected (default) and input the name of the application. Click Save. Download the iApp template, import it into BIG-IP and create an Application. For step-by-step guidance and details on the iApp configuration options, consult the Integrated Bot Defense Configuration Guide for BIG-IP. Testing We used OpenBullet2 to simulate a malicious bot performing credential stuffing attacks against the OIDC IdP / OAuth Authorization Server, PingFederate. Although OpenBullet2 is configured to use valid credentials, no hit is registered after 3 attempts due to IBD blocking all login attempts generated by bots. Examining the F5 Cloud Services dashboard, we can see how IBD identifies and blocks bot sessions while allowing human sessions to pass through. The 3 malicious bots blocked correspond to the 3 attempts made by OpenBullet2 - the valid human traffic has been generated in the background. Conclusion Integrated Bot Defense brings the sophisticated AI/ML technologies used by Shape Defense in a package that is very easy to deploy and configure with minimal configuration changes to the infrastructure components, such as BIG-IP. The ability of IBD to detect advanced tools like OpenBullet2 makes it ideal for securing high-value targets such as Open Banking consent management infrastructure. In this article we demonstrated how IBD can be deployed inside customer's infrastructure, using a BIG-IP device as an insertion point, to protect a PingFederate server acting as OIDC IdP/ OAuth Authorization Server in Open Banking scenarios. Resources The UDF lab environment used to build this configuration can be found here.Knowledge sharing: An example of the general order of precedence for the BIG-IP modules. Also, the F5 ASM DDOS Protection or Bot Protection order of precedence explained.
For the General order of the modules in F5: Packet Filter > AFM > iRule Flow Init event> LTM(or GTM/DNS) >APM > ASM . Also in the AFM there is DDOS at Layer 3 or 4 that is before the AFM rules (the same as the ASM). For the AFM DDOS there is general device DDOS and virtual server specific DDOS and the Genaral Device DDOS takes precedence but it has higher by default thresholds and this why during attack the Virtual server DDOS will in most cases be first activated. The Device DDOS is present even without the AFM module but when there is AFM module it can actually be controlled and configured(not only using the default values). The AFM rules themselves have a conext order(https://techdocs.f5.com/kb/en-us/products/big-ip-afm/manuals/product/network-firewall-policies-implementations-13-1-0/2.html). To see what part of the AFM is blocking you use the packet tracer tool: https://clouddocs.f5.com/training/community/firewall/html/class1/module2/module2.html If needed you can still place the ASM infront the APM by following: https://support.f5.com/csp/article/K54217479 https://support.f5.com/csp/article/K13315545 Other F5 precedences is the GTM/DNS order : https://support.f5.com/csp/article/K14510 The Local traffic object and VIP order for the LTM: https://support.f5.com/csp/article/K9038 https://support.f5.com/csp/article/K14800 The F5 irule event order: https://devcentral.f5.com/s/question/0D51T00006i7X94/irule-event-order-http The picture of the F5 order is from the old F5 401 study guide: As in the newer F5 TMOS versions the Bot defense is seperated from the DDOS Protection and as my tests confirmed first the ASM DDOS is activated then the Bot defense and after that the ASM policy and in the most F5 documentation maybe not writen good this is the case. In the older versons also first the DDOS filtered requests and then the Bot Defense further filtered the traffic before the ASM policy. As of now the Bot protection also generates support id, so if you are blocked and you see support id but in the security policy searches you can't find anything also search the support id under the Bot defence request logs as I found this the hard way. The Bot defence can also make in some cases dynamic signatures for the DDOS in order to stop the traffic at the DDOS checks but I still have not seen this done. https://clouddocs.f5.com/training/community/ddos/html/class7/bados/module4.html For testing web DDOS attacks jmeter is a great free tool and for bigger commercial tests there is cloud platform named RedWolf but Jmeter in most cases will do just fine.Credential Stuffing Tools and Techniques
Credential stuffing is a type of cyberattack that uses credentials obtained from previous breaches to take over accounts on other web or mobile applications. This type of brute force attack relies on the fact that many people use the same usernames and passwords on multiple sites. Peter Silva starts the clock for #CredentialStuffing Tools and Techniques including #OpenBullet in this 90 Seconds of Security episode.
