Advent of Cyber - Web Exploitation section

First, as it's very important we will need to keep a reference of the story - the characters , premise etc - as multiple tasks throughout the event use it.

"

After last year's shenanigans where Elf McElferson and Elf McSkidy were on damage control mode the entirety of December, McSkidy vowed to never let that happen again. The previous Christmas period was extremely stressful with the Christmas Monster managing to compromise every system within Santa's corporate infrastructure to prevent Christmas from happening. Is Christmas still in danger this year?



McSkidy showed great promise with the previous incident and was tasked with building up a security team within Santa's company - *The Best Festival Company*. Due to resistance from management, budgeting and bureaucracy issues, McSkidy was only able to start building out her team from the 8th November. Since then, she's only hired 2 team members - one security specialist Elf McHacker and one intern Elf McEager.

It's the evening of 30th November - McSkidy's team has been working hard to prevent any down time and security incidents within the entire network and application stack of the Best Festival Company. McHacker suggested installing a VPN and only allowing access to the infrastructure via the VPN. After a long 8 hour installation and deployment, McSkidy opens her monitoring dashboard and notices that no traffic is flowing to any of the applications (this was expected as no one had access to the VPN). *thank god,* she said. *Getting hacked again is not an option.*

*RING, RING, RING* - her Elf hotline starts ringing and she jumps. *Santa's schedule isn't working - I CAN'T SEE ANYTHING,* yells Elf McAssistant. Within a matter of seconds hundreds of phone calls come in and *Elf McSkidy gets that sinking feeling in her stomach.* She quickly dispatches *McHacker* to analyse the VPN logs. He notices a payload that resembles a VPN authentication bypass that allows anyone to bypass the VPN - *did someone install the wrong version.* With the poor state of security across the entire network, this unknown actor managed to access all applications and their underlying servers!

Unlike last time, no one has claimed responsibility for this incident. *Here we go again*, she sighs. It's up to you (Elf McEager) and the rest to save Christmas.

"

Task 1 : [Web Exploitation] A Christmas Crisis

We need to find our way back into Santa's Christmas control centre ! To do this we need to turn to the web application:

Here we can see I turned burp on, as this task is practically demanding it - though you don't have to use anything really - I find it's powers of examination priceless. Turn on the extension, set the scope (which for me was the IP in the search bar) and keep intercept on , as we want to see the cookies this thing throws back. Let's try registering an account:

And we get back,

Perfect, let's try logging in then.

After forwarding our login packet we get our response, and we can see our cookie is called auth but it looks like gibberish. I tried a few different methods like base64 and other encryption schemes, but when I plugged into this hexadecimal converter:

This is some pretty poor cookie , it doesn't even have a password ! What this means is if we supply the right username, like Santa then we can have that account's privileges. Let's try it out.

As we construct our cookie we will need to log out of the Christmas console and then in the browser insert our new hexadecimal value into the value field. All we need to do is refresh the page, which will give a request of / , with the cookie inside and we should be authenticated.

Keep note to get to this stage I did have some problems with burp and the machine , so if you see that the website automatically logs you out and rejects the cookie , just restart the machine, insert the cookie you found and refresh, no problem.

Onto task two!

Task 2 : [Web Exploitation] The Elf strikes back !

In this box we shall be looking at GET requests now, no longer sticking to our POST request cookie skills. The main difference between the two types of requests is their motive, and their data management. POST is used to issue data to the client, whereas GET will issue data as a side-effect of wanting a particular resource, in this case the data we need to supply is our ID to get into the upload section of the website:

We need to add the ?id=ODIzODI5MTNiYmYw section to the URL as the ? denotes we are adding data to the resource link, and then subsequent variables of the form a=b represent data - with more than one separated by &.

We can see the request if we use burpsuite:

And the response we get shows us some very interesting things within the html of that page:

Depending on the way the upload filter code is implemented, it may just split the file name at the extension . and if the next immediately proceeding attribute is jpeg or something, which we can see is part of the allowed image file types , then if we sneakily put .php after it would allow the reverse shell script to proceed through... We don't need to change the contents, so the server can still recognise the code as PHP and we're fine.

