User privileges settings in commercial software frequently (and inadvertently) expose your business to privilege escalation attacks. Monitoring for access rights changes can help to proactively mitigate the risks.
The team at CYDEF advocates for the principle of minimum privileges; according to which users should have only the minimal access rights to perform their jobs. A big part of the goal of minimum privileges is to ensure that users do not casually operate their machines with administrator privileges. After all, the consequences of an attack that targeted a limited user are much less severe than the ones that successfully compromised an administrator account.
However, all the good work you have done limiting user privileges can be undone by poor software practices.
In this post, we will look at a class of privilege escalation (privesc) vulnerabilities and at what to look for in your logs to detect it.
User Privilege Escalation
As an attacker, when you compromise a machine and you end up as a local user, your life SUUUUUCKS. All the tactics you’d normally use to expand your foothold won’t be available.
Dumping passwords? Requires admin privileges.
Sniffing the network? Yup, admin privileges required again.
Scheduling a task or launching a service? Better have that admin account.
Basically, as a limited user, you have access to the user’s documents, the user’s profile and the user’s processes. So, you can steal the documents written by the user, but not those of anyone else. You can sniff the keystrokes of the user, but not keystrokes from anyone else. You can achieve persistence at user logon, but not at computer reboot.
So, it is no surprise that, when an attacker gains this kind of access, they will immediately try to increase their privileges.
As an attacker, there are a number of ways to increase your privileges. For example, we had one case when an enterprising attacker used a compromised account to send spear phishing emails to other people from inside the company. (That attempt is described in our post about Phishing Campaigns). However, usually, privileges are escalated by triggering a software vulnerability. This creates a class of vulnerability called Local Privilege Escalation vulnerabilities.
There are many flavors of LPE (see the CVE database for examples). As an example, there might be a buffer overflow in software that runs with admin privileges (e.g. a setuid program on Linux) but is not accessible from the network. So, a remote attacker cannot use it to gain access to the computer, but a local user might be able to trigger the vulnerability to gain administrative access.
Another example, and the one that interests us today, is weak access control permissions to the location of the privileged software on the hard drive. A good example of an attack that targets this kind of vulnerability is the technique described in the ATT&CK framework as T1574.010 – Hijack Execution Flow Service File Permission Weakness.
In this technique, the attacker finds software that is running on Windows as a service. Windows services generally run as Local System unless configured otherwise, so they provide incredible privileges if they can be exploited. If the folder where the binary of the service runs has loose permissions, for example, allowing write access to all authenticated users, a malicious user can just delete the legitimate binary and put a malicious software with the same name as the legitimate binary in there. When Windows wants to start the service (often at startup), it will check in the service configuration for the full path, see the malicious software with the right name in the right spot, and just launch it with Local Systems privileges.
In our daily security monitoring performed for our SMART-Monitor service, we see a good number of applications setting up users for this kind of problem.
Privilege Escalation: What to Look For
The way we detect this kind of problem is by looking at calls to software from the OS designed to change permissions (e.g. cacls and icacls on Windows, chmod and chgroup on MacOs). In addition, we look for software running in folders with known loose permissions, in particular the ProgramData folder in Windows which is a common offender.
Here are a few examples extracted from our incident database of the kinds of things we see.
C:\WINDOWS\system32\cacls.exe “C:\Program Files (x86)\[REDACTED COMPANY NAME]\[REDACTED PROGRAM NAME]Setup_21233.exe” /E /C /G Everyone:F
This line grants the “everyone” named account on Windows full control over the installer executable file. So, a malicious user could replace this with malware, call up the help desk complaining about issues with the software to get an admin to reinstall it. The admin would run the malware instead.
We have seen similar issues on MacOS. Here is an MSP software granting all users read, write and execute permission on the temp folder where they drop their scripts.
“ParentImage”:”/Library/Application Support/ [COMPANY NAME] MSP/[COMPANY NAME]MSP.app/Contents/MacOS/[COMPANY NAME]clr/dotnet”,
“Image”: “/bin/chmod”,
“CommandLine”: “/bin/bash -c chmod 777 /tmp/[COMPANYNAME]/”
This creates a race condition where, if a user could modify the script after it is dropped, but before it is executed, it would run with the RMM software privileges. It is very difficult to understand why all users would need write access to this folder as well.
The next one is a case where a user set up a service using the “non sucking service manager” (nssm), but this is done from the ProgramData folder.
“C:\ProgramData\SD_AboutMyDevice\nssm.exe” install “[SERVICE NAME]” C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe “-ExecutionPolicy Bypass -NoProfile -File “C:\ProgramData\SD_[SERVICE NAME]\ [SERVICE NAME]_Service.ps1″”
The ProgramData folder is a default Windows folder designed to be writable by user programs, specifically as a centralized place to write data that needs to be shared across multiple programs. This means that users have write access to the ProgramData folder itself, even if they don’t technically have access to subfolders created by other users. However, many programs set excessive permissions when they create a folder there, or, if a user can delete a folder and create one with the same name, can essentially gain control of the path. Naturally, it is very dangerous to run a Windows service from there.
Giving everyone full access is so easy.
It’s much easier than trying to debug your software to find out exactly what are the proper access rights users need. That is why some software companies offer unlimited privileges out of the box, and why some system administrators do it as well.
The only way to defend against user privilege attacks is to proactively monitor for this type of activity and restrict access rights when these issues are found.
How CYDEF Protects Your Business from Privilege Escalation Attacks
CYDEF’s proprietary technology, SMART-Monitor, monitors endpoint performance and access. If your business inadvertently provides user privileges that lead to an endpoint breach or compromise, SMART-Monitor will detect the source of the issue. With our 30-day Proof-of-Value, you can experience first hand the value of endpoint security on your network.
