Forwarding-Loop Attacks in Content Delivery Networks Jianjun Chen∗yz, Jian Jiangx, Xiaofeng Zheng∗yz, Haixin Duanyz{, Jinjin Liang∗yz, Kang Lik, Tao Wan∗∗, Vern Paxsonx{, ∗Department of Computer Science and Technology, Tsinghua University yInstitute for Network Science and Cyberspace, Tsinghua University zTsinghua National Laboratory for Information Science and Technology fchenjj13, zhengxf12, [email protected], [email protected] xUniversity of California, Berkeley [email protected] {International Computer Science Institute [email protected] kDepartment of Computer Science, University of Georgia [email protected] ∗∗Huawei Canada [email protected] Abstract—We describe how malicious customers can attack In this work we present “forwarding-loop” attacks, which the availability of Content Delivery Networks (CDNs) by creating allow malicious CDN customers to attack CDN availability forwarding loops inside one CDN or across multiple CDNs. Such by creating looping requests within a single CDN or across forwarding loops cause one request to be processed repeatedly or multiple CDNs. Forwarding-loop attacks allow attackers to even indefinitely, resulting in undesired resource consumption and massively consume CDN resources by building up a large potential Denial-of-Service attacks. To evaluate the practicality number of requests (or responses) circling between CDN of such forwarding-loop attacks, we examined 16 popular CDN providers and found all of them are vulnerable to some form of nodes. The impact can become more severe in the (common) such attacks. While some CDNs appear to be aware of this threat case where attackers can manipulate DNS records to dynami- and have adopted specific forwarding-loop detection mechanisms, cally control a loop’s IP-level routing on a fine-grained basis. we discovered that they can all be bypassed with new attack tech- niques. Although conceptually simple, a comprehensive defense Although many CDN providers have internal mechanisms requires collaboration among all CDNs. Given that hurdle, we (such as appending custom HTTP headers like CloudFlare’s also discuss other mitigations that individual CDN can implement CF-Connecting-IP [19]) to detect repeated requests when immediately. At a higher level, our work underscores the hazards they circle back, we find that an attacker can bypass such that can arise when a networked system provides users with defense mechanisms by using features offered by some control over forwarding, particularly in a context that lacks a other CDNs to filter HTTP headers. Our experiments with single point of administrative control. 16 commercial CDNs show that all of them are vulnerable to forwarding-loop attacks, even with their existing defense mechanisms. I. INTRODUCTION We also examine the threat of stealthy forwarding-loop Content Delivery Networks (CDNs) are widely used in the attacks. In the Dam Flooding Attack, an attacker secretly Internet to improve the performance, scalability and security and gradually accumulates a large number of pending CDN of websites. A CDN enhances performance for its customers’ requests over a lengthy period (hours). They then trigger a huge websites by redirecting web requests from browsers to ge- volume of cascading traffic by suddenly providing bandwidth- ographically distributed CDN surrogate nodes. A surrogate consuming responses and controlling all responses to arrive serves the content directly if cached, or forwards requests to the simultaneously. Worse, we find that internal CDN features— origin site otherwise. To improve availability, surrogates absorb such as automatic server probing (Azure China), forwarding distributed denial-of-service (DDoS) attacks by distributing the retries (Akamai and CloudFront), and proactive decompression attack traffic across many data centers. Some CDN providers of gzip’d responses (Akamai, Baidu and CloudFlare)—can also provide WAF (Web Application Firewall) services to amplify the DoS effect of forwarding-loop attacks and further normalize traffic and filter intrusions to their customer’s web exacerbate the load on the CDN. sites. Overall, we make the following contributions: Permission to freely reproduce all or part of this paper for noncommercial 1) We describe forwarding-loop attacks that broadly purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited threaten CDN providers. Our study shows that the without the prior written consent of the Internet Society, the first-named author amplification attacks are severe and can consume (for reproduction of an entire paper only), and the author’s employer if the a huge volume of resources in commercial CDNs paper was prepared within the scope of employment. at low cost. The attacks can potentially undermine NDSS ’16, 21-24 February 2016, San Diego, CA, USA Copyright 2016 Internet Society, ISBN 1-891562-41-X the security provided by CDNs, which are usually http://dx.doi.org/10.14722/ndss.2016.23442 considered robust against DoS attacks. 2) We performed controlled tests on 16 popular CDN Request Forwarding providers to verify the practicality of such attacks. example.com Server IP Although some CDN providers implemented defense HTTP GET/POST HTTP GET/POST mechanisms for mitigating forwarding loops, we http://example.com http://example.com Web Site Browser CDN Node show that those defenses can be bypassed. (example.com) 3) We present the Dam Flooding attack, a highly dam- aging type of forwarding-loop attack. 4) We propose four approaches to preventing or mit- Fig. 1. Normal CDN forwarding behavior. igating forwarding-loop attacks, and discuss their advantages and limitations. a CDN’s performance. The higher the ratio, the more requests We organize the rest of this paper as follows. Section II that the CDN answers out of its cache, significantly reducing describes CDN operation, especially forwarding and filtering response latency and as well as the load imposed on the origin techniques. In Section III we present various forwarding- website. However, a user can force requests to come from the loop attacks and analyze the factors affecting them. We also origin website instead of the CDN’s cache. First, adding a described our experiments to construct loops within and across no-cache request header will make the CDN re-validate the CDNs, and the “Dam Flooding” attack leveraging streaming response from the origin server [6]. Second, POST requests HTTP responses. We discuss possible defenses to prevent or usually will write through to the origin server [7], [16]. In mitigate forwarding-loop attacks in Section IV and related addition, most CDNs provide ways for customers to configure research regarding forwarding loops and CDN security in the CDN to not cache certain URLs. Section V. We conclude in Section VI. Typical commercial CDNs usually have massive bandwidth and computational resources distributed around the Internet, II. BACKGROUND making them much more resilient to DDoS attacks than most of websites. DDoS traffic targeting a CDN-protected website CDNs are distributed systems with large numbers of servers will be directed to CDN servers distributed across data centers deployed across the Internet. Initially created to improve with ample bandwidth, and then absorbed or blocked before website performance and scalability, many CDNs also provide arriving the original website. Indeed, capacity for mitigating security features such as DDoS protection and Web Appli- DDoS attacks has become a “selling point” for today’s com- cation Firewalls (WAFs) for websites. CDNs have evolved mercial CDNs. to become important Internet infrastructure. For example, the leading CDN provider Akamai claims that it alone delivers Many CDNs also provide an additional security service 15–30% of all Web traffic [1]. called content filtering, or WAF. A WAF applies a set of rules to each HTTP request and response. Generally, these Web access involving a CDN includes two steps: first, rules cover common attacks such as cross-site scripting (XSS) a user’s request is directed to a CDN server geographically and SQL injection. By customizing WAF rules, customers can close to the user; second, the CDN server obtains the content have their CDNs examine HTTP requests and filter out some for the responding to the request. The first step is called suspicious traffic before it reaches the origin website. request routing [2]. Commonly used request-routing techniques include URL rewriting and DNS-based request routing [2]. III. FORWARDING-LOOP ATTACKS URL rewriting requires website owners to change website URLs to use CDN-assigned subdomains that resolve to CDN Malicious customers of CDNs can deliberately manipulate servers. DNS-based request routing instead works by chang- the forwarding process (in the pull mode) to create forwarding ing the DNS resolution of website domains, either directly loops inside CDNs. Forwarding loops can cause CDNs to mapping to CDN server IP addresses, or using CNAMEs to process one client request repetitively or even indefinitely. The chain to CDN subdomains. These request-routing techniques consequent amplification effect allows malicious customers to usually determine the selection of edge (entry) server, but launch, with little resources and cost, resource-consuming DoS users can also override a CDN’s selection by directly con- attacks against CDNs. necting to a desired edge server using its IP address rather In general, as shown in Figure 1, before a CDN node than hostname [22]. Users can obtain CDN IP addresses forwards an HTTP request from a client, it checks the Host by resolving CDN subdomains via public platforms such as header of the request to look up any customer-specified for- PlanetLab [20]. We verified that this technique for overriding warding destination. The node then connects to the forwarding a CDN’s selection works for all CDNs in our study. destination and relays the request. In the benign case, the forwarding destination returns a response that is further relayed The second step, i.e., how the CDN server obtains the by the CDN node to the client. However, if an attacker requested content, also has two different modes: push and pull.