Cloud Security
Published in

Cloud Security

CDN Security Wishlist

One way content delivery networks make security harder

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! 😊

Teri Radichel

If you liked this story please clap and follow:

Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research

© 2nd Sight Lab 2020

____________________________________________

Want to learn more about Cloud Security?

Check out: Cybersecurity for Executives in the Age of Cloud.

Cloud Penetration Testing and Security Assessments

Are your cloud accounts and applications secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Cloud Security Training

Virtual training available for a minimum of 10 students at a single organization. Curriculum: 2nd Sight Lab cloud Security Training

Have a Cybersecurity or Cloud Security Question?

Ask Teri Radichel by scheduling a call with IANS Research.

____________________________________

2020 Cybersecurity and Cloud Security Podcasts

Cybersecurity for Executives in the Age of Cloud with Teri Radichel

Teri Radichel on Bring Your Own Security Podcast

Understanding What Cloud Security Means with Teri Radichel on The Secure Developer Podcast

2020 Cybersecurity and Cloud Security Conference Presentations

RSA 2020 ~ Serverless Attack Vectors

AWS Women in Tech Day 2020

Serverless Days Hamburg

Prior Podcasts and Presentations

RSA 2018 ~ Red Team vs. Blue Team on AWS with Kolby Allen

AWS re:Invent 2018 ~ RedTeam vs. Blue Team on AWS with Kolby Allen

Microsoft Build 2019 ~ DIY Security Assessment with SheHacksPurple

AWS re:Invent and AWS re:Inforce 2019 ~ Are you ready for a Cloud Pentest?

Masters of Data ~ Sumo Logic Podcast

Azure for Auditors ~ Presented to Seattle ISACA and IIA

OWASP AppSec Day 2019 — Melbourne, Australia

Bienvenue au congrès ISACA Québec 2019 KeynoteQuebec, Canada (October 7–9)

Cloud Security and Cybersecurity Presentations

White Papers and Research Reports

Securing Serverless: What’s Different? What’s Not?

Create a Simple Fuzzer for Rest APIs

Improve Detection and Prevention of DOM XSS

Balancing Security and Innovation with Event-Driven Automation

Critical Controls that Could have Prevented the Target Breach

Packet Capture on AWS

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Teri Radichel

Teri Radichel

Cloud Security Training and Penetration Testing | GSE, GSEC, GCIH, GCIA, GCPM, GCCC, GREM, GPEN, GXPN | AWS Hero | Infragard | IANS Faculty | 2ndSightLab.com