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

Mozilla has expanded their Plugin Check page to cover more than just firefox, now including Chrome, Safari, Opera, and to a limited extent, IE. This is an awesome good citizenship concension, so bravo Mozilla. I think it is a great step to building awareness about keeping plugins up to date, especially as they are getting to be a much more common attack vector than the browser itself.

That said, the other large hurdle is the actual process of updating that many vendors have. To be polite, Adobe’s updating software has quite a bit of room to improve. I went to install a photoshop update earlier today and it required me to shut down all office apps, all web browsers, and all open explorer windows. Acrobat is only slightly less anal. And yet, I can run Microsoft Update in the background and install updates specifically for those applications without having to shut them down (the system does ask to reboot, but I can just wait until the end of the day to do that). When an updater requires that a person basically stop using their computer until it is done people are not going to update. I don’t want to have to stop everything I am working on, pause my work and my train of thought, because Adobe has issued an update, and I suspect most users are the same. Until that changes, people are going to put off updating and Mozilla is going to have a hard time getting above that 60% up to date mark that they have currently reached.

As an aside, FileZilla, when I am prompted for an update literally every time I run your application your patch release process is broken.

~ Joshbw

Microsoft has made a little game of threat modeling, with details here. The idea is that by printing particular scenarios on cards and creating a competition to figure out how each scenario can be applied to an application model a development team will be reasonably effective at finding threats (I would add that if you put in some prize people will be extra competitive). Having looked through the deck they do a good job of enumerating common scenarios for each stride element – it isn’t exhaustive, but it covers a good deal of ground and should provide good guidance to product staff that are not accustomed to thinking about attack scenarios. It’s a clever way to approach threat modeling with folks that are probably not well versed in it.

That said, a couple comments -
• The “Instructions 2″ Elevation of Privilege Variants offer some suggestions I think should be in the core rules, specifically that each player can “riff” off of a card played by another by suggesting additional ways a threat could be applied and get an additional point for each new valid scenario. As soon as I watched the video in the link above explaining the game the first flaw in the game I thought of was that only one person is really considering how a given threat might be applicable. Anything they miss won’t be necessarily documented. By allowing other players to get points by also considering a threat and contributing possible attack scenarios it increases the potential analytical coverage of the application.

• Like the more mundane threat modeling process the diagram of the application is incredibly important. A diagram that doesn’t model all of the data flows is going to cause people to miss threats. A diagram that is too high level, or abstracts crucial details (for example a series of components collapsed into one entity, and as a result hides a trust boundry), is going to be a handicap. A diagram too detailed, that shows unnecessary elements, is also going to be a handicap because it presents more information than humans are good at tackling at any given point. The application diagram is the most critical part of the threat modeling process and whether you use the game or the recent threat modeling tool (which is so much better than the first gen tool I used at MS that pulled in DREAD, risk trees, etc) or have a hack session on a whiteboard, if you don’t draw a good application diagram you are going to miss threats. What I would love to see MS do is release training videos specifically trying to provide guidance on the creation of data flow diagrams.

• and yet again I am disappointed by Microsoft not trying to leverage their multiple platforms in some semblence of synergy. Just when WinMo 7 looked to finally tie the xbox, zune, and phone together, when it looked like MS finally got it, they go and do a stunt like this. Paper cards when you have the best online multiplayer system in the world Microsoft? Really? This should really be a free download on xbox live arcade, with achievements and avatar prizes. Adam, if you are reading this, drop me an email. I can put you in contact with some folks in xbox – my old manager works there now, as does his old manager. You can get this done.

Anyway, for those of you looking to get threat modeling in your organization (and you should – it is the best methodology I have found for doing design level security analysis) this is a good starting point. Apple, now that you have hired Window Snyder and may finally be taking security seriously, you might want to check this game out, even if Microsoft made it. It is released under a creative commons license, so you could even make it into an iPad game if that is what it takes to get you to finally threat model Quicktime.

~ Joshbw

Couple random thoughts, observations, stuff:

Last night my wife wanted to pay her Sprint bill – she didn’t want to get up and go down stairs to grab her purse and credit card so she asked me for mine and I just tossed her my wallet without thinking. Rather than grabbing my dedicated credit card out she grabbed my debit card, which wouldn’t have been my preference (easier to dispute credit credit card charges if necessary). I was prepared to start answering the various interrogation questions necessary for a card purchase, since the CVV code is intentionally missing from all of my cards (no need to make it extra easy for a would be pickpocket), and was sort of suprised that she didn’t need any information other than the card number. It turns out Sprint uses the STAR network with debit card transactions and all it needs is the credit card number – how is that a good thing? Credit cards are already great theft targets since you only need a couple pieces of information to charge them – I don’t think reducing the amount of information is wise. In Sprint’s defense, only a moron would place a charge with a stolen card on their own account, but in terms of industry trends I can say that offering debit transactions with just a card number is one that I feel should continue.

