What’s Lurking in Your CDN?

I was able to get to DerbyCon V this year for the first time – an annual conference founded by David Kennedy that is held at the end of September in Louisville, KY.  One of the talks that I attended was also given at Blackhat 2015, “Bypass Surgery – Abusing Content Delivery Networks with Server Side Request Forgery, Flash, and DNS” by Mike Brooks from Bishop Fox and Matthew Bryant from Uber.

A lot of background material was covered to get attendees to the point that they could understand the fairly complicated exploit chain they developed. So, if you find yourself getting lost by my explanation or if you’d like more detail you can see their whole DerbyCon talk on YouTube.

The material covered was fairly specific to one exploit chain, but in my mind, I boiled down the material to be a bit more generic. In order for websites using Content Delivery Networks (CDNs) to function, they have to trust the CDN and include them in their same origin policy. So, if executable content is being cached by the CDN (flash, applet, etc.) it might be possible to inject code and get the CDN to retrieve content from the origin site on behalf of the attacker. This is both a Server Side Request Forgery (SSRF) attack and violates the same origin policy. In essence, an attacker can use your CDN against you!

Mike and Matthew gave a specific example of a flash-based web video player called FlowPlayer. The FlowPlayer team created their own URL parser as part of the player. This sounds easy on the surface, but the rules of parsing URLs are actually more complex than you’d think. Because there were bugs in the URL parser, they found several ways to include arbitrary code. The code is retrieved from another site of their choosing, but looks like it’s coming from the destination domain. As it turns out, FlowPlayer has no plans to fix this issue since Flash is going away (by popular demand) in favor of technologies like HTML5. So, sites that continue to use the flash-based FlowPlayer will continue to be vulnerable.

When looking for websites where the vulnerable FlowPlayer versions were used they found an older part of a major provider’s CDN that had multiple versions cached. The way this CDN works, URLs for objects converted so that requests can directly address specific objects on the CDN. The first part of the resource locator might be something like xyz.legitbank.com so it appears that the request is to an object at legitbank.com, but DNS sends the request to the xyz host on the CDN instead.

In the exploit chain example they gave:

1. A user logs into Legitbank to do their banking and creates an authenticated session. Even if the browser tab is closed the session is still active from the server perspective (unless the user actually logged out!).
2. The next step might be kind of hard, because the user has to be directed to the attacker’s website somehow. This step would probably rely on spear phishing, search engine optimization, or social media to direct traffic to them.
3. The attacker site calls the resource locator for the Legitbank hosted application (in this case FlowPlayer). That application is then retrieved from the CDN and run in the Legitbank.com domain origin space.
4. The attacker injects external code into the application so it can make requests to Legitbank.com without violating the same origin policy. That means it can use the session that was established by the user.
5. Raid bank account. Profit.

To prevent this type of attack one has to make sure that the same origin policy on the origin server is as specific and wildcard free as possible. Limiting the types of content cached by the CDN and performing security audits, code review, and perhaps pentesting on any executable content that can be cached is now important too!