Any sensible IT system isn’t going to store passwords in clear text, nor will it transfer them over a network in any fashion that makes eavesdropping feasible. Yet some days I get a nice list of user passwords emailed to me, a list created without the need for keyloggers, social engineering or psychic powers. The list is created by my own users, aided and abetted by the system that’s designed to protect their passwords, not leak them. Let’s see how the password goes on its journey from the user’s brain to my inbox.
It’s Monday morning, and Joe.User hasn’t had his coffee. He sits at his keyboard and tries to get the day started:
CTRL-ALT-DELETE… joe.user… jo3i5l33t… <return> … damn, failed login… try again… joe.user… <tab> jo3i5l33t… <return> …ah, I’m in!
The failed login was due to Joe missing <tab> the first time around – the focus didn’t move from the username field to the password field, so he tried to login as a user called “joe.userjo3i5l33t” with no password.
That’s not so bad, is it? Well, depending on how hard you’re listening to your network and your level of vigilance to detail, Joe’s password is well on its way to publication:
- Depending on the audit policy in use, Joe’s login failure as “joe.userjo3i5l33t” will leave an impression in the event log of the local machine, and also the domain controller that processed the request. The log impression will contain the composite of Joe’s username and password because that was what he typed into the username field.
- In my specific case, the domain controller’s logs are harvested at five-minute intervals into a security event correlator wotsit (a Cisco CS-MARS, in this case). Joe’s password takes another step closer to me.
- Every day, the MARS emails a report of failed logins to me, primarily so I can spot (albeit retrospectively) things like brute-force login attempts. Most of the time the report lists innocent login failures, but today I have a bonus – Joe’s username+password combo.
So now I serendipitously know Joe’s password, thanks to the written record that now exists in several places (Joe’s machine, the domain controller, the MARS and my inbox).
There are other flavours of this leak:
- Sometimes a user will omit their username altogether and enter their password in the username field. The login will fail, leaving the password in a log entry. It’s quite simple to determine the username that owns the password – the chances are, the next valid login to the same workstation will be from the user in question.
- If there is a KVM switch in use, sometimes the user uses their credentials for system A when the KVM is actually showing them system B. System B’s administrators now have a valid login to system A.
So, only our diligent security admins are seeing this, right? They’re the ones who read these reports, and they’re the guys we trust, right?
- Server administrators will be able to see the contents of their own eventlogs.
- If emails are stored centrally for a period of time in line with corporate policy, the email administrators can potentially find this information.
- The screen-scraping/email-copying malware on my PC might be sending this stuff to who-knows-where.
The point is that the scope of Joe’s password leak is potentially quite large (and may even extend outside the bounds of our own enterprise). The consequences of the leak will of course depend on who sees the information and what they do with it.
A diligent, trustworthy admin will force Joe to change his password at the earliest opportunity, rendering the leak moot. An evil admin will just use Joe’s password, given that Joe is the CEO and all. Perhaps I’d like to read his emails, or open that document called salaries.xls? Hmm, I wonder if Joe habitually re-uses passwords in other places? Does he have a GMail account? Or eBay? Amazon? I’ll be back in a tick, I’ve got some shopping to do…
Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk