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

Two talks at RSA last week helped galvanize a concept for me that has been kicking around unverbalized in my head. I have long thought that things like CSRF are problems that developers *shouldn’t* need to worry about – they are a fundamental design issue with the web that requires custom coding in each application to rectify. This holds true for many (all?) of the other implementation level issues as well. Our strategy for application security is to make developers aware of all of the potential problems and put the responsibility on them to code around the problems because we haven’t come up with a better option (but we have, and I will get to that). The art of writing code is simultaneously seeing the big picture and the small picture – understanding how each individual statement builds towards bigger functionality. That alone is a fair amount to simultaneously track, and every concern or complication that the developers have to be aware of at the statement level increases the chances that they will make a mistake.

Brian Chess (of Fortify Fame) gave a great talk last Monday at RSA as part of the AppSec symposium, where he discussed why Buffer Overflows still exist even though we know the technical cause. He had a great demonstration of how many decisions a developer needs to make in a single line of code to get some derivative of sprintf to be safe from an overflow (it was either 6 or 8 decisions, for what amounts to a pretty simple buffer transfer). That was the eureka moment for me, where my own thoughts came together – the cause of Buffer Overflows isn’t buffer manipulation per se, but rather that the developer needs to simultaneously be aware of many conditions and get every single one of them right. How many other implementation level vulnerabilities are the same way? We know that managed languages mostly cure buffer overflows (edge cases like the C# Unsafe keyword not withstanding) but I think we chalk up the reason why to purely technical concerns. What we miss is that the technical concerns are a result of a coherent design decision – automate the memory allocation for strings so the developer never has to be aware of it.

The second talk that reinforced this was by Alan Karp of HP Labs. He was demonstrating an analog to email file sharing that hid all of the security decisions from the user; his little app automatically used SSL for all communications, automatically applied ACLs to the files being shared, automatically had user authentication built in to restrict file access, etc but look to the user just like the normal workflow for sending a file via email. In practice I don’t think we need one more way to share files, but as a demonstration of security concepts, where security is implicit rather than explicit, it worked.

Right now AppSec is very tactical. We are trying to fix the immediate problems through developer education and add on security frameworks, and as a stop gap that’s fine. For a strategy though, I think the various custodians of the languages/popular frameworks (MS, Oracle, SpringSource, the Apache Foundation, the PHP group, etc) should make a conscious decision to change the languages/frameworks to hide the default security decisions from developers in the exact same way that the move to managed languages hid buffer decisions. Add whitelist validation implicitly to the various parameter retrieval functionality based on the current character set, so that every time the developer accesses a parameter it is automatically sanitized (as an aside, I think languages should not automatically mix retrieval from Cookies/Get/Post variables). If the developer wants to deviate from the implicit input validation then have an unsafe version of the retrieval mechanism that they have to explicitly invoke (in the same way that you have to explicitly use the Unsafe keyword in C# for memory manipulation); that would still allow the current flexibility but it would make such a choice explicit for the developer and make flagging areas for manual code review very easy. Replace the current SQL with a query language completely immune to injection attacks (essentially something like LINQ); yes we have parameterized queries now, but they are an opt-in solution. I think languages or frameworks should instead move to opt-out solutions. Take the notions of ViewState the full distance to prevent CSRF (since they only *mostly* protect against CSRF now, and are obviously MS specific) and make that the defacto mechanism everywhere. And so forth for as many of the implementation level issues as we can. So long as we put the burden on the developer to get everything perfect they will continue to miss things, because humans just aren’t perfect. We need to move a lot of that burden to the languages or frameworks the developers are using, just as we did to get rid of Buffer Overflows.

Yeah, it will break a whole lot of backwards compatibility. Yes a migration path will be hard and it will only work if we can get people to migrate. But in yet one more RSA there continues to be a whole lot of talks about how we are still losing at AppSec (with folks like Verizon providing hard data to prove it), nothing but false promises from vendors to fix the problem, and the best strategies (education and verification tools) being no different from 5 years ago. I think more drastic and ambitious attempts are really in order.

~ Joshbw

Microsoft has released a RegEx fuzzer and I suggest that people check it out as it is reasonably nifty. Finding and fixing costly Regexes certainly has a great deal of utility.

That said, I have a bit of an issue with a sentiment aired by Brian Sullivan in an SDL Blog Post introducing the tool:

“I’ve predicted before that as cloud computing gains wider adoption, we’ll start to see a significant increase in denial of service (DoS) attacks against those services. When you’re paying for the processor time, bandwidth and storage that your applications use, attacks that explicitly target and consume those resources can get very expensive very quickly, not to mention the costs of downtime for legitimate users. Attackers will shift from pursuing elusive privilege elevation vulnerabilities to simply blackmailing SaaS providers: pay me $10,000 or I’ll make your app consume $20,000 worth of server resources,”

This should not be the application’s problem. This isn’t an attack against the application, but rather against the Cloud Providers’ business model and it isn’t reasonable to offload the responsibility for reducing exploitation scenarios onto the App Developers. Just as the basic business model make credit cards susceptable to fraud and thus most (all?) Credit Card providers accept the risk for that fraud instead of pushing it onto customers, the Cloud Provider should adopt the same stance. Admittedly the application design impacts the ease of carrying out fraud with regard to cloud providers, but the consumer’s practices influence fraud the same way for credit card companies. Not only is it appropriate for Cloud Providers to assume this risk given that the exploit is in their business model, it is in their best interest. Should extortion tactics hypothesized above see any widespread adoption the long term impact is going to be on the confidence in the Cloud model. The bottom line hurt by that impact isn’t going to be consumers of the cloud, but the providers. By assuming the risk, rather than passing it off to customers, Cloud Providers may suffer increased cost per customer, but they will not losing customers due to a lack of confidence in the basic service model.

~ 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

WhiteHat security has recently released a paper where they attempt to answer “What is the most secure programming language or development framework available?”. There are two very good responses to the paper from Michael Coates and pInvoke which are well worth the read.

Ignoring the multitude of issues with the actual methodology (scientists WhiteHat is not – if this paper gets published in a proper journal that journal has some low standards) I have issue with the actual question. What on earth do they mean by “Most Secure Development Language/Framework”? If they mean the language or framework whose runtime or libraries will most likely have attempts to break the framework or language that will already be a hard thing to measure. Do you measure the NVD numbers for vulnerabilities discoverd in the language or framework (PHP I think you lose Mr. 18,000 and counting), the severity of the vulnerabilities, the exposure window between discovery and fix, effectiveness of patches to address the issues, etc? How do you create a metric when the Linux and Windows, Firefox and IE teams (and really every internal AppSec organization in an enterprise) have been argueing over a good metric for ages with no agreement. That said, having some measure, even if not agreed on, is a useful thing because the security of an internet facing application isn’t just dependant on the code an enterprise writes, but also the 3rd party code exposed to the internet. It would be useful to know how Tomcat stacked up to WebLogic in terms of security while I am making my decision of which server runtime to use.

That would be a literal interpretation of “Most Secure Language/Framework” because you are measuring the security specifically of the runtime/framework code. Whitehat does not mean this however. What they mean is which language will produce more secure websites, which is neither an appropriate question to ask, nor one that they have answered reasonably (see two other links above). Thinking completely ideologically, a better question would be given the following languages and frameworks, which will prove to take my developers the least amount of time to implement the following product with a minumum of critical, high, and medium severity vulnerabilities? Do the languages have features that make defending against certain vulnerabilities significantly easier and less time consuming, and thus save me development costs? Do those security features come at some cost that increases development time elsewhere? Alternitively, are their design decisions in the language, or a lack of features, that have to be engineered around to make a secure site, and how much time does this cost (for example, PHP before it had prepared statements – that is an inherent handicap).

An incredibly competent and methodical C-coder could make a CGI based website just as securely as an incredibly competent and methodical C#-coder could make a MVC.net 2.0 website. The C-coder certainly has a heck of a lot more hurdles (a little something called buffer overflows, for starters) but there isn’t a technical reason that makes certain vulnerabilities absolutely unavoidable. If I am making a language decision for my enterprise the fact that it isn’t technically impossible to make a secure website in a particular language doesn’t matter to me – what matters is that it is going to take the C-coder many times as long to spit something out as the C#-coder. So the useful question isn’t “Which language/framework is more secure” but rather “Which language/framework makes it EASIER for the coder to produce a secure website, and do so quicker” and the WhiteHat paper doesn’t address this. In fact their methodology makes answering that question impossible. The only real test would be to stack up balanced teams of comparable skill at each language and have them implement the exact same website, then measure how fast they produced the site, how many vulnerabilities were initially detected by equally balanced pentesting teams, and finally how quickly it took to fix the vulnerabilities.

I don’t see that test happening soon because that is a fairly non-trivial amount of work. It also would only tell you something about that specific type of application. A website with dramatically different design considerations, or a web service, or other type of application may not have the same results. That said, in general I agree with pInvoke in his writeup above that the Microsoft stack does offer some very obvious built in advantages, from preventing CSRF (encrypted view states, to my knowledge the only framework with such a protection built in) to the trivial input encoding, that can be compared to other languages without having such a thorough experimental design.

All of that said, for any given organization the languages that are probably the most secure are the ones the developers are most comfortable writing code with. Forcing a PHP developer to write mvc.net code because you feel it is more secure is a mistake and will buy you nothing but a longer development cycle. (exception – if your coders still swear by CGI you really are better off forcing them into something invented in the past decade even if they will have a learning curve. You probably shouldnt’ have let them be so resistant to change to begin with).

~ 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

An old and well worn addage is “Do as I say, not as I do”, generally in a fit of hypocracy when the listener is asked to ignore the example being set by the speaker. The fallacy of that statement was addressed by the series of “I learned it by watching you” advertisements trying to drive home the point to parents that children are more likely to learn from example than from what the parent says.

In the Applications Security space we are big fans of telling developers what they should and shouldn’t be doing in order to produce secure applications, which is all well in good so long as we are not violating those very same instructions within our own properties. If developers are visiting their enterprise’s security portal and see examples in practice contradicting the secure coding and design standards on display on the very same portal, it completely undermines those standards.

Having raised this more than once and been given a liteny of excuses of why it is acceptable (there isn’t anything of value on this website, we wanted to get the content up now and we can always go back and fix the problems, it is only for internal employees anyway, etc), the same excuses that developers of any other project will put forth for why they don’t need to build security in for this release, I really wonder about the effectiveness of the message the application security community is trying to convey. If we can’t even get our own organizations to embrace our suggestions, obstensibly folks that “already have the religion”, what is our hope of getting converts to that message elsewhere.

So for various security organizations, the risk profile of your application is not an acceptable excuse to ignore your own security recommendations; if you are not going to abide by your own mandates do not bother asking others to do so. “Do as I say, not as I do” is a very ineffective strategy. Developers WILL notice your lapses and no amount of trying to create a justification of such a lapse based on the risk profile of the application in question will buy you any crediblity to restore that which was just lost. The risk is not to the confidentiality or integrity of the application, but rather to the integrity of the message the security organization hopes to convey. Even if the underlying message is completely valid, a kid being told by a parent presently working through another pack of cigarettes for the day isn’t going to buy that they themselves shouldn’t smoke.

And a special message to OWASP, the same applies to you, and your various caveats throughout your website do not make it ok to ignore your own advice. Saying

“You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. “

when subscribing to a mailing list is not OK. It doesn’t matter that there is little security risk even if someone does compromise the password – the entire point of this post was to establish that security risk is not the only consideration. You undermine your message when you choose the easy route – why should I hash my passwords when it is obvious OWASP, whose job is communicating security, doesn’t think it is important that they do.  Similarly, I think it would be great if you set “AUTOCOMPLETE=off” on your login form, like you suggest in your various coding recommendations, and similarly switch to a generic message if either the username or password is wrong, rather than telling me that specifically the username or password is wrong. Incidentally, MediaWiki would be all the better if you had those changes adopted into their mainline branch, which is the least you can do having leveraged the project.

~ 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