Recently I changed my personal firewall software. I was using the default Windows7 Pro firewall, which is fine for basic stuff, but I found a deal on one of my favorite security suites, so I went ahead and sprung for it. One main befuddlement people have with additional firewall software is the amount of nagging it often does when it’s first installed. You open your email client – popup – “program X is trying to communicate on port Y would you like to allow this?” You click yes, and move on. You open your instant messaging client and again – popup – “program X is trying to communicate on port Y would you like to allow this?” This can be annoying but this is usually the training mode of the software, it’s trying to learn what software you use, and it’s relying on you to make educated decisions on whether that software is really what you’re trying to run.

Usually firewalls only do this when they are initially installed and are in their “learning” modes. I usually keep it in “learning mode” for about a week to ensure I cover the plethora of software that I’d typically use. Then I go into lock down mode – blocking all other outbound and inbound traffic. Most people will only resort to a middle ground where most of the known ports are allowed, and others are not.

But this “learning” time period can also be beneficial. It will ask you whenever any program tries to communicate in/outbound – so if you start getting warnings when you’re not actively trying to run a program, then pay close attention to what program is trying to communicate. If it’s not a Microsoft service (windows) or some other service from a trusted source, then most likely it’s malware that’s been residing on your system for some time and you probably didn’t even know.

Most of this is beneficial to you home users, but it can also help those in the IT departments as well. It’s a good learning tool to help those just starting out to realize that there’s a lot more going on than you might expect. There are a lot of underlying communications that can occur especially in the corporate environment. So use these “learning” sessions to help educate yourself, for home and work life; and those in IT should be making notes of what is trying to communicate, and compare those with the known services that your company is running. Once you’ve determined all the proper services and software – opt to block all other in/outbound communications. You should document this in a policy and keep records of this. The last thing you want happening is not knowing what could potentially be coming or going from your networks.

Enter Armitage. If you’re normally a windows/GUI person and aren’t comfortable with the command line (much less metasploit’s command line), you might want to look into Armitage. It uses xmlRPC to talk to metasploit and presents you with a nice pretty picture of your network and what you’ve compromised and allows you to launch metasploit plugins and attacks against the networks, as well as interface with meterpreter to pivot through compromised hosts.

I have only scratched the surface of what Armitage can do in my own testing, but what I’ve seen so far has been excellent – especially for an initial release.

Some folks will complain that this makes it too easy to “hack” into things, but I really think it’s an improvement for those professionals that have other things to do than memorize metasploit’s command line or have to read through the manual every time they use it (raises hand).

Recently I found myself playing red cell at Computer Sciences Corporation’s Cyber Defense Competition. By the time I heard about it, the competition was well underway, students were crying and vomiting all over the competition room (I exaggerate) and Meterpreter shells on every student network. I quickly ran into Tim Rosenberg from White Wolf Security and found some space at the red cell table for me and my Backtrack netbook. I spent the rest of the day harassing my former team from James Madison University, as well as 3 other school teams from the Virginia/D.C./Maryland area.

Rarely as a pentester will you find a gig where the scope includes defacing websites with lolcats, chatting with employees through Nuclear RAT, and just plain bringing the network down. At a cyber defense competition anything goes, from social engineering to DDOS within the last hour of competition. As a junior penetration tester, cyber defense competitions are a good place to practice your craft experimenting with new techniques outside of your home lab environment. It’s also a good time to watch the more experienced red team members at work picking up tips to improve both at play and back at work.

White Wolf Security has added an additional element to the game since I last played in one of their competitions in 2009. In addition to wreaking as much havoc as possible and inducing vomiting among the student teams, this time the red cell had specific tasks to complete like competitors in a capture the flag event. Individual red team members scored points for completing tasks as well as being the first person to “phone home” from a penetrated student machine.

There was a mixed bag of machines in the student networks. In a one day competition, you won’t see as much patching and other vulnerability solutions cropping up as at longer competitions. Having spent two years on the student side I know it is a hard enough task to keep the networks up and abreast of business injects. The boxes ranged from vulnerable to ms08_067_netapi or a default xammp install, to boxes with no outward facing vulnerabilities. On the whole the flags were challenging for a one day competition, residing on boxes without any vulnerabilities with publicly available exploits. I look forward to another try at it at the Collegiate Cyber Defense Competition Mid-Atlantic Regionals this spring.

My only criticism of the new setup is that I would hate to lose the camaraderie of the red team by turning it into an individual competition. The most fun I had all afternoon at the competition was teaching a couple of CSC employees who had joined in the fun how to use Metasploit. Working together and sharing techniques is the best part of playing red team. Perhaps in the future the red cell should break into small teams like the student teams. Then we can move forward with the challenges for red cell without losing the mentoring and teamwork among red cell members.

Thanks to Computer Sciences Corporation, White Wolf Security, all the sponsors, and student teams, for another great competition. If it wasn’t for you guys I wouldn’t be lucky enough to be in this industry.

