Part 2 (2/2)

I can and have gained access to various government and government contractor groups in the social media s.p.a.ce using this technique (more detailed but you get the point). Given that people work from home, access home services from work-getting access to the target is just a matter of time and nominal effort.

Knowing about a target's spouse and college and business and friends makes it relatively easy to engage in a ”spear phis.h.i.+ng” attack against that person-say, a fake e-mail from an old friend, in which the target eventually reveals useful information.

Ironically, when Anonymous later commandeered Greg Hoglund's separate security site rootkit.com, it did so through a spear phis.h.i.+ng e-mail attack on Hoglund's site administrator-who promptly turned off the site's defenses and issued a new pa.s.sword (”Changeme123”) for a user he believed was Hoglund. Minutes later, the site was compromised.

After the Anonymous attacks and the release of Barr's e-mails, his partners furiously distanced themselves from Barr's work. Palantir CEO Dr. Alex Karp wrote, ”We do not provide-nor do we have any plans to develop-offensive cyber capabilities... The right to free speech and the right to privacy are critical to a flouris.h.i.+ng democracy. From its inception, Palantir Technologies has supported these ideals and demonstrated a commitment to building software that protects privacy and civil liberties. Furthermore, personally and on behalf of the entire company, I want to publicly apologize to progressive organizations in general, and Mr. Greenwald in particular, for any involvement that we may have had in these matters.”

Berico said (PDF) that it ”does not condone or support any effort that proactively targets American firms, organizations or individuals. We find such actions reprehensible and are deeply committed to partnering with the best companies in our industry that share our core values. Therefore, we have discontinued all ties with HBGary Federal.” (PDF) that it ”does not condone or support any effort that proactively targets American firms, organizations or individuals. We find such actions reprehensible and are deeply committed to partnering with the best companies in our industry that share our core values. Therefore, we have discontinued all ties with HBGary Federal.”

But both of the Team Themis leads at these companies knew exactly what was being proposed (such knowledge may not have run to the top). They saw Barr's e-mails, and they used his work. His ideas on attacking WikiLeaks made it almost verbatim into a Palantir slide about ”proactive tactics.”

And Palantir had no problem sc.r.a.ping tweets from union supporters and creating linkages from them.

As for targeting American organizations, it was a Berico a.n.a.lyst who sent out the Team Themis ”sample reports,” the doc.u.ments suggesting that the US Chamber of Commerce create false doc.u.ments and false personae in its effort to ”discredit the organization” US Chamber Watch.

The US Chamber of Commerce expressed shock when the Team Themis work came to light. ”We're incredulous that anyone would attempt to a.s.sociate such activities with the Chamber as we've seen today from the Center for American Progress,” said Tom Collamore on February 10. ”The security firm referenced by ThinkProgress was not hired by the Chamber or by anyone else on the Chamber's behalf. We have never seen the doc.u.ment in question nor has it ever been discussed with us.” on February 10. ”The security firm referenced by ThinkProgress was not hired by the Chamber or by anyone else on the Chamber's behalf. We have never seen the doc.u.ment in question nor has it ever been discussed with us.”

Indeed, the meeting between H&W and the Chamber on this issue was set to take place today, February 14. On February 11, the Chamber went further, issuing a new statement saying that ”it never hired or solicited proposals from HBGary, Palantir or Berico, the security firms being talked about on the Web... The leaked e-mails appear to show that HBGary was willing to propose questionable actions in an attempt to drum up business, but the Chamber was not aware of these proposals until HBGary's e-mails leaked.” saying that ”it never hired or solicited proposals from HBGary, Palantir or Berico, the security firms being talked about on the Web... The leaked e-mails appear to show that HBGary was willing to propose questionable actions in an attempt to drum up business, but the Chamber was not aware of these proposals until HBGary's e-mails leaked.”

”No money, for any purpose, was paid to any of those three private security firms by the Chamber, or by anyone on behalf of the Chamber, including Hunton & Williams.”

As for Hunton & Williams, they have yet to comment publicly. On February 7, however, the firm celebrated its top ranking in Computerworld's report on ”Best Privacy Advisers.”

