Whether you’re going or not, Rob McMillan over at IDG has done a good job of summarizing some of the key stories you should be watching come out  of Vegas this week.  I should be able to get interviews with at least a few of the people giving these talks, so keep an eye out here and the podcast page for this year’s series of microcasts.  Or if you hate those, you might just want to unsubscribe until next week.  In fact, if you don’t want to hear about the events going on in Vegas this week, you just might want to stop reading most security blogs, Twitter, Facebook, blogs and most other social media outlets security folks use for a little while. 

Following the twitter stream, it’s easy to see that there are a lot of security professionals eager to get to Las Vegas, meet with old friends, make new ones and get the party started.  And the parties really are an integral part of the the whole experience.  If nothing else, try making it to the IOActive Freakshow Saturday night; if last year is any example of what they have planned for this year, it’ll be worth it if only so you can say you saw it.  Just be careful how much you drink and what you say, you don’t want to be this year’s example of someone who ignored that cardinal rule.

So much for seeing eight hours of sleep a night for at least a week.

I talk to Jack, Josh and a lot of other people about PCI fairly regularly.  I’m fairly confident I know their positions on compliance and they have a good idea of mine as well.  Jack’s a good moderate who sees both the good and bad, while Josh sees it as a tidal force in the security market space, and not one he likes.  Where PCI points, the money goes, like it or not.  But this talk won’t just be about PCI, we’ll talk about compliance in general, the good, the bad and the ugly. 

If you, by some chance, are around at Noon on Sunday, come see the discussion.  The question I have for the audience is simple, “How has compliance affected you and/or your company?”  Has it’s affect been positive or negative? Given the crowd we’re drawing our audience from, it could generate some very interesting responses.  I’m curious to see how a group that collectively thinks of themselves as hackers feels business attempts at compliance frameworks really affect the work they do.  I expect to hear more annoyance with compliance getting in the way of real work than anything else.

This should be a fun way to end Black Hat and Defcon.  Josh and I really haven’t had it out over whether compliance being a market force is a good thing or a bad thing and this is a good venue to draw him out on the subject.  I’m looking forward to it.

“I think it’s surprising that PCI still hasn’t developed a program to certify pen testers or at least standardize the approach”

In reply I stated that given the level of certification for ASV’s (Approved Scanning Vendors), I’m just as happy if the PCI Council would stay out of the business of certifying pen testers or creating a standardized approach.  In reply @secrunner asked the following:

“In the spirit of PCI, isn’t even some standard (even a low one) better than none?”

The answer is, no, it’s not.  To be more specific, my answer was “Low standards for a merchant are better than nothing.  Low standards for a vendor are misleading at best, dangerous at worst.”  Let me explain why I think this way:

When you go shopping, one of the last things on your mind is probably “How does this merchant protect my cardholder information?”.  It’s one of the first things I think of, but that’s what I do for a living.  Most people are just concerned about if their merchant is going to have their size or the best price on the new toy they want.  They just assume the merchant has taken the necessary steps to secure their cardholder information.  And if they haven’t, consumers know that they’re only responsible for the first $50 dollars worth of fraud, and even that is usually absorbed by their bank or credit card company.  Sure, getting a new card issued to you is a bit of a hassle, but for most people it’s something that’s over and done with in a few minutes.

In this case, security is assumed and is not the primary concern of the person doing the purchasing.  A default standard such as the Payment Card Industry (PCI) Data Security Standards (DSS) is important and useful because it gives a baseline level of security for the industry to meet.  It may not be the level of security the company really needs to protect themselves, but all too often this baseline is more than the company was doing prior to the standard.  It may not be perfect security, but at least it pulls you up from the level of ‘low hanging fruit’. 

