Putting Vulnerabilities in Perspective

February 10, 2009
Secure Development

CGI Security via AppSec Notes complains that Netflix has not fixed all of their CSRF vulnerabilities. You can no longer access account information, billing information, change shipping address, or anything of value, but you can still add movies to someone’s queue. This apparently still bothers the author who has a note of annoyance that Netflix hasn’t completely fixed everything yet. I think this loses sight of realistic business goals of security- from an enterprise perspective one addresses security vulnerabilities in order to protect revenue or prevent damage. It is a cost benefit analysis, weighing whether allocating resources to address a particular vulnerability allows the greatest capitalization of those resources.

I’d posit that Netflix does not believe preventing CSRF attacks that add movies to the top of a queue to be the most effective use of those development resources. When looking at the impact and likelihood of this sort of CSRF attack the associated risk comes out quite low:

Impact- no direct loss of capital or resources, some level of brand damage. Some customers may very well be so pissed over getting sent some embarrassing video that they leave completely, which is a drop in revenue, however I would posit that these people are probably the minority. More people are likely to be pissed, complain, and probably get a free month as a token apology (loss of 1/12 of the yearly revenue for those people) but complaining smacks of efforts so I don’t imagine that this number will be horribly large either. Then there is the group that will be pissed and do nothing, no appreciable loss. Next is the group that is confused because they didn’t order that particular embarrassing video, no appreciable loss. Finally there is the outlier group that is hard to predict- the group where a couple gets an embarrassing movie, gets in a fight, and seperates over a movie (I live in a town where two middle aged men shot each other because of an argument over who parked their oversized SUV too close to the other oversized SUV, so I fully imagine there are people who would overreact to a movie). This might be a loss of a subscription, maintain the status quo, or a gain of a subscription because now the newly separated couple both wants a subscription, whereas they accounted for only one before.

There is also brand damage should this get media coverage once it is exploited. That is a hard thing to put dollars on.

Likelihood- For this to be exploited a customer needs to visit another website that actually carries out the CSRF attack. For that to happen the other website would need to choose actively to be malicious to Netflix instead of carrying out CSRF against a website that would allow monetary gain- there is no personal gain in exploiting this, only vandalism (which isn’t quite the correct word, but in the same spirit). The visitor needs to be logged into Netflix, and they need to be people who don’t frequently manage their queues otherwise they would notice the movie prior to it being sent (and may still react badly, but I posit that even fewer people would if they caught the movie before it shipped). Of Netflix’s 10 million subscribers I would assert that the number that would fall victim to this is small enough to be indistinguishable from zero.

Let’s look at the likely attacker- this isn’t organized crime, or any accomplished Blackhat. Those people are after money. This hypothetical attacker is likely a malcontent teenager who thinks it is funny to screw with a Netflix queue. That mostly rules out the attacker owning their own site that gets enough traffic to exploit this from, and also mostly rules out the attacker knowing of XSS or SQLi flaws in websites that do get enough traffic for this to exploit this from. It leaves their dinky website that pretty much only gets visited by their friends on IRC (or whatever script kiddies use these days)- probably some random blog on blogspot or something similar. In other news this will be exploited from a location that will not attract any noticeable number of Netflix subscribers.

So the likelihood is pretty nonexistent, the impact is very low, and thus the risk of losing subscribers because they were exploited is essentially 0. The risk of brand damage from press coverage isn’t much higher- someone in the press needs to find out about this flaw, grok what the heck the flaw really is, actually have a victim so they can tell a story about, and then compete for airtime with Company X is laying of 50,000 employees and congress is too incompetent to fix things. I predict the tampered roadsigns warning about zombies gets more press coverage. Finally the viewers need to care. TJ Max is our security story, biggest public data loss to date (with Heartland possibly taking the crown), and anecdotally the people I know who shop there weren’t even aware of it, and upon me explaining it STILL DIDN’T CARE. Netflix subscribers are a slightly different demographic, but I don’t see people getting really worked up about hearing that maybe they might be sent the wrong movie.

