Security

Understanding Shared Account Password Management

Chris Stoneff

At a Glance:

• Shared and privileged account password risks
• How passwords are stored
• Managing and securingshared passwords
• Being compliant

Contents

Understanding the Problem
The Longer, the Better
Domain Violence
Excuses, Excuses, Excuses
What the Regulators Want
An Automated Approach
Think about It

One of the common things that administrators must deal with on an ever-increasing basis is the regular changing of the password for shared and privileged accounts, such as the built-in

administrator or root account, a firecall account, or perhaps even a process account. For the sake of definition, the built-in administrator or root account is the account that comes on every version of Windows®, Linux, and UNIX, and it always has the same Security Identifier (SID) or User Identifier (UID). Firecall accounts are those other accounts you create to help facilitate emergency access to a secure system. These firecall or administrator accounts are sometimes used by otherwise unprivileged users to gain access to key systems when problems arise. Finally, process accounts are the accounts you use to run services, tasks, COM+ applications, and embedded items, such as scripts and other binary files that must log in.

Now, you likely deployed your systems using install scripts or images. In addition, all your workstations or servers probably have the same administrator account name and the same 8-character password that more than likely has not been changed since the systems were originally deployed. For this reason, I use the singular term "password," as opposed to "passwords."

An administrator might be compelled to change these passwords as a matter of using best practices or meeting compliance requirements, such as those mandated by Sarbanes-Oxley (SOX), Payment Card Industry (PCI), or the Health Insurance Portability and Accountability Act (HIPAA). Sometimes an administrator is motivated when an ex-administrator or technician with knowledge of these passwords leaves the company, for fear of a publicized security breach or losing the ability to process credit cards. Despite these factors, it really comes down to the administrator having to change these passwords for the simple security of the company and the data the company is required to protect.

Understanding the Problem

There are a few factors that must be understood when you are dealing with these accounts and their passwords:

1. The older a password becomes, the less secure the password becomes.
2. Longer passwords are, as a general rule, harder to crack.
3. How computers authenticate doesn't change just because they belong to a domain. In every domain lies the heart of a workgroup.

"The older a password becomes, the less secure the password becomes" is a misleading statement. What it really means is that given the will to break into a computer, all you really need is time. If someone asks, "How long does it take to break a password?" I generally say that there is no definitive answer and, instead, give some clues that can help determine the answer for a given system:

• How many people know the password?
• Do all of those people still work for the company?
• If some of the people who know the account's password no longer work for the company, did they leave amicably?
• Do you deny access to boot from the floppy disc, CD or DVD drive, or network?
• Are the users of the computers also local administrators?
• Do all of your systems use the exact same password for their privileged accounts?

Starting at the top of this list, it's fair to say that the more people who know a secret, the more likely it is that the secret will become public knowledge. I recall working for companies where the administrators felt it was more convenient to set the shared password to the same value and tell the IT staff as well as the interns what the passwords were, rather than typing in the passwords for them as required. Of course, as time continued, the company started finding machines with various unapproved settings and regular network users able to log into these accounts.

If all of those people who know the passwords still work for the company and are otherwise happy and dutiful employees, this access risk is slightly mitigated. But you never know when you might have a malicious user to contend with. If any of those users have left the company on bad terms, you have a loose, hostile element that knows how to break into your network using an otherwise untraceable account.

If you do not deny access to booting from anything other than the hard drive, then you also permit users to boot using non-authorized images, such as Windows PE or various Linux systems that can read directly from the computer's file system and gain access to the computer's secured storage. (I should point out that many breaches do occur from internal elements. Even if all the staff members and interns are still employed by the company, this is in no way an assurance that the passwords and systems are secure.)

I've know many people who have continued to log in to a network at a previous employer just because they could. It's mildly amusing that they are merely pointing out the poor practice of not changing system passwords, but it is also frightening to consider the damage they could do if they had malicious intents.

If you allow the ability to boot from a DVD or the network, then you may not be able to audit what people are doing. That is, a Linux boot disk or network image can often gain access directly to your file system. If your systems use the same user name and password for their privileged accounts, then you are setting your systems up for a major fall. More on these items later, though.

The password age and length are relevant depending on the method being used to crack a password. If you are dealing with a brute force method to determine passwords, then time is really what you are up against. The less frequently a password changes, the longer the window of time is for a cracker to obtain the password.

Similarly, longer passwords have exponentially more character variations and therefore require more time to crack. So it is important to consider whether your passwords are fewer than 7 characters, 8 to 14 characters, or 15 or more characters in length. And if the passwords are fewer than 15 characters and you are using Windows, do you disable LAN Manager (LM) hashes as part of the system configuration or by Group Policy?

