2013/10/16 18:41

0 x00 background

Hello everyone, we are OpenCDN team, focusing on the development and research of CDN technology.

First of all, in order to attack CDN, we must know the working principle of CDN. Here we will briefly introduce the working model of CDN.

CDN, which stands for Content Delivery Network, shields websites from malicious traffic and forwards normal traffic through accelerated node servers throughout the Network. In simpler terms, A CDN generally serves three purposes

1. Cross-carrier acceleration: Our own websites often belong to only one operator (e.g., China Telecom), and the acceleration nodes are spread across every operator, so that users of different operators (e.g., China Unicom) can access the site less slowly. 2. Cache acceleration: Many static resources and some pages are updated slowly (such as the home page). At this time, THE CDN will cache according to the max-age and last-Modified values of the browser and the preset values of the administrator. Therefore, a lot of traffic CDN nodes will not come to the website every time. CDN nodes can directly return hit cache content on their own. 3. Malicious traffic filtering: This is a very important role of CDN, which is also the reason why many websites use CDN, because CDN can resist large traffic attacks and ordinary attacks (such as injection), and only normal traffic will be forwarded to the website.Copy the code

Here are a few more nouns:

Source site: Our own site is called source site. Reverse proxy: The way that a CDN node requests data from the source station is called reverse proxy, also known as forwarding. Back source: The behavior of CDN node requesting data from source station is called back source.Copy the code

0x01 A journey of inquiry

We encountered some minor problems when we were doing OpenCDN testing. Find a website that nobody visits that has traffic and an amazing number of visits.

Our OpenCDN does reverse proxy checks every 2 minutes, but that only adds up to 720 visits. Where did those 4 million visits come from? Then we looked at the logs, and we saw that the logs For a single domain name reached 58 gigabytes. When we opened them, we found that the x-Forwarded-For field sent to Each domain name was X-Forwarded-For. So that the source site can get the real visitor IP after using the CDN instead of the CDN node IP) is flooded with a large number of existing IP, and all of them are local server IP. We instantly understood something and went to the management side to verify it. Sure enough, we accidentally set the source IP to the IP of the CDN node, but we didn’t realize it at the time. Therefore, such a large flow is also explained, because the detection of 2 minutes triggers the CDN node back source, and the source station of this site is the CDN node itself, so the CDN began to continue its own reverse proxy cycle, so that a request was infinitely amplified. If the HEADER times out or is too large (the x-Forwarded-For field overloads the HEADER), the request is discarded.

The source IP of the site is set as the CDN node itself, so that the CDN node can carry out its own reverse proxy loop, and then magnify the traffic.Copy the code

It seemed interesting, so the kids immediately went into action and did the experiment.

We successfully set the source IP to some CDN node IP to speed up for us on the security treasure, and then started Webbench on a small VPS in the US with 2000 threads to call this site (no matter which CDN node receives the request, the request will eventually converge to the innocent CDN node that is set up as the source). However, the experimental results were not ideal. The node did not break down. Through IP reverse search, we found a website that shared the same CDN node with us. Since we can’t collect performance data on this node of the security treasure, we can’t evaluate our attack. What’s more, we lack a control group in this experiment, whether the CDN node is stuck because the traffic is amplified by the infinite loop, or the 2000 thread itself can punch the CDN node.

So we summed up and guessed that the attack method of node reverse proxy itself might be applicable to such scenarios

You want to attack a CDN node, but if you hit a 404 page will not consume too much, and if you hit a site in the CDN, because the traffic will pass through, may not even knock out the CDN node, the site behind has been killed. At this time, if the node is allowed to carry out its own reverse proxy endless cycle, it will eat all the traffic and cannot spit it out. At this time, a certain amount of flow lever effect can be produced, which can make CDN nodes appear abnormal.Copy the code

However, the defense method of this attack is also extremely simple. As long as the source IP is set, the CDN node IP is not set. As long as the verification is added to the interactive input of the front end of the website.

