old notes

cron

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

#cron #crontab #cronjobs

LV 21 —> 22

This was a straight-forward level with a linear problem-solving narrative.

What we know:

“A program is running automatically at regular intervals from cron, the time-based job scheduler. Look in /etc/cron.d/ for the configuration and see what command is being executed.”

What I did with this knowledge:

First, I navigated to the /etc/cron.d directory and researched what this directory contains.

Cron reads the files in /etc/cron.d/ directory. Usually system daemon such as sa-update or sysstat places their cronjob here.

So I understand the /etc/cron.d/ directory to be files read by cron the utility.

I decided to try to run the cronjob most relevant to my goals: crontab cronjob_band22

The response was: /var/spool/cron/: mkstemp: Permission denied

Then I decided to take a look at the cron by using less which gave me:

@reboot bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null * * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null

I then researched the syntax of a cronjob which is:

a b c d e /directory/command [output]

The first section (a b c d e) contains 5 field options to indicate the date/time/re-occurrence of the job.

The second section is the location and script you want to run.

The third section is optional and indicates the output.

In this case, our script is located at /usr/bin/cronjob_bandit22.sh and the output is disappeared into the void of /dev/null.

So I navigated to /usr/bin/ to read the cronjob script (yes, I'm aware I could have done this without navigating there!) and used less to see this script:

#!/bin/bash chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv /usr/bin/cronjob_bandit22.sh (END)

I interpreted this to mean that the output to the cronjob was being saved in a file called t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv in the /tmp folder.

I used less t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv and viola! The password is mine!

What I could have done better:

What is the difference between the file in etc and bin?

running diff /usr/bin/cronjob_bandit22.sh /etc/cron.d/cronjob_bandit22 gives a comparison:

`1,3c1,2 < #!/bin/bash < chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv < cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv


@reboot bandit22 /usr/bin/cronjobbandit22.sh &> /dev/null * * * * * bandit22 /usr/bin/cronjobbandit22.sh &> /dev/null`

Upon first glance, I notice that the cronjob file in bin has a .sh which means that it is a script for bash. I verified this using file /usr/bin/cronjob_bandit22.sh to see the following output:

/usr/bin/cronjob_bandit22.sh: Bourne-Again shell script, ASCII text executable

Then I used file -- * in theetc/cron.d/` directory and found that they were all just ASCII text files, not executables:

cronjobbandit15root: ASCII text cronjobbandit17root: ASCII text cronjobbandit22: ASCII text cronjobbandit23: ASCII text cronjobbandit24: ASCII text cronjobbandit25_root: ASCII text`

This is something I could have noticed much earlier had I been either more observant of the file suffix' or used the file command to check.

LV 22—>23

A very similar level to the previous. Straight-forward, easy. This time the cronjob script that we had to understand contained:

`#!/bin/bash

myname=$(whoami) mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)

echo “Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget”

cat /etc/bandit_pass/$myname > /tmp/$mytarget`

At first, I thought this was super straight forward so I can the contents of the script replacing the variable myname with my current user of bandit22. I ran it through the md5sum checksum, let it be piped into the cut command to remove the extra space returned by the checksum and then printed the result of the $mytarget variable:

8169b67bd894ddbb4412f91573b38db3

According to the cronjob script, the bandit password is written into the file in /tmp/8169b67bd894ddbb4412f91573b38db3

I was VERY surprised that the result returned here did NOT work as my password! Then I realized I should have been using the username bandit23 and not bandit22 since my goal is to find the password for the next level not this level.

I went through the same steps using the correct username for the $myname variable and checked the output file in the relevant tmp folder and viola! Completed.