Then they lost the stick.

With a yellow sticky attached to it with the password.

We really can’t make this stuff up.

Of course, you may be thinking:  The world didn’t come to an end.  Clearly, this whole thing was just a Y2K hypefest.  I’m sorry the bad guys aren’t quite the eschatologists some people would like them to be, but somebody’s been investing extraordinary amounts of resources making a worm very difficult to kill.  It’s not like there was a contingent of rogue coders, sitting around figuring out where they could put two-character date fields after January 1st, 2001.  There’s a bad guy out there, and while we shouldn’t panic, we shouldn’t quite ignore the situation either.

I agree with his advice.  Don’t panic, but don’t drop your guard either.  Now that network based scanners can spot this, the owners of enterprise networks should be scanning and cleaning up.

The Conficker Working Group is a (rare) collaboration among a broad spectrum of technology companies and organizations including Microsoft, Afilias, ICANN, Neustar, Verisign, CNNIC, Public Internet Registry, Global Domains International, Inc., M1D Global, AOL, Symantec, F-Secure, ISC, researchers from Georgia Tech, The Shadowserver Foundation, Arbor Networks and Support Intelligence. Their work was aimed at both detection (hence the AV companies) and keeping the worm from phoning home (the registrars and ICANN).

Reports are that some small percentage of infected machines did manage to connect to an update server, but did not immediately change their behavior.  This has led some to speculate that the April 1 date was a blind and the worst may be yet to come.  Certainly, it is no time for complacency, and organizations should remain vigilant in detecting and cleaning up Conficker-infected machines.

The most interesting work actually came over the weekend on the detection front.  Dan Kaminsky reports on work he did jointly with Tillman Werner and Felix Leder of The Honeynet Project to detect infected machines from the network rather than the host. The authors of Conficker want to protect their botnet from poaching, so after they own a host they patch the buffer overflow that let them in.  Werner and Leder exploited the differences between the Conficker patch and the official Microsoft patch to develop a malformed RPC request that will elicit different responses from healthy and infected machines, allowing detection.  This is vital to remediating infections because the worm disables Windows update and any security software it finds on the machine to avoid detection.

In an amazing piece of coordination, the group figured this out last Friday and working code was in the major vulnerability scanners by Monday.  I don’t impress easily, but I’m impressed.

While my initial reaction was “Why?”, that’s really the wrong question.  The question is really when it makes sense.  Mantissa claims that a single mainframe can run thousands of virtual PCs.  So as large enterprises consider moving to virtual desktops (accessed by thin clients) it becomes a question of cost effectiveness. Which is more economical, a bunch of VMware or Windows servers hosting virtual PCs or a single mainframe?  I have no gut feeling right now.  It will be interesting to see how it shakes out.

This is, of course, SQL injection as we fondly remember it — one person mano y mano against the database.  More on how the world has changed in a future post.

July 4th is a day for remembering the founding of this country and the lofty ideals of those who founded it.  It is also a time to reflect on the words of Thomas Jefferson, one of the sharpest minds and greatest writers of that period.  Consider the soaring prose of “all men are created equal and endowed by their Creator with certain inalienable rights, among them being life, liberty, and the pursuit of happiness.”  Part of the brilliance of the Declaration was Jefferson’s morphing of Locke’s “life, liberty and the pursuit of property” to something accessible by everybody, happiness, rather than just the landed gentry, property.

I hope that everybody, regardless of political orientation, will take some time to celebrate the American experiment.  We have our ups and downs, and plenty of imperfections, but it’s still descended from the ideals on which it was founded.

A famous quote from Winston Churchill come to mind.  “It has been said that democracy is the worst form of government except all the others that have been tried”.  He also thought that the fourth was a holiday for Englishmen, since it recalled the fight by Englishmen for their rights as Englishmen against a German king.

Happy holiday, everybody.

Another of those security “rules of thumb” that people accept without a lot of critical thought is the notion that you should lock user accounts after some (small) number of consecutive bad passwords. Auditors, regulators, and (to my surprise) even a fair number of security professionals will cite automated lockouts as a best practice.

