Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
First we're met with a signin form:
Let's try some default creds, admin and admin.
Below, the query run on the database is shown; this seems like a clear example of SQL injection.
Ultimately, we want to try and log in as a user. To do this, we can try to inject our own SQL.
We know the payload looks like the following:
We want to trick this into always returning a user, and to do this we'll inject a clause that's always true, such as 1=1.
That will make the query equal to the following:
So here, it'll compare the username to admin, and if it's not the same the check will still pass because 1=1. However, there's a small issue with the password still being wrong. To bypass this check, we'll make everything after our injection a comment so that the databse ignores it:
That would make the query be:
As you can see, the username will always be correct due to the 1=1 and the password check is commented out! Let's try it.
We still have to input a password because some javascript checks to make sure it's there, but we can fill that with any rubbish. And we get the flag!
HTB{SQL_1nj3ct1ng_my_w4y_0utta_h3r3}
Ropme was an 80pts challenge rated as Hard on HackTheBox. Personally, I don't believe it should have been a hard; the technique used is fairly common and straightforward, and the high points and difficulty is probably due to it being one of the first challenge on the platform.
Exploiting the binary involved executing a ret2plt attack in order to leak the libc version before gaining RCE using a ret2libc.
One output, one input, then the program breaks.
No PIE, meaning we can pull off the ret2plt. Let's leak the libc version.
We can now leak other symbols in order to pinpoint the libc version, for which you can use something like here. Once you've done that, it's a simple ret2libc.
Dream Diary: Chapter 1 (known as DD1) was an insane pwn challenge. It is one of the few heap challenges on HackTheBox and, while it took a great deal of time to understand, was probably one of the most satisfying challenges I've done.
There were two (main) ways to solve this challenge: utilising an unlink exploit and overlapping chunks then performing a fastbin attack. I'll detail both of these, but first we'll identify the bug and what it allows us to do.
Let's have a look at what we can do.
So at first look we can create, edit and delete chunks. Fairly standard heap challenge.
Now we'll check out the binary in more detail.
Many of the functions are bloated. If there is a chunk of irrelevant code, I'll just replace it with a comment that explains what it does (or in the case of canaries just remove altogether). I'll also remove convoluted multi-step code, so the types may be off, but it's much more readable.
Very simplified, but it takes in a size and then calls malloc() to assign a chunk of that size and reads that much data into the chunk.
Again, quite simplified. Calls strlen() on the data there, reads that many bytes in.
The delete() function is secure, so it's clearly not an issue with the way the chunk is freed. Now we can check the functions that write data, allocate() and edit().
allocate() only ever inputs how much it allocates, so it's secure. The bug is in edit():
Remember that strlen() stops at a null byte. If we completely fill up our buffer the first time we allocate, there are no null bytes there. Instead, we will continue into the size field of the next chunk.
Provided the size field is greater than 0x0 - which is will be - strlen() will interpret it as part of the string. That only gives us an overflow of one or two bytes.
But what can we do with that? The last 3 bits of the size field are taken up by the flags, the important one for this being the prev_in_use bit. If it is not set (i.e. 0) then we can use PREV_SIZE to calculate the size of the previous chunk. If we overwrite P to be 0, we can fake PREV_SIZE as it's originally part of the previous chunk's data.
How we can utilise this will be detailed in the subpages.
Some helper functions to automate the actions.
When we start the instance, we are met with an options menu:
It appears as if we can input the IP, which is then pinged. Let's imagine for a second how this could be implemented on the server side. A common trap developers can fall into is doing something like:
Essentially, we're passing the parameters to bash. This means we could, theoretically, insert a ; character into the ip variable, and everything behind it would be interpreted as a seperate command, e.g.:
Here, ls would be run as a separate command. Let's see if it works!
Let's try it by simply inputting ; ls to the end of the IP and submitting:
Look - as well as the ping command, we get index.php, which is the result of the ls command!
There doesn't appear to be a flag, so we'll try ; ls / to read the root directory next:
Woo - there's a flag_2viTb file! Now we'll inject ; cat /flag_2viTb to read the flag:
And boom, we've got the flag - HTB{I_f1n4lly_l00k3d_thr0ugh_th3_rc3}.
Because I prefer a command-line interface, I originally created a simple script to inject parameters for me:
This simply inputs the command as cmd, sets the POST parameters, and (really messily) parses the response to return just the data.
We can inject cat index.php to see what exactly was happening, and we immediately see the following lines:
As we guessed, it passed in the input without sanitising it to remove potential injection.
In this approach, we overwrite PREV_SIZE to shrink the size of the previous chunk. This tricks the heap into thinking that the previous chunk's metadata starts where our data does, enabling us to control chunk metadata. As we can control the fd and bk pointers, we can execute an unlink exploit. We can bypass the unlink security checks by pointing fd and bk to the chunklist, which contains a pointer to the chunk.
This enables us to overwrite a chunklist entry with the address of the chunklist itself, meaning we can now edit the chunklist. This gives us the ability to write to wherever we want, and we choose to target the GOT. We can overwrite strlen@got with puts@plt as that makes it functionally equivalent and then read a libc address. From here we overwrite free@got with the address of system and free() a chunk containing /bin/sh.
To bypass the unlink check, we need P->fd->bk to point to the address of P, meaning P->fd has to point 0x18 bytes behind it. Because we want P->fd to be within the chunklist (most simply at the beginning), we will allocate 3 chunks before the chunk we use for the unlink() exploit. Each chunk we allocate takes up 0x8 bytes of space on the chunklist (this will make more sense later, I promise).
We'll choose a size of 0x98 for the chunks. Firstly, this means the chunk does not fall in fastbin range. Secondly, the additional 0x8 bytes means we do in fact overwrite prev_size. Other sizes such as 0x108 would also work, but make sure Chunk 4 overwrites Chunk 5's prev_size field.
Now we will create a fake chunk. The fake size we give it will be the difference between the start of our fake data and the next consecutive chunk. In this case, that is 0x90 - as you see from the image, the difference between chunks 4 and 5 is 0xa0, so if we remove the metadata the fake chunk is 0x90. We'll also overwrite PREV_IN_USE to trick it into thinking it's free.
And if we send this all off, we can see it worked perfectly:
radare2 tells us chunk 4 is free. Chunk 5 has a new prev_size and P is no longer set. If we run dmhc again to view the chunk at location of chunk 5 - 0x90, our fake chunk is set up exactly as planned.
Now we free chunk 5, making Chunks 4 and 5 consolidate. This triggers a call to the unlink() macro on Chunk 4. Let's look at how we expect the unlink to go.
Both writes write to CHUNKLIST + 0x18, and the value written is the address of the chunklist. Now, if we edit Chunk 3, we're actually editing the chunklist itself as that's where the pointer points to.
We also manage to bypass the unlink check by getting FD->bk and BK->fd to point at the chunk's entry in the list.
Note that the value written was the location of fd, so if the chunk we overflowed with was Chunk 0 we would have had to write to a location ahead of the chunklist in memory in order to bypass the check, and pad all the way to the start before we could edit chunklist entries. By allocating 3 chunks before the overflow chunk we were able to write the chunklist address to entry 4 directly and bypass the check, meaning we had to mess around with padding less.
And it definitely worked:
Editing Chunk 3 now edits the chunklist itself, meaning we can overwrite pointers and gain arbitrary writes.
If we go back to the disassembly of edit(), we notice strlen() is called on the chunk data. We can overwrite strlen@got with puts@plt to print out this data instead - and using puts has an additional benefit: puts also returns the length of the string it reads. This means the program will not break, but we'll still gain the additional functionality.
Once we overwrite strlen@got, we'll call edit() on another GOT entry (free) to leak libc.
Now we just attempt to edit Chunk 0. Because it would print the libc address as soon as we enter the index, we'll have to do this part manually or the p.sendlineafter() lines would skip over the leak.
The response we get is
So it worked! Let's just parse the response and print out the leak.
Perfect.
This is quite simple - change a GOT entry such as free and replace it with system. Then, if the chunk contains /bin/sh, it'll get passed to the function as a parameter.
You may notice the 2nd and 3rd chunks have been untouched so far, so we could easily place the /bin/sh in one of those right at the beginning for use now.
We're currently halfway through using edit() on free@got, so we can just continue inputting system@libc as the data, then free Chunk 1.
And boom - success!
There are a few changes we need to make remotely. Firstly, the libc may be different (it was for me). Simply leak a couple more libc addresses and use somewhere like here to identify the libc version. We can also change the beginning of our script.
Secondly, the way the service uses socat means it echoes our input back to us. Because of the way we use p.sendlineafter(), this doesn't affect us until we parse the libc leak. We can just listen to the extra data if it's on REMOTE mode.
Thirdly, the socat used has pty enabled. This means it interprets the \x7f we send as the ascii representation of backspace, which would delete anything we sent. To mitigate this (it's only relevant when sending system) we just check if we're on REMOTE mode and if we are we can escape the \x7f with \x16, the socat escape character.
And it works perfectly!
All the references to pickles implies it's an insecure deserialization challenge. pickle is a serialization format used in python.
If we check the cookies, we get the following:
Our guess is that this is a pickled python object, and decoding the base64 seems to imply that to us too:
Let's immediately try to unpickle the data, which should give us a feel for how data is parsed:
The error is quite clear - there's no anti_pickle_serum variable. Let's add one in and try again.
That error is fixed, but there's another one:
Here it's throwing an error because X (anti_pickle_serum) is not a type object - so let's make it a class extending from object!
And now there's no error, and we get a response!
So the cookie is the pickled form of a dictionary with the key serum and the value of an anti_pickle_serum class! Awesome.
For an introduction to pickle exploitation, I highly recommend this blog post. Essentially, the __reduce__ dunder method tells pickle how to deserialize, and to do so it takes a function and a list of parameters. We can set the function to os.system and the parameters to the code to execute!
Here we create the malicious class, then serialize it as part of the dictionary as we saw before.
Huh, that looks nothing like the original cookie value (which starts with KGRwMApTJ3)... maybe we missed something with the dumps?
Checking out the dumps() documentation, there is a protocol parameter! If we read a bit deeper, this can take a value from 0 to 5. If we play around, protocol=0 looks similar to the original cookie:
Let's change the cookie to this (without the b''):
As you can see now, the value 0 was returned. This is the return value of os.system! Now we simply need to find a function that returns the result, and we'll use subprocess.check_output for that.
For reasons unknown to me, python3 pickles this differently to python2 and doesn't work. I'll therefore be using python2 from now on, but if anybody know why that would happen, please let me know!
Now run it
And input it as the cookie.
As can now see that there is a flag_wIp1b file, so we can just read it!
While it's tempting to do
subprocess.check_output requires a list of parameters (as we see here) and the filename is a separate item in the list, like so:
And boom - we get the flag!
HTB{g00d_j0b_m0rty...n0w_I_h4v3_to_g0_to_f4m1ly_th3r4py..}
We are first greeted by a login page. Let's, once again, try admin with password admin:
Looks like we'll have to create an account - let's try those credentials.
This is great, because now we know we need a user called admin. Let's create another user - I'll use username and password yes, because I doubt that'll be used.
We're redirected to the login, which makes it seem like it worked. Let's log in with the credentials we just created:
Whoops, guess we're not an admin!
When it comes to accounts, one very common thing to check is cookies. Cookies allow, among other things, for users to authenticate without logging in every time. To check cookies, we can right-click and hit Inspect Element and then move to the Console tab and type document.cookie.
Well, we have a cookie called PHPSESSID and the value eyJ1c2VybmFtZSI6InllcyJ9. Cookies are often base64 encoded, so we'll use a tool called CyberChef to decode it.
Once we decode the base64, we see that the contents are simply {"username":"yes"}.
So, the website knows our identity due to our cookie - but what's to stop us from forging a cookie? Since we control the cookies we send, we can just edit them. Let's create a fake cookie!
Note that we're URL encoding it as it ends in the special character =, which usually has to be URL encoded in cookies. Let's change our cookie to eyJ1c2VybmFtZSI6ImFkbWluIn0%3D!
Ignore the warning, but we've now set document.cookie. Refresh the page to let it send the cookies again.
And there you go - we successfully authenticated as an admin!
HTB{s3ss10n_1nt3grity_1s_0v3r4tt3d_4nyw4ys}
