Episode 2 of retrying challenges attempted on my dead laptop : analysing bash history of privilege escalation

 this is Privilege Escalation, again from btlo.  Completed on Jun 29 2022. 

https://github.com/dakshita-joshi/BlueTeamLabsOnline/blob/main/Privilege%20Escalation

Funny thing is, I remember when I attempted this challenge the first time I was so dazed and confused and honestly? i only answered contextually. so if the question said "what script" etc etc id look for what sentence would contain an sh extension since that would be a script and kind of threw pasta at the wall and saw what sticks.

but now, knowing all I know NOW? this looks like cakewalk. so now I will try to attempt this freshly. 

daniel is mentioned as a user in cd /home/daniel/

root wgets linux-eploit-suggester.sh so that answers second question. 

lol went on a privilege escalation tutorial spiral while trying to learn more about this script. this is why I love CyberSec, its so extensive that any direction takes you to some completely new realm of information. 

the next question is fairly easy the last lines show an x.phtml file that was removed.

now for last question. it says what misconfiguration was used and back then I just wrote 1, 2, 3, 4 and four became correct so I rolled with it (LOOK IM NOT PROUD OF IT id just not been able to complete three challenges in a row and was desperate ) anyway I'm righting this wrong today.

going through the bash history the user first opens index.php, creates test.php then removes it then dances around a few directories and settles on /html/uploads. pwd gives path to working directory, then id gives uid of current user. then whoami gives user name. then enters root user with su. 

then finds perl and python with find command. then spawns a separate python terminal and wgets a linux-exploit-suggester bash script. then sees all running processes by root and other users by ps -aux. then ps -ef | grep "root" lists all processes on system in full format and grep root gives only processes run by root.  

then lists all files in long format in /usr/bin then /sbin. (what is happening what are they doing hello??)

then recursively lists all files in long format (with permissions)in /etc/directory then uses awk command which ill have to use a brief reading break for. 

so the command was ls -aRl /etc/| awk '$1 ~ /^.*r.*/'

of which the ls -aRl was listing all files in /etc/ recursively and with permission lists. the awk commant is a text reader. the $1 specifies only the first field of the file to be printed. now  ~ /^.*r.*/' i could not understand. i assumed it meant files ending with r in their extension so i did the same command in my terminal and that's a boatload of files :( 

so it is not a file extension but a description of permission. i could not figure out how to identify so i tried replacing the asterisk or slashes with other things. so i replaced the *r with *s and it showed only one file 

drwxr-s---   2 root dip     4096 Feb 23  2022 chatscripts

so its obviously some way to list file permissions so i looked it up and the first letter tells if its a file (-) or directory (d). the rest of the nine characters display information for root, user and group. so a permission label that looks like -rw-r--r-- means file(-), it has read write but not execute permission for owner(rw-), only read permission for group(r--) and only read permissions for user(r--) . so i think ^.*r.* means files that have read permission in the group?? 

so that were meta characters. i was looking for search expressions with awk but i found a better description for grep. so * is used as a meta character which means “repeat the previous character or expression zero or more times”. so it was simply a search expression and not an indication towards the answer for question 5 as i had thought. its ok. i learnt a lot.(this is how ppl in tech pacify themselves after obviously wasting a lot of time on looking for absolutely inconsequential things that don't matter in the grand scheme of the universe) 

anyway in the meanwhile i read forward and went through the rest of the commands and they were pretty straightforward. nothing i learnt a lot from except lsof -i lists all open files based on IP address. and iptables which was a nice long rabbit holing session. oh, and 2>/dev/null is basically throwing all errors into the linux trash file. 

then I'm assuming because the ls wasn't very successful the user uses find command. this one i didn't have to have to read up on (oh, joy) so they're looking for files (type -f) owned by root (-user root) and has permissions -4000. so permissions are usually 3 numbered( just read about this, this feels nice). so 400 would be read permissions but only for root. but further in that text i read that 4 digit permissions have a special meaning. the first digit can mean suid, sgid and sticky bit. the rest of the numbers as usual mean read write or execute permissions based on the digit. 000 means no rwx access. 4 means......SUID. finally we have the answer to question 5. suid basically means if setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed. so the user is looking for files owned by root with suid bit set. 

then the user spawns another python terminal in /bin/sh. (when i read the write up in the btlo terminal they said the answer to question 5 is suid because the python terminal is spawned from a root location therefore the user exploited this vulnerability of user id and therefore the answer is suid. i will have to read more on that). And at last a phtml file was removed from /var/www/html/uploads so we can guess the answer to question 4 is .phtml upload filter. 

And that concludes this retry at a challenge i obviously didn't go about the right way in the beginning. Cheers!