Make sure to remove them from the html code and then it allows us to select the script from our folder

The last bit now will be to call that file so the script is executed, and to find where the file is we need to use the big guns, I loaded up dirbuster and it found the directory , and even my shell pretty quickly:

So we can see that /uploads is where we need to go,

Make sure that before you click on the shell:

You have a nc listener on:

And now we can see that it got executed and we're in !

Most websites are served in /var/www/ and so it's no wonder we're asked to check there. Type in

cat /var/www/flag.txt

And you shall see your flag.

Task 3 : [Web-Exploitation] Christmas Chaos

This box is to do with bypassing credentials, through brute-forcing. Here we shall go further with the concepts of authentication and authorisation. Authentication can be best described as aligning the credentials someone has provided with the credentials that are stored on the system, and checking whether someone can access their account. Authorisation is aligning the permissions of the account's request with what is stored on the system to see whether they can access a resource.

Default credentials are an authentication nightmare as it means anyone can authenticate, and we have no authenticity with users - as they could all use this account if they are familiar with the default credential set.

What we can also do is constantly see if we can line up the credentials stored by brute-forcing - which is where we just try a list of usernames and/or passwords into a login form etc. As this is with web-forms we can use either burpsuite or hydra.

We can see that for this box we have given the dictionaries necessary for bruteforcing, so I'll make those files to use as input:

The -e is for echo to evaluate characters such as \n, \t etc.

Let's switch it up and use hydra for a change, all I want to establish is the POST API endpoint and if there are any cookies, so I'll use burpsuite briefly:

So we can see the names of the login fields, and we can see the location is /login. Now to put it together. Remember from our GET and POST challenges in the other two tasks , that the POST data is kept in the body not within the URL, so when people do this in hydra:

"/dvwa/login.php:username=^USER^&password=^PASS^

;; this isn't to signify that the data is within the URL string, it is to say all the
;; arguments which need to be included for that endpoint. The : is hydra syntax.

You can see that hydra will give all the possible combinations as correct passwords if we don't provide the login part of the data correctly. We can see that the error message produced for wrong passwords is username_incorrect. But if I just change the message for

&Login=Login:Your username isn't correct

to Your username is incorrect then we see that the right error data, which is shown on the website once we make a mistake

can help hydra identify the responses in which the website has rejected:

So we get cleaner and more accurate output. Now let's login.

Task 4 : [Web Exploitation] Santa's Watching

In this box we're going to be looking at fuzzing, which is essentially a finer-grained - and much more widely applicable use of the concept of brute-forcing, but we try use it against pretty much any input the program has, whether it be fields , articles , headers, forms URLs etc.

We often use automating tools for this as there is such a depth of data we need to try on such a wide variety of inputs... One such tool is wfuzz which we shall look at in a moment.

Brute-forcing, as the name would suggest, is a bit of a blunter tool and it is used mostly for simple targets like directories on a website , DNS or for finding all the different vhosts of a domain , for example this is a vhost scan using gobuster :

This is the tool we'll be using to find some of the hidden directories in this box, and so to turn its attention to the website I'll have to use dir mode. Besides

gobuster [mode] ...

Here are some of the other options:

Target in question:

And our gobuster run

Ah ha ! The famed API directory

Now if we try and click on this file without the right date parameter value , essentially of the form:

10.10.130.9/api/site-log.php?date=20201101

;; format is YYYYMMDD

Now I am going to cheat and use the wordlist provided in /opt/AoC-2020/Day-4 for wfuzz to crack:

Options for wfuzz:

And so we can begin testing by:

wfuzz -z file,wordlist -c --hc 404 http://10.10.160.10/api/site-log.php?date=FUZZ

If we did a rudimentary brute-force we would struggle to identify the result which differed, as our means of separation is at the levels of status codes, but we can see the character response sizes and if we go to this URL with that payload we see the flag...

Task 5 : [Web Exploitation] Someone stole Santa's gift list!

