We’re beginning to hear more about content distribution network (CDN) providers burnishing their offerings with WAF-like capabilities. While it appears to address some of the concerns raised in Radware’s recent “2011 Global Application & Network Security Report,” there are some misconceptions of what CDN providers and other cloud security providers actually might be able to protect. Most cloud security providers and CDN providers miss a number of key issues.
Before I get into some of the more detailed and nefarious exploits Anonymous, AntiSec, LulzSec and the other hactivists have been using, I have a couple of simple questions:
- Do you have PCI or HIPAA compliance requirements?
- Who thinks it’s a good idea to give away their private SSL keys to some third-party company?
- What happens when they get compromised?
Defeating the CDN or Cloud security provider is as simple as attacking the target over SSL. SSL is a secure tunnel that hackers like to use to mask their behavior.
Some large CDN providers have over 35,000 caches distributing content. They use a “map” for most companies in a parent-child relationship. For example let’s say I have a Seattle Datacenter with a web server. My IP address is 188.8.131.52 and it maps to http://www.davidhsite.com. The CDN provider would then map 10-15 parent caches that would fetch from the origin server(s) that are nearby my datacenter. Then, the 35,000 caches would feed from those 10-15 parent caches.
Now, if Anonymous knows that my IP is at 184.108.40.206, what prevents them from just attacking my origin server? You may think, “We’ll just block the world at the firewall and only let our CDN provider’s Map in.” OK, how do you test your site? What if your CDN provider is introducing a bug?
Remember my blog post on Using CDN’s as a Weapon for DDoS? Those 10-15 parent caches would have to KNOW EVERY URL to whitelist the site against a random application attack.
Here’s another example: Go to each of the 35,000 nodes with your script, do a ‘get’ for:
Random[5-27 length ,a-z,0-9].html, pragma no-cache, cache-control: no cache.
That still allows you to execute a DDoS attack tool on the site very easily. About 35,000 edge caches can easily overwhelm the parent caches as well as requests to the origin server.
Next, if we understand the services of the CDN provider, one could potentially abuse their systems by manipulating their custom headers and who knows what kind of mischief Anonymous could use with some of these:
Pragma: cdnprovider-x-cache-on, cdnprovider-x-cache-remote-on, cdnprovider-x-check-cacheable, cdnprovider-x-get-cache-key, cdnprovider-x-get-extracted-values, cdnprovider-x-get-nonces, cdnprovider-x-get-ssl-client-session-id, cdnprovider-x-get-true-cache-key, cdnprovider-x-serial-no
We have seen these kinds of attacks recently in some high-profile and high-visibility attacks around the world. While there is plenty of value from the CDN providers and edge caching services, you should know what they can and cannot do. DefensePro® from Radware will help you with attack mitigation on your site. We all know hiding behind a cloud is just an illusion for serious security.