The Security Practice

Some clarification of HSTS behavior on non-standard ports

Andy Steingruebl here,

 

Some discussion about HSTS behavior on non-std ports today.  I wrote about it on my personal blog. Rather than copy it all here, here is a link.

http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-http-strict.html

 

How Cross Site Scripting was discovered

Hi, Michael Barrett here.

These days, most of us have to grapple with preventing Cross Site Scripting and other web-based attacks from occurring against our web sites.  What's lost in the mists of time is who discovered it and why. 

I had the unique privilege of being there when a couple of really talented security testers (Marvin Simkin and Toby Barrick) came up with what we now know as Cross Site Scripting.  Of course, it's entirely possible that another individual or team discovered the same idea at roughly the same time - history is littered with such examples - so the re-telling of this story shouldn't be taken as invalidating any other suggestions of how it was first discovered.  I should add that I've never met anyone who claimed to have found it before Marvin and Toby did, and I think there's a very good chance that they really were the first ones to think of this.

Recently, Marvin wrote up how it all happened - when we all worked at American Express in the late '90s - and so here's his telling of how it happened:

"I think of it more as "discovering" than "inventing" because I didn't set out to make a new attack vector -- I just stumbled across it.

 Toby, an associate of mine, and I were testing a new web site in development which allowed you to customize a few pages with links to your favorite services etc. We noticed that the customizations were associated with a cookie that basically told the site who you are. The contents of the cookie was your email address.

We argued that the cookie value should be something harder to guess. If I know your email address I could tamper with my cookie and see your custom page. The developers, as they often do, said "So what? So you see my links. There's no harm. We're not going to fix it."

Toby pointed out that part of the customization was a name field so the page could say "Welcome back Mark". Toby said you could change someone else's name to something foul or insulting. Developers didn't budge. Toby then figured out some obscure encoded character in some weird font that would display a skull and crossbones. He also embedded it in a FONT COLOR=RED tag. Still not scary enough. So the question came back to us "what's the worst thing you can do" given the ability to maliciously control the content of a page someone else will view?

Well, that is exactly the wrong question to ask me. Because it set me thinking of possible attacks. What's the most harmful HTML tag? Played with that a little... hey, not just HTML, what about SCRIPT? Not merely formatting but now I have control of your browser! Still didn't think about stealing your cookie because in this attack I already had your cookie to start with (and didn't realize it would give me your OTHER cookies).

Now putting crazy HTML and/or scripts into persistent stores like bulletin boards (called blogs today) was already a known attack, and many people were filtering any user submitted page content. I don't claim to be the first on persistent XSS. But if I'd thought of it, I could have done something like that here.

This exercise however provided the mental positioning for when I was testing another site and found I could inject page content through something in the URL. Again the developer response was "So what? You're only ruining your own page. Why would you attack yourself?"

It occurred to me that if I could entice someone else to view my crafted URL (this was before phishing took off big time) I could immediately run my code in their browser. This was, I suspect, the first use of "reflected XSS". I knew right away that would give me access to their Document Object Model. What's the most valuable thing in the DOM, to read or alter? If I can attack a session cookie it would provide access to financial stuff. OK, now how to I get your cookie back to me, the attacker? It didn't take long to realize an embedded image tag with an HREF to my server would do the trick, and I demo'd stealing cookies in real time first to my boss, then step by step up the management chain until we got to some higher execs I didn't even know.

I found XSS holes in the default "404" error page of the three top web servers at the time. Together they served 95% of the sites on the net. Hypothetically speaking, at that moment, I pwned them all! :)

I don't know the exact date of discovery because (1) it happened gradually, over several weeks, with back and forth debates asking me to prove the issue by strengthening the attack and increasing the potential harm, and (2) I didn't know it was going to be a big deal so I had no reason to take note of it at the time. But I have some emails discussing it in September 1999, so it was at least then if not sooner, and I have a code snippet dated November 3, 1999 from a spider I modified to scan for XSS. I think it is very likely this was the world's first reflected-XSS scanner.

