Supply Chain Defense
CDN Cache-Poisoned Denial-of-Service
“Life in the SOC” is a Blog Series that shares experiences of the BlueVoyant SOC defending against the current and prevalent attacks encountered by our clients. The blogs discuss successful detection, response and mitigation actions that can improve your defensive capabilities.
In the early days of the internet, one of the primary architecture challenges was the domain name system, or DNS. DNS is the protocol that takes easy-to-remember domain names (espn.com, google.com, etc.) and translates them into hard-to-remember IP addresses that are needed for internetworking protocols to work. As more systems came online, more requests were being made to resolve domains to IP addresses. Industry leaders recognized this potential bottle-necking and incorporated DNS caching to resolve the problem.
DNS caching is nothing more than having a number of relative subsystems that maintain temporary storage of information that has already been translated. As a result, each subsequent request does not have to access to the primary (authoritative) server responsible for that requested domain.
This idea spawned the concept behind content delivery networks (CDNs). CDNs work much in the same way as DNS caching does. But, rather than having one (or a group) of servers in one geographical location serving content to the entire world, CDNs employ a network of distributed servers in different geographical locations that can singularly make requests to the primary server(s) and then "mirror" or cache that content for subsequent requests. CDNs increase content delivery speeds, guarantee limited service in case the primary server goes down, and provides protection from large surges in traffic.
DNS caching became the target for cache-poisoning attacks, including DoS attacks. Threat actors are now targeting CDNs with the same attack methodology with CPDoS attacks. In these attacks, malformed requests are made that force a call back to the primary server for updated content that can be cached.
These malformed requests generate a server error response (i.e. 400 Bad Request) that is then cached at the CDN server before it is ultimately served back to the attacker.
The end result is that subsequent requests from other users for that same resource will now return the error response and the content could become inaccessible. This will continue to happen until either the CDN server is forced to update content from the primary server, or the cached content goes stale.
CDNs operate across large geographical locations and the error page generated by a CPDoS attack can reach multiple cache server locations. However, not all edge servers are affected by this threat. Some clients still receive valid pages from the origin server. In addition, some of the methods used to generate server errors fall outside the bounds of HTTP standards, so as long as CDN providers adhere to these standards, several of the methods for this attack will be rendered unsuccessful.