So why should Netflix fix this problem, instead of working on features that may attract more customers? The people who found this flaw care because it is their flaw- it matters because it is theirs. Unfortunately that doesn’t sway companies. For any vulnerability that is found it isn’t enough to point out the vulnerability- a business case also needs to be made for addressing the vulnerability. That is the reality of enterprise security- everything is cost/benefit analysis. If the risk is low, the response will reflect that. I’d love to see all vulnerabilities get addressed as much as the next security professional, but that is idealism rather than realism talking.

~ Joshbw

IE 8 Clickjacking Protection

January 28, 2009
Browser/Web Security

Eric Lawrence has a pretty thorough writeup on the IE 8 blog concerning *some* protection that IE 8 now offers to avoid clickjacking. In essence there is now a new response header that can be sent back, X-FRAME-OPTIONS, that instructs IE on which behavior should be followed if the website happens to be in a frame, and can be used in conjunction with same origin to ensure that only that domain may frame a particular page.

This is by no means a bullet proof fix especially as it is up to web developers to actually go and use the response header. I can hope that other browser vendors, as well as previous versions of IE, implement this header and behave in the same manner as it will increase uptake (just as the gradual support by browser vendors of HTTP Only has seen a corresponding uptake of people using it to protect cookies). It’s nice to have an option to control frame behavior without hack-y javascript (at least in IE, whose framebusting javascript is no where near as good as in every other browser). Regardless, as this is a server side fix it is up to developers to do something- clients are still stuck using NoScript on Firefox as the only solution they have control over. It will be a long time before this change has any impact.

~ Joshbw

Concerns

January 8, 2009
Browser/Web Security, General Ramblings

Yesterday my debit card was deactivated. After calling my bank it turns out that a retailer I had shopped at (whom my bank very annoyingly refuses to disclose) had their card database ripped off, so my bank pro-actively canceled my card. I am a bit annoyed that my notification of this was my card being killed, and that I am now without a debit card for a week until the new one arrives (considering there isn’t a branch of my bank within 2000 miles of me, this is a bit more than an inconvenience), but I can’t be too pissed about the bank being so proactive about this.

There are also a couple of lessons that are apparent. First, the retailer seems to have been able to suppress the data breach. I am sure there is some agreement where they opt to notify banks but only if the banks keep mum about the breach. Second, I personally have no real risk associated with my card being compromised- it is annoying but I am not liable for any fraudulent charges and my bank seems very proactive about even preventing fraudulent charges to begin with. Third, the response seems entirely mundane. There is no big how-to-do. Data breaches have become so common place it is like finding out a politician is crooked. I think we are at the point where we assume a “when” rather than “if” mentality towards our cards being compromised, which is sad as it reduces the urgency towards security.

Furthermore, over the holidays (note to Bill O’Reilly, who according to twitter’s lack of login attempt monitoring, is apparently gay now [now I know why Colbert calls you Papa *Bear*], there are many holidays at the end of December, hence plurally referring to them as holidays rather than Christmas) I caught up with several family members, and it came out that most were not even aware of the TJX data breach, and even finding out, don’t care. We in the security community love to throw that around as the big example, but I don’t think we realize that it is an example pretty contrary to our message. Here is the largest credit card compromise ever, and most of their customers don’t even know, and those that do don’t really care. They suffered a pittance of expense as a result of the breach. The real lesson is that most people don’t care about credit card theft, it isn’t really a big deal, and successful handling of the media response can largely mitigate a breach. All of that sucks for our message to improve security.

But really, isn’t all of that true? To customers a credit card theft means worst case having to sit on the phone with your bank and go without your card for a while. Credit card theft is a regulatory head ache, but the real pain comes from true identity theft. This is where the title of this post comes in. Thinking about this I started hypothesizing where there is the risk of true identity theft. The places that have all of the information to steal id is a much smaller population, but many of them have really crappy security. Banks and financial institutions are an obvious choice, but they actually are usually pretty on top of things (relative to IT systems as a whole). However any place that accepts your credit information for financing are also likely targets- places like card dealerships, jewelry stores, furniture stores, and any other place that sells something expensive. Many of these places have very shoddy IT systems, pieced together by small local vendor shops who have no clue about security. As an example, my coworker went to buy a car from a local used car dealership that accepts credit applications over the web, password protected, however the forgot password functionality simply accepted the email address and echoed the password to the screen. Worse, if one entered the email address of a sales person (conveniently on their business cards they hand EVERYONE), you get an admin password, able to view all credit applications and results. So a would be attacker gets both absolutely everything they need to steal someone’s identity AND how much that identity is actually worth.

