Cloud-specific Vulnerabilities – CompTIA Security+ SY0-701 – 2.3

An application in the cloud is susceptible to many different attack types. In this video, you’ll learn how denial of service, authentication bypass, directory traversal, and other attacks can be used against our cloud-based applications.


In a relatively short period of time, companies have really embraced the cloud. And today, practically every organization has one or more applications that they run in a public cloud. But of course, along with these applications, we’re putting a great deal of data into the cloud as well. These applications are often accessing sensitive data, and it’s important that we find ways to maintain security for all of these cloud-based applications and their data.

Unfortunately, we’re not always using the best practices for security to protect these systems. For example, it’s estimated that 76% of organizations aren’t even using multifactor authentication to log into the central console for their cloud-based systems. And we’ve also found that up to 63% of the code that’s in the cloud is currently unpatched.

These are not minor patches either. These are significant security concerns. And in some cases, these vulnerabilities have a Common Vulnerability Scoring System, or CVSS, that is greater than or equal to 7 on a scale of 10. If you have an application that’s in the public cloud, then anyone in the world would be able to at least attempt to connect to that particular application. That is the point of putting your applications in a public cloud.

Unfortunately, this also means that anyone in the world could try to disable that application through a Denial of Service, or DoS. This may also be a Distributed Denial of Service, since it could be done by many different devices simultaneously anywhere in the world. We also have to think about the authentication method that’s used to allow access to the application and this data.

If we have a weak process for authentication or we’ve misconfigured the authentication process to allow people in this application without the proper credentials, this could cause a significant breach of data. When you have anyone in the world that’s able to connect to an application, you have to make sure that the configurations are set properly for the app and for the security surrounding that application.

One common misconfiguration we often see with web servers is the ability for people to manually move around the structure of that web server into different folders or different subdirectories. We refer to this as directory traversal, and it’s something that should not commonly be allowed. And of course, if a system is unpatched, an attacker may be able to take advantage of vulnerabilities existing for that application or operating system. And it may be very easy for them to run a remote code execution and effectively run any application they’d like on your cloud-based system.

Not only do we have to make sure that our underlying operating systems and other components in the cloud are up to date, we also have to make sure that our applications have been properly patched. There have been cases where an attacker has taken advantage of an application vulnerability to then gain access to the system underneath and then other systems within that same cloud.

A good example of this are the vulnerabilities we found in recent years with Log4j and the Spring Cloud Function. These are very easy to exploit. You don’t need a lot of knowledge in IT security to be able to take advantage of these vulnerabilities. And because you effectively have full control of the system afterwards, the rewards for running this exploit are very extensive.

If the application developer has not properly provided input validation for the fields in this application, this could be a case where cross-site scripting is used by an attacker to gain access to this system. Attackers might also try to take advantage of an out-of-bounds write. This is when they’re able to write information into memory even though that section of memory is unauthorized to that user. This might allow the attacker to run a remote code execution or to simply crash the system and make it unavailable for others.

And of course, if the application is in the cloud, then the data itself is also in the cloud. So the attacker may try to take advantage of code injection, such as SQL injection, to be able to gain access to the data that’s in that database.