Cloud services are becoming ubiquitous, common, and more useful every day. What do I mean by cloud services? Google Apps, Dropbox, or basecamp are all cloud services. Many people (including me) use them to manage their productivity work flow. I’m a big fan of Dropbox to sync my to-do list (Things) and 1Password file between my office machine, my desktop at home, and my laptop. It just works. I also use MobileMe to take care of my calendar syncing.

But, I’m careful about what I put in my calendar, or my to-do list. Those things can tell a great deal about information that should be kept confidential – who I’m having meetings with about what can give away who our clients are and some information about them – completely unintentionally. What’s on my to-do list can give an indication of my (or my client’s) priorities.

There’s two ways of approaching the problem: control what you put into the “cloud”, or protect it before it goes into the cloud. I do a mix of both. My calendar information is limited as MobileMe won’t allow me to send an encrypted file to their caldav servers. My to-do list (and 1password file) are encrypted in an encrypted disk image in my dropbox folder. 1password does its own encryption. And if I do use dropbox to sync files, all of those files are in an encrypted disk image. I may be paranoid, but I haven’t audited these services to see what their security levels are, so I choose not to trust them. Our clients expect us to take good care of their data and protect it as well (or better) than they do, so I default to not trusting them.

Be aware of the information you are storing in the “cloud”, even if it seems silly to you. At least be aware of what data is getting pushed to someone else’s servers.

Today is the day before thanksgiving in the U.S., otherwise known as the busiest travel day of the year.  It is also the date of national opt-out day, an effort to raise awareness of the TSA’s use of “strip search scanners” and “enhanced pat-downs”.  While I’m sure most folks would prefer not to be irradiated, seen naked, and/or groped, they will willingly do it because (a) they want to get to their destination with a minimum of hassle, and (b) everyone else is doing it.

Robert Graham decided to address this topic and to do so he wanted to take some photos of his TSA checkpoint for his blog.  Photography is, by the way, completely allowable under TSA regulations. Unfortunately, due to the fear and concern raised by potential protesters and this opt-out day brouhaha, the TSA employees overreacted and detained Mr. Graham for 30 minutes trying to decide what to do with him.

Many folks will point to quotes from the interaction such as “Not all parts of the government are accountable to the public, especially the TSA” and think that the TSA is out to get us all, strip all our liberties and freedoms away and be accountable to nobody.  While this is a good sensationalistic view and will draw a certain type of reader, I don’t think it accurately reflects the real problem here.

The TSA really is just trying to keep us safe when traveling.  That’s their mission. They are trying to do their job.  Mind you, I disagree with many of their methods because they are ineffective and uncreative.  The TSA’s security mechanisms are focused almost entirely on solving the last security breach, not preventing the next one. That’s a topic for another post.

The TSA’s largest failure is one of communication with their officers. The TSA agents at Mr. Graham’s airport should have known that taking photos was allowable.  Matt Kernan’s post about avoiding scanners upon re-entering the US and how many different phone calls and individuals had to be involved demonstrates that communication and cooperation is limited at best.  All this behavior and resulting blog posts and press articles are exactly why a vocal minority of folks is now dead-set against the TSA, organizing protests, and being labeled as domestic extremists.

I hope the TSA learns from these misadventures and improves its communication before everyone’s view of it becomes unfavorable.  As I said before, I believe TSA is really trying to do its job, but to do that job they must walk a fine line.

One of the most common vulnerabilities in web applications is known as HTML injection or cross-site scripting, and one of the simplest ways of showing such a problem exists involves loading a JavaScript alert dialog. Those who understand the ramifications of such an issue know that it creates the potential for far more malicious activity, but the alert box is an easy demonstration that the application can be automatically manipulated.

Other vulnerability, though, may be more subtle and not as readily visualized. Take cross-site request forgery, for example. It’s easy to understand that there’s a problem when an application lets you manipulate the data of other users – the site should validate the account making requests before executing them. What may not be so obvious is that problems can still arise even when the application checks the account first. If no system exists for verifying that the account owner actually intended to perform a given action, it may be possible to hijack that user’s session and make requests without them knowing. The technical term for this behavior is cross-site request forgery.

Read the rest of this entry »

The din has increased of late over the “need” for AV on all Macs. Historically, there haven’t been a lot of overt malware threats to the platform, and thus it has persisted as a special case, for better or for worse. Commercial solutions have existed for years, and yet in the past few weeks some of those packages have been released for free (presumably because they’re not making much money anyway).

Some cite “Boonana” as the latest “big” threat since Koobface…

• New Mac Trojan uncovered: “Boonana”
• New Java trojan attacks Mac OS X via social networking sites

Of course, then the threat is downplayed…

• Intego classifies new Mac trojan threat as “minimal”

Nonetheless, it seems that there *is* Mac malware…

• Free anti-virus for Mac – 150,000 active users and plenty of malware found

Note that most of the stats in that report, however, seem to apply to either harmless files or cross-platform (Java) attacks

Nonetheless, there are several free AV and security tools out there that you might consider.

• http://www.apple.com/downloads/macosx/networking_security/index_top.html

