Archive

Monthly Archives: August 2011

I’ve long held that one of the best ways of securing ones’ data/functionality is by making them worthless to attackers. If SSN wasn’t the primary key to the US consumer credit system then systems could collect it without much concern, because there would be little incentive to try and compromise the system for SSNs. There are a lot of different entitities that have an interest in compromising a given system, but outside of anarchists/hacktivists (and seriously, at least in the West can we tell the difference between the two anymore?) and parties out for some form of revenge pretty much all of the other threat agents are financially motivated. If their ROI attacking your system/app doesn’t make sense they aren’t going to do it.

Given that, I can’t help but wonder if the benefits of Blizzard Entertainment’s decision to use cash transactions for In Game auctions of Diablo III are going to be worth the headache it is going to generate for them. For those who don’t understand the context of the last sentence, Blizzard is the maker of the wildly popular World of Warcraft (or WoW) and is about to release another mega-hit game. WoW already experiences extensive account compromise attacks, to the point where Blizzard actually provides two factor authentication to a freaking computer game. The reason is because they created a scarcity driven economy within their game, so there is a lot of real world money that can be made by compromising an account and selling of the possessions of the characters in the account. There are a number of hurdles that need to be jumped through to do this, but the payoff is enough that people are encouraged to do so anyway. With Diablo III they are removing many of those hurdles – instead of selling items on ebay you will be able to sell them directly in the game for cash money. In fact, you will only be able to sell them in the game for cash money – there won’t be “gold” that players can swap for items anymore. On the surface this makes a heck of a lot of financial sense – Blizzard is going to skim a fee for posting an item for auction, for bidding, and off of the final sale price. If they hit anywhere near the userbase of WoW there are going to be a lot of transactions that Blizzard is going to be skimming.

The thing is, it is also going to dramatically increase the incentive for account hijacking – if I can spend real world money in the game then that means the game must have access to my real world money. Creative thieves will be able to steal real world assets from inside a fake world, as well as the fake assets of the fake world that they can sell for real money. So I really have to wonder if it is going to be worth the headache for Blizzard – will the amount of money they make off of the auctions balance out the fallout from increasing the ROI for attackers? For the rest of us I think we are going to have an object lesson in why we should try and minimize the incentive for breaking into our apps. (or I could be wrong and Blizzard could have really engineered a system that is hard to compromise, making this whole post moot)

~ Joshbw

Having just returned from Blackhat I have a wealth of topics that time permitting I may articulate under the arrogant notion that random people on the internet have some interest in my thoughts. Pertinent to this post is the ever popular habbit of PCI bashing at security conventions. Having thought of this, I think in some ways PCI is incredibly effective – wait, don’t go, just hear me out. Yeah, the PCI assessment process has a lot of shadiness, with various security service providers assessing areas where they have a vested interest in selling products. And yes, it’s fairly questionable that card data would actually be secure even if all of the controls were followed (your are in compliance until you have a breach, and then you are not), or that the card data wouldn’t be secure even if the controls weren’t followed (many ways to do things after all). And yes, there is a question as to whether said control list is updated often enough, or in the same breadth, too often. While we are on the topic there is criticism that the assessment process is pass/fail, rather than a graded rating that is publicized, and on and on. Mostly people think PCI is a giant pain in the ass.

That, by the way, is where I directly see the utility. PCI compliance really is a huge pain in the ass for a company – nobody actually wants to bother. And because of that companies large and small are getting out of the business of needing to be PCI compliant. They are offloading to a 3rd party processor to handle all of the card transaction stuff – essentially the paypal merchant model at scales much larger than mom and pop websites. While at some distant point in the future there is a worry about sufficient payment processors to offer competitive pricing (just like right now the huge market penetration of the actual credit card companies allows for some fairly predatory pricing), for the time being it is a great trend to see a consolidation of payment processing to fewer vendors. Rather than 1 million online vendors getting every security protection right I have a lot more confidence that a couple dozen vendors whose focus is on delivering that sort of service securely.

Put another way, for as evil as the big three credit agencies are (and one of them is responsible for some incredibly sketchy mortgage and student loan advertising scams), would you rather have those three agencies, or would you rather have thousands of companies creating independent credit databases of all your info for their individual use? While I question the big three I would much rather it was just them than every furniture store, car dealership, mortgage broker, bank, appliance company, etc. trying to secure their own versions of the databases. In the same way I think it much preferable to have only a couple companies securing card data – because it is really inconvinient to have to call my bank to cancel charges and wait the 7-10 days for a new card because some random website had their card database hijacked (and my bank probably finds eating those charges pretty inconvinient as well).

- Joshbw

Matt Johansen and Kyle Osborn had a well delivered talk at Blackhat on hacking Google ChromeOS. For those not familiar with ChromeOS it is essentially an OS made up only of the Chome web browser – Google asserts that this creates a malware free operating environment which is not quite accurate as the talk showed. Since ChromeOS lacks any other native app Google has introduced extensions that are what amounts to little weblets with API access to Chrome (Javascript that doesn’t just control the DOM but also the, uh, the chrome/shell of the browser) to provide an app concept that sits between the notion of a native app and a website. The crucial (for this talk) consideration is that these extensions are not sandboxed in the same way that a normal website is – they can create and interact with other tabs, regardless of the domain origins of that tab. Showing what could be done because of this, Matt and Kyle demonstrated that by either subverting a vulnerable plugin (including a google authored scratchpad that has since been fixed) or by putting out a malicious plugin in the extensions market they could essentially compromise any website the user visits (or had visited and still has an active session for). Extensions allow you to inject code into an open tab (and to open tabs and navigate them to a particular page), which means the integrity of any website can be compromised on the client.

What this really means is that malware won’t be barred from ChromeOS – it will simply need to evolve. You will still have trojans, just in the form of malicious extensions hosted in the Chrome Extension market rather than hosted on random websites (and hey, we already seeing closed markets hosting trojans – just see Google’s Android market). It’s still going to have exploitation of installed vulnerable software, just in the form of vulnerable extensions rather than vulnerable apps. That isn’t to say that everything is the direct mirror of the desktop world, but rather simply an illustration that the more permissive you allow running third party code the more malicious actions it can perform (which should be self evident). By being fairly permissive with extensions ChromeOS allows for several exploitation scenarios – they could lock down what extensions do (cutting off API access to tabs for example) but in doing so they also cut down what legitimate extensions are capable of. What the talk really illustrated for Google are lessons that MS is plagued with – no matter how awesome your own security you are still impacted by the permissions you give the third party code a user wants to run, and the security of said third party code.

~ Joshbw