Mining JavaScript Events for Fun & (Preventing Someone Else’s) Profit
For a deep dive analysis on a specific attack or suspicious transactions on a customer’s web application, one of my favorite things to examine is the interaction with the website. There is a wealth of JavaScript information that can be collected to figure out how someone or some bot behaved on the page. In this post, I’ll review some of the key items I investigate to get a sense of the interaction with the page, specifically for desktop web browser data. What’s up with that mouse? I look at mouse clicks and mouse movements. For mouse clicks, one of my favorite phenomenons is what we call a “Magic Mouse.” A Magic Mouse can click in all the right places, but never travels between them. It just magically appears in different locations without any trail. Of course it’s possible to miss some mouse movements depending on how often the JavaScript polls to track them. But if you know the polling conditions, you can easily rule that out as the cause of missing mouse movements. Another interesting component to mouse clicks is where they occur. The best locations to see are negative coordinates, which means the click occurred off the visible screen. In case you are wondering how that’s humanly possible, the answer is - it’s a bot, not a human. If you’re a bot, the world is your oyster and you can click the right web elements, regardless of where they might be - on or off your screen. For mouse movements, I like to look for straight-line tracks. Is it theoretically possible for humans to move their mouse in a straight line? Sure. But if you think this actually happens in real life, then I invite you to draw a “straight line” with your mouse and let me know how it turns out. Moreover, I’d like to know the last time you logged into your bank account while also moving your mouse in a straight line. Beyond straight lines, I also look for identifiable patterns in tracks like fixed or otherwise predictable increases/decreases in the x or y direction. Polling frequency can matter a lot in terms of your ability to identify these patterns. They are generally more nuanced and difficult to spot but are very fun to watch. This process can also be generalized by considering the entropy of the movement. Human users typically have higher entropy in their movement data while bots may struggle to introduce the right amount of randomness in mouse moves. How about those key events? Under normal circumstances, every key movement should have three events: key down, key up, and key press. The first thing to check is whether every movement has all three of these events. It’s odd to find key down events with no key up events or key press events without either up or down events. Such anomalous key movements would be worth further investigation. Key events happening at the same time as mouse movements are also suspicious. It’s difficult for a human, but not for a bot. The next thing to examine for key events is timing. I like to think I’m a quick typer, and I can hit around 85 words per minute (please hold your applause). Since the average English word is 4.7 characters, that puts me at about seven characters per second. So if I see transactions that have seven characters in 10 milliseconds, that seems just a little bit suspicious. Conversely, taking 30 seconds to type seven characters also seems a little odd. That would involve a slow hunt and peck process. The timing between characters can also be interesting. Evenly spaced characters are typically suspicious because humans vary times between different keys based on typing strategy and keyboard layout. Sometimes I also take it a step further and look at the timing between key down and key up events. Too-regular and too-quick timings on these events can also be a red flag, as they fail to align with the organic timings from human typing. Along with general timing and cadence, copy and paste events are always of interest. Specifically, I mean the use of command/control-c and command/control-v, not a browser autofill. Depending on the particular webpage and the completed fields, the level of suspiciousness can vary significantly for copy and paste events. Copy and paste events for a password, for example, don’t usually sway me one way or another because I envision a lot of people who need to retrieve their password from another application. Applications that are good and bad for this purpose is the subject of a different post. Copy and paste events for a username, although slightly less common perhaps, are probably also not too interesting. But copy and paste events for a social security number, or a home address, well now we are talking. All good things with context, as they say. What are the screen dimensions? When I consider screen dimensions, I look at the dimensions for the available real estate, meaning the screen itself, and the browser window. As a single piece of information, the screen dimensions aren’t wildly informative. A lot of real users have their screens set up for multitasking or multi-viewing. And there isn’t always a lot of variation between the screen dimensions used by millions of real humans. But sometimes the screen dimensions are useful for tracking attack traffic over time if they are sufficiently uncommon. In addition, browser windows that are small in relation to the available real estate might set off red flags, particularly if combined with mouse events like those negative-coordinate clicks. And multi-tasking setups, combined with visibility events, may also seem suspicious. Speaking of visibility events, were there any? A visibility event occurs when the user clicks off the main screen and allows another window to become active. If you envision your normal login process, you probably don’t venture off the login page. There are of course legitimate reasons you might move away based on a distraction or retrieving a password. Combined with keyboard events though, like those suspicious copy and paste events, visibility events can be significant. Additional data as needed These categories including mouse events, key events, screen dimensions and visibility events cover the main items I investigate. But there is a treasure trove of behavioral information that can be collected and explored over JavaScript. Moreover, there is a lot more you can do once you consider groups of transactions. Semi-odd data seen once can typically be explained away. But if that same data is seen in multiple transactions, then more red flags may be raised. I hope the items discussed here provide you with a springboard for diving into your own data to investigate suspicious traffic.Using Shape IBD to protect OIDC IdP from Bot Attacks in Open Banking scenarios
Introduction Open Banking implementation standards reserve ample space for describing security controls that need to be in place to secure the access to APIs, with particular focus on end-user consent management. The mechanisms ensuring end-users can securely give banks their consent for third party fintechs to perform banking operations on their behalf, are the bedrock of Open Banking standards. The banks are required to put in place Strong Customer Authentication (SCA) methods allowing the end-user to login to the OIDC IdP/ OAuth Authorization Server to give their consent for the access token to be generated. This implies the existence of a login form, most often reinforced with multi-factor authentication methods. While these methods provide a good measure of defense against less sophisticated threats, bot networks are still capable of being platforms for launching application denial of service or advanced financial fraud attacks so warding off bots allows the defense to keep one step ahead of the attackers. Shape represents best-in-class bot defense available in the market today, relying on a managed service model backed by advanced AI/ML models and dedicated SOC teams. Integrated Bot Defense (IBD) is the first self-service offering from Shape, encapsulated in an easy-to-use form factor. Customers don't need to route their traffic to Shape cloud, IBD integration with Shape backend systems relying instead on API calls. Also, customers can manage the entire onboarding process through the self-service dashboard available on F5's Cloud Services portal, allowing quick addition of new applications to be protected. IBD supports BIG-IP as an insertion point in the customer environment, with more methods to be added. To assist with BIG-IP deployment of IBD, the onboarding process is making available for download a per-application customized iApp template that doesn't require deep BIG-IP expertise to install and provides a wizard-like way of configuring IBD. Setup The high-level diagram of the lab used to simulate an Open Banking deployment is shown below, along with the roles performed by each element: The Open Banking workflow for an authorized end-user is described below: The user logs into the Third Party Provider application ("client") and creates a new funds transfer The TPP application redirects the user to the OAuth Authorization Server / OIDC IdP - PingFederate The user provides its credentials to PingFederate and gets access to the consent management screen where the required "payments" scope will be listed If the user agrees to give consent to the TPP client to make payments out of his/her account, PingFederate will generate an authorization code (and an ID Token) and redirect the user to the TPP client The TPP client opens an MTLS connection to the IdP, authenticates itself with a client certificate, exchanges the authorization code for a user-constrained access token and attaches it as a bearer token to the /domestic-payments call sent to the API gateway over an MTLS session authenticated with the same client certificate The API Gateway terminates the MTLS session and obtains the client certificate authenticates the access token by downloading the JSON Web Keys from PingFederate, checks the hashed client certificate matches the value found in the token and grants conditional access to the backend application. The App Protect WAF and DoS modules perform advanced security checks before releasing the request to the backend server pod. OpenBullet2 launching credential stuffing attacks Integrated Bot Defense installation To install IBD, login to your F5 Cloud Services account, select Integrated Bot Defense and click on Add Application button. Select BIG-IP as the insertion point and click Next. Ensure Web App application type is selected (default) and input the name of the application. Click Save. Download the iApp template, import it into BIG-IP and create an Application. For step-by-step guidance and details on the iApp configuration options, consult the Integrated Bot Defense Configuration Guide for BIG-IP. Testing We used OpenBullet2 to simulate a malicious bot performing credential stuffing attacks against the OIDC IdP / OAuth Authorization Server, PingFederate. Although OpenBullet2 is configured to use valid credentials, no hit is registered after 3 attempts due to IBD blocking all login attempts generated by bots. Examining the F5 Cloud Services dashboard, we can see how IBD identifies and blocks bot sessions while allowing human sessions to pass through. The 3 malicious bots blocked correspond to the 3 attempts made by OpenBullet2 - the valid human traffic has been generated in the background. Conclusion Integrated Bot Defense brings the sophisticated AI/ML technologies used by Shape Defense in a package that is very easy to deploy and configure with minimal configuration changes to the infrastructure components, such as BIG-IP. The ability of IBD to detect advanced tools like OpenBullet2 makes it ideal for securing high-value targets such as Open Banking consent management infrastructure. In this article we demonstrated how IBD can be deployed inside customer's infrastructure, using a BIG-IP device as an insertion point, to protect a PingFederate server acting as OIDC IdP/ OAuth Authorization Server in Open Banking scenarios. Resources The UDF lab environment used to build this configuration can be found here.
Building a Fraud Profile with Device ID+ (Part 1)
Overview End-to-end architecture for IT fraud and security systems is an opaque space and best practices are usually held within the silos of large corporate cybersecurity teams - and for good reason. Cyber vendors are often the only ones who can connect the dots across customers and find pain points that need to be solved. Luckily for me, I have been able to sit down with security experts across all major industry verticals to discuss those pain points. For years, I have assisted their usage of cybersecurity point solutions (e.g., WAF, Bot, Fraud, etc.) from the perspective of API security, server-side exploits, client-side vulnerabilities, and so on. One piece of technology that is common across all cybersecurity architectures is some form of end user or device identifier. It is the single thread that runs across the entire technology stack and each organization uses it to drive fraud prevention and critical business analytics. Creation of an identifier starts when users interact with an application and provide input to it. Normally this happens when the user logs in, creates a new account, or creates a post or comment. This identifier is typically a traditional cookie from a browser fingerprinting solution created in-house or supplied by a third-party service. It is the way organizations identify and track their users and ultimately how they improve their business. At F5, we help security teams across the world’s top organizations understand their users better. Are they lying about their identity? Are they a known good user? Are they committing fraud, or do they appear to be malicious? We have made a large investment (see Shape Security) in creating an identifier that is based on unique signals and, most importantly, trusted by the security and fraud teams who use it. This identifier is known as Device ID+ and it is now available as a free service to anyone who wants to use it. Device ID+ Device ID+ was created to address the following problems with existing web-based identifiers and fingerprinting solutions: Over 30% of users cannot be tracked due to cookie churn. Frequent changes due to the likelihood that one browser will create multiple identifiers. Identifiers are reset after users clear the cache or go into incognito mode. Device ID+ leverages JavaScript to create an identifier that solves the issues of traditional user tracking through cookies. Developers can include a simple JavaScript tag (as shown in the example code) and use it in their application to determine if a user account is good, bad, encountering a bad user experience, has been compromised, and more. One of the major strengths of Device ID+ is that it persists across users who clear or reset their browser and you’ll have an opportunity to see this in action below. The purpose of this article is to give you a quick rundown on what Device ID+ is, why it’s important, and how to use it within your application. As a demonstration, I am going to inject Device ID+ into an existing login form that uses Google’s reCAPTCHA service. Google reCAPTCHA Google reCAPTCHA is the service that shows you pictures of things to verify that you are human. I am not going to address some of the most critical shortcomings of the reCAPTCHAapproach but since it’s a free service and many websites use it to manage bots, I thought it would make a great example on how Device ID+ can be used to strengthen any existing bot or WAF solution. In later articles we’ll trace Device ID+ from its creation to its consumption in fraud analytics. Preventing Application Abuse Since all users are born or recognized at login, I’m going to start with a simple login form. Login is where most of the fraud and malicious activity start and that’s why reCAPTCHA has been used over the years as a free service to try to prevent abuse. Today we are going to create what’s known as a Fraud Profile with Device ID+ and we’ll use it in later articles to super charge our fraud analytics and gain visibility into things like: Fraudulent behavior of automated bots Fraudulent or malicious posts and commenting Fraudulent user account creation Good user friction and unnecessary CAPTCHA challenges About the Demo Application This is a very simple demo application that shows how to layer Device ID+ into an existing application. See it in action at https://deviceid.dev/v3 If you wish to run this example locally as a Docker container, you can deploy it with the following command after installing Docker: docker run -d -p 80:8000 wesleyhales/deviceid.dev Open a browser and visit: http://localhost/v3 Demo Walkthrough For starters, go ahead and login to the application with your email address or any made-up value for the username. There’s no need to enter a password. Fig. 1-1 After you click Submit, you will see a description of the data that was captured. This is our Fraud Profile (Fig 1-2) that we have created for our users. It uses Device ID+ to encapsulate the reCAPTCHA score along with a timestamp of when the transaction took place. Fig. 1-2 Fraud Profiles are viewed differently across the cybersecurity industry. Some security teams build Fraud Profiles around credit card transaction data and others build them throughout specific flows across web pages. Device ID+ can be applied to any Fraud Profile and is built to be used on every page of the application. The more you use it, the more you can enhance good user experiences and/or eliminate actual fraud. The following JSON shows how the example app adds a reCAPTCHA signal to our Device ID+ Fraud Profile: Example of Device ID+ based Fraud Profile Fig. 1-3 Normally, developers would simply capture the score returned from the server side reCAPTCHA API and take action (0.9 in Fig 1-3 above). This score might be used in the authentication logic within the application, simply allowing the user to login if it’s above 0.7. It might also be sent downstream with additional user data to be recorded in a SIEM. The Device ID+ based Fraud Profile provides a structure around existing “scores” or data. This gives us an extendable framework that is decoupled from existing solutions and makes the identifier technology abstract. In our Fraud Profile, the Device ID+ information is located immediately following the username for a couple of reasons: Now we can identify how many different devices a single username is using. Is this account being shared? Is it compromised? Does it violate our terms of service? All of this can be answered by using Device ID+ under the system wide unique identifier (usually this is the username, or an email address as seen in the example). It also brings visibility to important user experience unknowns. Is this a good user who spends money regularly but is encountering too many reCAPTCHA challenges? It is a way to keep your current bot or fraud verification system in check to ensure friction is removed for your good user interactions. The Differentiator As users log in, they will acquire a new Device ID+ cookie which contains the following values. Fig. 1-4 diA is known as the “residue-based identifier”. It is the main identifier used directly after the username in our example. This value is stored locally on the device and may be deleted if the user clears their local storage or cookies. diB is known as the “attribute-based identifier”. This value will remain the same even when the user clears local storage. Keep in mind, it can change if the user upgrades their browser version as it is based on environment signals that remain consistent across browser versions. One easy way to test this feature is to log into the demo application with the same email address twice but using two different browser sessions. Login once in your regular browser and login again with the same browser in incognito mode. Fig. 1-5 In Figure 1-5, we see that the Device ID+ residue values are different for a single username, but the Device ID+ attribute is the same. Conclusion and Next Steps Now that we understand what makes the Device ID+ identification service unique, we can begin to craft ways to take advantage of it in our business analytics. In part 2 of this article series, we are going to analyze the user data from the live demo at https://deviceid.dev/v3 to visualize anomalies and areas where user friction might be occurring. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentation here. If you’d like to add Device ID+ to your own application, you can sign up for a free account here.Building a Fraud Profile with Device ID+ (Part 2 - Analytics and Reporting)
Overview Today there are at least 4.9 million websites using reCAPTCHA, including 28% of the Alexa top 10,000 sites. Google’s reCAPTCHA service is a free offering and developers have been using it for years to try and defend against automation. Many cyber security vendors embed it in their core offering where customers pay subscription service fees for these vendors to “manage” reCAPTCHA and the data it produces. TL;DR - reCAPTCHA is probably causing revenue leakage, false positives and allowing abuse of the web properties that it’s deployed on. How do I know? Watch this demo video I put together the other day. The link is time bookmarked to start at 5:13. The video shows me logging in across 2 different browser sessions and reCAPTCHA returning false positives. Additionally, a simple search on Google or Github reveals the problems that developers face when using reCAPTCHA. reCAPTCHA is embedded into the web’s top sites because it’s free and seems to work. Or does it? What do I mean by “seems to work”? It depends on the business and the type of website, but “works” in this context typically means making the bot or automation problem go away. While developers have been laser focused on solving problems around bot nets, fraudulent users, and overall noise hitting the system, they’ve forgotten about user friction and revenue. In fact, revenue and user friction may be an afterthought for most developers because they don’t see the opportunity to remove friction and again, they have tunnel vision on fixing one particular problem. (For the record I’m not blaming developers, just stating the reality of most engineering organizations and how tasks are managed.) Let’s take a step back. Fraud detection is a framework within web applications and the creation and ongoing maintenance warrants a good bit of architecture and thought. That’s why I’ve been on a pursuit to research and expose the development of a “Fraud Framework” or “Fraud Profile” across the cybersecurity industry. I want to give developers a resource for greenfield projects and rewrites. A place that is open and information flows freely to make the web a safer place. That’s why I started the conversation in Part 1 and I plan on writing as many articles as possible to open up this well-kept secret across the industry. Experienced security engineers are highly sought after because they have been through the pains of developing these systems and architectures. Not only creating them, but making use of the fraud data that they generate. My goal is to make this knowledge freely accessible through this series of articles. This article and video serve as a stepping-stone in my research. In Part 1, we reviewed a simple NodeJS web application that implements a device identifier service to keep the existing fraud system in check, remove user friction and defend against fraudulent activity. The article demonstrates how to add F5’s Device ID+ to an existing application that already uses a basic bot defense or fraud scoring system – in this case reCAPTCHA. Let’s take a look at the live data from our example application deployed at deviceid.dev/v3 to: Analyze user login and transactional scoring data. Understand how well our fraud scoring system is working by looking at good user data. Gain insight into how Device ID+ improves Fraud analytics. Find areas to make changes to our application to remove user friction. Conclusion and Next Steps The example analysis of our Fraud Profile is just the beginning of what can be accomplished with a trustable device identifier. Analytics around user behavior and malicious intent can now be uncovered in new ways in fraud reporting. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentationhere. If you’d like to add Device ID+ to your own application, you can sign up for a free accounthere.2021 Credential Stuffing Report on F5 Labs
Over the last few years, security researchers at F5 and elsewhere have identified credential stuffing as one of the foremost threats. In 2018 and 2019, the combined threats of phishing and credential stuffing made up roughly half of all publicly disclosed breaches in the United States. Now it is February 2021 and the tech industry is reeling from the twin shocks of the theft of FireEye’s red team tools and the SolarWinds Orion supply chain attack. We at Shape & F5 Labs anticipate there will be many more announcements and unwelcome discoveries surrounding credential spills and, it is important to point out, these campaigns also presented an opportunity for attackers to achieve persistence in the environments of thousands of organizations. For this year, we have renamed the Credential Spill Report (previously published by Shape Security, now part of F5) to 2021 Credential Stuffing Report. We did this in order to look at the entire lifecycle of credential abuse, dedicating much time and effort to not just quantifying the trends around credential theft but also to understanding the steps that cybercriminals take to adapt to and surmount enterprise defenses. Some Key Findings in the report include; The number of annual credential spill incidents nearly doubled between 2016 and 2020. Despite consensus about best practices, industry behaviors around password storage remain poor. Median time for discovering a credential spill between 2018 and 2020 was 120 days; the average time to discovery was 327 days. there are many more... Head over to the F5 Labs, 2021 Credential Stuffing Report to see more key findings, dive into the details around terminology and real-world data, look at lifecycle analysis around theft, fraud, sale, and abuse, and lastly - look at some steps you can take to minimize your exposure to the threats around credential stuffing.
F5 Bot Defense for Salesforce Commerce Cloud – Protect Your E-Commerce Site From Unwanted Bots and Illegitimate Traffic (1 of 2)
This article is the first in a two-part series. Go to Part 2 here. Introduction Effective security matters to every retailer of every size because attacks continue to increase, whether engineered by humans or automated by bots. To help all our e-commerce customers succeed, F5 has made security easy to adopt and offers a wide range of integrations, including with cloud-based commerce platforms like Salesforce Commerce Cloud (SFCC). F5 Bot Defense integrates directly into the SFCC storefront and protects your digital business against unwanted bots and illegitimate traffic. Website owners and developers can gain full visibility, protect against credential stuffing, fraud & abuse attacks, and other advanced attacks that bypass traditional security controls. In this article, you will learn how to configure and customize the F5 Bot Defense solution for your SFCC site. The solution is delivered as a certified cartridge and supports both the legacy Site Genesis Salesforce Commerce Cloud eCommerce sites and the modern Storefront Reference Architecture (SFRA) sites. Note: This article contains a fair number of references to Shape Security-related offerings including Shape Enterprise Defense. Shape Security was acquired by F5 in 2020 and many of the products and offerings are currently undergoing a rebranding effort. During a period of time, you will continue to see the Shape branding reflected in the user interface, some settings, and occasionally in product references. Figure 1: F5 Bot Defense for Salesforce Commerce Cloud Deployment Steps The F5 cartridge can be deployed with either Storefront Reference Architecture (SFRA), a controller-based SiteGenesis site, or a pipeline-based SiteGenesis site. The deployment steps outlined below were tested for Salesforce B2C Version 21.7, Compatibility mode 21.2, and SFRA version 6.0.0. Prerequisites F5 Bot Defense requires an API key and a header prefix string for your e-commerce website to connect to the backend engine. Please contact your F5 account team or F5 customer services for any help in obtaining the API key and the prefix string. Step 1: Install the F5 Cartridge and Import the Metadata Firstly, you will install the F5 Cartridge and set up the business manager, for integrating F5 Bot Defense with SFCC. Download and Install the F5 Bot Defense Cartridge Deploy the F5 Bot Defense cartridge using Salesforce UX Studio for Eclipse. Alternatively, you can use Visual Studio code with the Prophet Debugger extension. Download the F5 cartridge from the SFCC LINK Marketplace by clicking on the Download Integration button. Establish a new digital server connection with your SFCC instance. Import cartridges to the workspace in Salesforce UX Studio. Figure 2: F5 Bot Defense cartridge imported into the workspace within Salesforce UX Studio Add the cartridge to the Project Reference of Server Connection. Figure 3: F5 Bot Defense cartridge added to the Project Reference of Server Connection Wait until the Studio completes the workspace build and uploads source codes to the sandbox. Assign the F5 Bot Defense Cartridge to the Storefront Site In the SFCC Business Manager portal, navigate to Administration > Sites > Manage Sites. On the Storefront Sites webpage, click on your site name. Next, click on the Settings tab on the site webpage. At the beginning of the cartridge path, add the following: int_f5:int_f5_sfra: When done, press the Apply button. Figure 4: F5 Bot Defense cartridge path added to the Storefront site Import the Metadata To add the newly configured setting to the Storefront site, you will need to import the pre-defined metadata: Open the downloaded cartridge package and navigate to the /metadata/f-five folder. Click on the Sites folder and rename the RefArch folder to the ID of your storefront site specified in the Business Manager. Then, zip the f-five folder. Navigate to Administration > Site Development > Site Import & Export. Under the Upload Archive section, upload the f-five.zip file and click on the Import button. Figure 5: Import the pre-defined metadata for the site using the ‘Site Import & Export’ feature Continue reading Part 2 here.
