The goal of this lab is to understand how Linux permissions can be misused in a manner that allows for exploitation.

The program written in C below is used to print the "effective user name"--this means that it's not who necessarily invokes the process, but who (i.e. what permissions) is the one that's running the process.

#include <stdlib.h>
#include <pwd.h>
#include <stdio.h>
#include <unistd.h>

/*
SEC335 Illustrate SUID Programs
* based on: https://stackoverflow.com/questions/8953424/how-to-get-the-username-in-c-c-in-linux
* Make sure run the following
* sudo chown root:root nameofprogram
* sudo chmod u+s nameofprogram
*/

int main(int argc, char *argv[])
{
  struct passwd *pw;
  uid_t uid;
 
  uid = geteuid ();
  pw = getpwuid (uid);
  if (pw)
    {
      puts (pw->pw_name);
      exit (EXIT_SUCCESS);
    }
  else
  {
     puts ("Error");
     exit (EXIT_FAILURE);
  }
}

Here's an example of how it works:

In the lab we were asked to determine the file permission for effective_user in Octal--here are two ways to do this:

You can either run stat [FILE_NAME] or you can get a little fancier and only provide the desired output:

stat -c '%a' [FILE_NAME]

Here's a helpful resource where I found how to use stat to calculate the permissions for the file in Octal.

Here's another example, where the permissions are set at the root level for users (since we need to update /etc/passwd and /etc/shadow when changing a password):

If a suid bit is set that means the program runs with the owner's permission (in the example above, the permissions would be root so that the secure files could be updated).

Let's experiment with this C program to demonstrate how this suid bit works in another way--start by changing ownership of the file to root (you'll need to sudo in order to change the permission:

sudo chown root:root [FILE_NAME]

This command will change the ownership of the file to root and set the group to root. Now let's add the suid bit:

sudo chmod u+s [FILE_NAME]

Now when we run the program again as a normal user (no sudo we're returned with root as shown in the screenshot below):

So, how is this helpful from an ethical hacking perspective? Files with a suid bit enabled mean that a regular user is technically running the file as root. This leaves room for privilege escalation, and it's helpful to try and find what files on a system fall under this umbrella. Here's the command to search for files with a suid bit enabled:

find / -perm -u=s -type f 2>/dev/null

To clarify the syntax: This command is saying "find from the root directory the following permissions: files owned by the root user that are of the file type 'regular' and redirect standard errors to the /dev/null path.

Here's the resource I used for searching for files with the suid bit enabled.

Another potentially helpful element when considering pen testing and file permissions are globally writable files. Here's how to create one (no, you shouldn't use this permission, generally):

sudo chmod o+w [FILE_NAME]

This makes for a messy and dangerous way to live. From a hacker's perspective, locating the globally writable files is easy so long as they have a basic user account:

find / -perm -o=w -type f 2>/dev/null

You can | grep after this command to filter out your output some more too, if you're looking for files in a specific directory.

Here's a reference on using the find command with various permissions. Also bear in mind that grep -v is helpful as it does an inverted search (i.e. ignore lines that contain "X").

I didn't run into any crazy issues in this lab, most of the commands and permissions logic was relatively easy to find online. I've done my best to record the resources I've found, but I'm sure the links will break quickly. It took a few tries at understanding how file permissions work, but this lab did a good job re-exposing me to their logic. Overall this was a manageable lab with a good balance of hints in the lab and areas for independent troubleshooting.

N/A