In a recent thread on the CISSP® forum, a mailing list comprised entirely of people with CISSP certification, somebody posed the question “where did the standard of 3 attempts come from?” because he had been asked it in a job interview. I was rather appalled at the number of responses that accepted the premise that locking out after 3 tries was a standard.

In fact, locking out after 3 tries is in most situations a really bad idea, and certainly not something you should do without a careful risk assessment. Automated lockouts are meant to prevent password guessing attacks. However, what they really do is deny service to legitimate users and keep your security staff chasing non-events.

As we demand increasing levels of password complexity, and more frequent changes (see spaf’s blog to learn why that is a bad idea) it becomes much easier for users to mistype their passwords quite a few times in a row. After a password change, I’ve been known to fat finger the new one 4 or 5 times in a row. With automated lockouts, I’d be locked out and in need of (costly) service from the help desk. So, for starters, we know that lockouts lead to accidental denial of service.

Even nastier is that lockouts enable a denial of service attack that requires no privilege elevation to mount. This is no trivial concern. In environments without lockouts, DoS attacks against user’s ability to log in are novel enough to be the stuff of tabletop exercises and after-hours discussions at security meetings. These attacks require a lot of privilege to mount, and (fortunately) rogue system administrators don’t come along all that often.

Lockouts change all that — the bar is lowered to the point that anybody with access to your login prompt can mount a DoS attack and keep your users off the air. For example, a disgruntled trader could take out his or her entire trading desk in minutes just before resigning — no privilege or hacking credentials required.

That’s the risk you take on from an automated lockout, especially one with a low threshold. What’s the benefit? I would say little or none. What are the attacks that lockouts are designed to prevent? Most commonly, lockouts are used to prevent password guessing attacks. But let’s think about how password guessing attacks are mounted. They either come from a human user typing guesses or an automated attack.

Human attackers are most likely to use social engineering techniques to get your password. If they are any good, they do not need more than one try. They got your password from you or somebody you trust, either by being plausible on the telephone or by phishing for it with a clever email. A three-strikes lockout does nothing to stop that attack; only good user training will.

Automated attacks come in two flavors, offline and online attacks. A successful offline attack will give the attacker the right password before they log in, so again a lockout does nothing to prevent that attack. The way to prevent offline attacks is to protect your store of hashed passwords so that it can’t be stolen. This means locking down anonymous FTP areas, using shadow password files (or better still, Kerberos) and other means that keep password hashes out of public circulation.

Online password guessing attacks can be stymied by a lockout, but then the attacker knows that you’ve discovered their activities, limiting your ability to investigate the attack and deal with the attacker. My recommended solution is to monitor and alert on failed password authentications. Set a high threshold, say in the hundreds, so that you really know that your are dealing with an automated attack. This will save your response team having to follow up users (like me) with fat fingers and will let them focus their response on attacks in progress.

You will notice a strong bias towards preventing denial of service attacks. That’s because in the industry in which I toiled for 15 years the ability of legitimate users to log in was nearly sacrosanct. The risks associated with having a trader unable to trade on an active day are costly, which means there is a strong bias towards mitigating them. Which gets us back to what I said at the start — lockouts should only be considered after a careful risk analysis. There may be some cases were the DoS risk is cheap and risks that can be prevented with a lockout are higher. In that case go for it, but I’m sure those cases are few and far between. As I’ve tried to show here, automated lockouts don’t really solve the problem that the conventional wisdom intends for them to solve.

Let me just add one more note that may make me seem inconsistent. I do support the feature in portable devices, such as Blackberries, that wipes the device clean after 10 bad passwords. First of all, 10 is a much bigger number than 3 and is unlikely to be a set of consecutive typos. Second, that control is aimed at lost devices, in which case the users have already denied service to themselves, and protecting private data on the device becomes the paramount concern.

But that is the exceptional case. In the end, there is only one word to say in response to a request to implement automated lockouts: “No!”