Babak Amin Azad

Oleksii Starov

Pierre Laperdrix

Nick Nikiforakis

Web Runner 2049: Evaluating Third-Party Anti-bot Services

Given the ever-increasing number of malicious bots scouring the web, many websites are turning to specialized services that advertise their ability to detect bots and block them. In this paper, we investigate the design and implementation details of commercial anti-bot services in an effort to understand how they operate and whether they can effectively identify and block malicious bots in practice. We analyze the JavaScript code which their clients need to include in their websites and perform a set of gray box and black box analyses of their proprietary back-end logic, by simulating bots utilizing well-known automation tools and popular browsers. On the positive side, our results show that by relying on browser fingerprinting, more than 75% of protected websites in our dataset, successfully defend against attacks by basic bots built with Python scripts or PhantomJS. At the same time, by using less popular browsers in terms of automation (e.g., Safari on Mac and Chrome on Android) attackers can successfully bypass the protection of up to 82% of protected websites. Our findings show that the majority of protected websites are prone to bot attacks and the existing anti-bot solutions cannot substantially limit the ability of determined attackers. We have responsibly disclosed our findings with the anti-bot service providers.

Introduction

The modern web is home to benign and useful bots, such as, search engine crawlers that provide easy access to information around the web. Yet the same technology that enables benign bots is also utilized by malicious bots which disrupt services, steal business and customer information, and make illicit profits for their operators. Malicious bots are used to automatically find and exploit vulnerabilities on websites (such as outdated and vulnerable Content Management Systems) [START_REF] Canali | Behind the Scenes of Online Attacks: an Analysis of Exploitation Behaviors on the Web[END_REF], scrape email addresses and content for sending spam and creating phishing websites, registering thousands of accounts and selling them via underground markets (e.g. for fake followers on social networks [START_REF] Thomas | Trafficking fraudulent accounts: The role of the underground market in twitter spam and abuse[END_REF]) and brute forcing login forms with credentials stolen from other websites (known as credential stuffing). Some of the recent bot attacks include, ride-sharing companies scraping pricing and vehicle information from their competitors websites [START_REF]Uber's Massive Scraping Program Collected Data About Competitors Around The World[END_REF]. Similarly, the bots targeted the airline industry, causing an increase in the look-to-book ratio which leads to increased fees [START_REF]How Bots Are Disrupting Airline Ticket Sales[END_REF].

According to recent estimates, more than 50% of traffic on the web belongs to bots with more than half of that belonging to malicious ones [START_REF][END_REF]. In this environment, specialized anti-bot services have emerged which offer bot detection and bot blocking as a service to their clients. Even though these services claim to utilize an impressive array of technologies, their operation and effectiveness in detecting and blocking bots have not been evaluated.

In this paper, we report on the first analysis of 15 popular anti-bot services. We identify the JavaScript code which their clients deploy on their websites and perform a white box analysis of its operation. We observe heavy reliance on browser fingerprinting including recent fingerprinting techniques that fingerprint a system's graphics card, local IP address, and even whether the browser attempts to lie about its identity. To understand whether this extracted information is sufficient to detect and block abusive bots, we utilize six different existing automation tools, ranging from off-the-shelf crawlers, to automated browsers. Through the use of carefully designed experiments, we evaluate the ability of the most popular anti-bot services to stop attacks, such as, content scraping, credential brute forcing, and account hijacking.

Among others, we find that few services are capable of significantly slowing down attackers and that certain unusual crawling tools, such as, an AppleScript-controlled Safari Browser and an ADB-controlled Android smartphone can successfully crawl large numbers of webpages and conduct account attacks. More specifically, at least 68% of our simulated scraping requests were not blocked, and more than 90% of our account takeover attempts were successful with at least one of the tested tools. In addition, for more than half of our target websites, there is at least one tool that enables us to do 1,000 password brute force attempts without getting blocked.

Contrary to our expectations, we discover that having a bot reach websites from a public cloud does not significantly decrease its performance since existing services put more emphasis on browser fingerprints rather than source IP address.

Background

Since malicious bots can lie about their identity, prior research has proposed a number of methods for bot detection, including behavior-based detection (based on the premise that bots browse websites differently than real users [START_REF] Jacob | Pubcrawl: Protecting users and businesses from crawlers[END_REF][START_REF] Lourenc ¸o | Catching web crawlers in the act[END_REF]), detection based on accessing content that is invisible for regular users [START_REF] Park | Securing web service by automatic robot detection[END_REF][START_REF] Xie | Scanner hunter: Understanding http scanning traffic[END_REF] and more recently, based on browser fingerprinting [START_REF] Bursztein | Picasso: Lightweight device class fingerprinting for web clients[END_REF]. Once a visitor is suspected to be a bot, the website can request the solving of CAPTCHAs, rate-limit the user, or altogether block traffic from the offending IP address.

Even though web developers may try to implement the aforementioned techniques, it is unlikely that the developers of small websites can keep up with the adaptation from the side of the bot authors. In order to keep up with attackers, new businesses have emerged that sell bot-detection services to their clients, similar to anti-DDoS companies which protect their clients against DDoS attacks. Website owners can then integrate these services with their website to block bots without needing to know how a bot was identified. One major benefit of using such services compared to a custom implementation of an anti-bot mechanism, is the threat-information sharing that happens in the background. If bot activity with certain characteristics is detected on website A, website B that is also a client of the same anti-bot service, can get information about this bot and block it immediately at its first interaction.

Anti-bot companies advertise a range of bot-related attacks which they can detect and stop. By analyzing the descriptions of their services, we summarize the attack scenarios performed by malicious bots into the three following categories (these attacks are discussed in more detail in Section 5):

-Account Takeover, also known as credential stuffing, refers to automated login attempts with stolen or leaked credentials to target websites. In this case, attackers may take advantage of users reusing credentials across services and leaked password databases found in underground markets. -Credential Brute Force is another type of account takeover attack. In this scenario, the attacker uses a list of popular passwords against user accounts to break into them. -Content Scraping is an automated attempt to steal proprietary website information, such as product price lists and inventory, to gain a business advantage. The general structure for anti-bot services is depicted in Figure 1. We arrived at this architecture by studying the design of multiple anti-bot services and abstracting away servicespecific details. When users visit a website protected by an anti-bot service, fingerprinting scripts gather information from their browser and send it directly to the anti-bot service's backend. Information about how users interact with the website and actions taken, such as, login attempts and viewed pages, are also transmitted to the anti-bot service by the webserver using server-side APIs. Plugins are typically provided for popular content management systems (such as WordPress and Drupal) and integration is also available at the website and webserver layers using provided SDKs. In this architecture, every visitor of the website has a unique identifier which is later used by the webserver to query the anti-bot service and receive a risk score. Depending on the configuration of the website, different thresholds on the risk score can trigger different events, such as, showing a CAPTCHA, limiting the number of requests of suspicious users, or altogether blocking them.

A key component of each service is their fingerprinting scripts, which attempt to collect as many signals as possible for distinguishing between human and bot-like behavior. Browser fingerprinting has evolved substantially in the past few years from querying simple JavaScript APIs [START_REF] Eckersley | How Unique is Your Web Browser?[END_REF] to the rendering of complex 3D scenes with WebGL [START_REF] Cao | Cross-)Browser Fingerprinting via OS and Hardware Level Features[END_REF]. By collecting a range of information about the browser, the operating system and the hardware of a device, anti-bot services can obtain a precise view of the overall browsing system which can be used for detecting bots [START_REF] Bursztein | Picasso: Lightweight device class fingerprinting for web clients[END_REF]. Next, such services usually claim to have sophisticated machine learning models on their back-end servers, which are trained to identify bot-related fingerprints on large volumes of data that they observe across their clients. In order to get a complete view of these services, both the coverage of fingerprinting features, as well as the accuracy of their back-end models have to be measured to quantify their effectiveness. Hence, in this study, we perform an analysis of their deployed fingerprinting scripts (Section 3), as well as gray box and black box testing of anti-bot back-end models (Section 5). Our experiments allow us to not only capture the effectiveness of each anti-bot service in detecting bots, but to also measure how well websites interpret and act upon the risk score reported by each anti-bot service.

Analysis of anti-bot services

For our analysis, using popular search engines, we searched for phrases such as, "bot detection" and "bot prevention", and compiled a list of 15 popular services in September 2017. Table 1 lists the discovered services ranked according to their number of clients. The process of identifying client websites is described in Section 5.

Overall, we see that almost half of the anti-bot services have thousands of client websites with Cloudflare being the most popular service having 13.65% of its clients from the Alexa's top 1 million websites. The number of clients for Cloudflare in Table 1 represents the total number of websites observed using Cloudflare. The numbers are based on "BuiltWith" website statistics, which provides reports on web technologies [10]. Since all other services specialize only in bot protection, we already know that clients that use these services want to defend against bots. Whereas for Cloudflare, there can be various reasons to use their service such as DDOS protection, CDNs, or for adding HTTPS support to a website. Therefore, only a subset of these websites might configure Cloudflare's firewall to block bots.

