Shodan and passwords sitting in a tree, S-H-O-W-I-N-G!

If an application offers authentication security, it’s always a good idea to turn it on if on isn’t the default setting.

Too often, however, this cardinal rule is ignored or overlooked. The latest example of this has been discovered by researcher Giovanni Collazo, who decided to take a closer look at the etcd (“et-cee-dee”) clustering credential distribution store popular in Kubernetes datacentres.

What he uncovered with almost no effort is a security void with large numbers of etcd servers exposing a range of sensitive credentials to anyone with the nous to run a search on Shodan.

All told, Collazo reports finding 2,284 etcd servers reachable on the internet, which he queried using a simple script designed to see what he could shake down.

When he stopped the query at 750MB of collected data, he’d gathered credentials from 1,485 of these servers, including 8,781 passwords, 650 Amazon AWS access keys, and 23 unidentified secret and 8 private API/certificate keys.

Collazo observed:

I did not test any of the credentials but if I had to guess I would guess that at least a few of them should work and this is the scary part.

Anyone with just a few minutes to spare could end up with a list of hundreds of database credentials which can be used to steal data or perform a ransomware attacks. [sic]

Which is ironic because what piqued his curiosity in the first place was the similarity of etcd in its default state to the weakness that led to the January 2017 ransom attack on 27,000 MongoDB database servers.

As with MongodDB at that time, etcd’s authentication is not turned on by default, a consequence of needing to maintain backwards compatibility with older versions that were completely open.

Bad Packets researcher Troy Mursch confirmed Collazo’s discovery, publishing a MySQL password he was able to retrieve during a separate test. (The password was “1234.”)

Collazo recommends that Kubernetes/etcd admins who haven’t done so already should read up on its authentication settings as soon as possible.

It would also be a good idea, where possible, to remove servers from open internet access, he said.

Perhaps there’s an assumption that nobody would be interested in this relatively obscure but important infrastructure, or if they were, that they wouldn’t find it easy to target specific vulnerable servers.

This idea needs to be put out to grass. If a server is unsecured, it is a near certainty that someone will come for it eventually.

Anyone who uses etcd should double check its security settings before they receive a visit.