Linux Hacking Case Studies Part 4: Sudo Horror Stories
This blog will cover different ways to approach SSH password guessing and attacking sudo applications to gain a root shell on a Linux system. This case study commonly makes appearances in CTFs, but the general approach for attacking weak passwords and sudo applications can be applied to many real world environments. This should be a fun walk through for people new to penetration testing.
This is the fourth of a five part blog series highlighting entry points and local privilege escalation paths commonly found on Linux systems during network penetration tests.
Below are links to the first three blogs in the series:
- Linux Hacking Case Study Part 1: Rsync
- Linux Hacking Case Study Part 2: NFS
- Linux Hacking Case Study Part 3: phpMyAdmin
Below is an overview of what will be covered in this blog:
- Finding SSH Servers
- Dictionary Attacks against SSH Servers
- Viewing Sudoers Execution Options
- Exploiting Sudo sh
- Exploiting Sudo VI
- Exploiting Sudo Python
- Exploiting Sudo Nmap
Finding SSH Servers
Before we can start password guessing or attacking sudo applications, we need to find some SSH servers to go after. Luckily Nmap and similar port scanning tools make that pretty easy because most vendors still run SSH on the default port of 22.
Below is a sample Nmap command and screenshot to get you started.
nmap -sS -sV -p22 192.168.1.0/24 -oA sshscan
Once you’ve run the port scan you can quickly parse the results to make a file containing a list of SSH servers to target. Below is a command example and quick video to help illustrate.
grep -i "open" sshscan.gnmap grep -i "open" sshscan.gnmap | awk -F ' ' '{print $2} '> ssh.txt cat ssh.txt
Dictionary Attacks against SSH Servers
Password guessing is a pretty basic way to gain initial access to a Linux system, but that doesn’t mean it’s not effective. We see default and weak SSH passwords configured in at least a half of the environments we look at.
If you haven’t done it before, below are a few tips to get you started.
- Perform additional scanning and fingerprinting against the target SSH server and try to determine if it’s a specific device. For example, determine if it is a known printer, switch, router, or other miscellaneous network device. In many cases, knowing that little piece of information can lead you to default device passwords and land you on the box.
- Based on the service fingerprinting, also try to determine if any applications are running on the system that create local user accounts that might be configured with default passwords.
- Lastly, try common username and password combinations. Please be careful with this approach if you don’t understand the account lockout policies though. No one wants to have a bad day.
Password Lists
In this scenario let’s assume we’re going to test for common user name and password combinations. That means we’ll need a file containing a list of users and a file containing a list of passwords. Kali ships with some good word lists that provide coverage for common user names and passwords. Many can be found in the /usr/share/wordlists/.
While those can be handy, for this scenario we’re going to create a few small custom lists.
Create users.txt File Containing:
echo user >> users.txt echo root >> users.txt echo test >> users.txt
Create passwords.txt File Containing:
echo Password >> passwords.txt echo Password1 >> passwords.txt echo toor >> passwords.txt echo test >> passwords.txt
Password Guessing
Metasploit has modules that can be used to perform online dictionary attacks for most management protocols. Most of those modules use the protocol_login naming standard. Example: ssh_login . Below is an example of the ssh_login module usage.
msfconsole spool /root/ssh_login.log use auxiliary/scanner/ssh/ssh_login set USER_AS_PASS TRUE set USER_FILE /root/users.txt set PASS_FILE /root/password.txt set rhosts file:///root/ssh.txt set threads 100 set verbose TRUE show options run
Below is what it should look like if you successfully guess a password.
Here is a quick video example that shows the process of guessing passwords and gaining initial access with Metasploit.
Once you have identified a valid password you can also login using any ssh client.
Viewing Sudoers Execution Options
There are a lot of tools like Metasploit, LinEnum, Lynis, LinuxPrivCheck, UnixPrivsEsc, etc that can be used to help identify weak configurations that could be leveraged for privilege escalation, but we are going to focus on insecure sudoers configurations.
Sudoers is configuration file in Linux that defines what commands can be run as what user. It’s also commonly used to define commands that can be run as root by non-root users.
The sudo command below can be used to see what commands our user can run as root.
sudo -l
In this scenario, our user has the ability to run any command as root, but we’ll experiment with a few different command examples.
Exploiting Sudo sh
Unfortunately, we have seen this in a handful of real environments. Allowing users to execute “sh” or any other shell through sudo provides full root access to the system. Below is a basic example of dropping into a “sh” shell using sudo.
sudo sh
Exploiting Sudo VI
VI is a text editor that’s installed by default in most Linux distros. It’s popular with lots of developers. As a result, it’s semi-common to see developers provided with the ability to execute VI through sudo to facilitate the modification of privileged configurations files used in development environments. Having the ability to modify any file on the system has its own risks, but VI actually has a built-in function that allows the execution of arbitrary commands. That means, if you provided a user sudo access to VI, then you have effectively provided them with root access to your server.
Below is a command example:
vi ESC (press esc key) :!whoami
Below are some example screenshots showing the process.
Exploiting Sudo Python
People also love Python. It’s a scripting language used in every industry vertical and isn’t going away any time soon. It’s actually pretty rare to see Python or other programming engines broadly allowed to execute through sudo, but we have seen it a few times so I thought I’d share an example here. Python, like most robust scripting and programming languages, supports arbitrary command execution capabilities by default.
Below is a basic command example and a quick video for the sake of illustration:
sudo python –c “import os;os.system(‘whoami’)”
Here are a few quick video examples.
Exploiting Sudo Nmap
Most privilege escalation involves manipulating an application running as a higher privilege into running your code or commands. One of the many techniques used by attackers is to simply leverage the native functionality of the target application. One common theme we see across many applications is the ability to create and load custom modules, plug-ins, or add-ons.
For the sake of this scenario, let’s assume we can run Nmap using sudo and now we want to use it’s functionality to execute operating system commands.
When I see that an application like Nmap can be run through sudo, I typically follow a process similar to the one below:
- Does Nmap allow me to directly execute os commands?
No (only in old versions using the -–interactive flag and !whoami) - Does Nmap allow me to extend its functionality?
Yes, it allows users to load and execute custom .nse modules. - What programming language are the .nse modules written in?
Nmap .nse modules use the LUA scripting engine. - Does the LUA scripting engine support OS command execution?
Yep. So let’s build a LUA module to execute operating system commands. It’s important to note that we could potentially write a module to execute shell code or call specific APIs, but in this example we’ll keep it simple.
Let’s assume at this point you spent a little time reviewing existing Nmap modules/LUA capabilities and developed the following .nse module.
--- SAMPLE SCRIPT local nmap = require "nmap" local shortport = require "shortport" local stdnse = require "stdnse" local command = stdnse.get_script_args(SCRIPT_NAME .. ".command") or nil print("Command Output:") local t = os.execute(command) description = [[This is a basic script for executing os commands through a Nmap nse module (lua script).]] --- -- @usage -- nmap --script=./exec.nse --script-args='command=whoami' -- @output -- Output: -- root -- @args command author = "Scott Sutherland" license = "Same as Nmap--See https://nmap.org/book/man-legal.html" categories = {"vuln", "discovery", "safe"} portrule = shortport.http action = function(host,port) end
Once the module is copied to the target system, you can then run your custom module through Nmap. Below you can see the module successfully runs as our unprivileged user.
nmap --script=./exec --script-args='command=whoami'
nmap --script=./exec --script-args='command=cat /etc/shadow'
Now, you can see we’re able to run arbitrary commands in the root user’s context, when running our new Nmap module through sudo.
So that’s the Nmap example. Also, for the fun of it, we occasionally configure ncat in sudoers when hosting CTFs, but to be honest I’ve never seen that in the real world. Either way, the video below shows both the Nmap and ncat scenarios.
Wrap Up
In this blog we talked about different ways to approach SSH password guessing and attacking sudo applications. I hope it was useful information for those new the security community. Good luck and hack responsibly!
Explore more blog posts
Bytes, Books, and Blockbusters: The NetSPI Agents’ Top Cybersecurity Fiction Picks
Craving a cybersecurity movie marathon? Get recommendations from The NetSPI Agents on their favorite media to get inspired for ethical hacking.
Social Engineering Stories: One Phish, Two Vish, and Tips for Stronger Defenses
Hear real-world social engineering stories from The NetSPI Agents and tips to enhance your social engineering testing.
Hacking CICS: 7 Ways to Defeat Mainframe Applications
Explore how modern penetration testing tools uncover vulnerabilities in mainframe applications, highlighting the need for methodical techniques and regular testing to protect these critical systems from threats.