RTV'23 PrivEsc Challenge 1-3
Within 5 minutes, can you get root given an initial foothold?
CHAL#1 (SUID)
Connecting to the instance then securing a stable shell:
$ ssh -i jebidiah.rsa -l jebidiah RTV_Priv1
$ bash
jebidiah@ip-172-31-47-51:~$ id
uid=1001(jebidiah) gid=1001(jebidiah) groups=1001(jebidiah)First, looking at the contents of the /home directory, there is an interesting file inside /home/anthony:
jebidiah@ip-172-31-47-51:~$ tree /home
/home
βββ admin
βββ anthony
βΒ Β βββ bash
βββ jebidiah
4 directories, 1 fileLooking at the file, it is discovered to be an executable with the SUID bit set to the user, root; however, it can only be run by members of the group, anthony (which is also another user):
What should now be done is finding a way to change the current running context to anthony:
There is another bash executable in the / directory but this time an SUID bit was set to the group, anthony, which is what is currently needed:
Now, the effective gid of the current running context is for anthony meaning that the initially found bash file should now be executable and finally gain root privileges:
CHAL#2 (strcmp)
Connecting to the instance then securing a stable shell:
Looking at the home directory of the current user, there is an executable named, root:
Attempting to run it yields the following results:
It seems to be used for validating the root password and looking at its structure based on gdb, there is a strcmp() function probably used for verification and it seems that the plaintext password has been XORed which means that simply using strings will not give any results:
Debugging the executable then stopping at strcmp(), a password seems to have been recovered:
Now, using the discovered password to change the current user to root:
The same result could be obtained via ltrace:
Just something to share, this was the code used for the challenge:
CHAL#3 (passwd)
Connecting to the instance then securing a stable shell:
Looking at the current user's home directory, there is a passwd binary but there is nothing much that can be done about it as there are no escalation methods that can be achieved but this might be a clue to what can be done next:
Maybe it's the passwd file? Maybe it's the shadow file? Looking at it:
The passwd file is writable meaning a new user can be created that can be fully controlled; moreover, it could have root privileges. But first, it is important to note that the file follows a certain format per user:
Now, to create a new user with a blank password:
If you want to add a password, you can do so by doing the following:
Last updated