9 ms·

Anonymous speaks: the inside story of the HBGary hack

345 points by abraham 16y ago

bretthopper 16y ago
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.
- alttab 16y ago
  Mammoth global corporations use passwords like 'P@55w0rd' on production systems and open servers not blocked by a firewall that store product-code and build systems. This type of 'best practice failure' occurs everywhere. For most, its like flossing every day. You know you should... but do you?
  - khafra 16y ago
    I don't floss every day, but I certainly wouldn't go to a dentist with obvious gingivitis.
- rst 16y ago
  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.
  - jfoutz 16y ago
    It's weird. Once things are set up, it's so much nicer than the alternatives.
  - tedunangst 16y ago
    Changing passwords is a lot easier than changing keys.
    - cookiecaper 16y ago
      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.
      - tedunangst 16y ago
        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.
- hysterix 16y ago
  Company? Hell, government, military, it goes on and on how many vulnerable networks are out there.
  - zolchy 16y ago
    Not in Britain, though, where there is no culture of carelessness: http://www.google.fi/search?q=british+lose+confidential+data http://www.google.fi/search?q=british+lose+confidential+data
- gaius 16y ago
  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 policies in the world are of no help if people simply refuse to follow them. The truth is passwords are not like toothbrushes - they don't actually need replacing every three months. Only if some event has occurred (e.g. a sysadmin leaving the company). They don't get weaker over time. Why not let someone keep the same decently strong password for as long as they're an employee? I guarantee this will be actually more secure.
  - Sandman 16y ago
    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.
    - gaius 16y ago
      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.
    - count 16y ago
      Passwords historically got weaker over time, but not in the sense that 'if he got your password hes not going to wait to use it'. They weaken in their hashed form. It used to be (still is, really) trivial to score the passwd file of a system, and get all the hashes of passwords, but no plaintext. By changing passwords every N months, you eliminated the ability of someone to crack the hashes and obtain a cleartext password where they previously only had a hash. That time window has gotten absurdly short, however...and with Pass the Hash and MITM, I don't even need your password anymore :(
  - mjb 16y ago
- cosmicray 16y ago
  > It's just worse because they're a security company and they happened to piss off Anonymous. It's just worse because HBGary isn't eating their own dog food. Think about that.
waterlesscloud 16y ago
Wow. Did they do anything right? I can understand a typical organization making most of these mistakes, but a security firm?
- m0nastic 16y ago
  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 better) to actually rethink how your people/processes are implemented. This seems true for the largest banks in the world, and the smallest security firms. And it's easy to look back in hindsight and say "how could they have possibly had things set up that way?", but the truth is that this was not an opportunistic attack; if these vulnerabilities weren't present, then they'd have looked for others. That's the problem with securing your environment, you have to get everything right, and the attacker only has to get one thing right. That being said, as with most "disasters", this was a series of cascading failures (like most airplane crashes, or oil rig explosions). Hopefully they'll learn from this (assuming the negative fallout doesn't completely bankrupt the company).
  - stcredzero 16y ago
    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!
    - t3chg1rl 16y ago
      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!
jmtame 16y ago
Good TLDR: "So what do we have in total? A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren't patched. And an astonishing willingness to hand out credentials over e-mail, even when the person asking for them should have realized something was up."
jgershen 16y ago
Very well written article - it does a terrific job of explaining things like rainbow tables for a non-technical (or at least, technically-but-not-security-minded) audience. The only part that seems off is the theme that /all/ of the exploited vulnerabilities were necessary to render HBGary vulnerable: "Even with the flawed usage of MD5, HBGary could have been safe..." They homebrewed their own password system. Can someone switch on the tptacek bat-signal?
- there 16y ago
  They homebrewed their own password system. the story says hbgary hired an outside company to make this cms for them, which may explain the crappy security on that particular system. Can someone switch on the tptacek bat-signal? thomas' security company also got hacked a couple years ago and had sensitive information plastered all over a mailing list. rumor was that it happened via their use of wordpress for their weblog. i guess the moral of the story is... you will get hacked by crappy third-party software?
  - rdtsc 16y ago
    > 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, nobody would blame them, but they sell "security" and charge big bucks for it, so they deserve the ridicule. It is an interesting perspective I guess on selling "security", both as a service and a product. One can charge lots of money, but unless there is a serious attack and penetration, it is hard to know what the quality of they security product is. Of course once the penetration happened, there is at best pity and at worst ridicule and blame.
    - trotsky 16y ago
      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 software that will never have any vulnerabilities.
cookiecaper 16y ago
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.
- askar_yu 16y ago
  not sure how e-mail encryption would have helped... ? They SQL injected and got the DB, obtained the passwords and then proceeded further (social engineering: FW policy change, ssh password through e-mail, etc.)
  - firebird84 16y ago
    If you protect your keys well enough, you can protect the content of your emails. If they're stored on an IMAP server, downloading them will do you no good without the keys. Additionally, compromising a single machine may only yield the key to some subset of a company's emails.
  - cookiecaper 16y ago
    It would help because the private keys needed to decrypt the emails would not have been kept on the server, and, even if they were, they'd still need a passphrase to get the content of the private key (though, it could have been the same insecure passphrase used elsewhere). Also, a common policy of encrypting and signing emails would have stopped the social engineering attack completely, as the sysadmin would've known not to accept an unsigned request to give out passwords. Kind of mind boggling that people don't do this generally already.
- iuguy 16y ago
  > 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.
dantheman 16y ago
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.
- chopsueyar 16y ago
  Shouldn't this be the standard, not the exception?
- jokermatt999 16y ago
  Ars Technica regularly comes out with good pieces like this. Out of all the tech news sites I've seen, they're generally the most professional (other than their photoshopped story images; those usually go for humor) and thorough in their coverage.
- taylorbuley 16y ago
  Noted!
OoTheNigerian 16y ago
I just took an introductory course in web security. This explained many terminologies that fly over my head on HN.
wh-uws 16y ago
SQL injection and MD5... on a "security" company? In 2011? I'm sorry but thats just egregious. Thats like being a bodyguard and not even putting a lock on your own house. The rest of the attacks could have happened to anyone. We all know its best practice to use many different passwords but most don't because its more convenient to only have one or a few. And if the email is coming from the email address it should you could brain fart and give up the info without thinking. But the first two parts of the attack should NOT have been possible for them to even pretend to call themselves a computer "security" firm in 2011
- hysterix 16y ago
  You are completely wrong to justify people using the same passwords in multiple places because it is convenient.
  - RyanMcGreal 16y ago
    Understanding a behaviour isn't the same as justifying it.
CaptainZapp 16y ago
HBGary used Google Apps for its e-mail services So, this high flying super duper high tech hardcore company actually uses an external email provider for their (I suppose) super secret emails? The more I learn about this incident the more Mr. Barr and HBGary look like a bunch of amateurish dolts that may give good power point presentations, but I for one sure wouldn't take my security business there.
- iuguy 16y ago
  We use Google Apps for our e-mail and we're a security company not entirely dissimilar to HBGary (the main company, not federal, and in terms of services, not practices). We moved to Google Apps as they bought Postini. We had an adult discussion of the benefits and drawbacks, and as everyone had PGP made it a straightforward job of encrypting things according to policy. Google Apps (for business, at least) offers SSL encryption on everything and offers relatively little by way of additional risk compared to using someone like messagelabs for your AV. Obviously they're storing the data for you, but you'd get that with any hosted provider.
trotsky 16y ago
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.
- gaius 16y ago
  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 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.
Splines 16y ago
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?])
- weego 16y ago
  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.
- nikcub 16y ago
  root passwords shouldn't get you far though. I once published all my root passwords on IRC as a challenge and didn't change them for a few weeks. Nothing happen.