Also on the list of potential targets to get ID information are universities. The schools have all of a student’s demographic and personal information, often including bank account numbers for the deposit/withdrawal of money, but certainly SSN and birthdate (some schools even use SSN as the student number), maintain these systems well after graduation, and update them with information about alumni (where they live, work, etc). They are also renown for terrible security and are a perfect target for ID thieves.

So while all of the other voices are calling this the year of webappsec and such, I am in disagreement. I think we will see some big pushes at big companies, but we will also continue to see big blunders at big companies. I further think it will be years before general webappsec knowledge is prevalent enough to protect places like local car dealership websites, and university IT systems, and as the big boys get locked down we will increasingly see attacks against these smaller, and in some ways more lucrative resources (blackhats get fewer but more valuable records with less effort). This may be the point we get enough momentum to start moving security, but it will be a long time before this momentum has an effect on the average consumer.

~ Joshbw

What a crock

December 4, 2008
General Ramblings

In a recent conversation with a colleague on SSL and how it worked, it occurred to me that I really had no idea what extended verification certificates actually did, other than turn the address bar green and display the company name. What was the “extended verification” that made EV certs better than normal certs? In a normal SSL connection the client can do a reverse lookup based off of the cert to verify the host, but DNS poisoning would obviously render this worthless. Do EV Certs have some magic in their “extended verification” that addresses this shortcoming?

In a word, no. There is no technical advancement in the EV cert. There is no technology that makes the EV certificate a better option than a normal cert, that works around the weakness of the regular cert in verifying hosts. What the EV means is that the cert authority no longer does a half-assed job verifying that they are issuing a certificate for a particular company to that company. They do a bit more background checking so that they can attest that the company listed in the cert is really the same company requesting it. It is brilliant marketing, as you are paying double to three times the cost of a normal cert just to turn the address bar green and to get the CA to actually do some checking on who requests a cert.

The thing is, despite the fact that there is no technological benefit of this, and the fact that current cert prices should have already included verifying the requester, that stupid green address bar is probably worth the money just to increase customer confidence. But go ahead and be bitter about it, since that shade of green is going to cost you another grand for each certificate. Man is Verisign brilliantly evil in their product ideas, right up there with the guy who conned children into buying pet rocks.

~ Joshbw

Hurray HTTPOnly

November 12, 2008
Browser/Web Security

Hey Jim, MS fixed MSXML so that XHR can’t be used as a work around to get the cookies when HTTPOnly is used. I think that makes IE first to have full HTTPOnly support. Now when HTTPOnly is used an attacker can’t get the session at all via XSS, they can only completely deface the website, use javascript keyloggers to monitor all use on the website, forward users off to phishing sites, host malware on legitimate hosts, and other little things.

One hole filled, uncountable holes left.

(unrelated, it’s posts like this that suggest security folks some times speak their own language)

~ Joshbw

Its that time of year, another look at Giblets

November 4, 2008
Secure Development, Uncategorized

Giblets aren’t just the disgusting parts of the turkey, the foul (or fowl if you are no stranger to puns) organs that your grandma likes to try to fool you into eating for her own perverse amusement. In certain parlance they also refer to the external code that your applications is dependent on- source code for which you have little or no control. Giblets are typically libraries, assemblies, jars, or other such modules that a third party, whether it is an external company (for example, the excellent looking Elegant Ribbon), another internal team, a vendor, etc. wrote. They are also a huge security concern as you usually have little insight into what security was incorporated in the giblets’ development cycle, nor a great deal of control when vulnerabilities are discovered in the giblet. You can make your own code rock solid, but still find your application exploited because of Giblet code. MS Office has been hit by this a number of times, as legacy and third party file filters continue to be vulnerable despite the dramatic re-engineering of the Office file formats (.docx, .xlsx, etc) with security in mind.

