Bad password advice

In the December issue of Computer Fraud & Security, an article by Prof Steven Furnell - ‘Assessing password guidance and enforcement on leading websites’ - presents some fascinating original research into the password practices of various leading websites - and also paints a somewhat worrying picture.

In the article, Prof Furnell, of the University of Plymouth, follows up on earlier research looking at how well (or otherwise) websites guide their users when picking passwords. Do they provide decent advice on what constitutes a strong password? And just how clever are those password strength meters?

It’s not pretty.

It’s not just that many of these websites continue to allow the selection of very weak passwords: there’s also the problem of inconsistency. One of the things I took away from this article is that password meters - those little graphic devices that purportedly show you how strong or how weak your chosen password is - are pretty meaningless. Every site uses different criteria for rating the password strength, so a word deemed ‘weak’ on one site might be hailed as ‘strong’ on another.

Even within a single website, the strength criteria seem inconsistent and weird. Passwords we, as infosecurity specialists, know to be weak are deemed acceptable. For example, WordPress rates ‘qw12’ as ‘Good’. Oh really? And even when sites deem a password as feeble, some of them will still let you use it - Furnell discovered that Twitter, Windows Live and Yahoo fall into this camp.

There are widely accepted criteria for determining the strength of a password - a mix of upper- and lowercase, the inclusion of numbers and special characters, the avoidance of dictionary words and length (because size does matter). But it seems that some websites will allow users to go against their own best interests by selecting weak passwords. Why?

One useful thing that hacktivist group LulzSec did for us is make available a number of databases containing real-world user login credentials. Trawling through these databases is enough to make an infosecurity specialist weep. Yes, ‘password’ really is still used as a password - a lot. The same goes for ‘qwerty’, ‘123456’ and all the other classics.

Organisations such as SANS have formulated password policies that provide useful guidance. In fact, you can find any number of policies online, developed by organisations for their own use and offered to others as a template. But is it time to collate password best practices into a formal standard that website operators might actually accept and implement - and perhaps even mandate its use on any website that holds personal data?

Of course, there is a danger inherent in standards - that they become outdated too quickly. Remember when we used to think that six-character passwords were acceptable? (According to Furnell’s research, some websites still think this.) Now that hackers can buy multiple GPUs in the cloud to run password crackers, an eight-character password is now too feeble. The other problem with standards is that, during their formulation, they are beaten to a pulp by committees and self-interested parties until they represent only a lowest common denominator.

But a standard accepted across the industry would at least be a starting point. And it should address not just what is an acceptable password (or, better, passphrase), but also what advice is given to users when choosing passwords. Again, Furnell’s research found that this is highly inconsistent and usually inadequate.

There have been too many breaches for us to regard website security a trivial matter. For example, we’ve witnessed a long litany of hijacked accounts on Twitter, whose primary advice on password choice seems to be limited to ‘make it tricky’, whatever that’s supposed to mean. Those strength meters may help give you a feeling of confidence, but because they give no clue as to why a password is considered strong, they don’t actually help users understand the principles at work. Smarter registration procedures would explain why dictionary words are bad, why you should a mix of character types. And sites should also encourage periodical password changes - not a single site I’m registered with does that.

Review: BackTrack 5 Wireless Penetration Testing

Vivek Ramachandran. Published by Packt Publishing (ISBN: 978-1-849515-58-0). Price: $49.99, 208pgs, paperback.

Backtrack 5 wireless pen-testingIt says something for the ubiquitious nature of wifi that this subject warrants a book to itself. Wireless networks are everywhere - some would argue they’re in too many places. And as we discuss in the article on pg.14 of this issue, the technologies that are supposed to secure wireless networks are proving not to be up to the task. Of course, that very insecurity is what makes this book possible. 

It also says something about the popularity of BackTrack that it’s Ramachandran’s platform of choice for this subject. This makes a lot of sense: BackTrack effectively provides a standardised reference platform with all the necessary tools either built in or easily available. This saves a lot of time and effort for the author who doesn’t need to go through endless pages of installation procedures.

For wireless pen-testing, you do need one other piece of equipment, and that’s a wifi adapter. Many laptops come with built-in devices, of course, but these are often Broadcom cards that can have issues with things like promiscuous mode. This book is based on an Alfa USB adapter which is cheap, easy to obtain worldwide and highly amenable to the tasks asked of it here. And Ramachandran guides you through setting up a lab network for testing the methods detailed here.

Once it’s got you set up, the book wastes no time in delving into a hands-on session with wireless networking. By page 29 you’re already sniffing packets. And that pretty much sets the tone for the rest of the book. The pace is fast and the emphasis is on actually doing it. You’re soon cracking WEP and WPA passwords, becoming an evil twin with MAC spoofing, setting up rogue access points and conducting man in the middle attacks. The book doesn’t just go for the easy scores, either: there’s a chapter on attacking WPA-Enterprise and Radius-based systems. All the way through there are lots of screengrabs, so you can see what should be happening on your screen.

This is an excellent tutorial in the current state of the art when it comes to hacking - or testing - wireless networks.

Available from Amazon.co.uk and Amazon.com.

Users are stupid

At the recent RSA Europe conference in London, security consultant Ira Winkler said something we’re not supposed to utter. To paraphrase, he said: “Users are stupid”.

We all know that computer users do stupid things. Infosecurity professionals within organisations must despair every time they hear, “Well, I clicked on the link because…” or “I gave him my password because…” followed by any one of a score of lame excuses.

Winkler was talking in the context of social engineering, which he believes is too broadly defined. True social engineering, he says, involves interaction between attacker and victim. Something like a phishing attack, or an email with a malicious payload, does not count. Talking about the infamous I Love You virus, Winkler said: “Nobody wants to say, ‘well it’s not really social engineering because you’re not interacting with the person, it’s just stupidity. But oh no, you can’t blame the user and call them stupid.’ Yes, you can blame the users and call them stupid.”

