Shulou(Shulou.com)05/31 Report--

How to analyze the vulnerabilities contained in the local file of Elasticsearch core plug-in Kibana. In view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Not long ago, Elasticsearch issued the latest security announcement, the Console plug-in in the previous version of Elasticsearch Kibana6.4.3 and the previous version of 5.6.13 has serious local file containing vulnerabilities that can lead to denial of service attacks, arbitrary file read attacks, and cooperate with third-party application rebound SHELL attacks. The following article analyzes and reproduces the vulnerability background, attack principles and behavior.

I. scope of influence

Elasticsearch Kibana is a set of open source, browser-based analysis and search Elasticsearch dashboard tools from Elasticsearch in the Netherlands. As the core component of Elasticsearch, Kibana can be provided as a product or service, and can be used with a variety of systems, products, websites and other Elastic Stack products in the enterprise. As Kibana is widely used in big data's field, the impact of this vulnerability is large. The Shodan search results are shown in the figure.

Second, vulnerability scenario

The author chooses the Kibana-6.1.1-linux-x86_64.tar.gz version, the construction process is not shown, and there are many references on the Internet.

2.1. Denial of service

The author chooses / cli_plugin/index.js to demonstrate the denial of service, and the attack vector is as follows

After the GET request is sent, the client cannot open the application page. The Kibana process on the server exits, and the application service dies. See the figure below.

2.2. Arbitrary file reading

The author chooses / etc/passwd to demonstrate when reading the file, and the attack vector is as follows

After the GET request is sent, the client page will throw 500 errors, and the server will throw the read passwd content, as shown in the following figure.

2.3. Cooperate with third-party applications

Usually, Kibana is deployed with other applications. If the application can upload or write to a Javascript file, an attacker can create a Reverse Shell through Nodejs, as follows

Path traversal allows an attacker to access the location of any file on the Kibana server, as follows

Nc bounce listens for interactive sessions

Third, loophole analysis

The vulnerability contamination point is located in\ src\ core_plugins\ console\ api_server\ server.js

The value obtained by Apis is passed to the assignment parameter name. You can also see from the figure that the contents of the name variable are introduced into require without any filtering. While the require module represents the way to load the module in Nodejs, you can load the core module, such as the built-in "http". It can also contain a file or directory named "index.js". If the parameter starts with "/", ". /", ".. /", then the function knows that the module is a file or folder and continues to follow up to the api.js file where the function asJson is located.

There is an exported instance of this class in ES_5_0.js in the same directory.

To sum up, the normal process of this function is to obtain the name of the JavaScript file that exports the API class instance and call the function asJson, but ignores the filter verification, so we can specify any file. With directory jump traversal, we can read any file on the Kibana server. Based on the above analysis, it is clear that Nodejs applications require a large number of files. If these files contain process.exit instructions, it is possible to shut down the Kibana process and cause a denial of service attack. Three possible attack vectors are found through search.

LFI usually appears in PHP applications. It is common that require applications are used in Nodejs programs this time. It is believed that more Nodejs programs will have this problem in the future, because local inclusion vulnerabilities have appeared for many years, but there are still many software developers and architects who do not take this into account. This article well illustrates a key LFI vulnerability in Kibana, allowing attackers to run native code on the server. The direct harm is the denial of service attack. If the business can not afford to be hurt in the production environment, we need to pay more attention to Nodejs LFI.

This is the answer to the question on how to analyze the vulnerabilities in the local file of Elasticsearch core plug-in Kibana. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.