Haystack - HackTheBox

Released: 29th June 2019 - Retired: 2nd November 2019

Summary: An easy difficulty machine hosted on HackTheBox requiring exploitation of the ELK stack.

Tikvah and myself worked on rooting this box together, please go check his projects out and show him some love! <3
First we head over to the web page being hosted by the box and are greeted with this image.



We downloaded the image, ran it through strings and found base64 hidden inside the file.



Decoding it using openssl we find that the message is in Spanish. We translate it using Google and get the following.




With not much else to go on from here we began enumerating the services on the box using Nmap.




Whilst port 22 and 80 are commonplace in most of these boxes, port 9200 is not typically seen open. After some research we connected to the port via our browser and discovered that the box is running Elasticsearch. The tagline 'You Know, for Search' is a hint to the next step.



After some digging around we discovered that Elasticsearch has a built in search API. After navigating to this API we are presented with various bits of data such as _id, _index, _type etc. We are also shown another service which appears to be running on the box, Kibana and it's version 6.4.2, make note of this for later.



Again we hit a wall so we decided to play around with the API a little. First we queried one of the _id numbers 44 like so '_search?q=_id:44' which revealed many more pieces of data to look through. One specifically of interest was the _index type "quotes", we again queried this using the API like so '_search?q=_index:quotes' and it returned a considerable amount of results.




We again ran out of ideas here and began digging around the web some more. Eventually we came across a tool called elasticdump and after some fiddling around trying to get it to install then some more trying to get it to run, we were able to dump all of the "quotes" data. Once we had the dump all that was left to do was find the needle in the haystack!



Think back to the base64 encoded message in the image from when we first connected to this box. 'la aguja en el pajar es "clave"' translated to 'the needle in the haystack is "key"'. So all we had to do was run the dump through cat and pipe the output into grep using clave as our keyword and voila!



Now all that's left to do is translate the Spanish to English and decode the base64 messages and we have the credentials we need to gain a foothold onto the box!




Using these credentials we login via SSH and we now have the user flag!



This is where the difficulty of the box steps up a notch. Recall before when we found that another service called Kibana was running on this box. Now we have a foothold we search for this service using whereis and take a look at it's config file 'kibana.yml', from this we are able to determine that it is running locally on port 5601.




After some more searching the web we find that this version of Kibana, 6.4.2, is vulnerable to CVE-2018-17246 a local file inclusion vulnerability which would allow us to gain a reverse shell on the application. All we need to do is tweak the shell to connect to our own IP like so.




It took some fiddling around to get this right as described in the link to the CVE, node's module caching feature will cache any filename it is passed, meaning we can't use the same file to spawn a shell twice. All we need to do is set up a netcat listener on our own machine, from the victim machine save our shell to '/tmp/' and then make a local request to our shell using curl, wait about a minute and our listener should catch that shell!



Victim machine



Attacking machine

So now we have access to the kibana user our next step is to exploit the last segment of the ELK stack which is Logstash. After finding the config files we take a look at them to find a way to escalate our privileges further. In input.conf we can see it is looking for files in the path "/opt/kibana/logstash_*" the asterisk at the end is a wildcard meaning this config file will execute all files starting with 'logstash_' in that specific directory.



The next config file filter.conf is using grok filtering to take files that have their type set to 'execute' and are then matching the message inside the file with "Ejecutar\s*comando\s*:\s+%{GREEDYDATA:comando}". The last config file output.conf merely takes the selected file and executes it as a shell command.



So all we need to do to exploit this is create our own file in /opt/kibana/, the file name needs to start with 'logstash_', containing the following format "Ejecutar comando: [our command]" to execute a command of our choosing. Like before we'll leverage netcat to catch a reverse shell like so!



Victim machine



Attacking machine

The shell may take a few minutes until it connects but once it does all that's left to do is navigate to the root directory and capture the root flag to own the box!