Advice on Violating Corporate IT Policies from the Wall Street Journal

Published: 2007-08-01. Last Updated: 2007-08-02 01:47:59 UTC
by Lenny Zeltser (Version: 2)
0 comment(s)

Several ISC readers told us about an article in the Wall Street Journal titled Ten Things Your IT Department Won't Tell You that seems to describe several ways of violating corporate IT policies.

The article points out that often "it's just easier to accomplish certain tasks using consumer technology than using the sometimes clunky office technology our company gives us. ... There's only one problem with what we're doing: Our employers sometimes don't like it. ... To find out whether it's possible to get around the IT departments, we asked Web experts for some advice."

I was troubled by the perspective this influential business publication is taking on IT policies. Surely, many employees know about services such as YouSendIt for transferring files to home systems, web versions of chat clients that don't require installation, web proxies for bypassing website filters and other handy tools that can often violate corporate IT policies. Unfortunately, the tone of the article almost encourages the employees to look for ways of bypassing such policies--an action that can be detrimental to their employers and their careers.

ISC reader Thomas Schmitzer told us he was "amazed at this article." He wrote, "We spend years training our users to follow good security practices and a 'trusted' source of information for executives and management writes this article. ... Yet it ultimately tries to convince our users that forwarding sensitive company information to free web based storage solutions, installing any application, surfing porn, or forwarding your email to a free third party service is perfectly acceptable."

ISC reader Jeff said he was "very surprised that this is published in such a mainstream news outlet.  What's next, an article on how to help terrorists launder money and not get caught?"

The article did list the risks associated with attempting to violate the policies. "To find out the risks, we talked to three experts who make a living helping IT departments make the rules and track down the rogue employees who break them."

ISC handler Swa Frantzen mentioned that the article left out one big risk: Violating the company's policy may be a reason for dismissal. He pointed out that IT staff can use the article as a way of raising awareness for the policies that exist at the companies, and the sanctions associated with violating the policies. He also emphasized the need to develop IT practices that support the mobile nature of the modern workforce. "We will need to evolve from the medieval walled city model we all build with our current security technology to a modern grid pattern city, where the people live in the suburbs and are mobile." (Swa offers a presentation about adapting the IT paradigm to embrace mobility instead of blindly banning it.)

ISC reader P. looked at the article not as a suggestion to subvert IT polices, but rather as a checklist of common symptoms to monitor the IT policies for process improvement. He pointed out that there are "a number of really effective tools that can be implemented that  truly do remove the need for the workarounds in the first place.  "

Was the article a good way to cultivate such a discussion? Was the Wall Street Journal's perspective out of line? Take a look at the article and judge for yourself.

-- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

Keywords:
0 comment(s)

Remote Password Guessing - Follow-up

Published: 2007-08-01. Last Updated: 2007-08-02 01:18:13 UTC
by Lenny Zeltser (Version: 2)
0 comment(s)

We received several responses to the earlier diary about remote password guessing.

Melvin Klassen highlighted an important technique for mitigating the risks of remote password guessing: monitoring the logs on servers that authenticate users, such as POP, FTP, IMAP, web mail, telnet, and SSH. Melvin suggested counting the number of failed logon attempts and the number of logon attempts per source IP address, so that you can look for spikes and trends that may signal an attack.

Gabriel Friedmann and Mark Senior reminded us of the large-scale phishing attack on MySpace, which allowed researchers to analyze password usage patterns. According to several reports (see 1, 2, 3), the most common passwords included:

password1, abc123, myspace1, password, blink182, qwerty1, fuckyou, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1, monkey, cookie123, iloveyou, miss4you, password19, clumsy, sassy, pablobob, mobbie, fuckyou1, tink69, gospel, terrete, monster7, marlboro1, bitch1, flower

Daniel Cid told us about an SSH honeypot he set up to monitor SSH brute force attempts and record the passwords used by them. The passwords he observed included:

1qaz2wsx, 1q2w3e4r5t6y, 1qaz2wsx3edc4rfv, qazwsxedcrfv, michael, work, maggie, print, 123456, internet, mobile, windows, superman, 1q2w3e4r, network, system, 123qwe, manager, querty, www, coder, 123123, 1234567890, info, tony, bill, flowers

Nathaniel Hall described his process of cracking local LDAP password hashes using John the Ripper, through which he identified the following common passwords:

Cobra1, Dragon1, Travis1, Ferry1, Password8, Ynattirb1, Iloveyou5

Paul Dabrowski pointed out the importance of validating a user's secret question answers to ensure they don't include the actual password. He emphasized that "in addition to dictionary checks that some services make against submitted passwords, the password hint should be compared to the submitted password to plug up that little hole."

Thanks to everyone who wrote in.

-- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

Keywords:
0 comment(s)

Remote Password Guessing - Concerns, Observations, Recommendations

Published: 2007-08-01. Last Updated: 2007-08-01 21:57:00 UTC
by Lenny Zeltser (Version: 1)
0 comment(s)

