pwnded. Personal tip for privesc: Sometimes it’s not about files, but folders. If anyone needs help, can dm me.
i got .**t directory but nothing is sensitive there how guys did you find the password
i was able to find the password
rooted.
but I’m confused about something.
I tried doing the ‘thing’ for priv esc in /tmp and it didn’t work
and when I tried the same ‘thing’ from HOME dir of user, it worked. why is that?
I think it has something to do with the sticky bit on tmp, not quite sure either, but that’s my theory. Am too lazy to test it though.
GG. This Box was a bit difficult for me.
Recon phase: Wordlist is crucial.
LFI phase: ChatGPT is helpful.
Any tips on where i need to look?
I dumped the *** directory but I don’t know where to find the creds
Open the directory you dumped in VSCode. Then check the portion of VSC that shows *** history
I know it’s late, but with the help of chatgpt, that’s what I concluded (I’m not really sure, but it makes sense and fits the scenario). Some directories in Linux like /tmp, /dev/shm or similar shared directories, usually have the sticky bit enabled, which, as chatgpt says:
Its main purpose is to control who can delete or modify files within a shared directory, even if the general permissions of the directory allow write access for everyone.
In the case of
/tmpand/dev/shm, the sticky bit ensures that:
- Only the owner of a file or symbolic link can delete or modify it.
- Other users, even if they have write permissions for the directory, cannot delete or modify files/links created by others.
If you check that with ls -ld <dir> you will see that /tmp and /dev/shm have the sticky bit enabled drwxrwxrwt 13 root root 36864 Jan 22 21:18 /tmp (it’s the -t at the end) and the directories that you own or you create do not have it drwxrwxr-x 2 bob bob 4096 Jan 22 21:03 /tmp/myfolder. If you try to repeat the privilege escalation process in a folder created by you inside /tmp you will see that it works like in $HOME
Ok, but it doesn’t explain that root can’t read the double symlink, and asking about that, chatgpt says:
The sticky bit in shared directories like
/tmpor/dev/shmenables extra kernel protections, blocking privileged processes from following symbolic links if the link’s owner differs from the file owner. These restrictions do not exist in private directories, allowing symbolic links to resolve normally.
From this (assuming chatgpt wasn’t tripping), when I put the first symlink in /tmp and the second in /tmp/privesc (or another non-sticky bit folder) the exploitation works like in $HOME, so the conclusion for this scenario is that the symlink that jumps in ownership bob → root couldn’t be in a sticky bit folder in order to succeed.
1 Like
Can anyone PM me the hints for finding the specific directory? Been dir busting but to no avail…
PWNED.
User is complicated but easy overall. Once you find something you will have everything in place. You have to just open your eyes widely 
Root is easy but you need to understand the vuln. Honestly AI helped me to understand.
Hint for user, Do simple user enumeration using login page
Hint for password, many password in the files, but grep for files with authentication, ALSO DONT MISS THE PASSWORD LIKE 10 TIMES LIKE AN IDIOT Make sure you see the password.
If you still cant find password, grep for password, but try to use smart password greps to filter out too much junk so you dont miss it again.