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.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.How to Setup Shape Log Analysis in Fastly
Update 8/3: Shape Log Analysis is now a supported log streaming endpoint on Fastly. Read the full details here. Shape Log Analysis is a non-invasive technique used to analyze HTTP and application logs for a clearer view into attackers that are bypassing current security measures. Oftentimes bad actors, botnets, and drive by attacks will consume system resources and commit fraud against APIs in the form of Credential Stuffing, Scraping, Account Takeover and more. Without the proper defenses in place, these attacks are a pain to stop for most security teams who are forced to play “whack-a-mole" with solutions that are not built to permanently defeat fraudulent and automated attacks. Shape Security has a unique corpus of data from attacks that have been identified and blocked over the years for the world's largest banks, airlines, hotels and many other types of infrastructure exposed to the public internet. This anonymized attack data is used to examine application logs revealing automation and fraud that is bypassing perimeter security mechanisms and making its way to your origin servers. Through analyzing data points in Layer 7 traffic, Shape will create a threat assessment on old and new campaigns that are currently attacking specific parts of your applications. Log Analysis Example - Figure 1 The visualization shown in Figure 1 represents all malicious and fraudulent traffic against a specific application. The green pattern hidden in the back is the normal diurnal flow of legitimate user traffic. All other colors are automated attacks driving abuse of APIs and important parts of the application. This type of reporting can be used to not only understand types of attacks and abuse but can also be used to create a plan for integrating a mitigation solution. Types of attacks that will be uncovered: Credential Stuffing Account Takeover Scraping API Abuse System Resource Consumption Getting Started Shape Log Analysis is a free service that is now integrated with Fastly CDN. To avoid complications of compressing, securing and manually sending log data to Shape, we now have the ability to securely send logs to Shape through Fastly's real time log streaming configuration. This is a simple “flip of the switch” configuration, doesn't involve sending any PII data to Shape, and gives organizations the visibility required to take action and prevent these types of attacks. To configure Fastly CDN for Shape Log Analysis, follow these steps: 1)Request a secure S3 Bucket from Shape (send an email to fastly@f5.com with title "Fastly Log Streaming Setup") Once Shape has setup your designated S3 bucket, you will receive an email with a private access key that will be required to complete the configuration in the next step.Keep in mind that Shape uses network and security access controls between Fastly and AWS to ensure data is kept private and confidential. If there are any concerns around how log data is kept safe and secure, please ask in the setup request email. 2) Follow Fastly’s well written instructions on creating a new log endpoint and copy in the Shape specific configuration from below. Log format for Shape Log Analysis (Non-PII data) { "timestamp": "%{begin:%Y-%m-%dT%H:%M:%S%z}t", "ts": "%{time.start.sec}V", "id.orig_h": "%h", "status_code": "%>s", "method": "%m", "host": "%{Host}i", "uri": "%U%q", "accept_encoding": "%{Accept-Encoding}i", "request_body_len": "%{req.body_bytes_read}V", "response_body_len": "%{resp.body_bytes_written}V", "location": "%{Location}i", "x_forwarded_for": "%{X-Forwarded-For}i", "user_agent": "%{User-Agent}i", "referer": "%{Referer}i", "accept": "%{Accept}i", "accept_language": "%{Accept-Language}i", "content_type": "%{Content-Type}o", "geo_city": "%{client.geo.city}V", "geo_country_code": "%{client.geo.country_code}V", "is_tls": %{if(req.is_ssl, "true", "false")}V, "tls_version": "%{tls.client.protocol}V", "tls_cipher_request": "%{tls.client.cipher}V", "tls_cipher_req_hash": "%{tls.client.ciphers_sha}V", "tls_extension_identifiers_hash": "%{tls.client.tlsexts_sha}V" } S3 Bucket Details When you receive the S3 Bucket confirmation from the fastly@f5.com email address, it will contain the following 5 items that you'll need to insert into your Fastly configuration. 1.) Bucket Name 2.) Access Key 3.) Secret Key 4.) Path 5.) Domain Click on "Advanced options" and add the following: After completing the setup, your configuration summary for Shape Log Analysis will look like the following: Once the Fastly logging configuration is complete, logs will be sent to Shape's secure S3 bucket for analysis. Typically we collect around two weeks worth of log data to provide a comprehensive analysis of attack traffic. Additionally, an F5 or Shape representative will be available to provide support during the logging setup and a Threat Assessment Report will be provided as part of the service. Additional Information on Shape and FastlyHow Malware Evades Detection
Malware loves encryption since it can sneak around undetected. F5Labs 2018 Phishing & Fraud Report explains how malware tricks users and evades detection. With the cloning of legitimate emails from well-known companies, the quality of phishing emails is improving and fooling more unsuspecting victims. Attackers disguise the malware installed during phishing attacks from traditional traffic inspection devices by phoning home to encrypted sites. Let's light up how evasion happens & get your F5 Labs 2018 Phishing & Fraud Report today. psLock Down Your Login
Last week we talked about WebSafe and how it can help protect against phishing attacks with a little piece of code. This is important since malware can steal credentials from every visited web application from an infected machine. This time we’re going to look at how to protect against credential grabbing on a BIG-IP APM login page with WebSafe encryption layer. You’ll need two modules for this, BIG-IP APM and of course, WebSafe Fraud Protection Service. The goal is to protect the laptop from any malware that grabs sensitive login credentials. In this case, the malware would be configured to grab the login page along with the username and password parameter fields. Command and control could also be set to retrieve any credentials from the infected machine at certain intervals, like every 5 minutes. The first goal would be to encrypt the password. Within your BIG-IP admin GUI, you would navigate to Security>Fraud Protection Service> Anti-Fraud Profiles>URL List. APM’s logon page usually ends with ‘/my.policy’. Create then click that URL to open the configuration page and enable Application Layer Encryption. And select the Parameters tab to configure the fields you want to protect. In this case it is password and username. In the screen grab, you can see ‘Obfuscate’ is selected and to both ‘Encrypt’ and ‘Substitute Value’ for the password field. Now when the user goes to the page, a bit a JavaScript is injected in the page to protect the specified fields. If you run a httpwatch or wire shark on the page, you’ll see that the values for those parameters are obfuscated. This makes it incredibly difficult for the bad actor to determine the correct value. And if the malware also grabs the password, since we set that to encrypt, all they get is useless information. At this point, the BIG-IP will decrypt the password and pass on the traffic to appropriate domain controller for verification. This is a great way to protect your login credentials with BIG-IP. If you’d like to see a demonstration of this, check out F5’s Security Specialist Matthieu Dierick’s demo video. Pretty cool. psIdentity Theft: Not So Scary Anymore?
This article originally appeared on F5.com on 10.20.15. With Halloween in our rearview mirror and the holiday shopping season upon us, a couple surveys are out examining our fears and in particular, our concerns about identity theft. Apparently, ID theft is not so scary anymore - like entering a haunted house for the hair-raising screams but walking out with nervous giggles. Over at Bankrate.com, only 54% of surveyed tricksters says they are somewhat or very frightened of ID theft. That's down 80% from those who expressed the same level of concern back in 2008. Almost half, 43%, claim they have little or no fear, trouncing the 19% who were brave in 2008. This is all while the overall victim count remains at similar levels - 12.5 million in 2008 verses 12.7 million in 2014 according to Javelin Strategy & Research. As far as knowing someone who has been hit, 46% say they or a friend has been a victim compared to 34% in 2008. They chalk it up to people being desensitized to breaches due to the almost weekly confessions of data intrusions. The general feeling is that if large retailers, health care providers and credit agencies can't keep my data safe, how can I. More of those same folks however are also following some good advice of shredding sensitive documents (72%), checking their credit report regularly (56%), avoiding insecure WiFi (54%) and almost 20% have frozen their credit files. These are all good ways to help you worry less. And Chapman University published their Survey of American Fears, Wave 2 (2015) examining the fears of average Americans. The domains of fear include areas like crime, natural and man made disasters, personal anxieties, environment, technology and others. Along with the corruption, terrorism and warfare, identity theft comes in at 39.6% and credit card fraud sits at 36.9%. Both in the Top 10. So, while ID theft is still one of our top fears, by the time you get to Nightmare on Identity Street 4, Freddy isn't so freighting and you have some tools to deal with him. Besides, your insecure connected kettles could be exposing your WiFi passwords without your knowledge. Now that's scary! ps Related Survey: More Americans say 'boo' to the ID theft boogeyman America’s Top Fears 2015 Connected kettles boil over, spill Wi-Fi passwords over London The Breach of Things The Reach of a Breach 5 Stages of a Data Breach Technorati Tags: identity theft,breach,privacy,crime,fears,silva,fraud Connect with Peter: Connect with F5:
Dyre presents server-side web injects
Dyre is a relatively new banking Trojan, first seen in the beginning of 2014. It soon emerged as one of the most sophisticated banking and commercial malware in the wild. One of the main capabilities Dyre has presented, which differentiated it from the other well-known banking Trojans, was the “fake bank page” functionality. Once the victim tries to reach the real bank, Dyre intercepts the request and fetches its own fake page from one of its C&C servers. However, while researching the Trojans’ internals we noticed another stage in the fraud techniques evolution. “Traditional” fraud malware performs malicious JavaScript injection on the client machine while taking it from a configuration previously downloaded from the C&C server. However, Dyre maintains the injections on its C&C servers. This gives Dyre the flexibility to adjust the injected code on demand and minimize exposure of the existing web-injects. During our research we noticed two types of injections which lead to two different scenarios. In the first scenario, the web-injects (malicious JavaScript) stole just the login credentials, while in the second scenario it would also contain an embedded HTML page which targets credit card information as well. Other than just targeting financial online applications, using the “Grabber” module, Dyre enables its operators to steal virtually any user-supplied sensitive information online in large amounts. This information includes credentials for email applications, social platforms, hosting infrastructure, and corporate SSL-VPNs. While this information may be resold in the “underground”, the bigger risk is that malware operators might hijack email and social network accounts to perform surveillance, or blackmail individuals or organizations. They could also hijack hosting infrastructure to further deploy other malicious code, or break into organizations using stolen VPN credentials. Many have written about this new threat. However, few have succeeded in covering the entire fraud flow and most of its capabilities. For more details on the Trojan’s internals, read the report: https://devcentral.f5.com/s/d/dyre-malware-internals?download=true
