The Security Practice

New rev of Strict Transport Security (STS) Specification

2009-12-23T13:13:54-08:00

Hi, Jeff Hodges here.

I have pushed out a new rev (-06) of the Strict Transport Security (STS) Specification, with changes derived from feedback from various folks. This message (HERE) discusses the more major changes.

Note that STS discussion has now moved to the public-web-security@w3.org mailing list (from the public-webapps@w3.org list).

There is also a wiki page on which public-web-security@ denizens are working on coalescing various facets of web security, http://www.w3.org/Security/wiki/Main_Page, (including a page on STS).

Strict Transport Security presentation

2009-12-10T14:57:53-08:00

Hi, Jeff Hodges here.

This evening, I'll be presenting on Strict Transport Security at iSEC Partners' iSEC Open Security Forum. My presentation is HERE. It provides a succinct STS overview and a brief status report on where we are with the effort.

What works in fighting phishing

2009-12-04T15:42:53-08:00

Hello, Michael Barrett here.

Over the few short years that PayPal has been in existence, we’ve been very successful: we now have 78 million active customers globally – more than the population of many countries. We also have an online system that’s designed to make it easy to move money around the globe. And, we have a team of the usual paranoid information security types like me who do our utmost to keep our core online engine safe and secure.

Given all of that, it’s no particular surprise that our brand and our customers were early targets of phishing, and continue to be targets to this day. I have written occasionally on the question of how companies can help their customers protect themselves online, especially from phishing. Perhaps the most detailed of these was in a white paper that I co-wrote, and it gives a pretty good level of detail on our thinking on an entire strategy for addressing phishing: https://www.thepaypalblog.com/2008/04/a-practical-app/

Because of our status, we’re also used often used as an example of whatever particular idea an individual security researcher is arguing for. Alas, that has recently happened when Randy Abrams, Director of Technical Education at ESET, published a blog entry under the sensational title, “PayPal admits to phishing users.” (For the usual infosec crowd who reads thesecuritypractice.com, you all know that ESET is a good and well-recognized anti-virus solution vendor.) You can find the blog entry here: http://www.eset.com/threat-center/blog/2009/12/03/paypal-admits-to-phishing-users#comments

The reason that I’m commenting on this is as follows. In our white paper, we didn’t cover the topic of links in e-mails, but we’ve researched it extensively and have come to certain conclusions about this.

First, we doubt the effectiveness of removing all links in e-mails as a way to eradicate phishing. Every single Internet user on the planet would have to understand that no PayPal e-mails contain links. The whole point of phishing as a crime is that it exploits customer cognitive dissonance around how the Internet and links work.

Thus, even if we didn’t send e-mails with links in them, there would be nothing to prevent criminals from sending phishmails with links, and some small percentage of users would almost certainly fall for those e-mails.

Secondly, the reason that links are so popular in e-mails is because they simplify things for the recipients of the e-mails. In our own analysis of this, we found that there were indeed a certain number of links that we could remove from our e-mails, and we have done so. But, there were others that would be very problematic – sending someone a reference to a transaction, for example. (“Log on, go to your transaction history page, scroll forward three pages, go to the transaction three quarters of the way down the page …”) We have to balance our risk prevention techniques with our customer experience. It’s a delicate balance, and one that we take very seriously.

Instead of removing all links in e-mails, we have embarked on a program to ensure e-mail standardization of legitimate PayPal e-mails. The basic rule that we’re trying to enforce is that links in legitimate PayPal e-mails will always be through paypal.com, and they will always be HTTPS links. We believe that this is defensible territory and that customers can be trained to look for this, although we don’t actively do this much as most users are confused by the link destination URL vs. the link text.

