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

41–50 of 84 posts

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

#41

Post by _b8r0 »

cookiecaper wrote: post #8

This really makes the case for much more public-key cryptography everywhere -- if all of the emails between HBGary, even internally only, were encrypted, HBGary would have gotten out with just a small DDOS and been meandering along just fine today. I think that people that run a computer security company should at least be able to figure out Enigmail.

> This really makes the case for much more public-key cryptography everywhere

This is what we do. We use Google Apps so we used a combination of existing policy, crypto and user awareness. It's not the use of email that's an issue, it's the how the data is stored. If it's encrypted with good crypto it's not a problem. If it's encrypted with bad crypto or no crypto then the extent of the problem is down to the data.

As an aside, while you would want to encrypt anything sensitive, that doesn't mean you need to encrypt everything - it certainly makes conversations over smartphones more difficult, and google chats wouldn't be encrypted.

Still, a little common sense goes a long way.

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

#42

Post by Sandman »

gaius wrote: post #32
bretthopper wrote: post #2

HBGary isn't anywhere near the only company to have security holes like this open. It's just worse because they're a security company and they happened to piss off Anonymous. Getting employees or users not to reuse passwords is probably the hardest thing to do. Also, Ars' coverage of this story has been great.

That's not a technical problem tho', it's social/organizational. If you make passwords too complex and change too often and enforce it in software, you simply encourage people to write them down, save them in the browser, etc. Or people will be phoning the helpdesk every day to get a reset, and security as a whole will be discredited as a waste of time. NOTE: I'm not saying that it is a waste of time, but the best po…

Your last paragraph actually has a very good point - why do companies insist on changing the employee passwords every month? Chances are, if somebody got hold of your password, he/she is not going to wait a month before using that knowledge, right? So, really, I'm curious as to why most companies have this policy.

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

#43

Post by samlittlewood »

_b8r0 wrote: post #39
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.…

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

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.

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

#44

Post by bartman »

_b8r0 wrote: post #39
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.…

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

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

#45

Post by _b8r0 »

bartman wrote: post #44
_b8r0 wrote: post #39

Earlier quoted context omitted.

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

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

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

#46

Post by _b8r0 »

samlittlewood wrote: post #43
_b8r0 wrote: post #39

Earlier quoted context omitted.

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

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.

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

#47

Post by JoachimSchipper »

trotsky wrote: post #28
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,…

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. No more than google choosing a linux kernel with a privilege escalation bug for Android, anyone using OS X in 2009 while a remote jdk bug sat open for 6 months, anyone using windows+ie in dec '10 or jan '11. Unless you can explain how to only buy soft…

Umm, if you're supposed to be a security guy, you shouldn't use IE+Windows, especially if there are publicly known vulnerabilities. You should also reconsider the use of OS X, and at least be able to follow instructions on how to disable the JDK. Etc.

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

#48

Post by cookiecaper »

tedunangst wrote: post #29
rst wrote: post #9

Earlier quoted context omitted.

One point in favor of requiring ssh keys for external access is that the users don't get to blow it on passwords. Though it does require sysadmin staff who are willing to walk users through the process of creating the keys --- and stubborn enough to explain that this is the procedure until following it becomes the path of least resistance.

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 delete the old key from authorized_keys and replace it with the new one.

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

#49

Post by weego »

Splines wrote: post #30

One: the root password to the machine running Greg's rootkit.com site was either "88j4bb3rw0cky88" or "88Scr3am3r88". There must be more to it than this. If you know it's one of two passwords, why bother asking - couldn't you just try both? (In retrospect, maybe it was to give Jussi confidence that he was communicating with the real Greg? [Who else, after all, would know the root passwords?])

That was the root password, and remote root was disabled, so they had to social engineer an account that could remote in over ssh so they could su to do the real damage.

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

#50

Post by gaius »

Sandman wrote: post #42
gaius wrote: post #32

Earlier quoted context omitted.

That's not a technical problem tho', it's social/organizational. If you make passwords too complex and change too often and enforce it in software, you simply encourage people to write them down, save them in the browser, etc. Or people will be phoning the helpdesk every day to get a reset, and security as a whole will be discredited as a waste of time. NOTE: I'm not saying that it is a waste of time, but the best po…

Your last paragraph actually has a very good point - why do companies insist on changing the employee passwords every month? Chances are, if somebody got hold of your password, he/she is not going to wait a month before using that knowledge, right? So, really, I'm curious as to why most companies have this policy.

Because, let's be honest, most "security consultants" are people who couldn't make it as sysadmins, and they've no idea what they're doing.
Post reply on HN