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.
Enhancing Silverline with F5 Device ID+
Setting the Scene If you haven’t heard already, F5 closed out the year of 2020 by announcing a new and completed free of charge service called F5 Device ID+. The free service is available for all F5 customers with up to 20 million devices. This number of 20 million, refers to the number of unique customer devices that visit your Websites, Applications, and Web based Services. The concept of a Device ID isn’t exactly a new thing, but the way it’s delivered by F5, and the fact that it’s offered at no cost, does make it a unique and revolutionary offering. We have already published a board range of information relating to the service, including a Video Introduction, and Introductory page on F5.com, as well as the getting Started documentation on F5 Cloud Docs. There are multiple ways to configure and consume the new F5 Device ID+ service, and the one we wanted to talk about today, was how and why to combine this new capability through the F5 Silverline Security-as-a-Service solution. What is F5 Device ID+? F5 Device ID+ is a real-time, high-precision device identifier that utilizes advanced signal collection and proven machine learning algorithms to assign a unique identifier to each device visiting your site. Deployment is simple, with immediate benefits for the security, networking, fraud, and digital teams. Never has understanding the unique devices visiting your applications been so easy. When each user visits your website, F5 Device ID+ leverages JavaScript to collect information about the browser, device’s OS, hardware, and network configuration. These attributes feed into F5 Device ID+ service built on F5 Shape’s industry-recognized AI and machine learning capabilities. The data is processed in real time, and a unique identifier is assigned to the device, unless it is already a known device. For returning devices, behaviour, actions, and other properties can be recorded, learned, and studied to facilitate the reduction of fraud and a smooth experience for known good users. Further information on the Use Cases for F5 Device ID+ can be found on the Product overview Datasheet What is F5 Silverline? F5 Silverline is a cloud-based security-as-a-service platform. That can be deployed in front of any application or app infrastructure no matter where they reside across the multi cloud world. It can deliver a broad range of services to secure those applications from emerging and sophisticated threats. F5 Silverline is a fully managed service that combines a 24 by 7 security operations center. With an industry leading technology platform. The SOC is populated with over 150 security experts on hand to facilitate policy lifecycle management and to analyze logs with you to look at threats and the mitigation actions instigated to block them. The Service is managed through an Easy to use customer Portal, which provides rich contextual dashboards, and a comprehensive knowledge base for customers wishing to be self-sufficient and maximise their return on investment. At present the Silverline service can be consumed as 3 primary standalone solutions, or combined together for holistic application and infrastructure protection. F5 Silverline DDoS Protection service, provides comprehensive, high performance protection from Distributed Denial of Service (DDoS) attacks, with real-time cloud scrubbing services. F5 Silverline Shape Defense solution, prevents a broad range of online automated fraud to keep your applications and digital assets safe, and Bot Free. F5 Silverline Web Application Firewall service, will help defend your application capital from emerging and sophisticated threats, to ensure business continuity for critical applications and your digital presence. We also have an additional Add on Service for F5 Silverline Threat Intelligence, which integrates dynamic lists of threatening addresses based on IP reputation to give additional context for policy decisions. All of these Services are designed to help organisations tackle the challenges of their digital transformation journey. And as of December 2020, we now also offer the F5 Device ID+ service to all F5 Silverline Customers, in order for the Silverline Cloud to inject the required Javascript in to all HTTPS traffic flow to Applications secured through the Silverline Service. Why enable F5 Device ID+ for F5 Silverline? F5 is the industry leader in Application Delivery and Application Security Services. F5 Silverline is the simplest and most cost effect way to deploy and operated a globally dispersed Application Services solution, and F5 Shape provides the most innovative and comprehensive range of anti-bot and anti-fraud solutions, with a laser focus on effectively identifying devices and their intentions. F5 Silverline provides a zero-effort way to activate and consume the F5 Device ID+ service, powered by the machine learning analysis of Device, Browser, network and environmental signals and telemetry discovered by the F5 Shape Cloud AI engine. Bringing these two great services together is a bit of a no brainer, and existing F5 Silverline customers, can simply flip a Toggle switch to get the HTTPS enabled applications provisioned to start processing traffic in real time, and assigning a unique identifier to every device interacting with your websites and Apps. If you're new to F5 and want to take advantage of this unique combination of Fully Managed Services, you can request a free trial of the F5 Silverline WAF or F5 Silverline Shape Defense at F5.com. How to Onboard Your Silverline Protected Applications with Device ID+ Device ID+ can only be configured on HTTPS services for Applications provisioned as an Application Proxy within the Silverline system. Application proxies are the recommended way to deploy HTTP & HTTPS Services to your protected Web Applications and allow you to take advantage of the Silverline Regional POPs and newer services such as Multi-FQDN configuration and Silverline Shape Defense. More information on the configuration and Application Proxies can be found on the support knowledge base HERE Navigate to the Application Proxy you wish to enable for Device ID+ and follow these steps to activate the configuration: 1.Navigate to the HTTPS Service on the Application Proxy 2.Navigate to the Shape Security Tab 3.Switch the DeviceID+ Toggle to the ON position 4.Fill in the Javascript Insertion Service Configuration section: a.Define the Shape Javascript Path – create a name for the Javascript you want to insert on to the pages i.Must be unique and cannot already be in use in your Application ii.Do Not Use a name that indicated Shape or Silverline in the path b.Define the Javascript Insertion Location – to indicate where you want the Javascript to be inserted in the page i.Before <script> ii.After <head> (our preferred option) iii.After <title> iv.Other – Customer-configured c.Specify any Excluded Paths – Define any HTTP Paths where you do NOT want to insert the F5 DeviceID+ Javascript If you are not able to locate the Shape Security Tab, or the Device ID+ Toggle switch, please contact the Silverline SOC for assistance. Working with an F5 Device ID+ Deployment In order for you to then be able to leverage the F5 Device ID+ identifiers, there will be some work that you need to do in your Application logic. Full details on how to work with this solution can be found on the F5 Cloud Docs website HERE You will find the details of the two unique identifiers the solution creates. residue-based identifier and an attribute-based identifier. The residue-based identifier is based on local storage and cookies. The attribute-based identifier is based on signals collected on the device. The two identifiers always have different values. The residue-based identifier will change whenever local storage is deleted, such as when a user clears cookies. We expect this identifier will have lower persistence and hence high divisions, that is, the same device might appear to have different residue-based identifiers over time. On the other hand, because the residue-based identifier is a sufficiently long random string, there is nearly no chance of collision (that is, when one identifier is shared by more than one device). The attribute-based identifier, based on signals collected from the device, is more persistent in that it will remain the same even when the user clears local storage. However, the attribute-based identifier could change when certain events occur such as a browser update, configuration change, or hardware change. Device ID+ continuously strives to base the identifier on the most persistent of signals, those least likely to change. The attribute-based identifier, however, does not guarantee persistence. It is possible for two devices to share an attribute-based identifier if the devices are sufficiently similar. Again, F5 performs continuous research to collect signals that will minimize collisions. Maximising the use of F5 Device ID+ Your initial thoughts may well be that the solution seems limited in its current form, and that we are asking your development teams to do the heavy lifting, to actually start to leverage the Device identifiers. In some ways this is true, however it’s likely that you are already using some kind of session tracking or device identifier, such as cookies. All we are providing is a more reliable and tamper proof alternative identifier, as part of this free service. This service will enhance your visibility and awareness of the users and devices traversing your websites and application, but the story doesn’t end there. F5 does offer several additional Security solutions that leverage this fundamental Device ID+ to provide advanced Bot Detection, and other anti-fraud capabilities. The F5 Device ID+ service should be seen as a foundational element to your overall security posture. As such, in the very near future, we will be enhancing the F5 Silverline Customer Portal with some additional Dashboard charts built on the Device ID+ Analytics. Future Visibility for Device ID+ in F5 Silverline In the next phase of development, we will be adding additional visibility and analytics gathered from DeviceID+ into the Silverline Dashboards, charts and Statistics. Existing customers can get details as they are released by subscribingto our release notes by following the details in this Support Knowledge Base Article What this means for you The F5 Silverline Portal already provides a very rich set of analytics, performance and security related dashboards, statistics and charts. All aimed at increasing your situational awareness of your Application Security posture. Adding F5 Device ID+ to this already powerful set of analytics, will further enhance your awareness of application traffic, and any potential risks to your infrastructure, Websites, and Services. F5 Silverline delivers Industry leading protection for multi-cloud hosted applications and services. It ensures that Applications stay online and available to improve the end user experience, while delivering business continuity for critical application and digital assets. The Service will help you reduce operating costs in the time and management of Application security, as well as the operational overhead on in-house IT resources and skills, by leveraging the Silverline SOC cyber security experts to augment IT security staff 24x7 The comprehensive mitigation techniques implemented through the F5 Silverline Web Application Firewall service help drive efficiencies in your application security and deliver complete visibility and insight into application attacks. F5 Silverline Shape Defense has been a huge hit with our customers so far, as the zero impact deployments really help demonstrate a rapid return on investment, while reducing the time to achieve and the cost of managing Bot and automate fraud prevention. Adding Device ID+ Dashboard charts will provide unparalleled visibility and reporting for all human, automated and/or bot traffic, while ensuring your applications and digital assets are online and available.Introducing App Proxies for F5 Silverline
Introduction When F5 Silverline was first introduced to the market back in 2014, the service was heavily focused on DDoS Mitigation through our globally dispersed Scrubbing centers. Traffic handling and customer configuration was very network focused and IP based. However with well documentation limitations of available IPv4 address spaces, combined with the need for greater agility of our Layer 7 Application services a new Proxy configuration construct was needed to help scale the F5 Silverline cloud service to a new Regional POP (point of presence) based architecture. Historically all Application level configuration through the Silverline service was provisioned through our Classic Proxy methodology, however this functionality had a variety of limitations, so is slowly being deprecated within the Portal. These Classic Proxies, have now been replaced by two separate Proxy configuration objects. Any customers using the Silverline Portal today will see the following two Proxy types, the DDoS Proxy, and the Application Proxy. The DDoS Proxies, support TCP, UDP and DNS based configuration elements, focused on cleaning and controlling traffic flow to a customer’s infrastructure. Details of what can and can’t be configured through these constructs will be discussed in a future article, but for now we will focus on the Application Proxies, or “App Proxy” for short. What is on App Proxy? An App Proxy is the friendly name we use for the logical configuration construct within the Silverline customer portal. Each Application or website a customer wishes to protect will typically have it’s own App Proxy configured via the portal, for the relevant configuration objects to be automatically deployed across the globe within the Silverline cloud service. An App Proxy allows for a single configuration construct that includes objects for the Incoming expected URL’s for traffic to ingress in to the Silverline service, as well as the Back End configuration objects for your Application Origin Servers. The Construct also of course includes or the Security profiles that you wish to be applied by the Silverline service to protect and secure your application traffic from threats and attacks, before forwarding the good and clean traffic on to your App. F5 Silverline Web Application Firewall service does act as a Full Proxy configuration, so the returning traffic from your App to the client will also traverse the Silverline cloud, and the response will also be inspected and checked for security purposes. Why should you use them? For all new customers subscribing to F5 Silverline today, will see the App Proxy construct as the most logical way to provision Application services to their protected Apps, but for existing customers currently configured with Classic Proxies may need guidance for why to migrate to the new Proxy type, so lets run through some of the reasons to opt for an App Proxy. Firstly in order to leverage the new Regional POP’s (rPOP) for your Application Security, then the App Proxy construct is the only way to gain access to them. I’ll go into a little bit more detail as to why this is in the next section, but primarily this is to do with the way CNAMEs are issues to the App Proxy, in order to Globally Load Balance traffic to your Application from users based all across the globe. The next reason to use them, is because they are very easy to use, and act as a single logical construct for all your Application security needs. Within the App Proxy, you can apply a variety of security policies, such as, a Web Application Firewall (or WAF) policy, a Layer 7 DDoS Profile, a Shape powered Anti-Bot profile, a Threat Intelligence Profile, and the additional benefits of F5 iRule’s for increased security and functionality. The App Proxy construct also facilitates a single place to configured all your TLS & SSL needs for handling both Client-side and Server-side SSL certificates and ciphers. In June 2020, we also introduced a new Service to the Silverline portfolio, with the introduction of F5 Silverline Shape Defense, this innovative new Service is designed to protect your web applications from automated bot attacks to prevent large-scale fraud, inflated operational costs, and friction for your end users. The configuration of Silverline Shape Defense, is only supported through the new App Proxy construct, and provides a collective defense strategy to detect and block automate bot traffic. A great example of how effective the combination of the Silverline Service is to defend against automated attacks such as Credential Stuffing, can be found on our YouTube Real Attack Stories playlist HERE How do they work? If you're still not convinced by the advantages you can gain from our App Proxies, then maybe we should look at their configuration and functionality in a bit more detail. First let’s look at some of the configuration options in the App Proxy: Shown here is an example of the configuration for the Front End and Back End section of a new App Proxy in the Silverline Portal. There are several items that need to be defined by the customer, including the display name for the App Proxy, which would typically be something logical and relating to the purpose of the App we are protecting. The more important field in the Blue section, is the Fully Qualified Domain Name, which needs to be correct for the URL of the Application we are going to receive traffic for. During the provisioning of the App Proxy, the Silverline Portal will automatically assign a CNAME in the f5silverline.com domain space, which will be used to redirect traffic to the Silverline service. (more on this shortly) There are a couple of additional fields, for adding some descriptive notes, and also the ability for you to define custom Tags, as part of the Silverline Role Based Access Control (RBAC) configuration, which allow for granular access control to configuration objects and data analytics by user. The Back End Section allows you to define either an IP Address, or a DNS name for the Back-end or Origin Server of your Application. You can then select which of the Silverline Points of Presence you wish to deploy the configuration of the App Proxy too. You can choose to select them all, or just the ones in which you wish the Silverline Service to be able to Decrypt any HTTPS related traffic, which could help address any compliance or performance needs. Now this is where things start to get interesting! As well as the flexibility to select which POP’s you wish to deploy your App Proxy too, you also have the ability to configure Multiple different Back-ends. Which means, that if you have your Application hosted in multiple different locations, you can configure each one individually as needed, and then select only the Silverline POP’s from the same regions as your own Datacenters, or Public Cloud hosted Apps. We of course being F5 will handle all the Load Balancing and Global Server Load balancing as needed to ensure data is ingressed in to Silverline at the closet point to the users, and exits Silverline at the closest point , and with the optimum route to you back-end origin servers, regardless of how simple or complex the configuration becomes. After setting up the Front and Back end configuration, you can then move to the HTTP or HTTPS Service tab to start to define your security policies and profiles. If you have the Silverline Add-on service for Threat Intelligence, you can create a policy to block different threatening sources based on dynamic IP reputation categories: Most customers opt to block all the known bad IP address categories, but the flexibility is there for you to granularly control. You can specify the Ports: And the iRules you wish to apply to the App Proxy: If your leveraging the F5 Silverline Web Application Firewall service, this would also be the section where you can apply your WAF policies and any L7 DDoS configuration as well, but as both of these elements can be quite complex, I will be dedicating a future article to each of these topics individually. I’ll also be writing another article specifically relating to the F5 Silverline Shape Defense service, and the configuration options you would have in the Portal. Which would also be configured under the App Proxy construct, and even has it’s own full page of options. There are some other configurable options in the Advanced tab, which vary based on the objects and settings you configure in the App Proxy. Which we don’t have time to cover today. The one thing I did want to go in to more detail about however, is how traffic actually gets directed to your App Proxy, and the relevance of the CNAME I referenced earlier. Handling GSLB to App Proxies As a critical element to the Regional POP expansion and the App Proxy construct, we need to look in to a bit of detail about how DNS is used to direct traffic to the Silverline Service, in what we refer to as “Proxy Mode”. The Service can also use “Routed mode” the leverage BGP route advertisement to redirect all of your traffic through Silverline, but this is typically reserved for tour F5 Silverline DDoS Protection customers. In Proxy Mode, we need to leverage DNS in order to get traffic destined for your Websites and Applications, to be redirected first to the F5 Silverline Cloud for processing. So when you provision a new App Proxy in the Portal, you will be allocated a CNAME record that we specific bind to your App Proxy. In your own DNS system, you will then need to modify the DNS response for your relevant Application from its original IP, to the CNAME of the Silverline App Proxy. While you’re doing this, you can also set the TTL to a longer time period such as an Hour or more. The Silverline Service will automatically provision you a new GSLB record in our GSLB solution. We will set the TTL of this record to 30 seconds, to help with our dynamic autoscaling and orchestrated App Proxy deployment methodology. Depending on the number of POP’s you selected for the App Proxy, we will add the different dynamic IP addresses of the different Regional POP’s to the GSLB system. For each rPOP,your App Proxy GSLB record will be populated with 3 separate IP Addresses, to span different availability zones. As requests come in for different users in different regions’ around the globe, we will then issue the relevant IP address closest to the clients LDNS. Our primary Scrubbing centers, will typically leverage an IP Anycast address, which also gets added to the GSLB pool. It’s a difficult thing to put in to a single image, but here is an example of the GSLB style system for our App Proxies: This GSLB solution for App Proxies, provide a lot of benefits and flexibility for Global availability and the capability for us to dynamically scale the Silverline cloud platform as need demands. Are there any recently introduced App Proxy features? Also, in recent times, we have also just added support for “Multi-FQDN” support within a single App Proxy. This means, that as long as your Back-end Origin Servers can serve the content to each of the FQDN’s or URL’s of your application, then you can provision them all as a single App Proxy to save administrative overhead, and to simplify security and policy tuning. Each individual FQDN, can be define in the App Proxy Front end screen, and assigned the relevant Client-side SSL Profile. As shown in the example image below: As you then move through the Security Tabs of the App Proxy configuration page in the portal, you will be able to define which L7 DDoS Profile and WAF policy to assign to each or all of the define FQDN’s. Each defined FQDN, can then be handled by the same Silverline allocated CNAME DNS record, and handled by our GSLB solution. What are the benefits of F5 Silverline App Proxies? Hopefully you can now see what many of the benefits are for leveraging the new App Proxy construct within the F5 Silverline Portal for deploying you Layer 7 Security Services. They really are easy to use, and provide a single logical structure for all your Application Security needs. They have a great amount of flexibility and functionality to meet the changing needs of your applications. The use of CNAME records for traffic redirection through the Silverline Proxy mode, helps with dynamic scale and Global availability of your Apps. What does the future hold for App Proxies? For anyone familiar with F5 Silverline, you will know we operate a two week release cycle of Portal & Platform enhancements. All new Application delivery and Application Security features, will be built around the App Proxy construct. So if you want your Apps to benefit from the innovative new features in the roadmap for Silverline, now is the time to start to leverage the F5 Silverline App Proxy!
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.Lightboard Lessons: Silverline Architecture
In this edition of Lightboard Lessons, I cover the architectural overview of F5’s Silverline managed security services proxy and routed modes. The granular details of the scrubbing center architecture, as well as the overall DDoS and WAF architectures, are available via the links below. Resources Silverline DDoS Architecture Silverline WAF Architecture Silverline Threat Intelligence Technorati Tags: security, silverline, lightboard lessonsHow AI Will Automate Cybersecurity in the Post-COVID World
Widespread remote working is accelerating the trend of digitization in society and a derivative trend of this acceleration is our increased reliance on online applications - which also means cybercrime is becoming more lucrative. Over on F5 Labs, Shuman Ghosemajumder briefly introduces the problem space and links to an article on VentureBeat about how AI will Automate cybersecurity in a Post-Covid world. https://www.f5.com/labs/articles/bylines/how-ai-will-automate-cybersecurity-in-the-post-covid-worldLightboard Lessons: F5 DDoS Hybrid Defender
F5 is committed to bringing purpose-built security solutions to market. DDoS Hybrid Defender (DHD) is a purpose-built hybrid solution that provides comprehensive L3-7 DDoS mitigation, to prevent network, application, and volumetric attacks. DHD provides a flexible and integrated platform to combat L3-7 DDoS attacks; from volumetric (L3/4) attacks to sophisticated application (L7) attacks that hide within encrypted traffic. In this video, John outlines many of the exciting features offered in the F5 DDoS Hybrid Defender. Related Resources: F5 DDoS Hybrid Defender F5 Silverline DDoS Protection Services The Hunt for IoT: The Growth and Evolution of Thingbots Ensures ChaosSilverline WAF Architecture
In a previous article, Jason Rahm did a great job of outlining why you need F5’s Silverline services. The threat is global, and it’s time to reposition your defenses to meet the enemy where they are. Many companies can’t afford the cost of hiring a specialized team of security experts to protect their very important business applications…but neither can they afford to let those applications fall prey to an attack. We see attacks at all networking layers today, so it’s vitally important to have proper network defenses deployed at each layer. A Web Application Firewall (WAF) is a critical part of this network defense because it can uniquely defend against attacks that other devices can’t. F5 Silverline WAF is a cloud-based service built on the BIG-IP Application Security Manager (ASM) with 24x7x365 support from highly specialized security experts to help organizations protect web applications and data, and enable compliance with industry security standards (i.e. PCI DSS). With companies moving applications to the cloud, it becomes extremely important to have a cloud-based service like Silverline to handle your WAF functionality. F5 Silverline WAF protects web applications no matter where they reside with consistent policies and compliance across hybrid environments. The diagram below shows an architecture view of where the F5 Silverline WAF could be deployed to protect your cloud-based applications. You’ll notice from the diagram that the Silverline WAF allows for easy integration with VA/DAST Scanning tools and it also easily integrates with BIG-IP ASM to provide hybrid WAF services while providing access to F5’s wide array of robust APIs. One of the great benefits of F5 Silverline is that is gives you access to the F5 Security Operations Center (SOC). The SOC is a state-of-the-art security center with all the latest and greatest network defense tools you can imagine. But more than having a bunch of really cool and expensive tools, the SOC’s greatest asset is the team of F5 security experts who proactively monitor and fine-tune policies to protect web applications and data from new and emerging threats. Remember how you didn’t have the resources to staff a fully-functional network security team? Well, now you do…it’s called the F5 SOC! Our SOC experts will help you with things like security policy setup, policy fine-tuning, proactive alert monitoring, false positives tuning, detection tuning, and Whitelist / Blacklist setup and monitoring. Another great benefit of F5’s Silverline services is the F5 customer portal. This online portal allows you to securely communicate with Silverline SOC experts and view centralized attack and threat monitoring reports. The portal allows you to view and take action on things like violation logs/stats, policy audits, policy stats, attack types, WAF policies, and L7 profiles. It also allow you access to F5’s very powerful iRule editor where you can gain programmability control over your security policies and web applications. The portal also allows you to manage your SSL Certificates. The pictures below shows screenshots of the WAF portal where you can see attack types over time as well as by geolocation. Attack Type Over Time Violations By Geolocation F5’s Silverline services also include DDoS attack protection as well as an additional threat intelligence service. Silverline is a very powerful and robust option for protecting web applications in the cloud. Remember, meet your enemies where they are…and they are definitely in the cloud!Real Attack Stories: Online Payment Center DDoS
A multi-vector DDoS attack was launched against the F5 Silverline service.This included a 400 Gbps UDP Flood and then a 100Gbps TCP SYN Flood .The Silverline service automatically detected this attack and deployed mitigation actions before our Security Operations Center (SOC) analysts even noticed that the attack was happening.The Silverline service remained operational through the entire attack, and no Silverline customers were affected.The same botnet also attacked one of our online payment application customers, but Silverline detected and mitigated the attack so that the customer was not affected.The attack against our customer was a volumetric TCP ACK attack that peaked at 228 Gbps.Watch the video to learn more about these attacks and how they were mitigated!
