Bruce Potter opened up with the event schedule and went on into his own little opening that had a common theme of “common sense”. He used the recent hiccups in the TSA as the base analogy. Basically the metric that we’re using to try and fix today’s security problems is solely based on the amount of money that we throw at it. Simply – the future looks grim if we continue the way we’ve been going.

Collin Brack kicked off the actual presentations with one titled: GPU vs. CPU Supercomputing Security Shootout. I was actually looking forward to this talk. Sadly, I was a little disappointed. I guess I was looking for some more in-depth technical slides or live demonstrations on how GPU vs. CPU compare. It was basically a link-filled slide hyping GPU. Nothing against Collin here, I’m sure it was a great presentation for those who had no clue that GPUs could be used for computation calculations, just didn’t have my vote. Key points: GPUs are great for many small calculations.

Larry Pesce, Mick Douglas followed up with “Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals”. This was a pretty good presentation. They showed what types of personal information they were able to find simply by parsing the P2P networks with a bit of command line scripting and mutella. It was entertaining and informative. Key point: careful with what you share on P2P, don’t share your entire C drive.

At this point I needed to stretch and take a small break, so I used this time to make my donation for my ShmooCon t-shirt. Also, I’m not entirely sure who or what the presentation was at this time. I thought I remembered Bruce mentioning one of the speakers not making it. And all the others were on the schedule, so this block was a blank to me.

I did return for Dan Crowley’s talk about “Windows File Pseudonyms”. It was a good presentation about the many different ways you could reference files without actually using a ‘C:\file.txt’ notation. Most involved some sort of ‘//’ notation or localhost network traversal. Some of this information I knew, but it was good to see it put to actual usage. He demonstrated with a php file upload attack exploiting file name safeties in the code. Key point: watch out for string comparisons for file checks, actually do a file/directory check for paths and files.

Doug Wilson’s “Learning by Breaking: A New Project for Insecure Web Applications” was probably the quickest presentation in ShmooCon history. I say this because as I stepped out for about 8-10 minutes figuring I’d come back just in time for the good stuff, the presentation was already over and he was taking questions. I was really kinda ticked at myself for this one as this was exactly something I was looking forward to seeing as I’ve attempted to set up my own WebApp test environments in the past. I’ll definitely be looking back over the recorded presentation for this one and checking out the site. Key points: Don’t be late for the presentations you WANT TO SEE!

“Guest Stealing…The VMware Way” by Justin Morehouse and Tony Flick brought to the surface an old attack involving a directory traversal vulnerability in VMware Server. They basically explained how they came across it, along with a live demonstration. It’s something that’s long been patched, but it was good to see it in action anyways. Key points: Patch!

The final keynote “Closing the TLS Authentication Gap” presented by Steve Dispensa and Marsh Ray was a very good look into the actual process of discovering a real (and major) vulnerability, and the process it takes to disclose this information in a timely and yet safe manner without simply dropping it as a 0-day for the world to engulf. They discovered many of the issues weren’t technical at all, simply getting vendors and companies to cooperate with what needed to be done. It was a great view into the process and something I think all of us should look into. It gives a good showing at how hard it is to be an actual White Hat.

So, the fun continues tomorrow at 10am EST – I’m beat from a long day and not looking forward to trudging back through the snow, but hey, it’s ShmooCon!

I’ve mentioned OpenVAS before, but version 3.0.0 came out in December, so I figured I’d give more details on it.

It’s a fork of Nessus 2.0, so if you used Nessus while it was still open source, it’ll be somewhat familiar to you. It still uses NASL for tests, so you can use some of those ancient vulnerability tests if you need to. It also has the same basic client/server architecture. You put the “server” on the network segment(s) you want to scan, and you can have the client pretty much anywhere that can talk to the server.

There is an “official” OpenVAS feed, but you can subscribe to any feed you want – including the Nessus feeds.

If you’re not used to working “under the hood”, then OpenVAS will seem like a huge change for you, but if you used nessus previously, you’ll just have to remember a few of the old things on the command line.

I haven’t used it on an assessment (yet), since we have a Nessus professional feed, but I’ve used it at home and have found it quite nice to use and might consider starting to use it for assessments.