We considered that we could not have a good evaluation of the bandwidth upper limit and performance upper limit of the CDN nodes that were not ours, and the black box groping might not bring anything, so we started with our own CDN nodes.

In the meantime, we continue to explore this idea. We found that since one node can loop indefinitely, how about two nodes? The results were positive and produced a qualitative change. We have a hypothetical scenario like this

Our opencDn. cc is registered with CDN provider A and CDN provider B, and then we get a CDN acceleration node 1.1.1.1 of CDN provider A and 2.2.2.2 of CDN provider B. And you must have figured it out. We set the accelerator node 2.2.2.2 with source station B in THE CDN service provider of A and 1.1.1.1 with source station A in the CDN service provider of B, and then A will ask B to obtain the source station, and THEN B will ask A to obtain the source station, so 1.1.1.1 and 2.2.2.2 are very happy and keep communicating ~Copy the code

So we did the experiment. This time we use the POST package for testing.

There are two reasons to use a POST package

1.CDN nodes will have a caching mechanism, just you request the address hit the cache, then directly returned, will not become an infinite loop, and the POST packet has a very good feature, absolute back source, no ambiguity. 2.POST packets can be expanded to make the effect more obvious with the same number of connections.Copy the code

In this test, we sent 500 POST packets, each about 10K in size. Then the total amount of traffic sent is 5M.

And then let’s look at what happens at the next two nodes

But it seems to be at the bandwidth limit. Because the machine in our hands is not very powerful after all.

Then let’s take a look at the effect of those 500 POST packages

58.215.139.124 RX bytes:5473847154 (5.0 GiB) TX bytes:17106340685 (15.9 GiB) RX bytes:6014294496 (5.6 GiB) TX Bytes :17717990777 (16.5 GiB) inbound 540447342(515MB) outbound 611650092(583MB) 112.65.231.233 RX bytes:5583125549 (5.1 GiB) TX Bytes :5022744608 (4.6 GiB) RX bytes:6133578284 (5.7 GiB) TX bytes:5649798353 (5.2 GiB) incoming flow 550452735(524MB) outgoing flow 627053745(598MB)Copy the code

Let’s take the smallest measure, which is about 100 times the flow, and then if you add up the inflow and outflow, it’s about 200 times the flow.

This type of attack has two advantages over the previous one

1. The CDN service provider cannot limit the source IP address for defense purposes, because it cannot know the IP address of other CDN nodes. 2. The CDN node of one CDN service provider can be used to call another CDN service provider.Copy the code

Then we also made some associations, a site can put two nodes into an infinite loop, what if more nodes come in?

We could do this. Let multiple CDN nodes and a CDN node cycle, the middle CDN node bandwidth exhaustion.

We could do this. Let the three CDN nodes in an infinite loop, if there is a limit on the inflow and outflow detection of traffic, so as to ensure that the inflow and outflow is not the same IP.

After all, the cost of adding a domain name to a CDN service provider is very small (free), we can string the nodes together with one domain name after another, and then snap and start the traffic loop.

Ok, let’s sum up the characteristics of this vulnerability in four words: leverage force to fight force.

0x02 Defense Method

So how do you defend against this and possibly evolving attack?

1. Do not set the source IP address to the CDN node itself (this is mandatory). 2. Limit the bandwidth of each site. 3. Limit the source sites whose requests time out. 4. Each layer is forwarded-to x-Forwarded-for. Each layer is automatically forwarded-to x-Forwarded-for.Copy the code

As well as a series of existing soft and hard defenses of CDN nodes, part of the attack flow can not be formed, and naturally, it can not form an infinite cycle shock.

This paper is only an idea of CDN traffic amplification attack, only some small-scale experiments have been done, and we welcome you to verify it. If there are inadequacies or logical errors please also put forward, thank you for your reading.

By OpenCDN member Jions 8000 Twwy.net