Javascript injecting systems effect on web application end users - a scenario review
Hello! ArvinF is back to share a scenario review where Javascript-injecting systems affected web application end users - web and mobile application. Problem Users are failing to login to a web application protected by BIG-IP ASM/Adv WAF and Shape Security Defense. The site owner notes that the authentication was failing for an unknown reason. There were ASM Support ID noted and an error informing to enable Javascript. Please enable JavaScript to view the page’s content. Your support ID is: xxxxxxxxxxxx Troubleshooting To understand the cause of the authentication failure, we gathered HTTP traffic through a HTTP sniffer. We used httpwatch and gathered HAR (HTTP Archive) files. The site was protected with both on-premise BIG-IP ASM/Adv WAF bot defense and back then, Shape Security Defense (now F5 Distributed Cloud Bot Defense). After the review of the HAR file in httpwatch, the following were noted: ASM blocks a request in a URL related to authentication with a Support ID in the response. There was also javascript code included and it references https[:]//s[.]go-mpulse[.]net/boomerang/. The authentication attempt failed with an error in the HTTP response: ...unable to process your request. Please try again later... BIG-IP ASM/Adv WAF related HTTP cookies from its various features such as Bot Defense Client Side challenges as TSPD_101* cookie was present and other TS cookies, which could also come from Bot defense and DoS profile and security policy configurations. There were also HTTP cookies coming from BIG-IP AVR - f5_cspm cookie was present. Application Visibility and Reporting (AVR) module provides detailed charts and graphs to give you more insight into the performance of web applications, with detailed views on HTTP and TCP stats, as well as system performance (CPU, memory, etc.). https://clouddocs.f5.com/training/community/analytics/html/index.html https://clouddocs.f5.com/api/irules/AVR_CSPM_INJECTION.html Seeing the javascript code referencing "/boomerang/" included in the ASM blocking response was interesting. Reviewing the HAR file, there were several instances of this "/boomerang/". This finding was inquired with the site owner and they noted that there is another system that is in the path between the end users and their web application - a CDN. The traffic flow is as follows: End user web browser / mobile application >>> CDN >>> FW >>> BIG-IP >>> web application On the BIG-IP Virtual Server that fronts the web application, F5 AVR profile, ASM/Adv WAF Bot defense, and security policy and Shape Security defense iRule are configured. From the F5 side, these were the products with features that may insert Javascript in the client-side response. As part of troubleshooting, to isolate the feature that might be causing the failing authentication for the web application, the bot defense profile was removed from the site's Virtual Server and the Shape Security iRule and AVR profile were left untouched. Site owner noted that the authentication works after this change. Shape Security Defense was implemented using an iRule to protect specific URIs. When the iRule was removed from the Virtual Server and the Bot defense and AVR profile were left on, the VS, Site owner noted that the authentication works after this change. But if both ASM/Adv WAF Bot defense and Shape Security Defense iRule is configured on the VS, the site's authentication fails. Per the site owner, there were no changes in the Bot Defense or Shape Security Defense iRule configurations prior to the incident and that these configurations were in place way before the incident. Site owners shared the findings with their respective internal teams for their review. Resolution Afterwards, Site owner shared that their site now works as expected and authentication works for the web application with no changes done on both ASM/Adv WAF Bot defense and Shape Security Defense iRule on the site's VS. The cause of the authentication failure was undetermined. A theory on the possible cause of the issue was perhaps, there was another system inserting Javascript code in the responses and it might have affected the authentication process of the web application by prevented that portion of the site from loading. Additional Troubleshooting Notes The data gathered during the troubleshooting were the qkview and HTTPWatch capture - HAR files. It would help if a packet capture was taken along with the HTTPWatch capture while the issue was happening to have a full view of the issue. Decrypt the packet capture to observe HTTP exchanges and to correlate it with HTTPWatch capture events. The corresponding BIG-IP ASM/Adv WAF application event logs, Bot Defense or DoS protection logs will also be helpful in the correlation. Having a visual idea on how the Security Policy, Bot Defense or DoS protection profile are configured is also helpful - so its good to have a screenshot of these. It helps in analysis when there is complete data. Gathering the asmqkview with report and traffic data and corresponding ASM and AVR db dumps helps in the analysis. asmqkview -s0 --add-request-log --include-traffic-data -f /var/tmp/`/bin/hostname`_asmqkview_`date +%Y%m%d%H%M%S`.tgz #mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` DCC | gzip -9 > /shared/tmp/dcc.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` PLC | gzip -9 > /shared/tmp/plc.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` PRX | gzip -9 > /shared/tmp/prx.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` logdb | gzip -9 > /shared/tmp/logdb.dump.gz It would also help if the systems in the path of the web application are known and whether it has features that may interfere with the features of BIG-IP ASM/Adv WAF or Shape Security Defense. Per the findings, there was a CDN that was injecting javascript code in the HTTP response and it may have contributed to the authentication failure for the end users. Isolate potentially conflicting features by removing one of them one at a time and observe the HTTP responses. Per the reference configuration, BIG-IP ASM/Adv WAF, Shape Security Defense, and BIG-IP AVR worked well prior to the incident. boomerang The injected javascript code noted in the ASM blocking page response was loaded from https[:]//s[.]go-mpulse[.]net/boomerang/. Checking this reference, it was related to https://github.com/akamai/boomerang. boomerang is a JavaScript library that measures the page load time experienced by real users, commonly called RUM (Real User Measurement). It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is. In BIG-IP, the similar product we have is BIG-IP AVR - Application Visibility and Reporting (AVR) - where it collects "performance of web applications, with detailed views on HTTP and TCP stats, as well as system performance (CPU, memory, etc.)." Organizations may have specific needs on data that they need to collect from their site/web application and using a customizable solution such as boomerang can help. That's It For Now I hope this scenario review on Javascript-injecting systems effect on web application end users will be helpful on your next troubleshooting and hopefully gives you guidance on what data to gather and look for and troubleshooting options. The F5 SIRT creates security-related content posted here in DevCentral, sharing the team’s security mindset and knowledge. Feel free to view the articles that are tagged with the following: F5 SIRT series-F5SIRT-this-week-in-security TWISF5 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 ServiceMaking Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator
Introduction To prevent attackers from exploiting mobile apps to launch bots, F5 provides customers with the F5 Distributed Cloud (XC) Mobile SDK, which collects signals for the detection of bots. To gain this protection, the SDK must be integrated into mobile apps, a process F5 explains in clear step-by-step technical documentation. Now, F5 provides an even easier option, the F5 Distributed Cloud Mobile SDK Integrator, a console app that performs the integration directly into app binaries without any need for coding, which means no need for programmer resources, no need to integration delays. The Mobile SDK Integrator supports most iOS and Android native apps. As a console application, it can be tied directly into CI/CD pipelines to support rapid deployments. Use Cases While motivations for using SDK Integrator may vary, below are some of the more common reasons: Emergency integrations can be accomplished quickly and correctly. Customers experiencing active bot attacks may need to integrate with F5 Distributed Cloud Bot Defense immediately and minimize integration risks. Apps using 3rd-party libraries may not be suitable for manual integration, particularly when these libraries do not provide APIs for adding HTTP headers into network requests. In such cases, the SDK Integrator can inject SDK calls into the underlying network stack, bypassing the limitations of the network library. Customers who own multiple apps, which may have different architectures, or are managed by different owners, need a single integration method, one which works for all app architectures and is simple to roll out to multiple teams. The SDK Integrator facilitates a universal integration approach. How It Works The work of the SDK Integrator is done through two commands: the first command creates a configuration profile for the SDK injection, and the second performs the injection. Step 1: $ python3 ./create_config.py --target-os Android --apiguard-config ./base_configuration_android.json --url-filter "*.domain.com/*/login" --enable-logs --outfile my_app_android_profile.dat In Step 1, apiguard-config lets the user specify the base configuration to be used in integration. With url-filter we specify the pattern for URLs which require Bot Defense protection, enable-logs allows for APIGuard logs to be seen in the console, outfile specifies the name of this integration profile. Step 2: $ java -jar SDK-Integrator.jar --plugin F5-XC-Mobile-SDK-Integrator-Android-plugin-4.1.1-4.dat --plugin my_app_android_profile.dat ./input_app.apk --output ./output_app.apk --keystore ~/my-key.keystore --keyname mykeyname --keypass xyz123 --storepass xyz123 In Step 2, we specify which SDK Integrator plugin and configuration profile should be used. In the same step, we can optionally pass parameters for app-signing: keystore, keyname, keypass and storepass. Output parameter specifies the resulting file name. The resulting .apk or .aab file is a fully integrated app, which can be tested and released. Injection steps for iOS are similar. The commands are described in greater detail in the SDK Integrator user guides distributed with the SDK Integrator. Mobile SDK Integrator Video In Conclusion In order to thwart potential attackers from capitalizing on mobile apps to initiate automated bots, The F5 Distributed Cloud Mobile SDK Integrator seamlessly incorporates the SDK into app binaries, completely bypassing the necessity for coding making the process easy and fast. Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDKProtecting 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)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)OWASP Automated Threats - OAT-005 Scalping
Introduction: In thisOWASP Automated ThreatArticle we'll be highlightingOAT-005 Scalpingwith some basic threat information as well as a recorded demo to dive into the concepts deeper. In our demo we'll show how Automation is used to monitor and wait for goods or services to become available and then take rapid action to beat normal users to obtain them. We'll wrap it up by highlightingF5 XC Bot Defenseto show how we solve this problem for our customers. Scalping Description: Acquisition of goods or services using the application in a manner that a normal user would be unable to undertake manually. Although Scalping may include monitoring awaiting availability of the goods or services, and then rapid action to beat normal users to obtain these.Scalping includes the additional concept of limited availability of sought-after goods or services, and is most well known in the ticketing business where the tickets acquired are then resold later at a profit by the scalpers. OWASP Automated Threat (OAT) Identity Number OAT-005 Threat Event Name Scalping Summary Defining Characteristics Obtain limited-availability and/or preferred goods/services by unfair methods. OAT-005 Attack Demographics: Sectors Targeted Parties Affected Data Commonly Misused Other Names and Examples Possible Symptoms Entertainment Many Users NA Bulk purchase High peaks of traffic for certain limited-availability goods or services Financial Application Owner Purchase automation Increased circulation of limited goods reselling on secondary market Retail Purchase bot Queue jumping Ticket Scalping Scalping Demo: In this demo we will be showing a simple example of how automation is used to monitor and wait for goods or services to become available and then take rapid action to beat normal users to obtain them. We'll then have a look at the same attack with F5 Distributed Cloud Bot Defense protecting the application. In Conclusion: Scalping Bots are a real problem for organization and customers as they are made up of a vast ecosystem to acquire large amounts of inventory at scale to be sold for a profit. F5 has the solutions to provide superior efficacy to interrupt and stop this unwanted automation. 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 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 DefenseOWASP 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
Operationlizing Online Fraud Detection, Prevention, and Response
Overview A rapidly growing use of digital channels, ample use of AI and ML programs and an endless availability of stolen user credentials to perpetrate attacks and retool as needed have resulted in more sophisticated and common fraud attacks – resulting in increasingly high fraud losses. Fraud organizations continue to struggle with the volume, sophistication, and rapidly evolving threat landscape. As fraudsters fine tune their attack methods, fraud teams are challenged with increased complexity and operational costs. Operationalizing Online Fraud Prevention Demo See in real-time how Distributed Cloud Account Protectionstops Online Fraud Attacks and provides a simple and intuitive UI for Fraud Analysts to investigate potential fraud and provide direct feedback to the decision making AI Fraud Engine. Demo Portion Begins at 2:31 Related Resources Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud - Part 2 JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) F5 Distributed Cloud Bot Defense (Overview and Demo) F5.com Account ProtectionJavaScript 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 Report