As an organization's IT security practices mature, it gets better at protecting its network perimeter systems: the patches get applied more regularly, the firewall rules become more restrictive, the OS gets locked-down more rigorously. Even at such companies, authentication systems often lag behind. If the employees, partners, customers, vendors need to remotely access an application with logon screen that requires a password, two things will often hold true:

1. The application will assist the user in remembering the password.

This may involve emailing the password to the user's email address. If you're an attacker, you will try gaining access to that inbox to retrieve the password.

The application may also present the user with a "secret question" picked by him or her in advance. Unfortunately, such questions often have easy-to-guess answers. Favorite color? Blue. Favorite month? March. It doesn't take many tries to go through likely answers to such questions. Even if it doesn't work for a particular user, it may work over a large population of targeted users. In many cases, answering such questions may not trigger the account lock-out mechanism.

Finally, the application may provide a different response to a valid username than to an invalid username. For instance, if the username and password are both incorrect, it might say "Access denied." But if the username is correct, it might say "Password incorrect."

Make sure your users recognize the importance of protecting access to their email boxes. Help them by protecting the email servers. Also, consider implementing complexity requirements for answers to secret questions or give users a few secret questions to chose from, but omit common questions such as those about color. Finally, don't provide too much information in response to a failure to logon successfully.

2. The user will select an easy to remember and easy-to-guess password.

There are too many passwords to remember. Of course, users will try to select those that are easy for them to remember. Much has been said about encouraging users to select hard-to-guess passwords, so I won't repeat the discussion here. Once concern to keep in mind is that if your selection requirements are too strict, or if the users need to change the password too often, they will still find a way to beat the system. They may write the passwords down or use the same password across multiple systems/sites/organizations.

Also, the use of default passwords plagues many environments. If possible, require that your users change the pre-assigned password after first logging on to the system, and make sure the default passwords you assign are difficult to guess.

Automatically locking an account after several failed logon attempts will address many of these concerns, but sometimes it's not a feasible option. We may be concerned about denying service to our customers or executives. Or we may not have the staff to deal with unlock-my-account requests. A nice compromise is often a mechanism that locks the account for a few minutes, then automatically unlocks it. This can slow down the attacker's guessing tactics, yet allow the legitimate user to login after a brief waiting period. Implementing CAPCHA to discern between human and non-human users of your site can be effective as well to discourage automated password guessing.

Include Remote Password Guessing in Your Assessments

If your security assessment procedures do not already include remote password guessing, consider adding this task. The steps that come to mind include:

  • Identify publicly-accessible services/applications that request username/password credentials and attempt bypassing them via manual guessing. Keep an eye out for account lock-out mechanisms.
  • Query Google and examine your public website to identify possible usernames. (The Backtrack CD has some nice tools for that.)
  • Compile a list of possible passwords the users might use, accounting for your organization's location, name, and industry-specific terminology. Add common names and words like "passsword" to the list. I find that having a short, but intelligently-crafted list is more effective than using a 100KB dictionary file (the long file often takes too long to cycle through remotely).
  • After trying the manual route, make use of an automated password guessing tool to see whether it can guess logon credentials using the short password list you put together. Hydra is an excellent tool for this task. It's free, fast, and effective, even though it's poorly documented. (Anyone feels like writing a comprehensive guide to using Hydra, or pointing us to one that already exists?) Hydra is included on the above-mentioned Backtrack CD, and supports most of the protocols you're likely to encounter in the field.

Do you know of any lists that include passwords that actual non-IT users have used? We know of lists that include common passwords of IT staff, but we're looking for one that would apply to non-IT users. Not a dictionary file of potential passwords, but the words real users have used as passwords. If you know of such a list, let us know.

Update: A follow-up to this diary is available here as a separate note.

 -- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com

Keywords:
0 comment(s)

Apple?s patch flood

Published: 2007-08-01. Last Updated: 2007-08-01 20:54:45 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

On Tuesday Apple released 3 major security update batches:

  • APPLE-SA-2007-07-31 Security Update 2007-07 fixes 45 security vulnerabilities in Mac OS X (various applications and services are affected). If you run Mac OS X you definitely want to install this since a lot of common packages are affected. You can find more information at http://docs.info.apple.com/article.html?artnum=306172.
  • APPLE-SA-2007-07-31 Safari 3 Beta Update 3.0.3 fixes 4 security vulnerabilities in Safari 3 Beta. All 4 vulnerabilities affect Safari on Windows XP or Vista and 3 of them also affect Mac OS X. More information at http://docs.info.apple.com/article.html?artnum=306174.
  • And finally, APPLE-SA-2007-07-31 iPhone v1.0.1 Update fixes 5 security vulnerabilities in iPhone. As some of them are pretty bad (arbitrary code execution after viewing a maliciously crafted web page) you also definitely want to install them, if you’re using your iPhone for web browsing. More information at http://docs.info.apple.com/article.html?artnum=306173.
Keywords:
0 comment(s)

Comments


Diary Archives