1 of 1

Intense

SQL Injection, Hash Length Extension, LFI and binary exploitation

Overview

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 . From here we exploit a vulnerable binary run by root to gain root access.

Enumeration

Nmap

nmap shows ports 22 and 80 open, so let's have a look at 80.

HTTP

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.

Source Code Analysis

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.

SQL Injection

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.

Payload Formation

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

Extracting the admin username

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.

Extracting the admin secret

We get the hash f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105, which appears to be the correct size:

Signing in as the admin

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 , 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!

Analysing the Source as Admin

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.

Scripting the LFI

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 . 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.

Finding Root

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.

Exploiting the Binary

Summary

A few things lack bounds checking, allowing us to a) leak the stack and b) write to the stack.

Analysis

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

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.

Setup

First, some basic setup:

Leaking Canary and PIE

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.

Leaking LIBC

TODO

Intense

SQL Injection, Hash Length Extension, LFI and binary exploitation

Overview

Using the LFI we can grab an SNMP Read-Write Community string, which we can . From here we exploit a vulnerable binary run by root to gain root access.

Enumeration

Nmap

nmap shows ports 22 and 80 open, so let's have a look at 80.

HTTP

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.

Source Code Analysis

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:

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.

SQL Injection

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.

Payload Formation

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

Extracting the admin username

We can assume the username is admin, but we should make sure.

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.

Extracting the admin secret

We get the hash f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105, which appears to be the correct size:

Signing in as the admin

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!

Analysing the Source as Admin

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.

Scripting the LFI

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 . 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.

Finding Root

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.

Exploiting the Binary

Summary

A few things lack bounds checking, allowing us to a) leak the stack and b) write to the stack.

Analysis

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

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.

Setup

First, some basic setup:

Leaking Canary and PIE

Now let's try writing 3 times then copying a massive amount.

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:

We're 12 off the canary at the end, so we put 12 A characters ahead and copy 12 extra.

Leaking LIBC

TODO

Intense

hashtagOverview

hashtagEnumeration

hashtagNmap

hashtagHTTP

hashtagSource Code Analysis

hashtagSQL Injection

hashtagPayload Formation

hashtagExtracting the admin username

hashtagExtracting the admin secret

hashtagSigning in as the admin

hashtagAnalysing the Source as Admin

hashtagScripting the LFI

hashtagFinding Root

hashtagExploiting the Binary

hashtagSummary

hashtagAnalysis

hashtagSetup

hashtagLeaking Canary and PIE

hashtagLeaking LIBC

Intense

hashtagOverview

hashtagEnumeration

hashtagNmap

hashtagHTTP

hashtagSource Code Analysis

hashtagSQL Injection

hashtagPayload Formation

hashtagExtracting the admin username

hashtagExtracting the admin secret

hashtagSigning in as the admin

hashtagAnalysing the Source as Admin

hashtagScripting the LFI

hashtagFinding Root

hashtagExploiting the Binary

hashtagSummary

hashtagAnalysis

hashtagSetup

hashtagLeaking Canary and PIE

hashtagLeaking LIBC

Overview

Enumeration

Nmap

HTTP

Source Code Analysis

SQL Injection

Payload Formation

Extracting the admin username

Extracting the admin secret

Signing in as the admin

Analysing the Source as Admin

Scripting the LFI

Finding Root

Exploiting the Binary

Summary

Analysis

Setup

Leaking Canary and PIE

Leaking LIBC

Overview

Enumeration

Nmap

HTTP

Source Code Analysis

SQL Injection

Payload Formation

Extracting the admin username

Extracting the admin secret

Signing in as the admin

Analysing the Source as Admin

Scripting the LFI

Finding Root

Exploiting the Binary

Summary

Analysis

Setup

Leaking Canary and PIE

Leaking LIBC