We have indeed done a number of things around consumer education. Our first rule – which Mr. Abrams indeed followed –“forward uncertain PayPal e-mails to spoof@paypal.com” is generally a very good one. We also have another one which is effective – “if you’re unsure of the legitimacy of an e-mail, close the e-mail, open a new browser and go to the website concerned (https://www.paypal.comin our case) and just log on there.”

Finally, I will make an admission – we had an error in the system which processes e-mails to spoof@paypal.com. It mis-categorized a legitimate e-mail as a spoof one. Of course, we don’t like to make errors. I will explicitly note this though – no harm was done. The infosec crowd very well understands the “crossover error rate” concept. I would much rather that our spoof e-mail processing veers towards extremely low false negative rates, even if it errs occasionally as in this case towards a false positive or two. The consequences of false positives are simply that we look like twits, and those who have the proverbial ax to grind can exploit that. The consequences of false negatives could seriously threaten the online safety of our customers, and so we go to some lengths to ensure that doesn’t happen.

Announcing Strict-Transport-Security Support on www.paypal.com

2009-11-06T13:31:22-08:00

Hello, Andy Steingruebl here.

I'm pleased to announce that PayPal is the first major internet site to implement the draft Strict-Transport-Security standard. As of Friday November 6th, 2009 PayPal is supporting the Strict-Transport-Security (STS) mode on our main website, https://www.paypal.com.

As we published back in September when we released the jointly developed spec, STS allows a site to override a web browser's normal protocol preference for HTTP, and instead tells the web browser to convert all attempts to access a given site to use HTTPS. The draft spec is here.

A few small caveats.

Right now we're just supporting this on https://www.paypal.com, not any of our other sites.
We've launched with a very small max-age parameter for testing purposes. We expect that after more extensive testing we will deploy with a much larger max-age value to provide more robust protection for users.
This feature is currently supported in the NoScript and ForceTLS extensions for Firefox, and Chrome-4 (currently in beta). We expect other browsers to add the feature in the future.

An ethical framework for information security research

2009-10-23T14:17:41-07:00

Hello, Michael Barrett here again.

I’ve written before about the responsible disclosure of security research, and the need for the industry to align around that. And, other members of my team have previously highlighted PayPal’s own disclosure policy (https://www.paypal.com/cgi-bin/webscr?cmd=xpt/Marketing/securitycenter/general/ReportingSecurityIssues-outside) which attempts to lay out what we regard as acceptable vs. unacceptable behavior in disclosures of potential vulnerabilities within PayPal itself.

In the ensuing time, a couple of things have happened. First, my own team has done a certain amount of security research into vulnerabilities that we’ve run into, and it’s helped clarify our own thinking about how the research itself should be conducted. The experience of both conducting the research, and then working the disclosure process, gave us a great deal of insight. Second, PayPal and its customers have recently been uniquely put at risk, not just by irresponsible disclosure, but by what we believe was irresponsible conduct in the way that the research itself was carried out.

Over the last few years, there’s been a lot of debate within the security research community about the question of whether the laws that apply to security breaches have the necessary “carve outs” for legitimate security research. The adequacy of today’s legal framework is a difficult topic. I personally believe that these laws have grown in a rather organic fashion - that as such they are perhaps less well focused than they should be, and indeed they have often not kept up with the evolution of the Internet. Frankly it has not helped where law-makers – no doubt with good intention – have attempted to outlaw all “hacking” tools, with apparently no awareness of where these tools have legitimate dual-use within the security community.

However, the security research community has tended to focus on “what’s legal” and “what do I do if I inadvertently breached the law”, but has given relatively little attention to the question of “what’s the ethical way to conduct and disclose my research”. There is some thinking on this topic that is worth referencing, and these analyses represent a good starting point:

· Towards Community Standards for Ethical Behavior in Computer Security Research, by David Dittrich, Michael Bailey, and Sven Dietrich, Stevens CS Technical Report 2009-1, April 20, 2009 [Local copy and most recent draft release.]

· EFF’s Coders Bill of Rights - http://www.eff.org/issues/coders

· Conducting Cybersecurity Research Legally and Ethically. Aaron J. Burstein. http://www.usenix.org/event/leet08/tech/full_papers/burstein/burstein_html/

· Toward a Culture of Cybersecurity Research. Aaron J. Burstein. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1113014

We believe that the time is right to open a robust debate within the security research community on this question.

There are some who may argue that it’s still too early to develop such an ethical framework, either based on notions that the field is still too immature, or on potentially misguided notions that this is a First Amendment issue. I think these two points are fairly easy to cover. First, the security research area has in fact been operating for quite some time now: one could argue that the infamous Morris worm was the first example of rogue security research - and that was in 1988 - more than twenty years ago. Second, I am personally very sympathetic to supporting First Amendment rights. But, there are recognized limits to First Amendment rights in the real world - the famous shouting of “Fire!” in a crowded theater - and I’d argue that there should be some reasonable limitations to “speech” in the virtual world too.

To make this clearer, consider a hypothetical conference at which a researcher is presenting a design for an improved bomb. (Please note that this is a very hypothetical case – there would likely be all sorts of practical reasons why this would never happen!) It’s one thing to publish the details of how this improved bomb might work; it’s another to leave a pile of components & materials on the sidewalk outside the conference center. The problem is that in the virtual world, publishing attack source code and cryptographic material is tantamount to being that pile of components & materials, and as such I believe it’s doubtful that it’s automatically covered by First Amendment rights.

Also, it’s quite clear that there are other areas where voluntary and non-binding codes of conduct have been very effective. Probably the best example is of bioethics, where the overwhelming majority of researchers in biological & genetic engineering voluntarily subject their research to falling within certain guidelines, and formal oversight. Another example is virology research, where there are well-understood guidelines to ensure that pathogens don’t escape into the outside world, as well as controls over publication to ensure that raw research is not disclosed in ways that would imperil public safety. Why should information security research be any different?

While we’re not proposing any kind of formal oversight organization, we do believe that some kind of ethical framework for responsible research and disclosure is quite feasible. If the guidelines are well-developed with good input from the community, they should be quite practical.

Based on the above thinking, we are intending to work to see how many people within the security research community we can find who are interested in the development of such guidelines. We believe it’s finally time.

Strict Transport Security (STS) for Web Browsers

2009-09-24T14:16:19-07:00

Many (most?) of us, when accessing a "secure" web site, have at one time or another been presented with a browser dialog indicating something isn't quite right with the site's certificate, and offering the ability to ignore the issue and proceed. Sometimes proceeding is not a good idea because it may lead to a man-in-the-middle attack.

Collin Jackson and Adam Barth present the details of such situations, as well as a means to remediate them, in their paper ForceHTTPS: Protecting High-Security Web Sites from Network Attacks. Essentially, ForceHTTPS enables a server to signal to browsers that it wishes to be interacted with only over secure transport, e.g. TLS/SSL. Part of the idea here is if the user enters, say, "http://www.paypal.com", the browser will rewrite it as "httpS://www.paypal.com/", and initiate the HTTP connection over secure transport. Another aspect is that if there are any certificate errors upon secure transport establishment, the connection will simply fail and the user won't be presented the opportunity to "click through" warnings.

Now, working with Collin and Adam, we've produced a refinement in the form of a HTTP Header Field specification entitled Strict Transport Security (STS). We're talking with the W3C about standardizing it there. There are already two Firefox extensions implementing it, Giorgio Maone's NoScript, and Sid Stamm's ForceTLS. Both Giorgio and Sid have blog entry's concerning STS, too:

Additionally, Google Chrome has STS functionality implemented and it is working its way through the development channel process.

We (PayPal) are excited by the positive feedback we're receiving and the implementation work. We're looking forward to having our customer's security improved.

Submitted by Jeff Hodges.

Software Assumptions Lead to Preventable Errors

2009-08-03T17:12:15-07:00

Hello, Andy Steingruebl here. Cross-posting from my personal blog.

Here is a paper I co-wrote with Gunnar Peterson for the IEEE Security and Privacy Magazine. The title is pretty much the subject of the piece - how assumptions in the development process, and the associated lack of documentation and explicit statement of those assumptions, leads to preventable errors. We cover some techniques for documenting assumptions across a number of areas of the product lifecycle. Hopefully there are a few ideas here about formally documenting assumptions that you'll find useful.

Note: This article is Copyright IEEE and was originally published in IEEE Security &
Privacy magazine, vol. 7, no. 4, 2009, pp. 84-87.

Got My New Security Key

2009-07-17T12:58:50-07:00

PayPal has been busy behind the scenes with two new form-factors for our two-factor authentication security key.

We launched both a new physical form factor that is credit-card sized, as well as an SMS version of the key. The credit-card form factor is pictured here. So far so good on the credit card and I find it a little easier to keep track of than my previous token.

If you want to learn more visit: https://www.paypal.com/securitykey

Socket Capable Browser Plugins Result In Transparent Proxy Abuse

2009-03-09T16:32:34-07:00

We're pleased to announce the availability of 'Socket Capable Browser Plugins Result In Transparent Proxy Abuse'. This document outlines the abuse case in CERT's VU #435052 advisory published last month.

Abstract

"Transparent proxies allow organizations to influence and monitor the traffic from its users without their knowledge or participation. Transparent proxies act as intermediaries between a user and end destination, and aren't generally apparent to users sitting behind them. Enterprises, Hotels, and Internet Service Providers often use transparent proxy products to lower bandwidth consumption,speed up page loads for their users, and for monitoring and filtering of web surfing. When certain transparent proxy architectures are in use an attacker can achieve a partial Same Origin Policy Bypass resulting in access to any host reachable by the proxy via the use of client plug-in technologies (such as Flash, Applets, etc) with socket capabilities. This write up will describe this architecture, how it may be abused by Flash, its existence in various network layouts, and mitigations."

Download Paper: http://www.thesecuritypractice.com/the_security_practice/TransparentProxyAbuse.pdf

CERT Advisory: http://www.kb.cert.org/vuls/id/435052

PayPal's Information Risk Management Team is Hiring

2009-02-17T19:43:45-08:00

We're hiring two application and project security consultants and a security manager. Duties include security analysis of projects, high level risk analysis, threat modeling, implementation guidance, deployment guidance, and some strategic consulting and research.

Here are some easily clickable links:

Manager, Information Security - Phoenix
Principal Information Security Engineer - Phoenix
Principal Information Security Engineer - San Jose

You can also check out the PayPal jobs board at https://www.paypal.com/jobs and search for security jobs.