Introduction 

Earlier this year I wrote a blog post that laid out some table-top cloud security exercises based on real-world attacks on cloud environments. The goal was to help cloud security teams find gaps in their detection and response programs (we ended up having multiple customers use these exercises which was great to hear!).  This post delves into one of those attack scenarios which involved vulnerable MS SQL Server databases hosted on misconfigured Amazon EC2 instances. This attack underscores the crucial importance of taking a holistic approach to cloud security, emphasizing the need to have clear visibility into risks that permeate from specific database configurations to the overarching cloud infrastructure. 

The Attack Vector 

The breach in question unfolded methodically, exploiting each weak link in the system’s defenses: 

  1. Identification of Publicly Accessible Servers: The attacker started by scanning IP ranges associated with Amazon EC2, specifically searching for instances that responded to MS SQL Server’s default port. This reconnaissance allowed them to pinpoint potential targets for the attack. 
  1. Brute Forcing SQL Logins: Utilizing powerful tools and pre-compiled lists of common passwords, the attacker then subjected the identified servers to brute force attacks. Given the weak authentication mechanisms in place, it was only a matter of time before they gained access. 
  1. Leveraging the Impersonation Chain: Upon successful login, the attacker capitalized on an impersonation chain – a sequence where one SQL Server user can assume the identity of another. This allowed them to elevate their privileges within the system, even if the initial breached account had limited rights. 
  1. Downloading and Deploying Malicious Payload: With elevated access, the attacker had the means to download a malicious payload onto the host machine. This not only jeopardized the integrity of the data within the SQL Server but also posed a risk to other interconnected systems in the cloud environment. 

In essence, a combination of publicly accessible servers, weak password policies, and misconfigured user permissions facilitated a multi-stage attack that culminated in the deployment of a malicious payload, underlining the dire consequences of lapses in cloud security. 

Detection of the Attack 

One of the major benefits of the team running through an attack scenario like this is not only to ensure you have the appropriate response, but to be sure you can even detect the attack in the first place. Customers use OpsCompass to detect risks across clouds like AWS and database platforms like MS SQL. You can see below that we detected a MS SQL Server with several configuration problems including lack of a strong password policy for SQL logins. 

We’re also able to see pretty clearly (below) that the MS SQL Server database in question here lives on an EC2 instance that allows TCP ingress on port 1433 and 3389. 

Preventive Measures 

This attack scenario reinforces the need for: 

  • Private Accessibility: EC2 instances should be confined within a Virtual Private Cloud (VPC), ensuring that direct public access is restricted. This encapsulation significantly reduces the surface area vulnerable to attacks. 
  • Robust Database Configuration: Regular audits should be conducted to ensure databases are stripped of default settings and are equipped with optimal security configurations. 
  • Strong Authentication: Implementing multi-factor authentication (MFA) and enforcing stringent password policies can deter brute-force attempts, bolstering the security of SQL logins. 
  • Limit User Permissions: Overly permissive roles should be avoided. Users should be granted only the permissions essential to their tasks, thereby minimizing potential damage from any single compromised account. 

By proactively implementing these measures, organizations can secure their cloud environments and reduce their overall risk to their data.  

Conclusion 

The incident with the vulnerable MS SQL Servers on EC2 underscores the pressing need for businesses to have comprehensive visibility into risks spanning the layers of the stack from the database to the EC2 service, and on to the rest of your AWS infrastructure like identity and Organization settings. In an age where cloud is a mostly ubiquitous part of the enterprise tech stack, siloed visibility leads to mistakes and vulnerability. Organizations must cultivate an integrated perspective, understanding how vulnerabilities in one layer can ripple through and potentially impact the entirety of their cloud estate. Using a platform like OpsCompass to maintain this holistic view and provide valuable intelligence surrounding your most consequential cloud and data risks is a great way to close the gap between your data and infrastructure risks in the cloud.  

Like what you see? Try OpsCompass for free!

Get started right now by signing up for a free trial of OpsCompass. Or, learn more with a live demo.