"This one's caused by people clicking through the hard parts of Elasticsearch configuration"
Nope, it's caused by insecure default configuration and/or allowing someone to click through something that needs setting.
Lazily-configured software has again created a security incident, this time resulting in 4,000 instances of open source analytics and search tool Elasticsearch inadvertently running PoS-stealing malware. Kromtech's Bob Diachenko writes those servers are just 27 per cent of a total of 15,000 ill-secured Elasticsearch nodes the …
Yeah, funny how the when the great devil incarnate Micro$oft was guilty of punting server software like this they were pilloried back an forth for crimes against humanity, but now it's a modern trendy tech firm it's suddenly the customer's fault.
Although reading between the lines, isn't it Amazon who've cocked up with their wizard, not ES?
Both this article and the Kromtech post are missing something critical. It sounds like they're talking about Amazon's managed Elasticsearch Service offering, where you point and click (or not) through the console to have a cluster set up for you. But that service doesn't give you host access and it doesn't even let you install ES plugins of your choice, even if you are enough of a muppet to not configure any security.
The worst a dumb customer should be able to do is leave all their data exposed for the stealing and/or deleting. But Kromtech claim "the lack of authentication allowed the installation of malware on the ElasticSearch servers." If those managed ES versions can be remotely compromised through their REST APIs, wouldn't that be a fairly obvious thing for a provider to have patched?
If on the other hand we're talking customer-built (unmanaged) ES clusters, then the majority of the article is misleading if not downright wrong.
"The worst a dumb customer should be able to do is leave all their data exposed for the stealing and/or deleting."
A customer shouldn't even be able to do that. You need to think again about the "their" in "their data". The data may be about customers, employees etc. You and I may be included in the "they". "Their data" may mean "our data" and nobody should be able to leave that exposed.
"Their data" may mean "our data" and nobody should be able to leave that exposed.
I completely agree - by "should be able to" I meant "with the current implementation as I understand it, the worst I expect to be possible is that..." rather than "it's acceptable for an incompetent admin to be able to..." Upvoted both for the principle expressed and for catching my sloppy wording.
Yes, I was also confused. You shouldn't be able to get remote code execution from an unsecured ES instance. If so, it needs to be patched - maybe the 2 versions mentioned are ones that have a vulnerability, but that also sounds weird - why would AWS lock you in to a vulnerable version of a piece of software?
When I tried out a mongoDB and ES, working through the getting started guide and seeing the "we don't provide HTTP authentication, thats not our job, put as behind a reverse proxy" My immediate thought was that at some point, someone is going to scan for all unsecured instances and steal a lot of data. Why didn't mongoDB or ES see that coming?! If they used the "do one thing and do it well" philosophy to decide not to include authentication, their definition of "one thing" is not big enough. Storing data is part of the job, another part is making sure nobody can steal it.
ES let you install their software for free to have a play with, on your own servers or in the cloud. Its cheaper to let people have their own VM these days than to setup a "demo site".
I'd be surprised if demo instances have real data on them.
I wonder how many pwd VMs were setup by the botnet owners themselves? Someone "giving away free VMs" is always going to be a target.
Biting the hand that feeds IT © 1998–2019