Security Watch

Password Abuse Runs Rampant

One in five help desk calls related to passwords, says one study. Plus: Flaws in EMC NetWorker, GnuPG messaging.

• By Russ Cooper
• 04/18/2007

I have long believed that longer and/or more complex passwords do little to reduce the risks they are believed to prevent. This opinion is held by many others, including Eugene Spafford over at CERIAS, who recently blogged about passwords.

Passwords are abused because they are:

1. Cracked. No combination of length, complexity and TTL is going to thwart a concerted, brute-force attempt and still be a viable corporate-wide policy. For example, against all possible alphanumeric Windows passwords in 2003, it took 13.6 seconds to determine a password. Yes, longer passwords would make it take longer -- but not long enough. Yes, introducing non-alphanumeric characters would also make it take longer -- but again, not long enough.

2. Replayed. MITM, sniffed on the wire and reused is an example. Password policy serves no purpose in thwarting such attacks. If an authentication attempt is being intercepted en route and the password component can be redirected, the criminal need not know the password to use it.

3. Captured. Keystroke loggers are a primary example and password policy serves no purpose in thwarting someone using this snooping method. The criminal will have the password, regardless how long or complex it is. The TTL will be the only limitation on the abuse of it. If the keystroke logger isn't detected and removed, even a very short TTL will serve no purpose in thwarting the criminal as they will simply get the new one when the old one is changed.

4. Eavesdropped. Whether it's over the shoulder or via a surveillance camera, password policy serves no purpose in thwarting this type of these kinds of such attacks. Provided the criminal can actually see the password being typed in, they have it, again, regardless how long or complex it is.

5. Guessed. Here, and only here, is where policy has an impact. This is also the least likely method of attack to be used, and the slowest approach.

A Flaw That Impersonates NetWorker
Due to a vulnerability in how EMC's NetWorker Management Console protects its database, a criminal could compromise the console, obtain the contents of the database and then impersonate the Management Console to gain access to managed storage devices. The vulnerability could also give a criminal complete access to the system the Management Console is installed on. Patches are available.

The Management Console and managed devices communicate over port 2638. This port should not be accessible by systems that are not part of this client/server realm. Only managed devices should be able to reach the Management Console, and vice versa. Provided that access is already limited, the vulnerability poses little threat. If this protection is not already in place, enable it as a first step prior to applying patches.

GnuPG Data Spoof
It is possible to combined unsigned text with a signed, or signed and encrypted message in such a way that when displayed, it would be impossible to determine precisely which part of the message was actually signed.

The project calls on those who write applications that use GnuPG to implement the mechanisms to appropriately display the distinction between signed and unsigned components. The GnuPG software itself will not display the signed component as valid if there is not a distinction, so some products may still fail to distinguish signed versus unsigned, but the validation will fail.

Stormy Weather for Malware Defenses
Commtouch has released a study pertaining to the "storm" malware released in January 2007. They believe the authors are attempting to overwhelm the resources of anti-virus companies in an effort to ensure that some of their malware reaches victims who cannot detect it as malware. Commtouch claims that there were more than 42,000 variants of "storm" released during the last half of January.

There is no doubt that a battle is being waged by criminals against anti-virus as a technology. The cost to criminals for releasing a variant is almost nil, so it's hardly much more to develop a process that creates thousands of variants of the same code and release them all at once. Even if only one victim is found for each variant, the criminal still profits.

So it should be obvious why the idea of attachment-blocking at the e-mail perimeter is so important. "Storm" did not attempt to exploit any vulnerability, except that of not blocking executable attachment types at the mail perimeter. This will likely continue to be the case for the vast majority of e-mail-borne malware. If you don't have default deny enabled, get it done soon.