We mentioned earlier that we're limited based on the actual user's permissions when a file is executed normally.
See, now we want to take our search a little bit deeper and see if we can find files that are ran at the owner's permissions level rather than the actual user that's executing them.
The reason this becomes important is because there are files and programs on a Linux or a POSIX based system that run with root level permissions even if we don't see it running like a normal file or program.
And that's where we can start putting the pieces together in terms of gaining persistence and more access to the system and potentially the network.
Because if we're able to find a file with right permissions and a file that's executed with root level permissions and they are one and the same, I'm sure you can guess where we're going from here.
Now I do want to temper your expectations and the reason for this is because on an even out-of-the-box installation of Ubuntu or any other POSIX based operating system,
you should never be able to find a file that can run as root level and have write access to it based on anybody.
Because if that were to be the case, then any user could log in, remote in, whatever, write to that file and execute the file and it would be ran as root on the system.
So all security out the window, you would be able to go through and run whatever you wanted on the system.
Not just from a hacker's perspective, but let's say you're a regular user and you just want things to run that has been disabled by the system admin.
Whatever the case may be.
But I do want to show you this command here and I'm going to have it in the code box below as well.
And this is going to show you how to be able to find both having a user as root being able to run the permissions and have write ability access to it.
So basically the biggest flaws of all the flaws out there.
And when this is ran, you'll see that nothing comes back up and that's simply because there's no file on here that matches that criteria together.
And that's a good thing.
So this is also something to keep in mind when there's patching being done to the system.
We're installing new programs and some of those programs may not have passed the testing phase properly.
And so this is one of the checks that we can definitely do as an administrator and pen tester to go through and make sure that everything is secure on the actual system itself.
Now if you do find one of those files, by all means have fun with it as long as it's within the scope of your ROE.
Now don't worry, I still have the command here also in the code box below of finding actual files that have SUID set as root.
Meaning that whenever those files are ran, they run with that root level permission.
And even though we don't have files that match the criteria of both having root set as the owner for execution and write access to them.
What just happened was all the files on the system that are actually owned by root and when executed are ran at root level.
So this is something else for us pen testers and also those security administrators to be able to look at and see if that's something that we want to attack or if it's something that we want to defend.
Now some of these are pretty self-explanatory and I do want to show you because it kind of helps make sense with the actual operating system itself.
And for instance, we're taking a look at actual mount.
Now you may be thinking, well, that's very simplistic command and it is.
It requires permissions to be able to elevate and run that because when the actual mount command is ran on the system, it's running at that root level to make changes to the operating system and user experience for that user.
Now it's listed as the actual file path and we're used to seeing it in the terminal or command line as mount.
That's where it's actually stored at user bin mount.
And to prove that we go a little bit further in there and do a ls-la slash user slash bin slash mount.
And we can see that the permissions of that file are set.
Not only that, it is executable and it is owned by root.
Now that's again where the file is actually stored at.
If we go ahead and type in slash user slash bin slash mount dash dash help, for example, you can see that it operates just like the normal command if we went in and just typed mount dash dash help.
Using the actual command itself shows what's actually mounted on the system.
So you saw that I just did all that without using sudo.
Again, nothing up my sleeves except for arms.
So I wanted to display that because this mount is a command that runs at that root level because when it's invoked properly and you're actually mounting things to the drive itself, it's doing it to the actual operating system and user account experience that you're logged into at that time running as root.
Something to keep in mind when you export that list of files that are owned by root, just in case you find something you want to run in conjunction with mount, for example, and have it do something it's not supposed to do.