HTTP Strict Transport Security

mgoodwin

3

The lack of (or inconsistent use of) SSL puts users’ security and privacy at risk. Increasingly, popular sites require SSL not only for operations which are known to directly involve private data (login, etc) but for entire sessions. This is a good thing.

Unfortunately, there are a number of techniques an attacker can use to work around this. The most well known of these is SSL-Stripping in which an active man-in-the-middle can intercept traffic between the browser and the server, downgrading what should be an HTTPS connection to an unencrypted HTTP connection.

HSTS (HTTP Strict Transport Security) is designed to make attacks like this harder; it allows servers to specify that all subsequent connections must be made via HTTPS for a specified period of time. If a request is made over HTTP it will be automatically upgraded by the browser. Also, if the SSL certificate for an HSTS enabled site can’t be verified, the requested document won’t be loaded.

There’s a gap in this protection though; if your initial connection to a site is intercepted, not only could your connection still be downgraded but the attacker could also stop the browser from seeing the HSTS header too. This can be resolved for popular sites that use HSTS by means of an in-browser preload list (coming soon in Firefox 17 – currently in Beta). You can read more about preloading HSTS in our earlier post on the subject.

Firefox has supported HSTS since version 4; we think it’s about time your site did too. You can learn more about HSTS and how to implement it in this article on MDN.

Rebooting Security Engagement at Mozilla

Curtisk

We recently announced a reboot of our efforts to engage with security contributors at Mozilla. Today our strongest and most lasting contributor relationships are with individuals searching for bug bounties. While this program has been very successful, this model sets up a relationship where the only tangible contribution is a bug that may or may not result in a bounty. Instead we want to encourage growth in knowledge from those willing to learn, the creation of open source tools for security work and recognize the natural asymmetric challenges of an open source project that competes with closed source offerings.

In order to do this we have to recognize some unique challenges that security work has in an open project. The first issue being one of trust, as the information that is available in the normal course of our work could harm users in the wrong hands. Secondly that access to security knowledge is not conveyed simply by employment at Mozilla Corporation but by membership in the Security Group (which isn’t changing in any way). To date there has not been a clear path to get involved with security at Mozilla, and this new program aims to change that.

Contributor & Security Contributor
All contributors, individuals who contribute code to the various projects are already important participants in existing security review processes. However, we want to encourage security-minded contributors into providing more active involvement in the Mozilla security community.

The title “Security Contributor” is how we differentiate those contributors who provide security related content including (but not limited to): Brown Bag Presentations, Conference Talks, MDN documentation Security Review Documentation, Security Tool contributions, Vulnerability Defence Documentation.They file security bugs, but not necessarily in pursuit of bug bounties and they contribute patches for security bugs. They may over time also gain increased access to security bugs as needed for the work they are doing.

Security Champions
Champions are active members of a team that help to make decisions about when to engage others from the Security Team. They are recognized as an expert on a product or area as well as having security knowledge and expertise. Champions continue to do the work they do today but take on some added responsibility for guiding security decisions and verifying the security direction of the team they are already with.

One of those tasks would be helping to triage bugs in that component or area and get them into the hands of people who can make a difference in fixing and prioritizing them. As part of this program each champion has a direct contact in the Security Assurance team that they can ask questions of and get guidance when needed. This program has already begun and is actively looking for more people that want to be a part of it. As well our commitment to the success of this means we will be providing training and tools to ensure success.

Security Mentors
Our last group of contributors is one designed to maximize the impact of special knowledge for everyone. Mentors have expertise in a domain area, such as cryptography, JavaScript, memory models, or fuzzing etc. This group also is willing to mentor those that have questions or need guidance in a more general way. They don’t take on the extra work of our champions but are willing to work one on one to help others gain knowledge while working on a specific task. The program for this is also just getting started. We’ve lined up a group of people from the Security Assurance team and made some contacts with academic institutions to help drive some specific actions that we think will be rewarding for both parties.

This journey is just beginning, we hope that those of you reading this will find a place where you can engage with the project, grow in skill and become a part of our community.

Preloading HSTS

dkeeler

3

HSTS (HTTP Strict Transport Security [1][2]) is a mechanism by which a server can indicate that the browser must use a secure connection when communicating with it. It can be an effective tool for protecting the privacy and security of users and their data.