We all know that even the best security technologies, processes and policies can be undermined by people doing things they shouldn’t. Yet, except in cases of egregious lapses, or the clear and wilful breaking of the rules, we’re not meant to point the finger at user stupidity.

Infosecurity specialists and departments are meant to provide the infrastructure and training to protect the organisation, and this shouldn’t be dependent on the intelligence of end users. Similarly, security vendors are selling the technology and services, and aren’t about to accuse their customers of being staffed by morons. Even pen-testers can’t say users are stupid because no client wants to hear, “well your security systems are fine: the problem is that you hired idiots”.

Of course, none of this is meant to suggest that ALL users are stupid – not even most of them. But even smart people do dumb things from time to time and you only need one moment of weakness to open a security vulnerability. Just ask RSA.

So perhaps it’s a matter of degree. Winkler’s issue with the vagueness of the term ‘social engineering’ is that it makes it difficult to combat. You can’t form any sensible or effective countermeasures against something so amorphous. “If you overly define stupidity as [a reason for] being a victim of social engineering,” he said, “you’re not going to stop social engineering.”

So maybe we need to break this down a tad, to differentiate between actions that might be excused because the person was a victim of a genuinely skilled social engineering attack – such as we’re seeing as part of Advanced Persistent Threats (APTs) – and behaviour that simply shouldn’t be tolerated because it is plainly idiotic.

Winkler relates the story of a senior exec at a bank, responsible for millions of dollars in trades, who had written down his password on a sticky note attached to his monitor. What Winkler found particularly stupid, however, was that the password was a reference to an obscure fact in an obscure episode of Star Trek. The exec was able to remember that fact, but wasn’t able to remember that he’d made it his password.

To be fair, what constitutes ‘plain stupid’ will be different for the general public or ordinary members of staff than it is for security professionals. We’d like to think that writing your password on a sticky note is self-evidently wrong. The same goes for opening dubious files attached to dodgy emails. But if experience teaches us anything it’s that people are easily fooled.

This is where training comes in, backed up by policies. At the same time, perhaps it’s time to stop being so polite and, where appropriate, start labelling certain behaviours as clearly ‘stupid’.

[This post is a version of the editorial in the November issue of Computer Fraud & Security]

Black Project: security, secrecy and conspiracy

Black ProjectI’ve always been fascinated by the weird things people choose to believe. Credulity is a powerful force - it is the foundation, after all, of social engineering.

And I love a good conspiracy theory. The wackier the better. There are few things more entertaining than watching people construct an complex argument that can be demolished in a moment with a swift flick of Occam’s Razor.

These are the things that inspired my new novel, Black Project.

One of the key characters is Dick Kennedy, the UFO reported for a rather dubious publication, the Weekly World Inquisitor. He yearns for contact with the numinous. He wants strange phenomena in his life. He wants to believe. But his intelligence keeps getting in the way.

The story also features Kate Macmillan, an engineer on secret government projects who has some rather dark secrets of her own. She winds up working at a base that makes Area 51 look like a theme park.

They both come into contact with something that speaks directly to their desires - and their nightmares. From there, things start descending into madness, chaos and farce.

There are conspiracies and weird beliefs galore. There’s a messianic fundamentalist President - a puppet for a sinister Vice President. There are soldiers on the streets of the US, not in Army uniform but that of a private firm of mercenaries. And all of this is played out against the backdrop of a society descending quickly into totalitarianism, mostly in the guise of customer service. Did I mention it’s funny?

And yes, there’s a tiny bit of hacking in there too.

Black Project is available in print, Kindle and Apple iBooks editions. You can also check out the first three chapters free here

Enjoy!

My feature from the Aug 2011 issue of Network Security.

Interview: Greg Hoglund - a fight-through capability

Greg HoglundThe recent RSA Europe conference in London was unusual. Some of the high-profile security firms exhibiting and presenting have also been victims of serious breaches this year.

RSA, rather notoriously, had its SecurID product compromised by what it insists were state-sponsored hackers. Raytheon admitted to a couple of breaches. And also present at the conference, both in the exhibition hall and in the form of founder & CEO Greg Hoglund, was security firm HBGary.

The assault on hacktivist movement Anonymous by subsidiary HBGary Federal made headlines - mostly because the subsequent backlash led to the breach of the company’s own defences, ultimately resulting in the resignation of CEO Aaron Barr.

Many were surprised when Hoglund engaged directly with Anonymous, even venturing into IRC channels to get a better understanding of what the hackers were doing and to plead with them not to release the email files they’d exfiltrated.

It wasn’t the normal behaviour of a reputable security outfit, but it is of a piece with Hoglund’s philosophy of taking the fight to the hackers, and of treating security as an active, rather than passive, undertaking.

At RSA I got a chance to chat with Hoglund. As you’d expect, he was reluctant to discuss the Anonymous debacle - he must be tired of it by now. All the same, it lingered like a spectre, colouring much of what we discussed, and we touched on it finally.

He was far more interested in talking business. The Anonymous attack killed the HBGary Federal subsidiary, but HBGary itself continues to prosper. Hoglund was in Europe to drum up more business - and possibly flush out a buyer for the company.

It’s all about people

First, though, he wanted to tackle a current bugbear. Hoglund is dismissive of the way some people seem to be obsessed with Advanced Persistent Threats (APTs).

“People just like to call it advanced because it gets through the security that they have, and they need to justify to the board what this is,” he says. “There’s a mentality out there that you can solve the security problem with technology. And that’s entirely incorrect, and it doesn’t work. You can’t buy a magical silver bullet and expect it to solve the security problem … You’re covering your you-know-what, to justify ‘well this isn’t malware, this is APT, this is different, this is why we didn’t detect it’.”

