IT departments using the open source Elasticsearch search engine for in-house combing of log and other data are being warned of a ransomware campaign that appears to be orchestrated by groups aligned with the recent MongoDB attacks. The problem is poor security: Elasticsearch clusters that are left open to the Internet for no good reason.
There are reports that at least 600 hosts have been hit so far with ransomware demands. One problem is many Elasticsearch users put their clusters in the cloud.
“Whatever you do, never expose your cluster nodes to the Web,” warns search technology specialist Itamar Syn-Hershko. “This sounds obvious, but evidently this isn’t done by all. Your cluster should never-ever be exposed to the public web.”
A distributed, JSON-based search and analytics engine, Elasticsearch is said by its developers to be designed for horizontal scalability, reliability, and easy management. In the hands of an infosec pro, it can be useful for combing through reams of security logs. Analysts for sales and marketing staff like it because it can combine many types of searches — structured, unstructured, geo, metric.
As Syn-Hersko notes, Elasticsearch can be told what IPs to listen to: localhost, private IPs, public IPs or any combination. But, he repeats, “There is no reason in the world to set Elasticsearch to listen to a public IP or a publicly accessible DNS name.” The network.bind_host or network.host setting should always be set to a private IP only (or localhost too in some exceptions).
A very common mistake, he adds, are admins who reason that because Elasticsearch is REST over HTTP it can be accessed directly from smart HTML clients. Instead, he says querries should be passed through a software façade that can do request filtering and audit-logging. Don’t forget to password-protect your data, he adds.
Even within a corporate network, isolate clusters from other parts of your system as much as possible. For clients deploying their clusters on Amazon AWS for example, Syn Hersko recommends putting the cluster in a VPC (virtual private cloud), and then having two separate security groups – one for the whole cluster, and one for the client nodes that is then shared only with applications requiring access to this cluster.
Only client nodes should have HTTP enabled, he adds, and applications within your private networks should be the only ones with access to them.
Security researcher Victor Gervers of the Dutch non-profit GDI Foundation said in an email that like the MongoDB problem this is another case poor default product security. The default installation for Elasticsearch binds to localhost, allowing any unauthenticated user to send arbitrary requests to an Elasticsearch cluster as a super user. “Destroying an entire Elasticsearch takes merely seconds and can be done by command line or web browser,” he wrote.
An Internet search shows world-wide there are 34,418 Elasticsearch Internet facing instances, of which 16,280 are doing jobs such as data collection and log parsing (with Logstash) that could be used for network monitoring and other NOC/SOC activities, he said.