However, when connecting to an HSTS host for the first time, the browser won’t know whether or not to use a secure connection, because it has never received an HSTS header from that host. Consequently, an active network attacker could prevent the browser from ever connecting securely (and even worse, the user may never realize something is amiss). To mitigate this attack, we have added to Firefox a list of hosts that want HSTS enforced by default. When a user connects to one of these hosts for the first time, the browser will know that it must use a secure connection. If a network attacker prevents secure connections to the server, the browser will not attempt to connect over an insecure protocol, thus maintaining the user’s security.

Our “preload list” has been seeded with entries from Chrome’s list of a similar function. To build our preload list, a request is sent to every host with ‘mode: “force-https”‘ on Chrome’s list. Only if a host responds with a valid HSTS header with an appropriately large max-age value (currently greater than or equal to 10886400, which is eighteen weeks) do we include it in our list. We also see if the includeSubdomains value for the entry on Chrome’s list is the same as what we receive in the response header (if they do not match, we use the one we receive).

We limit the list to hosts that send a large max-age under the assumption that these sites will not revert to non-HSTS status. However, this may become necessary. Suppose ownership of a domain on the preload list is transferred and the new owner decides to no longer use HSTS. The HSTS spec allows the site to send a header with the directive “max-age=0″. This indicates that HSTS should not be enforced for that host, and the browser would honor this. The preload list must replicate this behavior.

To accomplish this task, we introduce the concept of “knockout” entries in our HSTS implementation. When the browser receives an HSTS header with “max-age=0″, a knockout entry is stored that overrides the corresponding entry in the preload list. The knockout entry essentially says, “We have no HSTS information regarding this host.” As a result, the browser behaves as if the host were not on the preload list.

However, the normal rules of the “includeSubdomains” directive still apply. This can result in non-intuitive behavior. Suppose child.example.com is on the preload list, but has delivered a header with the directive “max-age=0″. Further suppose that example.com has sent a header with “includeSubdomains” and a non-expired max-age. The knockout value means the preload list will not be consulted for “child.example.com”. However, since we do have an entry for “example.com” where includeSubdomains is true, child.example.com is still an HSTS host (as is any other subdomain of example.com). Hence the browser will only connect to child.example.com over a secure connection, despite the fact that it has a knockout entry.

In short, HSTS in combination with a preloaded list of sites can be a great tool for increasing the security of users, but care must be taken with the includeSubdomains directive. This feature is currently in Firefox Beta, so download a recent build and give it a spin.

Updated on Nov. 5th, 2012 to clarify the minimum max-age value and to change some formatting.

Mozilla’s Commitment To Security

mcoates
October is National Cyber Security Awareness month and we want to take the opportunity to reiterate Mozilla’s security commitment to the Web. From Firefox for Windows, Mac, Linux and Android to Firefox OS to the Firefox Marketplace, Persona and more – Mozilla is committed to delivering secure applications and services that protect our users’ data and privacy. This is more than just a commitment; it’s even in our manifesto.

Individuals’ security on the Internet is fundamental and cannot be treated as optional. http://www.mozilla.org/about/manifesto.html

Open & Transparent

In the spirit of Mozilla and our pledge to being open, we report all of our security issues to the public. We don’t just show bugs when someone else publicly discusses an issue or when it is convenient to us; we’re open and transparent as a matter of principle.

When a security issue is present that impacts our users we’ll tell the world what we know, what it means to our users and what we’re  doing to address the concern. Our pledge is to provide this information to our users as soon as we know it and fix the issue as quickly and responsibly as possible.

Secure Software Development Lifecycle
Let’s take a quick look at the variety of mechanisms we include within our secure software development lifecycle.

  • Threat Modeling – During design we gather security experts, developers and architects to evaluate potential risks of a design and ensure proper security controls are present in the design of the new system or feature.
  • Fuzzing – Automated scripts and tools send a variety of malformed data into our applications to ensure our products properly handle all sorts of unexpected scenarios that could otherwise lead to vulnerabilities.
  • Security Code Review – Our security experts and developers manually review critical code to identify the proper use of security controls and proactively find potential flaws.
  • Penetration Testing – We perform the same actions that a real attacker would take against our applications and ensure all security defenses are properly functioning.
  • Bug Bounty Program – Mozilla began the first browser bug bounty program in 2004 and expanded to include critical web applications in 2010.  This program builds our larger security community and is another way we proactively discovery security issues and provide fixes long before users are ever at risk.

