Tools Resources

Killing Cloud Security Misconceptions Part 1: Common Vulnerabilities and Exposures (CVEs)

Or Azarzar

Tuesday, Nov 17th, 2020

Background

The Common Vulnerabilities and Exposures (CVE) tells us the whole story just by its name – these are exposures and vulnerabilities that are common. But what happens when uncommon issues are discovered and exploited by attackers? What if attackers just want us to think they’d only exploit common issues and vulnerabilities?

Securing CVEs sounds like it should be the right place to start from. Exploring common vulnerabilities and exposure is where script kiddies start from, that's what bots are exploiting, and none of us want to end up in the security hall of shame, set aside for organizations that were exploited and affected by ransomware, thanks to an unpatched CVE from months ago.

The importance of remediating vulnerabilities in our environment is obvious. But are we misleading ourselves by thinking that remediating vulnerabilities on public assets will eliminate all threats? Starting from the perimeter often leaves a false impression that we are safe. It's easier to communicate such effort to managers than it is to harden a Linux base image with SELinux.

Yet since we all want that simple task marked off on our endless list of tasks, that’s what we do and where we wind up putting our efforts. But in reality does the fact that we don't have any CVEs (at the moment, anyway) mean we’re secure? I don't think so. Let's have a look at some reasons why this is the case:

Application Security

Application security starts with the opposite of the Common Vulnerabilities and Exposures, the Unknown issues. These issues are often discovered by various security testing methods (SAST, DAST, RASP, etc...) and are prioritized by the OWASP Top 10.

The business use case of having a web application or an API exposed to the internet applies to most of us. Web applications are our "crown jewel," and most of our defense strategy focuses on preventing them from being exploited.

Although customer databases are the "crown jewels, "penetration testers typically start their cyber security testing scenarios from the internet. We want their path to the crown jewel to be as long and circuitous as possible to minimize their chances of capturing the flag.

But isn't that exactly where they shouldn't be placing maximum effort? If the database is the crown jewel, that's where the penetration test should start. We put most of our security testing effort on web applications and then put the extra effort we have in that same place.

That's exactly how you end up with a web application without CVEs and that’s free of XSS (good for you!) but with a weak password, hardcoded in the config file, communicating in an unencrypted channel in the backend database.

CVE vs. Bug Bounty

Crowdsourcing manual security testing is a great thing. It’s a win-win for all sides. The white hat hackers end up being rewarded for their hard work, we eliminate unknown threats and vulnerabilities in our code, security is improved exactly where we want, and awareness regarding security is enhanced.

Compared to common vulnerabilities, most of which do not have a public exploit, vulnerabilities found in bug bounties are always exploitable--so why are we so afraid of going out publicly for bug bounties?

That's another misconception that remains a mystery to me. For some reason, organizations seem to think that remediating common vulnerabilities should be first, and bug bounties are a security concept to be saved for mature security enterprises.

Open Sources

While there are huge benefits that come with open source code, we can't overlook the fact that any developer can write a library which can be adopted by developers, without anyone ever noticing a security bug.

Luckily, the wild jungle of open source security has experienced a significant improvement over the last few years, wherein companies like Snyk have developed automated solutions to alert developers of common vulnerabilities in open-source libraries in use. That's a tremendous achievement for security owners, where security has shifted left and the responsibility for remediation is on the developers

Bypassing Your Perimeter

The career path that many information security experts have taken usually does not include being on the offensive side. I'm glad that I had the opportunity to spend a few years as an offensive researcher and white-hat hacker, and specifically after having been in security ops and engineering roles. That really changed the way I see things in cloud security.

The most important thing that changed for me is the idea of bypassing the perimeter. Like many, I thought that exploiting a common vulnerability or a zero day would be required to bypass the perimeter (but that's saved for nation-states or top APTs – or maybe that’s just another misconception). But my first two years in the offensive field taught me otherwise--there are just so many ways of bypassing that same perimeter that you put so much effort into. Whether it's done by using default passwords for exposed management interfaces or dashboards, using leaked credentials, taking advantage of servers left open without authentication, and so many other methods, there are so many ways to bypass the perimeter.

Secure From the Inside-out

Common vulnerabilities and exposures are simply the first step an attacker would take to penetrate your organization. Making this step harder won't stop them and won't prevent data breaches.

But instead of making the attacker’s life harder every step they take, it's just getting easier because we are securing from the outside-in and not the inside-out. The closer we are to the crown jewels, the less effort we put into security.

Moving Beyond CVEs

Let's imagine a world without common vulnerabilities, a world where the first asset, our public asset, is accessible for everyone, not just hackers, but everyone.

Randomly choose an instance in your cloud environment, not a public one, and review its security posture. You’ll probably find one of the following:

A role with risky permissions attached (FullAccess ones or Admin)
Security Group with 0.0.0.0/0 enforced
Unnecessary sudoers (usually in Linux)
Sensitive information in old files in the operating syste

Adopting a state of mind in which it’s understood that the first asset will always get breached would dramatically improve cloud security posture. It’s time to start approaching security from the inside-out, securing the crown jewels and making every element of configuration super-hardened. In this construct, the attacker would be the one who has to put tons of effort into moving forward or performing any lateral movement across the system.

Are you ready to take this mental leap and start seeing your environment through the eyes of an attacker? In that case, I’ve got loads of insights to share with you in future posts.

Schedule Demo

Get Started

Solutions

Tools

Resources