Zero Trust and Feature Exploits: vi/vim, more
Welcome back to the 11th iteration of this blog series. In this series, we’re growing our cybersecurity knowledge starting from the very basics using the overthewire.org challenges as a guide. First, I’d like to thank everyone for their feedback based on the last post! I’ll do my best to implement it and as always, more feedback is always welcome. Now let’s start!
Picking up from bandit25, we’re told that logging into 26 should be pretty easy but that there’s a problem with the shell. We don’t know the password for bandit26 but let’s see what we can find:
Let’s use this private key to log in:
Something happened then we got logged out. Let’s check the default shell for bandit26. We can do this by looking at the passwd file. The passwd file is the list of all users on a machine and their default shells. It’s located at /etc/passwd:
So the default shell is some “showtext” file, let’s examine it:
So this is a shell script that calls more on some file called “text.txt” in the home directory of bandit26. If you recall, more is a featured version of cat (to keep it simple). It opens a text file and lets us scroll through it if our screen is not big enough (compared to less which just opens the file in a “scrollable” format regardless of how big our screen is). Let’s take a look at what we can do with more (check the man page):
We can hop into vi from more which would let us have more control. But first, how do we get to the point where we can do that? Make our terminal as small as possible. Let’s try that and get into vi:
We’ve talked about vim and vi before. They’re powerful CLI text editors and are full of cool features. One of those features is being able to open other files or even execute shell commands. We can even designate what the path to shell is:
Then we can enter that shell with “:shell”:
Cool, let’s grab bandit26’s flag:
Making the window smaller to “trigger” the scrolling function of more is a bit of an interesting gimmick to make things more fun. The point this presents, however, is that features oppose security. Much like how convenience and security tend to oppose each other, adding more features to a program allows for more loopholes.
Even though more in of itself didn’t have any crazy features like executing a shell, the flaw was that it let us use vi. vi is so feature-packed that we exploited that to get a shell.
Continuing on from our bandit26 shell, let’s see what we have:
We already know how to abuse this:
Wow! We solved 2 levels by really just solving one.
As security analysts, our job is to find the loopholes in existing security configurations. Assuming that bandit25 was a hacker who managed to steal the private key of bandit26, the “security” controls of bandit26 were (seemingly) good enough to keep anyone from logging in. But abusing features is the nature of hacking. In most cases, especially in our day and age, even default configurations on machines are relatively good at protecting their users. Hackers have to find a feature (service) to abuse and exploit that lets them get access.
In this case, bandit27 trusted bandit26 to do things on their behalf. Unfortunately for bandit27, this trust is exactly why their flag was captured. This introduces the “zero trust” idea in cybersecurity. Zero trust means just that: don’t trust anyone who isn’t you. It doesn’t necessarily mean you have to do everything yourself but it means that you need to check your trust relationship’s security configurations before giving them access to your system.
