Security practitioners are familiar with the dangers of an attacker tapping into privileged accounts. An attacker obtaining access to domain admin credentials or root access to a critical server could be a veritable catastrophe. Potential consequences include disrupting business, encrypting data and holding it for ransom, or using the impacted device as a beachhead to conduct further attacks.
Security professionals also understand how difficult it is for organizations to recover from these account hijacking attacks. By obtaining high levels of access, a malicious actor could potentially make subtle changes that make it difficult for security teams to confidently state that the environment has been fully restored.
In the cloud, the situation is no different, and in fact, it can be worse in some ways. Not only do we have user accounts and passwords used for VM images, such as in IaaS environments, but there are many other accounts to consider as well, including application accounts and accounts for third-party connected services that potentially have their own associated API keys. Additionally, there are user accounts with administrative-level access to the cloud provider's console, such as subscription accounts for public cloud services or the administrative accounts used to gain access to the service provider's console. Depending on configuration, access to these accounts enables malicious actors to enact billing changes, enable or disable services, change configurations, launch new VM instances, delete or modify storage, and create havoc on numerous other critical functions.
How cloud account hijacking works
When an account such as a subscription account becomes compromised, it becomes a major security issue. This, in a nutshell, is what cloud account hijacking is all about. Cloud account hijacking is the disclosure, accidental leakage, exposure or other compromise of a cloud account that is critical to the operation, administration or maintenance of a cloud environment. This is often a subscription account as described above, but it can also target, depending on access, nonadmin accounts or other accounts that can be misused to cause unwanted disruption.
There are a few ways this can happen. First, passwords can be lost or stolen. Users might protect passwords poorly or choose weak passwords. Likewise, users might recycle passwords that they use outside of work for the cloud console. Consequently, an exposure in an unrelated application or service may expose the cloud console password. Additionally, credentials can be used inappropriately. For example, passwords may be included in application source code, in scripts, or stored on file systems or storage buckets. Lastly, attackers can attempt to actively harvest them through phishing, malware, brute force or credential stuffing.
Even if a credential is not lost or stolen, account access of this type is a high-value target from an attacker's point of view. Malicious actors may use alternative methods, such as Clickjacking, to subvert the authentication model of a cloud provider without directly compromising a credential. Large, security-savvy cloud providers will employ strategies to help prevent some of those attacks by implementing tactics such as response headers that control page rendering. However, smaller providers may not offer the same protections.
3 ways to mitigate cloud account hijacking attacks
The threat of cloud account hijacking is so significant that it ranks fifth in the Cloud Security Alliance's 2019 list of the "Egregious 11" threats in cloud computing. Given the critical nature of what these accounts protect, it is incumbent on security leaders to identify what strategies cloud customers can use to prevent this type of compromise. Fortunately, identity and access management is a well-understood problem. Security professionals harden credentials used for business or other applications and should use similar methods to harden cloud administrator credentials.
1. Use multifactor authentication (MFA). Most cloud providers support MFA for console access, and it should be a must to allow console access in a production cloud environment. Organizations must also factor in the various methods of automated access to cloud tools. These include certificates for TLS mutual authentication used for web APIs, as well as authentication tokens and API keys in use. It is critical to understand both how someone might log in -- via the console and also programmatically -- and take appropriate protection steps for each access method.
2. Segregate duties. Accounting teams typically require access to the payment and billing portions of a cloud provider's console. Do they also require the ability to create new storage buckets, launch new virtual instances or make modifications to functions running in a serverless PaaS? Probably not. Likewise, operational engineers responsible for overseeing objects in an IaaS environment probably do not need access to detailed billing records. Disallow unneeded access to the extent that cloud providers support it.
3. Trust but verify. Similar to internal accounts, such as Windows domain accounts, periodically validate that access levels are appropriate. Establish termination and job change procedures to ensure that access is adjusted accordingly when individuals quit or change roles. Audit the use of credentials to ensure that they are being used appropriately. Consider whether there are existing tools, such as privileged identity management (PIM) that can play a role in the organization's access strategy. PIM tools can keep records of credential use, while cloud access security broker tools can help log console access.