Hacking ELK: A Guide

ElasticSearch was created nearly ten years ago and they have since built a fantastic analytics, SEIM, and logging solution that we use here at LARG*net. The Elastic company is listed on the stock exchange with a valuation of around 5 billion USD$ so they must be doing a few things right. An ELK server is so named due to the combination of services it runs: ElasticSearch, LogStash, and Kibana. ElasticSearch is the search and analytics engine, Logstash is the server-side data processing pipeline, and Kibana is the GUI you use to interact with your data.

Chances are you can name a few companies that run an ELK server so the ability to hack one is attractive. First thing we do is get permission! With that in hand, we have to figure out how to access the server and discover ElasticSearch is but Kibana is not. This is rather unusual given Kibana is the front-end so is usually accessible while ElasticSearch doesn’t need to be and usually isn’t.

This is the nmap results after a scan. TCP port 9200 is reporting as Nginx a webserver. Going to this page reveals it to be an ElasticSearch backend.

22/tcp open ssh OpenSSH 7.4 (protocol 2.0)

| ssh-hostkey:

| 2048 2a:8d:e2:92:8b:14:b6:3f:e4:2f:3a:47:43:23:8b:2b (RSA)

9200/tcp open http nginx 1.12.2

With ElasticSearch accessible I can query it’s data so I ran a query GET _all/_search?pretty=true&size=500000 and pulled a significant amount of content out of the database. From here I turn my attention to finding any usernames and passwords in the datadump. I’m hoping to get lucky with a plaintext password. I find these logs that appear to show the service account user and password accidentally typing their password instead of their username:

sshd[60660]: Denied password for P@ssw0rd from 127.44.27.1 port 22 ssh2

sshd[60660]: Accepted password for elasticsearch from 127.44.27.1 port 22 ssh2

I try this combination at the login prompt and get SSH access. This is an extremely limited service account, so I run a Linux Privilege Escalation Enumeration script.

The problem is this ssh user is tremendously unprivileged so I can’t do anything. Remembering Kibana was inaccessible when it normally is available, I decide to investigate why. A quick check with the command SS reveals it’s definitely running on the machine:

ssh elasticsearch@10.10.10.115 -L 5601:127.0.0.1:5601

When I go to port 5601 (the default Kibana port) on my machine, SSH forwards it to the Kibana port on the target machine. Since a firewall is blocking Kibana externally; I connect to it through ssh pretending to be the server instead.

Not only is the Kibana instance not configured but it’s an older version. A quick search for version 6.4.2 reveals a few exploits I can try to further my access.

I decide to give CVE-2018-17246 a try using this exploit on GitHub. I follow their steps exactly: first creating a shell.js with my unprivileged user and then using Burp Suite to craft my exploit by literally copying and pasting the rest. I find myself with another very limited shell but at least I’m the Kibana user now:

I ran LinEnum against this user and discover I can execute a file as root which gave me a root shell. Now that I’m root it’s game over for this machine.

This is root’s hash if you want to try to crack a sha512crypt hash. I wasn’t able to crack it so let me know if you have better luck!

$6$/gcnv5Evs/VUMis1$3tBvFBAKoQ1ia.q4holEgSbS09XFIIJx7Iv8WHpqf2Jag3BBeoIS8qd3raGB1YM0MlL9lVpZYqndoRf5UdRuE.