How does the length of the password affect anything? In the case of Windows, the answer is simple. Omitting the history of Microsoft hashing processes, Microsoft implements two types of hashes for passwords, LM hashes and Message Digest 4 hashes (MD4). By default, Microsoft uses LM hashes, and the values are stored for all passwords up to 14 characters unless you explicitly turn off the storage of these hashes. These passwords are broken apart into two 7-character values—the first value for the first 7 characters and the second value for the second 7 characters, as shown in Figure 1.

Figure 1 Sample hash table

Thus, if your password is only 7 characters long, it would be contained in a single LM hash. For years Microsoft has recommended using at least 8 characters in your passwords. The reason for this was that the 8th character would then mandate that the password be divided into two LM hash values.

It is important to note, however, that LM hashes are widely understood and very easy to circumvent. The only purpose for them in current solutions is to help maintain backward compatibility with down-level systems, such as Windows NT® 4.0.

Nowadays you should be using passwords (passphrases, really) that are at least 15 characters or, preferably, longer because by definition they will not generate an LM hash. If mandating the use of 15-character passwords is not a viable option in your environment, you should disable the storage of LM hashes in both the image creation process (by using local policy) and in your Active Directory® Group Policy.

This policy can be found at Computer Configuration\Windows Settings\Security Set­tings\Local Policies\Security Options. Simply set the policy "Network security: Do not store LAN Manager hash value on next password change" to ENABLED.

It is important to remember that although good policy will dictate the use of uppercase and lowercase letters, as well as numeric or special characters, a better policy will also dictate a length of 15 characters or more.

The Longer, the Better

One current method used to break into computers is called Rainbow Tables, and it uses LM hashes as the exploit. But longer passwords can negate the effectiveness of Rainbow Tables.

I am amazed at how many administrators who wear the security cap seem to know very little (or nothing) about Rainbow Tables. There are various ways to create Rainbow Tables to deal with different algorithms. But these are merely a pre-computed list of all LM hashes from 0-14 characters.

The caveat of Rainbow Tables is that the attacker must obtain the LM hashes in the first place. This leads to the previous questions about how the system can be booted (to the CD or DVD) or whether or not your users are local administrators. Ultimately, these LM hashes can be extracted in a few seconds using free tools, such as pwdump. With the use of Rainbow Tables, the hashes are then searched for to determine the password.

To satisfy my own curiosity, I set a password on a system's built-in administrator account. It was 14 characters and contained various uppercase and lowercase letters as well as special characters and numbers. I then used Rainbow Tables that I downloaded for free from the Internet, and I was able to extract the password hashes for all the accounts on my system and determine the administrator's password in less than two minutes.

I must admit, it is pretty cool to watch the first LM hash being defeated, followed by the second hash, and then when you put them together you've got your password. To reiterate the point, if I had disabled my LM hashes using the policy I discussed previously, this particular attack vector would be severely limited, if not entirely blocked.

Domain Violence

Being in a domain doesn't fix the problem. Computers in a domain still authenticate in the same way. And, as I said before, in every domain lies the heart of a workgroup. This simple statement is not always obvious. I have had many conversations about this subject, and I find myself frequently reminding administrators what it takes to access a machine—a user name and a password. Then I must dive into a discussion of how Windows functions in a workgroup.

If you attempt to access a system, you will need to provide a user name and a password to the remote system. Through the use of integrated authentication, Windows will attempt to do this for you. This means that if you access another Windows system, Windows will use your currently logged in user name and password. So if you attempt to access another Windows system, you will never be prompted for that user name and password if the remote system has the same user name and password.

This is also referred to as pass-through authentication. The process works in workgroups as well as cross-domain. In the worst case, the system will ask you for a user name and a password, which means you simply have to retype your logon information.

Now even if you join a workstation or a server to a domain and Active Directory becomes your central account repository, all of the local Security Account Managers (SAMs) or local account stores on those systems don't just magically disappear. The only thing that seems to happen to those local SAMs is that they are no longer managed and secured, and herein lies the root of the problem. When was the last time you changed the built-in admin or root account on your systems? Better yet, download any reporting utility that can show you what the password age is for all your accounts and see if the results would pass an audit.

If you are still not sure what I mean, take any one of your domain workstations and logon as a domain account with administrator privileges. Open up computer management on your system and create a local user named ToldYouSo. Give the account a password and add it to the local administrators group of your system. Repeat this process on a second domain system.

