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

#bandit #bash #scripting #permissions #cron

What we know:

• We will be writing a shell script
• This shell script is removed once executed, meaning that there is likely a script that will remove our script
• The script file that the cronjob relevant to this level is located here: /usr/bin/cronjob_bandit24.sh and contains:

#!/bin/bash

myname=$(whoami)

cd /var/spool/$myname echo "Executing and deleting all scripts in /var/spool/$myname:" for i in * .*; do if [ "$i" != "." -a "$i" != ".." ]; then echo "Handling $i" owner="$(stat --format "%U" ./$i)" if [ "${owner}" = "bandit23" ]; then timeout -s 9 60 ./$i fi rm -f ./$i fi done

What to do with what we know:

First, let's understand the cronjob_bandit24.sh script:

1. #!/bin/bash indicates which shell program will be used to interpret the script — in this case: bash (Bourne Again Shell).

2. An variable is initiated and saves the results of the whoami command. (To verify that the current user is bandit23, I ran the whoami command inside of the directory where the script is located.) We navigate to a directory based on this variable: `/var/spool/bandit23'

3. A loop will initiated through all the files in this directory and for the files that are not equivalent to . or .., we (1) save data from the stat command regarding the file into the variable owner then we (2) check if the file owner is bandit23 and if so, (3) the file is deleted after 60 seconds.

(There's more but these are the most crucial steps to understand for our goals.)

So I attempted to navigate to the bandit23 directory (/var/spool/bandit23/) and received the error message that: -bash: cd: bandit23: No such file or directory

Going back one step into /var/spool/, I discovered that bandit24 exists as a directory. What does this mean?

Mistake 1: Checking Permissions

I thought that the /usr/bin/cronjob_bandit24.sh permissions could be checked from running whoami from the /usr/bin directory in which the file was found. Of course this is not true because whoami checks the current user and not the file. I knew this but I didn't pause to consider what exactly I was checking for when I mindlessly ran whoami. This error is silly, I should have been more mindful as to exactly what I am asking the computer to do in every command I make.

So to check the owner of the script in question, I ran: ls -alh cronjob_bandit24.sh

-rwxr-x--- 1 bandit24 bandit23 376 May 14 2020 cronjob_bandit24.sh

This means the script cronjob_bandit24.sh belongs to owner bandit24 and group bandit23. Now it makes sense that /var/spool/bandit23/ did not exist.

Back on track

I navigated into bandit24 directory and attempted to make a temporary directory only to discover that tmp already existed. (ls was denied.) Inside of tmp, I create a script that copies the password file from where it's located into where I can access it as bandit23.

!#/bin/bash cp /etc/bandit_pass/bandit24 /tmp/emin/pass

Then I created the directory tmp/emin/ and the file pass.

I moved a copy of the script into the relevant directory (/var/spool/bandit24') and waited for my password to appear in/tmp/emin/pass` but it never did!!

MISTAKE 2: Permissions Denied

I tried to execute my script myself using the command:

bash /var/spool/bandit24/tmp/lumpo.sh (yes, that's my script name..) and received the error message:

cat: /etc/bandit_pass/bandit24: Permission denied

I wasn't sure where exactly the error was triggered: was it the execution of the cat command on the original password file or was it the act of writing it onto the file I created? So I decided to check permissions on the files:

My script file is owned by bandit23. My script is run by a server-provided script (/usr/bin/cronjob_bandit24.sh) owned by bandit24.

It needs to read a file owned by bandit24 and write its contents into the file I created and therefore owned by bandit23. This means that the file owned by bandit24 must have permissions for user bandit24 to read its contents and the file I created must have permissions for user bandit24 to write its contents. The assumption I'm making is that because my script file is run by another script file owned by bandit24, it will belong to that user? FOLLOW UP

Checking permissions for the original password file: ls -alh /etc/bandit_pass/bandit24 gives me this information:

-r-------- 1 bandit24 bandit24 33 May 7 2020 /etc/bandit_pass/bandit24

I know that each file or directory has three permission types: read, write, execute. According to the Linux docs:

The first character is the special permission flag that can vary. The following set of three characters (rwx) is for the owner permissions. The second set of three characters (rwx) is for the Group permissions. The third set of three characters (rwx) is for the All Users permissions. Following that grouping since the integer/number displays the number of hardlinks to the file. The last piece is the Owner and Group assignment formatted as Owner:Group.

An example: _rwxrwxrwx 1 owner:group

So we can conclude that since the original password file can be read by the owner that runs it, this not the source of the problem.

Checking permissions on my file ls -alh /tmp/emin/pass gives:

-rw-r--r-- 1 bandit23 root 0 Jan 3 20:38 /tmp/emin/pass

This means that only the owner (bandit23) can read and write to this file. Otherwise, it is read-only.

So I ran chmod 777 on the file which gives full permission to access the file and verify that it is so: ls -alh /tmp/emin/pass

-rwxrwxrwx 1 bandit23 root 0 Jan 3 20:38 /tmp/emin/pass

Now if I try the script again, it should work! ALAS IT DID NOT!!!!!

Now questioning whether the permissions for the directory containing the file needed also to be changed? So I ran the same chmod 777 command recursively from the /tmp/emin directory.

STILL DIDN'T WORK!!!!

The only other file that does not have full permissions and that I have the ability to change is my script. So I changed it to full permissions and it worked. But why?

What is the difference between this file having full permissions: -rwxrwxrwx 1 bandit23 bandit23 59 Jan 3 20:35 lumpo.sh

Vs. read-only permissions? -rw-r--r-- 1 bandit23 bandit23 59 Jan 3 21:33 lumpo.sh

Remember that this file contains the script that copies the password from the bandit24 file to my file: cp /etc/bandit_pass/bandit24 /tmp/emin/pass

Why would my script need write permissions?! This doesn't make sense...

Follow-up Questions:

• What are the usage differences between a (POSIX) shell and bash?
• Why did cp but mv and cat work? Are there permissions blocking copying files on this server? Likely.

What I learned:

PERMISSIONS COME FIRST.