Services in Table 1 marked with (G) indicate those for which we could acquire an account (trial or paid) without having to talk to a sales representative. For these services, we were able to conduct gray box testing, in addition to the black box testing for all services. Among the services we study, we can distinguish the following two main types:

-Universal solutions against bot attacks usually collect fingerprints and user-behavior data from clients using JavaScript and other common browser fingerprinting methods. They also collect information from the web server including the specific actions taken by users, such as, the browsing of a specific page, or the submission of a form.

-Specific services against account fraud that focus on the defense against account takeover and credential stuffing attacks. These services make use of both bot detection and anomalous account activity to identify attacks.

All of the anti-bot services listed in Table 1, except Cloudflare, use fingerprinting scripts on their clients' websites to assist them in bot detection. We collected client-side fingerprinting scripts from the 14 anti-bot services that use this technique. Next to beautifying and statically analyzing the JavaScript code, we dynamically executed the scripts in order to inspect the sent payloads and detect what fingerprinting-related APIs they utilize. For that, we used a custom browser extension (following the approach of Lerner et al. [START_REF] Lerner | Internet jones and the raiders of the lost trackers: An archaeological study of web tracking from 1996 to[END_REF]) that can intercept browser API calls on a page.

Fingerprinting and automation detection mechanisms

First, we observed that most services use standard fingerprinting features, such as, screen properties, available fonts, plugins and MIME types. We observed similar features being collected to those reported by Vastel et al. [START_REF] Vastel | FP-Crawlers: Studying the Resilience of Browser Fingerprinting to Block Crawlers[END_REF]. The particular techniques in extracting these features differ, e.g. some services directly enumerate the navigator.plugins object, some simply use the PluginDetect library [START_REF] Plugindetect | [END_REF], and others have further custom checks. In comparison, we witness that few services incorporate more recent fingerprinting techniques, such as, Canvas or WebGL fingerprinting that can provide a more accurate view of the system's hardware.

Another finding, supporting the fact that anti-bot scripts attempt to capture obvious signs of web automation, is the variety of checks to detect PhantomJS, Nightmare [START_REF] Nightmare | [END_REF], Selenium, and headless Chrome browsers. Different services use different techniques, such as, printing a stack trace and searching for the "selenium" keyword or probing for the existence of known variables (e.g., window.callPhantom). By deploying these checks against our own Selenium installations, we discovered that most of the deployed checks do not work for recent Selenium versions (except the navigator.webdriver property which is still present on the Selenium ChromeDriver).

Even though not all services use state-of-the-art fingerprinting techniques, those that do also try to detect inconsistencies in the collected browser fingerprints. For example, the useragent sent by Selenium can be modified to look like a Firefox browser on Android, or Safari on iOS. The problem is that these modifications can lead to inconsistencies where modified and unmodified attributes cannot possibly belong to the same browsing environment. Three services make use of client-side code to detect such cases of mismatch between attributes.

Table 2: Known fingerprinting libraries

Source library # Services Source library # Services Source library # Services

Fingerprintjs2 [4] 4 PluginDetect [7] 3 fonts2.swf [1] 1 FontList.swf [4] 3 Evercookies [3] 1 Modernizr [5] 1
As Table 2 shows, a significant number of anti-bot services rely on existing fingerprinting libraries, such as, the popular Fingerprintjs2 [START_REF][END_REF]. We also observed services that use other advanced fingerprinting features, including the detection of the local IP address through WebRTC and Flash, as well as the recording of user actions, i.e., mouse moves and clicks. Some collect and send this data only once, whereas others periodically collect and report this information. Finally, we discovered a number of cases where more novel fingerprinting techniques were used, like the recently deprecated Battery status API [38] (Castle), AudioContext fingerprinting (PerimeterX), and even DOM changes to a supplied HTML page with different input fields (ThreatMetrix) which can be used to detect browser extensions [START_REF] Starov | XHOUND: Quantifying the Fingerprintability of Browser Extensions[END_REF]. This demonstrates that a small number of anti-bot services are closely following browser-fingerprinting research, and incorporate this research in their products.

A service which includes anti-bot functionality but differs from the rest is Cloudflare [START_REF] Cloudflare | The web performance & security company[END_REF]. Unlike the evaluated third-party anti-bot services, Cloudflare itself is responsible for all resolutions of their clients' domains. As a result, Cloudflare can detect and block traffic at their servers, without any input from their clients. After analyzing the requests, we observed that Cloudflare does not perform any type of client-side fingerprinting using JavaScript or Flash. Cloudflare mostly relies on IP reputation (historical malicious activity), firewall rules based on HTTP requests, and rate limiting to prevent automated and malicious behavior.

Anti-bot service integration with websites

As depicted in Fig. 1, anti-bot services communicate the decision (often in the form of a risk score) to their clients upon each request. In this section we present our observations on how risk scores or decisions are communicated to clients and how the websites react to these reports.

Communicating the raw risk score. Services like Cloudflare, directly communicate the score to their clients and let them decide which thresholds to choose when blocking bots (e.g., show a CAPTCHA when risk score is greater than 50).

Communicating the final verdict. Services like Castle interpret the risk score internally and communicate the final verdict (Allow, Challenge, or Block) to the client websites through their API. Website administrators can then decide to show a CAPTCHA or notify the user via third-party channels.

Handling everything in the background.

These services analyze the collected fingerprints and events, redirecting users to CAPTCHAs or block pages. As a result, the whole process of decision making happens in the background and website administrators have no control over it. Occasionally, there are no tunable parameters exposed to administrators which means that false positives have to be communicated and remediated through customer-support channels.

Finally, next to communicating the risk score and decision making, how websites react to bots is also defined by the anti-bot service. Some services have the ability to be deployed inline with the web traffic (e.g., Distil Bot Defense and Cloudflare). In this scenario they can straightforwardly redirect malicious users to CAPTCHAs and block pages. Similarly, the integrated SDK can communicate with the anti-bot service and redirect the detected threats to specific block pages. Lastly, the reaction may be left up to the website developers. In the example of Castle, website developers can decide to block the request or notify the users about the breach.

Available tools for building bots

In this section, we introduce the tools that we utilized to evaluate whether the anti-bot services are capable of detecting attackers of different levels of expertise (reflected in the complexity of their tools). We categorize the tools that are available for attackers in three groups, covering multiple levels of complexity:

-Basic bots: The least sophisticated approach is based on general-purpose automation tools (e.g., Python Requests and PhantomJS). Python Requests scripts are capable of sending GET and POST requests but do not execute JavaScript (these are conceptually similar to utilizing command-line tools, such as, wget and curl). This is the most basic approach that we expect to be detected by anti-bot services. We also include Phan-tomJS in this category, which was the first easy-to-script, headless, JavaScript-supporting browser [START_REF]PhantomJS -Scriptable Headless Browser[END_REF] and therefore attracted a great deal of abuse [START_REF] Shekyan | Detecting PhantomJS Based Visitors[END_REF]. -Automated Browsers: The second and more sophisticated category involves using real browsers (e.g., Firefox and Chrome) automated by Selenium. These bots can often be augmented with user-action simulation, such as, mouse moves, floating delays, and page scroll. -Less Popular fingerprints: Anti-bot companies claim to share threat information between their clients. As a result, common tools used to create bots can be detected more effectively. Contrastingly, attackers can incorporate less popular tools to potentially bypass bot detection mechanisms, due to their limited history of malicious activity. To model this approach, we use AppleScript-automated Safari and ADB-automated Chrome on Android.

Experimental Setup

To analyze the effectiveness of anti-bot services in terms of preventing bot activity, we utilize a number of real-world attack scenarios. In this section, we describe the categories of our tests, and how we utilize tools from different bot categories presented in Section 4. We implement a large number of web automation scripts that can interact with websites at different levels of complexity. Each test is comprised of attack and tool combination and is executed from hosts with IP addresses belonging to our campus and a public cloud. These addresses are picked from a pool of 30 campus IP addresses and 30 cloud IP addresses distributed across 8 geographical regions.

Gray Box Experiments

For the companies that we could obtain paid or trial accounts, we integrate their SDK with our testing website (a WordPress-based, web application). Under the gray box scenario, we run our tests in a fully controlled environment where we control both the bots as well as the website receiving the bot traffic. By monitoring the administration panel provided by the antibot service, we have access to the final decisions to allow or block the traffic. Nevertheless, the machine learning models and decision boundaries used to classify the incoming traffic is still a black box. As such, we call these set of tests, gray box.

