Privilege Escalation and a Proposal for Acceptable Exclusion
By submitting this form, you agree to our privacy policy.
Photo by Annie Sowards on Unsplash
“I’d never join a club that would allow a person like me to become a member.” — Woody Allen
Social concepts about exclusivity and inclusion have changed over the last 50 years. It used to be common for social and professional clubs to aggressively seek homogeneity among their membership and exclude based on things that members felt might threaten the organizational structure. Some are remnants of an older, less kind era, while others are simply awesome in their exclusivity practices (the “Ejection Tie Club” comes to mind).
For those who maintain cloud environments, however, exclusivity is to be prized and protected. Be they unwashed or otherwise, the masses have no place in ACLs or to be granted permission to change resource settings or configurations. There are two distinct categories which need to be managed and monitored. The first is interactive in nature; this is where you need to look out for instances of users being impersonated which can give an actor privileges he shouldn’t have. The other is application-driven. This is usually the result of a design flaw or a misconfiguration in the application itself. These are difficult to audit and remediate at scale unless an organization is applying automated and continuous monitoring.
Privilege escalation is faking who you are to get something you shouldn’t have. There’s nothing egregiously wrong about that if you’re trying to sweet-talk your way into a nightclub. But within the cloud, your ability to bypass permissions intended to keep you out can happen all too common because most environments don’t apply tools to detect suspicious activity. Those that do will only apply a battery of disconnected tools for detection of suspicious activity. These get stuck in classifying and reclassifying logs and events in the hopes of finding a needle in a haystack.
In the world of hackers, escalating one’s privileges are not usually just for the pursuit of having a casual look around. Access can put them in front of files with possibly sensitive data that can be deleted, copied, or injected with malware. Depending on the hacker’s purpose, they can alter sensitive data, exfiltrate it, or do a backdoor injection to launch exploits at a later time. Privilege escalation acts as if an occult hand had reached down and simply placed an unwarranted person in the midst of juicy storehouses of data.
AWS IAM Policies provide guidelines for implementing the concept of “least privilege” access to applications and resources. This means that access is strictly enforced and only granted to the least number of people who absolutely need that level of access. Now, some may have read access which is a measure of protection (this can be problematic in cases of horizontal privilege escalation), while a more selective group is given write access, which can lead to vertical privilege escalation.
The concept of least privilege was first developed in 1975 by two MIT computer scientists, Jerome Saltzer and Michael Schroeder in a paper titled, The Protection of Information in Computer Systems. In it, they stated:
Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide “firewalls,” the principle of least privilege provides a rationale for where to install the firewalls.
The issue, however, is that in organizations where EC2 instances and S3 buckets are accessed or allowed to be added to the infrastructure by a wide range of participants, it can be difficult to apply effective governance. After all, some users need the flexibility for their AWS services to authenticate with the AWS API service. AWS can provide a temporary authentication token for that particular app and instance, but it’s not a scalable way to maintain adequate access for those who need it and for whom it is valid.
To avoid privilege escalation, Lacework’s Chief Security Architect, Dan Hubbard, says you should build least privilege systems into your architecture. If you’re migrating from on-premises systems, then you should probably focus on policies for resources such as:
- Templatized workload configuration tools: TerraForm, AWS CloudFormation
- Orchestration systems: Kubernetes, Swarm, Mesos
- Container technologies: Docker, Linux Containers, Rocket
- Your operating system: CoreOS, Ubuntu, RedHat, CentOS, Debian
Within AWS itself, you will also need to ensure the appropriate level of access and privilege across all the different resources and services AWS provides. It’s not inherently difficult but is a bit cumbersome because of the demands of speed and scale. A good checklist includes these steps:
- Security for your AWS accounts
- Security for all the AWS services you are using
- Security for all your AWS and non-AWS APIs
- Security for your applications
- Security for your users
- Compliance for all of the above
Underlying all of these steps needs to be aware that, frankly, IT isn’t always equipped to police all the elements within the cloud environments it manages. That’s not a criticism, it’s an admission that simply too much is happening within the cloud for manual oversight. As a best practice, apply a mindset that presumes the environment is already compromised and seek out admins for all resources and applications. Apply policies that insist on limiting access and audit those admins.
The thing you really can’t do manually, however, is knowing whether or not those policies are enforcing the proper level of admittance. Understanding your environment through continuous monitoring and mapping all cloud events (yes, ALL cloud events) against behavioral norms is truly the only way to really see what’s happening and where anomalies are occurring. The right organizational mindset will help, however, and you should always insist on practices that detect and minimize privilege escalation.