Results?

Our secure software development lifecycle allows us to proactively harden our applications and fix potential security concerns. In fact, since 2010 we’ve only had three public security zero-days (potentially exploitable security vulnerabilities in the current version) within our Firefox code that has caused us to rapidly release a security fix. When these situations arise we deliver fixes to our users in an average of under 48 hours.

A Secure Mozilla Experience

Mozilla is committed to the security of our users. We employ a variety of  strategies to securely build and maintain our software. When unexpected  issues arise, we’re open and honest about what happened and what we’re doing to make it right.  We hope that these commitments and our track record speaks to the importance and priority that we place on protecting user data and the web.

Michael Coates
Director of Security Assurance

Click-to-Play Plugins, Blocklist-Style

dkeeler

14

You may have heard of click-to-play plugins (in short: don’t load plugins until they’re clicked). You may have also heard of the blocklist (essentially a list of addons and plugins that are disabled to prevent users coming to harm; this includes vulnerable and outdated versions of popular plugins). Now, appearing together for the first time in Firefox Beta, allow me to introduce click-to-play blocklisted plugins!

This is how it looks in action:

(Note that the popup notification won’t show itself automatically. This is intentional, so as to not interrupt the user. To open the popup, simply click the plugin icon in the url bar as shown below.)

By combining the safety of the blocklist with the flexibility of click-to-play, we now have an even more effective method of dealing with vulnerable or out-of-date plugins. Instead of choosing between vulnerable but useful (by allowing an old plugin to run automatically) and safe but less useful (by completely disabling old plugins), click-to-play blocklisted plugins gives the user the ability to make an informed decision depending on their current activity. For instance, when browsing a reputable video sharing website, a user might feel safe enough to enable a vulnerable plugin in order to view the site’s content (in fact, the trusted site can be whitelisted using the “Always activate plugins for this site” option in the button drop-down menu). Of course, it would be best if the user upgraded the plugin to a secure version, but perhaps they can’t for one reason or another. In another scenario, they might not fully trust a site they arrive at after visiting a link sent from a friend. In this case, the blocklisted plugin would not automatically run, and the user would be protected.

At the moment, click-to-play blocklisted plugins is a security feature that protects against drive-by attacks targeting plugins that are known to be vulnerable. It does not prevent attacks where a user is convinced to activate a vulnerable plugin on a malicious site. It also is not an all-purpose plugin management system.

This feature is enabled by default, so users are automatically protected. For the adventurous, the about:config preference “plugins.click_to_play” can be set to true to enable click-to-play for all plugins, not just out-of-date ones. However, this aspect of the feature is still in development.

This feature is currently in Firefox Beta, so grab a copy. For more information about the specific plugins we’re starting with, visit the add-ons blog. There is also more information in a few bugs.

Security Vulnerability in Firefox 16

mcoates

155

Update (Oct 11, 2012)
  • An update to Firefox for Windows, Mac and Linux was released at 12pm PT on Oct 11. Users will be automatically updated and new downloads via http://www.mozilla.org/firefox/new/ will receive the updated version (16.0.1).
  • A fix for the Android version of Firefox was released at 9pm PT on Oct 10.
Issue:
Mozilla is aware of a security vulnerability in the current release version of Firefox (version 16). We are actively working on a fix and plan to ship updates tomorrow. Firefox version 15 is unaffected.

 

Impact:
The vulnerability could allow a malicious site to potentially determine which websites users have visited and have access to the URL or URL parameters.  At this time we have no indication that this vulnerability is currently being exploited in the wild.

 

