Vulnhub: BTRSys v1.0 Boot2Root VM

Introduction

After enjoying the BTRSys V2 VM so much, I decided to have a pop at it’s predecessor, BTRsys1. Same as BTRsys #2, this VM was created by @ismailonderkaya and hosted by Vulnhub

NMap

As always we kick off by poking the VM with NMap to see which TCP ports are listening –
– So we can see here that there are a few things running. FTP, SSH and an Apache webserver.
FTP allows anonymous logins so we try that first  to see if it shows any interesting files or allows us to upload a shell –
So there are no files to read and we don’t have permission to write new files. Moving on!

HTTP Server

Pointing Firefox at the web server yields an index page with two links written in Turkish. One is just a “home” link pointing back to the index and the other points to –
Which isn’t immediately helpful. No hidden goodies in the page source either, so we’ll have to fall back to our old faithful tools Nikto and Dirb

Dirb

However sadly the uploads directory wasn’t as interesting as it sounded, just an empty directory.

Nikto

Nikto was more interesting and highlighted a login page was available, so let’s go and prod that and see what happens.

Login Page

As usual we try “admin:admin”. Rather than the usual “incorrect login” error we get a fancy Javascript popup in Turkish –
Looking at the source code shows us what the issue is:
As we can see, if we provide a username which doesn’t end in “@btrisk.com” then it’ll moan, and if we attempt some SQL injection on the form then it’ll shout at us too..
So on a whim I tried “admin@btrisk.com” with the password “admin” and it let me in.
Note: However it transpires that any username with @btrisk.com on the end is a valid login, password is irrelevant. Additionally navigating directly to the post-login page “personel.php” without entering a valid login is perfectly fine, it just throws an SQL error about missing parameters.
It turns out that our excitement over the login bypass was short lived, as it’s only giving us a limited form on the following page (which the source code shows to be some kind of personnel database with file upload utility)
After endless poking around I eventually found an SQL injection vulnerability in the username field of the login, and achieved an admin login using the following details –
kullanici_adi=admin’ OR 1=1–&parola=’ OR 1=1

Post Login

 
That’s more like it. File Upload components in websites are frequently vulnerable, allowing attackers to upload file types which they shouldn’t be allowed. If the site allows the upload of PHP files for example the attacker could upload a reverse PHP shell.
 
The only control here over the filetype is some Javascript on the page, which Chrome allows us to override using the developer tools.
I chose to use the developer console to set the getFile function to simply submit the form:
 
getFile = function() { document.myform.submit(); }
 
And now we can see our shell under “/uploads” (which Nikto highlighted for us earlier 🙂 )
 

Endgame

So we’ve achieved a limited shell on the box. Now it’s time to escalate our privileges to root and achieve full compromise.
First thing’s first, we move to a proper TTY meterpreter shell (Google it if necessary, there are tonnes of guides about)
Unix-privesc-check revealed nothing of interest so we go for the old faithful Kernel exploit. I chose this one which worked without issue. After running “passwd” to change to root password to “goat” we can SSH to the box and get a full TTY.

Conclusion

This was a great VM and had a few nice unique twists such as Javascript verification of file uploads, this is normally done server side for example.

Add a Comment

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.