ahrens 16y ago
<rant>As others have said, the most serious thing is that it is a security company, and they seem to have ignored EVERY security best practice ever! Did they do anything right? As a security specialist myself, I always do my very best to follow best practices, not only to protect myself, but to show others that I am willing to follow my own advice. I have met security people doing presentations that need to elevate to admin, and they are logged in as admin already. Sometimes even with UAC turned off. This completelly shatters my confidence in them. I am always logged in as normal user and have long (20+) passwords, and make sure people see that I have long passwords. I don't hold others to the same standard, but I know people. If they see that I use 20+ characters, they will not think that the 10 that I want them to use is that bad. This is the way the security landscape should work. We should all set ourselves to much higher standards than the advice we give others. We should always follow up on it. We KNOW lazyness will cause breaches, so therefore we should never be lazy when it comes to security. For a security company - and especially the president - to have such low security lowers the confidence for the whole industry. Yes, security is asymmetric. That is why companies must always follow at least the recommended best practices. If they are followed, the target might be too hard to break into and a hacker might go someplace else where it's easier to break in. Targeted attackers might still get it, but we should all make sure they have to work DAMN hard to succeed! If we start thinking that the attackars will succeed anyway, we might as well drop all defences. Display the admin passwords at the bottom of the "About us"-pages. Bottom line, HBgary fucked up good. They showed the world that they give advice that they don't follow. They deserve the burn and anybody thinking about hiring them should think again. Even if they change the problems that allowed this breach, the basic problem is that they obviously don't understand security. If they did, none of this would have happened. </end rant>
iuguy 16y ago
This is a very well written summary of how it all went down. From this, we can conclude: * An initial entry point through SQL injection (from which we can infer that the federal site was probably never security tested) * The use and re-use of weak administrative passwords * The adoption of poor practices (such as sending passwords in cleartext via email) at rootkit.com Of all of these, the attack would've probably been limited to the federal site had Aaron used decent strength administrative passwords (or just not reused them). The issue regarding the website comes down to risk ownership. If Aaron Barr was the risk owner for the website, it falls down to him. If in his contracting the company, Aaron had a plan to test the website then whomever tested it missed the SQL injection (which could've been implemented after a test by the CMS firm without him knowing, or any number of things). If Aaron didn't have a plan to get the site checked out, then that's both strikes falling on his shoulders. The third strike is quite clearly stirring the hornets nest. Moral of the story: Don't antagonise groups that will strike back without a plan to deal with it. Moral #2: Don't reuse passwords. Moral #3: Retest your app on every significant change (including initial deployment).
bane 16y ago
Relevant: http://news.ycombinator.com/item?id=2227181 http://news.ycombinator.com/item?id=2227181
djm 16y ago
FYI, it looks like Anonymous is aiming for total humiliation as far as HBG is concerned - they have even set up a pretty web interface/search for the entire collection of stolen emails - see http://hbgary.anonleaks.ru/ http://hbgary.anonleaks.ru/

345 points by abraham 16y ago

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.

alttab 16y ago
Mammoth global corporations use passwords like 'P@55w0rd' on production systems and open servers not blocked by a firewall that store product-code and build systems. This type of 'best practice failure' occurs everywhere. For most, its like flossing every day. You know you should... but do you?
- khafra 16y ago
  I don't floss every day, but I certainly wouldn't go to a dentist with obvious gingivitis.
rst 16y ago
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.
- jfoutz 16y ago
  It's weird. Once things are set up, it's so much nicer than the alternatives.
- tedunangst 16y ago
  Changing passwords is a lot easier than changing keys.
  - cookiecaper 16y ago
    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.
    - tedunangst 16y ago
      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.
hysterix 16y ago
Company? Hell, government, military, it goes on and on how many vulnerable networks are out there.
- zolchy 16y ago
  Not in Britain, though, where there is no culture of carelessness: http://www.google.fi/search?q=british+lose+confidential+data http://www.google.fi/search?q=british+lose+confidential+data
gaius 16y ago
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 policies in the world are of no help if people simply refuse to follow them. The truth is passwords are not like toothbrushes - they don't actually need replacing every three months. Only if some event has occurred (e.g. a sysadmin leaving the company). They don't get weaker over time. Why not let someone keep the same decently strong password for as long as they're an employee? I guarantee this will be actually more secure.
- Sandman 16y ago
  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.
  - gaius 16y ago
    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.
  - count 16y ago
    Passwords historically got weaker over time, but not in the sense that 'if he got your password hes not going to wait to use it'. They weaken in their hashed form. It used to be (still is, really) trivial to score the passwd file of a system, and get all the hashes of passwords, but no plaintext. By changing passwords every N months, you eliminated the ability of someone to crack the hashes and obtain a cleartext password where they previously only had a hash. That time window has gotten absurdly short, however...and with Pass the Hash and MITM, I don't even need your password anymore :(
- mjb 16y ago
cosmicray 16y ago
> It's just worse because they're a security company and they happened to piss off Anonymous. It's just worse because HBGary isn't eating their own dog food. Think about that.

