Objective:
Find the password to the next level
Intel Given:
- 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.NOTE: This level requires you to create your own first shell-script. This is a very big step and you should be proud of yourself when you beat this level!NOTE 2: Keep in mind that your shell script is removed once executed, so you may want to keep a copy around…
How to:
This level, similar to the last requires a little bit of outside the box thinking. Once again we’re told a cron job is running a script so lets look at that first.
We can see that its running the script /usr/bin/cronjob_bandit24.sh. When we cat that file we run into our very first for loop! Loops are very important in programming, in this case a for loop basically repeating itself FOR every instance specified. If you’ve never seen for loops before this may get a little hairy. DON’T WORRY. Loops can be tricky and it can take some people a little bit of time to understand.
So in the script above ‘for i in *;’ means that each file in the directory /var/spool/$myname will be input into the ‘do’ section one at a time.
Within the do section ‘./$i’ means each file will be executed and the ‘rm -f $i’ will force remove it.
What does this mean to us? We know that there is a script that is running commands at the user permission level of Bandit24. That means that we could possibly inject our own script to be run if we put a script of our own into the /var/spool/bandit24 directory. If only there was a file that stored the Bandit24 password… well if you remember in our Bandit 20 tutorial we were given the hint that the password for that level was stored in /etc/bandit_pass/ so it stands to reason that our bandit24 password is there as well. Lets test our theory.
First we’re going to make a little space to work with in the tmp directory and then we’re going to create a file called password.sh to write our script.
Our script is going to be pretty simple. All we’re doing is reading the contents of the bandit24 password file and sending its output into a file that our bandit23 user account can see.
We need to make our script executable by bandit24. 777 is excessive for permissions and I normally would advise against giving broad permissions such as this, but since we’re in a lab theres no harm. Note: You can also chmod -R 777 your tmp file in order to ls your files if you’re finding not listing your directory to be irritating.
Then we copy our script into the /var/spool/bandit24 folder. Give it a minute to allow the cron job to run and then cat the file you specified as output.
Ta-Da! There’s your password!
Conclusion:
This lesson got a little more difficult. We showed a very simple for loop and we figured out that if we have jobs, dameons or services that are running scripts on BEHALF of a user account it is possible for us to inject our own code into it in order to gain access to places we don’t have permissions to. This is why running vulnerable services as root or admin that can be exploited is a bad idea. If a hacker can gain access to that service they can execute commands on behalf of that service that were never intended to be run.
