Post navigation

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.

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.