Comment by trotsky | Hacker News Reader

Comment by trotsky | Hacker News Reader

Parent Full thread

Computer security is obscenely asymmetric - an attacker only has to find one flaw, once, somewhere. A defender needs to constantly monitor, test, review isolate and basically never make any mistakes.

It is easy to look at almost any intrusion and attribute it to poor defenses. If HBGary didn't have a SQL injection, they'd have had a XSS vuln. Or a employee would get spearphished. Or an attacker at a local coffee shop would compromise a mobile client. Or a backup service would get compromised and unencrypted. Or a interviewee could plant a network listening device. Or the CEO's daughter could win a pre-owned iPhone. Or a secretary gives out a VPN login. And so on and so on.

Did HBGary suck worse than usual? Possibly - but consider Google china got hit by ie6+acrobat vulns, DOD lost hundreds of thousands of classified documents from an air gapped and physically controlled system to a private, Open BSD may have included side channel backdoors, Kaspersky lost their source code, PS3/iPhone/Xbox/HTC etc. are unable to secure their platforms.

The truth is, a motivated attacker will rarely fail. Anyone reading this would be unlikely to survive 24 hours of a coordinated attack whether it's done by 16 year olds, chinese university students, russian mafia, FBI or simply nerds that know how to google vulnerabilities.

Fighting back against a group like Anonymous provides the same asymmetric warfare problems as the US military experiences in fighting terrorists, including the inability to respond with similar tactics for legal reasons.

Bottom line is, almost any organization can be subject to this kind of embarrassment without warning.

The 'real' story is that HBGary charges that big bucks to tell other companies and/or government agencies about how they aren't following security best practices, yet they themselves weren't doing so. I don't think that anyone would be ragging on HBGary for lax security if Anonymous had pulled out some 0day kernel exploit to break into HBGary's systems.

They failed in:

- Keeping their systems patched and up-to-date.

- Convincing/forcing their users to use strong passwords.

- Convincing/forcing their users to use separate passwords per system.

- Convincing/forcing their power users/admins to use a unique, strong password on key systems (i.e. Google Apps Admin).