A few of us got on the phone to the MS security center and told them about it. They hadn't heard of it before and had no solution. A few months later they made the issue public through the CERT. I was not able to disclose it myself and claim credit because of nondisclosure agreements in effect at the time. So since then many companies and many products have risen from my discovery, but I have yet to see much in the way of royalties. Oh well. :)

Oh -- and I didn't name it "Cross Site Scripting". I called it JavaScript injection. I suppose I was thinking too small by limiting it to JavaScript, but that seems to be the primary attack vector even today. It has remained #1 on several top-ten lists for over a decade now, and I don't see it being solved any time soon -- for the same reasons as it originally arose. Developers under too tight deadlines to spend time validating inputs. Or, simply, being unaware of negative use cases and designing / testing only to positive use cases."

The Need for Coherent Web Security Policy Framework(s)

Hi, Jeff Hodges here.

Andy Steinguebl and I presented ths paper at the Web 2.0 Security and Privacy 2010 Workshop..

  The Need for Coherent Web Security Policy Framework(s)

..back in May (abstract below). Since then, we’ve been waving our paper around and pursuing the action items outlined therein with some modest success, which we'll discuss as things develop.

Abstract

Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. In this position paper, we give a brief overview of the ravaged web security landscape, and the various seemingly piece-wise approaches being taken to mitigate the threats. We then propose that with some cooperation, we can likely architect approaches that are more easily wielded and provide extensibility for the future. We provide thoughts on where and how to begin coordinating the work.

 

HTTP Strict Transport Security Happenings -- IETF, Firefox 4.0 beta

Hi, Jeff Hodges and Andy Steingruebl here..

The HTTP Strict Transport Security (HSTS) spec is now an IETF Internet-Draft, and available here (for now): http://tools.ietf.org/html/draft-hodges-strict-transport-sec

Also, we held a successful BoF at IETF-78 Maastricht last month, named "HASMAT" (for "HTTP Application Security Minus Authentication & Transport"), the result being that a new IETF Working Group will be formed (which may be named HASMAT or something else), into which the HSTS spec will land. Once that happens, the spec will likely become a working group item, and thus the filename and URI for that new version will change (just fyi). We'll post about that when it occurs.

In terms of Firefox support, the HSTS implementation has landed in the nightlies (thanks Sid!) and will be included in the next Firefox 4.0 beta. Note that HSTS is already a feature in Google Chrome as of version 4.

Enjoy!

Mozilla Security Blog: HTTP Strict Transport Security

 

 

PayPal's Information Risk Management Team is Hiring

PayPal's Information Risk Management (IRM) team is hiring.

Principal Security Strategist

IRM Program Manager

Information Risk Analyst

Information Security Engineer

Information Security Engineer

How Mine Safety is Like Internet Governance

Hello, Andy Steingruebl here:

There was a great piece on NPR  (a link to some of it here: http://www.npr.org/blogs/thetwo-way/2010/04/safety_agency_to_use_ignored_p.html)  the other day about the MSHA (Mine Safety and Health Administration) and how their enforcement against unsafe mines has been sorely lacking.  One key piece of the story is that essentially the statutory authority granted to the MSHA is to close a mine, or a section of it.  They don’t have the power to levy fines for example, or prosecute individuals doing unsafe things.

As a result, their main weapon is essentially the nuclear option against a mine operator.  They are therefore reluctant to use that authority, and so they have instead created a system of letters-of-pending-action or somesuch.  Under these they indicate to a mine operator that they are getting close to a breach of their requirements, and they give them a cure timeframe.  Because mine operators can appeal any judgments, this ends up being a real obstacle to credible enforcement.  Historically we’ve seen the same things from the FAA.  They are loathe to write up formal findings because they have the possibility of causing major harm to an airline, rather than just getting them to modify the offending behavior.

 ICANN has a similar problem with policing their registrars.  historically the only penalty they can impose is removing a registrar’s accreditation.  This is the nuclear option.  They have typically been loathe to fully remove a registrar, and so we end up with bad registrars in the system. We've seen them step up the enforcement recently, but I think these are probably still enforcements against only the most egregious offenders.

The lesson for us in working to craft internet governance and regulations is that we need to understand this dynamic between regulator and regulated-entity, and create flexible schemes that allow the regulator to effectively police, without each policing action being a nuclear option, and thus causing regulated entities to fight every judgment action in court, etc.

Perspectives on "perspectives"

Hello, Andy Steingruebl here:

After the paper a week ago by Chris Soghian and Sid Stamm on the possibility and perhaps high likelihood of a breakdown in the CA trust model due to coerced certificate generation, a lot of attention has focused on how to mitigate this type of attack.

Generally speaking people have been looking to several different solutions to the problem:

1. Detection of changes in a given site's CA or Certificate
2. Allowing a site to indicate its CA policy via some OOB means
3. Alternative means for scoping CA signing rights in browsers so that the trust-root isn't one size fits all.
4. Sites advertising their SSL keys via other means than signing by a CA.

I want to focus on just topic #1 in this post and I will write up some further thoughts on #2 , 3, and 4.

Several solutions to detect changes or variances in a site's certificate have been proposed. One of the most prominent and advocated is the Perspectives work (and Firefox plugin) from CMU.

Perspectives works by having a group of "notary" servers on the internet monitoring certain sites, and capable of telling an end-user whether they have a quorum of agreement on the value presented for a given server's certificate.  If the version of a certificate that your client sees differs substantially from those seen by a number of notary servers, there is some chance you are suffering a MiTM attack.  

These Notary servers can also be used to track the properties of a given certificate over time.  If they notice for example that the certificate at https://www.paypal.com/ is usually singed by Verisign (it is) and is an EV certificate, and all of sudden it is signed by some other small CA, then that may be evidence of something like compelled certificate generation.

Just this last weekend we had some security researchers contact us about a number of certificate fluctuations for https://www.paypal.com.  Over the last few weeks our certificate changed several times, and in one case for very short period of time.  Based on the assumption that certificate fluctuations like this could also be a result of an attacks, the researchers contacted us. (Reminder, we have a contact process for security issues).

Unfortunately, the changes of certificates for www.paypal.com was intentional.  We were testing out some new certificates on the PayPal site, and rolled them out in order, and for a short duration.  All of the certificates were signed by the same CA as usual, but were distinct from each other and did cause fluctuations within the Perspectives tool.

During the recent Global Symposium on DNS Security, Stability and Resiliency the issue of coherency for DNS came up as a metric to track.  One of the hard things to define within the DNS is "right answer" to a query.  As it turns out, the best definition we could come up with was - "Client gets the answer to the query that the zone owner intended."

Which bring me back to the point of this post.  In the space of Web server SSL certificates, the only point of view of correctness that really matters, is what the server intended to publish.  Yes, there is a relying party in this trust relationship (the end user) and they are ultimately responsible for deciding whether to trust a certificate. But the major data point they should consider is what the Site intended, and try to discern that as best they can.

The only party who actually knows what certificate should have been published, is the site owner.  

This means that for certain types of prevention and defense against certain attacks, we need to look for options #2,3,4 above to solve the problem, because the current in-band signaling mechanism isn't always up to the task against certain classes of adversaries, and has certain undesirable failure modes.

Abusing Transparent Proxies with Flash Presentation Available + Paper Update

Hello, Robert Auger here:

I have updated the whitepaper 'Socket Capable Browser Plugins Result In Transparent Proxy Abuse' to better emphasize the impact of NAT with transparent proxies, and how vendors have been addressing this transparent proxy abuse case.

Additionally the slides from my OWASP DC presentation 'Abusing Transparent Proxies with Flash' are now available online in Powerpoint format.

OWASP DC Slides: Abusing Transparent Proxies with Flash Presentation
Whitepaper: Socket Capable Browser Plugins Result In Transparent Proxy Abuse

New rev of Strict Transport Security (STS) Specification

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 [email protected] mailing list (from the [email protected] 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

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.