Yesterday I posted about manipulating group membership to get access to a SQL Server. Today comes attack vector #2: stealing an account. And when I mean stealing an account, it could be any account. It doesn't have to be a DBA's account. For instance, if I know a particular end user has to ability to see the data, better yet, to issue SELECT statements so they can manipulate the data in an application like Excel, that will do. Actually, the less privileged users are typically a better choice for account theft. Why? Because those users tend to be less technically savvy (not always, but in general) and they make easier prey. Let me explain.
Because I have always held admin rights throughout my career, I keep track of my passwords, even when I go away on vacation. As a matter of fact, I tend to try and reset my passwords well before any vacation time so that I'll have used them enough to where I remember them well. Nothing like being out for a week after having just changed a password to put you in a situation where you can't remember your password and have to have it reset. As a security person, I realize I am paranoid for stuff like this and I'm not the normal user.
Most normal users would think nothing of having to reset their password after a week or two away because they forgot their passwords. Therefore, these folks make the ideal targets for an admin trying to steal an account. So here's how the attack goes down:
- User goes on vacation and the bad admin knows about it.
- Bad admin issues a password rest for the user's account.
- Bad admin logs in as user.
- Bad admin steals data.
What can make this especially troublesome is the bad admin probably has the ability to see when a password was last changed. So if you can pick on a user who has just changed a password, it is all the more likely that the user will assume he or she just forgot it. And by the way, with some users you don't have to wait until vacation. These are especially the "computers hate me" type users. They don't understand they their account password shouldn't have changed and computers don't do things like that and just ask that the password be reset without nary a thought. If you've ever worked workstation support or computer helpdesk, you know there are plenty of these types of users out there.
How do you protect against this? I'm going to drop back and say, "Audit for it." The event in Windows XP and Server 2003 (and 2003 AD) is event ID 628. This is different when a user changes his or her own password, which is event ID 627. For Windows Vista and higher (and 2008 AD) the event ID is 4724. The one catch is if you have a situation where you've got some sort of self service password change system. Then you'll need to filter out any changes made by the service account corresponding to that system. But otherwise, you look at event 628 or 4724 and you report on who the caller is. This is the easiest way to see if someone has the permissions to do something but doesn't the have appropriate authority from the organization's perspective or if that person is abusing those permissions/authority.