It has been an embarra.s.sing week for security firm HBGary and its HBGary Federal offshoot. HBGary Federal CEO Aaron Barr thought he had unmasked the hacker hordes of Anonymous and was preparing to name and shame those responsible for co-ordinating the group's actions, including the denial-of-service attacks that hit MasterCard, Visa, and other perceived enemies of WikiLeaks late last year. and was preparing to name and shame those responsible for co-ordinating the group's actions, including the denial-of-service attacks that hit MasterCard, Visa, and other perceived enemies of WikiLeaks late last year.

When Barr told one of those he believed to be an Anonymous ringleader about his forthcoming expose, the Anonymous response was swift and humiliating. HBGary's servers were broken into, its e-mails pillaged and published to the world, its data destroyed, and its website defaced. As an added bonus, a second site owned and operated by Greg Hoglund, owner of HBGary, was taken offline and the user registration database published. one of those he believed to be an Anonymous ringleader about his forthcoming expose, the Anonymous response was swift and humiliating. HBGary's servers were broken into, its e-mails pillaged and published to the world, its data destroyed, and its website defaced. As an added bonus, a second site owned and operated by Greg Hoglund, owner of HBGary, was taken offline and the user registration database published.

Over the last week, I've talked to some of those who partic.i.p.ated in the HBGary hack to learn in detail how they penetrated HBGary's defenses and gave the company such a stunning black eye-and what the HBGary example means for the rest of us mere mortals who use the Internet.

Anonymous: more than kids HBGary and HBGary Federal position themselves as experts in computer security. The companies offer both software and services to both the public and private sectors. On the software side, HBGary has a range of computer forensics and malware a.n.a.lysis tools to enable the detection, isolation, and a.n.a.lysis of worms, viruses, and trojans. On the services side, it offers expertise in implementing intrusion detection systems and secure networking, and performs vulnerability a.s.sessment and penetration testing of systems and software. A variety of three letter agencies, including the NSA, appeared to be in regular contact with the HBGary companies, as did Interpol, and HBGary also worked with well-known security firm McAfee. At one time, even Apple expressed an interest in the company's products or services.

Greg Hoglund's rootkit.com is a respected resource for discussion and a.n.a.lysis of rootkits (software that tampers with operating systems at a low level to evade detection) and related technology; over the years, his site has been targeted by disgruntled hackers aggrieved that their wares have been discussed, dissected, and often disparaged as badly written bits of code.

One might think that such an esteemed organization would prove an insurmountable challenge for a bunch of disaffected kids to hack. World-renowned, government-recognized experts against Anonymous? HBGary should be able to take their efforts in stride.

Unfortunately for HBGary, neither the characterization of Anonymous nor the a.s.sumption of competence on the security company's part are accurate, as the story of how HBGary was hacked will make clear.

Anonymous is adiverse bunch: though they tend to be younger rather than older, their age group spans decades. Some may still be in school, but many others are gainfully employed office-workers, software developers, or IT support technicians, among other things. With that diversity in age and experience comes a diversity of expertise and ability.

It's true that most of the operations performed under the Anonymous branding have been relatively unsophisticated, albeit effective: the attacks made on MasterCard and others were distributed denial-of-service attacks using a modified version of the Low Orbit Ion Cannon (LOIC) load-testing tool. The modified LOIC enables the creation of large botnets that each user opts into: the software can be configured to take its instructions from connections to Internet relay chat (IRC) chat servers, allowing attack organizers to remotely control hundreds of slave machines and hence control large-scale attacks that can readily knock websites offline.

According to the leaked e-mails, Aaron Barr believed that HBGary's website was itself subject to a denial-of-service attack shortly after he exposed himself to someone he believed to be a top Anonymous leader. But the person I spoke to about this denied any involvement in such an attack. Which is not to say that the attack didn't happen-simply that this person didn't know about or partic.i.p.ate in it. In any case, the Anonymous plans were more advanced than a brute force DDoS.

Time for an injection HBGary Federal's website, hbgaryfederal.com, was powered by a content management system (CMS). CMSes are a common component of content-driven sites; they make it easy to add and update content to the site without having to mess about with HTML and making sure everything gets linked up and so on and so forth. 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 custom solution on HBGary's site, alas, appeared to lack this kind of support. And if HBGary conducted any kind of vulnerability a.s.sessment of the software-which is, after all, one of the services the company offers-then its a.s.sessment overlooked a substantial flaw.

