F5 Distributed Cloud Bot Defense (Overview and Demo)
What is Distributed Cloud Bot Defense? Distributed Cloud Bot Defense protects your web properties from automated attacks by identifying and mitigating malicious bots. Bot Defense uses JavaScript and API calls to collect telemetry and mitigate malicious users within the context of the Distributed Cloud global network. Bot Defense can easily be integrated into existing applications in a number of ways. For applications already routing traffic through Distributed Cloud Mesh Service, Bot Defense is natively integrated into your Distributed Cloud Mesh HTTP load balancers. This integration allows you to configure the Bot Defense service through the HTTP load balancer's configuration in the Distributed Cloud Console. For other applications, connectors are available for several common insertion points that likely already exist in modern application architectures. Once Bot Defense is enabled and configured, you can view and filter traffic and transaction statistics on the Bot Defense dashboard in Distributed Cloud Console to see which users are malicious and how they’re being mitigated. F5 Distributed Cloud Bot Defense is an advanced add-on security feature included in the first launch of the F5 Web Application and API Protection (WAAP) service with seamless integration to protectyour web apps and APIs from a wide variety of attacks in real-time. High Level Distributed Cloud Security Architecture Bot Defense Demo: In this technical demonstration video we will walk through F5 Distributed Cloud Bot Defense, showing you how quick and easy it is to configure, the insights and visibility you have while demonstrating a couple of real attacks with Selenium and Python browser automation. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Hope you enjoyed this Distributed Cloud Bot Defense Overview and Demo. If there are any comments or questions please feel free to reach us in the comments section. Thanks! Related Resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Web Applications Against Critical OWASP Automated Threats Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Enabling F5 Distributed Cloud Client-Side Defense in BIG-IP 17.1 Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Distributed Cloud WAAP Distributed Cloud Services Overview Enable and Configure Bot Defense - F5 Distributed Cloud ServiceUse F5 Distributed Cloud to service chain WAAP and CDN
The Content Delivery Network (CDN) market has become increasingly commoditized. Many providers have augmented their CDN capabilities with WAFs/WAAPs, DNS, load balancing, edge compute, and networking. Managing all these solutions together creates a web of operational complexity, which can be confusing. F5’s synergistic bundling of CDN with Web Application and API Protection (WAAP) benefits those looking for simplicity and ease of use. It provides a way around the complications and silos that many resource-strapped organizations face with their IT systems. This bundling also signifies how CDN has become a commodity product often not purchased independently anymore. This trend is encouraging many competitors to evolve their capabilities to include edge computing – a space where F5 has gained considerable experience in recent years. F5 is rapidly catching up to other providers’ CDNs. F5’s experience and leadership building the world’s best-of-breed Application Delivery Controller (ADC), the BIG-IP load balancer, put it in a unique position to offer the best application delivery and security services directly at the edge with many of its CDN points of presence. With robust regional edge capabilities and a global network, F5 has entered the CDN space with a complementary offering to an already compelling suite of features. This includes the ability to run microservices and Kubernetes workloads anywhere, with a complete range of services to support app infrastructure deployment, scale, and lifecycle management all within a single management console. With advancements made in the application security space at F5, WAAP capabilities are directly integrated into the Distributed Cloud Platform to protect both web apps and APIs. Features include (yet not limited to): Web Application Firewall: Signature + Behavioral WAF functionality Bot Defense: Detect client signals, determining if clients are human or automated DDoS Mitigation: Fully managed by F5 API Security: Continuous inspection and detection of shadow APIs Solution Combining the Distributed Cloud WAAP with CDN as a form of service chaining is a straightforward process. This not only gives you the best security protection for web apps and APIs, but also positions apps regionally to deliver them with low latency and minimal compute per request. In the following solution, we’ve combined Distributed Cloud WAAP and CDN to globally deliver an app protected by a WAF policy from the closest regional point of presence to the user. Follow along as I demonstrate how to configure the basic elements. Configuration Log in to the Distributed Cloud Console and navigate to the DNS Management service. Decide if you want Distributed Cloud to manage the DNS zone as a Primary DNS server or if you’d rather delegate the fully qualified domain name (FQDN) for your app to Distributed Cloud with a CNAME. While using Delegation or Managed DNS is optional, doing so makes it possible for Distributed Cloud to automatically create and manage the SSL certificates needed to securely publish your app. Next, in Distributed Cloud Console, navigate to the Web App and API Protection service, then go to App Firewall, then Add App Firewall. This is where you’ll create the security policy that we’ll later connect our HTTP LB. Let’s use the following basic WAF policy in YAML format, you can paste it directly in to the Console by changing the configuration view to JSON and then changing the format to YAML. Note: This uses the namespace “waap-cdn”, change this to match your individual tenant’s configuration. metadata: name: buytime-waf namespace: waap-cdn labels: {} annotations: {} disable: false spec: blocking: {} detection_settings: signature_selection_setting: default_attack_type_settings: {} high_medium_low_accuracy_signatures: {} enable_suppression: {} enable_threat_campaigns: {} default_violation_settings: {} bot_protection_setting: malicious_bot_action: BLOCK suspicious_bot_action: REPORT good_bot_action: REPORT allow_all_response_codes: {} default_anonymization: {} use_default_blocking_page: {} With the WAF policy saved, it’s time to configure the origin server. Navigate to Load Balancers > Origin Pools, then Add Origin Pool. The following YAML uses a FQDN DNS name reach the app server. Using an IP address for the server is possible as well. metadata: name: buytime-pool namespace: waap-cdn labels: {} annotations: {} disable: false spec: origin_servers: - public_name: dns_name: webserver.f5-cloud-demo.com labels: {} no_tls: {} port: 80 same_as_endpoint_port: {} healthcheck: [] loadbalancer_algorithm: LB_OVERRIDE endpoint_selection: LOCAL_PREFERRED With the supporting WAF and Origin Pool resources configured, it’s time to create the HTTP Load Balancer. Navigate to Load Balancers > HTTP Load Balancers, then create a new one. Use the following YAML to create the LB and use both resources created above. metadata: name: buytime-online namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.waap.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true port: 443 tls_config: default_security: {} no_mtls: {} default_header: {} enable_path_normalize: {} non_default_loadbalancer: {} header_transformation_type: default_header_transformation: {} advertise_on_public_default_vip: {} default_route_pools: - pool: tenant: your-tenant-uid namespace: waap-cdn name: buytime-pool kind: origin_pool weight: 1 priority: 1 endpoint_subsets: {} routes: [] app_firewall: tenant: your-tenant-uid namespace: waap-cdn name: buytime-waf kind: app_firewall add_location: true no_challenge: {} user_id_client_ip: {} disable_rate_limit: {} waf_exclusion_rules: [] data_guard_rules: [] blocked_clients: [] trusted_clients: [] ddos_mitigation_rules: [] service_policies_from_namespace: {} round_robin: {} disable_trust_client_ip_headers: {} disable_ddos_detection: {} disable_malicious_user_detection: {} disable_api_discovery: {} disable_bot_defense: {} disable_api_definition: {} disable_ip_reputation: {} disable_client_side_defense: {} resource_version: "517528014" With the HTTP LB successfully deployed, check that its status is ready on the status page. You can verify the LB is working by sending a basic request using the command line tool, curl. Confirm that the value of the HTTP header “Server” is “volt-adc”. da.potter@lab ~ % curl -I https://buytime.waap.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:23:55 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 136 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049035840-557942247; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:23:55 GMT set-cookie: 1f9403=viJrSNaAp766P6p6EKZK7nyhofjXCVawnskkzsrMBUZIoNQOEUqXFkyymBAGlYPNQXOUBOOYKFfs0ne+fKAT/ozN5PM4S5hmAIiHQ7JAh48P4AP47wwPqdvC22MSsSejQ0upD9oEhkQEeTG1Iro1N9sLh+w+CtFS7WiXmmJFV9FAl3E2; path=/ x-volterra-location: wes-sea server: volt-adc Now it’s time to configure the CDN Distribution and service chain it to the WAAP HTTP LB. Navigate to Content Delivery Network > Distributions, then Add Distribution. The following YAML creates a basic CDN configuration that uses the WAAP HTTP LB above. metadata: name: buytime-cdn namespace: waap-cdn labels: {} annotations: {} disable: false spec: domains: - buytime.f5-cloud-demo.com https_auto_cert: http_redirect: true add_hsts: true tls_config: tls_12_plus: {} add_location: false more_option: cache_ttl_options: cache_ttl_override: 1m origin_pool: public_name: dns_name: buytime.waap.f5-cloud-demo.com use_tls: use_host_header_as_sni: {} tls_config: default_security: {} volterra_trusted_ca: {} no_mtls: {} origin_servers: - public_name: dns_name: buytime.waap.f5-cloud-demo.com follow_origin_redirect: false resource_version: "518473853" After saving the configuration, verify that the status is “Active”. You can confirm the CDN deployment status for each individual region by going to the distribution’s action button “Show Global Status”, and scrolling down to each region to see that each region’s “site_status.status” value is “DEPLOYMENT_STATUS_DEPLOYED”. Verification With the CDN Distribution successfully deployed, it’s possible to confirm with the following basic request using curl. Take note of the two HTTP headers “Server” and “x-cache-status”. The Server value will now be “volt-cdn”, and the x-cache-status will be “MISS” for the first request. da.potter@lab ~ % curl -I https://buytime.f5-cloud-demo.com HTTP/2 200 date: Mon, 17 Oct 2022 23:24:04 GMT content-type: text/html; charset=UTF-8 content-length: 2200 vary: Origin access-control-allow-credentials: true accept-ranges: bytes cache-control: public, max-age=0 last-modified: Wed, 24 Feb 2021 11:06:36 GMT etag: W/"898-177d3b82260" x-envoy-upstream-service-time: 63 strict-transport-security: max-age=31536000 set-cookie: 1f945=1666049044863-471593352; Path=/; Domain=f5-cloud-demo.com; Expires=Sun, 17 Oct 2032 23:24:04 GMT set-cookie: 1f9403=aCNN1JINHqvWPwkVT5OH3c+OIl6+Ve9Xkjx/zfWxz5AaG24IkeYqZ+y6tQqE9CiFkNk+cnU7NP0EYtgGnxV0dLzuo3yHRi3dzVLT7PEUHpYA2YSXbHY6yTijHbj/rSafchaEEnzegqngS4dBwfe56pBZt52MMWsUU9x3P4yMzeeonxcr; path=/ x-volterra-location: dal3-dal server: volt-cdn x-cache-status: MISS strict-transport-security: max-age=31536000 To see a security violation detected by the WAF in real-time, you can simulate a simple XSS exploit with the following curl: da.potter@lab ~ % curl -Gv "https://buytime.f5-cloud-demo.com?<script>('alert:XSS')</script>" * Trying x.x.x.x:443... * Connected to buytime.f5-cloud-demo.com (x.x.x.x) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=buytime.f5-cloud-demo.com * start date: Oct 14 23:51:02 2022 GMT * expire date: Jan 12 23:51:01 2023 GMT * subjectAltName: host "buytime.f5-cloud-demo.com" matched cert's "buytime.f5-cloud-demo.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multiplexing * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x14f010000) > GET /?<script>('alert:XSS')</script> HTTP/2 > Host: buytime.f5-cloud-demo.com > user-agent: curl/7.79.1 > accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 200 < date: Sat, 22 Oct 2022 01:04:39 GMT < content-type: text/html; charset=UTF-8 < content-length: 269 < cache-control: no-cache < pragma: no-cache < set-cookie: 1f945=1666400679155-452898837; Path=/; Domain=f5-cloud-demo.com; Expires=Fri, 22 Oct 2032 01:04:39 GMT < set-cookie: 1f9403=/1b+W13c7xNShbbe6zE3KKUDNPCGbxRMVhI64uZny+HFXxpkJMsCKmDWaihBD4KWm82reTlVsS8MumTYQW6ktFQqXeFvrMDFMSKdNSAbVT+IqQfSuVfVRfrtgRkvgzbDEX9TUIhp3xJV3R1jdbUuAAaj9Dhgdsven8FlCaADENYuIlBE; path=/ < x-volterra-location: dal3-dal < server: volt-cdn < x-cache-status: MISS < strict-transport-security: max-age=31536000 < <html><head><title>Request Rejected</title></head> <body>The requested URL was rejected. Please consult with your administrator.<br/><br/> Your support ID is 85281693-eb72-4891-9099-928ffe00869c<br/><br/><a href='javascript:history.back();'>[Go Back]</a></body></html> * Connection #0 to host buytime.f5-cloud-demo.com left intact Notice that the above request intentionally by-passes the CDN cache and is sent to the HTTP LB for the WAF policy to inspect. With this request rejected, you can confirm the attack by navigating to the WAAP HTTP LB Security page under the WAAP Security section within Apps & APIs. After refreshing the page, you’ll see the security violation under the “Top Attacked” panel. Demo To see all of this in action, watch my video below. This uses all of the configuration details above to make a WAAP + CDN service chain in Distributed Cloud. Additional Guides Virtually deploy this solution in our product simulator, or hands-on with step-by-step comprehensive demo guide. The demo guide includes all the steps, including those that are needed prior to deployment, so that once deployed, the solution works end-to-end without any tweaks to local DNS. The demo guide steps can also be automated with Ansible, in case you'd either like to replicate it or simply want to jump to the end and work your way back. Conclusion This shows just how simple it can be to use the Distributed Cloud CDN to frontend your web app protected by a WAF, all natively within the F5 Distributed Cloud’s regional edge POPs. The advantage of this solution should now be clear – the Distributed Cloud CDN is cloud-agnostic, flexible, agile, and you can enforce security policies anywhere, regardless of whether your web app lives on-prem, in and across clouds, or even at the edge. For more information about Distributed Cloud WAAP and Distributed Cloud CDN, visit the following resources: Product website: https://www.f5.com/cloud/products/cdn Distributed Cloud CDN & WAAP Demo Guide: https://github.com/f5devcentral/xcwaapcdnguide Video: https://youtu.be/OUD8R6j5Q8o Simulator: https://simulator.f5.com/s/waap-cdn Demo Guide: https://github.com/f5devcentral/xcwaapcdnguide
How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively
Prerequisites This article assumes that you have access to the F5 Distributed Cloud and you are using BIG-IP version 17.0. If you have BIG-IP version 14.1 to 16.x you should follow the steps in this article. Log in to your tenant dashboard. You should now see a new tile called Bot Defense. Click on the Bot Defense tile. You are presented with the following screen: Verify the correct "Namespace" in the upper left and then click on “Add Protected Application.” The following screen appears, and you need to supply the highlighted information: Name Region Connector Type Click Save and Exit. Back in the Bot Defense management space, select the application you just created by clicking the … dots, and then Copy the App ID, Tenant ID and API Key to a convenient location, where you will need to access these values when configuring your BIG-IP SaaS Service. Login to your BIG-IP. In version 17.0 you will notice a new tile down on the left side called SaaS Services. Click on Bot Defense. Click on Bot Defense, BD Profiles and click Create. In the following sections I have highlighted sections I want to call out. In addition, another article will be devoted to all the knobs and widgets on this page. I am just discussing the minimum to easily deploy F5 XC Bot Defense. In the first section you are going to fill in the fields with the keys you copied earlier form the F5 XC Bot defense page. Select the BIG-IP to handle the JS injections and the path or URL. Next are the endpoints you want to protect from automated bots. You supply the host, url or path, the method, and the mitigation you desire, continue, redirect, block or drop. These pages typically are login pages and pages subjected to web scraping. Select the Shape Protection pool F5 tells you to use. Select the SSL Profile you are going to use. Click Finished when done. That is how simple and quickly you have protected your application with F5's XC Bot Defense. Next we will switch back to the F5 XC Dashboard and see themitigation taking place. Navigate to Bot Defense, Overview, Monitor.. As you can see, F5's XC Bot Defense was able tosuccessfully stop bot attacks from the endpoints you protected. You are able to see the Countries, the endpoints and the action, along with the number of bots versus human traffic. Related links: YouTube: https://www.youtube.com/watch?v=kHHDOyIQu1c F5: https://www.f5.com/cloud https://www.f5.com/cloud/products/bot-defense Lab: Advanced WAF Demo v17 + LCC, ML, ATI, CSD, XC Bot Defense and GraphQL - VD Solutions https://udf.f5.com/b/a5732e46-d2b9-45d8-9aff-d0d9de52fd0c#documentation
Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK
Introduction The amount of automated attacks that target mobile devices is increasing rapidly each year and causes major financial damage across industries. Today, malicious bots are launched in droves to attack our mobile devices and apps where most of our online activity happens. Unfortunately for developers of mobile apps, many techniques used by traditional bot-defense solutions are not supported by native mobile apps. As a result, if developers do not take precautions, their back-end mobile API components can be exposed to automated attacks such as content scraping, denial of service (DOS), credential stuffing, fake account creation, and a host of others. F5's Mobile SDK is a component of the F5 Distributed Cloud (F5 XC) Bot Defense service. It is designed to protect requests made by native mobile apps.Similar to the web JavaScript solution, Bot Defense Mobile SDK works by gathering telemetry on the mobile device, and sending it to the Bot Defense server as headers with the protected requests. Bot Defense Mobile SDK exists for both iOS and Android, and functions similarly on both platforms. Demo: In our first demo we’re going to navigate through the WAAP (Web App & API Protection) Connector for Distributed Cloud Bot Defense and step through the configuration items to protect a mobile application endpoint In Conclusion: A Mobile app is a prime target for attack because it is so ubiquitous and has been traditionally difficult to secure. Software Development Kits (SDKs) such as the F5 Bot Defense Mobile SDK eliminate that difficulty and enable app developers to quickly integrate critical security features into their code—without having to write additional code themselves. F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Bot Defense Solutions F5 Fraud Solutions F5 Authentication Intelligence The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) OWASP Automated Threats - Credential Stuffing (OAT-008) OWASP Automated Threats - OAT-001 Carding Operationlizing Online Fraud Detection, Prevention, and Response JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense (Overview and Demo)JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo)
JavaScript Supply Chain Attacks are on the Rise With a firewall, a WAF, bot defense, and a SIEM, you control and monitor web traffic entering the data center. Criminals have adapted their strategies to attack your customers in the browser. New web architectures involving dozens of third-party JavaScript files make this new attack surface even more vulnerable. Increasing Web Page Complexity Enterprises cannot keep track of all the scripts and changes that go on in their website and attackers are exploiting this lack of surveillance to introduce malicious code into the supply chain that their web page relies on. Most use 3rd party libraries (eg. Marketing Scripts) Most 3rd party libraries themeselves depend on another set of 3rd party libraries (eg. jQuery.js) Final page loads on end user's browser can easily contain scripts from 20-30 different organizations Magecart, Formjacking, and E-skimming These attacks occur when a threat actor injects one or many malicious scripts into a legitimate page or code repo to create a software supply chain man-in-the-browser attack (SC-MITB). The attacker can then run keyloggers and any other JavaScript based attacks on the end-users browser stealing any credit card data, username and password combinations etc... which will be sent to the attackers command and control server as pictured below. What is Distributed Cloud Client-Side Defense? F5® Distributed Cloud Client-Side Defense (CSD) provides a multi-phase protection system that protects web applications against Magecart-style and other malicious JavaScript attacks. This multi-phase protection system includes detection, alerting, and mitigation. Detection. A continuously evolving signal set allows CSD to understand when scripts on web pages exhibit signs of exfiltration. CSD detects network requests made by malicious scripts that attempt to exfiltrate PII data. Alerting. CSD generates timely alerts on the behavior of malicious scripts, provided by a continuously improving Analysis Engine. The Analysis Engine contains a machine learning component for accurate and informative analysis and provides details on the behavior of malicious script to help troubleshoot and identify the root cause. Mitigation. CSD detects threats in real-time and provides enforcement with one-click mitigation. CSD leverages the same obfuscation and signal technology as F5® Distributed Cloud Bot Defense, delivering unparalleled efficacy. High Level Distributed Cloud Client-Side Defense Architecture Client-Side Defense Demo: Learn about the risks of JavaScript supply-chain attacks (aka Magecart), the costs of Formjacking and PII Harvesting, and how to detect and mitigate this threat vector. Regain security control of your apps with F5’s Distributed Cloud Client-Side Defense. Related Resources Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Client-Side Defense Product Page Client-Side Defense DocumentationBots, Fraud, and the OWASP Automated Threats Project (Overview)
Introduction Many of us have heard of OWASP in the context of the OWASP Top 10. In this article series we will take a look at another very important threat classification list called the OWASP Automated Threats (OAT) Project and provide a foundational overview. The terms Malicious Bot and Automated Threat can be used interchangeably throughout. In future articles we'll dive deeper into individual key threats called OATs and demonstrate how these attacks work and how to defend against them. Why should we care about the OWASP Automated Threats Project? Web security is no longer constrained to inadvertent vulnerabilities and attackers are abusing inherent functionality to conduct Automated and Manual Fraud. Existing technologies are not capable of detecting advancedautomated abuse, fraud teams can’t keep up with new fraud mechanisms,while web users are increasingly adverse to encountering Authentication Friction created by legacy or traditional bot defenses like CAPTCHAs. From its original release in 2015, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying Bots and better understanding all aspects of Malicious Web Automation. What OATs Are Not - Not another vulnerability list - Not an OWASP Top N List - Not threat modelling - Not attack trees - Not non web - Not non application What Are OATs (aka Malicous Bots)? In order to quantify these threats, it is necessary to be able to name them. OAT stands for OWASP Automated Threat and there are currently 21 attack vectors defined. Currently OAT codes 001 to 021 are used. Within each OAT the Threat definition contains a description, the sectors targeted, parties affected, the data commonly misused, and external cross mappings to other lists like CAPEC Category, possible symptoms, suggested countermeasures, etc... Here is the Full List of OATs ordered by ascending name: Identifier OAT Name Summary Defining Characteristics OAT-020 Account Aggregation Use by an intermediary application that collects together multiple accounts and interacts on their behalf OAT-019 Account Creation Create multiple accounts for subsequent misuse OAT-003 Ad Fraud False clicks and fraudulent display of web-placed advertisements OAT-009 CAPTCHA Defeat Solve anti-automation tests OAT-010 Card Cracking Identify missing start/expiry dates and security codes for stolen payment card data by trying different values OAT-001 Carding Multiple payment authorisation attempts used to verify the validity of bulk stolen payment card data OAT-012 Cashing Out Buy goods or obtain cash utilising validated stolen payment card or other user account data OAT-007 Credential Cracking Identify valid login credentials by trying different values for usernames and/or passwords OAT-008 Credential Stuffing Mass log in attempts used to verify the validity of stolen username/password pairs OAT-021 Denial of Inventory Deplete goods or services stock without ever completing the purchase or committing to the transaction OAT-015 Denial of Service Target resources of the application and database servers, or individual user accounts, to achieve denial of service (DoS) OAT-006 Expediting Perform actions to hasten progress of usually slow, tedious or time-consuming actions OAT-004 Fingerprinting Elicit information about the supporting software and framework types and versions OAT-018 Footprinting Probe and explore application to identify its constituents and properties OAT-005 Scalping Obtain limited-availability and/or preferred goods/services by unfair methods OAT-011 Scraping Collect application content and/or other data for use elsewhere OAT-016 Skewing Repeated link clicks, page requests or form submissions intended to alter some metric OAT-013 Sniping Last minute bid or offer for goods or services OAT-017 Spamming Malicious or questionable information addition that appears in public or private content, databases or user messages OAT-002 Token Cracking Mass enumeration of coupon numbers, voucher codes, discount tokens, etc OAT-014 Vulnerability Scanning Crawl and fuzz application to identify weaknesses and possible vulnerabilities Automated Threats Breakdown By Industry Within each OAT definition there is a section for the Sectors Targeted for that particular attack vector. For example, a Carding Attack would be seen on ecommerce and retail type of sites with payment card processing. Here they would be able to validate a list of stolen credit card numbers to identify the working ones from non working. Example: OAT-001 Carding Attack example highlighting "Sectors Targeted" for this type of attack. This exists for each attack definition. OWASP Defined Countermeasures Countermeasure Classes: The technology and vendor agnostic countermeasure classes attempt to group together the types of design, development and operational controls identified from research that are being used to partially or fully mitigate the likelihood and/or impact of automated threats to web applications. In all applications, builder-defender collaboration is key in controlling and mitigating automated threats – the best protected applications do not rely solely upon standalone external operational protections, but also have integrated protection built into the design. Similarly to other types of application security threat, it is important to build consideration of automated threats into multiple phases of a secure software development lifecycle (S-SDLC). 14 Countermeasure Classes: Value Authentication Requirements Rate Testing Monitoring Capacity Instrumentation Obfuscation Contract Fingerprinting Response Reputation Sharing Countermeasure Controls Countermeasures are controls that attempt to mitigate the identified automated threats in three ways: Prevent - Controls to reduce the susceptibility to automated threats Detect - Controls to identify whether a user is an automated process rather than a human, and/or to identify if an automated attack is occurring, or occurred in the past Recover - Controls to assist response to incidents caused by automated threats, including to mitigate the impact of the attack, and to to assist return of the application to its normal state. Cross References Other Threat Mappings Each OAT Threat is cross referenced with other external threat lists to provide and understanding of how this OAT Handbook can be integrated with other works. Example, OAT Threat below shows the cross referenced CAPEC, CWE, and WASC Threat ID's You can find links to each of the external classification models below: Mitre CAPEC - best full and/or partial match CAPEC category IDs and/or attack pattern IDs WASC Threat Classification - best match to threat IDs Mitre Common Weakness Enumeration - closely related base, class & variant weakness IDs Matching pages defining terms classified as Attacks on the OWASP wiki Youtube Conclusion In conclusion, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying and better understanding all aspects of malicious web automation. We can use this handbook to build secure software development lifecycles around our web properties and implement the appropriate countermeasure to prevent unwanted automation against them. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing ReportOWASP Automated Threats - Credential Stuffing (OAT-008)
Introduction: In this OWASP Automated Threat Article we'll be highlighting OAT-008 Credentials Stuffing with some basic threat information as well as a recorded demo to dive into the concepts deeper. In our demo we'll show how Credential Stuffing works with Automation Tools to validate lists of stolen credentials leading to manual Account Takeover and Fraud. We'll wrap it up by highlightingF5 Bot Defenseto show how we solve this problem for our customers. Credential Stuffing Description: Lists of authentication credentials stolen from elsewhere are tested against the application’s authentication mechanisms to identify whether users have re-used the same login credentials. The stolen usernames (often email addresses) and password pairs could have been sourced directly from another application by the attacker, purchased in a criminal marketplace, or obtained from publicly available breach data dumps. Unlike OAT-007 Credential Cracking, Credential Stuffing does not involve any bruteforcing or guessing of values; instead credentials used in other applications are being tested for validity Likelihood & Severity Credential stuffing is one of the most common techniques used to take-over user accounts. Credential stuffing is dangerous to both consumers and enterprises because of the ripple effects of these breaches. Anatomy of Attack The attacker acquires usernames and passwords from a website breach, phishing attack, password dump site. The attacker uses automated tools to test the stolen credentials against many websites (for instance, social media sites, online marketplaces, or web apps). If the login is successful, the attacker knows they have a set of valid credentials. Now the attacker knows they have access to an account. Potential next steps include: Draining stolen accounts of stored value or making purchases. Accessing sensitive information such as credit card numbers, private messages, pictures, or documents. Using the account to send phishing messages or spam. Selling known-valid credentials to one or more of the compromised sites for other attackers to use. OWASP Automated Threat (OAT) Identity Number OAT-008 Threat Event Name Credential Stuffing Summary Defining Characteristics Mass log in attempts used to verify the validity of stolen username/password pairs. OAT-008 Attack Demographics: Sectors Targeted Parties Affected Data Commonly Misused Other Names and Examples Possible Symptoms Entertainment Many Users Authentication Credentials Account Checker Attack Sequential login attempts with different credentials from the same HTTP client (based on IP, User Agent, device, fingerprint, patterns in HTTP headers, etc.) Financial Application Owner Account Checking High number of failed login attempts Government Account Takeover Increased customer complaints of account hijacking through help center or social media outlets Retail Login Stuffing Social Networking Password List Attack Password re-use Use of Stolen Credentials Credential Stuffing Demo: In this demo we will be showing how attackers leverage automation tools with increasing sophistication to execute credential stuffing against the sign in page of a web application. We'll then have a look at the same attack with F5 Distributed Cloud Bot Defense protecting the application. In Conclusion: A common truism in the security industry says that there are two types of companies—those that have been breached, and those that just don’t know it yet. As of 2022, we should be updating that to something like “There are two types of companies—those that acknowledge the threat of credential stuffing and those that will be its victims.” Credential stuffing will be a threat so long as we require users to log in to accounts online. The most comprehensive way to prevent credential stuffing is to use an anti-automation platform. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Bot Defense Solutions F5 Labs "I Was a Human CATPCHA Solver" The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing Report
Protect your Mobile Applications with F5 Distributed Cloud Bot Defense
Introduction The newly released F5 Distributed Cloud (F5XC) Bot Defense iApp v.3.0.3 Connector for BIG-IP supports the following enhancements: Enables Mobile SDK support:Customers can now configure endpoints for web, mobile, or both. Independent SNAT configuration: Customers can configure SNAT for access to F5 Security API separately from SNAT for their protected virtual servers. Syslog improvements:Log messages are now distinguished by syslog severity level and can be associated with a specific transaction.Detailed per-transaction log messages are available if desired. SIEM logging:Users can send log messages to an external logserver/SIEM by using BIG-IP’s High Speed Logging (HSL) feature.(This applies to data generated on the BIG-IPand not to data from F5 Cloud dashboards.) Many additional performance and functional improvements. In this article, I will show you how to protect an Application with the new iApp and how to enable Moblie SDK. Getting Started First login to F5 Distributed Cloud console. Click on the Bot Defense Tile Make sure you are working in the correct Namespace. Click Add Application Give your protected application a Name, Labels and Description. Select your Application Region and F5 BIG-IP iApp as the Connector Type. Click Save and Exit Next, we will download the iApp template created for this application and save it in an accessible location to be installed on your BIG-IP. Now we will import the template, create the Application Service on the BIG-IP and configure the iApp. Log in to your BIG-IP. Navigate to iApps, Templates, Click Templates. Next Click Import. Navigate to the template file you downloaded from F5XC Console. And click Upload Next navigate to Application Services, and click Applications, click Create Give your application a Name and select the template you just uploaded. This will display the iApp page where we will configure all the options to protect your mobile applications. I have covered web applications in previous articles that I will link to at the end. You can select Advanced at the top of the page to see the complete list of options. You must change Mobile SDK options tab shown at the bottom of the image to Yes, to see the correct Security Endpoints. First, again you will be prompted that you need a F5XC Security Mobile SDK Subscription. You will supply what headers are expected from your mobile SDK and Enter the Mobile SDK Reload Header Name supplied by F5. This is used for signaling between the Mobile SDK and the F5XC Security service. Moving to the next section you will cover how the BIG-IP will handle the JS Injections, the URL and/or path and where on the page to inject. The next section has the newly added features for the iApp version 3.0.3. You'll notice at the bottom, you configure what URLs to be routed to the F5XC console. The options are Web, MSDK or Both. I give more details below the image of how to set this up and what to consider when designing your protected endpoints. When Mobile-SDK support is enabled, there are three types of protected endpoints: Web MSDK Both Endpoints marked Bothcan be accessed by either web or MSDK clients. When a client request reaches a Both endpoint, the F5XC Bot Defense iApp assumes the request comes from a web client unless the request includes a Mobile Request ID value shown in the red box above. There are two types of Mobile Request ID’s: Special request headers Special string values embedded in a request body (typically a POST request) To recognize Mobile SDK requests by headers, enter regular expressions to recognize the names and acceptable values of those headers. To recognize Mobile SDK requests by one or more keywords embedded in request-bodies, enter a suitable regular expression, using alternation to recognize different keywords if necessary. Beware of partial matches; use regex operators like ^ and $ and [^\w] as needed. The Actions available for protected endpoints also differ between Web type and MSDK type endpoints. Requests from MSDK clients may be Continued or Blocked but cannot be Redirected or Dropped. Whenever the Action configured for an MSDK request is Redirect or Drop, it is silently converted to Block whenever it is applied to a request from an MSDK client. The host and path are determined by your application. Finally, I want to point out a few features under Advanced Features that were highlighted in the opening of this article. Previous versions of the Bot Defense iApp “borrowed” the SNAT configuration they needed to connect to the F5XC Security Service API server(s) from the virtual-server to which Bot Defense protection was attached. That approach was not optimal, so starting with iApp v3.0.3, a distinct SNAT configuration must be selected. The default option is SNAT Automap: If configured to do so, iApp v3.0.3 will log an informative message about each transaction (a transaction is a distinct client HTTP request). Transaction logging does not directly incur a performance penalty but sending transaction logs to the local control-plane syslogd will incur a large performance penalty. If you want to log transactions, you should enable HSL (High-Speed Logging) to an external log server: Many log servers prefer messages in structured (JSON) format, which you may choose in the iApp. To include some HTTP request headers in transaction log messages (for example, headers which identify site users) specify a regex to match those headers’ names. Make sure you click Finished and you will have deployed your protected application. Closing: I wanted to highlight the changes F5 has made and show how easily you can deploy the iApp and take advantage of all the new features. That is all that you need to configure, to take advantage of F5’s Distributed Cloud Security Service. Note: If you are upgrading from an earlier version of the iApp (for example, iApp v.3.0.2 or v.3.0.1), you need take these steps to avoid possible errors: Prior to installing the v3.0.3 template: Reconfigurethe current Application Service (iApp instance). SetClean Before DeletiontoYes. SelectFinished. Install the v3.0.3 template. Be sure to select theOverwrite existing templatecheckboxbefore uploading the new template. Reconfigurethe current Application Service: SetClean Before DeletiontoNo. Check and update configuration as needed. SelectFinished. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Related Articles: F5 Distributed Cloud Bot Defense Overview: https://community.f5.com/t5/technical-articles/f5-distributed-cloud-bot-defense-overview-and-demo/ta-p/292187 How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense with iApps: https://community.f5.com/t5/technical-articles/how-to-easily-protect-your-big-ip-applications-using-f5-s/ta-p/295578 How to easily protect your BIG-IP applications using F5's Distributed Cloud Bot Defense, natively: https://community.f5.com/t5/technical-articles/how-to-easily-protect-your-big-ip-applications-using-f5-s/ta-p/295590 Get Started: F5 Distributed Cloud Services: https://www.f5.com/cloud F5 Distributed Cloud Bot Defense: https://www.f5.com/cloud/products/bot-defenseProtecting Your Native Mobile Apps with F5 XC Mobile App Shield
Introduction Mobile App Shield is a security technology that integrates directly into mobile applications to provide proactive security against a wide range of attacks, such as tampering, debugging, code injection, code modification and stealing of data from the app. Mobile App Shield is delivered in separate packages for iOS and for Android. Shielding an app with Mobile App Shield is an automated process. Key Capabilities F5 Distribtued Cloud (XC) Mobile App Shield contains multiple security features to counter threats found in the Android and iOS eco-system, and are outlined further below. Product Demo In this Product Demonstration we'll be showcasing Mobile App SHIELD with a product demonstration of how to both integrate SHIELD while also highlighting the protection it provides Conclusion Mobile App Shield represents an advanced security technology seamlessly embedded within mobile applications, offering proactive protection against a diverse array of threats and is easily coupled with XC Bot Defense for comprehensive Mobile App Protection for both Android and iOS. Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Bot Defense Solutions F5 Fraud Solutions F5 Authentication Intelligence The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) OWASP Automated Threats - Credential Stuffing (OAT-008) OWASP Automated Threats - OAT-001 Carding Operationlizing Online Fraud Detection, Prevention, and Response JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense (Overview and Demo)How Attacks Evolve from Bots to Fraud - Part 1
Bot Basics A bot is a software program that performs automated, repetitive, pre-defined tasks. Bots typically imitate or replace human user behavior because they operate much faster than human users. Good Bots make the Internet work - From search engine crawlers that bring the world to your fingertips to chatbots that engage and enhance the user experience. How Do Bots Facilitate Fraud? Bots can also be used to scale automated attacks which can result in account takeover (ATO) and fraud. Motivated cyber criminals leverage a sophisticated arsenal of bots, automation, and evasion techniques. They also perform ongoing reconnaissance to identify security countermeasures and constantly retool their attacks to evade detection. Automated Bot Attack Vector Examples... Credential Stuffing Automated Account Creation Content Scraping High Value Data Credit Application Fraud Gift Card Cracking Application DDoS Aggregator Threats Fake Account Creation Inventory Hoarding Bypass Auth reCAPTCHA The list goes on... Business Impact of Bad Bots Infrastructure Costs - Infrastructure needs to scale to deal with unwanted and/or undetected bot traffic Competitive Intelligence - Web scrapers collect important data to help competitors adjust their pricing strategies Wrong Business Decisions - Bot traffic distorts web site analytics which could lead to making wrong business decisions Sneaker Bots - Bots are buying limited editions of certain products before regular buyers and then sell on black market Account Take-over - Credential stuffing leveraging stolen accounts purchased on the Darkweb providing access Fraudulent Transactions - Fraudulent transactions with large financial consequences as a result of account take-over in the finance sector The Industrialized (organized) Attack Lifecycle Figure 1. It begins with unwanted automation and ends with account takeover and application fraud What are Credential Spills? Credential Spill - A cyber incident in which a combination of username and/or email and password pairs becomes compromised. Date of Announcement - The first time a credential spill becomes public knowledge. This announcement could occur in one of two ways: A breached organization alerts its users and/or the general public A security researcher or reporter discovers a credential spill and breaks the news Date of Discovery - When an organization first learned of its credential spill. Organizations are not always willing to share this information. Stolen Credentials - Criminal Usage by Stage Stage 1: Slow and Quiet Sophisticated threat actors operating in stealth mode - 150 to - 30 days before the public announcement Each credential used (on average) 20 times per day Figure 2. Slow and quiet stage. Attackers use credentials in stealth mode from 150 to 30 days before the public announcement Stage 2: Ramp Up Creds become available on Darknet around ~30 days before public announcement Use of creds ramp up to 70 times per day Figure 3. The ramp-up stage. Attackers ramp up use of compromised credentials 30 days before the public announcement. Stage 3: The Blitz Credentials become public knowledge Script Kiddies + N00bs The first week is absolute chaos - each account attacked > 130 times per day Figure 4. The blitz stage. Script kiddies and other amateurs race to use credentials after the public announcement. Stage 4: Drop-Off / New Equilibrium Creds *should* be worthless at this point... Consumer reuse and lack of change allows for attacker "repackaging" and long tail value Figure 5. The drop-off stage. Credentials no longer have premium value Network Traffic Automation The simplest level of user simulation contains tools that make no attempt toemulate human behavior orhigher levelbrowser activity. They simply craftHTTP requests along specified parameters and pass them along to the target.These are the simplest, cheapest, and fastest tools.Sentry MBAis perhaps thestandard tool of this type. Figure 6. Sentry MBA, a standard user simulation tool Browser and Native App Automation Most of the websites that we interact with every day—online banking, ecommerce, and travel sites—consist of large web applications built on hundreds of thousands of lines of JavaScript. These webpages are not simple documents, so simulating convincing transactions at the network level is extremely complex. At this point, it makes more sense for an attacker to automate activity at the browser level. Until 2017, PhantomJS was the most popular automated browser in the market. When Google released Chrome 59 that year, however, it pushed forward the state of browser automation by exposing a programmatically controllable “headless” mode (that is, absent a graphical user interface) for the world's most popular browser, Chrome. This gave attackers the ability to quickly debug and troubleshoot their programs using the normal Chrome interface while scaling their attacks. Furthermore, just weeks after this announcement, Google developers released Puppeteer, a cross-platform Node.js library that offers intuitive APIs to drive Chrome-like and Firefox browsers. Puppeteer has since become the go-to solution for browser automation, as you can see from its growing popularity in web searches. Figure 7. Google trends graph showing interest in PhantomJS versus Puppeteer between 2010 and 2016. (Source: Google Trends) Simulating Human Behavior The next level of sophistication above simulating a browser is simulating human behavior. It's easy to detect rapid, abrupt mouse movements and repeated clicks at the same page coordinates (such as a Submit button), but it is much harder to detect behavior that includes natural motion and bounded randomness. While Puppeteer and the Chrome DevTools Protocol can generate trusted browser events, such as clicks or mouse movements, they have no embedded functionality to simulate human behavior. Even if perfect human behavior was as simple as including a plug-in, Puppeteer is still a developer-oriented tool that requires coding skill. Enter Browser Automation Studio, or BAS. BAS is a free, Windows-only automation environment that allows users to drag and drop their way to a fully automated browser, no coding needed. Figure 8. Browser Automation Studio User Interface Scaling Up Real Human Behavior As attackers grow in capability, they succeed in creating automated attacks that look more like human behavior. In some contexts, it actually makes more sense to just use actual humans. "Microwork" is a booming industry in which anyone can farm out small tasks in return for pennies. These services describe their jobs as ideal for labeling data destined for machine learning systems and, in theory, that would be a perfect use. In reality, the tasks the human workers perform are helping bypass antibot defenses on social networks, retailers, and any site with a login or sign-up form. Figure 9. Data labeling “microwork” using humans to help bypass antibot defenses In Conclusion Depending on the attacker sophistication level and motivation there are a variety of tools ranging from basic automation to leveraging real humans to attempt to bypass bot defenses and perform account takeover actions. No matter the skill level, most attackers (at least, most cybercriminals) will start off with the cheapest, that is, least sophisticated, attacks in order to maximize rate of return. Able attackers will only increase sophistication (and thereby cost) if their target has implemented countermeasures that detect their original attack, and if the rewards still outweigh that increased cost. Related Content: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud - Part 2 F5 Labs 2021 Credential Stuffing Report
