Update: Cybercriminals are now targeting Java-based search engine ElasticSearch in a similar way to the recent string of MongoDB ransom attacks.
The attacks were first discovered by security researcher Niall Merrigan, and the criminals appear to be going after ElasticSearch instances that are connected to the internet, either without password protection or with easy to guess passwords.
A group called P1l4tos is believed to be behind the attacks. Merrigan found that over 600 hosts have been hit by the ransomware so far, and a search on Shodan turns up tens of thousands of ElasticSearch servers that are available online.
Like the MongoDB attacks, cybercriminals went after Elastic users who had not secured their data stores. As one user points out on the Elastic forums, in their instance the open cluster was used exclusively for test environments – much like the open MongoDB databases will have been. But there could be some organisations storing critical data on Elastic.
Security researcher and blogger Itamar Syn-Hershko has put together this post with advice on securing ElasticSearch. In it, he stresses the importance of hiding clusters deep in private networks and accessible only to your applications, along with disabling unused features and switching from default ports.
Alienvault's Javvad Malik says the attack "highlights the disconnect between many developers from good security practices."
“Like MongoDB, the ElasticSearch attacks are not so much about the technologies themselves, but in the way people have implemented them using either default configurations or weak passwords," Malik says.
Ransomware groups have now launched attacks on more than 30,000 MongoDB databases, demanding just under £200 in Bitcoin to regain access.
The first instances were uncovered by GDI Foundation's Victor Gevers in late December, but now multiple groups are thought to be involved.
Reports so far say that the attacker erases a database and demands the ransom before restoring it – so far 16 victims are believed to have paid up. Generally the advice with ransomware is not to pay unless absolutely necessary, as it's possible that even after coughing up the cash there's no guarantee that files will be restored.
Infosec researcher Victor Gevers found an open MongoDB server in December last year, without password protection. Its text read:
"_id" : ObjectId("5859a0370b8e49f123fcc7da"),
"mail" : "[email protected]",
"note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"
The attacks were by someone going by the name of Harak1r1 who demanded a relatively small Bitcoin payment to swap the original database back in – but there's now a growing list of copycat attacks from different aliases, recorded in this Google Doc.
As security researcher Tim Kadlec notes, versions of MongoDB running before 2.6.0 accept remote connections without authentication and with a default port of 27017, making it easy to sniff out vulnerable connections using search engines such as ZoomEye.
There's a long checklist of security configuration advice plus tips on access control, data protection and encryption at the MongoDB website, so the attacks are not reflective of security flaws in MongoDB per se, but rather the decision to allow unauthenticated remote connections by default. It could also be lax security culture in the testing environments where MongoDB is often used - and where many platforms are run in their out-of-the-box flavours.
"It appears the victims of the MongoDB ransomware were running default configuration, which allowed attackers to gain access," says Javvad Malik, security advocate at AlienVault. "If businesses are running MongoDB, they should ensure it is not running in default mode and that the security features are taken care of."
There are plenty of high-profile businesses that use MongoDB, so it is a little alarming that so many of these databases were running on default settings with open ports – something noted by the founder of internet of things search engine Shodan in December 2015. A search on Shodan for MongoDB databases shows that 99,000 databases could be at risk of attack.
In a blog post, director of product security for MongoDB Andreas Nilsson writes that the attacks are "preventable" with the "extensive security protections" that are built into the product.
"You need to use these features correctly, and our security documentation will help you do so," Nilsson writes. Nilsson goes on to list some suggested steps users can take to check if their data has been compromised.
While it's recommended that MongoDB users secure their databases, according to Jonathan Sander, VP of product strategy at security company Lieberman Software, the actual risk behind these attacks is likely to be relatively low.
"The real risk of this MongoDB ransomware is probably pretty small," Sander says. "If you look at the way people are using MongoDB right now, a great deal of it is in experimental phases – so there might actually be valuable data sitting in the MongoDB, but it won't be the only copy of the data."
"At least in enterprises that would have data anyone might pay for, what that tells me is that this ransomware is not going to get paid off – the whole point of the ransomware is they have leverage over you and you need it back," he explains. "With MondoDB, it's not likely you need that data back, at least not from that database. It's probably somewhere else. You can probably delete the entire virtual machine MongoDB sits on and forgets about it, which is annoying but not worth paying for."
Sander does add that there will be exceptions. He notes that the mode of attack is puzzling from a business-case point of view – adding that the "better attack" might be to gain access to the "weak, soft underbelly in these labs, sitting there with all this information where the information might have some value."
The value in obtaining this information wouldn't be in holding it to ransom, but to enrich the "big data sheet of stolen credentials and stolen information – that would be the thing I'd have thought they would attack."
"They are not siphoning off the information, but it is a standard ransomware attack where they don't steal the information, they just lock it up where it lives," Sander says.
It's unlikely that the attacks are a red herring to gain access to data, agrees Jason Garbis, VP of products for Cryptzone.
"If an attacker just wanted to access the data there'd be no reason for them to advertise the fact that it had been stolen," he tells Computerworld UK. "These criminals aren't threatening to release the data – this looks like a disorganised group of attackers simply looking to extract some ransom money."
"In fact, according to the security researchers tracking this, the few people who have paid the ransom have not had their data back," Garbis adds. "On top of this, we're seeing multiple attackers step on each other's ransom notes. This entire situation is a dog's breakfast."