Recently my colleagues and I have been playing around with several different HTML Encoders in Java. Despite what OWASP has posted on the subject for an international enterprise it is not as simple as encoding everything that isn’t A-Z,a-z,0-9 (though I don’t think OWASP is making any claim at the robustness of their recommendation). Having all of your Chinese radicals all of a sudden converted to full character encoded values is going to dramatically increase page size, especially on anything like a blog or other large text field with copious blocks of user input that gets echoed to the screen. Most people don’t want to figure out how to implement their own character set aware, internationalized Entity Encoder, and so naturally prefer to use canned solutions. The desire to use a canned library is by no means unique to HTML Entity Encoding; for any number of functions this makes sense, since many functions take specific expertise (do you think your average PHP programmer wants to worry about image manipulation implementations for example). However in this specific case it easily demonstrates why Giblets are a big fat bag of security suck. What happens when there is a flaw in the Encoder giblet? You really don’t know what the inside of it looks like- you don’t know how well written it is. You trust that it works, but if your output encoder isn’t encoding all output properly your defense against XSS is now vulnerable.

Really any giblet that processes or transforms external data is a point of concern. To some extent open source giblets can be better, as you can at least look inside and see how well written something is (though I suspect that the number of people who do so are probably in the minority), but for enterprises this can actually be a liability, as legal departments worry about license compliance and IP taint. For all other Giblets, there are a couple of recommendations to make you safer -

1) Ask for details about the Giblet Developer’s secure development lifecycle, vulnerability history, mean time to patch, and other useful behavioral questions about their security posture. It might be worth going with a giblet that has a bit less functionality if the security posture of the developers seems higher.

2) External, Vendor, or Internal, get an SLA in place that clearly defines obligations. Include obligations to patch vulnerabilities of various criticality ratings, time frames for said patches, agreed upon criticality scales (do you consider SQLi to be critical while they think it high?), and maintenance length (if a vulnerability is found five years after you purchased the giblet, are you out of luck getting a fix). This is often overlooked when working with internally developed code from other teams; however just as with external developers your security vulnerability may not be the internal teams priority. You need a commitment to address vulnerabilities in a timely fashion.

For non-commercial giblets, especially open source, you probably won’t get an SLA, so explore the ramifications and practicality of fixing the flaw yourself (see afore mentioned worry about license compliance and IP Taint). Non-commercial, non open source giblets (freeware) are very dangerous as you have no assurance concerning timely fixes, nor the capacity to fix them yourself.

3) Try to validate/sanitize all data before passing it to a giblet anyway, even if the Giblet developer has a great security posture and a very aggressive SLA. An added layer of defense is never a bad thing.

4) If the Giblet is consumed by a client, make sure any agreement with the Giblet developer includes the rights to distribute updated versions to the client.

Most importantly though, just keep in mind that third party code is a risk. Security should be as much a consideration as features when incorporating third party code and all of the security effort you put in may be for naught if your 3rd party code is vulnerable. When I draw threat models I like to label Giblets as External Entities even if they are processes or libraries consumed on the same box, as I have no control over them. It just helps to draw out the ramifications of their use.

~ Joshbw

Preventing SQL Injection in Cold Fusion

October 22, 2008
Browser/Web Security

Well, the ASPROX worm has morphed to go after any page it finds ending with .cfm, which makes a good deal of sense. Much like .asp sites, a cold fusion site probably hasn’t been worked on in several years, was probably developed prior to SQL Injection being much of a worry, and is likely using SQL Server behind the scenes. The other day I stumbled across a website that was having problems connecting to their database, and as a result spit out a lovely exception trace to the screen, including the exact syntax of their SQL Query, which was not using prepared statements. Wanting to be the good little security monkey, I did some quick research into protecting against SQL Injection with cold fusion and sent the info on to them, as well as suggesting they don’t spill their debug info out onto the interwebs for everyone to see.

Adobe has a pretty good page on protecting against SQL Injection, which makes it a little embarrassing that one of their own sites fell victim, but that will hopefully serve as a warning to us all to worry about legacy apps. Anyway, you can enforce parameter typing withing your existing cfquery pretty easily by wrapping each parameter in a cfqueryparam . For example, the following query:

<cfquery name=”Recordset1″ datasource=”mydatasource”>
SELECT *
FROM myTable
WHERE myTableID =#URL.my_Table_ID#</cfquery>

would be turned into

<cfquery name=”Recordset1″ datasource=”mydatasource”>
SELECT *
FROM myTable
WHERE myTableID =<cfqueryparam value=”#URL.my_Table_ID#” cfsqltype=”cf_sql_numeric”></cfquery>

The cf_sql_numeric value ensures that the value passed will be considered as a number, rather than a string or function. This particular value should be of interest for everyone protecting against ASPROX since rather than targeting strings, it targets parts of your query that you assume are numbers. You can find a list of all potential cfsqltype values here. Also listed are other attributes that can be valuable doing rudimentary validation when using cfqueryparam, such as maxLength (it does what you think) and scale (number of decimal places in a number). If you know of any old cold fusion sites out there, let the devs know that they should probably go back and make sure they are using cfqueryparam with all of their SQL parameters. With how effective ASPROX is at finding and exploiting sites, chances are they will be victim if they do not.

~ Joshbw

How client users authenticate the server

October 15, 2008
Browser/Web Security, Secure Development

In my last post, on threat modeling, I had mentioned that there would be a follow up post would talk about the issues to authenticating the communication from the server. My cohort and fellow Josh has been working with me on some side projects with local small and mid-size business to secure their applications (things like auto dealership websites that collect information for credit checks) to offset all that money our investment accounts have taken in the past 18 months with some extra income. In that process we have noticed several issues that keep coming up that make it harder to be confident we are talking to the application we think we are talking to.

In this day and age phishing is so easy because it is hard to authenticate the server to the client. There isn’t end to end trust. Ultimately the user only has a handful of verification methods- does the website visually look like the website they want to connect to, does the URL look like the correct domain, and is the communication over a secure channel, none of which is going to be obvious to non-technical users. The visual appearance is incredibly easy to spoof, to the point where only the most lazy phisher won’t put forth the effort. Short of sternography, the visual appearance can’t be trusted, and sternography isn’t a viable option. So, here are a couple of things you can do outside of the visual appearance.

- Don’t use multiple domain names. You can register multiple domains, but always have them redirect to one domain, and never advertise anything but that one domain. This prevents dilution of the domain name, and trains the user to only trust one domain. Don’t use BobsFordMazdaLincoln.com and BobsMazdaLincolnFord.com, because a phisher can set up bobsLincolnMazdaFord.com or similar name. This is obviously a contrived example, but plenty of companies have a variety of domains for different purposes (Microsoft is really bad about this, and with their live ID being an SSO for all of their domains it is easy for me to phish that credential to great payoff).

It is better to use sub-domains if you have separate sites associated with one company. It is also better to try and have a simple and short domain name, without too many words in it. bobscars.com is way better than BobsMazdaLincolnFord.com because it is much harder to create a variant that fools the users. Bob could then have ford.bobscars.com, mazda.bobscars.com, etc (and this scales if bob ever opens other dealerships). Also, users are more likely to remember your domain name and it will have fewer common mistype permutations (which you should buy, domains are cheap) if it is simple (something for which I am probably guilty with analyticalengine.net, a url that even I mistype occasionally).

- Don’t go crazy with sub domains. You should probably only go one (or very rarely two) deep. mazda.bobscars.com is pretty simple to visually parse as being part of bobscars.com, but year2009.newcars.mazda.fordcorp.bobscars.com is going to be very easy to visually spoof to end users. We need to train customers to look at the domain name, and in order to do that it needs to be as apparent as possible. IE 8 does a good job calling this out, and there is a similar firefox plugin to highlight the domain name, but with many people still using IE 6 we need to focus on getting them to visually parse and recognize the domain (it would also be nice to get them to upgrade to a new browser). If we go overboard with subdomains we make the domain non-obvious and thus make it easy to spoof.

- Use SSL liberally, and use EV certs. The use of EV certs provides visual evidence in the location bar of the browser that this really is the corporation I intend to communicate with. It is one more protection that allows the user to visual identify the site. It offers more than that though, as it can attest to the integrity of the communication back and forth between the site. Afore mentioned cohort Josh has a post on his blog about using Ettercap to intercept communication and alter it in flight. The specific scenario he targeted was javascript based logins, where the page is served over http to improve performance but the login field uses javascript to submit over https; using ettercap he can show how he can modify the javascript while the page is being delivered so that it submits credentials elsewhere.