waterlesscloud 16y ago

Wow. Did they do anything right? I can understand a typical organization making most of these mistakes, but a security firm?

m0nastic 16y ago
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 better) to actually rethink how your people/processes are implemented. This seems true for the largest banks in the world, and the smallest security firms. And it's easy to look back in hindsight and say "how could they have possibly had things set up that way?", but the truth is that this was not an opportunistic attack; if these vulnerabilities weren't present, then they'd have looked for others. That's the problem with securing your environment, you have to get everything right, and the attacker only has to get one thing right. That being said, as with most "disasters", this was a series of cascading failures (like most airplane crashes, or oil rig explosions). Hopefully they'll learn from this (assuming the negative fallout doesn't completely bankrupt the company).
- stcredzero 16y ago
  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!
  - t3chg1rl 16y ago
    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!

jmtame 16y ago

Good TLDR: "So what do we have in total? A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren't patched. And an astonishing willingness to hand out credentials over e-mail, even when the person asking for them should have realized something was up."

jgershen 16y ago

Very well written article - it does a terrific job of explaining things like rainbow tables for a non-technical (or at least, technically-but-not-security-minded) audience. The only part that seems off is the theme that /all/ of the exploited vulnerabilities were necessary to render HBGary vulnerable: "Even with the flawed usage of MD5, HBGary could have been safe..." They homebrewed their own password system. Can someone switch on the tptacek bat-signal?

there 16y ago
They homebrewed their own password system. the story says hbgary hired an outside company to make this cms for them, which may explain the crappy security on that particular system. Can someone switch on the tptacek bat-signal? thomas' security company also got hacked a couple years ago and had sensitive information plastered all over a mailing list. rumor was that it happened via their use of wordpress for their weblog. i guess the moral of the story is... you will get hacked by crappy third-party software?
- rdtsc 16y ago
  > 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, nobody would blame them, but they sell "security" and charge big bucks for it, so they deserve the ridicule. It is an interesting perspective I guess on selling "security", both as a service and a product. One can charge lots of money, but unless there is a serious attack and penetration, it is hard to know what the quality of they security product is. Of course once the penetration happened, there is at best pity and at worst ridicule and blame.
  - trotsky 16y ago
    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 software that will never have any vulnerabilities.

cookiecaper 16y ago

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.

askar_yu 16y ago
not sure how e-mail encryption would have helped... ? They SQL injected and got the DB, obtained the passwords and then proceeded further (social engineering: FW policy change, ssh password through e-mail, etc.)
- firebird84 16y ago
  If you protect your keys well enough, you can protect the content of your emails. If they're stored on an IMAP server, downloading them will do you no good without the keys. Additionally, compromising a single machine may only yield the key to some subset of a company's emails.
- cookiecaper 16y ago
  It would help because the private keys needed to decrypt the emails would not have been kept on the server, and, even if they were, they'd still need a passphrase to get the content of the private key (though, it could have been the same insecure passphrase used elsewhere). Also, a common policy of encrypting and signing emails would have stopped the social engineering attack completely, as the sysadmin would've known not to accept an unsigned request to give out passwords. Kind of mind boggling that people don't do this generally already.
iuguy 16y ago
> 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.

dantheman 16y ago

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.

chopsueyar 16y ago
Shouldn't this be the standard, not the exception?
jokermatt999 16y ago
Ars Technica regularly comes out with good pieces like this. Out of all the tech news sites I've seen, they're generally the most professional (other than their photoshopped story images; those usually go for humor) and thorough in their coverage.
taylorbuley 16y ago
Noted!

OoTheNigerian 16y ago

I just took an introductory course in web security. This explained many terminologies that fly over my head on HN.

wh-uws 16y ago

SQL injection and MD5... on a "security" company? In 2011? I'm sorry but thats just egregious. Thats like being a bodyguard and not even putting a lock on your own house. The rest of the attacks could have happened to anyone. We all know its best practice to use many different passwords but most don't because its more convenient to only have one or a few. And if the email is coming from the email address it should you could brain fart and give up the info without thinking. But the first two parts of the attack should NOT have been possible for them to even pretend to call themselves a computer "security" firm in 2011

