Advent of Cyber - Special boxes

Advent of Cyber - Special boxes

This will cover the walkthroughs of the boxes which teach specific concepts , like Kernel exploitation, Server-Side Request Forgery and OSINT.

Task 19 : [Special] The Naughty or Nice list

We've often heard about cross-site request forgery, which is where we the attacker will craft a URL that targets the user - exploiting how the user server isn't very good at authorising certain requests. The most traditional XSRF is where we leverage a direct-object reference vulnerability:

http://somesite.co.uk/?account-id=110

;; now this is fine if the server checks other things like cookies and other data
;; to pin down that the person who sent id=110 over the wire can only be that user.

;; if we allowed say
http://somesite.co.uk/?account-id=0
;; then that would mean we may be able to see the admin account - as traditionally 
;; they always get made first to administer fixes, pages etc.

;; a XSRF vulnerability then could leverage this and send a links to other users with 
;; their id and get them to perform certain requests or actions...

Where the SSRF differs, is that we are primarily attacking the server - we are making the server itself the target of its poor handling - when we craft a request we seek to exfiltrate data out, redirect data channels, possibly layer in a stored or reflected XSS attack with the URL: whatever we are given to play around with we must compromise.

Back to the box now, we can see the following website allows people to check whether or not they are on the list:

list-site

We can see that I inputted Grinch and surprisingly it had us on the nice list... Oh well, it seems to be kind to all I guess - but what's more intriguing is the odd looking URL that gets generated in the search bar, let's inspect it but this time with burp.

captured-query

Checking the source code for the site to find where this generation happens:

where-is-this-req-going

Let's think about what's going on for a moment. Checking burp we saw that this is a GET request submission to the backend webserver - with an added query that contains the proxy server , of which the backend will send something to I presume. Looking at the proxy server itself, it seems to be where the backend will ask whether or not someone is on the list - the backend server of course has to authenticate itself - but regardless , we need to have that redirect to our machine to see what's going on !

After loading my own server instead of the list.hohoho domain we get errors,

localhost-was-banned

Just replacing the proxy for localhost gave us errors. What the backend server does is it checks that the domain for the proxy variable is including the list.hohoho domain within it, but when we do nslookup for such a domain:

nslookup-failed

Hmm , that's strange it doesn't actually exist - which means it is most likely residing on a private network... No matter , as what we can do is insert a domain which resolves the entire URL - list.hohoho and all to 127.0.0.1 , but how do we do that ? The room throws us a bone at this point, and tells us that the subdomain localtest.me resolves to 127.0.0.1 and when attached to other domains it still acts to resolve the localhost:

localtest

Now we can see that this works and data should be coming our way,

requested-url-was-not-found

Or not, all I did was insert that subdomain in and remove the port number ... but it seems I have yet more to fiddle with this URL - maybe if I just remove the querying parameters? Remember, what we're doing now is trying to get the backend server to give us - not the output of the proxy server it would've redirected to , but it will output whatever is returned from that IP address, which is their local localhost. Keeping it simple with

http://list.hohoho.localtest.me

Gives us the gold

there-is-the-password

This localhost panel is what we were hoping for, and we see the password for Admin (Santa) - include the "!".

nearing-the-end

And there you have it - click the button and you shall be done.

Task 24 : [Special] The trial before Christmas

This is the last task of the series ! So it will be combining a lot of the skills we have learnt over the last month - if you need help make sure to check out my other articles on the series - denoted by their tags Advent of Cyber and then *subject*

As we're going back through all the topics we get to use nmap again!

nmap-scan

And let's head on over - but whilst we do the manual checks we should have gobuster run in the background...

There wasn't much to the first website , but the second one is more interesting:

light-cycle

With gobuster also showing more results

gobuster-results

We're supposed to be looking for a hidden .php file - but after gobuster was only finding index.php I tried guessing , as the file in question is probably somewhere we are going to upload our shell to - as noted by subsequent questions. I found uploads.php only through guessing...

When we want to upload an image the server will load the uploads.php file alongside other .js files which contain the filtering code for checking. To grab these files, as burp actually doesn't by default we need to disable the option which stops us from viewing them:

remove-so-we-get-back-js-files

Removing that means we have the option to see the files coming in, and when that uploads file comes in we need to drop it ! If you don't catch them then the scripts are cached for that site - so I just reload the box - but removing the cookie might work I now realise ...

Now when we make a request to /uploads.php we can see the GET requests for filter.js etc. Don't drop uploads.js otherwise there won't be the functionality to upload a file in the first place. We can check the file was uploaded by going to /grid and seeing the shell

shell-upload-success

And with our nc listener we can spawn a little shell - from here we will want to use

python3 -c 'import pty; pty.spawn("/bin/bash")'

The reasoning is because this will take us out of a shell and into a terminal session, the difference being laid out clearly in this article. Now that we have a session which has some of the functions of a local session we can set things like environment variables - notably export TERM=xterm to allow us to use clear. Last but not least we need to make sure that our own operating system which sends input over isn't our own autocompleted sequence as the tools on one computer may send a garbled message over the line - so we need to CTRL+z to pause the shell, then back in our own terminal we use stty raw -echo; fg. This does two things: first, it turns off our own terminal echo (which gives us access to tab autocompletes, the arrow keys, and Ctrl + C to kill processes). It then foregrounds the shell, thus completing the process.

This brings the shell back and after a bit of snooping we find some credentials.

snooping

Let's connect locally :

entered-mysql

And we find a user hash we can pass to crackstation

well-hello-flynn

password-found

The room tells us we will be using this password to be logging into this user on the machine - a thing only possible because we migrated to a terminal session that includes the local variables and commands on the system - one of them being su.

Now that we're inside the flynn account we would traditionally try to have a look, copy over linpeas.sh or something - but we have a very specific goal in mind with this box and that is to exploit the lxd group that flynn happens to be in:

lxd-group

LXC is essentially software for Linux that lets us spin up containers, much like Docker but with the Linux kernel as that which applications will sit atop of and use those low-level utilities for things like networking etc. When we are part of this group , especially with the permissions we have, we can spin up containers which have root level privileges even though we don't - then this container can begin to sniff around and we purposefully let it break free of the VM jail to look in /root for example. All we need to do is configure that image, get it onto the victim and run it

image-list

Looking at the list of containers already present we can mess around with alpine and load it onto the device of our choosing, this is equivalent to mounting it.

My device name : christmas
My container name : santa 

;; need to run
lxc init Alpine christmas -c security.privileged=true
lxc config device add christmas santa disk source=/ path=/mnt/root recursive=true  

finished

And now that it's up and running I wish you a very merry Christmas , for that is all ! Take care.