1. Test Preparation Initially, for each "attack category," and "web automation tool," we create scripts to mount the attacks and measure their success. Our tests cover the following categories:

-Account Takeover: In this setup, we create an account on websites utilizing anti-bot services (either our own for gray box testing or third-party websites for black-box testing) from a fixed geographical location, IP address, and browser. We then attempt to automatically login to this account from different geographical locations and IP addresses using our bots. This discrepancy in login location, browser fingerprint, and use of automation tools should, in principle, trigger the account-takeover protection system to prevent the "malicious" login activity or alert the user. -Credential Brute Force: To implement this scenario, we use our web automation tools and try to login with 1,000 invalid credentials. We then measure the number of requests before getting blocked. According to prior work [START_REF] Kelley | Guess again (and again and again): Measuring password strength by simulating password-cracking algorithms[END_REF][START_REF] Melicher | Fast, lean, and accurate: Modeling password guessability using neural networks[END_REF], at least 4% of passwords created under different password policy schemes can be found in under 1,000 guesses. -Content Scraping: By extracting product list and pricing information from 1,000 pages, we evaluate whether the anti-bot service will block our bots.

Test Execution

Each attack script is executed from different IP addresses which we rotate as necessary. The hosts are located on our campus and on Linode (a public cloud provider). The reason for using two different locations is to simulate attackers who have access to premium IP address space that is not associated with crawling activity, versus attackers who can just rent virtual machines on public clouds. We do not perform multiple attacks at the same time to ensure that the detection of one attack does not affect the detection of another.

Post-processing of Results

After each test, we inspect the anti-bot administration panel and look for reports of blocked bots based on the IP address we used for each attack.

Black Box Experiments

Most services require their potential customers to talk to a sales representative, prove their identity as a real business, and go through a series of interactions to acquire and adopt anti-bot services. Since we cannot perform gray box testing for these service, we devised a set of black box experiments. Data Collection After compiling our list of anti-bot services that we wish to evaluate, we crawl the web and find websites that adopt these services. Starting with a list of known clients for each anti-bot service (e.g., list of clients on the website of anti-bot services), we analyze their websites to identify unique content, such as, JavaScript files or DOM elements that can be used as a signature to detect more clients of each service. The resulting signatures are then queried in the PublicWWW [START_REF]Publicwww: Search engine for source code[END_REF] and NerdyData [START_REF]Nerdydata: Search engine for source code[END_REF] code-search engines and the results are supplemented with our own crawls of the Alexa top 1 million websites.

Given the number of tests we wish to conduct and that we need website-specific scripts that can fill forms and navigate each website, it is not feasible to evaluate all clients of each service. As such, we decided to focus on a subset of their clients by randomly selecting ten clients for each anti-bot service. We ensure that the selected websites do not exhibit any client-side signs (e.g. JavaScript libraries) that would suggest that they are utilizing any anti-bot service, other than the evaluated ones. We also removed websites which, through experimentation, showed signs of additional, server-side software blocking our requests. This is not a challenge since block pages used by anti-bot services are distinctive (Figure 2) and HTML tags, URLs, and variable names within the page source point to the anti-bot company.

Test Preparation

We target the same attack categories that we discussed in gray box tests. Since we do not have access to the administration panel this time, we devised heuristics to detect being blocked based on the received response.

-Account Takeover and Credential Brute Force: We use the same type of scripts that we used in gray box tests. Note that in both experiments we create an account on the target website and only target our own user account during the experiments, for ethical purposes. -Content Scraping: In this attack scenario, we inspect the websites of clients of anti-bot services, and identify content that is a likely target for scraping by malicious crawlers (such as pricing of products and inventory details). We then implement the necessary automation scripts for each website, attempting to scrape 1,000 pages worth of content.

We spent a total of 5 man-months developing automation scripts for all tested websites which could appropriately navigate each website according to our desired tests. Another obstacle that we had to overcome is that, due to the churn of clients of the anti-bot services, we had to often repeat experiments with new randomly sampled websites, as some websites stopped being clients of the services before we were able to finish our experiments.

Test Execution

Using the same infrastructure, we run our experiments against selected clients of each service. To generalize our results, in addition to Linode, we ran a set of pilot tests from AWS and did not observe significant differences in the results (5% over 60 tests) showing that the choice between popular and less popular cloud providers does not have significant impact on the final results.

Post-processing of Results

After each test, we inspect our logs and screenshots to locate the number of successful attempts each bot made before getting blocked and to make sure any observed blocking is the outcome of fingerprint-related and behavior-related information that these services gather from our bots and correlate with server-side events.

The extracted information consisting of fingerprint, headers and user actions are used by each anti-bot service to come up with a verdict for each user ID, which their client will use to decide whether they should block the current request. Section 6 discusses the results from this step in more detail. In all cases where we received unexpected responses, we manually inspected them to verify that our scripts were indeed blocked. We define "success" and "failure" as follows:

-Successful content scraping is defined as our bot loading the content for 1,000 pages on protected websites containing information that would be worth scraping for attackers. -Successful account takeover is defined as our bot being able to login to a target user account from a different location and fingerprint from the actual user's fingerprint used to register and login to the account. The test is considered to have failed when the tool fails to login with explicit (e.g. "You are blocked") or implicit (e.g. "Incorrect credentials") responses.

-Successful brute forcing in our experiment is defined as a bot sending 1,000 login attempts with incorrect credentials and then being able to login with correct credentials. We designed this test in a way that simulates an attacker attempting a large number of incorrect credentials before finding the correct one.

For credential brute-forcing experiments, we distinguish the following cases as being blocked: being blocked with an explicit message, receiving a CAPTCHA in order to login, target user account being locked (note that this is always our account), being rate-limited for a considerable amount of time or not being able to login with correct credentials after brute forcing. The last case is based on the observation that some anti-bot services silently increase the risk score when the noisy brute force behavior is observed, and as a result, prevent the bot from logging in even with correct credentials.

Ethical Considerations

To understand how real anti-bot services detect malicious bots on their client websites, we cannot avoid sending bot-like traffic to public websites. To conduct these experiments in an ethical fashion we took special care when designing them and conducting them. For content scraping, we access content that is considered public, i.e., it is not behind a registration wall. For account takeovers, we only try to log in to our own account on all websites from a location/fingerprint that is different from the one that we utilized to register that account. Lastly, for account brute forcing, we only make login attempts against our own accounts, never trying to log in into the accounts of other users. We provide ample time between requests (in the order of seconds) allowing our requests to be interleaved with regular traffic received by the evaluated popular websites. Our bots behave as humans and therefore never send any maliciously-crafted input to target web applications.

As a result, we are confident that our experiments did not have any negative consequences, neither for the protected websites, nor for the anti-bot services themselves.

Analysis of Results

In this section, we describe the results of our bot experiments on our test websites (gray box testing) and on client websites of popular anti-bot services (black box testing). By combining data across both types of experiments, we uncover shortcomings and flaws of these services. Our focus in this section is on the common patterns across the services that will provide an opportunity for the attackers to bypass their protection. As our study is not meant to promote one product over another, we opt to anonymize the names of the anti-bot services.

Gray Box Testing Results

From the list of anti-bot services that we initially started with, we were able to obtain accounts from four services: Service #3, Service #4, Service #2 (providing generic anti-bot protection) and Service #1 (providing specialized protection against account fraud). For the first two services, installing their WordPress plugins and including the JavaScript file in all of our pages was sufficient to adopt them. After each client request reaches the webserver, these plugins collect the request context including HTTP headers, cookies and IP addresses and report it back to the anti-bot service through their APIs. Conversely, Service #2 protection is enabled by routing website traffic through their servers by changing DNS records. In the case of Service #1, while the JavaScript code sends back information on each page load, we needed to manually call their API upon authentication and report the event. Upon successful authentication, we then have to query their API to receive a verdict (Allow, Challenge, and Block) that defines what action the service recommends. The reaction to these verdicts is also the website developers' responsibility and can vary for each client website (e.g., showing CAPTCHA, or requesting a second factor of authentication).

Gray Box Content Scraping Results

