Security: CDNs and larger scale Tactics #4
Welcome back my Virus infected Reader,
We hope that you enjoyed our “walk in Attack Vectors Park” last time episode, where we explored some of the evergreen tactics and strategies to harm a destination Host in a Cloud environment; today we’ll bring this one step further and introduce Content Delivery Networks in the Cloud Security equation.
Please only expect some general concepts around how do Content Delivery Networks cloak an Origin Data Center behind thousands (sometimes hundreds of thousands) of “Edge” Servers, and how does this directly affect the way crooks come to exploit you. We could spend entire books on today’s Subject and in time we possibly will; today’s an introduction to the theme of CDNs and Security and as such, we’ll try to lay the foundations of further, more advanced Articles to regard.
To begin with, let us once again take a step back and see what a CDN is, what a CDN does, and how – and to which degree – does a CDN protect your Origin Server environment.
What is a CDN
Content Delivery Networks (CDNs), our specialty “after all”, play a very important role in distribution of content over the Internet worldwide. The interaction between a user and content online is by far more complex nowadays that it was just a few years ago. Today, users are very likely to stream long videos
or access a SaaS portal whilst working from home. This is a far more complex – and resource consuming – experience that didn’t exist (to such a scale) just five years ago. Considering the exponential growth of the CDN Market year over year since its birth, this Article should really come in handy and lead you straight into the basics of CDNs and CDN Security issues.
A Content Delivery Network is designed to improve the Availability, Security and Performance of a Website. Since the beginning of the Internet, delivery of content to the end users has evolved. We always like to distinguish between “static” and “dynamic” content when it comes to it.
Static content of a standard Webpage would be a profile picture, its description and HTML text that very rarely change. Dynamic content instead represents content that is constantly changing and moving. The growth of dynamic content distribution, such as in Twitter, is pushing the CDNs forward at unprecedented pace.
How does a CDN work
A CDN has Points of Presence (PoPs) or simply put – Data Centers spread all around the world. Each PoP has tens, hundreds or thousands of Servers connected to each other – and to the WWW. Together, the PoPs and servers help speeding up the process of content delivery to the end user.
The picture below (picture 1) is a representation of how a Webpage would work without a CDN. An end user requests a page, but all the components of the page HTML code, images, dynamic content) are retrieved from the Origin Server where the site is hosted, which could be anywhere on the planet. In the picture rovided, you can see the user from North America requesting content from all across the globe, which makes his/her experience painfully slow.
In picture 2 we can see a representation of how a Webpage is delivered using a CDN. A CDN puts all files in the local PoP an End User is connected to.
As a result, when End Users request a page, it is delivered – and loads – much faster. If the CDN doesn’t possess an image or file requested by the End User, it will retrieve it from the Website’s Server of Origin as needed.
CDNs for Dynamic sites (such as Twitter) are somewhat different. CDNs that support dynamic content create a “super fast highway” to speed up the delivery of content across long distances. Single ISP cannot provide this. In Picture 3 you can see the “super highway” enhancing the delivery of dynamic content from the Origin Server to the End User.
A Public Content Delivery Network (CDN) is a shared Infrastructure deployed over the Web for highly efficient delivery of Web content to the Internet Users. By providing vast resources among billions of different Customer Websites, a CDN possesses the economy of scale: due to the fact that different Sites experience so-called demand peaks at different times, the same capacity can be used to cover unexpected jump of demand for various Websites.
Most CDNs use Domain Name System (DNS) to redirect End Users to the so-called Edge Servers controlled by the CDN instead of the Website’s Origin Server. The DNS controlled by the CDN selects the best Edge Server for the User and then responds to his/her request with the selected Server IP Address. The basic mechanism is presented in picture 4.
The Components of Edge Server Attacks
Penetration through Edge Server for attacks isn’t really easy, and the attack itself is quite complex, too. In this section we’ll describe the key mechanisms and methodology used to compose these attacks.
Harvesting Edge Servers
CDN Edge Server discovery is based on resolving Hostnames of URLs delivered by a CDN from a few Network Locations. Hackers can use Botnets for this purpose. Within just a couple of hours it’s possible to discover entire portions of Network of Servers and prepare to launch an attack.
We would like to point out that while some CDNs expose actual IPs when resolved on a DNS level, and therefore are subject to above, some other CDNs instead offer so-called VIPs , or Virtual IPs, which by means of Anycast then resolve the connection to a Backend, internally translated , Server. Above harvesting tactic doesn’t apply to the latter.
Bypassing the CDNs Edge Server selection DNS mechanisms
After gathering an extensive list of Edge Servers for the attack, the Attacker needs to submit HTTP Requests to these servers from the same attacking Host, overriding the CDN’s Server Selection mechanism we mentioned for this host. Simply put, the Hacker needs to bypass DNS lookup, which means he/she needs to connect to the Edge Servers through direct use – “spoofing” – of IP Addresses rather than the dynamically DNS resolved Hostname from the URL. To trick Edge Servers into processing the request, it is sufficient to include HTTP Host Header which is later submitted together with a request with use of the proper DNS Hostname. Failure to do so generally resolves in a HTTP 400 – Malformed URL Response from the Server.
Penetrating CDN Caching
The most important component of the attack is to force the Hacker’s HTTP Requests to be processed by the Website Origin Server rather than the Edge Servers Caches. Usually, requesting a cached object on the Edge Server to refresh and pull from the Origin Server could be done by using HTTP Cache-Control Header, although a proper set of Response Headers can prevent this.
Amplifying the Attack
So, we showed that manipulation of the CDN Edge Server to download the file from the Origin Server, disregarding the content in its cache and – by doing so – penetrating the CDN’s protection layer of a Client’s Website against a DDoS Attack is possible. But what about recruiting an Edge Server to consume Bandwidth resources from the Origin Site without using much of the Hacker’s resources? By using completely independent Connections for decoupled File transfers, this is entirely possible. This is “naively” justified by the CDN’s huge desire to have files available in its Caches for any future request as soon as possible. Unfortunately, this can pose a serious Security threat.
A Burst Attack
A CDN can try – many as a matter of fact do – to employ Data Mining (also called “scrubbing”) over the incoming Requests to detect and block attacks. This protection is far from perfect, mainly because it takes time to spot and prevent attacks. Per example, if we send a one-time burst attack of, let’s say, 100 Requests to a number of Servers. This will be noticed, without any doubt. In our experiment, only around one third of all Requests successfully reached the Victim’s Webserver. That allegedly sounds quite good (“what a good Offload!”), but in reality, these Requests caused quite a lot of damage. A single Burst attack can have a long-lasting effect on the Victim’s Website. By conducting repeated attacks from random Botnet controlled Computers at random times, the crook can cause interrupted Availability and diminish Performance of his/her Victim’s Website.
A CDN, as mentioned, usually consists of a large number of Servers all across the Web. This enables them to offer their Customers huge Capacity “on demand” as well as improved End User experiences. Finally, a CDN should protect itself and the data stored on it as well as a Website’s Origin from possible intruders and Hackers. The most common threats to the CDNs are various types of DDoS attacks. A CDN has good techniques for detection, prevention as well as mitigation of various forms of DDoS attacks. HTTP Load Balancing, “always-on” approach and detection systems monitoring for suspicious behavior are just some of the preventive measures used by CDNs.
Historically, protection from the DDoS Attacks offered by CDNs is on the Application Layer (7); of course, many CDNs are now also offering Solutions to defend from Volumetric Attacks on Layers 3 and 4, but this will be discussed in future Articles.
In an Application Layer attack, the attacker sends normal Requests to the Server with the intention to consume resources which should be used to satisfy End Users’ Requests. These types of attacks are especially dangerous because they are often very hard to differentiate from legitimate Requests. Due to the fact that CDNs have much more “raw” resources than the average attacker, CDNs simply absorb DDoS Attacks without any effect on the End User experience for their Client’s Websites.
On the other hand, CDNs can be misused to amplify the DDoS attacks. DDoS attacks can make so that the CDN uses its own bandwidth, thus showing a very low request rate from the attacker. Because the rate is so low, it cannot be spotted by superficial Data Mining (or “scrubbing”). The only option to detect these sneaky attacks is to have CDN centralized Data Mining capabilities. This requires a transfer of large amount of data, in real time, to the central location, which might be a bit difficult. Even with real-time centralized Data Mining (a Feature the most robust CDNs offer), the crooks can use Botnets and Requests for always different Assets to make things more difficult to detect.
In a nutshell: everything is connected nowadays. In this article we have tried to explain how do CDNs work as well as some of their weak spots. As you can see, CDNs not only may not be able to protect their Clients from a DDoS attack (if not properly setup), but they can even be used to amplify the attack. Content Delivery Networks have an important role in the modern Internet Infrastructure. The use of CDNs is growing at a fast pace, and Vendors are increasingly very young Entities. We hope that all CDN Players will be keep up with fixing Vulnerabilities (only to discover more as we move forward in the WWW) and provide safer, faster and better End User experiences for all of us. Share your story!