The hbgaryfederal.com CMS was susceptible to a kind of attack called SQL injection. In common with other CMSes, the hbgaryfederal.com CMS stores its data in an SQL database, retrieving data from that database with suitable queries. Some queries are fixed-an integral part of the CMS application itself. Others, however, need parameters. For example, a query to retrieve an article from the CMS will generally need a parameter corresponding to the article ID number. These parameters are, in turn, generally pa.s.sed from the Web front-end to the CMS.

SQL injection is possible when the code that deals with these parameters is faulty. Many applications join the parameters from the Web front-end with hard-coded queries, then pa.s.s the whole concatenated lot to the database. Often, they do this without verifying the validity of those parameters. This exposes the systems to SQL injection. Attackers can pa.s.s in specially crafted parameters that cause the database to execute queries of the attackers' own choosing.

The exact URL used to break into hbgaryfederal.com was /pages.php?pageNav=2&page=27. 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, allowing the hackers to retrieve data from the database that they shouldn't have been able to get.

Rainbow tables Specifically, the attackers grabbed the user database from the CMS-the list of usernames, e-mail addresses, and pa.s.sword hashes for the HBGary employees authorized to make changes to the CMS. In spite of the rudimentary SQL injection flaw, the designers of the CMS system were not completely oblivious to security best practices; the user database did not store plain readable pa.s.swords. It stored only hashed pa.s.swords-pa.s.swords that have been mathematically processed with a hash function to yield a number from which the original pa.s.sword can't be deciphered. to yield a number from which the original pa.s.sword can't be deciphered.

The key part is that you can't go backwards-you can't take the hash value and convert it back into a pa.s.sword.With a hash algorithm, traditionally the only way to figure out the original pa.s.sword was to try every single possible pa.s.sword in turn, and see which one matched the hash value you have. So, one would try ”a,” then ”b,” then ”c”... then ”z,” then ”aa,” ”ab,” and so on and so forth.

To make this more difficult, hash algorithms are often quite slow (deliberately), and users are encouraged to use long pa.s.swords which mix lower case, upper case, numbers, and symbols, so that these brute force attacks have to try even more potential pa.s.swords until they find the right one. Given the number of pa.s.swords to try, and the slowness of hash algorithms, this normally takes a very long time. Pa.s.sword cracking software to perform this kind of brute force attack has long been available, but its success at cracking complex pa.s.swords is low.