And in a timely post from Brian Krebs on his new site krebsonsecurity.com, there’s a very simple way to crash IE6.

If you’re curious and have IE6 lying around, type or cut and paste the following into the address bar (that last character is a zero):  ms-its:%F0:

So, what are we missing? Are there any other reasons I can throw at this customer to put IE6 out to pasture? Let me know in the comments.

-30% of users had passwords made up of 6 characters or less. Most brute force attempts are moderately successful against short passwords.

-Over 50% of passwords were all lowercase, or all numbers. This is bad because the keyspace is reduced. Even a password that is longer than 6 characters is weakened if it has a small character set distribution.

On the surface, these two statistics aren’t a good look at all, especially considering the ease with which an attacker could successfully guess simple passwords.

Also, in many cases, a password breach may not just make a user’s account vulnerable on the breached site, but can also lead to their account being compromised on other sites as well (plenty of people use the same password on multiple sites).

However, there is an alternative way to interpret this data. Although there is no way to verify this, it could be the case that users are starting to give value to the importance of some accounts AND the security of the website associated with it. And those accounts that are of low significance (like a site they just sign up on to play a game) get simple, easy-to-remember passwords, while accounts of greater personal significance (banks, primary email, etc) get the more robust passwords. Similarly, it could be the case that users think sites like RockYou are sketchy anyway, and thus more likely to get hacked than other more-serious sites.

So, in a way, the user could be protecting themselves from a site breach. I know I wouldn’t care if I had a RockYou account and the site got breached since I wouldn’t really use that same password anywhere else important. It may be annoying, but it is much better than knowing that my super secret 28-character password is sitting on some stranger’s computer simply because somebody left the door open.

So if you think of this report from the perspective of users managing risks reasonably instead of users being victimized, it almost makes sense that 29,000 people had ‘123456′ as a password.

The “Fifth Annual U.S. Cost of Data Breach Study,” funded in part by encryption vendor PGP Corp., determines the annual cost of the breach by establishing a company’s cost of lost business as a result of an incident; expenses incurred by notifying individuals and authorities of a breach; costs associated with legal fees and consulting firms and new investments made in technology and employee education.

In our down economy, it is interesting that the cost of data breaches have been rising for five years running.  If I were cynical, I might suggest that one of the reasons for the constantly increasing costs in this study is the partnership with PGP, who sells products designed to protect you in the case of a lost laptop or storage device.

That said, I’m not even sure that those items above can accurately represent the cost of data breaches, especially in certain environments.  The loss or damage of reputation caused by a data breach can be so devastating that the monetary cost can’t even be calculated.  If you don’t know what I’m talking about, what is the first thing that comes to your mind when I mention Heartland Payment Systems, TJX, or the Department of Veterans Affairs?  These organizations have suffered tremendously because of wide (and widely publicized) data breaches.  Imagine the firestorm of criticism if some of the most trusted companies were to suffer data breaches along the lines of Heartland’s breach?

In addition to the loss of reputation, what are other costs of data breaches that the Ponemon study doesn’t reveal? Let us know in the comments.

So why does Backtrack rock in general? It’s basically most of the tools you will need for your pentest all rolled into one and set up nicely. I say most because it doesn’t have your commercial tools such as Nessus built in for obvious reasons, though it is possible to integrate your licensed Nessus into your Backtrack install. Ever been setting up Dradis for your first big pentesting gig at a new company on a recently imaged box? You’ve got your ruby prerequisites (rubydev, opensslruby, etc.), various gardening tools, SQLite, diamonds, garnets, and opals. At some point in the process of getting it all integrated, even your technically savvy individual may find himself ruing the day he decided it was a good idea to wait until the night before to build the pentest box. In Backtrack it goes like this:
root@bt4: cd /pentest/misc/dradis/server
root@bt4: ruby ./script/server
Done.