For all the talk of new threats, Hoglund agreed when I suggested our major problem is the inability to solve the problems we’ve already got. “When I talk about threat I’m talking about people,” he says. “The hackers. The mechanism by which they attack, that’s not new. So when you say the threat is evolving, it doesn’t mean the attack, technically, is evolving. What it means is the threatscape, the people - there’s more of them, they’re aware that they can achieve access to incredibly valuable data with relatively small investments - that’s an awareness they have, this year more than ever. So the threat is growing.”

So if the solution isn’t going to be a technical one, how do you tackle the issues?

“People,” says Hoglund. “It’s a counter-intelligence function. So if you’re a large enterprise and you don’t have a full-time security staff, game over. Yeah, it’s expensive … but this is where you have to go. You have to have a human in the loop.”

Taking a human-centric, counter-intelligence approach is specialised stuff. “You have to have access to the data, and you have to have analytics to turn that data into intelligence,” he adds. “Because raw data is not intelligence. If you don’t have a staff that can do that, then your security is already broken at that point. And any small to medium-size company, this is completely out of reach for them. So their only option is managed services.”

So there’s the sales pitch. Nevertheless, he’s convinced that this is how the security industry is going to evolve over the next 10 years.

If you manage to turn raw data into intelligence, what’s it telling you and what do you do with it? This is where the technology comes in, according to Hoglund.

 ”I like to focus on what I call actionable intelligence,” he says. “Actionable means you can take that piece of information and input it into a security solution you already own - a great example of that is an IDS signature. You see an intrusion in your environment, you examine it forensically and you get a URL that that malware or a remote access capability was using for command and control. You take that and put it into your IDS - you’ve just made your IDS smarter. You did that. No outside vendor, no magical blacklist. This is an attack specific to your environment. And what’s going to happen tomorrow is that same attacker is going to be back again, only this time you’re ready for him. You get smarter and smarter as this cycle continues and your cache of threat intelligence grows.”

Shared intelligence

The RSA show was opened by that company’s executive chairman, Art Coviello, calling for more sharing of infosecurity intelligence data. Ironically, this was followed by what was touted to be RSA sharing the story of its own breach, which turned out to be not quite the case. The firm remained tight-lipped about the details and persisted in describing it as a highly skilled and complex attack and not, for example, the compromise of a poorly patched Windows Server 2003 box.

So, does Hoglund think that information sharing is important? At first he seemed keen, but quickly added caveats.

“It’s a double-edged sword,” he says. “If you share data in a way that it’s public, or easily accessible to the bad guys, then they’re absolutely going to know what you know about them, so that’s the problem and the challenge with threat intelligence sharing. So, at least in the US, a lot of the threat intelligence sharing between the Government and the private sector is done using special relationships, closed forums, and may even be classified. If you’re not in that special circle, you’re not going to get access.”

Is this the only way it can be done? “I do think there have to be a lot of controls. You do need to make an effort so the bad guys can’t get the data. But that’s never going to work perfectly if you’re going to have a sharing system, then it’s going to get out some way or another.”

I asked if he thought sharing would need to be limited among countries, for reasons of national security, or if such pooling of data might be carried out within some existing framework - NATO, perhaps, or at a ‘five eyes’ level. “Sure, that would be interesting. But they’re never going to share everything - they’ll only share select stuff.”

Fight-through capability

You’re going to get breached, is Hoglund’s message for organisations of all kinds. Most security activity is reactive, not proactive. IDS signatures, for example, only tell you about old attacks, not the ones that are coming. Data sharing can help strengthen defences, in this reactive way, and raise the bar for attackers. But someone who’s sufficiently determined and resourced will still get through.

Hoglund likes to talk about a ‘fight-through’ capability. In the RSA panel session preceding our chat, he’d used this military term in the context of the US Air Force Reaper and Predator drone systems that have been infected with malware (widely misreported as being keylogger software).

“The military’s not that excited about it,” says Hoglund. “They know it’s not exfiltrating. The only threat to the system is instability.” He reckons that USAF will have quickly determined that the malware does not pose a threat to the stability of the system and will simply continue to use the infected systems - ‘fight through’ - carrying on with the mission while sorting out the compromise in parallel. This, he believes, is an attitude that commercial and other organisations should adopt.

“That’s the resilience and fight-through capability,” he says. “If you accept that business is just about managing risk, then there has to be some level of acceptance that compromises will occur. And you still have to be able to do business.”

Architectural changes

Indeed, Hoglund’s business prospects are companies that have come to the realisation that they are vulnerable (usually because they have already been breached) and will be compromised. Organisations that believe they can construct impregnable defences require too much education into the ways of the real world for Hoglund’s taste.

As most security vendors know, selling products and services is usually very easy during or immediately after an attack. But is there a need for organisations to take a longer term view and perhaps consider changing their network architectures to be more resilient, perhaps with increased use of air gapping?

“Absolutely,” he says, “because if you have a breach, that doesn’t mean that you’re going to lose data. So you have to make it very hard for them to get the stuff out. You should have your critical data separated from the rest of your network. You should have access control - this is such a basic idea, the principle of least privilege. It’s hard to believe how many enterprises out there simply don’t have that. But in a Windows network it’s entirely possible to implement that - it’s simply a manageability problem. And yeah, that’s expensive. But people will buy a SIEM, and then not use it. A problem with the SIEM is that it doesn’t do your work for you, and a lot of companies will look at it as a cost. The SIEM is giving you exposure to tremendous amounts of real-time data about what’s going on in your enterprise, but you still have to have a human being, an analyst, who can tune that data set, create analytics, so that 100,000 events an hour can be brought down to maybe four events of interest per hour, and that’s a huge problem.”

