Learning Linux & InfoSec Principles Using OverTheWire’s Bandit — Part 5
Begin learning Linux using a fun, online “wargame”
Introduction
In the previous post (https://bit.ly/3qFZACp) we have continued our Linux journey with levels 14 through 18 of OverTheWire’s Bandit machine. If you haven’t read the four first posts yet, they are warmly recommended — you’ll have an even better intro.
In essence, Bandit is the most basic machine the OverTheWire.org website has to offer, designed to introduce people to basic Linux commands and information security ideas.
The goal of this article is to provide you with a practical and enjoyable way of getting to know the Linux operating system (particularly the bash shell), using the Bandit “wargame”. If you have already read the previous posts, or are too enthusiastic to get on with this one (I completely understand that :)), then let’s dive in.
Level 18 → Level 19
At the end of the previous article, we found the password to Level 18: kfBf3eYk5BPBRzwjqutbbfE887SVc5Yd. Let’s use it to log into this level, as usual.
ssh bandit18@bandit.labs.overthewire.org -p 2220
Oh Oh! What happened? We provided the right password, and it seems like the authentication process succeeded, but we are immediately kicked out of the server, getting the message “Byebye!”.
Don’t be scared! Let me show you the appendix to the instructions for level 17:
So we need to progress to level 19. The instructions are:
We gather that we must check the contents of the readme file in the home directory. Remember that in the last post I recommended to keep the password to it? Now we’ll use it for an initial access that would help us surpass the “error”. The password is: xLYVMN9WE5zQ5vHacb0sZEVqbrp7nBTn. But once logged in, we discover we have no permission to read the relevant file, and even local connection to bandit18 cannot be achieved.
Moreover, we are told the reason why we are left outside even though the password is correct: someone modified the .bashrc file. This is a shell script that initializes interactive sessions with the terminal. It defines a couple of properties, in our case that an SSH login to bandit18 will instantly kick the user out.
So we have to find a way to execute the command before we are logged out, or without even fully logging in. Luckily, we can use SSH to send a single command to be executed. To do this, we append the command in quotes ‘’ at the end of the SSH line.
ssh bandit18@bandit.labs.overthewire.org -p 2220 'cat readme'
The home directory is the default login directory and we know the name of the file, so we successfully acquire the password for the next level.
Level 19 → Level 20
To continue to the next level, we need to take advantage of the setuid binary file in the home directory. A binary file is an executable, and we are told to execute it without arguments to comprehend how it works.
We’ll do that in a second, but first let’s explain what is the setuid. This is a property of a file, that if turned on, means that running the file won’t be by the user who actually runs it, but by the user who owns it. If we run ls -l:
Can you spot the single “s” on the left? This testifies that the setuid bit is indeed turned on. Now, if we execute the binary, we won’t be the user that manages the process, and whose permissions are inherited to the process — the owner will run it, and the process will have his permissions. We can see that the owner is the next level, bandit20. Let’s execute the script:
We are given an example. We can provide an argument after the script name, and this will be ran as a command by the user bandit20. Let’s try the whoami command. It tells us which user are we, and as we can see, using it with the script shows bandit20, and without it — bandit19.
Now, let’s run a more useful command, to read the password for the next level, which is stored in the /etc/bandit_pass/ directory inside the file bandit20, which can only be read by this user.
By utilizing the script, we acquired the permissions of the bandit20 user and read the password. Let’s carry on.
Level 20 → Level 21
Wow, this is a long passage!
Let’s summarize it. Again, we have a setuid file that connects to localhost, to a specific port. Then it reads the message it receives, and compares it to the password of the current level. The hint provided directs us at creating our own “network daemon” — this means a listener to connections, a dummy “server”, on which we will be able to control, and thus send the running setuid script the right password.
To set up this server, we will use netcat:
We have already dealt with the netcat command, but let’s review the meaning of the parameters. The l declares that we want to listen to incoming connections. The v stands for verbose, which we provide to tell netcat to show us as much data as possible. Last but not least, the p is used to specify the port, typed later — 1234.
But now it seems as though we are stuck, since netcat just waits for connections — but we are supposed to initiate them, all the same! To tackle that, we will pause this process, to be waiting-for-execute in the background, by hitting Ctrl+Z. Now, we will run the setuid script with the appropriate port: ./suconnect 1234
Again, this also waits — remember, it needs to inspect the message received from the connection. So we need to pause this process as well and return to the previous one. Again, hit Ctrl+Z.
To re-activate the original process, we use the numbers written on the left — the command for retrieving a background process is fg {process number}, which stands for “foreground”. After the fg 1 , we see the evidence for the connection we have made. Now, let’s send the password for level 20.
The goal for all this is the output from the suconnect script — so we need to return to. You already now how to pause the current process and move the other, whose number is 2.
The next password was sent, so to view it we will return to the netcat one.
And this is done.
Level 21 → Level 22
Let’s sum up the details provided: there is a relevant program that runs regularly using cron — this is an important part of Linux — it is called job scheduler, and as the name suggests, it manages processes to be ran at certain times. Its settings and commands to execute are specified in the /etc/cron.d/ directory, which configures cron. Let’s enter this directory and see what we have inside.
The file we should probably inspect is the one corresponding our current level. let’s read it.
It may look like a meaning-less mumble, but bear with me: the first segment defines the frequency/event/time to run the job at — the first line specifies to do it on reboot, the second line specifies “every minute”. Next, the responsible user it provided, and after it the command to be ran. In our case, a script is executed, and its output is discarded (the /dev/null is a file describing a device that discards all info written to it).
That is interesting! Let’s examine this script ourselves.
A .sh file in Linux is an executable script, that is able to perform commands we are used to type at the command line. This script has 3 lines. Their roles:
- Specify the interpreter for the script — basically who is responsible for “translating” the script to instructions the computer can understand. This is the bash shell, with which we always work, and thus regular commands we know can be used.
- Change the permission of the /tmp/t7O6lds9S0Rq….. File so that everyone would be able to read it. We won’t delve into permissions now.
- The interesting part: reads the contents of the file that stores the password for level 22, and redirects the output to the file in the /tmp directory. Remember: the second line specified that we are allowed to read this file!
So all we need to do is read the relevant file and discover the password:
Congratulations! We did it. Now keep this password until the next article :)
Conclusion
The several levels we have solved in this article introduced us to more advanced concepts and aspects regarding the Linux OS. We gradually discover more and more, main segments of the operating system that runs the world: setuid, cron, pausing and resuming processes…
I hope you have learned and improved your Linux skills throughout this article. As mentioned previously, I pray you have also had fun! Please leave some comments and let me know what you prefer me to do or want me to cover otherwise.
I must thank each and every one of you who reads my posts — you are amazing. Goodbye for now. Have a great time until we meet again!