Status:
Firefox 16 has been temporarily removed from the current installer page and users will automatically be upgraded to the new version as soon as it becomes available.  As a precaution, users can downgrade to version 15.0.1 by following these instructions [http://www.mozilla.org/firefox/new/].  Alternatively, users can wait until our patches are issued and automatically applied to address the vulnerability.

 

Michael Coates
Director of Security Assurance

OWASP ZAP – the Firefox of web security tools

Simon Bennetts

4

The OWASP Zed Attack Proxy (otherwise known as ZAP) is a free security tool which you can use to find security vulnerabilities in web applications.

 

My name is Simon Bennetts, and I am the ZAP Project Leader; there is also an international group of volunteers who develop and support it. Future posts on the ZAP blog will describe the features that ZAP provides and how you can use them, but this post will concentrate on the philosophy behind ZAP.

 

Some of the ideals that have driven ZAP are listed below and will be expanded upon in the rest of this post:
  • help users develop and apply application security skills
  • build a competitive, open source, and community oriented platform
  • provide an extensible platform for testing
  • designed to be easy to use
  • raise the bar for other security tools
Helping users learn about Application Security
Unlike many security tools ZAP is designed to be used by people new to application security as well as security professionals.
My background is in development, and I started playing around with the Paros Proxy (from which I forked ZAP) as a way to learn about security tools. Helping people to learn about application security has been, and will remain, an essential goal for ZAP.
The open nature of ZAP is key here – users can delve into the code to see how it works. Anyone who thinks they can make an improvement has the opportunity to implement those changes, feed them back and be credited for them. Developers can work on ZAP to help them learn about security, and security people can work on ZAP to help them learn about coding.

 

An Open Source, Community based project
Like all OWASP projects, ZAP is open source and completely free to use. This means that there is no ‘pro’ version, so there is no incentive for us to hold back features for the ‘paid-for’ version. ZAP is also a community based project, which is an important distinction when compared with some other tools.
There are many security tools that are open source but are still tightly controlled by one individual or company. While a user can see how these products work it is often difficult to change them or influence their direction.
Anyone can get involved with the ZAP development – once someone has shown that they can produce good quality code and conform to ZAP guidelines then they can get commit access!
There are plenty of opportunities for non coders to get involved too – testing, documentation, training videos, translating – all contributions are welcomed and credited.

 

An Extensible platform for testing web applications
In addition to improving the core feature set for ZAP, we are working to ensure that as much of ZAP functionality is implemented as extensions or addons, which can easily be added to existing ZAP releases. This means that new features can be added dynamically without having to wait for full ZAP releases, and also means that we can accommodate features that will only appeal to a small subset of our users.
The ZAP community is very supportive of people who want to learn about coding or security, and we have just benefited from 3 students producing excellent enhancements to ZAP as part of the Google Summer of Code.

 

Ease of use as a design goal
We realize that developers and functional testers will probably spend a relatively small amount of time using security tools, so we want ZAP to be as intuitive as possible.
But we try to maintain a balance between making things as simple as possible while at the same time not over simplifying them.
While there is no ‘big red button’ in ZAP which will solve all of your security problems,
ZAP provides a set of automated tools which will help individuals assess the security of applications.
ZAP also provides a set of manual tools which can be used by people with more knowledge, which is one of the reasons it has been so enthusiastically adopted by professional pentesters. Inexperienced users can start off using the automated tools and gradually use more and more of the manual features as they improve their knowledge of application security.

 

Raising the bar for security tools
Another way ZAP can help application security in general is by raising the bar for other security tools, commercial or otherwise. Other products are free to reuse our source code (with acknowledgement;) and also free to copy or be ‘inspired’ by features that are implemented in ZAP.
In fact we welcome such reuse as it will provide the following benefits:
  • improving other tools, which increases user choice
  • broadens the availability of effective security tools
  • allows feature parity across tools which will drive innovation and competition
Conclusion

In conclusion, ZAP is a free, open-source community developed tool aimed at making the online world more secure. Anyone can get involved developing the core engine, or by creating addons which have full access to the core functionality. And that will probably sound vaguely familiar as its very close to the philosophy behind Mozilla Firefox.

Its why I’m working for Mozilla as a security automation engineer, and the justification for this blog’s title:)

If you have any interest in application security then you should download ZAP and try it out. And if you would like to learn more, or help to make ZAP better then please get in touch with me.

Simon Bennetts
OWASP ZAP Project Lead
Mozilla Security Automation Engineer

Protecting Users Against Java Security Vulnerability

mcoates

26

Update – Aug 31, 2012

Yesterday Oracle released a patch for the critical vulnerabilities identified within Java.

Visit the Mozilla Plugin Check webpage to find out if your Java plugin needs to be updated:
https://www.mozilla.org/plugincheck/