There’s still the perennial problem of justifying the trouble and expense of doing this. Getting the business to understand the risks is tricky because it’s not easy to convert threats into risk metrics. But Hoglund believes the arguments are there. “What if we lost confidence in the network,” he says. “What if we simply don’t know how many back doors they have and we don’t know if we can detect them all. Then I have to re-architect everything and build it from the ground up. There’s a number that’ll get somebody’s attention.”

Defence in depth

He also believes that more attention needs to be paid to the latter phases of an attack. Perimeter-based defences are all geared to stopping the initial infection phase. But attackers are often most vulnerable in the following interaction phase, which is mostly manual work, getting to know the network and finding the target data, and then the exploitation phase during which data is exfiltrated.

“That’s your window of opportunity,” he says. “They’re actually highly exposed during that time. The bad guys don’t have a lot of stealth at that point. They’re leaving forensics artefacts all over the environment and all you’ve got to do is detect them. And there’s only so many ways to hack a network at that point. You just have to detect that behaviour, and that’s really not that hard, I just think that people aren’t doing it, at least not widely.”

So this is defence in depth in action? “Exactly. That might be your second-last line of defence. The last line is stopping the data as it’s going out over the firewall.”

Reputation and the killswitch

Hoglund has some experience of that. The word ‘killswitch’ was mentioned. And this is where the Anonymous incident couldn’t be avoided any longer.

In the earlier panel session, Hoglund recounted the galling experience of watching Anonymous download Gmail-based email files while he attempted, in vain, to get Google to intervene. Proving he was the account holder took time - too much time. He’s now a keen advocate of making cloud service providers implement a ‘killswitch’ so that an account can be turned off in an instant, with no data allowed in or out.

“In the end, it turned out to be not all that bad,” he claims. “It was shocking and we were scared at first, but then I realised there wasn’t anything bad in my email, it didn’t really matter that much. In the grand scheme of things it was a nit compared to what’s been happening to other companies this year. I was just in the unfortunate position of being the first one.”

I mentioned how some companies believe that reputational damage is short-lived. “It’s true,” he says. “Three to six months. There’s been research done - this is in the retail space: something bad happens and after a year, consumers recognise the logo but don’t remember why. So it’s almost like free publicity in a way.”

That last sentence was spoken with heavy irony and a kind of world-weary humour. HBGary has just posted its best-ever quarter, but in the aftermath of the Anonymous attack, I suggested that he must have had some intense conversations with clients. “Yes,” he admits, “but this wasn’t for reputation reasons. They were worried that, financially, we weren’t able to withstand it. They had orders in the pipeline, and they didn’t want to order if we were going to go under. As it turns out, we actually closed Q1 out above our numbers that we had set prior to the attack. So we were, in fact, still doing quite well. Now, unfortunately, we were doing very much better than that on our pipeline, but the orders that were delayed in Q1 ended up all coming in in Q2. So our Q2 was phenomenal.”

He doesn’t actually reveal the figures involved. But can it really be true that Anonymous - aside from bringing about the demise of HBGary Federal - had so little effect on the business?

“Keep in mind our customers don’t like Anonymous,” says Hoglund. “They view themselves as targets too.”

Review: Practical Lock Picking

Practical Lock Picking

Deviant Ollam. Published by Syngress (ISBN: 978-1-59749-611-7). Price: $34.95, 230pgs, paperback.

Picking locks and hacking have gone hand-in-hand right from the earliest days. Back in those heady years at MIT, when the term ‘hacking’ carried only positive connotations, lock picking was seen as part and parcel of the inquisitive nature that drove hackers.

Today, lock picking presentations and demonstrations are a common feature of hacker conferences, such as Defcon and ShmooCon. Indeed, one of the more popular presenters at such events is the author of this book, Deviant Ollam.

There are numerous lock picking books around. What’s interesting about this one is that it’s from a publisher - Syngress - that specialises in computer books. The clue to the reason for this is in the subtitle: “A physical penetration tester’s training guide”. Ollam’s assertion is that this book is needed because penetration testing is on the rise (true) and that customers for these services are increasingly demanding full-on tests that include testing of the physical security of their premises.

Hmm. I’m a bit less convinced of that. What I hear from pen-testers is that firms say they want a full test but really only want a vulnerability scan so they can tick their compliance boxes.

But let’s not quibble, because the truth is that it’s a damn good excuse for publishing a fine book on a subject dear to the heart of real hackers.

Why you want to pick locks is up to you. Hackers do it because they don’t like barriers. Ollam’s assumption is that you have no evil intent, and so he (thankfully) wastes little time on ethics lectures, other than explaining the lock picker’s credo that you should desist from picking locks you do not own, or on which you rely.

The bulk of the book focuses on pin tumbler locks, for the very good reason that these represent about 90% of the locks you’re likely to want to pick. Wafer locks are dealt with too, although when it comes to technique Ollam is understandably at a loss here. The most common way of dealing with these is the technique of raking, which is easy to do and hard to describe.

Tubular, cruciform and dimple locks are all covered fairly briefly, although this is fair enough. The principles of how these locks are picked are the same as for standard pin tumbler versions. There’s no coverage of lever locks, however. I wonder if this displays a slight US bias - something Ollam is generally at great pains to avoid through most of the book. There’s also only the most fundamental nod to automative locks. Ollam mentions that jiggler keys are a popular tool for picking double-sided wafer locks used for car ignitions. I don’t know if that’s another bit of US bias, but certainly most recent European cars come with more complex locks.

The real strength of this publication is in its illustrations. The numerous diagrams and photographs make both the principles and techniques crystal clear. In fact, Ollam is so good at explaining the subject that you’ll keep wanting to put the book down - to go and pick a lock. I was only about half-way through chapter one by the time I’d raked open our office filing cabinets.

The book also comes with a DVD with animated versions of the illustrations and a number of entertaining videos, some of them featuring Ollam at conferences.

