Consolidation

 Publ .

 Mins 8 (1622 words).

 Edit .

Consolidation

Moving forward, the game seeks to extend, improve and reinforce the tools and concepts from the previous levels. The levels do not bring much new stuff to the table, but will teach you a couple of idioms regarding the inner workings of the system.

Having done a thorough research for the previous levels, is your ticket to move on in a breeze. Proper understanding of basics and fundamentals, is, as usual all that’s need.

Note that its possible to ‘solve’ many of these levels in several different ways.

Index


LEVEL 17 -> LEVEL 18

There are 2 files in the homedirectory: passwords.old and passwords.new. The password for the next level is in passwords.new and is the only line that has been changed between passwords.old and passwords.new

NOTE: if you have solved this level and see ‘Byebye!’ when trying to log into bandit18, this is related to the next level, bandit19

Commands you may need to solve this level
cat, grep, ls, diff

Using wc --lines you see that both files to check have 100 lines each. Finding
the solution by visual inspection is painful. Focus on this fact: the password is in the file with extension .new, and all its lines are exactly the same as in the .old file, except for the line that is the password.

The grep manual says it can uses files as a search patterns. By combining the argument -f (or --file) with -v or (--invert-match) grep outputs all non-matching lines between the .new and the .old file, yielding the password.

$ grep -v -f passwords.old passwords.new

hga5tuuCLF6fFzUpnagiMN8ssu9LFrdg

Upon login, the “Byebye !” message followed by connection termination means that the password is correct.

EXTRA

You could also obtain the password by using the diff program. It takes as input to files and will list the changes needed to turn one file (the “old_file”) into the other (the “new_file”).

$ diff passwords.old passwords.new 
42c42
< U79zsNCl1urwJ5rU6pg7ZSCi7ifWOWpT
---
> hga5tuuCLF6fFzUpnagiMN8ssu9LFrdg

The first line of the output is a change command indicating that if you interchange line 42 between files, they will have the exact same data. They only differ on this line.


LEVEL 18 -> LEVEL 19

The password for the next level is stored in a file readme in the home directory. Unfortunately, someone has modified .bashrc to log you out when you log in with SSH.

Commands you may need to solve this level
ssh, ls, cat

You are not allowed to remain connected via SSH, but you have a connection anyways. SSH’s man pages indicate that it has the capability to specify a command instead of starting a shell session. Because the exact location of the password file is given, cat should do the job:

$ ssh bandit18@bandit.labs.overthewire.org -p 2220 'cat ~/readme'
                         _                     _ _ _   
                        | |__   __ _ _ __   __| (_) |_ 
                        | '_ \ / _` | '_ \ / _` | | __|
                        | |_) | (_| | | | | (_| | | |_ 
                        |_.__/ \__,_|_| |_|\__,_|_|\__|
                                                       

                      This is an OverTheWire game server. 
            More information on http://www.overthewire.org/wargames

bandit18@bandit.labs.overthewire.org's password: 
awhqfNnAbc1naukrpqDYcF95h7HoMTrC

LEVEL 19 -> LEVEL 20

To gain access to the next level, you should use the setuid binary in the home directory. Execute it without arguments to find out how to use it. The password for this level can be found in the usual place (/etc/bandit_pass), after you have used the setuid binary.

Helpful Reading Material
setuid on Wikipedia

You are dealing with a file that has special permissions. The simplest way to describe a setuid binary is that the system execute this file abiding by the following rule: “when this files runs, it runs with the identity of the owner of the file rather than the person who is executing it.”

The command ls -l helps you further explore the permissions and ownership of the file:

$ ls -l
-rwsr-x--- 1 bandit20 bandit19 14872 Sep  1 06:30 bandit20-do

They keys are the first, third and fourth columns of this output.

  1. The first column -rwsr-x--- should be interpreted as follows:
  • The first character of this string indicates with a dash if the file is a regular file, or a ’d’ if its directory.
  • The rest of the string is interpreted as three different columns:
    • Three characters state permissions for the owner.
    • The next three for group.
    • The final three the permissions for others.
  1. The third column, which reads bandit20 is the name of the owner of the file.

  2. Finally, bandit19 is the group of this file.

Most of the files a regular user deals with on a day to day basis have permissions of r=read, w=write and x=execute. For instance, a hypothetical file that reads:

-rwxrw-r-- 1 Alice Bob ..... ...  . ..... .......
  • Is a regular file, because the first character is a dash.
  • It has read write execute permissions for the owner. Alice can read, write, and execute this file.
  • Has read write permissions for the group. Every user on the group Bob is allowed to read and write this file.
  • Only read permissions for others. This means that any user that is not Alice and don’t belong to the group Bob are only allowed to read this file.

Observe that the bandit20-do binary has permissions r-x for the group bandit19. Every user on group bandit19 is allowed to read an execute this file. But it has the special permission rws for its owner bandit20. The s character is indicates that this file has the setuid flag on. It will be executed with permissions of the owner regardless of who runs it.

This is its default output:

$ ./bandit20-do

Run a command as another user.

 Example: ./bandit20-do id

Knowing that all passwords are stored in the folder /etc/bandit_pass/, you can use this executable to make bandit20 concatenate its own password file for you:

$./bandit20-do cat /etc/bandit_pass/bandit20
VxCazJaVykI6W36BkBU0mJTCM8rR95XT

LEVEL 20 -> LEVEL 21

There is a setuid binary in the homedirectory that does the following: it makes a connection to localhost on the port you specify as a commandline argument. It then reads a line of text from the connection and compares it to the password in the previous level (bandit20). If the password is correct, it will transmit the password for the next level (bandit21).

NOTE: Try connecting to your own network daemon to see if it works as you think
Commands you may need to solve this level
ssh, nc, cat, bash, screen, tmux, Unix ‘job control’ (bg, fg, jobs, &, CTRL-Z, …)

You deal again with a setuid binary. Once logged in the first thing you might do is execute the binary to see its default output:

$ ./succonect

Usage: ./succonect <portnumber>

  This program will connect to the given port on localhost using TCP. If it 
  receives the correct password from the other side, the next password is 
  transmitted back.

You are going to need some sort fo networking utility to accomplish this goal. In Level 14 -> Level 15 we established a TCP connection using telnet. This time we are going use netcat which is commonly known as “a TCP/IP Swiss Army Knife” because of its many functionalities.

In man netcat the DATA TRANSFER section contains specific directions for establishing a model similar to this level. You need only to recreate one part of the equation. First, write the password of the previous level to a file. Then, use netcat to transfer it to a specific port and while the program is running, initiate a connection with the succonect binary.

$ mkdir /tmp/foobarbaz/
echo "VxCazJaVykI6W36BkBU0mJTCM8rR95XT" > /tmp/foobarbaz/lvl20pass.txt

Now, just follow along the manpage’s instructions. You have to choose a port and use the input redirection operator < to transfer the file containing the password.

This establishes our server-side of the connection. But you need netcat running and at the same time use the terminal to open client request with succonect.

To sort this difficulty, you should understand Linux’s job control commands. A job is a process that the shell manages. It has three possible statuses:

  1. Foreground jobs occupy the terminal window, i.e. any command we normally enter on the terminal is a foreground job.

  2. Background jobs are running until completion but they do not occupy the terminal window by default. To push a process to the background you add an ampersand sign & at the end of the command. This frees the terminal to be used while the process continues its execution. The shell will assign a job number (in the form of %n) and a process ID (PID) to the background job, which can be used to manage the task using the job control commands.

  3. Stopped jobs are tasks that are placed in background by using the control character Ctl-Z.

The commands for job control are:

  • jobs: List all jobs. Printed information consists of the job ID between square brackets followed by a + or - sing meaning current and next job respectively. Then, state of the job (running, stopped, terminated, etc.) and finally the actual command of the job.

  • bg %n: Place the job whose ID is %n in the background.

  • fg %n: Bring back to foreground the job whose ID is %n.

  • Crl-Z: Pause a foreground job and send it to the background on the stopped state.

You might need some practice to get the gist of these commands. The procedure for retrieving the password is the following: First start your data transfer sending it to the background. Then use the suconnect binary, procuring specifying the correct port:

$ nc -l 1234 < /tmp/foobarbaz/lvl20pass.txt &
[1] 4134331
$ ./suconnect 1234
Read: VxCazJaVykI6W36BkBU0mJTCM8rR95XT
Password matches, sending next password
NvEJF7oVjkddltPSrdKEFOllh9V1IBcqxt

[1]+  Done                    nc -l 1234 < /tmp/foobarbaz/lvl20pass.txt