Enumeration of File Permissions/User ID's

Off-topic
1

Hello,

I am relatively new to pen-testing and am trying to get a good handle on all the enumeration basics and lately I’ve been looking at file permissions. I under what all the parts of .rwxrwxrwx root root mean but I’m not really sure when this information ever becomes useful?

  1. Can I use the fact a file has SUID SGID bit set?
  2. Is it significant when a file has a symbolic link?
  3. If I have just got onto a shell as, for example, user bob, do i treat files that are owned by bob any differently to files not owned by bob?

Any other tips/thoughts in this area welcome :slight_smile:

Also as a slightly off topic question is it possible to change my UID? For example I login as Bob UID 997 and I need to be Steve UID UID 998 is there a way to change between the two as a way of moving laterally?

thanks for reading!

2

@BugsBunny said:

I under what all the parts of .rwxrwxrwx root root mean but I’m not really sure when this information ever becomes useful?

Part of the problem answering this is that the real answer is “it depends”, which isn’t very helpful.

The information becomes useful when it is useful for an attack. A lot of the time it is just noise, so experience is really the best teacher here.

It is not possible to say “all files with the sticky bit set are useful for exploitation.” At best we can say “it is worth checking for files with the sticky bit set to see if anything unusual appears and then maybe that can be exploited.”

  1. Can I use the fact a file has SUID SGID bit set?

Yes. But the value to you depends on what the file is/does. If you don’t know what is normal for the OS, then it is hard to make this useable.

For example, you will often find /usr/bin/passwd has the sticky bit set, but this is normally not something you can exploit (if you do, its worth reporting it and getting it fixed).

However, if you find /opt/personal/myownfile is set to run as root, then there is a good chance it is exploitable (on a CTF, possibly not if its a live system which has been through a pentest etc).

Have a look at your own system and see what is set up to run as root. This is a good way to determine normal.

  1. Is it significant when a file has a symbolic link?

Normally, no. I wouldn’t use this as a way to prioritise binaries in my enumeration.

However, there are exceptions to this but they are a minority.

  1. If I have just got onto a shell as, for example, user bob, do i treat files that are owned by bob any differently to files not owned by bob?

Yes. If you can read, write or execute files which belong to other users then it is possible that you can use this to progress the attack. However, this can be a needle in a needle stack.

An example is if you have a shell as bob and bob can read alice’s files, and in one of alice’s files there is a password.txt with alice’s password, this is definitely something you can use.

This is rare though, so dont assume it will be there.

If you have a shell as bob and there is an executable file owned by alice, which runs as alice, then it might be a way to become alice.

Again, this is not common.

But you need to understand who owns what on the filesystem. Enumeration is one of the most important things to do, even though it can feel tedious and is certainly not as exciting as issuing arcane commands to get a reverse shell.

Really, you need to read and understand the environment you are in.

Also as a slightly off topic question is it possible to change my UID? For example I login as Bob UID 997 and I need to be Steve UID UID 998 is there a way to change between the two as a way of moving laterally?

Well, finding the way to do this is how you move between accounts. The most basic is compromise Steve’s account and su steve or ssh steve@machine. You cant just “do” it as part of the OS commands.

3

Hi Taz,

I just wanted to say thank for such a thorough responses to my questions, it really makes the learning process so much easier when I know how to direct my efforts. I appreciate a lot of the time the answer is “it depends” but hearing how it depends is really useful for someone who doesn’t have the confidence to de-scope/focus on certain bits of information :slight_smile:

4

@BugsBunny said:

Hi Taz,

I just wanted to say thank for such a thorough responses to my questions, it really makes the learning process so much easier when I know how to direct my efforts.

Always glad to help if I can.

I appreciate a lot of the time the answer is “it depends” but hearing how it depends is really useful for someone who doesn’t have the confidence to de-scope/focus on certain bits of information :slight_smile:

You’ve hit a good point here. The nightmare for everyone is knowing when something should work and when it shouldn’t. Sadly CTFs (with a tendency to put rabbit holes in) don’t always help here.

