When migrating applications and services to a cloud environment, whether it be infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS), customers will very quickly discover the similarities and differences in how these environments are managed.
Let’s use virtual machines (VMs), or as Amazon Web Services (AWS) and Google Cloud Platform (GCP) call them, instances, as an example (I will call this type of resource a VM from here on out to save some confusion). The deployment of these resources can be quite different from building physical or virtual machines on-premises. However, the maintenance of the systems differs minimally, if at all, as we often use management tooling which can leverage secure shell (SSH), remote desktop protocol (RDP), or Windows remote management (WinRM). This brings us to another subtle difference: how to connect to these systems over a network. This requires the end user to understand cloud networking, which, as you will see shortly, is well understood. But is the security of these connections understood? That remains to be seen.
Shodan is a tool that is primarily used to search scan results of internet-facing devices. From an attacker’s perspective, this is fantastic as Shodan is the one performing the work of scanning for alive systems, determining which ports are listening, which services may be listening on those ports and even provides screenshots of login pages and video stills of IP-enabled cameras. This allows the attacker to avoid early detection as, if they were the ones performing the scan, this could easily make their presence known. Of course, security teams can leverage this service as well to see what the world can likely access directly and address any concerning findings before an attacker can take advantage.
Let us do a simple search in Shodan to look for overly exposed systems. As we see in Figure 1 below, a search conducted on Nov. 6, 2023, is simply looking for well-known management services ports (SSH, RDP, WinRM over HTTP and WinRM over HTTPS). Shodan unveiled a considerable number of systems (32,299,678 to be exact) listening on those ports (22/TCP, 3389/TCP, 5985/TCP and 5986/TCP, respectively). If you look closely at the Top Organizations information, you will see that the top five vendors consist of either cloud service providers (CSPs) or internet service providers (ISPs).
Does this mean that CSPs and ISPs are unwilling or unable to protect customer systems? The most likely answer is “no.” What this most often means is that the customers in those environments who can lock down their management communication to an appropriate audience (i.e., not the entire internet) are not doing so. This could be due to ignoring CSP or ISP environment security best practices.
Cloud attack techniques
Now, we’ve seen these types of flaws before. In fact, most compute-related security issues remain when migrating from an on-premises environment to a cloud environment. However, the cloud introduces a whole new world to attackers full of many new capabilities that allow them to deploy and manage resources.
Luckily, there is an online repository you may be familiar with, MITRE ATT&CK, that tracks common attacker techniques (and much more information regarding real-world attack groups). You can even find this information compiled into matrices in the repo. These matrices include column headers indicating the types of tactics employed by known attack groups. In other words, tactics are what the attacker is attempting to accomplish during their campaign — there are often multiple tactics in the same campaign. In each tactic column, a variety of techniques and sub-techniques which are used to achieve the desired tactic are listed.
There can be (and are) hundreds of techniques and sub-techniques (I will just call them techniques moving forward to keep things simple) that can be employed given an appropriate environment. With just a simple list of techniques, it can be hard to identify, without a ton of research, which techniques may apply in each type of environment. Fortunately, MITRE has created multiple matrices — one for each common environment or technology deployment — like the Cloud Matrix as shown in Figure 2 below.
If you spend any amount of time looking over this matrix, you will quickly realize there are many techniques that are nearly identical attacks against both on-premises and cloud targets. Let us look at a few real-world examples.
What’s old is new: Background and sample attack
Authentication attacks are interesting as they wildly depend on what the attacker is trying to successfully access as a legitimate user. One approach can be to log in to a cloud resource’s management service (e.g., SSH on a Linux VM). So how would this attack look in a cloud environment? Spoiler alert: the same as an attack against an on-premises system.
Hydra is an attack tool specializing in attacking login services like SSH, RDP and web application login pages, to name a few. I have deployed a Linux system in Azure with the SSH service overly exposed so the attacker can see it (let us assume they either did some active reconnaissance using a port scanner like Nmap or maybe even “outsourced” this work to Shodan where they found this system). You can see that it was overly exposed by taking a look at the network security group (NSG) configuration for this VM in Figure 3.
The vendor I chose does not matter as it is up to me to lock down these types of management ports to only my expected audience like administrators and engineers. In fact, as you can see in Figure 3, Azure is trying to help by placing a warning icon (the yellow triangle with an exclamation point inside of it) to grab my attention and tell me this may be an unintended rule. Let’s see how Hydra can take advantage of this all-too-common misconfiguration. NSGs in Azure, security groups and network access control lists (NACLs) in AWS, and VPC Firewalls in GCP are used to allow or restrict traffic at layer three and layer four of the open systems interconnection (OSI) model. Layer three refers to the network layer so, as it applies here, we are concerned about IPv4 or IPv6 addressing. Layer four refers to the transport layer, and this is our attempt at locking down the transport protocols in use and the port numbers used over these protocols (for example, 22/TCP which is the well-known port for SSH — the application protocol).
As you can see in Figure 4 above, with only a properly guessed username and a list of candidate passwords (in which my password was on this list), Hydra identified a pair of valid credentials for the attacker. Yes, I know that is a super-weak password, but this was an example of just how easy it can be to discover valid authentication information. Besides, can you confidently say none of your systems administrators are using weak passwords?
How to defend against these attacks
The defense against these types of attacks in a cloud environment are remarkably similar to protecting any management service. Some things that come immediately to mind are producing methods to restrict users from creating weak passwords. Password policies implemented on your Windows, Linux and macOS systems can be extremely helpful here and there are even benchmark guides provided from security-focused providers and vendors that can come in handy to help implement and enforce these policies. For example, the Center for Internet Security (CIS) provides benchmark guides for most mainstream technologies ranging from operating systems, applications, cloud vendors and even printers.
Even with strong password policies in place, we really should focus on using multifactor authentication (MFA). This requires an attacker to not only successfully acquire credentials (something you know) using active authentication attacks or credential stuffing (i.e., using already stolen credentials to access another application with the same credential pair) but to also provide either something you have, like an authenticator application on your smartphone or hardware token or something you are like a biometric as that makes you “unique” to another person.
The next logical step to limit an attacker’s opportunity to attack or access these management services is to restrict network access to trusted sources. Here is where the big differences come into play when implanting these types of networking controls in cloud. Since cloud contains the built-in services mentioned before, there is a learning curve to ensure these services are configured properly to address these concerns. As vendors want to make it “easy” for customers to get their VMs up and running, default rules can be the cause of these over-exposed systems. For example, when deploying a Linux system in AWS, Azure or GCP, the vendor will populate an SSH rule that is exposed to, at least, the entire IPv4 internet. Customers should be aware of this (and you are now, so no excuses) and make the necessary adjustments to limit access to only expected sources.
What did we learn about cloud attacks?
In this first blog post on cloud attacks, we discovered that some of the tried-and-true methods that attackers use when attacking on-premises systems continue to work just fine when targeting cloud workloads. In fact, we as a community are making it easier on attackers as there is a learning curve when migrating your security efforts into a cloud environment.
Read Part 2: Cloud Attacks: What’s New Is New where I discuss novel methods used by real-world adversaries when specifically targeting cloud environments and resources.
Original content can be found at SANS.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