Certifying a vendor as a ‘compliant’ or ‘certified’ is a completely different story.  When an industry group such as the PCI Council makes a standard for a class of vendor and then certifies these vendors as meeting a certain baseline, this certification becomes one of the primary influencers in the purchasing decision.  Using the ASV certification as an example, a merchant won’t even consider a scanning vendor for their company unless the PCI Council has already certified them.  The merchant has to use a vendor who’s been certified otherwise they can’t submit the scans as part of their own compliance.  A large part of why this works is that external scanning of web sites is a fairly well understood, repeatable and, most importantly, testable process.  It can be easily automated and running the same test against the same site ten times will generally generate the same results every time (okay, maybe 90% of the time)

Penetration testing is an entirely different issue.  Yes, there are automated tools.  Yes, some pen testers don’t go much beyond that level.  But the good pen testers I know treat penetrating a company’s defenses more like an art than a science.  Metasploit and other tools are their paintbrushes, but it’s the person who’s using the tools that is actually making it possible to find the vulnerabilities in your company so that you can shore up your weaknesses and prevent someone else from finding them.  This isn’t a process that easily documented, standardized or testable.  It might be something you can do on a person by person basis, just as the PCI Council does for QSA’s now, but it would be nearly impossible to do for a company.

Let’s be honest, in the PCI-DSS, the idea of ‘penetration test’ is barely even defined.  It has to have a network portion and an application portion, but the how’s and what’s of penetration testing are left up to the QSA to verify and validate.  There’s no agreed upon standard in the industry of what makes a pen test a valid and acceptable pen test, let alone within the PCI community.  If the PCI Council wanted to certify pen testing companies, the first major hurdle they’d run into is making up that definition.  Then they’d have to come up with a way of testing companies’ adherence to the standards and create a certification program.  This would be a huge battle to undertake and the benefits would be minimal. 

Right now, it’s up to market pressures and QSA’s to determine what’s a ‘real’ penetration test.  If someone created a penetration testing certification there’s only one group of people it’d help:  marketing.  Most merchants wouldn’t read the requirements for the certification, they’d just use the certification process as a check box to weed out potential vendors.  And I can guarantee that the marketing teams would love that.  And I doubt it would make the results of penetration tests any better; in my opinion it would simply mean that most companies would ‘dumb down’ whatever they’re currently doing so that it met with the minimum standards and no more.  I much prefer seeing the merchant who’s having the pen test performed ask questions about exactly what’s going to be done and try to understand what they’re getting themselves in for.

One point Vik wanted to make that didn’t make it into the podcast is that the 0day that was used in the Aurora attack is not just being used against corporate targets.  It’s being used against consumers as well, so it’s important that the average home user be aware that their AV product may not be protecting them at this point.  What is part of the podcast is a discussion of how many AV vendors are trying to protect against the payload that malware is attempting to deliver, not the exploit itself.  Both are important points people need to be aware of.

Network Security Podcast, Episode 189, March 16, 2010
Time:  39:56

Show Notes:

• Vulnerability-based protection and the Google “Operation Aurora” attack
• NSS Labs’ Questionable Report – Note that the screen shot shown is of the Firefox browser, not IE in any form
• AVG & The Aurora Exploit
• Questionable Questions (and some answers)
• 7th Annual ISSA Security Conference
• Please take our short listener survey to help us create a better podcast!

In a lot of ways, Mykonos appears to be a standard WAF; it can be used to protect your site from many of the standard coding errors that a WAF is designed to deal with.  It addresses the OWASP Top 10, it has all the reporting capabilities to tell you something’s wrong; in this area it doesn’t appear to have a lot of extra punch you can’t get elsewhere.  The place it does start to have some distinguishing capabilities is in the tracking, categorizing and response to malicious attacks on your web site.

You want to know more about who’s probing your web site?  Mykonos will dynamically modify the code your site is serving to get you more information on who’s attacking.  It’ll tell you about the level of sophistication of the attacker, whether they’re just trying to manipulate a price in the shopping cart, if they’re trying a SQL injection attack or if they’re working on something at the higher end of the attack scale.  And it gives you a lot of choices about how you want to respond; simply block the user, send custom code telling them they’ve been identified and logged or act as a honeypot to get even more information about the attacker and how he’s planning on attacking your site.  The tracking and information gathering abilities seem to be pretty impressive and it may be worth looking at for that alone.

