A quick explanation of one of the most influential and misconfigured computing utilities.
You’re a hacker.
Okay, maybe you aren’t, but let’s say you are. You finally got into a server you’ve been attacking for weeks, but you’re stuck. The credentials you logged in with are only for a regular user. What’s your next course of action?
Go break into a building and steal the server? Too risky. Attack other machines on the network? That might cause alerts.
Manipulate the server to give you more access? That might work.
I’m referencing an action or (set of actions) called privilege escalation. Privilege escalation is a household phrase whether you’re an ethical hacker or a real adversary. It takes many forms and covering them all would be challenging for one blog post. So, let’s talk about sudo, how attackers use it, and why you should care about it.
What the heck is “sudo”?
Super User Do As or Sudo was first developed in 1980 by Bob Coggeshall and Cliff Spencer. Both Bob and Cliff worked at the Department of Computer Science at SUNY/Buffalo. Sudo’s purpose was and is what its name entailed: to act as the superuser of a particular system.
Let’s say you need to change a file, but only the root user can do it. Utilizing the sudo utility allows a user to make changes without needing to switch users. The user’s command executes as root (highest-level user), and that’s it. Now you don’t need to share your root password with everyone.
Bob and Cliff saw the need for this solution back in 1980, and it has gone through many iterations since its creation. We recommend taking a look at this interview with Bob if you’re interested in history. Unfortunately, malicious-minded individuals can still abuse it.
Sudo and Sudon’t: Misconfigurations
When a user uses the sudo command, it performs authorization checks to handle the request. This is generally done by referencing the sudoers file. You can find it on most UNIX systems at: /etc/sudoers
The contents of the sudoers file consist of various permissions and settings related to sudo. It’s easy to imagine the complexity of settings after 40 years. For our purposes, we’ll show a specific setting and how an adversary may use it.
Let’s re-use our previous example. A hacker gained access to a terminal or “shell” on a victim machine, but they only have access as the following user:
The attacker logged in as JohnRisky, and the system administrators have done a good job locking down most of the victim machine. JohnRisky cannot run privileged commands, access other users’ files, or perform any meaningful action on the machine. This is all great, but the IT staff made one crucial mistake.
The attacker runs the following command:
The -l option tells the sudo command list the commands the user can run with sudo itself. This shows the attacker the following output:
There’s a good bit of output here, but we only need to focus on the last part.
This output states that JohnRisky (the hacker) can use sudo to run a script called DailyWork.sh.
I’ll add some context. JohnRisky is an accounting user who needs to run this script daily to crunch some numbers. He must run the script as root, and IT staff got fed up with his constant annoying requests to run it. They modified the sudoers file, allowing JohnRisky to run his script with Sudo. They told themselves it wouldn’t be a big deal. After all, only JohnRisky can run it and it just does accounting stuff.
The attacker notes the output and realizes his path forward is quite clear. Since JohnRisky stored the script is his home directory, the attacker can change it. The adversary can edit it to perform pretty much anything they desire. They decide to change it as follows:
This simple script will execute Bash, displaying a new shell to the user. Wait a second – the attacker can run the script with sudo, right? And sudo performs an action as the root user of a system. You’re probably piecing it together now.
Since the attacker can run this script using sudo, the new shell will spawn under the root user. The attacker used a misconfiguration left behind by system administrators to gain more access. This occurred from a compromised user account to root on the target host.
The adversary started by logging in with JohnRisky’s credentials. They could have gotten them from a phishing email or a leak – who knows in the end? All that matters is that they leveraged an oversight to gain root access on the server. It’s theirs now. They can do whatever they want on it.
Pretty scary stuff.
Please note that this is, at best, a rudimentary demonstration of using sudo to escalate. Real-world examples are generally more complex. The purpose of this blog is to highlight its power and explain why you should pay close attention to it.
Cool, what next?
There’s a good chance if you own or manage assets, you’re now wondering what your sudo settings look like. To make things more fun, Sudo is one small aspect of the wide world of computing and technology.
Are you curious about your security standing? Not sure where your shortcomings or vulnerabilities may live? Allow one of our world-class consultants to guide you by contacting us!
Also, if you’d like to know more about what goes on during a risk3sixty penetration test, check out our whitepaper, Pillars of Pentesting: A Guide to the Risk3sixty Attack Strategy.
Leave A Comment