Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
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}
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.
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!
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.
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:
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.
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:
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
The wget it on the box:
Then chmod, run and analyse the output.
Something that really sticks out is this:
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.
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 attack in order to leak the libc version before gaining RCE using a .
One output, one input, then the program breaks.
No PIE, meaning we can pull off the . Let's leak the libc version.
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!
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}
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 . We can bypass the 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.
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!
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. 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.
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?
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..}
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.
How we can utilise this will be detailed in the subpages.
Some helper functions to automate the actions.
If we google this comment we come across an interesting with a collection of reverse shells. Let's put their names in a file called wordlist.txt and run gobuster:
It definitely exists! The tells us the default credentials are admin:admin.
Next we use a l on the webshell to redirect execution to it:
We get a connection! This is a fairly bad shell, but we can easily .
To perform some automated privesc recon, I'm going to run . Port it over by hosting it on a python SimpleHTPServer:
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 .
We can now leak other symbols in order to pinpoint the libc version, for which you can use something like . Once you've done that, it's a simple .
When it comes to accounts, one very common thing to check is cookies. Cookies allow, among other things, for users to . 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 to decode it.
We also manage to bypass the by getting FD->bk and BK->fd to point at the chunk's entry in the list.
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 to identify the libc version. We can also change the beginning of our script.
For an introduction to pickle exploitation, I highly recommend . 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!
Checking out the documentation, there is a protocol parameter! If we , this can take a value from 0 to 5. If we play around, protocol=0 looks similar to the original cookie:
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 .