A very good example is how you tell the difference between a fuzz string which should work but isn’t producing any results, which means its the wrong approach and a fuzz string which is broken and it isn’t working even though there is something to find.

There isn’t a good answer to this.

It is one of the reasons why OSCP (or timed CTFs like SANS NetWars) is challenging, because you have to be confident your commands are correct.

The simplest answer is that it really does come with practice. Over time you learn when it is a good idea to fuzz for txt, php and pdf extensions vs just txt and php extensions.

5

I wrote something this morning, but had some issues getting it one here. I see @TazWake helped you nicely, but it’ll post it anyway:

I’m going to take a stab at this, because I’m still wondering about some bits myself. I’m sure someone will jump on it if I make any mistakes.

First of all: there are good guides online about Linux permissions. It’s really worth checking them out, because it’s a big part of what you will do, but here’s some concrete answers to get you pointing in the direction you are looking for:

  1. You can use the fact that a file has a SUID or SGID bit set. And although the exact difference between both still eludes me a bit: here ownership and groups become important.

The ‘root root’ part you mention in your example, I’ll change that ‘root admin’ for the sake of explanation.
A file with the suid or sgid bit set will elevate you to whoever owns the file, so ‘who owns the file’ is important, but you also need permissions yourself to be able to execute the file.
This does, however not always mean that when you can execute a file with one of those bits set, you can suddenly ‘are root on the entire box’, there are other factors to it.

Consider the following example:
A file has a suid bit set, is owned by root and can be executed by the group admin and is not world executable.
When you speak about ‘.rwxrwxrwx root root’, out the top of my head, this would translate to:
’ .rwxs r-x — root admin’. Note that I broke the first part up into 3 groups.

  • The first group applies to the owner, so ‘root’ in this case.
    • So if I am root: I can read, write and execute the file
  • The second group applies to the group-ownership
    • So if I am part of the admin group: I can read and execute
  • The third group applies to anybody else
    • so ‘the world’ can neither write, read, nor execute this file

Say you have 3 users on your box:

  • bob uid 1000, not a member of the admin group

  • steve uid 1001, member of the admin group

  • root uid 0

  • Bob: would not be able to execute this nor read the file, he has no access to it and therefore has no (direct) chance of using or exploiting the suid bit

  • Steve: can execute the file, because he is part of the admin group, and by the fact of the suid bit being set on the binary, he can escalate to whomever owns the file, in this case, he can escalate to root… However… This does not mean he then suddenly ‘is’ or can ‘stay’ root: if the binary is safe, the user will stay contained within that binary and only be ‘root’ for whatever purpose the binary is intended.
    Take the ‘sudo’ command for example: a sudo command needs a suid bit set, because it will have to read files like a shadow file (the file with all hashed passwords stored, which a low privilege user can normally not read). But the binary is safe enough that you can’t escape from the binary, so any user using it, can within the binary read the shadow file, but can not abuse that momentary glory, because the binary will again safely guide them to their normal permissions.
    Sometimes binaries are unsafe and we can inject unintended commands, and for example run a shell and break out of the binary, in the elevated user context and privileges this binary provided.

This latter is one of the many ways to privilege escalation. It’s also a more complex mechanism to exploit, simply because it often needs reverse engineering, which requires not only an understanding of coding, but also the assembly language.

There are more easy variants where a binary has an intended way of creating a shell. An example would be that ‘less’ allows to spawn a shell. So therefore if the less command has the suid bit set and the owner is root, you can ‘be and stay’ root on that box, through that less command, by spawning a shell from it by native functionality it provides.

An analogy could be: imagine two buildings, one is a poor man’s house, the other a high-security scyscraper of a billionaire.
You can enter the poor man’s house easily, because it’s of low value, but if you knock around on some walls and suddenly find a door to the skyscraper, that’s pretty much the equivalent of having a binary with the suid bit set, from which you can funnel to higher privileges, bypassing pretty much all security that guards the entrance of those higher privileges.

6

@gnothiseauton , just seen this, thanks for adding and nice analogy :slight_smile: