Check Point
By Maya Levine, Technical Marketing Engineer, Cloud Security, Check Point Software Technologies
Let's give a brief overview into what a cloud native attack looks like from the inside and how we can protect ourselves. Let's consider a fairly common cloud deployment — a serverless application consisting of an API GW in front with a lambda function serving the main business logic and a persistency layer of a self-hosted Mongo DB backed by an EBS volume.
All a hacker sees externally is the API GW, and API GW calls that hit lambda functions. A simple mistake in the code, looking for an input without correct validation, leaves a lambda function susceptible to Local File Inclusion attacks. This can allow a hacker to extract the processes' environmental variables, like the token ID and secret, which can be used to impersonate the lambda in a newly created token.
Hackers can use enumeration tools to discover both the permissions a lambda has, and the roles that exist within an account. If this lambda they impersonate has the permissions to assume a role, these tools can point them right on target. In this case, there was a role called EBS-Snapshot they assumed, as the name indicated access to EBS. Enumeration tools can also be used to identify all the EBS snapshots they have access to. They will search for ones with “Backup” in the name, indicating storage of sensitive data.
The difficult part is accessing these snapshots without making too much noise and alerting the victim of their presence. One way of doing this is modifying the snapshot ACL's to allow external accounts to read the snapshot. The hacker can then access the backup from their own account and create a volume from it. This will not be visible from the attacker's account as the traffic goes through the cloud control plane directly to the attacker's account. At this point, even if the victim realizes their environment has been breached and removes the permissions, it no longer matters. The hacker has all the information already in their possession.
How to protect yourself:
Web Application Firewalls —This is very basic and signature based, but can protect against common applications exploits like an LFI
Posture Management Systems — Use a system that lets you write your own governance rules and makes sure they are enforced at scale. For example, making sure WAF is enabled for any API GW deployed.
Posture Management Systems — Use a system that lets you write your own governance rules and makes sure they are enforced at scale. For example, making sure WAF is enabled for any API GW deployed.
CloudGuard Posture Management allows you to create custom rules intuitively with the GSL Builder Tool
Workload Protection - Full time runtime protection that analyzes function behavior, establishes a baseline of function activity, and locks it down by applying a minimal privilege runtime profile. It is very difficult to utilize functions in any attack without having it deviate from its normal behavior.
CloudGuard Workload Protection will identify overly permissive roles and offer a Suggested Fix that can be copied directly into an IAM Policy
Detect permission changes — The hacker modified the EBS snapshot parameters by exposing it to their own account. “ModifySnapshotAttribute” is something your SIEM system or security analytics tools should look out for.
Utilize Security Analytic Systems to Detect Anomalies — For example, a session token being used by an entity that is disconnected from your environment is a clear sign of token abuse.
CloudGuard Intelligence analyzes real time traffic and event activity to notify you of security events and environmental anomalies