Because this book is focused on lock picking (and not locksmithing), and because it is intended to be a practical guide for pen-testers, there’s no waste or padding here. Ollam provides just the background information you need to understand how locks work, what you need to do, why it’s sometimes easy (because lock manufacturers need to make their products mass-producable and attractively priced) and why it’s sometimes difficult (because they have invented some cunning countermeasures).

So, buy some tools off the Internet (it’s scarily easy) and by the time you’ve finished this book you will be popping open locks all over the place. Of course, this is just a beginning. There are tougher and more complex locks out there and a great deal more to learn both about lock technology and ways to deafeat it. This is very much a beginner’s book. But as such, it’s hard to beat.

Practical Lock Picking is available from Amazon.co.uk and Amazon.com.

UPDATE (06/10/2011): Deviant Ollam tells me that he didn’t cover lever locks because they’re something of an advanced topic, which makes sense. Maybe they could be the subject of his next book!

Sony: just another victim

One of the most interesting aspects of the Anonymous/LulzSec hacking of Sony is the opportunity to observe what effects it might have over time. Now a legal decision in Australia has placed Sony in a position that, I suspect, it finds very agreeable - as a victim.

While most security analysts seem to agree that the hacks themselves were fairly trivial - from both a technical perspective and in terms of immediate damage - the true significance, we were led to believe, would be the effect on Sony’s brand.

Indeed, various Anonymous and LulzSec mouthpieces were keen to point out the reputational damage they had wrought. Time after time, with both the Sony hacks and other high-profile attacks mounted by the groups, we were informed that the whole point was to sully the reputations of the organisations under assault so that customers would think twice about doing business with them. 

One Anon told me, in an IRC chat, that the desired result will be that, “people will think twice before they hand over their identities online. That people will stop and say ‘Do I KNOW this data is safe? Do I KNOW no one can hack into this system and use my information against me?’ “

However, this effect relies on one critical factor: it’s important for the general public to believe that Sony was culpable in this matter - that its poor security (and it certainly was poor) was a major contributor to the leak of its customers’ data. In that scenario, hackers such as LulzSec are more of a catalyst than a cause, or at worst the final link in a chain of insecurity for which the hacked company is partly, if not largely, responsible.

But…

I found, when researching an article on hacktivism for Network Security (available on Science Direct - subscription or payment required), that this is not a perception of the Sony hacks that is universally shared. In fact, I concluded that LulzSec’s desire to taint Sony by leaking the company’s databases faced a number of hurdles.

The first is that people forget. Try asking your friends (at least those who aren’t followers of hacktivism) about the incidents and you’ll probably find that many have forgotten all about the hacks, even if they knew about them in the first place.

Sony customers, especially members of the PlayStation Network (PSN) may be more inclined to remember. But I don’t think it’s too cynical to suggest that most of those will be inclined to forgive and forget just as soon as the next cool game comes out. I’ve certainly not heard of any large-scale abandonment of the PS3 platform.

Of course, many people will simply not understand that Sony was in any way culpable in this matter. IT security is a complex and arcane issue. Poor security is hard to explain to lay people. Yet everyone’s heard of hackers, a term now (alas) largely synonymous with ‘criminal’ in the public’s perception.

And so most people who remember that Sony was hacked will simply assume that the poor company was maliciously attacked by bad guys.

The Australian Privacy Commissioner, Timothy Pilgrim, agrees. He’s just ruled that one of the victims of the PSN breach was … wait for it … Sony. His investigations have concluded that Sony was not in breach of the country’s National Privacy Principles - that it was the nasty old hackers who ‘disclosed’ the company’s data, not Sony itself.

As time goes on, the number of people who remember that Sony was hacked will diminish. Given that those who realise the company was partly to blame will be a small subset of that number, and that those who care enough not to give Sony their business is a smaller group still, then Sony can probably rest assured that it is already over the worst.

At least, that’s as far as reputational damage goes. The firm is still facing lawsuits, including several class actions. But all that’s at stake there is money…

Review: Metasploit: the penetration tester’s guide

By David Kennedy, Jim O’Gorman, Devon Kearns and Mati Aharoni. Published by No Starch Press (ISBN: 978-1-59327-288-3). Price: $49.95, 300pgs, paperback.

Metasploit has been such a key weapon in the penetration tester’s armoury for so long that a book like this is long overdue. Yes, there are other titles that provide a general guidance to the software, but this one is very focused on the needs and methods of pen-testers.

The Metasploit Framework (MSF) is a complex set of tools, so 300 pages isn’t going to be enough to provide an in-depth manual for the software. But it is enough to get you up to speed on the fundamentals of how it works, how all the pieces fit together and how you would typically use the software in a pen-testing environment. So that’s exactly what the authors do.

Those authors have highly appropriate pedigrees for this job. David Kennedy is CISO at Diebold and a key member of the team at Offensive-Security that produces BackTrack, the Linux distribution for pen-testers and security professionals. Jim O’Gorman is a pen-tester with CSC’s StrikeForce, co-founder of Social-Engineer.org and an Offensive Security instructor. Devon Kearns is also an Offensive-Security instructor and one of the developers of BackTrack. And Mati Aharoni created BackTrack and founded Offensive-Security.

The book doesn’t just cover Metasploit. It touches on other tools that are typically deployed in conjunction with MSF in pen-testing situations, many of them accessible from with MSF itself. For example, NMAP is to go-to tool during target enumeration and this book shows not only how to run it from the MSF command line but also how to record its output in a database. Similarly, it briefly covers tools such as Nessus and NeXpose, and gives over whole chapters to the Social-Engineer Toolkit and the Python-based Fast-Track tool, which uses MSF for payload delivery and client-side attacks.

