The principle of least privilege is an essential component of information assurance and security activities. According to the National Institute of Standards and Technology (NIST), organizations apply least privilege to provide users with only the rights and permissions needed to do their jobs. Like all security controls, however, vulnerabilities often exist that reduce effectiveness and increase risk
In this article, I’ll describe several vulnerability types often seen in Windows environments that allow malicious actors (MA) to bypass least privilege access management efforts. I’ll also briefly describe how to detect and manage these weaknesses.
Users must access information resources to do their jobs. This makes it possible for MA who compromise their systems to access what the users can access. Theoretically, strictly restricting access for each user account to only what the associated role needs within the contexts of need-to-know and separation of duties, MA access is restricted.
When an MA uses a compromised account without elevating privileges, it is called a horizontal exploit. When the MA elevates privileges to gain access beyond what the compromised account is supposedly allowed, it is a vertical exploit. In both instances, the approach is known as privilege escalation: gaining access at levels not approved by data owners.
If MAs can circumvent user account restrictions or use service accounts to access resources, they can access resources with elevated access rights and permissions. They can also pivot to other accounts for additional access. In many cases, they can act as local or domain administrators.
Common least privilege vulnerabilities
Least privilege vulnerabilities exist largely in cloud and local third-party applications or applications developed in-house. Three least privilege attack vectors often leverage the Windows operating system include
- UAC bypass
- Token theft/manipulation
- DLL hijacking
UAC (User Account Control) bypass
*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Tom Olzak. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/ggk62bc_a_M/