He recommends that to maintain performance you specifically force users to go to a separate page that is served start to finish over SSL. The problem is that 1) you don’t get the EV Cert based visual confirmation on the landing page if you do this and 2) if your landing page is sent in the clear you can use Ettercap to modify the url to the login page so the user goes offsite to submit credentials. Once a user is logged in you need to either have a ridiculously short session limit or make sure you continue to communicate over SSL, otherwise the sessionid will be sent in the clear which is almost as valuable as the user credentials.

I think it is much better to ALWAYS use SSL with EV certs, forced on every page. That way you get the visual validation of the cert on the landing page, the customer sees the little lock through the whole communication, and the entire conversation is resistant (not immune, but resistant) to tampering. This will impact performance (though I think it might have the advantageous effect of forcing cleaner website design) on dial up (I doubt it is human noticable on broadband) but if you want to provide some level of certainty to the user it is the way to go. Obviously, this should be weighed based on the risk of the site; paypal and banks should obviously do this, engadget probably can do without. As a final piece of advice, make sure that you set the cookie flag so that session information is only sent over secure channels.

These aren’t bullet proof assurances. It is all based on visually notifying the user that this is the site the really mean to be on. It is very reliant on training user behavior, a generally unreliable approach, and then on the user consistently being wary, which is even more unreliable. However, at this point we don’t have much else we can really do. Sandbags may not be an ideal replace for building on high ground, but it beats letting the water in. End to end trust is an unsolved problem but we do what we can.

~ Joshbw

Threat Modeling, quick recommendations

October 14, 2008
Secure Development

A paper by Adam Shostack is circulating the blogosphere, and it is worth a read. I’d already left MS before Adam took over as the gatekeeper of threat modeling for SWI but it is nice to see that he basically agrees with the stripped down version that we regularly did in WinCE and that I still evangilize. Mainly-

1) Draw a data flow diagram (DFD) of how data moves around for your application/feature (depending on scope of the model), and where trust boundries are crossed

2) Enumerate threats. The paper has a nice little matrix of what threats are pertinent to what elements of the DFD and while he applies the necessary conditionals about it being specific to MS and perhaps not being universally applicable, I think it is a pretty good reference in general.

3) Determine Mitigations (or decide to let a threat slide)

4) Validate mitigations that are put in place

We lived by those simple steps, rather than getting into the horrid threat trees and DREAD risk modeling and all of that other overhead. I say this having been the security guy for my area in MS, supposedly the expert, and I ignored them. I can’t imagine the average non-security guy going to that trouble. Granted, being a security guy I probably find it a bit easier to subjectively (wait, am I supposed to say qualititavely now that I am a CISSP?) determine risk from a threat than put a number on it, which is what the overhead in threat modeling was supposed to do, but I think most non-experts can still make an educated guess.

Anyway, the reason I am bringing all of this up is to illuminate one aspect that isn’t touched on much in most threat modeling discussion- Don’t just focus on your process/components. When people create a data flow diagram and start thinking about threats and mitigations they tend to focus on threats specific to their own code and how to mitigate stuff entering that code. However if we look at a vulnerability like XSS, it isn’t a threat to your own code, it is a threat to external entities (in this case, client browsers), and the best mitigation is to sanitize (HTML encode) data as it leaves your application rather than validate it as it enters (now you still need to validate it as it enters to make sure it isn’t malicious to your code, but don’t worry about flat out stopping xss with input validation if you can output encode).

Similarly, in the above web app example, a threat model would have us worry about how to authenticate the client for repudiation and information disclosure purposes, but I haven’t been to many threat modeling sessions where the team originaly considered the data flow the other direction (establishing to the client that this is the server you can trust- more on that in a post in the near future).

So as you are developing your threat model be sure to consider threats to each of the entities in the DFD. Don’t focus only on the flow into your components, and don’t consider threats to just your components, but rather look at the full ecology represented in your DFD.

~ Joshbw