#overthewire #wargames #leviathan #linux #ctf

There is no information given regarding these levels. Upon sshing into Lv1, I found a program called check that according to the file command is:

check: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=c735f6f3a3a94adcad8407cc0fda40496fd765dd, not > stripped

Running ./check gives us a prompt for password: so I tried the only password I currently have (from entering this level) and nothing.

Decided to track down this /lib/ld-linux.so.2 directory mentioned. Tracing all the symbolic links gets us to this file: /lib32/ld-2.24.so. Running the file goes us:

You have invoked ld.so', the helper program for shared library >executables. This program usually lives in the file/lib/ld.so', and >special directives in executable files using ELF shared libraries tell the >system's program loader to load the helper program from this file. This >helper program loads the shared libraries needed by the program >executable, prepares the program to run, and runs it. You may invoke >this helper program directly from the command line to load and run an >ELF executable file; this is like executing that file itself, but always uses >this helper program from the file you specified, instead of the helper >program file specified in the executable file you run. This is mostly of >use for maintainers to test new versions of this helper program; >chances are you did not intend to run this program.

So researching how to analyze Linux binaries gives us a list of commands to explore:

ldd –> print shared object dependencies. Used to run against dynamically linked binary to show its dependent libraries and their paths. Running this on check binary shows:

linux-gate.so.1 (0xf7fd7000) libc.so.6 => /lib32/libc.so.6 (0xf7e12000) /lib/ld-linux.so.2 (0xf7fd9000)

Which is info we had already ascertained from following the breadcrumbs. But at least next time, I won't need to follow the breadcrumbs.

ltrace –> displays all the functions that are being called at run time from the library. (Function names, arguments being passed into that function, and what is returned.)

hexdump –> display file contents in ASCII, decimal, hexadecimal, or octal

strings –> print the strings of printable characters in files

readelf –> display information about ELF files

objdump –> reads the binary or executable file and dumps the assembly language instructions on the screen.

strace –> traces system calls aka calls that interface with kernel

nm –> list symbols from objects > if using a binary that was not stripped, you can identify variables, functions, and other valuable info embedded in the binary during compilation

gdb –> GNU debugger: load a program, set breakpoints, analyze memory and CPU register, etc.

But what is relevant here?

Let's try ltrace check. Immediately we get prompted for the password along with information about the function calls behind that prompt:

__libc_start_main(0x804853b, 1, 0xffffd744, 0x8048610 <unfinished ...> printf("password: ") = 10 getchar(1, 0, 0x65766f6c, 0x646f6700password:

This means that the functions __libc_start_main, printf, and getchar were called in order to run the program up to the password prompt. Entering a password of rioGegei8m gives the following output:

getchar(1, 0, 0x65766f6c, 0x646f6700password: rioGegei8m ) = 114 getchar(1, 0, 0x65766f6c, 0x646f6700) = 105 getchar(1, 0, 0x65766f6c, 0x646f6700) = 111 strcmp("rio", "sex") = -1 puts("Wrong password, Good Bye ..."Wrong password, Good Bye ... ) = 29 +++ exited (status 0) +++

It looks like we used the getchar function for stndin then we called strcmp for matching rio to sex. I'm assuming that only the first three characters of my password attempt was matched because the password is only three characters longs. I will pretend not to judge that the password for here is `sex. Really?

Entering the password into the ./check binary brings us to a shell. Immediately, let's check whoami and echo $0 which tells us that we are levianthan2 and our shell is /bin/sh.

Let's check the leviathan2 home directory. There is a file called printfile that is a setuid regular file with no read permission. Checking permissions show that:

-r-sr-x--- 1 leviathan3 leviathan2 7436 Aug 26 2019 printfile

This file belongs to leviathan3 user and the group leviathan2. The s in the permissions for leviathan3 user means that the setuid bit is set, and the execute bit is set. According to research: “A file with SUID always executes as the user who owns the file, regardless of the user passing the command. But when I try to execute the file, I still get /bin/sh: 31: ./printfile: Permission denied.

Tried to change permissions for

$ chmod u-s printfile chmod: changing permissions of 'printfile': Operation not permitted

Thinking more about the permissions and checking my own with id:

uid=12002(leviathan2) gid=12001(leviathan1) groups=12001(leviathan1)

Turns out that even though I have managed to set my uid to leviathan2 from running the check binary, I am still in the leviathan group. Let's learn more about the s permissions:

“The setuid bit simply indicates that when running the executable, it will set its permissions to that of the user who created it (owner), instead of setting it to the user who launched it.”

A very, long deep dive time later...

Yeah, I just realized I didn't check the regular ol' etc/leviathan_pass/leviathanLVL file.. and there it was. The password.

---

Random Notes on New Knowledge

openssl to generate password + salt!

$ openssl passwd -1 "hello world" $1$Y3FAzTxG$/I/sykzmytIduJwbL4mjo1 $ openssl passwd -1 -salt "my salt" "hello world" $1$my salt$lY65QUBqL1JO3LEh3ENqe.

The shell escape feature/exploit

• check sudo privileges: sudo -l
• use sudo to go into a command to check if current user can execute any commands without password entry
• if so, run that with sudo, for example: sudo /usr/bin/man man to run the man command on man with sudo
• then drop into a bash shell with !/bin/bash

---

About Me

#whoami #cv #extendedcv #favouritebooks #philosophy #email #me #at #yffenim@protonmail.com #guaranteed #slow #reply

---

CTF Learning Journey

#bandit #overthewire #hackthebox #leviathan

---

Infosec Concept Notes and Cheatsheets

#threatmodeling

---

UofT Cybersecurity Bootcamp

#UofTBootcamp #classwork #homework #classwork

---

Homelab Experimentations

#brainstorm #config_1

---

Searchable Tags by Topic

#ssh #nmap #nc #git #grep #awk #ps

---

Other Careers

#activism #poetry #prose #fiction #literature #movementtherapy #personaltraining

#SSL #SSH #NC #nmap #bandit #overthewire #linux #cli

Level 13 –> 14

In this level, we were given: – “a private SSH key that can be used to log into the next level”

Upon examination, there was a RSA key in the file sshkey.private. The goal is to use this key to login to the next level.

_What is immediately different about how we are asked to log in here vs previous levels?

• Previously, we had to exit the connection and SSH into the server using the next username and password. This time, we must use the next username and RSA key.

To log in using a private SSH key, we use: ssh -i sshkey.private bandit14@localhost

We are staying on the same server (localhost) so we don't need to specify the port number.

Level 14—>15

We are asked to submit data to port 30000 on localhost in order to retrieve the next password.

The utility nc (netcat) allows us to “read or write data across network connections using the TCP or UDP protocols”. The basic syntax is: nc [options] host port

The data we needed to send is a file called bandit14 so we used: less bandit14 | nc localhost 30000 to solve this level.

QUESTION: Can I log into LV15 from within the server?

Yes! It worked to use SSH bandit15@localhost! Yay for learning to be more efficient!

Level 15 –> 16

In this level, we are asked to submit “the password of the current level to port 30001 on localhost using SSL encryption”.

Tools to explore: openssl, client_s

s_client will connect to “a remote host using SSL/TLS.”

QUESTION: why does it specify that it connects to a remote host? What about connecting to a service on localhost?

What I tried (unsuccessful):

openssl s_client -connect localhost:30001

I knew this wouldn't work because I wasn't sending the password. But it did say CONNECTED. Unfortunately, it kept waiting for something and I wasn't sure how to interpret this so I looked up a hint online. It turns out it was waiting for a password! There was no password prompt so I didn't think to try sending any input. Had I tried sending _anything at all, I would have received a wrong password message and realized what was happening!

LESSON LEARNED: TRY EVERYTHING!!!

The answer turned out to be: openssl s_client -connect localhost:30001 $PASS (with the password string saved in $PASS)

Level 16 –> 17

In this level, we have to (1) scan for open ports for a server that listens to SSL and then (2) forward the response credentials to login to the next level.

I used nmap -p 31000-32000 localhost to scan for the ports on localhost between 31000-32000 (the range given in the instructions). This returned only 5 active ports (yay!):

Starting Nmap 7.40 ( https://nmap.org ) at 2021-12-31 02:52 CET Nmap scan report for localhost (127.0.0.1) Host is up (0.00033s latency). Not shown: 996 closed ports PORT STATE SERVICE 31046/tcp open unknown 31518/tcp open unknown 31691/tcp open unknown 31790/tcp open unknown 31960/tcp open unknown

Then I manually attempted an openssl s_client connection to each port to see if there would be a response.

I found that port 31790 responded with the credentials (an RSA key). I then created a temporary file containing this key and attemped to SSH into the next level using the method from a few levels back: ssh -i lumpo.private bandit17@localhost

Unfortuately, this did not work because I got this warning back:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'lumpo.private' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored.

So now my options are to either (1) set permissions for my temporary file so that it is not accessible by others, or (2) find a way to forward the credentials automatically when they are returned from the server.

Trying (1) first:

chmod 600 /tmp/lumpo.private will restrict my file so that the owner (me) has access to read/write but nobody else can do so. Retried sending ssh with private key after adding this permission restriction and success!

What I could have done better?

Instead of manually testing each listening port with openssl s_client, I should have figured out how to automate it because testing manually would not work for a large pool of ports.