#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

#UofTBootCamp #classwork #linux #permissions #users #groups #su #sudo #less #more #shellbreaking #shellexploit #exploit #escapeexploit

Running commands from inside of less with sudo access

Run !bash inside of less to drop to a root shell

sudo

sudo and su basics

su substitute user identity sudo execute a command as another user

sudo -l will list (if no command is specific) the allowed/forbidden commands for the invoking user (or a specific user if -U). If a command is specific, it will list the “fully-qualified” path to the command.

sudo -lU <user> to check if has can run sudo OR sudo -nv

Updating the /etc/sudoers/ file withvisudo`

sudo visudo to see the file john ALL=(ALL:ALL) /usr/bin/apt, /usr/bin/less to give john access to run apt as root and less

Syntax for /etc/sudoers/

The first ALL is the users allowed (john) The second one is the hosts (ALL, as in all machines) The third one is the user as you are running the command The last one is the commands allowed

Activity 1

Determine what sudo activities the sysadmin user has using sudo -lU sysadmin:

(ALL : ALL) ALL meaning that sysadmin user can run on all commands as root on all hosts.

Record what access each user on the machine has:

Find all real users:

grep -E '^UID_MIN|^UID_MAX' /etc/login.defs to find the range for the real users on the machine.

getent passwd {1000..6000} to display only those users.

However, this does not tell us what commands each user has effectively bc I would now have to manually search each one then save that into a file.

Display all users:

awk -F':' '{ print $1}' /etc/passwd OR compgen

Display all sudo users:

getent group sudo | cut -d: -f4

grep '^sudo:.*$' /etc/group | cut -d: -f4

Find the user who has sudo access to the less command

cat /etc/sudoers | grep less

Switch to Root

sudo su root

Check for users or groups

grep <user or group name> /etc/passwd or group

Users and Groups

UID over 1000 = standard user

groups or groups <user> prints your user's groups to the screen

id prints the groups + GIDs

sudo usermod -L <user> to lock the account

sudo usermod -G <group-to-remove> <user> to remove from a

sudo deluser --remove-home <user> to remove

--remove-home flag removes the home folder, too

`sudo usermod -aG to add to the

Activity 2

1. Use a command to display your ID info.

2. Use the same command to display the ID info for each user on the system.

– In case you forgot, how can you learn what these usernames are? – Record the output from this series of commands to a new file in your research folder.

3. Print the groups that you and the other users belong to.

– Record the output from this series of commands to a new file in your research folder.

4. Document in your research folder anything suspicious related to any of the users.

– Hint: Are there any users that shouldn't be there?

5. Make sure you have a copy of the home folder for any rogue users and then remove any users from the system that should not be there. Make sure to remove their home folders as well.

Hint: Remember from the first activity, the only standard users that should be on the system are: admin, adam, billy, sally and max.

1. Verify that all non-admin users are part of the group developers.
   • If the developers group doesn't exist, create it and add the users.

#linux #networking #router #automation #bash #python #ruby

The suggest from my tutor was to “write an automation script that goes into my router and pulls the logs from the router logs to system logs and then scans them for any occurrences of nmap and sends the results to me in an email. Possibly filtering by priority?

To Research

Router Access

• does my router have logs accessible
• can my router easily transfer those logs to my system logs or do I have to manually do that?

System logs

• where is the appropriate place to put them?

Cron job

• set it up where?

Email server

• can I send it directly to my thundermail client or does it have to go through gmail?

Additional Practice

• redo this assignment using my linux machine?
• redo in py?

#UofTBootCamp #classwork #linux #processes #ps #grep #awk

Given a VM with a shady user running a shady script...

###...list all processes running in real time

top for finding running processes in real time

lsof -u jack for finding jack's processes lsof | grep jack for highlighting ps aux | grep jack

How many tasks have been started on the host?

ps aux | wc -l ps aux | grep jack | wc -l ^ not great because grep has not filtered out occurrences of jack elsewhere

ps -eo user | grep jack | wc -l -o allows you to specify format -e selects all processes, including those of other users

ps -U jack -u jack u every process running as jack (real and effective ID) in user format?

How many are these are sleeping?

ps -U jack -u jack u | awk '{if ($8=="S" || $8=="D") print $0' | wc -l (1 process is sleeping)

ps -eo user,state | awk '{if ($2=="S" || $2=="D") print $1,$2}' | wc -l

Which process uses the most memory?

ps -eo user,pid,cmd,%cpu,%mem --sort=-%mem | head -20

Search all running processes by a specific user

ps -eo user,pid,cmd,state | grep root | awk '{if ($4=="R") print $1,$2,$3, $4}'

ps -U root -u root u | awk '{if ($8 == "R") print $0}'

BONUS:

List all processes with a TTY terminal

ps -t ps -eo pid,tty,cmd | grep pts

Identify the ID of suspicious processes:

ps -eo pid,user,tty,cmd | awk '/str.sh/{print $0}' – returns the matches including the awk command process

ps -eo pid,user,tty,cmd | awk '/[s]tr.sh/{print $0}' – adding the [] around the first character will avoid matching the awk command itself

ps -t | grep "[s]tr.sh" | awk '{print $0}'

WHY DOESN'T A WILDCARD WORK HERE?????

ps -t | grep “*.sh” |

#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.