Loading...
Loading...
Loading...
Loading...
We start off with a full-port nmap to check running services (most of output truncated)
We see port 22 with SSH and port 80 with HTTP. Let's check the HTTP.
We're greeted with a strange message:
It seems as if our job is to find the "backdoor" into the system. The source has nothing particularly interesting, except for a comment:
If we google this comment we come across an interesting GitHub repo with a collection of reverse shells. Let's put their names in a file called wordlist.txt and run gobuster:
It appears as if smevk.php is on the target! Let's head over to http://10.10.10.181/smevk.php and we what happens.
It definitely exists! The repo tells us the default credentials are admin:admin.
The webshell looks horrible, but we have an Execute input where we can run commands. We can now use this to get an actual reverse shell.
First we use nc on a terminal to listen for incoming connections:
Next we use a PHP reverse shell on the webshell to redirect execution to it:
We get a connection! This is a fairly bad shell, but we can easily upgrade it to be useful.
Now we have a foothold, let's check what's in our user's home directory. It appears to be a file called note.txt:
We have been left "a tool to practise Lua". As always, first thing we should do as a new user is check our permissions.
We can run luvit as sysadmin! We can guess that luvit is the tool that runs Lua scripts. Because we can run it as sysadmin, if we create a Lua script that spawns a shell we will spawn with higher privileges.
This is the command we want to run. We can simply use echo to create it:
Now let's run it as sysadmin!
You could also have done it in one line using the -e flag:
sudo -u sysadmin /home/sysadmin/luvit -e ‘os.execute(“/bin/bash”)’
We can now read user.txt!
Firstly, we want to get a nice SSH shell. We can get this using SSH keys.
First create the key pair:
I just hit Enter, meaning there's no passphrase. Now cat traceback.pub and echo it into ~/.ssh/authorized_keys - this registers the keypair as valid.
When using echo in these scenarios, use >> rather than >. Using only a single > will overwrite all the other contents, essentially erasing any keys owned by other people, which is not a great thing to do.
If ~/.ssh doesn't exist already, make sure you create it.
Make sure you spell it authorized not authorised!
Now we can log in via SSH using
To perform some automated privesc recon, I'm going to run linpeas. Port it over by hosting it on a python SimpleHTPServer:
The wget it on the box:
Then chmod, run and analyse the output.
Something that really sticks out is this:
These scripts get run every time someone logs in with SSH. If we can modify them (which we can), they will run whatever we modify them to. The important part here is they get run as root.
So the privesc is simple, but what should we get the file to do? There are a couple types of choices:
Run something that enables us to get root
Print the flag
In these situations, if both approaches are equivalently easy, then it's a good idea to go for the approach that affects the least other users. Nobody can notice our reverse shell since it's directly to our IP, so it doesn't affect other users.
Make sure you set up an nc listener on port 9002 and then log in via SSH again.
And bam, we have a root shell.
SQL Injection, Hash Length Extension, LFI and binary exploitation
Intense is definitely the best box I have ever done on HTB, and I loved it every step of the way. We start by doing some general tampering on the website and, combined with source code analysis, we find an SQL injection vulnerability. As there is no controllable output, we can execute a boolean-based blind SQL injection attack and extract the secret character by character.
The hash is not crackable, but rather used to sign a custom JWT token to prove it's authentic. The hashing algorithm in use is vulnerable to a Hash Length Extension attack, which allows us to append our own data to the hash and sign in as the admin. More source code analysis reveals admins have access to an API vulnerable to LFI.
Using the LFI we can grab an SNMP Read-Write Community string, which we can leverage for RCE. From here we exploit a vulnerable binary run by root to gain root access.
nmap shows ports 22 and 80 open, so let's have a look at 80.
Couple things to note right away:
We get given the default credentials guest:guest
The app is open source
I'm going to download the source right away, and while that goes I'll sign in as guest.
First things first, I notice a cookie has been assigned:
Looks like a custom JWT due to the two base64 strings separated by a .. Let's try decoding it.
The second part of the cookie looks like it's not ASCII. Based on how JWTs normally work, we'll assume it's the cookie signature.
Around now we crack open VS Code and have a look at how the cookie is made, along with possible attack vectors.
The cookies seem to be defined in lwt.py.
This function appears to create the signature we saw as part of the JWT (I'll call it an LWT from now to avoid confusion). How is SECRET defined?
SECRET is completely random, which means that hypothetically we shouldn't be able to forge the LWTs.
The base app.py has an interesting function, however:
If we use the Send Message feature of the website, our data gets parsed immediately into a database query. There's no sanitisation involved (with the exception of checking that the message is within 140 characters), so we should be able to do some SQLi.
Note how the function returns the SQLite error if there is one, meaning we should get some feedback:
Now we know there is some SQL injection involved, let's think about what we need to extract. In utils.py, we see that there's a try_login function:
Now we know there is a column called username and a column called secret. If we go back in the source, we can see that the secret is used for creating the LWTs.
In app.py:
Calling lwt.create_session() with the response:
Extracting the admin's secret might bring us one step closer to successfully logging in as the admin.
As only errors are returned, I originally attempted to trigger my own custom errors. In the end, though, I went for a boolean-based blind SQLi payload.
After a big of tampering, I finished on this payload:
CASE tests the specific thing we give it
SUBSTR(username,0,1) grabs the first character of the username
WHEN 'a' is the other part of CASE - if the value, in this case the result of SUBSTR() is a, it'll then run LOAD_EXTENSION('b'). If not, it essentially does nothing.
LOAD_EXTENSION('b') is just there to trigger the error if the first characters is a as there is likely to be no extension with the name b
We can assume the username is admin, but we should make sure.
We'll loop through username with every printable character and see if it matches. Note that it will also match guest, so there'll be two matches. The way I'll fix this is I'll print it out only if it's not the corresponding letter in the word guest and hope there are no common letters, although there's probably a better way.
If we find a match, we add it to the known string and go again.
Success!
As expected, the username is admin. Now let's extract the secret.
We get the hash f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105, which appears to be the correct size:
Now we have the secret, it's time to work out what we can use it for. The way the cookies are signed is vulnerable to a Hash Length Extension attack. A good explanation can be found here, but the basic theory is that even if you don't know the secret you can append data to the end of the hash simply by continuing the hashing algorithm.
I'll be using hashpumpy to extend the hashes.
The signature changes every reset, so make sure you update it!
I got the cookie
Updating it in Inspect Element works!
A logical place to look now would be admin.py.
The admin viewing abilities allow you to read files. Interesting. Are admin_view_log() and admin_list_dir() safe?
Nope! Simple LFI flaw.
I made a simple, messy script.
If we read /etc/passwd, we see there's a user called user.
Now to find a way to get foothold.
After some searching (and some nmap) we find SNMP is open, so let's see what we can do with that.
There's a rwcommunity called SuP3RPrivCom90. RW Communities can be leveraged for RCE. To do this, I'm going to use the metasploit linux/snmp/net_snmpd_rw_access module.
And we get a meterpreter shell! Our user is Debian-snmp.
If we go into the home directory of user, we see a note_server and a note_server.c. Running netstat -tunlp tells us there is something listening on port 5001.
We can dump the files using meterpreter.
Let's run the file and check if it's this that runs on port 5001:
Checking the source, it definitely does.
As the program is running remotely, binary exploitation seems likely, so I'm going to dump the remote libc and linker as well:
I'll rename them to libc-remote.so and ld-remote.so respectively.
A few things lack bounds checking, allowing us to a) leak the stack and b) write to the stack.
The only part that's important is the switch statement within handle_client(), as it's in an infinite loop that gets run.
To summarise, the code can do the following:
Write
Read input size - only one byte
Check if that would bring you over the max size
Read that many bytes
Increase index (a pointer to the end of the current note)
Copy
Take in offset
Take in size
Check if index is out of range
Copy Data
Increase index
Show
Write note contents
The main flaw here is the check for copy occurs before index is increased. So if we copy a massive chunk, the check will be passed anyway.
The binary uses fork(), which means the memory will be identical for every connection. Same binary base, same libc base, same canary, same everything.
First, some basic setup:
Now let's try writing 3 times then copying a massive amount.
Well, we've leaked significantly more than the stuff we wrote, that's for sure. Let's completely fill up the buffer, so we can work with the stuff after it. The buffer size is 1024 bytes, plus another 8 for the saved RBP.
Now we've successfully leaked, we can parse the values. Using radare2 and breaking on the ret, the offset between the leaked RIP value there and binary base is 0xf54:
Now we need to somehow read a GOT entry. Since the binary uses write(), it's possible. But first we need to get the copy working in a way that it starts overwriting at exactly the return pointer. With a bit of messing about, I got a function that seemed to work.
We're 12 off the canary at the end, so we put 12 A characters ahead and copy 12 extra.
TODO
LFI to RCE using PHAR files while bypassing disabled_functions, followed by abuse of SUID and sudo.
As per usual, we knock out a quick nmap:
It appears to be running Apache on Ubuntu, including a webserber titled Is My Website Up?
A quick look on the IP gives us a basic page. It appears to be an application that checks for you whether or not a website it up:
We can see at the bottom that siteisup.htb is the domain, so we add it to /etc/hosts. The website we are served, however, is still the same.
I listen with sudo nc -nvlp 80 but if we put in our IP, we get an interesting message:
If we put in http:// it works, though. There is probably some check to detect the protocol the request uses. It does appear to just be a GET request
Nothing of note here, except confirmation that the domain is siteisup.htb. On the website there is a massive delay and it says it's down:
This makes sense as we are not sending a response, so it has no way of telling. If we instead serve port 80 with a python SimpleHTTPServer, which has a response, we are told it's up:
There is once again no additional data:
If we turn on Debug Mode, the website prints out the headers and the HTML data.
We can also realise that we can use http://127.0.0.1 as input so SSRF could be possible. If we try and use other wrappers like file:// or php:// then it breaks and we get the Hacking attempt was detected ! message again.
It's not all wrappers that get blocked, as ippsec showed in his video, as ftp and gopher both work fine.
We can run some brute force scripts in the background for files and directories while we probe manually:
Gobuster detects that there is a /dev directory! This looks like the only useful thing it finds, as basically everything else is status code 403. Connection to /dev just loads up a blank page with no information.
But what if we bruteforce under /dev? In fact, we hit the jackpot - there's a .git directory!
We'll use a tool called git-dumper to dump the contents of the Git repo:
The contents are interesting. First we see index.php, which looks like this:
Essentially, it checks the page parameter; if it doesn't contain strings like bin or etc, it will append .php to the end and serve it back. If it does, it simply renders checker.php. checker.php is the file for the main page we see on a normal connectiong, which checks if a website is up or not.
There is clearly LFI here, but made slightly more difficult by the blacklist and the addition of .php onto the end of a filename.
Additionally, we can dump more details from Git using the git log command. A couple of intersting commits come up if that happens:
There is very potentially some interesting information in .htpasswd and .htaccess, and the mention of a dev vhost is useful too - there may be a dev.siteisup.htb. We'll add this to our hosts file, but if we try to connect, it tells us it's Forbidden to access that resource. We've at least confirmed that the subdomain exists and is treated differently.
If we checkout the commit 8812785e31c879261050e72e20f298ae8c43b565 using git checkout, we can see that .htpasswdexists, but it's empty:
.htaccess is much more intersting:
This tells us there is a special header that needs to be set called Special-Dev with the value only4dev. COnsidering the description of the commit is New technique in header to protect our dev vhost and dev.siteisup.htb is Forbidden, it's likely for that. We can check using BurpSuite:
And it looks like it is!
To make it easier for us, we're gonna get BurpSuite to add the header for us with its proxy (thanks to ippsec for this!). We can go to Match and Replace under Proxy Options:
And we can access it successfully in the browser:
Fiddling around with the website, we realise it reflects the git repository perfectly - the hyperlink for the Admin Page adds ?page=admin to the request, which then spits out the contents of admin.php. Clearly, the LFI works.
A logical route here would be to upload our own file and then LFI it for RCE. However, there are two issues with this.
Firstly, the server checks the file extension, and denies uploading a fair few of them:
Secondly, the server appends .php to the page parameter of the GET request:
We have to somehow bypass these restrictions to get proper LFI.
If we have a proper look at the code, we realise that it all happens very quickly:
So after all the checks, it:
Uploads it to uploads/, under a folder by time
Reads all the lines in the file, putting them into a list
Queries each element of the list to see if it's up
Deletes the file
So it seems like it expects a list of websites to check, then once that's done deletes them immediately.
Note that if the webserver doesn't respond, it hangs for a period of time - this is the massive delay we noticed right away. We can use this to our advantage and keep the server running, leaving the file up.
We make a very simple test.php:
As we predicted, the server rejects the file. If we rename it to test.txt and try again, the upload is successful. If we go to http://dev.siteisup.htb/uploads/, we see the file gets deleted immediately. Let's add our own IP and see if it hangs long enough for us to actually get it:
Still nothing. The resposne is very quick on the original site, so it probably detected the socket was closed. If we open the socket but don't respond, for example with netcat, it might delay:
And now if we run over to uploads we can see the file!
We can actually also add the -k flag to the above nc command to keep the listening persist over multiple connections. I'll have this running in the background while I tinker with what can be done.
PHP has its own archives called phar files, where you essentially package up PHP files into a zip file. The cool thing about a phar file is that we can use the phar:// stream wrapper to access a PHP script inside the phar file.
The way this works is that we can have a file with the .php extension, then in the page parameter of the GET request we can use the phar:// wrapper to access the PHP file inside it.
We'll make test.php really simple to start with:
We then compress it into a phar file:
The upload works! Let's try and access the file itself. In BurpSuite, we'll use Repeater to query for the file. Note that the server appends the .php for us - that's half the reason we have to do it this way! So don't include the extension in the page parameter.
It worked! Now let's do a crazier command, like system("ls"):
Huh, it's an Internal Server Error. Considering that the previous attempt worked well, chances are some PHP functions are disabled. This is done using disabled_functions, and we can check by running phpinfo(), so let's do that:
There are a lot of disabled functions, but one that is not disabled is proc_open(). This can be found using the tool dfunc-bypasser, as recommended by ippsec and 0xdf. A proc_open() reverse shell can be pretty simple:
A basic reverse shell to port 4000. Let's do the exact same thing and pray it works.
Which it does! We upgrade the shell quickly using
A quick check in /home tells us there is a developer user. If we go into their home directory then /dev, there is a SUID binary named siteisup with the source code siteisup.py. We can read siteisup.py:
We can immediately spot this is python2, and even more importantly it's using input() in python2 - which can easily lead to code execution. If we run ./siteisup, we get prompted for the URL. If we enter a simple os.system command, we get a response:
Aside from the errors, we can see it works! Now we can run __import__('os').system('bash') and get a shell as developer. I'll grab the id_rsa in .ssh, call it dev.key and SSH in:
And now we have a shell as developer and can read user.txt!
We can check our sudo permissions:
We have sudo permissions to run easy_install. We can use GTFOBins to find an easy sudo privesc for easy_install:
And from there we easily read root.txt.
SQL injection, PHP reverse shell upload, mysqldump and PATH injection
As always, let's start with an nmap:
Only ports 22 and 80. Add magic.htb to your /etc/hosts and let's check out the website.
There's definitely a lot going on. By analysing the source we can see some images are in the images/uploads/ folder, which is useful for later. Let's click the Login button at the bottom left.
First thing's first, let's try the default admin:admin. We get told it's invalid.
Now we can mess with the input to test for SQL injection. Tampering with a payload such as '<>:32;4#::!@$":' doesn't tell us it's invalid; perhaps it's having an affect?
If we try a basic payload such as admin'#, what happens? The logic here is it logs in with the username admin and comments out the password check to always successfully log us in, essentially making it
Success!