The number of successful content-scraping attempts against the three services which protect against it (Service #3, Service #4, and Service #2) is listed in Table 3. For Service #2, none of our scraping bots was ever blocked, regardless of their location (i.e. Campus vs. Cloud). While further fine-tuning the rate limits might be helpful to block more aggressive bots, as long as bots keep their request number low, they can hide within normal user traffic and remain undetected.

Our results show that Service #3 clearly makes a distinction in its decisions to block bots based on their source IP address. Requests from bots originating from campus IP addresses were strictly more successful, compared to those of Linode datacenters. For Service #4, this observation does not always hold true. While Firefox Stripping (i.e. with fingerprinting script blocked) got worse results when originating from Linode, AppleScript and Mobile scrapers remained undetected. This suggests that Service #3 places more weight on the source IP address in their decision-making model, compared to Service #4. Service #3 trusts IP addresses to the extent that attackers with access to prime IP addresses from outside datacenters (Campus address space, in our case) can scrape content even with trivial tools from the "Basic Bots" category. Not executing JavaScript can be helpful: Finally, using Python, our bots were able to successfully log into user accounts both from Campus and Linode IP addresses with a high degree of success. Service #1 was the only exception which returned the verdict of "Challenge" only for Python requests from Linode.

For brute force tests (Table 4), similar to account takeover results, Service #3 shows higher sensitivity to source IP addresses and blocks requests from Linode more aggressively whereas Service #4 does not penalize Python and Safari-based bots. For Service #1, this transition from Campus to Cloud was enough to mark all our login attempts as malicious and increase their risk scores, shifting them to their next verdict category: from Allow to Challenge and from Challenge to Block.

Overall Content Scraping Results

In this section, we report on six anti-bot services which were either included in our gray box tests or match our criteria for black box tests, that is: (a) provide overall protection against automated attacks/mention content scraping as a covered use case; (b) have a representative sample of at least 10 client websites. We chose distinct websites that use only the corresponding service out of the known anti-bot solutions. Each website was tested against eight different automation tools among three bot categories and each test included the scraping of 1,000 pages. Table 5 summarizes our results for content scraping from gray box tests and black box tests. The column named "IP sensitivity" indicates whether using IP addresses from Cloud (Linode) rather than Campus makes the service block our bots earlier. If there is more than 50 % change (i.e., at least half of the websites that did not block us on campus IPs blocked us from cloud IPs), we consider the service to be highly sensitive to cloud IP addresses and if the change is less than 50 %, we say the impact of source IP address is low. Finally if we do not observe a significant difference when moving from Campus to Cloud, we infer that presence/absence of an IP address from a cloud provider, does not have an effect on the blocking decision.

In Tables 5 and6, partial success is marked with half-filled circles indicating that either some tools within that bot category were not blocked (e.g., PhantomJS was blocked but Python was not), or some websites protected by the same service blocked a tool within a category while others did not. Even though we do not have enough information for a definitive answer, we opine that the partial difference in behavior among clients of the same anti-bot company is the result of different characteristics of their normal traffic and the dynamic nature of the machine learning models. Basic bots: Nearly all services with the exception of Service #2 are able to block "basic bots" to some extent. Among them, Service #5 and Service #4 successfully block both Python and PhantomJS consistently on all their clients. Automated browsers: Service #4 always detects and blocks automated browsers. While Firefox automated by Selenium goes undetected by Service #5 and Service #7, Selenium Chrome is blocked quickly (in less than 100 requests). Adding page scrolls and mouse moves to our automated browsers only helped with Service #7 which led to scraping 1,000 pages on some clients and getting blocked after around 60 attempts on other clients where we could previously make less than five successful requests.

Less popular fingerprints: Applescript-Safari and Chrome on Android are able to bypass the limitations imposed by most anti-bot services. The only exception is Service #5 where some of their clients block Applescript-Safari while others block Chrome on Android. Even the websites that block either of these tools, do so after 300-600 attempts. Compared to basic bots and automated browsers which made less than 10 successful attempts on Service #5 clients, this demonstrates that unpopular, JavaScript-enabled clients can be significantly more successful in evading detection.

Stripping: Stripping refers to blocking fingerprinting JavaScript when scraping content from the websites. None of the services allowed our bots to scrape more pages when client side fingerprints were stripped, and most of the time we got blocked earlier (e.g., in less than 5 attempts on Service #5). Since Service #2, Service #3 and Service #6 either do not perform clientside fingerprinting via JavaScript or do not block our automated browsers, we can not compare their performance when automated browsers are used and fingerprinting scripts are blocked. Figure 3 generalizes the performance of different scraping bots across all evaluated services. There we can see that, even though the different traffic patterns of different websites lead to noisy results, there are clear patterns that favor some tools over others. For example, when operating either an Android bot or a Firefox-Selenium one with added mouse moves from "premium" address space, attackers can scrape content from the vast majority of sites and services. For cloud tests, we repeated the experiments for the tools that showed better performance from campus IP addresses.

Overall Account Fraud Results

Here, we present our results for the Account Takeover and Brute Force experiments. We analyzed ten anti-bot services which advertise themselves as general anti-bot or account-fraud protection services and for which we could find at least ten distinct client websites that allowed us to register a new user (a requirement for these experiments). We evaluate these services against five tools by performing a total of 2,800 tests. 4, we observe that because of the absence of a large number of requests to the service during account takeover (attackers have already stolen the credentials and are logging in from a "foreign" environment), most services fail to block the attack. We have already seen that general bot-detection mechanisms fail to block most of the bots right away except basic bots, which also holds true for account takeover attacks. The change in fingerprint and location of the login attempt were not enough to raise an alarm and block the takeover in many of our attempts. As a result, even with the worst-performing bot (i.e. PhantomJS) attackers can successfully conduct an account takeover attack in 40-60% of the time.

PhantomJS Python

Credential Brute Force Results

The results for this section are summarized in Table 6.

Column "Brute Force" in this table refers to the number of websites on which at least one of our bots was able to perform 1,000 brute force attempts against their login forms. This not only shows the lack of defense from anti-bot services but also signifies that neither the website nor the anti-bot service enforce a hard limit on the number of failed attempts (e.g. by account lockout, CAPTCHA or IP address ban). Lu et al. studied the presence of rate limiting mechanisms on top Alexa websites and already pointed out this lack of protection [START_REF] Lu | A measurement study of authentication rate-limiting mechanisms of modern websites[END_REF]. Our results support Lu et al.'s findings by showing that, even among the websites that actively seek to protect against bot attacks, 30-100% of them do not enforce any type of login rate limiting. Among all tested services, Service #5 and Service #7 blocked more categories of bots and enforced rate limits on a wider range of tested clients. For Service #4 and Service #8, almost none of their tested clients enforced rate limiting. Interestingly, simple rate-limiting on POST requests to login pages enforced by Service #2, is sufficient to fully prevent brute force attacks, even without any type of client-side fingerprinting.

Contrary to content-scraping results, different tools from automated browsers and less popular fingerprint categories achieve similar results. However, Safari is still the best performing bot. Orthogonally to the type of bot being used, we observe that most anti-bot services become slightly stricter when the bot is sending authentication requests from Cloud IP addresses. For example, the average number of successful requests by Safari, drops from 564 to 433 after transitioning to cloud. This subtle effect is visible in Figure 5. More importantly, the hourglass-like distributions of Figure 5 show that the majority of bruteforce attempts are either blocked in under 400 attempts (the narrow "neck" of the hourglass) or not blocked at all. With the use of more sophisticated tools (right side of the Figure 5), the number of successful 1,000 bruteforce attempts increases.

When combining account takeover and brute force protection, Service #5, Service #7 and Service #9 block bots across all categories. Yet, specific tools are able to evade detection. On the other end, websites using Service #8 in our dataset did not show any specific pattern of blocking bots (except one website that was enforcing a local rate limit to block brute force attempts).

PhantomJS

Discussion

In this paper, we conducted the first, large-scale study of commercial anti-bot services that websites can use to detect and protect their content and their users against malicious bots. Using basic bots as well as popular and less popular automated browsers, in conjunction with different types of IP address space (public clouds vs. campus networks), we evaluated -in an ethical fashion -the ability of ten services to detect and block bots on the websites of their customers. While each service has its own specific strengths and weaknesses (as described in Section 5 and Section 6), we can still observe common patterns across services. We describe these patterns (and their implications) below:

Variance across clients of the same service. An unexpected finding of our experiments is that not all clients of the same service block bots in the same way. This could suggest that some services are more sensitive to false positives than others, but it could also suggest misconfigurations from the side of clients of anti-bot services. Our recommendation is that anti-bot services regularly perform bot-based crawling of their own clients and observe whether their own attempts are blocked by their clients. In the cases where blocking is under a configurable threshold, these anti-bot services can reach out to their clients and inquire whether the recorded permissiveness is a conscious choice or merely a misconfiguration.

Browser fingerprinting. Virtually all services rely, to a certain extent, on browser fingerprinting as part of their bot-detection logic. Browser fingerprinting is a powerful mechanism that can be used either constructively (for authentication) or destructively (for unwanted online tracking) to re-identify users (including attackers). Yet it is also susceptible to evasions when attackers are aware of it. When it comes to advanced attackers who can mix and match bots, constructively using browser fingerprinting is more likely to work in a whitelisting fashion (i.e. is the current user's browsing environment, similar to their past browsing environment?) rather than in a blacklisting fashion (i.e. is the current user's fingerprint matching that of a previously-observed, malicious bot?).

PhantomJS is universally recognizable. As we showed in our experiments in Section 5, PhantomJS is universally recognizable by anti-bot services and often performs worse than simple bots that do not support JavaScript at all. Even though this is desirable for detecting attackers abusing PhantomJS, academic researchers have also extensively relied on PhantomJS for web-security [START_REF] Nikiforakis | Stranger danger: Exploring the ecosystem of ad-based url shortening services 38[END_REF][START_REF] Srinivasan | Exposing search and advertisement abuse tactics and infrastructure of technical support scammers[END_REF][START_REF] Tajalizadehkhoob | Herding vulnerable cats: a statistical approach to disentangle joint responsibility for web security in shared hosting[END_REF][START_REF] Van Goethem | Clubbing seals: Exploring the ecosystem of third-party security seals[END_REF][START_REF] Vissers | Maneuvering around clouds: Bypassing cloud-based security providers[END_REF] and web-privacy [START_REF] Acar | FPDetective: dusting the web for fingerprinters[END_REF][START_REF] Starov | Are you sure you want to contact us? quantifying the leakage of pii via website contact forms[END_REF] studies. Assuming the increasing adoption of anti-bot services, this means that the results obtained through PhantomJS-related crawling will be decreasingly accurate. In the short term, we recommend that researchers avoid using PhantomJS in favor of newer and more complete crawling tools, such as, headless Chrome and OpenWPM [START_REF] Englehardt | Online Tracking: A 1-million-site Measurement and Analysis[END_REF]. In the long term, we need both the technical means to evaluate the fingerprintability of crawling frameworks used for research, as well as a discussion between stake-holders on how crawling-based studies should be best conducted.

Responsible Disclosure

During this study we observed behaviors that can either be attributed to customer-website misconfigurations of an anti-bot service (i.e. customers do not fully take advantage of the detection capabilities of anti-bot services) or can be blind spots within the detection models of the evaluated services. As such, we contacted 7 services with what we regarded as high-impact misconfigurations or security issues on their client websites in December 2019. During these communications, our goal was to share our findings and obtain more information about the design decisions and details that we could not observe as outsiders. Ultimately, three services (ThreatMetrix, DataDome, and Castle) reached back to us. We have shared the list of vulnerable target websites in our study and our bot scripts with the anti-bot services upon their request and we are in continuous conversation with them. We hope that this information will be used to increase the accuracy and coverage of these services.

Related Work

Research-wise, despite its potential for abuse, bot identification has only attracted limited research which, given the adaptations from bot authors, can quickly become dated. Existing attempts to differentiate crawlers from real users rely on differences in their navigational patterns, the percentage of HTTP methods in requests, the types of links requested, and the timing between requests [START_REF] Jacob | Pubcrawl: Protecting users and businesses from crawlers[END_REF][START_REF] Lourenc ¸o | Catching web crawlers in the act[END_REF][START_REF] Tan | Discovery of web robot sessions based on their navigational patterns[END_REF]. These features are then used in supervised machinelearning algorithms trained using ground truth that the authors of each paper were able to procure, typically by manually labeling traffic of one or more webservers to which they had access. Xie et al. propose an offline method for identifying malicious crawlers by searching for clusters of requests towards non-existent resources [START_REF] Xie | Scanner hunter: Understanding http scanning traffic[END_REF]. Next to ML-based methods, Park et al. [START_REF] Park | Securing web service by automatic robot detection[END_REF] investigated the possibility of detecting malicious web crawlers by looking for mouse movement, the loading of Cascading Style Sheets, and the following of an invisible link that is present in the HTML code of a page yet is invisible to regular users. McKenna [START_REF] Mckenna | Detection and classification of Web robots with honeypots[END_REF] recently experimented with more types of invisible links and resources but was unable to gauge their effectiveness due to size and duration limitations of their study. Interestingly, the majority of work on bot detection predates browser fingerprinting despite the latter appearing as early as 2010 [START_REF] Acar | The Web Never Forgets: Persistent Tracking Mechanisms in the Wild[END_REF][START_REF] Acar | FPDetective: dusting the web for fingerprinters[END_REF][START_REF] Das | The web's sixth sense: A study of scripts accessing smartphone sensors[END_REF][START_REF] Eckersley | How Unique is Your Web Browser?[END_REF][START_REF] Englehardt | Online Tracking: A 1-million-site Measurement and Analysis[END_REF][START_REF] Gómez-Boix | Hiding in the Crowd: an Analysis of the Effectiveness of Browser Fingerprinting at Large Scale[END_REF][START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF][START_REF] Nikiforakis | Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting[END_REF] even though as we showed throughout this paper, all but one of the evaluated anti-bot services heavily rely on fingerprinting for identifying bots.

All the prior research that focused on adding new attributes to a fingerprint [START_REF] Fifield | Fingerprinting web users through font metrics[END_REF][START_REF] Mowery | Fingerprinting Information in JavaScript Implementations[END_REF][START_REF] Mulazzani | Fast and reliable browser identification with javascript engine fingerprinting[END_REF][START_REF] Starov | XHOUND: Quantifying the Fingerprintability of Browser Extensions[END_REF], notably techniques like canvas [START_REF] Mowery | Pixel Perfect: Fingerprinting Canvas in HTML5[END_REF], AudioContext [START_REF] Englehardt | Online Tracking: A 1-million-site Measurement and Analysis[END_REF] or WebGL [START_REF] Cao | Cross-)Browser Fingerprinting via OS and Hardware Level Features[END_REF] fingerprinting, is especially relevant to anti-bot services as it could offer more ways to distinguish a bot from a regular user. Moreover, there exists machine-learning approaches to link fingerprint evolutions over time [START_REF] Vastel | FP-STALKER: Tracking Browser Fingerprint Evolutions[END_REF] which could be used to track changes in a bot fingerprint. Relying on fingerprinting techniques, Bursztein et al. proposed Picasso, a tool aimed at identifying inorganic traffic through canvas fingerprinting [START_REF] Bursztein | Picasso: Lightweight device class fingerprinting for web clients[END_REF].

Jueckstock et al. introduced VisibleV8, an instrumented Chromium based browser that is capable of monitoring dynamic JavaScript API calls [START_REF] Jueckstock | VisibleV8: In-browser monitoring of JavaScript in the wild[END_REF]. The authors found that 29% of top 50k Alexa websites probe for artifacts of automated browsing environment but do not evaluate the usage of these artifacts and whether these websites can detect different types of bots in practice. Vastel et al. study the presence of bot-detection artifacts over the Alexa top 10K websites [START_REF] Vastel | FP-Crawlers: Studying the Resilience of Browser Fingerprinting to Block Crawlers[END_REF]. While they focus on fingerprinting behavior of anti-bot systems, our study systematically evaluates the overall benefits and drawbacks of existing anti-bot approaches as they are deployed in the wild. Moreover, we model real world attack scenarios whereas previous work focused on the fingerprinting surface of browsers and blocking behavior when visiting target websites.

Conclusion

In this paper, we reported on the first analysis of anti-bot services for the web. By isolating and analyzing the JavaScript code which the clients of anti-bot services need to utilize, we identified near universal-reliance on browser fingerprinting, including recently-proposed fingerprinting techniques, as well as checks for the consistency of the presented fingerprints. Through large-scale, black box and gray box analyses of each service using off-the-shelf automation tools as well as less-popular automated environments, we quantified the ability of these services to detect and block bots. We discovered that many services perform poorly and browsers that are less commonly automated (i.e Safari on Mac and Chrome on Android) can achieve an overall success rate of 80% during content-scraping attempts. We also discovered that the location of a bot on a public cloud is secondary to its fingerprint and only 4 services are sensitive to the location of source IP address. This allows attackers to launch massive bot campaigns by renting low-cost virtual machines on public data centers.

Overall, our findings suggest that existing services can stop basic bots, but are currently not capable of blocking specialized tools and even the less popular automated browsers, which can bypass the protection of around 75% of content-scraping targets. As such, they cannot substantially limit determined attackers. At the same time, our findings are relevant for all research involving the crawling of websites since websites that utilize anti-bot services may be able to identify the tools used by researchers (such as PhantomJS) and thereby evade accurate analysis.

Fig. 1 :

 1 Fig. 1: High-level architecture of Anti-bot services

Fig. 2 :

 2 Fig. 2: Screenshot of blocking message from Distil Networks

C h ro mFig. 3 :

 3 Fig. 3: Performance of Content Scraping Bots

Fig. 5 :

 5 Fig. 5: Performance of Brute Force Bots

Table 1 :

 1 Popular anti-bot services

	Service	Type # Clients Alexa 1M
	Cloudflare (G)	Bot attacks 7,250,835 13.65%
	Sift Science	Bot attacks 18,733	3.41%
	Iovation	Account fraud 14,280	1.62%
	ShieldSquare (G)	Bot attacks 8,151	1.46%
	PerimeterX	Bot attacks 7,808	1.14%
	InfiSecure	Bot attacks 5,443	0.11%
	DataDome (G)	Bot attacks 912	5.48%
	ThreatMetrix	Account fraud 628	5.41%
	Distil Bot Defense	Bot attacks 484	38.43%
	Castle (G)	Account fraud 260	4.62%
	Simility	Account fraud 182	2.20%
	ThisData	Account fraud 138	1.45%
	Kount Access	Account fraud 124	31.45%
	Unbotify	Bot attacks	60	3.33%
	DupZapper	Account fraud	33	3.03%
	Overall	Anti-bot 7,311,809 13.56%

Table 3 :

 3 Number of successful content scraping attempts (Gray box)an Apple device or Safari. For comparison, this score is in the range of 70-88 for Selenium and 100 (i.e. maximum risk) for PhantomJS.

Table 4 :

 4 Number of brute force attempts before getting blocked (Gray box) Checkmarks indicate successful account takeover

	Service	Service #1	Service #2	Service #3	Service #4
	Tool	Campus Cloud Campus Cloud Campus Cloud Campus Cloud
	Python	1000	0	5	5	240	12	2	1000
	PhantomJS	0	0	5	5	0	0	0	0
	Chrome	0	0	5	5	250	23	0	0
	Firefox	10	0	5	5	405	21	1	0
	Safari	1000	0	5	5	334	13	1000	1000

Table 5 :

 5 Service ability to block content scraping by different bots (Gray box and Black box tests) ( : Blocked, : Some automation tools can bypass, : Failed to block) Anti-bot Service Basic bots Automated browsers Less Popular FPs Stripping IP Sensitivity

	Service #2 (G)

  Performance of Account Takeover BotsAccount Takeover Results Overall, 2-8% of websites blocked all our account takeover attempts across all bot categories from Campus and Cloud IP addresses respectively. Applescript-Safari was the most successful tool with 82.5% average success rate. Bots based on Safari automated by AppleScript, were able to break into user accounts with unseen fingerprints (Safari browser) and from new IP addresses. Table 6 summarizes our results for gray box and black box tests for account takeover and brute force tests. The results are sobering. By looking at Figure

		100%	Campus	Cloud
		80%
	Success rate	20% 40% 60%
		0%	Chrome	Firefox	Safari
		Fig. 4:

Table 6 :

 6 Service ability to block Account Takeover by different bots (Gray box and Black box tests)

	( : Blocked, :Some automation tools can bypass, : Failed to block)
		Brute force: number of websites without any login rate-limiting
	Anti-bot Service Basic bots Automated browsers Less Popular FPs Brute Force IP Sensitivity
	Service #1 (G)	6/10	High
	Service #2 (G)	0	None
	Service #3 (G)	4/10	High
	Service #4 (G)	10/10	Low
	Service #5	3/10	High
	Service #6	7/10	Low
	Service #7	3/10	Low
	Service #8	9/10	None
	Service #9	7/10	High
	Service #10	8/10	Low

Acknowledgements: We thank the anonymous reviewers for their helpful feedback. This work was partially supported by a gift from Amazon and the National Science Foundation (NSF) under grants CNS-1813974, CNS-1617902, and CMMI-1842020.

Service

Tool

Gray Box Account Fraud Results

The account-fraud tests are relevant for all four companies in our gray box experiment. We analyze the results for both account takeover and account brute force tests. The time window of interaction for account takeover is limited to two requests (one to grab the CSRF token and one to login). As a result, features, such as, login history including locations, fingerprint of used devices and fingerprints of bots, are more effective in this scenario compared to behavioral anomaly detection. Table 4 shows the number of successful brute force attempts along with whether the account takeover was successful.

Plain Python outperforms PhantomJS: The first unexpected observation, which is consistent among nearly all tests and anti-bot services, is that PhantomJS has inferior performance to plain Python scripts. For example, all services with client fingerprinting capability block login attempts from PhantomJS. Our hypothesis is that this tool was so much overused by attackers (PhantomJS was the first headless JavaScript-supporting browser) that anti-bot services have enough features to detect it with high confidence. Contrastingly, since Python scripts are not capable of executing JavaScript, anti-bot services give them the benefit of the doubt (e.g. it may be a JavaScript-blocking user) and allow a few requests to go through before taking action.

Safari breaks into all user accounts: Interestingly, none of the services block Safari that is automated by Applescript. To our surprise, the risk score reported by Service #1 for Applescript is very low (17/100) even though a real user never logged into the user account with


Babak Amin Azad

Oleksii Starov

Pierre Laperdrix

Nick Nikiforakis

Taming The Shape Shifter: Detecting Anti-fingerprinting Browsers

come

Introduction

Major database hacks and personal information leaks have been the common cyber news headline for the past couple of years. Haveibeenpwned 4 , the website that hosts the records of publicly known credential leaks, currently hosts 428 instances of credential leakage from different websites, including some highly popular (e.g. Linkedin and Dropbox). The number of accounts affected by these leaked credentials adds up to over 773 million accounts.

In a similar fashion, the online shopping industry has been the prime target of attackers. In 2019, over 180,000 websites were successfully attacked by Magecart hackers [START_REF]Magecart Skimmers Spotted on 2M Websites[END_REF]. By implanting malicious JavaScript code on hacked websites, attackers behind these operations steal credit card and payment information of clients upon checkout. According to statistics from the security industry [START_REF]Magecart Skimmers Spotted on 2M Websites[END_REF], these attacks have so far affected more than 2 million users.

The stolen credentials and credit card information typically end up being sold in bulk in the underground markets [START_REF] Thomas | Data breaches, phishing, or malware? understanding the risks of stolen credentials[END_REF]. Verification and monetization of the stolen information at scale requires specific tools. Automation is also a vital part of these malicious operations as the size of the data that needs to be verified and then abused becomes increasingly larger. As a result, malicious actors have built automation tools to speed up this process. The existing anti-bot and fraud detection tools and services heavily rely on browser fingerprinting [START_REF] Aminazad | Web Runer 2049: Evaluating Third-Party Anti-bot Services[END_REF]. In order to bypass these mechanisms, malicious actors use specialized browsers that enable them to easily switch fingerprints or simulate a target browsing environment and evade detection. We assembled our list of anti-fingerprinting browsers by searching the underground markets for the tools that malicious actors use, as well as commercial and research projects that promise to defend against tracking. Success stories (e.g., reaching over 90% success rate in carding attempts) and tutorials on configuring and efficiently using these browsers are widely available on different carding forums [START_REF]AntiDetect tool, only way to cashout from stolen credit cards[END_REF][START_REF]Fraudfox makes it easier for thieves to empty bank accounts[END_REF][START_REF]AntiDetect 7 and FraudFox VM, best carder protection[END_REF][START_REF]Fraudfox tool in and underground carding forum[END_REF]. Malicious actors use these forums to trade the stolen credit card information and share their latest tips on successful cashout strategies.

Tools such as AntiDetect [START_REF] Krebs | AntiDetect' Helps Thieves Hide Digital Fingerprints[END_REF] and Fraudfox [START_REF] Kirk | This tool may make it easier for thieves to empty bank accounts[END_REF] are commonly incorporated to mask the browser fingerprints of attackers and evade detection from tools that look for known good (i.e. belonging to a specific benign user) or known bad (i.e. belonging to a previously seen attacker) fingerprints. These browsers not only enable attackers to switch browser fingerprints, they also give them the ability to mimic a victim's environment, such as, setting their timezone and screen resolution to match the victim when visiting websites to make fraudulent purchases or access the hacked accounts.

Even though these tools are popular among attackers, they have not received the attention they deserve from the research community. In this paper, we study the techniques that these tools incorporate to remain undetected and quantify their effectiveness against state-of-the-art, in browser fingerprinting. After analyzing the fingerprintable surface of these tools, we show that we were able to devise fingerprinting-based signatures for all of them which can be used to uniquely identify them. Our findings can be used by the existing anti-fraud systems to precisely identify the usage of antifingerprinting browsers.

Background

In a typical case of online fraud, multiple entities are involved. Usually, one party is responsible for stealing credentials, which are then sold in bulk to another party to be monetized [START_REF] Singh | The Underground Ecosystem Of Credit Card Fraud[END_REF]. The timeliness of these events is crucial. As the stolen information gets stale, it is more likely for the compromised websites or individual victims to have been informed about their information being stolen and invalidate their credentials. In the mean time, to prevent issues with stolen credentials, merchants who process payment information started to incorporate browser fingerprinting to detect fraudulent and automated browsing activities.

Companies providing fraud detection services commonly use browser-fingerprinting to track users [START_REF] Datadome | Protect your website from bot traffic[END_REF][START_REF]Distil Networks: Bot Mitigation & API Security[END_REF][START_REF]ShieldSquare: Bot Mitigation & Protection[END_REF][START_REF]PerimeterX: Anti Bot Protection -Protect Against Bot Attacks[END_REF]. By collecting information from users' web browsers, these services build browsing profiles of normal users. This information is then used to filter out fraudulent requests.

State-of-the-art browser fingerprinting identifies users by leveraging features such as HTTP headers and available JavaScript APIs [START_REF] Eckersley | How unique is your web browser? In: Privacy Enhancing Technologies[END_REF][START_REF] Laperdrix | Beauty and the Beast: Diverting modern web browsers to build unique browser fingerprints[END_REF]. The act of fingerprinting transcends the actual browser, enabling the identification of the operating system and the underlying hardware [START_REF] Cao | Cross-)Browser Fingerprinting via OS and Hardware Level Features[END_REF]. This is typically achieved based on the characteristics of rendered images within an HTML canvas element [START_REF] Bursztein | Picasso: Lightweight device class fingerprinting for web clients[END_REF][START_REF] Mowery | Pixel Perfect: Fingerprinting Canvas in HTML5[END_REF]. Other researchers have focused on other parts of the browsing environment to build more robust fingerprints by extracting the list of available fonts and browser extensions [START_REF] Fifield | Fingerprinting web users through font metrics[END_REF][START_REF] Starov | XHOUND: Quantifying the Fingerprintability of Browser Extensions[END_REF]. Fingerprintjs2 [START_REF] Vasilyev | FingerprintJS2: Modern & flexible browser fingerprinting library[END_REF], a well-known browser fingerprinting library, compiles the previously mentioned fingerprinting methods in a JavaScript module that can be integrated with any website to collect browser fingerprints of its visitors. Lastly, behavioral features of the user like the use of clicks or touch can be collected to separate interactive user activity from that of an automated client.

