Quackerjack
Last updated
Last updated
I performed a quick check for anonymous login on FTP and was returned a logon error.
As we have no luck with FTP I then run enum4linux against the target to look for users, groups and to perform RID cycling.
Unfortunately enum4linux did not return any relevant users information. I also checked null authentication against the target.
As we have HTTP running on port 80 and 8081 we can run gobuster against these ports.
The default page for 80 brings us to a CentOS Apache test page.
On port 8081 we come to a login page for rConfig. As we can see from the landing page rConfig is running on version 3.9.4.
A Google search reveals a multitude of exploits for this for varying versions. I went thought a fair few some of which I could not get to work which are specific to 3.9.4. Eventually I come across a SQL injection exploit.
Run the exploit with the following syntax.
We manage to extract a hash. I identified this as a MD5 hash and was not able to crack with John using the rockyou.txt. I ended putting the hash into online databases to find a match.
We now have the following credentials for rConfig.
Now that we are authenticated we can search for authenticated exploits. I soon come across an authenticated remote code execution exploit for 3.9.3. Whilst not intended for the version we have 3.9.4 we can try it anyway.
Looking at the exploit code looks like we supply the arguments below and in return the payload will attempt a bash reverse shell back to us.
First set up a netcat listener on our attacking machine. I am going to use port 80 this is a common port for outbound traffic.
Then execute the exploit with the following syntax:
Once we have run the exploit we should get a shell back on our listener.
We confirm we are the apache user.
In the home directory we have the user 'rConfig'. I grabbed the local.txt flag and then started a Python SimpleHTTPServer on my attacking machine. I then uploaded linpeas.sh to aid with privilege escalation.
After running linpeas and going through the results we actually have various potential exploits. I will be focusing on the SUID being set on the find binary.
Lets use the syntax above and call the binary and see if we can escape the restricted shell as root.
Once we escape we should have a root shell.
We can check on for how we cab use the binary for privilege escalation.