Notable on the list are the free Sophos Mac AV, ProtectMac AV, ClamXav for Mac… you might also be interested in MacScan, which helps supplement AV in looking for other forms of cruftiness, and Little Snitch, which helps you monitor resources and connections that may or may not be good or approved.

Bottom line: Don’t panic, but start considering adding some security tools to your Macs. If you’re using Macs in the enterprise, then it’s probably a good time to start thinking about how to manage and scale security solutions (which you should be doing already, assuming you’ve not already gone down this path).

In talking to Peter last week, I asked him a question which we realized was pretty much impossible to answer:

How do you measure security strength?

That is, we know that an 8-character password with upper-case letters, lower-case letters, numbers, and special characters is definitely stronger than a 6-character password with only letters and numbers. But how much stronger is it?

Unfortunately, that’s incredibly hard to answer.

Of course, we know that there is no such thing as bulletproof security; if an attacker has sufficient time and resources, any security measure can be surmounted. Passwords can be broken, encryption can be cracked, etc. Given that the goal of security is to keep an attacker out, perhaps the most direct way to measure the effectiveness of security is, “How much effort will it take for the attacker to defeat it?”

This can be expressed in a fashion rather similar to programming complexity, using “Big O” or “asymptotic” notation. Which is useful because it communicates a key concept: multiple layers of poor security are not equal to one layer of good security. One might be inclined to think that, for example, requiring three weak password authentications is better than just one weak password authentication. But, while the difficulty in breaking one password is O(n), the difficulty in breaking three passwords is just O(3n) – which is, asymptotically, the same thing!

For real security improvements, the cost of defeating the security must be a higher order of complexity – it must be O(n log n), or O(n^2) or the like. That’s a real improvement over O(n). In the real world, this means adding levels of complexity to a password, requiring a hardware token, or adding in biometric identifiers.

But even expressing security in terms of complexity won’t really work: it doesn’t account for the myriad ways which attackers might use. Keeping passwords as an example, you may require strong passwords which truly are an order of magnitude harder to defeat than simple passwords… but if you’re not using good encryption for transmission, you’re no more secure. And even if you’re using good encryption, a wrench can still get the password (not that I advocate this method, of course, and especially not when my kneecaps might be involved!)

So, realizing that there are no easy fixes, and that attackers can be resourceful, how do you measure the level of security?

Well, so far the best idea I’ve seen has been to create a composite score based on your vulnerability to various attack vectors, giving weight depending on the expected likelihood of a given vector. Yes, that’s right: benchmarks.

And ultimately, you don’t want to get too hung up on the score. With benchmarks, you can usually manipulate to get whatever score you want. It’s just a number; the question is whether you’re secure. So use a metric, or pick a team that uses a metric, which you believe realistically reflects the threats you expect to see. And whatever the answer you get, the question is binary: “Am I secure enough?”

If you haven’t heard of Firesheep yet, I’ll let you go read those details for a bit. When you come back, I want to talk about why SSL is generally not used in these situations – the title gives a hint – it’s all about economics.

SSL is still quite expensive in terms of computing power. Sure, not for your computer when you’re browsing, but for a server which is handling thousands if not millions of requests per second? That’s a lot of the CPU (and RAM) being dedicated to just SSL, not counting whatever service the server is providing. There are hardware SSL accelerators, but they are also fairly limited: this one claims up to 14,000 transactions per second. What is twitter’s estimated usage? I’m not sure, I can’t find out, but with an estimated 14 million users in 2009, I’m guessing that it’s pretty high.

Now, imagine computers handling over 14 million HTTPS transactions (even within one day) – that’s a lot of transactions. That’s a lot of transactions even without SSL, but SSL brings in computational and bandwidth overhead, and those are things that these companies are paying for. Bandwidth is generally charged on a fixed fee for a certain amount, and then a per-bit rate after that.

By reducing the number of SSL sessions, they’re reducing bandwidth – and thus costs. They are also reducing the computational power needed for each of those sessions.

Should they offer SSL? Of course! Should people take advantage of it – I think so. Should they be villainized for thinking about their bottom line? Not more than any other company. But when you’ve got a user base basically paying nothing and wanting them to spend significant amounts of money on infrastructure costs, it’s not exactly fair.

Back in January, Google announced they would pay between $500 and $1,337 for bugs in their Chromium web browser code, if the discoverer first reported it privately to them and followed certain conditions. Since then, the company has handed out quite a few bounties to security researchers who found problems.

Now, Google has expanded the program by offering similar bounties for vulnerabilities in their web-based applications. Hackers who find issues such as HTML injection or cross-site request forgery in important Google services can now report them and possibly qualify for rewards ranging from $500 to $3,133.70. As with the Chromium bounties, bug hunters have to follow a few rules and conditions, such as giving Google some time to fix the issue before public disclosure.

Given the success of the Chromium bounties, it’s likely this new experiment will be beneficial both for security researchers and Google’s users. It certainly adds an interesting new twist to the debate over how to handle outside bug discoveries – perhaps we’ll see more companies offering such compensation in the future.