Exploiting Misconfigured Cron Jobs.
In this video, we will be exploring
the process of searching for and identifying
misconfigured Cron jobs, and taking a look at how
we can essentially exploit them in order
to elevate our privileges.
Now, before we get started with the actual exploitation
process, let's get an understanding
of what Cron jobs are.
What is Cron?
Well, Linux implements task scheduling
through a utility called Cron, all right?
Now, Cron is a time based service
that runs applications, scripts, and other commands
repeatedly on a specified schedule.
An application or script that has
been configured to run repeatedly with Cron
is known as a Cron job.
Cron can be used to automate or repeat
a wide variety of functions on a Linux system
from daily backups to system upgrades and patches.
So Cron jobs is really an element of the Linux operating
system that you will be running across,
especially if the Linux target that you're dealing with
is actually a Linux server, right?
So why are they created?
What is a Cron job?
Well, a Cron job is essentially in the context of Windows
what you might consider a scheduled task, right?
So it's a task that has been configured
to run on a specified schedule.
Now, the way system administrators
utilize Cron jobs is to repeat otherwise repetitive tasks
like taking backups of specific folders, updating packages,
and anything else that they would like to automate.
And the great thing with Cron is that you can essentially
have a particular task or script or command executed
on a specified schedule.
So I can repeat a Cron job or I can
set a Cron job to run every one minute
of every hour of every day of every week of every month.
Or I can set it to run once every week
or once every month, et cetera, et cetera.
It's really, really limitless in terms of the schedule
that you can set up for a specific Cron job.
All right.
So as I said, the typical scenario that you would have
is where you have a system administrator who
wants to automate a specific repeated or repetitive task
like taking a backup of a user's home directory
or any directory for that matter.
Well, they can create a Cron job that executes the command that
actually performs that backup.
So the command could be copy home user and copy it
to another directory maybe under the /var directory,
under backups, or they could-- and this is what is typically
done-- they could create a shell script that contains those
commands.
And again, that Cron job will then
execute that particular shell script on a specified schedule
so it could be done every 1 minute or every week,
et cetera, et cetera, right?
Now, the crontab file is a configuration file
that is used by the Cron utility to store and track
Cron jobs that have been created.
So if you're ever on a Linux system
and want to identify what Cron jobs are currently
active and configured, you can essentially
display the content of the crontab file,
and that should display the Cron jobs that
have been configured for that specific user account
that you have access to.
All right.
Now, in terms of exploiting misconfigured Cron jobs,
it's very important to note that Cron jobs can also be
run as any user on the system.
So let me just break this down a little bit.
So again, a current job can really
be set up by any user on the system.
However, in the context of privilege escalation,
we are going to be targeting Cron jobs
that have been created or that have been scheduled by the root
user, right?
Because Cron jobs that have been created or scheduled
by the root user will run with root privileges.
All right.
So as I said, this is a very important thing
to keep in mind.
This is primarily because any script or command that
is being run by a Cron job--
so if a shell script is being run,
then it will run as the root user or with root privileges.
And if we find a way of taking advantage
of a shell script for example, a misconfigured shell script
then we can get it to execute any other commands
that we would like it to execute with root privileges.
So we could connect to a Netcat listener,
and that is going to provide us with privileges
or we could run other commands.
For example, we could add a specific command to add
the current user that we have access to the sudoers file
consequently allowing us to perform tasks that would
require root privileges or that require root privileges without
having to provide a password, right ?
So really, the crux of this really
revolves around the ability to find and identify
Cron jobs that have been scheduled by the root user
or the files being processed by the Cron job.
So as I said, in this context, we
are going to be taking a look at a Cron job that essentially
runs a specific shell script.
Now, you might be thinking to yourself, well,
if the shell script has been created by the root user
and the Cron job has been created by the root user, well,
how do we exploit or what misconfigurations
are we looking for?
Well, if that shell script has improper permissions,
meaning that shell script essentially
can be edited by any user on the system,
then that means that we can essentially
input any commands that we would like
executed into that shell script.
And once that Cron job is run, that particular shell script
will be executed with root privileges.
And the command that we specified
within that shell script will be executed with root privileges.
Now, as I said, there's multiple misconfigurations
that surround Cron jobs or Cron that
can be used to elevate your privileges.
In this case, we're going to be taking a look
at a very simple scenario that will again, explain
this vulnerability and will give you an idea as to how one can
find ingenious ways of elevating your privileges
through misconfigured Cron jobs or the files or scripts
associated with a Cron job.
And of course, this is a vulnerability or privilege
escalation vector that we will be exploring in the privilege
escalation course in depth.
And we'll be taking a look at the various techniques that
can be used to elevate your privileges by exploiting
misconfigured Cron jobs.
All right.
So let's get started.
This video already has a lab environment attached to it.
So all you need to do is just fire it up
and I'll take you through the process
of exploiting the Cron job.
And by the end of it, we should have elevated our privileges.
So I'll see you within the lab environment.
All right.
So I'm back within the lab environment.
And within this lab environment, you
are not required to exploit or gain access to a Linux system.
You already provided with access on the target system
as the user student who is an unprivileged user.
So again, if I say who am I, you can see that is student.
And if I list out the groups that this user is a part of.
So I can say--
let me type that in correctly-- so I can say groups student.
You can see that it's a part of its own group here
and is not part of the pseudo group.
So this is an unprivileged user account.
And of course, we are going to be looking
to elevate our privileges and obtain permissions,
the permissions associated with the root user account.
We really don't need to gain access to the root account
if we can essentially obtain pseudo permissions.
Then that means that we can execute commands
that require root privileges without having to provide
a password for example.
So as I said, this is really the target account.
All the privileges that we're looking for
are associated with the root account.
All right.
So as I said, you can identify the Cron jobs
that have been scheduled for this particular user
by saying crontab-l.
And you can see it's going to tell us,
no crontab for student.
Well, how do we find out whether we
have any Cron jobs that have been scheduled by the root
user?
Well, really it's going to require a lot of enumeration
and searching.
However, in this lab environment the actual technique
or the scenario has been made much simpler so that you
understand what's going on.
So if we list out the contents of the students home directory,
you can see that we have a file called message
that is owned by the root account, which
is very interesting because we are working within the home
student directory.
So why would the root user count store a file
within the student account?
So this file potentially be associated with a Cron job?
Well, if we try and cut out the content of the message file,
you'll see it's going to tell us, permission denied,
which makes sense because it's owned by the actual root user.
And you can see the actual permissions here.
So only the root user can read and write or make changes
to it, whereas every other user account and group on the system
doesn't have the privileges associated or required
to actually read the contents of this file
or make changes to it.
All right.
So we do know one thing.
We know that this particular file
is being stored within the student's home directory.
So we know that the file is under /home/student,
and the file name is message.
So we could try and identify where
this particular string of text or where the path is specified.
And in order to do this, we can utilize a utility.
So what we're going to do is we're
going to utilize the actual grep utility.
And we are going to look for all occurrences
of the path specified to the file
and try and see whether we have any occurrences of it
within a shell script or any other file for that matter.
That may shed a light on what exactly is being done
or why this file exists within the student home directory.
So I'll just navigate to the root of the Linux file system.
And we can use the grep utility, and we're going
to search recursively within--
we can start off with the user directory.
So this is typically where you would find
shell scripts being stored.
And what we're looking for is, again any occurrence
of the path in a /home/student/message.
And I'm just going to close that up there.
So again, just to reiterate what I said earlier,
we are essentially utilizing the grep utility to find any
occurrences of the path /home/student/message
because if there is a shell script that is being used,
then it is very likely that it contains the actual path
or rather the actual path to this particular file or where
this file is being stored.
So we can hit enter, and let's see whether we
are able to identify anything.
Well, that's interesting.
So it looks like we find a shell script called copy.sh,
and it's under /local/user/share.
And the occurrence of the string as you can see here
tells us that this file is been copied into the temp directory.
So if we list out the contents of the temp directory,
you can see, indeed we have the message fall here.
So if I cut out the message file within the temp directory,
you can see it's going to tell us, hey, you're not root.
So again, this is just a simple example or a scenario that
was used to highlight this.
So let's take a look at this shell script,
and let's see what exactly is being done.
However, before we do that, let's
actually check the permissions for this shell script.
Can we actually modify it and get
it to run with root privileges or get
it to execute any of our own commands with root privileges?
In order to do this, I'm going to use the LSAL command,
and say we want to list all the permissions of the shell script
under /usr/local/share/copy.sh.
All right.
So we can see that this script is owned by the root account
right over here.
But if we take a look at the permissions,
you can see that every user count in group on the system
has read, write, and execute permissions,
which means we can execute this or rather we can edit it.
But if we execute it with our current privileges,
then we really are not going to get anywhere.
What we want it to do or what we want
to happen here is we want to add a line of code
within this particular shell script, right?
And we want to essentially have the Cron job executed this.
And we really aren't aware of the schedule behind the Cron
job.
But again, as I said, this lab environment
will execute the current job every 1 minute.
So after 1 minute, this script will be executed.
And so if we can get it to execute a specific command,
command maybe that will add us to the sudoers group
or added to the sudoers file, consequently providing us
with elevated privileges or root privileges,
then that will be very, very helpful.
So because we can edit it, if I can just cut out
the contents of the file.
So this is under /usr/local/share/copy.sh.
You can see that this is what it does.
So it's a bash script here.
And all that it does is it just copies the message
from the home directory of the student,
and it copies it into the temp directory
under the same file name, which is message.
And then modifies the permissions
of the message file that's stored within the temp
directory so that any user can read it,
which is why we were able to read it,
we were able to read the message file that's
stored in the temp directory.
So it's essentially the same file.
All it's all that's happening is the Cron job or this shell
script is copying the message file from the home
directory of the student into the temp directory
and then changing the permissions.
OK.
So let's find a way of modifying it.
We don't have any text editors within this particular lab
environment.
So we're going to have to use an ingenious technique.
So in order to do this, what we're going to do
is we are going to use the printf command.
So printf and we are then going to specify
that we want-- this is a bash shell or a bash script.
So we'll specify the environment variable bin/bash.
All right.
So we'll say bin/bash.
There we are.
And we then want to create a new line and then say echo.
So we're now echoing or redirecting text.
And the text that we want to redirect
is going to involve the student account.
So we're saying students should have all permissions
without providing the password.
So we can say no password.
And this again comes down to Linux permissions,
but I'm going to be explaining it as we go on.
And again, all permissions, right?
So what we're saying here is we're echoing or redirecting
the following output into the sudoers file.
And we're seeing the student account
should have all privileges and does not
need to specify a password.
And again, this particular command requires
or the ability to edit the sudoers file
requires root privileges.
So again, this will only be executed once the shell
script is executed.
So we close the quotation marks there,
and we are going to append it to the etc sudoers file.
And we can then close the single quotes there.
And we are going to then output or essentially save this
or redirect this entire command into the actual shell script
that is being executed by the Cron job,
which is under /usr/local/share/copy.sh.
So we hit Enter, and that was done successfully.
So we can now cut out the content of the shell script.
So we can say /usr/local/share/copy.sh.
And you can see that is the actual shell script there
or bash script.
So it essentially outputs or echoes the following string
of text, "student all no password all" into etc sudoers
and that is pretty much it.
OK.
So now, we are just going to wait for a couple of minutes.
And we can view the members or we can actually
view the users that are part of the sudoers group
by saying sudo-l.
And you can see right over here, user student
may run the following commands on the attack defense system.
And right away you can see no password all.
Before they could actually interact with the Cron utility,
and now they can run any commands here
without providing any password.
So the Cron job has run, and it has add the student account
to the sudoers group.
So that means that we can pretty much do whatever we want
or rather we can execute any commands that
require root privileges.
So for example, I can say sudo su,
and we have elevated or switched to the root user.
And of course, we've elevated our privileges.
So I can say, who am I?
There we are.
So let me tap that incorrectly.
There we are, root user.
And we can navigate to the root directory,
and we can get all the contents of the flag, which
you are supposed to obtain.
So that is how to elevate your privileges by exploiting
a misconfigured Cron job.
Now, as I said, this might be a little bit confusing.
But as I said, I wanted to demonstrate this now
before we actually get into Cron jobs in depth
within the privilege escalation course.
But I'll just highlight or go over what we've done.
So the first step essentially involved
identifying the files or scripts that
are being used by Cron job.
And of course, we really can be sure
when the Cron job or the actual schedule
the Cron job is using to run.
So once we've identified the shell script that
is being used or being run by the Cron job,
we can then identify whether that shell script can actually
be modified by an unprivileged user for example,
which in this case, it was.
What we then did is we then essentially
modified the shell script and added a command that
would add our current user to the sudoers file,
consequently allowing us to essentially run
commands that require root privileges without providing
a password.
And in this case, as you saw, we were
able to switch to the root user.
So if I now say crontab-l, you can
see the Cron job that was created by the root user.
So you can see that it runs every 1 minute,
and it essentially runs the shell script copy.sh.
So I've actually confirmed that indeed there
was a con job that was running 1 minute or every 1 minute,
and it was executing the shell script copy.sh.
All right.
So that is going to conclude the practical demonstration
side of this video.
In the next video, we will be exploring
the process of exploiting SUID binaries,
and taking a look at how they can
be used to elevate our privileges on a Linux system.
So I'll see you there.