However, a technique first published in 2003 (itself a refinement of a technique described in (itself a refinement of a technique described in 1980) gave pa.s.sword crackers an alternative approach. By pre-computing large sets of data and generating what are known as rainbow tables, the attackers can make a trade-off: they get much faster pa.s.sword cracks in return for using much more s.p.a.ce. The rainbow table lets the pa.s.sword cracker pre-compute and store a large number of hash values and the pa.s.swords that generated them. An attacker can then look up the hash value that they are interested in and see if it's in the table. If it is, they can then read out the pa.s.sword.

To make cracking harder, good pa.s.sword hash implementations will use a couple of additional techniques. The first is iterative has.h.i.+ng: simply put, the output of the hash function is itself hashed with the hash function, and this process is repeated thousands of times. This makes the has.h.i.+ng process considerably slower, hindering both brute-force attacks and rainbow table generation.

The second technique is salting; a small amount of random data is added to the pa.s.sword before has.h.i.+ng it, greatly expanding the size of rainbow table that would be required to get the pa.s.sword.

In principle, any hash function can be used to generate rainbow tables. However, it takes more time to generate rainbow tables for slow hash functions than it does for fast ones, and hash functions that produce a short hash value require less storage than ones that produce long hash values. So in practice, only a few hash algorithms have widely available rainbow table software available. The best known and most widely supported of these is probably MD5, which is quick to compute and produces an output that is only 128 bits (16 bytes) per hash. These factors together make it particularly vulnerable to rainbow table attacks. A number of software projects exist that allow the generation or downloading of MD5 rainbow tables, and their subsequent use to crack pa.s.swords. exist that allow the generation or downloading of MD5 rainbow tables, and their subsequent use to crack pa.s.swords.

As luck would have it, the hbgaryfederal.com CMS used MD5. What's worse is that it used MD5 badly: there was no iterative has.h.i.+ng and no salting. The result was that the downloaded pa.s.swords were highly susceptible to rainbow table-based attacks, performed using a rainbow table-based pa.s.sword cracking website. And so this is precisely what the attackers did; they used a rainbow table cracking tool to crack the hbgaryfederal.com CMS pa.s.swords.

Even with the flawed usage of MD5, HBGary could have been safe thanks to a key limitation of rainbow tables: each table only spans a given ”pattern” for the pa.s.sword. So for example, some tables may support ”pa.s.swords of 1-8 characters made of a mix of lower case and numbers,” while other can handle only ”pa.s.swords of 1-12 characters using upper case only.”

A pa.s.sword that uses the full range of the standard 95 typeable characters (upper and lower case letters, numbers, and the standard symbols found on a keyboard) and which is unusually long (say, 14 or more characters) is unlikely to be found in a rainbow table, because the rainbow table required for such pa.s.swords will be too big and take too long to generate.

Alas, two HBGary Federal employees-CEO Aaron Barr and COO Ted Vera-used pa.s.swords that were very simple; each was just six lower case letters and two numbers. Such simple combinations are likely to be found in any respectable rainbow table, and so it was that their pa.s.swords were trivially compromised.

For a security company to use a CMS that was so flawed is remarkable. Improper handling of pa.s.swords-iterative has.h.i.+ng, using salts and slow algorithms-and lack of protection against SQL injection attacks are basic errors. Their system did not fall prey to some subtle, complex issue: it was broken into with basic, well-known techniques. And though not all the pa.s.swords were retrieved through the rainbow tables, two were, because they were so poorly chosen.

HBGary owner Penny Leavy said in a later IRC chat with Anonymous that the company responsible for implementing the CMS has since been fired.

Pa.s.sword problems Still, badly chosen pa.s.swords aren't such a big deal, are they? They might have allowed someone to deface the hbgaryfederal.com website-admittedly embarra.s.sing-but since everybody knows that you shouldn't reuse pa.s.swords across different systems, that should have been the extent of the damage, surely?

Unfortunately for HBGary Federal, it was not. Neither Aaron nor Ted followed best practices. Instead, they used the same pa.s.sword in a whole bunch of different places, including e-mail, Twitter accounts, and LinkedIn. For both men, the pa.s.swords allowed retrieval of e-mail. However, that was not all they revealed. Let's start with Ted's pa.s.sword first.

Along with its webserver, HBGary had a Linux machine, support.hbgary.com, on which many HBGary employees had sh.e.l.l accounts with ssh access, each with a pa.s.sword used to authenticate the user. One of these employees was Ted Vera, and his ssh pa.s.sword was identical to the cracked pa.s.sword he used in the CMS. This gave the hackers immediate access to the support machine.

ssh doesn't have to use pa.s.swords for authentication. Pa.s.swords are certainly common, but they're also susceptible to this kind of problem (among others). To combat this, many organizations and users, particularly those with security concerns, do not use pa.s.swords for ssh authentication. Instead, they use public key cryptography: each user has a key made up of a private part and a public part. The public part is a.s.sociated with their account, and the private part is kept, well, private. ssh then uses these two keys to authenticate the user.

Since these private keys are not as easily compromised as pa.s.swords-servers don't store them, and in fact they never leave the client machine-and aren't readily re-used (one set of keys might be used to authenticate with several servers, but they can't be used to log in to a website, say), they are a much more secure option. Had they been used for HBGary's server, it would have been safe. But they weren't, so it wasn't.

Although attackers could log on to this machine, the ability to look around and break stuff was curtailed: Ted was only a regular non-superuser. Being restricted to a user account can be enormously confining on a Linux machine. It spoils all your fun; you can't read other users' data, you can't delete files you don't own, you can't cover up the evidence of your own break-in. It's a total downer for hackers.

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.

Exploitation of this flaw gave the Anonymous attackers full access to HBGary's system. It was then that they discovered many gigabytes of backups and research data, which they duly purged from the system.

<script>