In today’s world, data plays a crucial role in the success of any organization, but if left unprotected, it could be a cybercriminal’s dream come true.
Poorly protected MongoDB, CouchDB, and Elasticsearch databases recently got a lot more attention from cybersecurity firms and media lately.
More than half of the known cases of massive data breaches over the past year originated from unsecured database servers that were accessible to anyone without any password.
Since the database of an organization contains its most valuable and easily exploitable data, cybercriminals have also started paying closer attention to find other insecure entry points.
Though the problems with unprotected databases are no news and are widely discussed on the Internet, I want cybersecurity community and industry experts to pay some attention to thousands of unsafe Kibana instances that are exposed on the Internet, posing a huge risk to many companies.
Kibana is an open-source analytics and visualization platform designed to work with Elasticsearch. The platform makes it easy for data analysts to quickly and easily understand complex big data streams and logs through graphic representation.
Kibana comes as a browser-based interface that has been designed to fetch data from Elasticsearch databases in real time and then perform advanced data analysis to present it in a variety of charts, tables, and maps.
Upon installation, the default settings configure Kibana to run on localhost at port 5601, but some administrators may choose to change this setting to make it remotely accessible anywhere from the Internet.
Over 26,000 Kibana Instances Found Exposed on the Internet
According to a new report shared by an IT professional who wants to remain anonymous and tweets from @InfoSecIta, there are more than 26,000 Kibana instances that are currently exposed on the Internet, and unfortunately, most of them are reportedly unprotected.
That’s because Kibana does not come with any security baked into it, like session management, though administrators can still manually configure it to use third-party plugins, like Search Guard, to enable authentication.
“Even if your server is super secured and well configured, and your Elasticsearch is bound to 127.0.0.1 or localhost, or whatever kind of loopback address, an unprotected Kibana app running on top of the elasticsearch stack can compromise your server operativity and allow unauthenticated users to access Kibana dashboard (with admin privileges), thus gifting a strong foothold in further privilege escalation attacks to malicious entities,” InfoSecIta explains.
It should also be noted that Kibana instances are not by default configured to access anything available in the Elasticsearch databases; instead, admins configure what data users can access through Kibana dashboard.
InfoSecIta told The Hacker News that he found a lot of open Kibanas instances that belong to large entities—ranging from e-learning platforms to banking systems, parking management to hospitals and universities.
“I found many Kibana instances owned by big companies. One of them is a leader in building automotive technology (such as connected cameras etc.). Its Kibana server was exposing all the data coming from every camera they sold worldwide,” he told The Hacker News in an email interview.
“Every kind of data coming from the logs/debug/status of such camera were available. I also found a Kibana stack from a big Asian stock exchange, which is still available unprotected in the wild.”
According to shodan, with a maximum number of open Kibana instances United States (8,311) is top in the list of affected countries, followed by China (7,282), Germany (1,709) and then France with 1,152 open instances.
The report also reveals that a maximum number of exposed Kibana instances are hosted on cloud services from Amazon, Alibaba, Microsoft Azure, and Google Cloud.
What’s worrisome? Out of these 26,000+ Kibana instances, a large number of servers are running outdated versions of the software that contains an arbitrary file inclusion vulnerability in its Console plugin.
The flaw allegedly allows remote attackers to execute malicious javascript code, which could potentially let attackers run arbitrary commands on the host system.
This is troubling news, and given the fact that a large number of servers don’t have any authentication in the first place, it could be a nightmare for organizations storing their important and sensitive data on those servers.
To mitigate this threat, it is recommended for organizations to secure their exposed instances with a password, while monitoring existing servers to ensure they’re not leaking any private data.
Also, last but not the least, for god’s sake, update the software to the latest version.