Now, from either of those systems, log on as the local ToldYouSo account and attempt to access the second machine by going to \\systemName\c$. You will be able to access the administrative share, and you won't even be prompted for a password! I hope this example is not a surprise for you. But if it is, then please learn from this and allow me to reiterate: just because your system belongs to a domain does not change the fact that all of these systems still function as though they belong to a workgroup.

The point is that if you use passwords for your shared and privileged accounts that rarely, if ever, change, your shared and privileged accounts are at risk. All it will take to compromise your entire network is time.

Excuses, Excuses, Excuses

When I talk with administrators and even CIOs, I frequently hear the same top reasons for not changing these account passwords:

• We have thousands of systems and not enough time or manpower to change these accounts.
• We don't have the necessary budget.
• We have completely disabled our administrator accounts.
• We haven't been compromised yet, so we don't really think it's a problem.
• The auditors didn't notice.

While I can empathize with the first two reasons, these are not valid excuses. I shudder to think that I may have personal information stored with companies that do not address this issue for any reason.

While it is true that not every system in your network has sensitive information stored on it, the users of these computers do potentially have access to sensitive information, such as your Social Security number, medical records, or financial data. As an admin of a system, a user can install key loggers and screen capture utilities, stop Group Policy from applying, introduce shims into various subsystems to capture and transmit data, and so on. And when the user is doing this at the individual computer level, your ability to catch this malicious user is made much more difficult since he is named Administrator.

Did you know that disabling the built-in administrator account in Windows does not stop your ability to logon as that account? Try this: restart your system in safe mode and logon as the built-in administrator account. You can probably use the password issued to the account from the original image and be successful. For more information on this behavior, see the Microsoft® Knowledge Base article "How to Access the Computer after You Disable the Administrator Account" (support.microsoft.com/kb/814777).

What the Regulators Want

Dealing with SOX, PCI, HIPAA, and other regulations can make your head spin. Understanding their requirements can be tricky, as they are expansive and not clearly defined. Generally, what all of these regulations are looking for can be summed up as follows.

First, you need to guarantee who has access to all privileged accounts and information at all times and provide a method for proving this. This is good behavior in all scenarios—a privileged account is an account with rights to do anything over any system. This is the built-in administrator. This is the firecall account. These are the accounts that your entire help desk staff and every administrator working for you probably knows.

When you choose to implement a solution to manage these shared account passwords, you are creating an audit trail to the built-in administrator account where one currently doesn't exist. You are gaining a password that is fluid. And since the solution is automated, you won't lose weeks of productivity time spent changing these passwords. Ultimately, since the solution provides auditing capabilities, your company will be a step closer to passing its audit.

An Automated Approach

The most effective way of dealing with accounts such as these is to regularly change the accounts so that no two accounts ever share the same password. With shared passwords, a compromise of one system would mean a compromise of the other. In other words, there should be no common local or domain accounts.

When you deal with automated solutions that can manage and randomize these passwords, avoid doing just the bare minimum of what's required by your auditors. For example, why use only 8 characters for your passwords when you can do 15 or 20, or 127, without any extra effort (see Figure 2)?

Figure 2 Use automation to create very long passwords (Click the image for a larger view)

Also, consider randomizing your privileged accounts every day, as shown in Figure 3. There's no reason to do this only every 90 days when you can do it monthly or bi-monthly or even daily. After all, if the procedure is automated, it should not create any extra work for you. Plus, if you do this on a regular basis, you will force users to recover the passwords from the tool's audited retrieval interface, providing another audit trail where one hadn't previously existed. (If you presently store written passwords in an envelope in a safe in the back corner of someone's office, you have no audit trail for those passwords like you would if you used a password management solution.)

Figure 3 Randomize your privileged accounts every day (Click the image for a larger view)

Finally, ensure that when passwords are recovered they can and will be re-randomized after a fixed period of time following recovery. I am not referring to the scheduled randomization jobs you created, I am talking about creating one-time-use passwords that are only valid for a matter of hours instead of a few months. Again, this method will force users to recover the passwords from the tool's audited retrieval interface, providing an audit trail.

Think about It

The issue of shared account password management must be addressed. This means you should obtain a method of reliably and regularly changing your passwords. The solution must be scalable and flexible. It must also provide secured access to the passwords, and it needs to audit every action taken by the tool as well as every action taken by every user of the tool. In addition, the passwords generated need to be unique on every system in order to avoid a break-in due to shared account information.

Many vendors have been addressing this problem for a number of years, and many more new vendors have crept into this field recently. Be sure to do your research and try out all new tools before you buy to ensure the solution you settle on is the right fit for your environment.

Chris Stoneff is a Product Manager at Lieberman Software (liebsoft.com), a security and systems management software developer. His biggest drive is not just to know how something works a certain way, but why.