- Not-invented-here syndrome (or maybe security through obscurity -- hey! if we use an obscure CMS then it won't be exploitable!) with respect to their CMS. I can be a little lax on them here. Had they chosen 3rd-party software people would doubtless be railing on them for which off-the-shelf 3rd party software they were using (e.g. had they been exploited through a Wordpress vuln, then people would be lambasting them for using Wordpress vs <insert-cms-here>).

The 'real' story is that a motivated attacker will rarely fail.

You can take almost any intrusion and write it up in wildly different ways.

If HBGary had not failed in everything that you listed, odds are you would be listing some other comparable set of failures:

- something somewhere is always unpatched and out of date

- humans always deviate from best practices

- 99.99% of intrusions involve traditional threats, well known vulnerabilities, unpatched systems and human error

I could write up 100 different intrusions done in 100 different ways and almost always make the victim sound incompetent, or like a real life spy novel, or make the defenses sound like fort knox, or make the intruders sound like gods, or make it sound like my product would have prevented them, or draw the conclusion that the security environment is hopeless and out of control.

In the end it doesn't really matter how it happened or what I make it sound like.

Bottom line: Did you get owned [Y/N]

Then again, a motivated defender is a very though adversary. Think "web server serves plain files only and is disconnected from the internal network"[1], "secure OSes everywhere"[2], "password quality checker installed"[3], "full-disk encryption for all serious data"[4], "SSH logins only via public key"[5], etc. Yes, this takes (some!) real effort. No, getting 0wned by "please drop the firewall and send me the root password" is not acceptable if you're a security outfit.

Really, you can go years without patching if you choose your software properly. (Except browsers - those just suck.)

[1] e.g. https://github.com/mojombo/jekyll [2] e.g. http://www.openbsd.org [3] e.g. http://www.openwall.com/passwdqc/ [4] http://www.openbsd.org/faq/faq14.html#RAID or the equivalent for other OSes [5] All over the internet. Or set up a Kerberos environment and get single-sign on too.

Bottom line: Did you get owned [Y/N]

As I've mentioned elsewhere, competent security needs to take into account sociological/economic analysis. Only looking at the technical and organizational side is literally just playing with yourself.

For example: if you're a major technology company, taking the step of publishing wildly popular content with DRM means you're going to be taking on a lot of highly motivated opponents. History demonstrates that this isn't a fight that you want to take on. Now consider: if you're a security company, what do you think is going to happen when you take on a subset of /b/?

Here's a hint: before you're in the position where you're risking the ire of a large, technically savvy population that's had demonstrated success taking on other corporations with comparable or greater resources than yourself and a history of flaunting the law, it really behooves you to do some preparation.

If you've been saving some chump change by keeping your mailserver on the same machine as your webserver, and you're about to take on /b/, now's the time to do something about it.

That's like some athlete not checking if his shoes are laced up properly before the event.

Did this security company ever audit its own security? Either they didn't or they did an incompetent job of that. Would you trust a security company that doesn't eat it's own cooking?

Not necessarily. It's easy to forget that attacks typically depend on, admittedly very common, multiple layers of security failures. For example, using the same passwords on many systems, etc. Good security is defense in depth. Keeping every component as secure as possible and keeping any breach of security as restricted as possible. It may not be possible to avoid every conceivable attack, but it's certainly possible to withstand a large number of attempted attacks.

The other side of the coin is that attackers don't publicize their losses. Every attacker has a limit to their skillset. If they can't compromise someone they won't announce to the world their failure, they'll just pretend like nothing happened and move on.

- Convincing/forcing their users to use separate passwords per system.

I have to disagree that this one is really a best practice at all. I have dozens of different accounts on different computer systems, if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.

With that said, I absolutely think passwords on critical systems must be unique and strong. But I have maybe three systems I consider critical and dozens that not. My bank password for instance is unique and long. But I am more worried about being able to remember my passwords than whether or not someone who gets into the account I use to play Go online can also get into the account I use to play chess online.

if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.

There are a variety of good password vault programs out there. I keep my passwords in a KeePass 1 file on Dropbox. I can run Keepass on Windows, Linux, OS X, and my iPhone and iPad. There are a variety of low-cost and free options that are about this good or better.

Sometime, I'll be working on a Keepass compatible iPhone program that can access Dropbox directly.

> I have to disagree that this one is really a best practice at all. I have dozens of different accounts on different computer systems, if I didn't do at least some password reuse I would have a hard time writing them all down, and remembering them would be totally impossible.

Yes, it's a pain in the ass (at present), but yes, you should be using different passwords for everything, and pubkey authentication where possible.

The problem of maintaining an encrypted master password list for many different accounts is just a technical one. It will be solved. Keyring managers already do this. I noticed the latest Chrome linux builds use the desktop keyring manager now for saved passwords, rather than storing them unencrypted in the browser's password store.

Personally, until these keyring managers are mature enough, I use a few simple scripts: one which generates a new semi-pronounceable password with random chars, one that adds a new account to a gpg-encrypted master password file, and one that queries the gpg-encrypted master password file when I've forgotten a password to an account.

You make good points and I think I may have to work more on using more distinct passwords.

Though, as you alude, this will become easier as keyring managers mature. I am also hoping that as security technology matures more places will move to forms for two factor authentication.

> Keeping their systems patched and up-to-date.

Which systems were these? I didn't see anything that implied they were compromised through a missing patch.

If you're referring to the CMS, then that could just be a bit of custom code. We don't know.

From page 2:

"The only way they can have some fun is to elevate privileges through exploiting a privilege escalation vulnerability. These crop up from time to time and generally exploit flaws in the operating system kernel or its system libraries to trick it into giving the user more access to the system than should be allowed. By a stroke of luck, the HBGary system was vulnerable to just such a flaw. The error was published in October last year, conveniently with a full, working exploit. By November, most distributions had patches available, and there was no good reason to be running the exploitable code in February 2011."

Thanks. I was getting confused about the root password with jussi's email.

There was apparently a privilege escalation from Greg Holund's ssh account on the support machine - leading to the rootkit.com data and further credentials.

Thanks for pointing that out - I missed it. Was thinking of rootkit.com.

When an attacker uses state of the art techniques to get through your security, you curse them and then redouble your efforts at security.

When an attacker uses rudimentary techniques that have been well known for many years and have straightforward and low-cost counter-measures, then you should rightfully be disgraced. More so if you are a security company.

It's not as though the attack against HBGary was like some expert safe-cracker routine. Rather, it was more similar to someone walking up to the front door, finding it locked, then finding a key under the doormat and letting themselves inside. There's no excuse for that. Not if you have any sort of obligation to maintain a level of security and secrecy.

I consider this instance to be a step worse, given that you have to actively work against the tools available to create an SQL injection vulnerability (or at least take extra steps to work around the easy way of operating).

I wouldn't go quite that far. In PHP, for example, it's still the most straightforward way to use dynamic sql statements built up as concatenated strings. It's easy enough to skip input sanitation here or there on accident.

That being said, there's absolutely no excuse for that sort of slap dash engineering today. It's dead simple, even in PHP, to use input sanitation, or to use parameter binding / prepared statements to avoid SQL injection vulnerabilities. Those sorts of best-practices have been well known for at least the last half decade.

I see these apologist comments on every HBGary article and, please, it's not rocket science.

When you call yourself a "security company" then it is not too much asked to please not expose a half-baked PHP Application to the public. It is not too much asked to have your team adhere to the most basic password practices.

A defender needs to constantly monitor, test, review isolate and basically never make any mistakes.

This is bordering on FUD.

No, as far as your network presence is concerned there is a very finite number of attack vectors. For most companies there is no reason to expose more than a very small set of services to the world. Hardening these services is well understood.

If I only open Port 22 and 80 to you, and the webserver will serve only static files, then you'll have a pretty damn hard time owning that box, unless you have access to very rare and precious remote exploits for the kernel, OpenSSH or nginx. And unless I make very basic mistakes in configuring these things.

Moreover good security is layered. It's absolutely ridiculous to try to come up with excuses for a security company having their CMS broken into and that being enough to effectively travel their entire network.

Any admin worth their salt will put the company wordpress on a separate server, with zero trust-relationship to the rest of the infrastructure. It's a no-brainer.

Yes, incompetence is widespread. But please call it out for what it is and don't try to come up with justifications.

Security it's not about being totally impenetrable, it's about being too expensive to be attacked.

Computer security is obscenely asymmetric - an attacker only has to find one flaw, once, somewhere. A defender needs to constantly monitor, test, review isolate and basically never make any mistakes.

That is something the IRA used to say, they only needed to get lucky once, whereas the police needed to get lucky all the time. Of course humiliating someone on the Internet is a world away from blowing up a shopping centre. If the consequences were more serious than embarrassment, then a lot more resource would go into guarding against it. Schneier talks about attack trees (http://www.schneier.com/paper-attacktrees-ddj-ft.html) - always look for the cheapest vulnerability.

Incidentally there is one online group who could eat Anonymous for breakfast - Mumsnet. If Anonymous ever took them on, they'd be grounded before you knew it.

  > Incidentally there is one online group who could eat Anonymous
  > for breakfast - Mumsnet. If Anonymous ever took them on, they'd
  > be grounded before you knew it.

For those less inclined, this seems like a joke as Mumsnet seems to be a UK online parenting community mostly consisting of mothers and presumably they would 'ground' Anonymous whom are supposedly just a bunch of punk kids.

Don't underestimate Mumsnet, the British government is terrified of them. Get them all pointed the same way and they are like a pack of angry she-wolves going for the wounded wildebeest of public policy. Think what they could do to any organization that doesn't have any real-world assets to protect it...

Reply on news.ycombinator.com