Reading Kibana

In the meantime I decided to check one of the webapp we can find during internal infrastructure pentests - Kibana. Below you will find the details.
Sometimes during the pentests we can find some hosts with not-so-usual ports open. Today I decided to prepare a lab for the case like this and that how I installed Kibana with environment based on Ubuntu 18 (64bit).

To prepare such (basic) 'lab' you'll need:
- Ubuntu 18 ISO
- VirtualBox
- Kibana 7.x

As you will see later, during the installation we will find what needs to be done/installed (as well) but for now it should be our 'core' installation. ;) So, here we go:

After your Ubuntu 18 is ready, open console to install few packages:

root@u18:~# # apt-get install kibana elasticsearch vim openssh-server -y

(I added vim and openssh-server because - in 'my lab' - in most of time I'm using some various clients like putty or winscp (or TotalCommander ;)) so it's easier to switch between the windows... anyway)



Now you should install OpenJDK, mine was:


root@u18:~# java --version
openjdk 11.0.3 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Ubuntu-1ubuntu218.10.1)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Ubuntu-1ubuntu218.10.1, mixed mode, sharing)
root@u18:~#

Now you should be ready to visit your http://localhost:5601 to manage your fresh installation of Kibana... but no:

Sometimes I just need to read something multiple times to understand the message between the lines:

root@u18:~# apt-get install elasticsearch -y





Yes I know, brilliant. :] But this is happen very often if you do not RTFM. ;D

Now - if you still want to run your Kibana 'remotely' - go to /etc/kibana/kibana.yml:

# vim /etc/kibana/kibana.yml
(...)

As you can see (line 7) you can find there (commented) server.host variable. I added my own line below (with IP "in the same DMZ/LAN").



After a while (and few more VM restarts ;)) Kibana should be ready to visit and use:

 
Let's back to the 'pentest part'.

TL;DR - ports we'll found open during infrastructure scan (with "sample installation/box" configured like that) should be:

- 9200/tcp open -- ElasticSearch - explained here
- 9300/tcp open -- ElasticSearch - explained here as well
- 5601/tcp open -- Kibana webapp

"Big mistake" (or misconfiguration, you name it) you can find during the test(s) is of course no authorization at all[1, 2, 3] for the service you'll find open.

Very basic check for found port 9200 open can be done using curl:

 
I was looking for some other/already created CLI tools/scripts ...

...and this is how I found curator [1, 2 , 3] (nice name for a tool btw! ;D) 

Checking - "version not compatible"... Checking again:

 

Compatible version:

Now (according to the Vendor's pages):

Ok, cool. Let's change filters:

Good. Now you should be able to identify ElasticSearch installation on remote host during pentest and run some basic queries using tools available online.

If we will back to (our latest) Kibana installation we can easily find that there is a Console available:

When I was playing a bit with the tutorials I found some interesting request in Console's communication:

 
Checking:

Very cool :) 

Original http://-address was located at Vendor's page but I decided to change it and redirect this request to my Ubuntu VM (Kibana server):

At this stage I was wondering if I can redirect this request to some other server/location:

Sure, why not.

(I hope that those Shodan/ZoomEye results are fake... :| )


See you next time.

Cheers