According to a 2019 Cyber Security Report published by the International Information System Security Certification Consortium, 93 percent of organizations say they are concerned about cloud security and 28 percent admit to having experienced cloud security incidents during the past year.
The reality is, most companies lack the specialized knowledge and skills needed to provide that customer data stored in the cloud is protected Cloud service providers (CSPs) do provide extra security layers, such as automating threat detection, with the intent of making their customers feel more confident in the security of the cloud. However, the number of cloud breaches that are being reported shows that CSPs and organizations alike continue to struggle with cloud security. Much of this is due to a lack of unified visibility not just in the cloud, but across an organization’s entire network, siloed teams and technologies, lack of threat intelligence, and partnerships with third-parties whose security controls are not up to snuff.
To address these challenges, many in the industry are advocating for organizations to simplify and unify their security approach, i.e. bring as many controls as possible into a single solution in order to break down the silos between security teams and technologies and to give greater visibility across the organization. We at AT&T Cybersecurity help organizations to accomplish this with our Unified Security Management (USM) Anywhere platform.
Of course, the effectiveness of any security solution is largely determined by the threat intelligence underpinning it. In any environment, we need to identify the common tactics, techniques, and procedures (TTPs) adversaries are using in their attacks. Below, we provide an overview of the latest threat intelligence from Alien Labs for Google Cloud Platform (GCP), which helps security practitioners to discover issues in their cloud workloads and detect adversaries exploiting attack vectors commonly seen in cloud environments.
Google Cloud Platform integration in USM
This summer, AT&T Cybersecurity launched the USM Anywhere™ integration with GCP. Through the USM Anywhere Alien App for GCP, USM can now consume all logging information managed by the Stackdriver utility in a configurable and intuitive way.
Google Cloud Platform logs are provided through three major channels:
- Audit Logs. Record all events impacting objects within the environment. These logs are used to monitor any cloud assets, presenting a solid baseline for security detection.
- VPC Flow Logs. Half way between resource monitoring and cloud infrastructure security, these logs are the delights of NIDS enthusiasts.
- Firewall Logs. These help with auditing firewall rules events, and they are useful in detecting risky open ports and other configuration issues.
In USM, these channels are processed by different plugins, which extract pieces of intelligence and map them to variables that are easy to steer into orchestration rules. The correlation engine allows for the combination of detections from different channels into a single orchestration rule, scaling GCP security to a new level.
To prevent an intrusion from being recorded or triggering a notification, adversaries may try to disable audit logging once they get the necessary permissions. To protect against that, the product has out of the box correlation rules to generate an alert if any of the logging features is disabled.
Tracking identity thieves in USM
Access management control is possibly the most security critical feature to manage properly in a cloud environment. GCP accounts are linked to Google or Google Apps accounts, which means that attackers must find a way to access valid credentials before attempting to compromise cloud resources.
Users of the GCloud CLI utility need to pay special attention to credentials.db and access_tokens.db. These database files are stored in C:Users{user}AppDataRoaminggcloud for Windows machines and ~/.config/gcloud/ in Unix systems along with the legacy_credentials directory. Any user who accesses these files will be able to impersonate the Google account from another machine.
An interesting utility that helps to look for stored credentials in Windows machines is SharpCloud. This tool digs into the filesystem to find stored GCP, AWS, and Azure credentials by inspecting the default installation directories. Alien Labs threat intelligence is directly integrated and continuously updated in USM provides the logic to alert on adversaries attempting to use this tool.
To help protect against credential phishing, Multi-Factor Authentication methods, like security keys or backup codes, can serve as a final protection layer.
However, in some scenarios, adversaries can take control of a machine with legitimate access to the cloud or have their own valid account. In addition, many organizations continue to struggle with managing the accidental exposure of API keys or service account credentials, which sometimes can be found hardcoded in web applications or committed to public repositories.
For those cases, USM can help to identify and alert on anomalous user behaviors.
Usually, credentials thieves won’t steal and abuse the credentials right away, but will store and sell them to others (a growing market of stolen Google Compute credentials is arising in the dark market).
As analyzed in our recent blog about cryptomining attacks detected on AWS, attacks targeting cloud environments are focusing on compute resources consumption and identity management manipulation. For instance, it is likely that adversaries accessing the cloud environment will try to create alternative accounts (preventing loss of access if the credentials they stole get revoked), deleting the user’s original accounts or assigning elevated privileges for themselves.
Containers are another preferred target when it comes to hijack cloud resources. In late 2018, a newly discovered vulnerability impacting Kubelet API triggered an uptick of activity exploiting exposed kube-apiserver services.
Kubelet, the primary agent that rules kube-nodes, does not prevent unauthenticated access to the endpoint by default. This means if the network configuration is not properly protected, it can lead to sensitive information exposure and arbitrary code execution. More importantly, adversaries can try to steal Google’s Service Account access tokens, stored at /var/run/secrets/kubernetes.io/serviceaccount/token
One way to read these files would be an anonymous ‘exec’ request. Tools like the kubelet-anon-rce script helps to automate unauthenticated access.
USM can help prevent this scenario by alerting on unsecure Kubelet API configurations or multiple rejected unauthenticated access attempts.
Bucket privilege escalation
When it comes to protecting data, security practitioners should also be monitoring storage security. Access control to GCS buckets is managed by special policies called “bucket policies,” which grant special permissions to individual users in a bucket, regardless of their role in the project (if any).
Using these policies, it’s possible to make data public. Contrary to regular project policies, bucket policies allow for the addition of public users - allUsers and allAuthenticatedUsers - to a project role. This can result in a privilege escalation scenario whereby the public user is added to a role with write permissions — for example, the storage legacy bucket role.
If a bucket is misconfigured, adversaries can modify their own role to get admin permissions and gain control of the data. A few months ago, I tried a Rhino Security Labs tool called GCPBucketBrute. This script can help a user find a “public” misconfigured bucket with word-based enumeration, and it can automate the privilege escalation process.
Therefore, it’s vitally important to monitor public user activity in GCP for stored data. Within USM, we created rules to help protect against storage misconfigurations, such as having the public user added to a privileged group.
It is also possible to detect GCPBucketBrute in the enumeration process, when the tool generates multiple requests to various endpoints with similar names. Alerts triggered for this in USM will show the specific endpoints that were reached and the source of the requests, helping to pinpoint unprotected resources.
Continuing to expand security detection in the cloud
As organizations continue to migrate workloads to the cloud, Alien Labs will focus on expanding the USM security analytics capabilities for cloud platforms, including Amazon AWS, Azure, and GCP. With the release of the USM AlienApp for GCP, we included a set of new correlation rules covering critical GCP security misconfigurations and use cases.
Most cloud threat scenarios involve identity and account manipulation, credentials theft, and storage access. Other cloud features like containerization are also protected with the recent release of correlation rules for Kubernetes, compatible to both GCP, GKE and AWS EKS.
This new set of cloud-based correlation rules expands our coverage, which already includes AWS CloudTrail and GuardDuty, Box™, Okta, Microsoft® Azure Security Center and Office365, among others.
Alien Labs correlation rules for Google Cloud Platform
(This represents the correlation rules as of the date of this blog. We are continuously updating our GCP rule set. Please refer to the AT&T Success Center for the latest updates.)
- Suspicious Security Critical Event |GCE Instance limit exceeded after mass GCE Instance launch
- Security Critical Infrastructure Update |GCP VPC Logging Disabled
- Security Critical Infrastructure Update | GCP Audit Logging Disabled
- Credential Abuse | Access Key used from multiple locations in a short period of time
- Brute Force Permission Enumeration | Multiple GCP Account access denied
- Suspicious Security Critical Event | Multiple GCE Instances stopped programmatically
- Suspicious Security Critical Event | Multiple GCE Instances started programmatically
- Anomalous Infrastructure Update | GCE Instance launched in a region not used before
- Anomalous Infrastructure Update | New GCE Instance Type
- Anomalous User Behavior | New GCE user starting a high number of GCE Instances
- Use of Known Malicious Infrastructure | Assigned Public IP Previously Identified as Malicious
- Anomalous User Behavior | New account added to admin role
- Anomalous User Behavior | New account used to delete multiple accounts
- Publicly Accessible Resource | Exposed GCE Bucket or file
- Anomalous User Behavior | New Account followed by Source Account Deletion
- Suspicious Security Critical Event | GCE Instance Limit Exceeded
- Anomalous User Behavior | Multiple user account deletion
- Publicly Accessible Resource | Git directory exposed in bucket
- Brute Force Enumeration | Unauthorized Bucket Enumeration
- Bucket Privilege Escalation | Public user added to storage admin role
- Risky Configuration | Exposed Kubelet API
- Anomalous User Behavior | Project created and deleted in a short period
- Anomalous User Behavior | A new user tried to delete a GCP Project
- Anomalous User Behavior | User Role created and deleted in a short period
- Anomalous User Behavior | New Role with write permiss
Jose Manuel Martin is a Security Researcher and a part of the AT&T Alien Labs team. Read more AT&T Cybersecurity blogs here.