In this task we shall be making heavy use of the powers of SQL injection, poor SQL handling and creating some payloads to expose database errors. Now, the most basic test is to use the ' operator, which is used to quote strings, and if we include an extra one that it may break the query on the server and release some information.

We can also the ' operator to then inject our own query after it, as it may still be concatenated. Then we start to look for any columns in the database and see what's what.

What we can do after the ' operator is specify something like OR 1=1 and this will should evaluate the statement as true. But, there are some queries which pull together more than one section of our inputs (username and password) into a single query, so we may be able to add this and flunk the username, but the query - which I presume looks like this:

SELECT * FROM users WHERE username='$username' and password='$password'

what we can do then is comment out the rest of the query so the password isn't considered and we can get back the data !

Comment operators differ between databases - like mysql , sqlite etc but for this box we've been tipped that it is a sqlite database and the corresponding comment operator is --, and so we turn it into:

SELECT username,password FROM users WHERE username='' or true -- and password=''

Our input being

Username : ' or 1=1 --
Password : anything...

Let's try this out in the login panel.

If you're sitting there staring at question one wondering how you get here... just take the hint for the question as it's one of those "creative mind-expanding" questions ... tish ! If I wanted to build a custom wordlist and crack that it was actually /sa**apa*** then I would. But just mesh the two words in the question and you got it.

Sure enough the values I listed above worked and we're in

Now, we need some cookies to make successful sqlmap enumerations, so what's easiest is if we capture an example request, save it - and then use that file as input and it shall do all the work of processing it.

When we enter a query it will show up in the searchbar as:

http://10.10.21.162:8000/santapanel?search=select+*+from+gift

;; given that we input : select * from gift

The problem with using a query such as this for sqlmap to play with and replace with different payloads is that the * character is used to denote where payloads are injected, so such a query isn't optimal... Just enter something generic like

;; input : idk
;; this will then return

http://10.10.21.162:8000/santapanel?search=idk

;; this makes it simpler for sqlmap to figure out which variable will need replacing,
;; also we need to make sure that cookies are taken into consideration. Such headers are 
;; important, and it's best if we just use burp to trap the request, save the item and 
;; then reuse it.

Save the file as anything , convention is to save it as **.request but it doesn't really matter.

Turn intercept to off and it doesn't matter whether the packet is sent through or not, but now turn to sqlmap and reuse that captured packet:

Often times there will be a WAF monitoring the content for such malicious inputs like SQL injection and so we may benefit from adding --tamper=space2comment which obfuscates the input slightly.

;; sqlmap request...

sqlmap -r captured.request --tamper=space2comment --dump-all --dbms sqlite > result.txt

Searching through the results we find the "gift database" entries, it isn't a database with that table , but the database we use to hold all the gifts the children want.

All the answers to the rest of the task are in that file...

Task 6 : [Web Exploitation] Be careful with what you wish on a Christmas night

This is all about Cross Site-Scripting (XSS) , and there are a couple different types. I won't go over the intricacies of what XSS is in this task, as there is an entirely separate room specialised for this ... But I will make sure you're not lost along the way !

There are different types of XSS depending on the application, the most deadly of which is called stored/persistent XSS which is where things like comments etc will keep code entered in by the user and show it to others that want to read the stream - meaning our script would run in those sessions - so if you wanted to pull their document.cookie out and send it to your server you could.

On the website we see a comment section:

So there is one section which will query the database, and perform a GET request with some sort of querying parameter I assume, whilst we can submit our own wish ... this is the first thing I want to turn my attention to, and let's see if the following works:

So that's the stored XSS done, what about reflected - which is usually occurs in this form:

http://10.10.208.38/?q=<script>alert(1)</script>

Such a query string is present,

In future, the websites you attack will be much more sophisticated - and so you will need to fallback on some sort of automation - the OWASP Zap tool is a good choice to fulfil this need:

After the tests have completed and the streams of attempts have stopped, you will see a little reports section in the bottom left corner:

As we can see it picked up the same two alerts, this being a small site - but nevertheless handy !