It’s worth noting that MSF can be used on a number of platforms and with a variety of database backends. On BackTrack, for example, you may find that it’s installed using MySQL as the database engine. This book, however, largely assumes that you’re running the software on Linux and are using PostgreSQL for your database. It also assumes that you will have enough technical knowledge to adapt the examples given for your own environment, should it differ from this - not unreasonable given the intended readership.

An introductory chapter on the basics of penetration testing is mercifully brief and mostly points readers to the Penetration Testing Execution Standard (PTES). From there, it’s straight into hands-on coverage of actually using Metasploit. The authors have made a wise decision to focus on the free, command-line version of MSF. Rapid7, which now owns the rights to Metasploit, also markets the paid-for Express and Pro versions, which offer additional capabilities, ease of use and integration with other tools. However, the book is aimed at those just getting to know MSF and who are unlikely to be at the stage where it is a professional tool of such value that they can justify expensive software licences.

After a run-through of the basics of how to issue commands, select exploits, load payloads and so on, the book quickly gets into how it is used in pen-testing environments. This starts with target enumeration and vulnerability scanning before moving on to executing exploits - the job for which Metasploit is best known. Meterpreter, which is capable of providing a shell on the target system running in memory, gets a chapter to itself, which is appropriate considering how important it is to stealthy intrusion. And talking of stealth, the next, short chapter covers the important topic of avoiding detection. 

It’s obvious from the way the book is constructed that this is a practical publication. It’s not a manual for Metasploit, nor a comprehensive reference work for what is, after all, a highly complex suite of utilities. This is a guide for people who really want to use the software in real-world scenarios. And so following chapters include: exploitation using client-side attacks; Metasploit’s auxiliary modules (including how to write them); the Karmetasploit wireless tools; how to build your own modules and create your own exploits; and Meterpreter scripting.

Thanks to numerous screenshots and command examples, the authors make it very easy to understand how all this works, so it’s impossible to get very far into the book without wanting to fire up Metasploit and try the techniques for yourself. As Metasploit is all about exploiting vulnerabilities, practising these techniques against other people’s systems would be unethical and, in many cases, illegal. And trying them out on your own production systems would be unwise: make a mistake and you could bring them crashing down.

The answer is to read Appendix A before you really get started on the main contents of the book. This guides you through the process of setting up a target system running virtualised versions of Windows (preferably an unpatched version of Windows XP Service Pack 2) and Linux. This provides a safe environment in which to learn the intricacies of Metasploit.

This isn’t the only resource that will help you do that. One of the issues that book publishers have to face these days is competition from the web. Indeed, much of the information in this book - and much, much more - is freely available on the Metasploit Unleashed website, some of it supplied by the same authors. The website is also more easily updated - something highlighted by the fact that this book is based around MSF3 and version 4 of the framework was released very shortly after its publication.

However, this book provides all the key information you need to get going with Metasploit in one easily read and referenced package. In practical terms, the differences between MSF3 and MSF4 are sufficiently minor that, at least for the beginner, you’re unlikely to hit any major problems.

The conciseness of the book, its step-by-step tutorial style and simple, clear writing style mean that it’s easier to get to grips with MSF than trying to wade through the massive amount of information available at Metasploit Unleashed. Once you understand the basics, and are comfortable with Metasploit’s environment, commands and concepts, you can them move on to the website, or perhaps Offensive-Security’s highly regarded training courses.

This post is based on a review in the September issue of Network Security.

Metasploit: the penetration tester’s guide is available from Amazon.com and Amazon.co.uk.

Watch out! Hackers!

The very word ‘hacking’ is enough to make some people paranoid. Of course, it doesn’t help if they’re paranoid already.

Case in point: last week I was on a Certified Ethical Hacker (CEH) course in the UK. Right at the beginning, our instructor warned, “If anything goes wrong, even if the Coke machine breaks, we’ll get blamed”. And so it proved.

The training facility was alongside a hotel that is used by a number of training companies. In the bar, you’re likely to bump into all kinds of people. A couple of the lads on our course got talking to some people who refused to say what they did for a living or what kind of training they were doing. As it happens, we’d already discovered, by other means, that they were undercover police officers. I wasn’t there, but apparently, when they learned that we were hackers in training, their jaws hit the floor.

Sure enough, the next day the manager of our training company stormed into the classroom and read us the riot act. Someone, he alleged, had been hacking outside of our subnet. ‘Someone’ had complained they were being hacked. We all knew who that was.

It was nonsense, of course. Okay, we had a couple of minor glitches. One of the students thought it funny to email the trojan we’d just built to all his mates. (It would have been picked up by anti-virus software in a millisecond and, in any case, wouldn’t have worked outside our network.) And a fellow student and I caused the receptionist to have to reset the wi-fi access point. We’d been using the Zyxel device as a zombie in an NMAP Idle scan. But hey, that device was on our subnet and therefore classed as ‘fair game’.

It seems that no-one pays attention to that ‘ethical’ adjective. If they hear the word ‘hacker’ they feel under attack. Oh well…

Wikileaks’ security failure

Wikileaks has committed a cardinal security sin, and is busy trying to blame it on The Guardian.

It all revolves the infamous ‘Cablegate’ memos - the US diplomatic cables that Wikileaks has been peddling for some time now.

Wikileaks has been working with media organisations in an attempt to release the material in a piecemeal fashion. The reason for this is to cherry-pick the most significant material in order to make the greatest impact. And, although Julian Assange was at first somewhat indifferent to the possibly dangerous effects that publication might have on whistleblowers, informants and others mentioned in the cables, the media organisations have been making an effort to redact the cables to protect the innocent.

As The Guardian explains, in the early days, before Wikileaks fell out with the paper (and the New York Times) for refusing to worship at the alter of St Julian, Assange made the full archive of unredacted cables available to the paper, via a downloadable zip file. The file was encrypted with PGP to which the paper was given the password. The file was to be available for a limited time only.