Anti-fingerprinting browsers

To battle fingerprinting, anti-fingerprinting browsers capable of modifying the content of their fingerprint were created. We categorize the browser fingerprint modification schemes into three groups. Each group has its own benefits and drawbacks as we discuss below:

-JavaScript Injection: In this method, JavaScript is injected into all webpages loaded by the browser. This way, JavaScript properties and methods are overwritten to send different information to servers. For example, when a script wants to access navigator.userAgent or render a canvas image, it will find the newly injected version instead of the default one. The strength of this approach is the ease of deployment and maintainability. However, prior work has shown that these spoofing extensions may not offer the best protection against fingerprinting as they often present incomplete coverage of JavaScript objects and can create impossible configurations [START_REF] Nikiforakis | Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting[END_REF]. -Native Spoofing: Native spoofing modifies the source code of the browser to return modified values. For some attributes, changing the sent value is as simple as rewriting a string but for other methods like canvas fingerprinting, successful modifications require a deeper understanding of a browser's codebase to find the right methods and modify them appropriately. The strength of this solution is that it can be hard to detect as an inspection of the Document Object Model (DOM) is not sufficient to detect traces of spoofing. However, the downside is that the cost of maintenance can be high, requiring a complete rebuild of the browser after each update. -Recreating Complete Environments: This method consists of utilizing a virtualized browsing environment with a desired configuration on top of the host system. The advantage of this method is that the fingerprint presented to servers is genuine as the components truly run on the system. For the same reason, no impossible configurations can result from such an approach. On the downside, this approach requires more system resources compared to a simple browser extension or a modified browser.

