» Archive for the 'authentication' Category

Trust Storm

Monday, January 12th, 2009

Courtesy of Heise, we learn details of flaws that researchers have found in the storm worm botnet.

The whole article is interesting, but I found this most interesting:

Using this background knowledge, they were able to develop their own client, which links itself into the peer-to-peer structure of a Storm Worm network in such a way that queries from other drones, looking for new command servers, can be reliably routed to it. That enables it to divert drones to a new server. The second step was to analyse the protocol for passing commands. The researchers were astonished to find that the server doesn’t have to authenticate itself to clients, so using their knowledge they were able to direct drones to a simple server.

What kind of savant goes to all the trouble of building a worm as sophisticated as Storm and then leaves out authentication? This sort of thing is why I still hold out hope for the future of computing–the Bad Guys can make just as serious dumb moves as the rest of us.

Happiness

Sunday, January 11th, 2009

Courtesy of Twitter admins and famous users, we get another example of poor passwords leading to a breach:

An 18-year-old hacker with a history of celebrity pranks has admitted to Monday’s hijacking of multiple high-profile Twitter accounts, including President-Elect Barack Obama’s, and the official feed for Fox News.

The hacker, who goes by the handle GMZ, told Threat Level on Tuesday he gained entry to Twitter’s administrative control panel by pointing an automated password-guesser at a popular user’s account. The user turned out to be a member of Twitter’s support staff, who’d chosen the weak password “happiness.”

Cracking the site was easy, because Twitter allowed an unlimited number of rapid-fire log-in attempts.

“I feel it’s another case of administrators not putting forth effort toward one of the most obvious and overused security flaws,” he wrote in an IM interview. “I’m sure they find it difficult to admit it.”

I tend to agree with him. Twitter had not implemented basic authentication controls. My preferred list:

1) Never share or disclose passwords. This is completely unnecessary on modern systems and the only reason it happens is because admins don’t know how to manage access to privileged resources. If the admins request an exception for shared passwords (you have a policy of no password sharing, right?), the solution is to get better admins.

Human nature, followed closely by Phishing, are the obvious failures here. Human nature won’t change, but it remains a significant user and technology issue.

2) Enforce password complexity. This is difficult with public Web sites, I realize, but admins should at least have a policy requirement to do so. You can check this by running a cracker such as John The Ripper against your internal database. It’s quite fast and will produce a reasonable level of confidence in password strength pretty quickly.

3a) Limit login attempts–lock out accounts after a suitable number of attempts–it could actually be pretty high if combined with complexity.
and/or
3b) Monitor logs for brute-force login attempts. But do so automatically, including a reactive control to disable or otherwise block the login attempt. And review the incidents.

Passwords rely on a few simple controls, and can be quite effective if they are all followed. If they are not, however, then you wind up on 27bstroke6.

For all the two-factor fans in the house, I recently had to have some folks fired for performing out-of-band (voice) disclosure of SecureID values to bypass remote access restrictions (I caught them by reviewing access logs after I suspected they were at-risk for misbehavior, btw), so don’t try to hide behind that.

Similarly, Smart Cards, to quote a friend of mine at the Department of Defense, “are only as smart as the General’s picture on the front of it.” People tend to either leave the card in the machine (unifying it with door systems helps with this) or at least store it in their laptop bag if they have a laptop, in which case it’s worse-than-useless in a lost laptop scenario.

Also, strong authentication mechanisms tend to have some sort of graceful degradation built in, which can be an easy branch of the attack tree as well.

The key thing to realize is that no authentication mechanism is a perfect preventative control. You need compensating controls like log analysis to actually have any confidence that your beautiful technology hasn’t been bypassed by some clever people.

One final thought–why was admin functionality incorporated into the user-side of a public Web site in the first place? The best way to manage the risk of an admin account compromise is to avoid it by not having it publicly accessible in the first place!