Target Experience:
My observations while working this target:
· Enumeration: CTF-like /Life-like
· Vulnerabilities: CTF-like/Life-like
· Exploitation: CTF-like/Life-like
· Difficulty: Medium
· Community Notes: CTF-like
Tools:
The recommended tools for this machine were:
· Nmap
· Gobuster
· Curl
· NetCat
· linPE
Vulnerabilities:
The following vulnerabilities were found:
· Local File Inclusion (LFI)
· Misconfiguration
· Local Privilege Escalation (2x)
Information Gathering:
Using Nmap, I performed a SYN scan on all TCP ports for service version detection as well as default safe scripts.
After identifying ports 80 and 9200 as HTTP, I performed a Gobuster scan on both ports.
Web Enumeration:
Reviewing the findings from Nmap and Gobuster, I decided to launch a browser to further investigate both HTTP ports.
TCP Port 80 revealed an image and no other information useful information.
Foothold:
Reviewing the TCP Port 80 web site a little closer, I used Curl to determine if there was anything that might have been hidden on the port itself.
Still not finding anything interesting, I decided to use Curl to download the needle.jpg file for further investigation.
Not having any luck with identifying Steganography, I used Strings and revealed a Base64 encoded line at the end of the image file.
Next, I launched the Base64 application to decode the message and found the cleartext being in Spanish. Since my Spanish was not that strong, I found a web site to translate the message.
Not finding any other interesting information from TCP Port 80, I turned to reviewing TCP Port 9200; where I found that the ElasticSearch had a searching mechanism that I used to search the /quotes directory.
Not finding much with the browser search, I manually discovered that there were multiple pages contained within the /quotes directory. I stumbled across one of the pages that provided a hint that a search would need to be performed.
I started to review the ElasticSearch web site and found a manual for the product. Using their examples, I used Curl to search for all contents within the /quote* directory.
Next, I used the “key word” found, from the image obtained from TCP Port 80, to search the /quotes directory; where I found additional Base64 encoded lines.
Using the previously found Spanish translator, as well as, the Base64 application, I was able to determine that I obtained credentials to the target.
With the credentials obtained, I decided to try them against the SSH port discovered earlier with Nmap.
Awesome. Having established a foothold to the target, I then obtained the User Flag.
Local File Inclusion (LFI):
With the User Flag secured, I decided to enumerate the target locally with linPE. I came across more Spanish within the Services section.
Next, I returned to the attacker system to perform another Curl against the target to help me enumerate.
Remembering that I had discovered what appeared to be a version number, I returned to the web browser using the ElasticSearch _search function for the entire target.
Having pretty firm evidence that there was a Kibana backend server, I reviewed the ElasticSearch documentation for clues on where I could find configuration files.
Not having much luck with the loopback connection to TCP Port 5601, I performed an Internet search and found a few CVE’s that I could possibly use to exploit the application.
I eventually found a GitHub site that had a POC for CVE-2018–17246. After reviewing the information, I copied the code for the Java Shell for use on the target.
With the shell code copied to the target’s /tmp directory, and a NetCat listen launched on my attacker system, I used Curl to launch the LFI attack.
Privilege Escalation:
After the successful LFI exploit of Kibana, I still did not have root access. So, I performed additional enumeration with the newly acquired user account. I eventually found that the kibana user had Read/Write access to the /etc/logstach directory.
Continuing to enumerate the conf.d directory, I found three configuration files that looked interesting. So, I returned to the ElasticSearch manual to review what the configuration files were used for.
After identifying that the configuration files we used for filtering, I reviewed each of the files based on the ordered used by Logstash.
This took me a bit, but the input configuration file looked at the /opt/kibana directory for a logstash_* file with a wildcard. The filter then launched any wildcard file on an interval of 10 seconds.
The grok filter configuration file used regex when identifying the key word of “Ejecutar comando : <command>“ to be utilized within the logstash_ file to search and launch.
The last configuration file, of output, executed the command found within the filter.
So, tying it all together, I created an executable file of logstach_123 to launch a reverse Bash shell to my attacker system with a NetCat listener.
After identifying that I had root, I located the Root Flag.
References:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
https://www.elastic.co/guide/en/elasticsearch/reference/6.6/query-dsl-match-query.html
https://github.com/carlospolop/linPE/tree/master
https://github.com/mpgn/CVE-2018-17246
https://www.elastic.co/guide/en/logstash/current/pipeline.html
Disclaimer:
This article is made available for educational purposes only!!! In addition, this article provides general information on cyber security topics used for “Ethical Hacking”.
Persons accessing this information assume full responsibility for the use and agree to not use this content for any illegal purpose. Furthermore, the author is not liable for any direct or indirect damages or expense incurred which may result from the use of the information covered within this article.
Information within this article is “as is”, without warranty of any sort.