In this section, we analyze research, commercial, and underground tools against fingerprinting, in order to understand whether masking the true fingerprint of a device can help bypass current fingerprinting techniques. Next, we list the tools that are included in this study along with the anti-fingerprinting mechanism they use.

AntiDetect and Fraudfox [JavaScript Injection].

AntiDetect is one of the first tools that surfaced online against browser fingerprinting, gaining visibility from a 2015 article [START_REF] Krebs On Antidetect | [END_REF]. AntiDetect uses JavaScript injection and relies on a browser extension to change the exhibited browser fingerprint. To improve usability, users are presented with an interface where they can choose a profile from a pool of existing browser fingerprint profiles. Fraudfox appeared at approximately the same time as AntiDetect and works in a similar fashion by providing an interface to users for selecting the fingerprint they want to expose [START_REF] Kirk | This tool may make it easier for thieves to empty bank accounts[END_REF]. Fraudfox offers the option to modify several attributes separately and also targets advanced techniques, such as, font fingerprinting. It uses a custom Windows XP virtual machine and a tool named OSfuscate to change the TCP/IP fingerprint of the system in order to confuse nmap-like tools that can identify OSes based on the structure of network packets.

Mimic [Native Spoofing].

Mimic is a modified Chrome browser that uses native spoofing to modify its fingerprint [START_REF]Multilogin -The Most Advanced Browser Fingerprinting Protection Ever Created -Enter Mimic[END_REF]. Users can generate various profiles and activate the desired fingerprinting protection. One particularly interesting feature of Mimic is that it gives users the option to either block, or introduce noise into some fingerprintingrelated APIs. In contrast to the previously mentioned underground tools, Mimic takes a different approach and advertises itself as a generic solution against browser fingerprinting that can be used for marketing, journalism, cyber investigation, and even web scraping activities.

