Secure coding

Least Privilege Vulnerabilities

Tom Olzak
March 25, 2020 by
Tom Olzak

Introduction

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.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Privilege escalation

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

Cynet writes that UAC bypass is possible if the UAC setting is not strong enough. This can allow an application to elevate privileges without user approval. According to SOC Level 1, some applications might be set to auto-elevate, allowing them to elevate privilege when necessary. As we’ll see later, compromise of authorized applications is a common privilege escalation attack vector.

Organizations may believe their applications do not improperly elevate privileges to perform tasks. However, testing is necessary to ensure this is true. Testing is especially important when bloatware (third-party software included on new hardware purchases) is distributed to users. This is one reason installing an approved image on a user device before distribution is a good security practice.

Access token manipulation

Windows uses tokens to represent users. Each authenticated user is provided with a token that information resources and the network use to determine rights and permissions. If an MA can steal a token, he can access whatever the token is allowed to access.

MITRE posits that an MA must use an account with highly privileged access (e.g., administrator) to steal a token. One of the easiest ways for an MA to work within a privileged access context is to compromise a system where a user consistently uses an administrator account for day-to-day activities. 

Users who need to run applications with a highly privileged token should use the Windows runas command. This eliminates the need and the temptation for IT personnel to continuously use a privileged account for things like email, use of Office applications and software development.

DLL hijacking

When using DLL hijacking, MAs might place a replacement DLL in the search path the system uses to find and load called application binaries. SEC Consult writes that by default, Windows checks the following locations in the order listed.

  1. The directory from which the application is loaded
  2. C:WindowsSystem32
  3. C:WindowsSystem
  4. C:Windows
  5. The current working directory
  6. Directories in the system PATH environment variable
  7. Directories in the user PATH environment variable 

System DLL locations are commonly listed in the Windows registry. Malicious access to the registry can also allow the implementation of MA DLLs.

If developers do not explicitly specify where a binary is located when called by the running code, the system must go looking for it. Based on the system configuration, an attacker can place a DLL with the same name as the called binary in the search path.

When the malicious DLL is run, the application comes under partial control of the MA. This is related to UAC bypass. The compromised application can elevate the privileges of the processes run by the application. This potentially provides escalated MA access to information resources.

The best defense is preventing the installation of any binaries not approved by IT: application whitelisting. Windows Defender Application Control is another layer of defense against DLL hijacking. Using this tool, organizations can define rules that manage 

  • Attributes of the code-signing certificate(s) used to sign an app and its binaries
  • Attributes of the application’s binaries that come from the signed metadata for the files, including file hashes
  • The path from which the app or file is launched
  • The process that launches the application or binary

General protection

Annually, researchers discover application and system vulnerabilities that allow privilege escalation. There is no way to completely eliminate these weaknesses and always keep them from user devices. Consequently, organizations must monitor for activities related to attacks against least privilege, including anomalous

  • Use of the runas command
  • User/token behavior
  • Change of token privilege (described in a Netsparker article)
  • DLL manipulation (described in MITRE’s article, DLL Search Order Hijacking)

Conclusion

Least privilege is an important security control and requires management beyond controlling user access by role. Organizations must also pay close attention to attack vectors internal and external MAs can leverage to bypass least privilege restrictions. 

Prevention controls are not enough. Organizations must include monitoring for anomalous behavior related to privilege escalation in their log management process and behavior analytics.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

 

Sources

  1. Understanding Privilege Escalation and 5 Common Attack Techniques, Cynet
  2. Application Control, Microsoft
  3. Access Token Manipulation, MITRE
  4. DLL Search Order Hijacking, MITRE
  5. What Is Privilege Escalation and Why Is It Important?, Netsparker
  6. Protecting Controlled Unclassified Information (CUI), NIST
  7. Windows Privilege Escalation - an approach for penetration testers, SEC Consult
  8. Bypassing Windows UAC, SOC Level 1
Tom Olzak
Tom Olzak

Tom Olzak is a security researcher for the InfoSec Institute and an IT professional with over 37 years of experience in programming, network engineering, and security. He has an MBA and is a CISSP.  He is currently an online instructor for the University of Phoenix.

He has held positions as an IS director, director of infrastructure engineering, director of information security, and programming manager at a variety of manufacturing, health care, and distribution companies. Before joining the private sector, he served 10 years in the United States Army Military Police with four years as a military police investigator.

He has written four books, "Just Enough Security", "Microsoft Virtualization", "Introduction to Enterprise Security", and "Incident Management and Response."  He is also the author of various papers on security management and a blogger for CSOonline.com, TechRepublic, Toolbox.com, and Tom Olzak on Security.