Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security

Anatomy of the HBGary Hack 220

PCM2 writes "Recently, Anonymous took down the Web sites of network security firm HBGary. Ars Technica has the scoop on how it happened. Turns out it wasn't any one vulnerability, but a perfect storm of SQL injection, weak passwords, weak encryption, password re-use, unpatched servers, and social engineering. The full story will make you wince — but how many of these mistakes is your company making?"
This discussion has been archived. No new comments can be posted.

Anatomy of the HBGary Hack

Comments Filter:
  • Awesome (Score:5, Funny)

    by cs668 ( 89484 ) <cservin@crom[ ]on.com ['agn' in gap]> on Wednesday February 16, 2011 @09:52PM (#35227952)

    The story of their being hacked and how it was done has probably done more for systems security than they as a company ever have......

    • by naz404 ( 1282810 ) on Wednesday February 16, 2011 @10:00PM (#35227998) Homepage
      Looks like they got taken out by Little Bobby Tables...

      http://xkcd.com/327 [xkcd.com]
      • Comment removed based on user account deletion
        • Re: (Score:2, Informative)

          by Anonymous Coward

          You're missing something.

          http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27

          Obviously the 2 and the 27 are not being validated before being appended into part of a larger SQL query, so construct your own URL substituting 2 (or 27) with something like 2';show tables; --

          Find the one that looks like it contains user login information and then substitute again with 2';select * from user_table; --

          Hey presto, you can now read all the user accounts and hashed passwords.

        • They are giving you the original URL where the injection was used, not a link to the actual injection.

          They probably replaced some of those parameters with the injection code.

          page is probably how many results per page they want, and pageNav is what page they want, so probably page landed straight into a LIMIT in a sql query, without any kind of treatment. Most likely, just passing that crap through mysql_real_escape_string() would have been enough.

          • or if you're expecting a number run it through something like parseInt() first. How hard is that?!

          • They are giving you the original URL where the injection was used, not a link to the actual injection.

            They probably replaced some of those parameters with the injection code.

            page is probably how many results per page they want, and pageNav is what page they want, so probably page landed straight into a LIMIT in a sql query, without any kind of treatment. Most likely, just passing that crap through mysql_real_escape_string() would have been enough.

            In the case of this both of those parameters should be restricted to being numeric only. This should be done as soon as the page reads the values from the querystring. On top of this they could use PDO or some other kind of prepared statements to provide a further level of security.

            Lets not restart the argument with Jamie about prepared statements being the only way of doing things :)

        • Forgive my lack of terminology; I know next to nothing of databases anymore. MSAccess was forced on me at college, and know nothing to speak of SQL.

          One of those passed parameters was passed directly to an SQL query, with no validation or sanitation whatsoever. Turning "...&page=27" into '...&page="; DROP TABLE (FOO);' or somesuch would result in the whole query being executed.

          Look for the XKCD on "Bobby Tables" for a better example. Again, I know next to nothing of the exact methods involved. It's
      • You can't mention SQL injection without reading this awesome thread [thedailywtf.com] on TDWTF.
      • by arivanov ( 12034 )

        No, it is from a different cartoon.

        The name of the company is not HBGary. It is HBGary Federal.

        Nuff said. No further comment necessary.

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Thursday February 17, 2011 @03:25AM (#35229706)
      Comment removed based on user account deletion
  • by jesseck ( 942036 ) on Wednesday February 16, 2011 @09:56PM (#35227970)
    I've been following this since I heard of it happening- definitely interesting. I like the idea of a custom CMS to avoid an open one (more security). And the poor admin who gave out root, dropped firewalls, and gave up the correct username all via email- that's a bummer. I bet that will be among his "worse day ever" collection. As for shared passwords, I'm sure a lot of us work at guilty companies. Hell, active directory exists partially to address the need for multiple passwords. In all, I enjoyed reading how it was done- quick, efficient work.
    • by NevarMore ( 248971 ) on Wednesday February 16, 2011 @10:17PM (#35228080) Homepage Journal

      I like the idea of a custom CMS to avoid an open one (more security).

      Its far easier to audit existing code than it is to build your own code. Even if you write it yourself you have to do the same auditing and testing that you would against an existing product.

      • A custom CMS isn't a bad thing is you commit hard to securing it.

        For various reasons, I've built custom CMSes. What I've committed to doing is limiting the accepted inputs. If something only needs an ID, then the inputs should be scrubbed down to only accept integers. If something only needs a name, scrub the inputs down to a regular expression covering letters, spaces and integers.

        Where people get in trouble is not scrubbing their input aggressively.

        • by mcvos ( 645701 )

          For various reasons, I've built custom CMSes. What I've committed to doing is limiting the accepted inputs. If something only needs an ID, then the inputs should be scrubbed down to only accept integers. If something only needs a name, scrub the inputs down to a regular expression covering letters, spaces and integers.

          Where people get in trouble is not scrubbing their input aggressively.

          Scrubbing your input is the wrong approach. The fix for SQL-injection is really simple: use parametrized queries. If you always, always do that, you can accept any input, and it will never accidentally be interpreted as a query. Explicitly scrubbing your input makes it possible, and therefore likely, to forget something. Parametrized queries is the only way to go. Accept no exceptions.

          Unfortunately my bank seems to use input scrubbing for passwords, and that frightens me. It gives me the impression that the

      • Yes and no.

        With custom code that audit, should you bother, needs to happen once and then perhaps again when changes are made.

        An open CMS is likely a moving target. Depending on the code quality and the familiarity of the audit team, an audit probably is easier, but how long is that audit really good for? What do you do when you KNOW you are running an insecure version as a hole has been found, but are not in a position to upgrade and re-audit the entire CMS? Do you get paid to keep the software updated to t

    • by nodwick ( 716348 ) on Wednesday February 16, 2011 @10:23PM (#35228102)

      I've been following this since I heard of it happening- definitely interesting. I like the idea of a custom CMS to avoid an open one (more security).

      Sadly the moral of the story is the exact opposite - the custom CMS HBGary commissioned was actually less secure, as it appears not to have been subjected to proper security audits, nor was it being updated to patch discovered bugs. Direct from TFA:

      Rather than using an off-the-shelf CMS (of which there are many, used in the many blogs and news sites that exist on the Web), HBGary—for reasons best known to its staff—decided to commission a custom CMS system from a third-party developer. Unfortunately for HBGary, this third-party CMS was poorly written. In fact, it had what can only be described as a pretty gaping bug in it. A standard, off-the-shelf CMS would be no panacea in this regard—security flaws crop up in all of them from time to time—but it would have the advantage of many thousands of users and regular bugfixes, resulting in a much lesser chance of extant security flaws.

      The very thing you consider a disadvantage in an open software system - the fact that anyone can discover bugs in it - also helps ensure that such bugs are publicized and fixed. With HBGary's custom CMS, the bugs were still there, but the only people looking were the ones specifically trying to break into their system. There can be a case for code obscurity, but if that's all you're relying on to protect yourself, I'd say you're really just burying your head in the sand.

      • by DarkOx ( 621550 )

        Its also true that if you are willing to put the time and resources into developing your own CMS you could use those same resources to add whatever features you need and spend the rest of the time auditing and hardening and Open Source solution.

        There is some terrible Open Source software out there just becuase its open does not mean its secure but with little effort you could likely compile a list of open cms products with the features you need, then sort them by best security track record weighted by marke

    • by jamienk ( 62492 ) on Wednesday February 16, 2011 @10:42PM (#35228204)

      A non-custom CMS like WordPress is very often the target of massive automated attacks: a new bug is discovered in WP and a tool is written to seek out vulnerable installations and exploit that bug. If you have the skill or $$ to pour over the code, you can probably find your own bugs before they become publicly known.

      On the other hand, if your site is specifically targeted, then your custom CMS is as vulnerable or more than the WordPresses out there. You might have a bit of security through obscurity (in a standard WP install, the attacker might know file names and locations, variable names, classes, etc.) but this will probably do you little good if you weren't able to harden the code.

      Lesson: you are screwed if a rich, powerful, or smart attacker singles you out. A standard CMS can land you in hot water if you don't have a knowledgeable person administering it (and who has that?).

      • A custom CMS will protect you against most automated attacks against a "generic" CMS. But it will leave you more vulnerable to directed attacks, which is what happened here.

        • by jamienk ( 62492 )

          But if you are vulnerable to automated attacks, then you most certainly are also vulnerable to directed attacks, no? The attacker can just use a known (or new) attack against WordPress once they see that that is what you are running:

          "Aha! From the Meta Tags I can tell they're running WordPress. Looks like it's version X. I'll do a POST to site/wp-admin/tiny-mce/lang/en-us/takefile.php of a PHP script. If they didn't apply the patch that was released yesterday I should be able to upload my PHP script which w

          • Sure, but the idea is that you do apply the patch that was released yesterday at some point in the very near future, so you are only vulnerable for a short time period. So most of the time you there aren't any known vilnerabilities that make you vulnerable and the direct attacker likely isn't going to find one right now.

            • Another benefit of choosing the "generic" CMS solution is that even when a new exploit is discovered, it's highly unlikely that those in possession of such a valuable prize, a zero day vulnerability in a major CMS product, are going to waste in on a small security company like HBGary (high-profile antics of one ridiculously over the top CEO, Aaron Barr, not withstanding) or some random individual user. No, the exploit will be saved for a high value target or sold to the highest bidder. Writing your own CMS
              • Writing your own CMS from scratch and then exposing it to the public Internet is like writing your own "killer" encryption algorithm, it just shouldn't be done

                Uh oh! Guess I'm going to hell.

      • A non-custom CMS like WordPress is very often the target of massive automated attacks: a new bug is discovered in WP and a tool is written to seek out vulnerable installations and exploit that bug. If you have the skill or $$ to pour over the code, you can probably find your own bugs before they become publicly known

        Wordpress is a particularly bad example. There are a lot of features it supports that a custom CMS may not support that make security more difficult. It's not unreasonable to expect a custom

        • I think it's reasonable to expect the login security of Wordpress to be pretty hardened. The CMS that I wrote won't even do anything unless you've logged in first. I tried running skipfish on it after giving it a login account, and other than filling a few tables with failed attempts at SQL injections, it was fine. That's not to say it's 100% secure, or more secure than something like Wordpress though. I'd trust the system that's very public and likely subject to constant attacks more than my own one, which

    • by Ihmhi ( 1206036 ) <i_have_mental_health_issues@yahoo.com> on Wednesday February 16, 2011 @11:05PM (#35228306)

      What happened to HBGary is like a fire station burning down because the smoke alarms didn't work - you'd think they, of all people, would know better.

      • by benjamindees ( 441808 ) on Wednesday February 16, 2011 @11:33PM (#35228426) Homepage

        It's more like a fire station burning down because the fire chief was being paid by the mayor to make molotov cocktails and throw them at local teenagers and one day they decided to throw one back and instead of putting the fire out the firemen screamed and ran around in circles and poured gasoline on it and the fire station exploded. But, yeah.

        • Really. +1.
        • It's more like a fire station burning down because the fire chief was being paid by the mayor to make molotov cocktails and throw them at local teenagers and one day they decided to throw one back and instead of putting the fire out the firemen screamed and ran around in circles and poured gasoline on it and the fire station exploded. But, yeah.

          In a WWII test of bat delivered incendiaries, the bats set fire to the base's wooden water tower and other locations. Further development was canceled.

  • Mistakes (Score:5, Insightful)

    by codepunk ( 167897 ) on Wednesday February 16, 2011 @09:56PM (#35227974)

    But how many of these mistakes is your company making?

    Most companies probably make these mistakes, all except the biggest mistake which was poking a sleeping bear.

    • by mcvos ( 645701 )

      But how many of these mistakes is your company making?

      That's the important question here. And it wasn't any terribly advanced cracking that brought HBGary down. Apart from the bit where they gave a normal linux user superuser privileges through some exploit, I could have done every step of it myself. And I'm no security expert.

      A couple of really basic lessons here:
      * Always, always use parametrized queries. It makes your code cleaner, and it automatically protects against SQL-injection. There's no reason not to do this.
      * Always salt your hash. Yeah, I don't do

      • by mcvos ( 645701 )

        Forgot another important one: don't neglect to install the security patches for your OS.

  • The real mistake (Score:5, Insightful)

    by Fex303 ( 557896 ) on Wednesday February 16, 2011 @09:58PM (#35227986)

    The full story will make you wince — but how many of these mistakes is your company making?

    Well, we're not going after 4chan/anonymous, so we're probably in the clear.

    I think the biggest security mistake it's possible to make is antagonizing the largest collection of bored hackers/crackers/script kiddies/associated hangers on that exists.

    • by gosand ( 234100 )

      Well, to be fair - a COMPANY doesn't have to go after Anonymous... all it takes is one person, then the company may be held accountable. Can you control what every person in your company says or does? All it takes is one comment, one "published" opinion to set off vigilantes. Then how do you stop them?

  • Incompetent (Score:5, Insightful)

    by Anonymous Coward on Wednesday February 16, 2011 @10:00PM (#35228002)

    I'm just amazed at how completely oblivious "Chief Security Specialist" Jussi Jaakonaho was during the email correspondence, AND that he was perfectly fine with sharing root passwords via plaintext email.

    How do these people even get security jobs and be negligent in even the simplest security practices?

    • A quick Google reveals he apparently used to work for Nokia. First as a design engineer then as a 'Chief Security Specialist' (ether that or he is a Russian Guitarist).

      It has no record of his having moved to a new job. Perhaps this was his first day?

      He had reached his level of incompetence. I'm guessing he is now unemployed and very soon unemployable. Google hasn't indexed much of this yet.

      • I'd hire him with no problem and most probably for peanuts. He got so burned that the paranoia will be eating him alive from now on. Yes, you can learn all you want about good practices and whatnot but sometimes you need to get really hurt to actually LEARN.

        • by Caraig ( 186934 ) *

          Good observation. I went to SUNY Maritime College at about the time they hired Joe Hazlewood as an instructor. The man was probably the most exacting officer on a deck watch. Granted, he was conning a ship full of cadets that had a big-ass 'STUDENT DRIVER' sign on the stern kingpost, but he knew his stuff, and like you said, paranoia will be eating him alive any time he's aboard a ship.

    • Re:Incompetent (Score:5, Interesting)

      by jesseck ( 942036 ) on Wednesday February 16, 2011 @10:58PM (#35228280)
      I also wonder though, how much of that was brought on by the corporate culture. My boss doesn't know what SSH is, so him asking about it would be a red flag to me. But executives at HBGary may have used it all the time. And maybe the required root access frequently. All it takes is one previous time of Jussi refusing to pass that info out and resulting in a "we pay your ass, do it when I tell you to!" reprimand, and Jussi will have been changed by the corporate environment to jump when the COO or CEO says to via email. Poor security practices, definitely. But often corporate culture leads to these poor practices. Everyone tries to start out doing the right thing, but often push it aside in favor of "the easy way".
      • if people ask me for passwords/credit cards numbers/bank details via email, the first thing i do is find their phone number via external means, then phone them to verify their identity, then give them the information over the phone. How fucking hard is that to do, even if it is your boss asking for root access?
      • I also wonder though, how much of that was brought on by the corporate culture. My boss doesn't know what SSH is, so him asking about it would be a red flag to me. But executives at HBGary may have used it all the time. And maybe the required root access frequently.

        That is the one thing that was new to me and where I could have gone wrong myself (but then I'm not a security guy): The person imitating the boss _did_ have the root password. And you'd think that anyone who has the root password can be trusted because they have ultimate power over the machine anyway. They can _read_ and _change_ any user password, so you would think that giving them a user password shouldn't hurt. But the root password doesn't allow them access through SSL! A hacker with root password doe

      • All it takes is one previous time of Jussi refusing to pass that info out and resulting in a "we pay your ass, do it when I tell you to!" reprimand, and Jussi will have been changed by the corporate environment to jump when the COO or CEO says to via email.

        I haven't received a reprimand like that.

        But think about how you would want to go out? Would you rather be fired for not dishing out a password without verification? Or would you rather be fired for letting hackers into your systems and run amok? One scenario will make you look decent in an interview. The other will ensure no one in town will hire you.

        I've gone to bat about foreign workers sharing login ids. I would flat out refuse to reset their passwords. It happened alot. But I was backed up on my

    • Reading through some of this, I got the impression that the problem has a lot more to do with making those above you happy, than anything else.

      While Jussi's mistake was pretty damned boneheaded, how often do you do what your boss says, because they said so? Not from the perspective of "How I do my job right?", but "Will I get canned if I say no? I'm not going to tell my boss that he is too stupid to remember both his username and his password".

      Granted, at that point, I'd probably just tell them, "I'll give

  • And What's next? (Score:5, Insightful)

    by rueger ( 210566 ) * on Wednesday February 16, 2011 @10:06PM (#35228026) Homepage
    Gotta say, the linked article was a great education for me, one who's interested but never had time to dig into some of the arcana of stuff like SQL injection.

    In watching Wikileaks, OpenLeaks, Egypt, the Palestine papers,and now HB Gary, I'm thinking that we're at the edge of something monumental. I expect we'll see a lot more formerly secret data become public, and see governments and corporations either clean up their acts, or become increasing desperate and hostile in trying to keep their inside info secret.

    Either way we're in for a wild ride!
    • Well, a Wikileak (that's the term for something Wikileaks leaks, right?) was one of the things that started the Tunisian revolution, which led to the revolt in Egypt, and protests in Algeria, Libya, Yemen, and Bahrain, and it seems to be spreading further, as far away as Iran, and Jordan. Add the fact that some pretty major corporations are also being attacked (), and this could be on the scale of 1848. I'm willing to bet that this chain of uprisings won't stop before it reaches Russia and Italy, and I'm ho
      • by jrumney ( 197329 )

        ...Yemen, and Bahrain, and it seems to be spreading further, as far away as Iran, and Jordan.

        Jordan is much closer to Tunisia than Yemen and Bahrain.

        • by seyyah ( 986027 )

          Well look at the last comma. It sort of absolves him of being ignorant about the location of Jordan.

          It is an awkward sentence mind you.

    • That's the end goal Assange always envisaged for Wikileaks. He wanted to make governments either become more open, or become so inefficient due to the security needed to hold their secrets, that Darwin would see them replaced with a more open one.

      Was talked about in one of the interviews he gave.

    • A great meaning for a 'hack', one often undermentioned in the media, is to investigate, learn, and then use something in a way that it was not intended to be used. This does not even require exploiting the system or changing it in any way. Its the result of lateral thinking and curiosity.

      You may enjoy hacking Google searches, it gives great insight into how their search engine operates, and you end up using these techniques to pinpoint your searches amazingly well sometimes!

      Check it out: http://www.hackersf [hackersforcharity.org]

    • I'm thinking that we're at the edge of something monumental.

      It reminds me of Project Mayhem. [wikipedia.org]

  • Attack Summary (Score:4, Informative)

    by Anonymous Coward on Wednesday February 16, 2011 @10:14PM (#35228068)
    1. SQL Injection

      The exact URL used to break into hbgaryfederal.com was http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 [hbgaryfederal.com]. The URL has two parameters named pageNav and page, set to the values 2 and 27, respectively. One or other or both of these was handled incorrectly by the CMS...

    2. Password Hashes didn't use salts etc.
    3. Password hashing was done using MD5.
    4. Password complexity policy was crap anyway.
    5. Password recovery policy was vulnerable to social engineering (insider attack).
    • You forgot the part where the CEO of HBGFed used the same six letter pass in the CMS, his email, twitter, facebook...

      Basically step 4->5 went lousy password to same password used for the email admin to another user's email account to the social engineering.

    • 6. After targetting Anonymous they didn't invest in curtains.

      7. After targetting Anonymous they didn't invest in a dog.

      Surely they saw the FOX11 story on Anonymous when checking out the background of their quarry?

    • This is especially shocking, as MD5 has had known vulnerabilities since 1996! [wikipedia.org]

      Any person worth their salt should know better! :-D

      Methinks the CMS designers should don their Drainpipe pants, Canvas Shoes and Rubber Bracelets, and catch the next plane to 10 years into the future.

  • by RelaxedTension ( 914174 ) on Wednesday February 16, 2011 @10:34PM (#35228158)
    They are the Tacoma Narrows bridge of the IT security world now. They will be the textbook case example of the generations of students, with the entire repertoire of what not to do every step of the way, especially the one about not pissing-off a malevolent, anonymous mass.
  • ... and look at this as a layman.
    OK, they chose a closed/custom CMS in hopes of security through obscurity, fair enough.
    Ok, the guy thought he was talking to the boss and gave away the credentials, fair enough.

    But how the HELL did they thought that such weak passwords, an out-of-date system and no SSH keys were fine?
    Granted that all of their mistakes look unforgivable to me since I'm in the business but I simply can't wrap my head around the ones I mentioned.

    Strong passwords aren't an inconvenience,
    • You shouldn't ever let your browser store passwords.......

      • You shouldn't ever let your browser store passwords.......

        Why not? I let my computer store my passwords.

        I have to unlock the key-ring with my master password; I drop access rights to the key-ring when I'm done "entering" the stored password; The passwords are encrypted while stored. What's the big deal? Don't all modern operating systems have this feature?

        Is the issue, "Single point of failure"? I have a strong 23 character master password. It's much easier to remember than 30 different variable length passwords, and no less secure than a keyed/salted pass

        • As long as your key is backed up, you're good to go. Ignore the ney-sayers.
        • No folly there.

          The first thing I did, after Google Chrome came out, was go through the source code to see how it encrypts saved passwords.

          Before using Firefox password saving feature, with a master password, I researched what techniques there are to brute force it open, and which password combinations are the most secure. I even bruted my own key file (with no important saved passwords btw) as a test.

          I then chose a password with a complexity to match my own educated guess.

          From my view, I'm pretty comfortabl

    • by AHuxley ( 892839 )
      Classic MS like group think? With the US and UK .gov..edu .com crypto circles they lived in/sold to ... whats to worry about?
      A very MS focused team to offer deep MS related solutions?
    • Not all sites let you use browser stored passwords.
      • by Tukz ( 664339 )

        Like /.

        I have to click login, then login without credentials, to be taken to the "wrong password" page, where it DOES work.

  • by Greyfox ( 87712 ) on Thursday February 17, 2011 @01:43AM (#35229224) Homepage Journal
    I think the big one is my CEO ain't talking shit about a bunch of hackers who are better at it than him.
  • by dave562 ( 969951 ) on Thursday February 17, 2011 @02:50AM (#35229544) Journal

    It's on par with what Sterling wrote in The Hacker Crackdown.

  • .. a perfect storm of SQL injection, weak passwords, weak encryption, password re-use, unpatched servers, and social engineering.

    Not the people I would go to for security advice

  • this is the accepted way for a lot of places to transfer credentials.  I'm really surprised a place like HBGary did the same.  It was a long time coming if this is SOP for them.

    http://dazzlepod.com/site_media/txt/rootkit.com.txt

"Trust me. I know what I'm doing." -- Sledge Hammer

Working...