Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anonymous speaks: the inside story of the HBGary hack

arstechnica.com

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Anonymous speaks: the inside story of the HBGary hack

#71

Post by moe »

trotsky wrote: post #27

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…

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.

Re: Anonymous speaks: the inside story of the HBGary hack

#72

Post by timwiseman »

pyre wrote: post #34
trotsky wrote: post #27

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…

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 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.

Re: Anonymous speaks: the inside story of the HBGary hack

#73

Post by stcredzero »

_b8r0 wrote: post #37
rdtsc wrote: post #12

Earlier quoted context omitted.

> the story says hbgary hired an outside company to make this cms for them, which may explain the crappy security on that particular system. Doesn't that make them look even more amateurish and incompetent? They chose an insecure content management system and, most importantly, they didn't isolate it enough. So penetrating that resulted in a complete penetration of their site. If they were selling hand-made baskets,…

Not really, they should've tested the site themselves and there's evidence that this actually happened on the main site but not federal. Normally a company contracts an external company to do the work for them and either asks the external company to independently check the security of the output or organises it themselves. In the case of federal it may have been the case that neither happened. > If they were selling…

someone else had a SQL injection bug on the same box and the hackers defaced every site on the box. The difference is that we did a risk analysis beforehand and decided to never to store sensitive data there nor use the same credentials for that account anywhere else

And that's precisely the difference everyone should look for when hiring a security company.

Re: Anonymous speaks: the inside story of the HBGary hack

#75

Post by taylorbuley »

dantheman wrote: post #11

Amazing write up - this is one of the best pieces of technical journalism I that I think I've seen. There is no hype, it's informed, it's detailed - but not super technical, i.e. math showing password complexity to rainbow table size tradeoffs etc. Any journalists out there, this is how it's done.

Noted!

Re: Anonymous speaks: the inside story of the HBGary hack

#76

Post by tedunangst »

cookiecaper wrote: post #48
tedunangst wrote: post #29

Earlier quoted context omitted.

Changing passwords is a lot easier than changing keys.

Also, passwords are compromised much more often than keys. To get someone's SSH key you have to have access to their local workstation, which is probably going to be more troublesome than access to a colo'd server, if for no other reason than most workstations go to sleep after they've been inactive for a while (there are other reasons, though). Also, changing keys isn't that hard. You just re-run ssh-keygen and dele…

replacing the private key is the hard part. it's the kind of thing where you don't discover that the new private key for your server isn't on your backup laptop until you need to login and don't have access to a system with they key.

Re: Anonymous speaks: the inside story of the HBGary hack

#77

Post by sigil »

timwiseman wrote: post #72
pyre wrote: post #34

Earlier quoted context omitted.

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 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…

> 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.

Re: Anonymous speaks: the inside story of the HBGary hack

#78

Post by InclinedPlane »

sophacles wrote: post #65
InclinedPlane wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: Anonymous speaks: the inside story of the HBGary hack

#79

Post by InclinedPlane »

trotsky wrote: post #55
pyre wrote: post #34

Earlier quoted context omitted.

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.…

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, w…

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.

Re: Anonymous speaks: the inside story of the HBGary hack

#80

Post by t3chg1rl »

stcredzero wrote: post #70
m0nastic wrote: post #14

Earlier quoted context omitted.

I don't mean to shatter your dream of how security firms are run, but on the whole, I'd bet we're no better than the industry at large. This might be a "cobbler's kids shoes" issue, or just a general failure of people and process. One of the only truisms I've found so far when dealing with breaches is that almost no one gets this right proactively. You almost have to be the victim of a breach (the more public the bet…

I don't mean to shatter your dream of how security firms are run, but on the whole, I'd bet we're no better than the industry at large. If it's ever possible for me to hire a security firm that has higher standards than this, I'm going to do that!

I agree with stcredzero. You need some standards if you're going to put yourself out there as a security company. I'm a random chick with some web programming and I know that you should iterative hash or salt your hashes. I also know you shouldn't use the same passwords, and what sql injections attacks are. Hey, maybe I should start a security company!
Post reply on HN