Unrelated to that, the vast majority of blog spam that gets trapped by the filters at the moment is related to amoxicillin ads – what the hell? Can someone explain the psychology behind that to me? First, amoxicillin is an antibiotic – typically something you are using because you went to the doctor, found out you have an infection, and want medicine sooner rather than later; it is also something you only take for a short period (what, 5 days or something like that) and don’t renew – how is that a good candidate for mail order? On top of that its about the cheapest antibiotic known to man – it isn’t like Walgreens is charging $50 for it after insurance. Last time I needed to pay for amoxicillin it couldn’t have been more than $5. Are people really looking to knock that price down even further? What makes it good chum for spam fodder?

Well, those are my deep thoughts for the day, cheers,
~ Joshbw

There is an interesting writeup on the Reddit blog about the particular vulnerability that lead to their exploitation. In general it is a reasonably informative writeup that delves into their mistake and I wish all security flaws recieved such an informative writeup (You occassionally see Michael Howard delve into details on a Microsoft vulnerability, but it is hardly the norm).

That said, there is a bit of silliness in one of their quotes:

As a matter of fact, these bugs were only exploitable because we are open source. The worm author had to scour the source of our output filter to find these holes. We cannot hide behind security though obscurity, and we like it that way. We also rely on our users reporting security bugs in a responsible manner.

There are a lot of reasons to choose the OSS model and extol its virtues, but it is craziness to PREFER that malicious users have access to the source code and thus have an easier time finding flaws; its a trade off of the OSS model for sure, and you can’t have the good without the bad, but I think largely it isn’t unfair to say that folks would be happier if only well intentioned individuals had access to the source code (save for Stallman, but he also believes a person should be more proud of contributing to the Linux kernel than raising kids so I think we can religate him to fringe nutjob). One could argue that it puts added pressure to fix even seemingly small issues because of public scrutiny or other such philosophies but at the end of the day that statement ultimately amounts to Reddit prefering the greater risk. That is not to say that the benefits don’t outweigh the risks for a particular company and a particular business model but from a standpoint of avoiding the exploitation of vulnerabilities security controls + obscurity is better than just security controls. The less an attacker can know about you the better you are; you can’t *rely* on them being ignorant of you but at the same time it is always better to try and keep them in the dark.

Obscurity alone does not ensure security, hence the various statements about security through obscurity being a fallacy, but it does have security utility (and indeed necessity at times – your encryption is only secure so long as your key is obscure). Obscurity raises cost for an attacker, all other factors being equal, since it increases effort to remove the obscurity. If two sites seem to have strong input and output controls and I want to break into either of them, I will choose the one with open source code because it will take me far less time examining code for flaws than trying esoteric attacks in the hope one sticks (and similarly increase the chances of tripping any IDS or IPS solution deployed). Thus being closed source in that regard has benefits. Indeed, if Reddit had been closed source the likelihood of this vulnerability being exploited would be far lower; the code would still be vulnerable but the cost to find that vulnerability is such that the attacker would probably spend their time elsewhere.

In the end obscurity doesn’t ensure security but it does reduce risk. Risk is the product of likelihood and impact, and obscurity does decrease the likelihood – it doesn’t reduce it to 0, but it does decrease it. That’s why most Pen Testers will write up any unneccessary disclosure of information, even if it is just server tokens, because it is BETTER to be obscure than not from a risk stand point.

And just to be a bit snarky, if Reddit really didn’t believe in Security through Obscurity they would favor Full Disclosure over Responsible Disclosure. The latter hopes to obscure the details of a vulnerability until it can be fixed while the former has no obscurity to speak of. Of course it also means the chances of a maelevolent party exploiting the vulnerability increases but that was pretty much the point of my post anyway.

~ Joshbw

This is a great article on some of the pitfalls of the security mindset – the post is essentially based around the quote “The more secure you make something, the less secure it becomes”. A quick snippet:

I recently attended two conferences on Usability, Security, and Privacy. The first, SOUPS (Symposium on Usable Privacy and Security), was held on the Google campus in Mountain View, California, the second at the National Academies building in Washington, DC. Google is a semi-restricted campus. People can freely wander about the campus, but most buildings are locked and openable only with the proper badge. Security guards were visibly present: polite and helpful, but always watching. Our meetings were held in a public auditorium that did not require authorization for entrance. But the room was in a secure building, and the toilets were within the secure space. How did the world’s security experts handle the situation? With a brick. The side door of the auditorium that led to the secure part of the building and the toilets was propped open with a brick. So much for key access, badges, and security guards.

Recently I encountered a policy that obviously dealt with user circumvention of security controls. It was the typical draconian AD password policy – 8 characters, upper, lower, numeric, special character, no repeats of the previous 24 passwords, change every 45 days, yadayada. On the surface the policy makes sense – it is sufficiently long and complex enough to prevent brute force, and the requirement to change the password and not repeat it should prevent any termed employees from having unlimited access to shared accounts. There are a couple other measures in place – every client has software that extends the normal delay Windows inserts into a failed login attempt to an even more annoying time (seriously, first failed attempt – 30 second wait, and it just goes up from there) and the AD will delay authentication as well, so brute forcing is already a bit impractical. A termed employee who is of the mindset to abuse a shared account that they still have access to isn’t going to wait 45 days, they will abuse it in a week.