hysterix 16y ago
You are completely wrong to justify people using the same passwords in multiple places because it is convenient.
- RyanMcGreal 16y ago
  Understanding a behaviour isn't the same as justifying it.

CaptainZapp 16y ago

HBGary used Google Apps for its e-mail services So, this high flying super duper high tech hardcore company actually uses an external email provider for their (I suppose) super secret emails? The more I learn about this incident the more Mr. Barr and HBGary look like a bunch of amateurish dolts that may give good power point presentations, but I for one sure wouldn't take my security business there.

iuguy 16y ago
We use Google Apps for our e-mail and we're a security company not entirely dissimilar to HBGary (the main company, not federal, and in terms of services, not practices). We moved to Google Apps as they bought Postini. We had an adult discussion of the benefits and drawbacks, and as everyone had PGP made it a straightforward job of encrypting things according to policy. Google Apps (for business, at least) offers SSL encryption on everything and offers relatively little by way of additional risk compared to using someone like messagelabs for your AV. Obviously they're storing the data for you, but you'd get that with any hosted provider.

trotsky 16y ago

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.

gaius 16y ago
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 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.

Splines 16y ago

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?])

weego 16y ago
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.
nikcub 16y ago
root passwords shouldn't get you far though. I once published all my root passwords on IRC as a challenge and didn't change them for a few weeks. Nothing happen.

ahrens 16y ago

<rant>As others have said, the most serious thing is that it is a security company, and they seem to have ignored EVERY security best practice ever! Did they do anything right? As a security specialist myself, I always do my very best to follow best practices, not only to protect myself, but to show others that I am willing to follow my own advice. I have met security people doing presentations that need to elevate to admin, and they are logged in as admin already. Sometimes even with UAC turned off. This completelly shatters my confidence in them. I am always logged in as normal user and have long (20+) passwords, and make sure people see that I have long passwords. I don't hold others to the same standard, but I know people. If they see that I use 20+ characters, they will not think that the 10 that I want them to use is that bad. This is the way the security landscape should work. We should all set ourselves to much higher standards than the advice we give others. We should always follow up on it. We KNOW lazyness will cause breaches, so therefore we should never be lazy when it comes to security. For a security company - and especially the president - to have such low security lowers the confidence for the whole industry. Yes, security is asymmetric. That is why companies must always follow at least the recommended best practices. If they are followed, the target might be too hard to break into and a hacker might go someplace else where it's easier to break in. Targeted attackers might still get it, but we should all make sure they have to work DAMN hard to succeed! If we start thinking that the attackars will succeed anyway, we might as well drop all defences. Display the admin passwords at the bottom of the "About us"-pages. Bottom line, HBgary fucked up good. They showed the world that they give advice that they don't follow. They deserve the burn and anybody thinking about hiring them should think again. Even if they change the problems that allowed this breach, the basic problem is that they obviously don't understand security. If they did, none of this would have happened. </end rant>

iuguy 16y ago

This is a very well written summary of how it all went down. From this, we can conclude: * An initial entry point through SQL injection (from which we can infer that the federal site was probably never security tested) * The use and re-use of weak administrative passwords * The adoption of poor practices (such as sending passwords in cleartext via email) at rootkit.com Of all of these, the attack would've probably been limited to the federal site had Aaron used decent strength administrative passwords (or just not reused them). The issue regarding the website comes down to risk ownership. If Aaron Barr was the risk owner for the website, it falls down to him. If in his contracting the company, Aaron had a plan to test the website then whomever tested it missed the SQL injection (which could've been implemented after a test by the CMS firm without him knowing, or any number of things). If Aaron didn't have a plan to get the site checked out, then that's both strikes falling on his shoulders. The third strike is quite clearly stirring the hornets nest. Moral of the story: Don't antagonise groups that will strike back without a plan to deal with it. Moral #2: Don't reuse passwords. Moral #3: Retest your app on every significant change (including initial deployment).

bane 16y ago

Relevant: http://news.ycombinator.com/item?id=2227181 http://news.ycombinator.com/item?id=2227181

djm 16y ago

FYI, it looks like Anonymous is aiming for total humiliation as far as HBG is concerned - they have even set up a pretty web interface/search for the entire collection of stolen emails - see http://hbgary.anonleaks.ru/ http://hbgary.anonleaks.ru/