Additional information from Oracle can be found here:
https://blogs.oracle.com/security/entry/security_alert_for_cve_20121

 

Update – Aug 29, 2012:

We’ve been closely monitoring the recent Java security vulnerability and evaluating different options to best protect our users.

Our goal is to provide protection to Firefox users against this actively exploited vulnerability in Java while also leaving the user in control so they can choose to allow Java on important sites that they trust.

We are still working out the implementation details, but our solution will accomplish two primary objectives:

  1. By default, vulnerable versions of Java will be disabled for our Firefox users.
  2. Users will be provided the option to enable Java through a clear and visible message that will be displayed anytime the user views a page using Java.

We’ll provide additional updates when items are finalized. In the interim, we still advise users to disable the Java plugin as described below.

Lastly, starting this week in Aurora and Beta we’ll begin adding the components of click-to-play, a Firefox security control that helps protect users against outdated and vulnerable plugins. We anticipate this new security feature to be fully operational by Firefox 18.

 

Original Post Aug 28, 2012

Issue

Mozilla is aware of a security vulnerability (CVE-2012-4681) in the current version of Java 7 (version 1.7, updates 0 through 6) that is being actively exploited to compromise users. Firefox users may be vulnerable to this issue if they are running the Java plugin within their browser.

Impact to Users

An attacker could exploit this vulnerability to download and execute malware on to a user’s machine.

We have received reports of this vulnerability being actively used in targeted attacks and the malicious exploit code is also available in common exploit kits indicating the number of attacks may increase.

Status

At this time there is no patch available from Oracle to address the vulnerability within Java. We recommend that users disable the Java plugin within Firefox to ensure they are protected against this vulnerability.

Steps to disable the Java plugin can be found here:
http://support.mozilla.org/kb/How+to+turn+off+Java+applets

Protect Your Machine From Losing Internet Connectivity Due to DNSChanger Virus

jstevensen

3

On Monday July, 9, 2012, approximately 250,000 internet users may lose access to the internet because of changes made to their computers by a malicious virus. The virus that caused this problem is commonly referred to as “DNSChanger”.
If your computer is infected, your computer may be accessing malicious DNS servers that would give fake answers, alter your searches, and promote fake and dangerous computer products. In addition, an infected computer will show you an altered version of internet sites. There are many ways a machine could have become infected with the DNSChanger virus including not applying operating system, browser, and browser plugin security updates.
On July 9, those malicious servers that your computer may be communicating with will be shut down by the FBI. If you are infected with DNSChanger, you will lose access to the internet.
We’re reaching out to as many internet users as possible in order to avoid any disruptions in internet service Monday. Here are a few things you can do now to see if you will be affected by this.
How can you detect if your computer has been infected with DNSChanger?
There are multiple websites that have been constructed to help users determine if they are infected with DNSChanger.  A full list, available in multiple languages, can be found at: http://www.dcwg.org/detect
Each site is designed a little different; however, the site http://www.dns-ok.us will state whether or not your computer is infected  by displaying a green or red graphic.
If you see a message like the following:
then you are not affected by DNSChanger and no action is needed.
What can I do if my computer has been infected with DNSChanger?
If the Check-Up Site indicates that you are affected then either follow the instructions on that site or go to the http://www.dcwg.org/fix page. This page contains links to detailed tips, tools, and procedures on removing the effects of the DNSChanger virus.
How do I protect my computer from viruses in the future?
Ensure you are regularly updating your operating system and web browser. It’s also important to ensure your plugins are up to date. Check out the following page to learn about keeping your plugins current: http://www.mozilla.org/en-US/plugincheck

“Subscription Trap” Websites

mcoates

“Subscription trap” websites prey on users who are trying to download
legitimate free software. These sites trick users into paying for
expensive subscriptions for otherwise free software. Some even go as far
as threatening users with collection efforts to compel payment. Such
sites have long been a cause for complaint among Firefox users,
particularly in Germany.

State authorities are starting to take the threat to consumers from such
sites seriously. Recently, a criminal court in Hamburg convicted 7
operators of fraud for the operation of such download websites. Part of
the case was based on the unlawful use and infringement of Mozilla’s
trademarks along with a host of other brand owners.

We provided evidence in the case to assist the prosecutors in
establishing their claims. We hope that this will make the Internet a
safer place for people who want to download Firefox and other free software.