At the same time, Assange distributed an encrypted archive, without revealing the password, to a select group of people. This was part of an insurance policy: Assange threatened to make the whole archive freely available if he was, for example, extradited to the US.

There’s hypocrisy in that, of course. If it is important for freedom and transparency that the cables should be published, why was Assange witholding them for personal reasons? Does he really conflate his own interests with those of the world? On the other hand, if it’s important that unredacted cables are not published, because of the damage they could cause to innocent people, then again Assange was being selfish and hypocritical for using them for his own self-interest.

It’s all moot now, of course.

The cables are out. One way or another (and with some pointing the finger at ex-Wikileaker Daniel Domscheit-Berg) the archive file has become readily available via torrents.

And the password?

In their excellent account of the Cablegate saga, Wikileaks: inside Julian Assange’s war on secrecy, Guardian journalists David Leigh and Luke Harding mentioned the password given them by Assange. Why wouldn’t they? As far as they were concerned, it was a unique password for a temporary file. I mean, Assange wouldn’t be dumb enough to use the same password anywhere else, would he?

Alas, he would. Yep, uber-hacker Assange reused a password. The insurance file, since leaked, can be decrypted using the same password. And boy, has it been decrypted. Head over to cryptome.org - the original, still operating and far superior whistleblower website - to get your own copy.

The reaction from Wikileaks was one of outrage, mixed with its usual brand of self-importance and martyrdom. While all but taking credit for the Arab Spring, the site has been frothing at the mouth about The Guardian and other media organisations, often descending to playground-level abuse. But the truth is, the fault lies squarely with Assange and Wikileaks and their ineptitude when it comes to security.

After all, Wikileaks has been touting these cables as the biggest thing since the Pentagon Papers. Surely, these of all files should have been secured with different passwords for separate files.

Wikileaks is now flooding the net with released cables. Now that it no longer has a monopoly on the material, it is indulging in a desperate bid to be first to publish. The organisation seems unaware that this nullifies its argument against The Guardian. It also dilutes their effect.

The biggest worry, though, is that Wikileaks has shown significant shortcomings when it comes to due diligence: it has demonstrated that it is not to be trusted when it comes to the custodianship of important material.

Let’s not forget that Wikileaks did not leak this material. Bradley Manning is accused of that and is paying a high price. Wikileaks is merely a conduit. And an incompetent one.

When is #Anonymous not Anonymous?

Not for the first time, the Anonymous activist collective is suffering some brand issues. It turns out that claiming you are ‘leaderless’ and ‘decentralised’ is something of a two-edged sword.

It’s also a lie, of course.

The concept is that anyone can operate under the Anonymous banner. There are no committees to attend, no leader from whom you need to seek approval. If you want to mount an operation and call it an Anonymous action … well, go right ahead.

Or maybe not. We’ve just seen two examples of where that causes some problems.

The one currently grabbing headlines is the so-called OpFacebook. A YouTube video by ‘Anonymous’ promises that everybody’s favourite personal data aggregator will be “destroyed” on Nov 5. And the video has all the classic hallmarks of Anonymous - it’s sufficiently pretentious and bombastic that you can’t help wondering if it’s meant to be funny.

Only it turns out that ‘Anonymous’ isn’t Anonymous, if you see what I mean. The ‘real’ Anonymous (the one, remember, with no leaders or centralisation) has been denouncing this operation as a fake. ‘Sabu’ (@anonymouSabu), the non-leader of Anonymous (and also, as it happens, LulzSec) has been especially active in denouncing this as a fraud and is practically begging the media to pay no attention to it.

So how does that work, exactly? Surely the whole concept of Anonymous is that, if I call myself an Anon, that’s enough. Who is Sabu to call this a fake? By what authority can he assert that this is not an Anonymous operation?

I’ve recently completed a long feature about Anonymous and LulzSec for the journal I edit, Network Security. During the research, I had a couple of IRC chats with Anons, via the irc.anonops.li server. Part of this touched on the ‘leaderless’ nature of the movement. I wanted to know how that assertion can be supported when there is clearly some direction from a core group. For example, the channels found on irc.anonops.li are regarded by pretty much everyone as the ‘official’ IRC channels. Some of the channel topics are used to set targets for the Low Orbit Ion Cannon (LOIC) - the DDoS tool used by Anons that has turned out to be so dangerous for its users. There are also channels used for co-ordinating operations that are not open to the likes of you and I - strictly invitation only. I wanted to know how this meshes with the leaderless concept.

I chatted with joepie91 who was at pains to point out that he did not speak in any official capacity, but just as one of many Anons. He did, however, have channel admin privileges in the #reporter channel set up to talk to the media, and most other people in the channel appeared to defer to him.

I asked him to explain a comment he made that, “anonymous =/= anonops”.

joepie91: anonops is just one network that is populated by Anons

joepie91: Anonymous is not a centralized entity

joepie91: there’s no member list, no ‘official representatives’, no leaders

So far so good. But I pointed out that someone gets to set targets in channel messages. The answer felt a little evasive, in that he largely just stated the obvious - that channel ops get to set the topics. But he also enlarged:

joepie91: if you don’t like operation payback, noone stops you from setting up a similar operation with similar targets but a different structure … if you disagree you can just walk away and set up your own … and noone will stop you

It seems that’s exactly what someone has done with OpFacebook. And now Anonymous seems not to like it.

But that’s not the only spat that’s been going on. When various Anonymous accounts were kicked off Google+, because they contravened the service’s rules on using real names, some Anons vowed to set up a social networking site just for Anons. It’s hard to see how the mechanics of social networking would fit with the idea of being Anonymous, but selah.