Blink [Recreating Complete Environments]

Blink is a moving-target-style defense against browser fingerprinting. Proposed by Laperdrix et al. [START_REF] Laperdrix | Mitigating browser fingerprint tracking: multilevel reconfiguration and diversification[END_REF], this tool assembles a set of components at runtime into a virtual machine. Upon each execution, the virtual machine's environment is modified with new configurations (e.g., timezone, available fonts, etc.) in order to generate an organic browser fingerprint. This guarantees that the exhibited fingerprint is coherent compared to the other tools where the artificial combination of browser properties can easily result in impossible configurations.

A full comparison of the tools along with the exact fingerprinting techniques that each of them counters, can be found in Table 1. The main tactic that these tools incorporate against detection is frequent rotation of valid fingerprints. That is, the common elements in browser fingerprints as mentioned both in the literature and popular opensource fingerprinting libraries such as Fingerprintjs2, are configurable.

These values are faked through a large list of valid fingerprints that is either shipped with these browsers or can be easily generated through their interface. For instance, AntiDetect comes with over 4,000 profiles and Fraudfox includes profiles with 90 useragents and 5 browsers and 6 operating systems. Moreover, users can choose to add noise to certain APIs such as audio context and the canvas API. This variety makes it hard to derive features from the common fingerprinting libraries to uniquely identify these browsers. Interestingly, Fraudfox has been tested against popular browser fingerprinting tools and the successful rotation of fingerprints and removal of tracking information (e.g., Evercookies [START_REF] Evercookie | [END_REF]) has been verified in the underground carding forums [START_REF]Fraudfox tool in and underground carding forum[END_REF].

All of the studied anti-fingerprinting browsers, except Blink, which is discussed separately in Section 4, modify or add noise to the existing browser properties. We will discuss in more detail how this type of modification will inherently introduce inconsistencies and demonstrate concrete examples of these inconsistencies and use them to build signatures that uniquely identify these browsers in Section 4.

Detecting the anti-fingerprinting tools

To extract unique characteristics that can be used to uniquely identify each browser, we analyzed each tool using the techniques described by Nikiforakis et al. [START_REF] Nikiforakis | Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting[END_REF] and Acar et al. [START_REF] Acar | FPDetective: dusting the web for fingerprinters[END_REF]. We investigate built-in JavaScript objects, such as, navigator and screen with and without anti-fingerprinting mechanisms, looking for inconsistencies. According to Vastel et al., existing bot detection schemes already use similar techniques to detect the presence of impossible fingerprints [START_REF] Vastel | FP-Crawlers: Studying the Resilience of Browser Fingerprinting to Block Crawlers[END_REF]. To the best of our knowledge, we are the first to report on the fingerprintability of dedicated anti-fingerprinting tools.

• AntiDetect Since AntiDetect relies on a browser extension, a single line of JavaScript is sufficient to detect injected values. Notably, objects created through JavaScript are easily identifiable as they only contain a toString function. In Listing 1 (top), we can clearly see the getGamepads function written by the developers to modify the returned value as if it was a native one. [native code] //}" canvas = document.createElement("canvas"); canvasContext = canvas.getContext("2d"); canvasContext.fillStyle = "#ff6600"; canvasContext.fillStyle.toString(); //Returns the color set by the user: "#71cda0" //Standard Firefox returns the color from the script: "#ff6600" Listing 1: Detecting JavaScript injection performed by AntiDetect (top)

and Fraudfox (bottom)