In general I am fine with the policy myself as I can generally remember an esoteric string of characters fairly easily, provided it is within a short period of time of first being exposed to it or I have used said string three or more times. I think I am probably an exception. Many people, when faced with a complex password are just going to write it down, making the system much less secure. Clever people who dislike the policy will change the password 25 times in a row so they can just go back to their old password, and so forth. Unfortunately for the latter category there were equally clever AD policy setters who decided that a password cannot be changed if it had already been changed once in the previous two days. Arguably what this has done was cause people who had committed ONE secure password to memory to now either use variations of the same password (which really achieves very little – someone who knew the password was Secret!01 is naturally going to try Secret!02) or to be one of those folks who just writes it down.

And then there is the little scenario that cause me to think up this whole post. I had access to a shared account. It was set up quite a while ago so that we could grant access to a server for folks in a different AD hive without creating seperate users for each (which is lazy and not great practice, but they only need access for a small window at which point the password can be changed). I immediately changed the password after the account was setup, since the default password sucked, for a number of reasons. Unfortunately the folks that were actually going to use the account weren’t ready for it for a decent period of time, and by the time they were ready I had forgotten the password, as I never used it after that initial change (first thought from me – “Crap, I should have written that password down”). I ask our friendly admins to change it, and they do – to “Password1″ (not sure how they got passed the requirement for special characters), email me said password, and ask me to change it. I immediately go try, but since the password was changed in passed two days, I can’t. Hurray draconian password policy, because of you now I have to wait until tomorrow to update the password. Granted a two day exposure window for a crappy password isn’t a huge deal, especially since outside of a test SQL server and a webserver it has no access, but it does demonstrate that in our effort to make something *more* secure, we can be counterproductive.

So when deciding what security controls to put in place I think it is a good idea to not just look at the surface. One question I have not heard asked at very many design meetings of security controls is “How will the control we are implementing end up working against its own intent?”. One way a control will be its own undoing is if it sets up security as the enemy of the users, because then the users will invalidate the control. “Make me change my password to something I can’t remember – well my good friend post-it will remember for me.” “Make me buzz in all my friends at the conference just so they can use the toilet, then I am going to prop the door open”

~ Joshbw

How do you make a web browser, already one of the most common attack vectors against a client, even less secure? I know, add a web server and have it serve up the whole damn client file system! What a great idea!

Is Opera insane? What does the Threat Model look like for this thing? Opera, you do know what threat models look like don’t you? You use them right?

~ Joshbw

So here is a hypothetical -

Say a small real-estate agency is using a simple PostNuke website (which is out of date) to gather rental applications – applications with all of the information necessary to both verify (and apply for) credit as well as history of passed residences. In other words, say they were collecting all of the information necessary to completely ruin someone’s life should the information be disclosed, to tie the would be applicant up in years of financial pain and legal hardship as they try to clear the ID theft from their record.

Now say that the version of PostNuke was woefully out of date and moreover nothing was over SSL.

Hypothetically a security minded person sees this and tries to fire off an email, but gets no response. Then calls the agency up and tries to explain in person how UTTERLY HORRIBLE this practice is, but it is filled with luddites that have no place running a website that collects this information and they just don’t get it (either the technical ramifications no matter how simple they are explained, or the ramifications to the applicants). Those fancy sort of attacks only happen in the movies after all. At that point, how does the would be Samaritan lawfully get the problem addressed, as the agency is an active security risk to every person who has ever provided information to it?

On the larger topic, man is our society screwed. A person can completely have their credit destroyed (and thus many years of their life since living in the US without credit has some major implications – no car or house loan for you. No credit card, which you need if you ever want to rent a car, etc) because some podunk mom and pop website decided they needed a credit application and had no idea how to securely handle the data they collect. We seriously need a better mechanism for asserting our identity than a bunch of easily disclosed historical data but there seems to be absolutely no pressure to move to that (probably because the big 3 credit bureaus are terrified of losing some of their power).

~ Joshbw

From Acidus on Curiouser and Curioser – USPA 0090132950 – IBM’s patent on input validation:

The present invention discloses a system for providing real-time validation of text input fields in a Web page during text entry. Such a system can include a validation-enhanced text input element and an input text validator. The validation-enhanced text input element can be configured to contain a validation expression for a text field in a Web page. The validation-enhanced text input element can be contained in the source code document that corresponds to the Web page. The input text validator can be configured to validate a character entered into the text field against the validation expression in real-time. Characters determined as invalid can be visually indicated by the input text validator in the text field.

Hurray for our busted ass patent system. As Acidus says, IBM, go fuck yourself. It may not be a patent on all forms of input validation (notice the reference to “real-time” – this seems to suggest an AJAX powered system to validate input fields as the user is typing), but really any patent on input validation is a freaking mistake by the patent office.

~ Joshbw