When it comes to cybersecurity, Remote Code Execution (RCE) might sound complex, but in essence, it's a straightforward concept with profound implications. Among the myriad of security vulnerabilities, RCEs are particularly alarming due to their high impact and the severe damage they can cause. A prime example of such a vulnerability is the infamous Log4j flaw, which shook the cybersecurity world by demonstrating just how widespread and dangerous these exploits can be.
In this blog, we're focusing exclusively on RCE within the AWS cloud environment. Our aim is to explain what an RCE is and guide you through a real-world scenario where Metasploit, a widely used tool by security professionals for deploying exploit code against a target, plays a crucial role. You will gain a deeper understanding of RCE through a hands-on example. Furthermore, you will recognize the vital necessity of protecting against such vulnerabilities in your cloud infrastructure, as they can result in extensive damage and expose your systems to significant risks.
At its core, RCE refers to the ability of an attacker to run arbitrary commands or code on another person's computer or server, typically over a network. This means the attacker can take unauthorized actions on the targeted system, from viewing confidential information to taking control of the system entirely, all without needing physical access.
RCE vulnerabilities are often hidden in the software we use every day, lying in wait for an attacker to exploit them. These vulnerabilities can stem from various sources, such as flaws in web applications, operating systems, or even the frameworks and libraries that developers rely on to build software. When these vulnerabilities are discovered and exploited, they can have devastating consequences.
One of the most talked-about examples of an RCE vulnerability is the Log4j vulnerability (CVE-2021-44228), which impacted millions of devices worldwide and highlighted the pervasive risk of RCE in modern software ecosystems. This vulnerability allowed attackers to execute arbitrary code on affected systems by manipulating log messages, demonstrating how seemingly innocuous components can become gateways for malicious activity.
In the context of cloud environments, such as AWS, Azure, and GCP, RCE vulnerabilities take on an added dimension of risk. Cloud infrastructures often host multiple services and applications, interconnected in ways that can amplify the impact of a single compromised instance. Understanding how RCE works, and the forms it can take in different environments, is the first step in fortifying defenses against these insidious attacks.
EC2 instances in AWS offer multiple points of entry for attackers. Tools like Nmap and Shodan are commonly used to scan for these instances, revealing their public IPs and any open ports or services that may contain vulnerabilities.
Once a vulnerability is detected, attackers use Metasploit to exploit it, creating a shell on the EC2 instance. This grants them control over the server. From there, they can misuse the instance's IAM role, modifying trust policies of privileged IAM roles or creating new access keys, facilitating deeper cloud environment infiltration.
This overview shows how attackers identify AWS instances and exploit vulnerabilities to gain control.
After identifying a target EC2's public IP address, the attacker conducts a targeted Nmap scan as part of a reconnaissance operation to find open ports and gather information on the target system specified by the IP address. The output reveals that the EC2 instance is running an FTP server daemon, 'vsftpd 2.3.4', known to have vulnerabilities, and the EC2 instance allows for anonymous FTP logins. Both findings are concerning.
Figure 1 - Attacker performing nmap scan on a target instance
Uptycs security insights: Our system proactively identifies the 'vsftpd 2.3.4' version as vulnerable to RCE attacks. By monitoring system configurations and software versions in real time, Uptycs flags this specific version of 'vsftpd' as a security risk. Following detection, we offer detailed remediation advice to address and secure the vulnerability, helping to protect your cloud environment against potential exploitation.
Now that the attacker has determined the target EC2 instance is running vsftpd, they search Metasploit for any matching modules that can be used to perform the RCE against the target EC2 instance. Metasploit returns two matching modules, one of which has an 'excellent' rank. The attacker then selects this module and initiates the RCE exploit.
Figure 2 - Attacker using Metasploit to initiate the RCE and create a reverse shell
Uptycs security insights: Our system is designed to identify unusual network patterns, including the initiation of a reverse shell connection, which is a common indicator of a compromise. Upon detecting such activity from the target instance, Uptycs alerts security teams immediately, providing them with the specific details of the suspicious connection. This allows for quick investigative and remedial actions to counteract the exploit attempt and secure the compromised instance.
After executing the RCE, a reverse shell is established. The attacker then creates a pseudo-terminal on the new shell and confirms its success by displaying the public IP of the target EC2 instance (x.x.x.165):
Figure 3 - Attacker now has a shell on a target instance and begins the next phase of their attack
Uptycs security insights: Our platform captures and visualizes the entire sequence of actions following the establishment of a reverse shell, including the creation of a pseudo-terminal. By displaying the complete process tree and every command executed within a comprehensive detection graph, Uptycs provides deep visibility into the attack's progression. This level of detail empowers security teams to understand the scope of the breach, trace the attacker's steps, and implement precise countermeasures to prevent further unauthorized access or damage.
The attacker copies their scripts—'script1of2.py' and 'script2of2.py'—to the target instance. The first script identifies the attached role and requests a session token from the EC2 Instance Metadata Service. It then uses this token to retrieve and save the credentials for the identified role to a file on the local filesystem. The second script retrieves the saved role credentials from the file, establishes a session with AWS, and uses that session to create an IAM user named 'BAD'. It then attaches the 'AdministratorAccess' policy to this user and generates an access key for them.
At this point, the attacker has successfully executed an RCE against the target instance, creating a reverse shell, and leveraged the available permissions to create a backdoor. This illustrates how an RCE can lead to a wider blast radius within a cloud account.
Figure 4 - Attacker is able to create a backdoor into the account by creating a new user and access key
Uptycs security insights: Our platform is designed to closely monitor the use of the EC2 Instance Metadata Service (IMDS), specifically identifying and alerting on unusual access patterns. When an entity other than the expected AWS Systems Manager (SSM) agent invokes IMDS—such as in the execution of unauthorized scripts for token retrieval—Uptycs immediately flags this activity. This alert includes detailed information about the suspicious request, enabling security teams to quickly respond to potential threats and prevent the exploitation of cloud resources, such as the creation of unauthorized IAM users and the assignment of high-level access privileges.
In this comprehensive exploration of RCE within cloud environments, specifically focusing on AWS, we've demystified the concept of RCE and its implications. Through practical examples, we've shown how attackers can exploit RCE vulnerabilities to not only gain unauthorized access to cloud instances but also to move laterally within the environment, amplifying the potential damage. Tools such as Nmap and Metasploit become critical in these exploits, enabling attackers to discover vulnerabilities and execute code that grants them deep access to cloud infrastructure.
Our journey through the reconnaissance process, the exploitation of vulnerabilities, and the establishment of a foothold within the target system underscores the critical importance of proactive security measures. It highlights the necessity of constant vigilance, rapid response to vulnerabilities, and the implementation of strict access controls to mitigate the risks associated with RCE.
As we conclude, let this blog serve as a reminder of the ever-present threat of RCE and the need for robust defenses in your cloud environments. Protecting against RCE is not just about patching known vulnerabilities; it's about adopting a comprehensive security posture that includes regular security assessments, embracing the principle of least privilege, and staying informed about emerging threats. Only through such diligent efforts can organizations hope to safeguard their valuable digital assets against the sophisticated and high-impact exploits that RCE vulnerabilities enable.