Mykonos looks like more than a plain vanilla web application firewall and the downside to that is it requires more work from the administrator and more work from your developers to make full use of it’s capabilities.  This also means it’s potential for becoming shelfware is much greater as well.  But if you’re looking for more than what a standard WAF offers, it might be worth looking at this product.  And once you do, I’d appreciate feedback on your impression of the product.  Is Mykonos a potential new product market, a single product with greater capabilities or just a flash in the pan that won’t amount to much?

I’ve said it a number of times in the last week, but it bears saying again:  If you’ve jailbroken your iPhone, change your iPhone’s root password immediately!

By the way, I don’t know anyone who’s jailbroken their iPhone in order to access pirated software, everyone I’ve talked to did it so they could install software that unlocks capabilities that Apple doesn’t want us to have in existing apps, for example tools like xGPS and SBSettings.

How to Change the iPhone’s Root Password

A Dutch hacker has started breaking into iPhones that have been jailbroken and left SSH running with the default root password.  This enabled the hacker to log into the iPhones and send the owner a message telling them their iPhone is insecure.  It goes on to give them a link and asks for 5 euros in order to secure the phone.  This has been sighted on a relatively few iPhones so far, but it’s not inconceivable that this could be weaponized and used on a much wider scale.

This just highlights that the act of jailbreaking your iPhone or hacking any manufacturer’s device places the onus of securing the device back on the owner rather than on the manufacturer.  I have no problem complaining about companies like Time Warner who’ve consistently given their users given their users insecure routers.  The company is supplying and configuring the device, the responsibility (and the power) to secure the routers is theirs and theirs alone.  The user has no ability to make changes and in most cases, probably doesn’t know much more than how to plug the router in and turn it on. 

But once you’ve taken the steps to jailbreak an iPhone or hack your router, you’ve relieved the company of that responsibility.  It may not take much, but if you’ve done the necessary research to download the tools to free your device, you are also taking on the responsibility of securing the same device.  So take the time to do a little more research and figure out what steps you need to take beyond just jailbreaking to secure your iPhone, or whatever device you’re hacking into today.

We don’t know exactly how the NYT site was compromised and this code implemented, but there is a good analysis of the malware at Inputs & Outputs.  The ad used a scare tactic but by itself it didn’t do much.  But this phishing scheme did point users to a small program that probably did some very interesting things to the end user’s computer if you believed you actually were infected.  If you’re a Firefox user with NoScript installed, you probably didn’t even notice that this fun piece of code had been added to the NYT site.  Score one more for blocking scripts by default.

Looking at the analysis of this compromise, it appears that the code wasn’t directly on a NYT server, rather it was served up by one of the third-party services that provide ads for the NYT.  Once again, it shows that even if you trust a particular site you’re visiting, the interaction between that site and the secondary systems supporting it offer a great attack vector for the bad guys to gain access through.  The New York Times probably has a great security team who’s up on the latest vulnerabilities and does an excellent job protecting their site, but if the other companies they rely on for additional code can’t protect their systems, even the best team at the NYT won’t be able to do a thing.  It’s something for anyone who relies on third-party code on their site to think about.

It’s a little surprising to me that one group of hackers is connected to so many high profile breaches, including TJX, OfficeMax and Dave & Busters.  Are they an isolated group who managed to find a way into these networks or are they just the group of hackers that was stupid enough to get caught?  The possibility that these guys are just the hackers who were unlucky enough to get caught worries me, since their capture may lead a number of security professionals to breath a sigh of relief and get back to life as normal.  Which means arguing with management to get new tools and toys for the network while ignoring serious configuration errors like having SQL command execution enabled on transaction servers.