Wekor Writeup
Wekor Link
Enumeration
After adding wekor.thm to our hosts as per the instructions for the room we can run an nmap scan. Nmap reveals that we have a webserver running on port 80 and ssh. Lets explore the webserver and see what we have.
Taking a quick look and we don't have anything of interest at all other than an incredibly basic website, inspecting the source we don't have anything of interest either.Let's run gobuster to see if that reveals anything for us.
Taking a look at the results from gobuster we can see that we have a robots.txt available, so let's take a quick look at that and see what directories we have.
Some interesting directories listed, let's start going through the list a see what is on each one.
Going through each of the directories we end up receiving a 404 except for one of them, we end up receiving a page that tells us where a website is located, let's go take a look at the website and see what we have.
Looks like we have a computer services website of sorts. Let's explore that page and also let gobuster run in the background in case it finds any extra directories.
Looks like we have a customer login form, could be interesting to explore.
After some testing it didn't lead anywhere, I also took a quick look at some of the other fields to see if there was any we could inject with sqli or nosqli and nothing eventuated so we need to go back to the drawing board.
After some testing it didn't lead anywhere, I also took a quick look at some of the other fields to see if there was any we could inject with sqli or nosqli and nothing eventuated so we need to go back to the drawing board.
Enumerating subdomains with ffuf, firstly we need to run ffuf without any filters so we can get an idea of what we can filter against, looking at our first short run it looks like size is consistent at 23 so we use that in our second run as the filter, which we will let complete.
Looking at the results we can see that we have a subdomain of site, lets add that to our /etc/hosts file and take a look.
Looks like we have another website coming soon, so let's load up gobuster again and see what directories we have.
Looks like we have a wordpress directory, let's take a look at it and see what we have.
Enumerating the wordpress site there isn't anything really of interest here as we don't have any credentials.
Let's go back to the original website and see if there's anything we missed.
Let's go back to the original website and see if there's anything we missed.
Digging further I managed to find a page I missed in my original search, looking at the cart page their is a coupon field which when entering a single quote returns a sql error, we can abuse this and either manually enumerate or use sqlmap to enumerate for us, I'll be using sqlmap.
Exploitation
Enumerating through the database we can see a database called wordpress, looking into this we can extract the wp_users table, now lets see if we can crack any of the user passwords.
Putting the users and hashes into a file and running them through john nets us some passwords for the accounts, no admin account though so lets look at the wp_usermeta table and see which users have the administrator capability in wordpress.
After dumping the wp_usermeta table we can see that the user wp_yura has the administrator capability to let's log in and see if we can exploit wordpress for rce.
The easiest way to get rce is if we have permissions to edit the theme files then we can go ahead and change the 404 page over to a php reverse shell like I have above. Now all we need to do is navigate to the 404 page with a nc listener waiting.
And just like that we have a shell.
I tried initially transferring over socat to the machine and running that so I could upgrade my shell to a more stable shell but for whatever reason socat kept giving me errors so for now I'll stick with this shell untill we get access to the user account.
I tried initially transferring over socat to the machine and running that so I could upgrade my shell to a more stable shell but for whatever reason socat kept giving me errors so for now I'll stick with this shell untill we get access to the user account.
Uploading linpeas and executing it we can take a bit of a look at what's going on in this system and hopefully try find our user entry point.
Looking at the network section of linpeas we can see a couple of interesting things, one is that osboxes seems to be running which is a virtual host application and there seems to be a strange port, 11211, taking a look at what this port is it seems it is something to do with memcached which seems to be a distributed memory caching system usually used to speed up database driven websites.
After doing some research on memcached I found an article here which details how to dig into it and extract information.
In the first image we telnet into the memcached server and then running stats gives us a bunch of information about that server including the version which in this case is 1.4.25.
The second image we are running the command stats slabs which returns us the total number of slabs represented by total_pages which in this case is 1.
In the third image we are using the command stats items which will return us the total number of items in the slabs.
In the third image we are using the command stats items which will return us the total number of items in the slabs.
The forth image we are running stats cachedump 1 0 which will dump everything that is cached in slab 1, this is represented in the command by the 1 being the slab number to dump from and the 0 meaning dump everything, we could select a particular number to dump if we'd like but with only 5 items we might as well get everything in the slab. As we can see there is an item with the title password and another item with the title username.
In the final image we use the get command to get the information stored in that item, in this case get username returns Orka and get password returns us the password for the user Orka, which is the user on the machine.
Now all we need to do is use su to switch to the user, but first we need to establish a more stable shell so we can use su.
Now all we need to do is use su to switch to the user, but first we need to establish a more stable shell so we can use su.
After doing a quick check with uname -a we can see that the machine is listing i686 which means this is a 32bit machine rather than 64bit which my socat is compiled for.
Grabbing a compiled x86 version of socat and transferring that over resolved the errors I was facing so we now have a more stable shell and can switch over to the Orka user.
And there we have it, now we can go grab our user flag and move onto gaining root.
PrivEsc
Doing a quick check with sudo -l we can see that we can run a binary called bitcoin with root privileges, lets take a look at what this binary does with strings.
Looking at the python file we can see we only have read access to it and reading the file shows that we can see it takes that argument that is passed to it and then connects to port 3010 and sends the argument that has been passed.
As we can see from what strings returned though, there seems to be some restrictions in place that stop us from being able to send anything too complex so simply passing on a string that will inject a reverse shell isn't going to be as easy.
One thing that is noticeable in the bitcoin binary is that python is being called without a path, this means that it will go through each path directory until it finds a binary call python.
We can check where python is located by either using the where command or by going back to linpeas which we ran earlier.
We can check where python is located by either using the where command or by going back to linpeas which we ran earlier.
Python seems to be located in /usr/bin so that means when looking at secure_path from when we ran sudo -l we can see that 3 other directories are going to be looked at first when searching for the python command, lets take a look at all 3 of those directories and see if one of them we can write to.
Taking a look at each directory we can see that we are able to write to /usr/sbin which is great as if we put a binary called python there it will be called first before any other binary.
Simply creating a script that executes bash and calling it python should do. Our next issue is the fact based on strings, we need a password in order to run the bitcoin binary.
Using ltrace we can see what the application is doing when we run it.
As we can see above it is comparing the string we enter as the password with another string, this other string is obviously the correct password, so now when we run the application with sudo, we can enter that password in and hopefully successfully run our fake python binary to get root.
















































Comments
Post a Comment