So why upgrade to Backtrack 4? First off, there’s the obvious perk of having the newest versions of all your favorite tools and some you’ve had on your list to check out for a while now. It also includes some new tools that have been developed in the interim since Backtrack 3 came out way back in summer of 2008, saving you the trouble of those pesky installs and svn checkouts. A great new tool that’s making its Backtrack debut on the final release of Backtrack 4 is re1ik’s social engineering toolkit (SET). Additionally, Backtrack 4 is Ubuntu based rather than Slackware based. While Backtrack 3 was great, your Ubuntu-based system has its perks as far as driver integration goes. As more and more people move from just the Live-CD Backtrack approach to using Backtrack as the base operating system on their pentesting boxes, this can only be a step in the right direction. Speaking of installation, Backtrack 4 final has an installation script that looks a lot like the GUI-based point-and-click installation wizards seen in system such as Ubuntu, resulting in a more hands-off approach than persistent changes in Backtrack 3.

The only drawback with Backtrack 4 as is that I can think of would be trying to write up your reports in Backtrack. Let’s not get into any holy war between writing in vi or nano, and just suffice to say it’s not easy. Backtrack 4 does come with Emacs, and some included tools such as Maltego make some pretty graphs. Plus, you can install OpenOffice on Backtrack, so it’s not that big of a drawback after all.
All in all, Backtrack 4 is the bomb, and if you haven’t jumped on the bandwagon, my advice is to get to it.

Georgia

First off, risk management is not specific to the IT field, and most risk managers are not working in IT but in project management. Second, there are very few risk management methodologies in use, or even studied, so what exactly does this certification teach/require? There are scant details on the web site on what the test will cover, but they claim that these professionals will help enterprises design risk management controls for IS. Risk isn’t only about controls – that’s auditing – making sure the processes you put in place are being followed!

Risk management isn’t only about determining and mitigating risk, it’s all about what are the risks and what are we going to do about them? I’m not sure these skills are easily taught, except through case studies.

Any project manager is going to understand risks better than most IT people will (unless they’re also a PM). Go for the PMP cert rather than this one.

While I’m happy that Google will now be encrypting Gmail-related communication by default, I’m a little surprised and disheartened that it took an attack to cause this to be implemented. Sure, https has been an option since July of 2008, but Google had previously warned of a security / usability tradeoff with turning it on:

Because the downside is that https can make your mail slower. Your computer has to do extra work to decrypt all that data, and encrypted data doesn’t travel across the internet as efficiently as unencrypted data. That’s why we leave the choice up to you.

Today’s computers are fast enough to handle https without concern, thank you very much. And I think they meant to say your encrypted email “can’t be cached by proxy servers” instead of “doesn’t travel across the internet as efficiently” – which is a good thing, right? The use of always-on-HTTPS is an infrastructure problem – establishing and maintaining all those different secure sessions with different keys certainly takes time and processing power. It is unfair to solve your infrastructure problem by suggesting that the user might not want comprehensive security.

Are you aware of any other services that allow the user to make a poor security decision in the (perhaps unjustified) name of speedier access? Let us know in the comments!

Attackers regularly scan large blocks of IP addresses in an attempt to find exploitable computers. When they think they’ve found a likely target, some form of attack usually follows. By placing honeypots on the Internet, security researchers are able to get a first-hand view of just how the attacker carries out his goal. Since the honeypot is no different from any other computer system from the perspective of the attacker, they are likely to never even suspect anything is wrong.

Honeypots may run under a virtual machine or within some other form of sandbox environment to protect the host computer from suffering any actual harm. The effect is similar to a glass-bottom boat, where all attacker activity is transparent to the researcher. Most honeypots advertise themselves by responding to scans as if they were a vulnerable service. For example, a honeypot may accept connections to TCP port 80 and claim that it is a webserver. The attacker will be inclined to believe that a webserver actually resides on the target computer at TCP port 80, even though this is incorrect. If the attacker attempts to attack the computer via that channel, the honeypot will log the effort for future analysis.

It can also be fun to set one up on your own computer and see what you catch. HoneyBOT is Windows honeypot software that lets you turn your system into a functional honeypot, ready to catch attackers in the act . If that’s your thing.

• Automation of compliance processes
• More regulation en route
• FISMA compliance reform
• More enforcement for noncompliance
• Federal data breach and privacy laws emerge
• Cloud computing complicates compliance
• SOX compliance for small companies
• Migration to risk management

I was quoted in a couple parts of the article with my visions of the future related to FISMA and risk management. It’s worth a read and a comment if you think they missed anything, or if my predictions are way off!