Like other tools relying on JavaScript injection, inconsistencies in fingerprints are possible and frequent. One example is when AntiDetect launches a Chrome profile where one can observe the presence of both webkit and moz prefixed properties which is impossible as these belong to two different rendering engines. Another example is a mismatch between two attributes where the user-agent reports a 64-bit OS and the navigator.platform indicates a 32-bit one.

• Fraudfox presents the same shortcomings as AntiDetect as it also relies on the same spoofing method. However, one needs to look elsewhere to find traces of JavaScript injection. As shown in Listing 1 (bottom), the developers directly poison the prototype of specific objects. One can also easily find the parameters that are set in the tool's interface like the exact filling color of the canvas API. This could, in fact, act as a longtime identifier if the user always reuses the same profile without regularly updating the canvas color. Finally, Fraudfox has its own set of inconsistencies. For example, Chrome profiles present moz-prefixed properties but no webkit ones. Mac profiles show .dll extension for plugins instead of .plugin.

• Mimic is harder to detect compared to the two previous solutions because it does not rely on JavaScript injection. However, the browser is still identifiable through some unique inconsistencies that come from its database of fingerprints. When spoofing the WebGL Renderer, Mimic always add the ANGLE string in front of every value. However, this string can only be found on Windows as Chrome uses the ANGLE backend on this operating system to translate OpenGL API calls to DirectX. On Linux, plugins with the .so extension are visible creating an inconsistency if a Windows or a Mac profile is selected. Finally, Mimic presents an incorrect priority in the HTTP language header. The second language should present a priority of 0.9 ("en-US,en;en;q=0.9") but Mimic returns one of 0.8 ("en-US,en;en;q=0.8"). Changing the priority is easily fixable in the profile database but it shows that the smallest detail can render a tool identifiable. Focus on canvas poisoning. Each tool also has its own canvas poisoning technique, which as we demonstrate is identifiable. Figure 2 illustrates them. AntiDetect changes the letters of a given string and their position. Fraudfox modifies the colors set by a script. This is directly configurable in the interface of the tool. Moreover, since the tool runs on Windows XP, the OS does not have any fonts that support emojis (presence of a green square at the end of the strings). Mimic is different from the other two as the modification is almost invisible for the user. Mimic introduces a small amount of noise but an in-depth analysis reveals that the transparency of some pixels were changed (on the zoomed-in image, the top half of the orange rectangle is more transparent than the bottom half).

Overall, our findings demonstrate that a combination of several tests is sufficient to precisely identify all evaluated anti-fingerprinting tools. The quirks discovered can be corrected but our results confirm that it is difficult to design an anti-fingerprinting tool that is not detectable. For both JavaScript injection and native spoofing, the smallest oversight can make the user stand out, be marked as malicious and invalidate the offered protection.

Blink and the recreation of complete environments

In this section, we showed how the operators of anti-fraud systems can fingerprint antifingerprinting tools, based on the latter's inability of perfectly mimicking a non-native browsing environment. Blink, the research prototype by Laperdrix et al. [START_REF] Laperdrix | Mitigating browser fingerprint tracking: multilevel reconfiguration and diversification[END_REF] that we introduced in Section 3, sets itself apart from the rest by the fact that it does not attempt to mimick a foreign environment. Instead, Blink assembles a real environment with different components and launches that environment in a virtual machine. As such, none of the techniques presented in this section can be used to detect Blink since there is no mimicking involved and therefore no inconsistencies to be discovered. Despite Blink's attractiveness for defeating fingerprinting-based, unwanted online tracking (since users can keep changing their fingerprints and therefore break the linking of browser sessions), we argue that Blink's utility is limited for attackers. This is because, an attacker who tries to match the fingerprinting of a victim user, must utilize Blink to recreate the entire browsing environment of their victim. This requires not just the installation of the appropriate software, but even the purchase of the appropriate hardware (e.g. to match the number of threads in the victim's CPU and how the victim's graphics card renders complex 3D scenes). All of this is clearly possible for highly targeted attacks but also highly unlikely for the monetization of credentials, since the investment in assembling the right environment can exceed the profit from the stolen credentials.

Related Work

Prior work can be split into the study of underground markets, browser fingerprinting, and bot-based fraud detection.

Singh et al. studied the underground ecosystem of credit card fraud [START_REF] Singh | The Underground Ecosystem Of Credit Card Fraud[END_REF]. They describe the different methods that attackers use to steal credit card information. These methods range from POS malware to exploitation of a vulnerability. Given the difficulty and risk associated with monetizing stolen credentials, attackers often resort to selling these illicitly obtained credentials to other attackers specializing in monetization. The authors then go over the existing channels to monetize the cards (e.g. by delivering high-end goods purchased with stolen credentials to unsuspecting users who believe they are working for a shipping company and will then re-ship the goods to another destination [START_REF] Hao | Drops for Stuff: An Analysis of Reshipping Mule Scams[END_REF]). Other works focused on trafficking of fraudulent twitter accounts in the underground markets [START_REF] Thomas | Trafficking fraudulent accounts: The role of the underground market in twitter spam and abuse[END_REF]. Fallmann et al. discussed their finding on probing these markets [START_REF] Fallmann | Covertly probing underground economy marketplaces[END_REF] and Thomas et al. assessed the effect of data breaches on the activities of underground markets [START_REF] Thomas | Data breaches, phishing, or malware? understanding the risks of stolen credentials[END_REF].

In the realm of browser fingerprinting, researchers keep identifying features that can be extracted from browsers and make browser fingerprints more robust [START_REF] Bursztein | Picasso: Lightweight device class fingerprinting for web clients[END_REF][START_REF] Cao | Cross-)Browser Fingerprinting via OS and Hardware Level Features[END_REF][START_REF] Fifield | Fingerprinting web users through font metrics[END_REF][START_REF] Mowery | Pixel Perfect: Fingerprinting Canvas in HTML5[END_REF][START_REF] Starov | XHOUND: Quantifying the Fingerprintability of Browser Extensions[END_REF][START_REF] Vastel | FP-STALKER: Tracking Browser Fingerprint Evolutions[END_REF]. As fingerprinting-based fraud detection tools incorporate these features into their techniques, the tools used by attackers must also account for them (such as accounting for canvas-based fingerprinting, as described in Section 4).

One of the challenges in the study of JavaScript files and fingerprinting scripts is instrumenting the various API calls and monitoring them. VisibleV8 is a Chromium based browser that is easy to maintain over time and provides the ability to monitor JavaScript API calls [START_REF] Jueckstock | VisibleV8: In-browser monitoring of JavaScript in the wild[END_REF]. The authors used their customized browser to analyze the prevalence of scripts that query for bot and browser automation artifacts on popular Alexa websites.

Conclusion

In this paper, we showed that anti-fingerprinting tools are capable of bypassing the protection of state-of-the-art fingerprinting techniques by masking the components that are queried by fingerprinting libraries. We analyzed their masking techniques (i.e., JavaScript injection, native spoofing, and the recreation of complete environments) and described the process of identifying fingerprinting-based inconsistencies which can be used to identify them and block them. Our analysis showed that all tools that attempt to mimick non-native environments are unique fingerprintable and therefore can be identified by anti-fraud systems, through the use of our proposed fingerprinting vectors. Finally, we discussed the difficulty of fingerprinting tools that are based on the recreation of browsing environments and the reasons why these tools are highly unlikely to be used in generic, non-targeted attacks.

Fig. 2 :

 2 Fig. 2: Renderings of the same canvas test

Table 1 :

 1 Overview of the studied tools with the fingerprinting techniques they counter

	Tool	AntiDetect	Fraudfox	Mimic	Blink
	Type	Injection	Injection	Native	Recreation
	Tested version	7.1	1.5.1	1.4.8	1.0
	Number of profiles or components	>4,000	600 fonts, 90 user-agents, 85 plugins, 5 browsers and 6 OS	1,000	2,762 fonts, 39 plugins, 6 browsers and 4 OS
					Latest versions of
	Browser used	Firefox 41-48	Firefox 41	Chrome 61	Chrome and
					Firefox
			Proxy through
	Network	-	SocksCap64 + Obfuscation of OS Network packet	Built-in proxy management (HTTP, Socks5)	Built-in support for Tor
			through OSfuscate
	User Agent
	Language
	Screen
	Navigator
	Timezone
	Date
	Fonts
	Plugins
	Media devices
	Canvas	Noise (letters in strings)	Noise (fonts and colors)	Noise (fonts and colors)	Noise (change of OS)
	WebGL	Blocked	Blocked	Only vendor and renderer	Noise (change of OS)
	WebRTC			Block or fake IP address
	Geolocation
	Hardware
	Concurrency

https://haveibeenpwned.com/

Acknowledgements: We thank the anonymous reviewers for their helpful feedback. This work was partially supported by a gift from Amazon and the National Science Foundation (NSF) under grants CNS-1813974, CNS-1617902, and CMMI-1842020.