The idea of CDN traffic amplification attack

First of all, in order to attack the CDN, we must understand how the CDN works, here we will briefly introduce the CDN working model.

The full name of the CDN is the Content Delivery network, which forwards the normal traffic through the accelerated node servers throughout the network to ward off malicious traffic to the website. In simple terms, a CDN generally has three functions.

1. Cross-carrier acceleration: Our own sites often belong to only one operator (e.g., telecommunications), and the accelerator nodes are spread across each operator, so that users of different operators (such as Unicom) on the site will not be so slow to access them. 2. Cache acceleration: A lot of static resources and some of the page updates are slow (such as home), this time the CDN will be based on the browser's max-age and last-modified values and the administrator's default values to cache, So many traffic CDN nodes will not every time to the site request, CDN node can directly take the liberty to return the cache content hit.  3. Malicious traffic filtering: this is a very important role of CDN, but also many sites will use the CDN reason, because the CDN can protect us against the attack of large traffic attacks, ordinary attacks (such as injection, etc.), only normal traffic will be forwarded to the site.

Here are a few more nouns:

0x01 Exploration Tour

When we were doing the OPENCDN test, we had some minor problems. Find a site that no one has access to that actually has traffic and has an amazing number of visits.

Our OPENCDN has a 2-minute reverse proxy detection, but this adds up to a mere 720 times, and where does this 4 million visit come from? Then we looked at the log, found that the log of a single domain reached 58G, and opened it after the discovery of the X-forwarded-for field (X-forwarded-for mechanism is through a layer of agents to record an IP, Let the source station after using the CDN to obtain the real guest IP instead of the CDN node IP is flooded with a large number of IP, and all of this server IP. We immediately understand what, and then to the management side of the verification, sure enough, we accidentally set the source station IP as a CDN node IP, but we did not find. So the flow of such a large explanation, because the 2-minute detection triggers the CDN node back source, and the site of the source station is the CDN node itself, so the CDN began to constantly self-reverse proxy dead loop, such a request is infinitely magnified. The request is discarded when the timeout or header is too large (that is, the X-forwarded-for field causes the header to overflow).

The site's source station IP is set to the CDN node itself, allowing the CDN node to self-reverse proxy dead loop, and then amplify the traffic.

Seemingly a bit of meaning, the small partners then immediately action up, carried out the experiment.

We successfully set the source station IP to a CDN node IP for our acceleration on the security treasure, and then open webbench on a small vps of the United States with 2000 threads to hit this site (regardless of which CDN node receives the request, The request will eventually converge to that innocent source station CDN node), but the experimental results are not ideal, the node does not go down, through the IP back to a and we have a common CDN node site, through this CDN node reverse proxy access to the site, there is a lag and can not open the situation, only that. We cannot assess our attacks because of the inability to capture the performance data of this node of the security treasure. And our experiment is missing a control group, in the end because the dead cycle of traffic amplification caused by the CDN node lag, or the 2000 thread itself can punch the CDN node.

So we summed up the idea that the attack method of the node reverse proxy itself might be suitable for such a scenario

You want to attack a CDN node, but if you hit a 404 page consumption is not too much, and if you hit a CDN site, because traffic will penetrate past, may not have the CDN node knocked out, the back of the site was early penetrated dead. At this time, if the node to the reverse proxy dead loop, he will be all the traffic to eat, and can not spit out, this time may produce a certain amount of flow lever effect, can make CDN node anomalies.

However, the defense of this attack is also very simple, as long as the source IP is set, not to set up the CDN node IP on the line, as long as the site at the front end of the interactive input when adding a bit of verification on the line.

We consider that we are unable to limit the bandwidth of our CDN nodes, the performance limit has a good evaluation, black-box groping may not bring anything, so we take our own CDN node surgery.

At the same time we continue to explore this idea. We found out that since a node can loop, what about the two nodes? The results are positive and have a qualitative change. We're assuming a scenario like this.

Our opencdn.cc in a CDN service provider, and in the B CDN Service Provider Registration, then we get a CDN service provider of a CDN accelerator node 1.1.1.1, and then get a CDN service provider to accelerate the accelerator node 2.2.2.2. Then you must have guessed it. We put in a CDN service provider to set up the source station for the accelerator node 2.2.2.2, in the B CDN Service provider set up the source station for a acceleration node 1.1.1.1, and then a will ask B to claim the source station, B and ask for a source station, so 1.1.1.1 and 2.2.2.2 is very happy and constantly communicate up ~

So we also carried out experiments. This time we use the post package for testing.

There are two reasons for using the post package

1.CDN nodes will have a caching mechanism, just the address you requested to hit the cache, then directly return, will not become a dead loop, and the post package has a good feature, absolute back to the source, a bit unambiguous. The 2.POST package expands the volume and makes the effect more noticeable in the case of the same number of connections.

We sent 500 post packages for this test, each with a volume of about 10k. Then a total of 5 m of traffic is sent.

And then let's take a look at the two-node reaction.

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

And then let's take a look at the effects of these 500 post packages

We take the smallest to calculate, probably to increase the flow of about 100 times times, and then if the inflow and outflow added up is about 200 times times the expansion.

This type of attack has two advantages over the previous one

1.CDN provider can not restrict the source station IP to defend, because he can not know the other CDN node IP. 2. Can diehard, can use a CDN service provider's CDN node to play another CDN service provider.

Then we have some Lenovo, a site can put two nodes into a dead loop, if more nodes come in?

We can do that. Let multiple CDN nodes and a CDN node die in cycles, draining the bandwidth of the CDN nodes in the middle.

We can still do that. Let three CDN nodes die Loop, if there is traffic flow on the incoming and outgoing detection limit, this can guarantee that the inflow outflow is not an IP.

After all, in the CDN service provider to add a domain name is very small (free), we can use a domain name to string up the node, and then snapped to start the flow of the dead loop oscillation.

OK, let's use four words to summarize the characteristics of this loophole: by dint of force.

0X02 Defense Method

So how to defend against this and possibly evolved attack?

1. It is forbidden to set the source station IP as the CDN node itself (this is required). 2. Limit the bandwidth for each site.  3. Make certain restrictions on the source station where the request timed out.  4. Limit by x-forwarded-for, more than how many layers are automatically discarded.

And the CDN node already exists a series of soft and hard defense can let a part of the attack traffic cannot form, naturally also cannot create the dead cycle concussion.

This article is only a kind of CDN traffic amplification attack idea, just done some small-scale experiments, but also welcome the Daniel to verify. If there is a deficiency or a logical error please ask, thank you for your reading.

By OPENCDN members 8,000 twwy.net

The idea of CDN traffic amplification attack