Sylphs in the Cloud
A Sylph (also known as Sylphid) is an air spirit. They are formed of air, they live in the air, and they have unusual power over the air, particularly the wind and the clouds. Usually, Sylphs are portrayed as guardians who protect secret knowledge, beautiful women, or the environment, but it's not out of the question for a Sylph to cause mischief among men. Read more about sylphs from mythology here.
Introduction:
CyberPoint is no stranger to malware and malware analysis. Our work has us detecting malware, analyzing malware, and occasionally writing malware. Part of the allure of ransomware originally was low barrier of entry – an author can simply call native system APIs to encrypt the files rather than using any real trickery. But with the comparatively recent attacks on the Colonial Pipeline and other industrial systems, ransomware has clearly established itself as a serious threat, not just a quick cash grab for amateurs. Once the victims started paying, and there was real money to be made, organized crime came in with Ransomware-As-A-Service platforms like Darkside and REvil. These services offer support, sophisticated user interfaces, and other standard features, further removing any technical barriers to cybercrime.
The Problem:
Too often, IT and infrastructure are seen as cost centers only. When everything works, why are we paying so much for IT? When nothing works, why are we paying so much for IT?
By now most companies with a need for infrastructure or network-accessible services will have a cloud component. Much like the ransomware kingpins, cloud service providers also offer a way to offload labor intensive tasks in exchange for cash. Often, the cost analysis comes down firmly in favor of cloud offerings when you take into account equipment maintenance, replacement costs, 24/7 labor support, and the highly paid engineers required to keep the bytes flowing.
Of course, the cloud itself comes with risks. Policy and Identity and Account Management are highly complex, making it vulnerable to the same issues of complacency, ignorance, or laziness that any other service can fall victim to. Cloud administrators aren't always cloud administrators – often they are database administrators, or software developers, or helpdesk technicians who had an additional duty thrust upon them. When you have a hundred conflicting priorities, it is too easy to simply assign Administrator rights to a struggling service, or a vocal end-user.
So now we face the obvious question – how do you defend against these sorts of attacks? There are plenty of guides available on best practices, but CyberPoint works to be proactive. To defend against the next generation of attacks, we have to be a step ahead of them. In the course of this research, we have identified a novel method for post-exploitation ransomware-style attacks on a cloud environment.
CyberPoint presents Sylph – the malevolent cloud sprite that causes mischief, but whose goal is protection. Sylph is a tool, written primarily in Python with a little orchestration in Terraform, that implements a series of techniques to ransomware a target's cloud storage devices at the block level. It has been tested and developed for AWS, but future research will target other environments such as Azure and GCP.
Disclaimer: ethically, we will not be releasing this tool publicly, but it will be used in upcoming APT simulation events and Rapid Prototyping Events at the Maryland Innovation and Security Institute's DreamPort facility.
Story:
Recently, we found ourselves wondering if, given the appropriate access, it would be possible to use API calls remotely to ransomware an entire corporate infrastructure using just some Python and Amazon's own boto3 library.
It is common in an AWS environment to use Elastic Block Storage volumes for storage, which can be encrypted at the volume level. AWS uses its Key Management Service (KMS) to encrypt the data key used to encrypt the volume. I was left with a few questions:
- Could a previously unencrypted volume be encrypted?
- Could a user-defined key be defined and used?
- Could access to that key be denied, even to an administrator on the account?
First, how to encrypt a volume attached to a running EC2 instance? Could we encrypt a running volume? The answer is…sort of. Indirectly. While the running volume cannot be modified that way, with a few steps and a short turnaround, an encrypted copy could be created and swapped out. There are a few steps:
- Create a snapshot of the running volume
- Create an encrypted volume from that running snapshot
- Stop the instance
- Replace the old volume with the encrypted volume
- Start the instance
The second and third questions go hand in hand. AWS KMS allows for 'customer managed' keys to be created. This is not passing in a symmetric passphrase or a public/private keypair in a traditional sense, but rather defining a key within the KMS infrastructure and applying appropriate configuration settings. That's all fine, but what about the final piece – making sure the administrator cannot access the key to decrypt his or her volumes?
Note the following snippet of a customer-managed key policy:
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:root",
"arn:aws:iam::222222222222:user/user01"
]
Snippet of KMS Policy
AWS policy allows for cross-account key use! The first IAM line allows the account 11111111111 to access the key stored in account 222222222222.
Realizing this, we created a key in a separate AWS account over which we have full permissions (managed keys are free or nearly free), and the full attack chain becomes simple:
- Enumerate all EBS volumes attached to an EC2 instance
- For volume in volumes, create snapshot
- Create volume from snapshot
- Replace the old volume with the new, encrypted, volume
- Clean up (delete old volumes and snapshots so the administrator cannot simply restore to a previous point)
- Remove permissions from the key in the attacker-controlled account
- Reboot the hosts (there may be an easier way to force the volume to require the key, but if so, I have not found it)
Example Output of Sylph.py
Before: KMS Key IDs are null for unencrypted or reflect a same-account key
After: KMS Key ID from External Organization
At this point, the EC2 instances will fail to boot and become inaccessible, and the bad actor can supply their demands. Restoring access is as trivial as restoring the original IAM policy on the KMS key.
Attempting to create a Volume from a Snapshot without KMS permissions fails
Attempting to Power On an Instance after removing KMS Permissions causes boot failure
Prevention and Mitigations:
The sort of IAM policy required to allow this is broad. This attack assumes a user has near-full control over EC2 permissions. The API calls used in this attack would be trivial to alert for — in most organizations creating snapshots is a regular occurrence, but it would be uncommon to create new volumes. Stay tuned for future blog posts with specific hardening techniques for cloud environments. Permissions required include:
"ec2:DescribeInstances",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:StopInstances",
"ec2:StartInstances",
"ec2:CopySnapshot",
"ec2:CreateSnapshot",
"ec2:CreateVolume",
"ec2:DeleteVolume",
"ec2:DeleteSnapshot",
"ec2:AttachVolume",
"ec2:DetachVolume"
Conclusion:
At the end of the day, administrators will slip up, policies will be weaker than they should, and other mistakes will be made. There's an old joke about two hikers who encounter a bear, and one starts lacing up his running shoes. "Why are you doing that?", asks the other, "You'll never outrun the bear!". The first replies simply "I don't have to outrun the bear – I only have to outrun you."
How do you become faster than the other hikers? A few ways:
Review your accounts regularly for privilege creep
Set effective alarms on dangerous API calls and accesses
And most importantly: don't be afraid to ask for help! The cloud security experts at CyberPoint are experienced in audits and assessments of cloud infrastructure, reviewing for misconfigurations and all the little things that accrue over time. The missed wildcard policy, the forgotten debug account, the weak Lambda – we've seen them, and we've fixed them.