1 of 8

Linux Machines

Easy

Traceback

Enumeration

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.

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 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 tells us the default credentials are admin:admin.

Foothold

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 l on the webshell to redirect execution to it:

We get a connection! This is a fairly bad shell, but we can easily .

User

Enumeration

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.

Exploitation

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!

Root

Firstly, we want to get a nice SSH shell. We can get this using SSH keys.

Getting SSH Access

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

Finding the Vulnerability

To perform some automated privesc recon, I'm going to run . 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 .

Exploitation

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.

Medium

Magic

SQL injection, PHP reverse shell upload, mysqldump and PATH injection

Enumeration

As always, let's start with an nmap:

$ sudo nmap -sS -n -p- -sV -sC -oN depth.nmp 10.10.10.185

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 06:d4:89:bf:51:f7:fc:0c:f9:08:5e:97:63:64:8d:ca (RSA)
|   256 11:a6:92:98:ce:35:40:c7:29:09:4f:6c:2d:74:aa:66 (ECDSA)
|_  256 71:05:99:1f:a8:1b:14:d6:03:85:53:f8:78:8e:cb:88 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Magic Portfolio
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Only ports 22 and 80. Add magic.htb to your /etc/hosts and let's check out the website.

HTTP

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!

UpDown

LFI to RCE using PHAR files while bypassing disabled_functions, followed by abuse of SUID and sudo.

Enumeration

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?

Webserver

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.

Website Analysis

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 , as ftp and gopher both work fine.

Gobuster

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!

Git

We'll use a tool called 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.

.htpasswd

If we checkout the commit 8812785e31c879261050e72e20f298ae8c43b565 using git checkout, we can see that .htpasswdexists, but it's empty:

.htaccess

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

Dev Website

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.

LFI Exploitation

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

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.

File Upload Attempt

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.

PHAR Files

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 .

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 . 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 , as recommended by and . 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

Privesc to Developer

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!

Privesc to Root

We can check our sudo permissions:

We have sudo permissions to run easy_install. We can use:

And from there we easily read root.txt.

Hard

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

Traceback

Enumeration

We start off with a full-port nmap to check running services (most of output truncated)

$ sudo nmap -sS -n -p- -A -oN full.nmp 10.10.10.181

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)
|   256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)
|_  256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us

We see port 22 with SSH and port 80 with HTTP. Let's check the HTTP.

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 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 tells us the default credentials are admin:admin.

Foothold

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 l on the webshell to redirect execution to it:

We get a connection! This is a fairly bad shell, but we can easily .

User

Enumeration

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.

Exploitation

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!

Root

Firstly, we want to get a nice SSH shell. We can get this using SSH keys.

Getting SSH Access

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.

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

Finding the Vulnerability

To perform some automated privesc recon, I'm going to run . 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 .

Exploitation

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

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.

UpDown

LFI to RCE using PHAR files while bypassing disabled_functions, followed by abuse of SUID and sudo.

Enumeration

As per usual, we knock out a quick nmap:

$ nmap -p- -sC -sV 10.10.11.177 -oA nmap/basic.nmp
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 9e:1f:98:d7:c8:ba:61:db:f1:49:66:9d:70:17:02:e7 (RSA)
|   256 c2:1c:fe:11:52:e3:d7:e5:f7:59:18:6b:68:45:3f:62 (ECDSA)
|_  256 5f:6e:12:67:0a:66:e8:e2:b7:61:be:c4:14:3a:d3:8e (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Is my Website up ?
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

It appears to be running Apache on Ubuntu, including a webserber titled Is My Website Up?

Webserver

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.

Website Analysis

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.

It's not all wrappers that get blocked, as ippsec showed in , as ftp and gopher both work fine.

Gobuster

We can run some brute force scripts in the background for files and directories while we probe manually:

But what if we bruteforce under /dev? In fact, we hit the jackpot - there's a .git directory!

Git

We'll use a tool called to dump the contents of the Git repo:

The contents are interesting. First we see index.php, which looks like this:

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:

.htpasswd

If we checkout the commit 8812785e31c879261050e72e20f298ae8c43b565 using git checkout, we can see that .htpasswdexists, but it's empty:

.htaccess

.htaccess is much more intersting:

And it looks like it is!

Dev Website

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:

LFI Exploitation

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

So it seems like it expects a list of websites to check, then once that's done deletes them immediately.

File Upload Attempt

We make a very simple test.php:

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!

PHAR Files

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 .

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:

It worked! Now let's do a crazier command, like system("ls"):

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

Privesc to Developer

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!

Privesc to Root

We can check our sudo permissions:

We have sudo permissions to run easy_install. We can use:

And from there we easily read root.txt.

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

Linux Machines

Easy

Traceback

hashtagEnumeration

hashtagHTTP

hashtagFoothold

hashtagUser

hashtagEnumeration

hashtagExploitation

hashtagRoot

hashtagGetting SSH Access

hashtagFinding the Vulnerability

hashtagExploitation

Medium

Magic

hashtagEnumeration

hashtagHTTP

UpDown

hashtagEnumeration

hashtagWebserver

hashtagWebsite Analysis

hashtagGobuster

hashtagGit

hashtag.htpasswd

hashtag.htaccess

hashtagDev Website

hashtagLFI Exploitation

hashtagFile Upload Attempt

hashtagPHAR Files

hashtagPrivesc to Developer

hashtagPrivesc to Root

Hard

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

Easy

Traceback

hashtagEnumeration

hashtagHTTP

hashtagFoothold

hashtagUser

hashtagEnumeration

hashtagExploitation

hashtagRoot

hashtagGetting SSH Access

hashtagFinding the Vulnerability

hashtagExploitation

UpDown

hashtagEnumeration

hashtagWebserver

hashtagWebsite Analysis

hashtagGobuster

hashtagGit

hashtag.htpasswd

hashtag.htaccess

hashtagDev Website

hashtagLFI Exploitation

hashtagFile Upload Attempt

hashtagPHAR Files

hashtagPrivesc to Developer

hashtagPrivesc to Root

Hard

Medium

Enumeration

HTTP

Foothold

User

Enumeration

Exploitation

Root

Getting SSH Access

Finding the Vulnerability

Exploitation

Enumeration

HTTP

Enumeration

Webserver

Website Analysis

Gobuster

Git

.htpasswd

.htaccess

Dev Website

LFI Exploitation

File Upload Attempt

PHAR Files

Privesc to Developer

Privesc to Root

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

Enumeration

HTTP

Foothold

User

Enumeration

Exploitation

Root

Getting SSH Access

Finding the Vulnerability

Exploitation

Enumeration

Webserver

Website Analysis

Gobuster

Git

.htpasswd

.htaccess

Dev Website

LFI Exploitation

File Upload Attempt

PHAR Files

Privesc to Developer

Privesc to Root

Enumeration

HTTP

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