accesses since April 8, 2004
copyright notice
accesses since April 8, 2004Hal Berghel
Welcome to Security Wise, a new feature to Gaming and Leisure. In the issues to follow I hope you'll have some fun reading my articles, learn a few things about security, and most important, pick up a few tips that you'll find useful in securing your computers and networks. This installment is about passwords - specifically, password policies that affect Windows 2000 and XP computers.
PASSWORDS: THE FIRST LINE OF DEFENSE
Password protection is usually the first line of defense with computer systems. The good news is that most organizational security policies require the use of passwords on their computer systems. The bad news is that many organizational security policies are bit fuzzy on important details. I'll illustrate this point with a real-world example. This is a fragment of an actual organizational policy manual in use at this writing:
|
Although these policies seem reasonable, let me walk you through the implications these policies would have on this organization's Windows 2000 and XP workstations?
But first, the tragic tale of Mary Queen of Scots.
THE HOUSE OF TUDORS AND MICROSOFT'S PASSWORD TECHNOLOGY
For those of you who missed the episode on the History Channel, In 1586 Mary Queen of Scots was put on trial for planning the assassination of her cousin, Queen Elizabeth I of England . Beth found out but was reluctant to off her cuz because she didn't want to establish a precedent of the casual disposal of royalty that could come back to haunt her. So Beth required proof beyond any reasonable doubt before she would dispatch Mary to the ultimate Scottish highlands. The proof came from Beth's secretary, Sir Francis Walsingham. Since Mary communicated with the other conspirators by means of a secret cipher, she felt her little secrets would remain secret. Oh what an tangled web we weave,...
By her teens, Mary was riding the crest of a slump. She set the stage by rejecting her Tudor suitor, Edward, son of England 's King Henry VIII (of "six wives was he wedded..." fame). Henry was nothing if not single-minded, and ransacked southern Scotland in defense of his son's post-rebuff honor (a technique called "rough wooing" in the 16 th century - kind of like "tough love" with arson). Mary ran off to France at age 6 for the baguettes and freedom fries, married King Francis at age 17, and was widowed at 18 when Francis died of an ear infection. Returning to Scotland at 19, she lost the throne, married a succession of losers, and was imprisoned for 18 years by her cousin Elizabeth who decided she really didn't need the royal competition. This threw Mary into a serious funk that disposed her to view Anthony Babbington's plan to overthrow Elizabeth and put Mary on the Tudor throne with great enthusiasm. They exchanged the details of their derring-do by means of ciphertext stored in the bung holes of beer kegs that moved back and forth between the local ale house and Mary's castle where she was imprisoned.
Now here's the rub. Walsingham was intercepting the bung-holed messages and was reading them in transit. Walsingham had created a cipher school in London , and his code breaker, Thomas Phelippes, was successful in breaking the cipher. The court of Elizabeth I found the forensics compelling and Mary Queen of Scots guilty of treason (despite protestations to the contrary). Beth got the required "proof beyond all doubt," over which Mary lost her head (literally). The same fate befell Babbington who was apprehended in St. John's Wood, the Northern suburb of London made famous some years later by the striped crosswalk on the cover of the Beatles Abbey Road album. But I digress.
What is the moral of this story, I hear you ask? Well, it's either that one should never assume that encrypted messages are secure - even if they're stored in a bung hole of a beer barrel; or, one should always assume that there's a peeping Phelippes behind every (Microsoft) window. I'm confident that at least one of these morals will find its way into the millennium edition of Bartletts Familiar Quotations.
HASH FUNCTIONS AND LAN MANAGER
Windows passwords are "hashed" and stored either in Active Directory or in a SAM database. A hash function is just a mapping from one string of characters (e.g. the password you use to secure your computer) to another, usually shorter, string of characters (e.g., the corresponding bit string that's stored in AD or the SAM database). If everything works according to plan, this conversion from password to "hash value" is irreversible and secure. But, everything didn't go according to plan for Microsoft.
The hashing algorithm that Microsoft used before Windows NT was called LAN Manager (aka LANMAN, or LM) and based on the Data Encryption Standard (DES). Rumor has it that the U.S. Government picked the 56-bit DES in the mid 1970's because it was thought to be too hard to crack by individuals, but possible to crack by the government's supercomputers. In any case, Whitfield Diffie and others predicted at the time that DES was too enemic to be on prime time, and by the mid 1990's cracking DES ciphers was a favored game of script kiddies and hacker wannabes. Take a close look at Figure 1, below.
FIGURE 1. Cracking LAN Manager Hashes with @stake's LC4.
(note: information on administrator accounts has been erased)
Figure 1 is a screenshot of a "password hack attack" that I ran against one of my computers. In this case, a brute force attack ran for slightly more than 16 days and recovered the password for every user account on the system but for one, including Microsoft's HelpAssistant account. HelpAssistant is the account that the Microsoft help desk can use to take over control of your computer over the Internet, so HA password discovery is a bit scary! The time it took to crack the password is listed in the audit time column. Password cracking utilities such as the one used here, LC4, are abundant and only as far away as aWeb search. Though they are indispensable for password auditing, they may also be used maliciously by hackers!
This insecurity is a direct result of Windows XP storing the LAN Manager password hash. Microsoft set LAN Manager as the default password hashing algorithm prior to Windows NT, but still stores the LAN Manager password hash values in all new versions of Windows unless you specifically disable it. Even though NTLM v2 password hashes are currently thought to be practically uncrackable, if you don't disable the LM hash would be hackers still have easy access to your passwords through the vulnerable LM side. Leaving LM enabled while requiring the more robust NTLM v2 hash in your organization's security policy is akin to putting steel bars over the windows but leaving the front door unlocked.
REALITY CHECK
Here's a quick LAN Manager Vulnerability test you can run on your own computer to determine if you are vulnerable to password cracking attacks.
|
LOCAL SECURITY POLICY REVISITED
Notice that these LM password vulnerabilities weren't even covered in our organization's security policy. In fact, the password crack depicted in Figure 1 was on a computer that had stronger password requirements than were required in the organization's security policy, above. So the policy wouldn't have helped much against a serious hack-attack.
Let's look at the other four entries again. To follow along with the discussion, return to Local Security Settings, expand Account Policies, and single click Password Policy. Recall that the organizational security policy stipulated:
Maximum password age: 180 days
Minimum password age: 1 day
Minimum password length: 8 characters
Passwords must meet complexity requirements: enabled
How long should we be able to use the same password? Our policy says 180 days. However, LC4 found all passwords but one on my computer in less that 16 days. In that light, does 180 days seem a bit too long - even for long passwords? Our recommendation would be somewhere between 30 and 90 days, the shorter being safer. If you're paranoid, make it 15 but be prepared for a user mutiny.
Minimum password age is a control parameter. Its main use is to prevent users from re-setting their passwords to the old value immediately after a required change. By setting this value to 1, we're saying that it's allowable to reset the password the following day. Do we really want to allow this? This may be too short a time span for undisciplined users.
HELPFUL HINT: Requiring passwords 15 characters or longer on any account automatically disables LAN Manager passwords because LM can't handle anything longer than 14.
If there is any hard-and-fast rule with regard to Windows password management, entry 3 clearly violates it. This setting is extremely important because it can stop the use of LAN Manager passwords even if our Local Security Policy doesn't explicitly prevent their use. The maximum password length that LAN Manager can handle is 14; thus using a password of 15 or more characters will prevent storing LAN Manager passwords.
Our final entry is a no-brainer but don't really help our organization much. It is always recommended that we require that passwords meet complexity requirements. However, our organization's password complexity requirements were so weak that enabling wouldn't discourage any serious aggressor.
CONCLUSION
We've covered a lot of ground - from English history to early Windows password hashing techniques.
If you ran the REALITY CHECK, how did your computer's password security policies compare with the recommended standards? Is your organization's security policy as loose as the one above? If so, you may be living with the same false sense of security as Mary Queen of Scots. To be certifiably nerdie, we'll label this the "Mary Queen of Scots password protection phenomena" - hereafter, MQoS_3p. I think we're on a roll with the name game. Next time you want security funding from your CFO, tell him/her that you wouldn't ask if it weren't for the MQoS_3p issue in Windows isn't handled by modern firewall hardware and virus protection, so you need a larger budget.