Writing

Feed Software, technology, sysadmin war stories, and more.

Saturday, May 19, 2012

Non-durable passwords done the wrong way

Imagine a situation where you have thousands of machines leased by different customers and hundreds of techs who might potentially need access to them. Your existing scheme is to provision machines with 3 known accounts, each with a different password: root, one for the customer, and one for technicians.

When a tech needs to log in, they just pull up that machine, then load the password page, and copy/paste that password into their ssh session. They get on the machine, run su, copy/paste the second password in, and now they're root and can start doing stuff.

Not too surprisingly, some people started seeing places where this could get really nasty. Any one person with access to this provisioning system could go in and write a quick scraper to snag login and password data for a bunch of machines. Then they'd be able to exploit them from anywhere in the world, since most of these systems were not behind firewalls (hardware or otherwise), and even then, hardly anyone restricted ssh access by IP.

When I heard about this, I came up with a half-baked idea of my own, and I wrote about that last year.

The story I haven't told yet is what I was hearing certain other people propose. They wanted to solve it with "non-durable passwords". In this environment, a tech would authenticate to some system and then would somehow convey that they wanted to connect to a customer's machine. The backend would then create an appropriately privileged account for them with a temporary password. Then they would use that to log in.

Nowhere in here did they specify authorization scope, like saying a given login would only work on one machine. Instead, they were talking about it more like a huge NIS+ environment, where one username and password works anywhere. These accounts would be created "just in time" and then would be deleted some time later, so snagging a bunch of login data wouldn't do you much good.

I got the distinct impression that they hadn't considered the possibility of replay attacks. All it would take was a single customer machine running a rogue sshd which captured the details of an incoming login. Then it could just turn right back around and use that against other customer machines and establish a foothold on as many as possible.

At this point I had a conundrum. Do I bring this up and hope someone will take me seriously? Or do I just stay quiet and let it happen, all the while arranging my own evil ssh daemon to take advantage of it?

I wound up moving my hosting out of there before they ever made a decision on that stuff. I sometimes wonder what they wound up doing about it, if anything, and if there are lovely gaping holes by design or not.