CDN Security Wishlist
One way content delivery networks make security harder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Network Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Content Delivery Networks serve an essential purpose. They help improve the performance of your website by pushing content closer to the end-user. Some of the services also provide a mechanism to prevent distributed denial of service (DDOS) attacks that can take down your systems or networks.
That said, there is one aspect of CDNs that has bothered me for a while and finally got the chance to write about it. The big, popular CDNs are so widely used that pretty much every organization on the planet has to open up access to and from their network for these services. That, in and of itself, is not the problem. You could allow access to and from a CDN IP range such as this one for Akamai, which you can lookup on ARIN.
The real problem is that when someone connects to a service on one of these CDNs, it is difficult to tell what the originating website was that caused the user to make that request. It is also challenging to know if the traffic is or is not from the intended source.
Take Microsoft updates, for example. One of my security instructors who does on-premises penetration testing said the way he always gets in on a pentest is via a tool that lets him hijack Microsoft software updates. Then he can deploy some malicious packages instead of the real Microsoft updates.
So I kick off Microsoft updates, and what do I see in Wireshark? A whole bunch of Akamai IP addresses for that range I just posted above. Attackers love to hide their dirty work in CDNs. How do I know if that’s a legitimate Microsoft update or not?
What if I do a dig -x on that IP address? That is not helpful either as it only gives me back the general Akamai information.
I presume my localhost will validate the packages, but what if my host is the source of the compromise? That won’t do me any good now, will it?
Ok, what about when I’m visiting one of the myriads of sites that leverage AWS CloudFront. In that case, I’ll see something in my logs like this and have a similar scenario. I have no idea what website is related to any of those requests based on what I can see in my logs. The tool I use to block unwanted websites is useless because it can’t tell which site I’m visiting via AWS CloudFront.
Perhaps the initial connection for an TLS certificate gave me the correct domain, at which point I could reject or deny that particular connection and the subsequent CloudFront connection. But what if subsequently, I have a security incident and want to go back to my logs and figure out what happened? I can probably do it, but it gets more complicated. What if an alternate website now uses the domain above due to redeployments? I may have already allowed the domain name in my firewall rules, and now traffic to a website name I didn’t authorize is permitted as a result. That is why a super paranoid security nerd such as myself, might only allow connections for a short time before re-validating.
I was not aware that the day after I published this, a talk would come out at DefCon on domain hiding using the SNI extension of TLS. The presentation introduced a new tool called Noctilucent. And immediately, China blocked it.
How could this scenario be improved? With all the software-defined networking and short TTLs in existence today, can’t the CDNs somehow return the domain name for the website or company the CDN is fronting or the company that is serving the content? I’m sure it’s complicated and hard — just like packet capture in the cloud was hard. But the cloud providers figured out how to do it.
So please add this to my wishlist for all CDN providers. When I am using network tools or looking up DNS records, I want to see the domain the IP is fronting or the company leveraging a CDN connection, so I know the real source of the content. I want my network tools to be able to block the original source if I choose. Thanks! 😊
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2020
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
