Akamai Diversity
Home > Web Security > Bypassing Content Delivery Security

Bypassing Content Delivery Security

As is true of every year at Black Hat there are some talks that catch our attention. Talks range from the well thought out research papers to those of the narcissistic vulnerability pimps. This year was no exception. A talk entitled "Denying Service to DDoS Protection Services" by Allison Nixon is a presentation which fell into the well thought out column. This talk caught our attention for the obvious reason that we provide this as a service to our customers.

From Nixon's talk abstract:

Cloud based DDOS protection suffers from several fundamental flaws that will be demonstrated in this talk. This was originally discovered in the process of investigating malicious websites protected by Cloudflare- but the issue also affects a number of other cloud based services including other cloud based anti-DDOS and WAF providers.

You know what? Without hyperbole Nixon is absolutely correct. There are indeed issues with these types of services as we see highlighted in this article by Robert Westervelt. The flip side being that this is nothing new. The novel aspect in this case is that it has not really been openly discussed at length before now with a few exceptions such as the report from NCC Group. And kudos to Nixon for doing it. Some of the issues that were discussed were origin disclosure and configuration errors. There wasn't much thought given to compensating controls however.

The origin discovery issue is one that allows an attacker to bypass edge servers to access the origin systems. A key issue here lies with naming origin systems. Don't use easily guessable origin host names. This presents a problem wherein the attacker can guess the origin system DNS entry and simply bypass the controls. Attackers can leverage a host of tools to enumerate such as examining DNS for NS and MX records, guessing origin hostnames, network scanning and Shodan.

Next up is the use of pragma headers on pages served by a content distribution network vendor. This is a header that is added by the provider to provide a level of debugging where required. This can also be used by an attacker to design a DDoS attack. Some providers may even put origin system names in these headers. The upside here for Akamai customers is that they are not absolutely necessary for service operation and can be disabled is required.

What can be done for Akamai customers?

First off, non-standard names should be utilized in addition to having properly configured access control lists. This ACL's should include only Akamai system addresses so that non-authorized addresses can't query origin systems directly. Verbose error pages on systems can disclose far more information than a customer may intend which can inadvertently disclose origin systems.

How can Akamai help? We provide a service offering called SiteShield.

"SiteShield protects the origin by effectively removing it from the Internet-accessible IP address space, adding an additional layer of security protection while still ensuring that content is delivered quickly and without fail, regardless of end user location."

We can detect when an origin system is in trouble and then pull from a different origin hostname or even Cloud Storage. We can segment sites by ensuring that only the Akamai edge servers can query the origin systems. We can block access to origin systems. We've known about these issues since before 2002 and at that time we applied for and received a patent on the concept of website security.

By sheer virtue of the size and scope of Akamai's scale we can mitigate most threats to our customers at the edge.

Leave a comment