The result was AnonPlus, which has so far had a very sorry history. It started out using bog-standard forum software, but has mutated many times, shifting domains and hosting, constantly promising great things to come. With amusing irony, it has been hacked numerous times (as in the example above) and this led to a blow-up between Sabu and ‘higochoa’. Sabu, it seems, was particularly incensed at people believing that he, personally, had been hacked every time AnonPlus was defaced.

<Sabu> I am getting sick of hearing that *I* get hacked every week

In a more telling moment, Sabu says:

<Sabu> I suggest you either kill the project / stop using anonymous’ name

That suggests to me that Sabu feels at least some sense of proprietorship over the Anonymous brand. Maybe it’s time for Anonymous to decide whether it is genuinely going to embrace an anarchic policy of no enforced structure, or whether it should grow up a little and become a more organised activist force. The latter would be more interesting because, currently, its disorganised and chaotic approach is achieving very little.

Time for a #LulzSec successor

Now that (allegedly) LulzSec spokesteen ‘Topiary’ has been arrested, and it’s only a matter of time before ‘Sabu’ is looking down the barrel of a law enforcement raid, maybe it’s time for a new group to take up the mantle of AntiSec.

We’ve already seen the rise of TrollzSec, which successfully outed Topiary’s true identity.

But there’s room for more on the open seas of hackerdom.

So, if you can watch Anonymous videos without laughing, own a pair of shades and can spell SQL, maybe it’s time to start your own script kiddie club. I offer the following as possible names:

SkullzSec - strictly for boneheads

DullzSec - we leak boring crap

ProllzSec - now anyone can be a hacker

DrollzSec - not funny, but maybe a tad amusing

GullzSec - for those who think security is strictly for the birds

NullzSec - hacking for zeroes

Dropbox security

A backlash against Dropbox shows just how little people understand security.

It seems that some people actually fell for Dropbox’s early assertions that files stored on the system might be more secure than those on your hard disk (ignoring the fact that these files are actually stored in both locations). No-one, but no-one, has access to your files, claimed the company.

Later, Dropbox realised that it’s subject to the same laws as any other US organisation and was obliged to change its terms of service to admit that it would have to co-operate with US law enforcement. Indeed, the forces of law and order have acquired a new forensic tool specifically for examining Dropbox accounts - Dropbox Reader.

This evidently provoked fury among some users who feel they were duped. There were threats of defections.

The image of Dropbox as a safe haven hasn’t been helped, either, by its recent screw-up in which accounts were left unprotected for a few hours, no password required.

But here’s the thing: Dropbox is a cloud service. Why would you imagine the cloud is automatically secure?

Yes, I know, people are not properly informed about this stuff and can only make decisions based on what they’re told. So Dropbox should carry a good portion of the blame for this. But there’s also an element of common sense here.

I don’t care what promises a cloud supplier makes, I work by a simple rule: if the data is the slightest bit sensitive, it gets encrypted before it hits the net. And I don’t just mean I use SSL for the connection. Any sensitive files we store on Dropbox are either encrypted individually or stored inside a PGP-encrypted virtual disk.

That means employing data classification of some kind, but for us that’s not nearly as complicated as it seems. It’s a simple question with a yes/no answer: could this file be of use to someone with malicious intentions? If the answer’s ‘yes’, into the encrypted drive it goes. No data of the slightest value leaves our home network without being encrypted first. And our threshold for what’s considered sensitive is very low.

So here’s a handy motto: Encryption - don’t leave home without it.

Talking about risk

The information security business is a bit like the world of 1970s French movies. At the time, these films had a reputation for being racy, of containing a lot of delicious naughtiness that was nevertheless somehow culturally uplifting. When you actually sat through them you found there was a lot of talking and very little action.

In the infosec domain I hear a lot about risk. Companies understand risk - or at least, go to great trouble to convince themselves they do. They have risk managers, risk metrics, godzillabytes of data measuring, delineating and analysing their risk posture so that they can decide on their risk appetite.

Of course, it all turns to shit the second they get to their IT systems. When it comes to the risk of flood, fire, market downturns or zombie invasions, risk managers can show you graphs and tables that would convince anyone the firm is doing all it can reasonably be expected to do. With IT, well, it’s anybody’s guess, right?

There are some attempts at improving this situation with IT. The Common Vulnerability Scoring System (CVSS), for example, is one effort to put a number against some of the risks firms face with their technology. But understanding how much danger you actually face as a result of, say, the software you have installed is very tricky.

It’s not that people don’t want to understand this stuff - they just don’t know how and, even if they did, might not want to expend the necessary money and effort.

I wrote a piece on software insecurity for a Guardian supplement recently and the one refrain I heard over and over from the experts I talked to is that enterprises aren’t looking at their software infrastructure from a risk perspective. 

Small wonder: analysing vulnerabilities in software is hard enough. People like OWASP are doing great work in trying to get developers and the people who pay them to make security an intrinsic part of the development process, but firms don’t want to pay for the extra effort needed and don’t like what it does to schedules. They want their software now. And as for existing code, yes you can run some automated pentests against it, but how much is that really going to tell you? Analysing vulnerabilities in existing code takes considerable skill - read: money.

And, of course, knowing that vulnerabilities exist is one thing. Analysing that in terms of risk is another.

Then there’s another worrying aspect to all this. Even if you can understand your vulnerabilities and can translate that into a meaningful risk metric, is that going to do any good?

When enterprises do all this risk analysis, are they really tasking themselves with fixing the problems? Or are they merely concerned with covering their asses when it comes to due diligence and compliance?

“Oh yes, we got hacked and all our customers’ information is now in the hands of heartless cyber-criminals. But not to worry: according to the regulatory requirements we did everything we could be expected to do given the risk.”

I’d like to suggest an addition to regulatory requirements. If you’re the CEO of an enterprise that is hacked using standard Metasploit modules or basic SQL injections, you go straight to jail.

Tags: risk