MozDef: The Mozilla Defense Platform v1.9

Jeff Bryner

1

At Mozilla we’ve been using The Mozilla Defense Platform (lovingly referred to as MozDef) for almost two years now and we are happy to release v1.9. If you are unfamiliar, MozDef is a Security Information and Event Management (SIEM) overlay for ElasticSearch.

MozDef aims to bring real-time incident response and investigation to the defensive tool kits of security operations groups in the same way that Metasploit, LAIR and Armitage have revolutionized the capabilities of attackers.

We use MozDef to ingest security events, alert us to security issues, investigate suspicious activities, handle security incidents and to visualize and categorize threat actors. The real-time capabilities allow our security personnel all over the world to work collaboratively even though we may not sit in the same room together and see changes as they occur. The integration plugins allow us to have the system automatically respond to attacks in a preplanned fashion to mitigate threats as they occur.

We’ve been on a monthly release cycle since the launch, adding features and squashing bugs as we find them. You can find the release notes for this version here.

Notable changes include:

  •  Support for Google API logs (login/logout/suspicious activity for Google Drive/Docs)
  •  http://cymon.io api integration
  •  myo armband integration

Using the Myo armband in a TLS environment may require some tweaking to allow the browser to connect to the local Myo agent. Look for a how-to in the docs section soon.

Feel free to take it for a spin on the demo site. You can login by creating any test email/password combination you like. The demo site is rebuilt occasionally so don’t expect anything you put there to live for more than a couple days but feel free to test it out.

Development for the project takes place at mozdef.com and report any issues using the github issue tracker.

May 2015 CA Communication

kwilson

1

Mozilla has sent a Communication to the Certification Authorities (CAs) who have root certificates included in Mozilla’s program. Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.

The CA Communication has been emailed to the Primary Point of Contact (POC) for each CA in Mozilla’s program, and they have been asked to respond to 5 action items:

  1. Confirm that they are the current Primary POC, or give alternative details;
  2. Confirm that Mozilla has the correct link to their most recent Baseline Requirements audit statement;
  3. Update us on their progress in eliminating use of SHA-1 as a certificate signature algorithm;
  4. Inform us whether they are still issuing certificates with certain problems identified when we moved to mozilla::pkix; and
  5. Tell us about their support for IPv6.

The full action items can be read here. Responses to the survey will be collated using Salesforce and the answers published in June.

With this CA Communication, we re-iterate that participation in Mozilla’s CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve.

Mozilla Security Team

Deprecating Non-Secure HTTP

rbarnes

288

Today we are announcing our intent to phase out non-secure HTTP.

There’s pretty broad agreement that HTTPS is the way forward for the web.  In recent months, there have been statements from IETF, IAB (even the other IAB), W3C, and the US Government calling for universal use of encryption by Internet applications, which in the case of the web means HTTPS.

After a robust discussion on our community mailing list, Mozilla is committing to focus new development efforts on the secure web, and start removing capabilities from the non-secure web.  There are two broad elements of this plan:

  1. Setting a date after which all new features will be available only to secure websites
  2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.

For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”.  For example, one definition of “new” could be “features that cannot be polyfilled”.  That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using <canvas>).  But it would still restrict qualitatively new features, such as access to new hardware capabilities.

The second element of the plan will need to be driven by trade-offs between security and web compatibility.  Removing features from the non-secure web will likely cause some sites to break.  So we will have to monitor the degree of breakage and balance it with the security benefit.  We’re also already considering softer limitations that can be placed on features when used by non-secure sites.  For example, Firefox already prevents persistent permissions for camera and microphone access when invoked from a non-secure website.  There have also been some proposals to limit the scope of non-secure cookies.

It should be noted that this plan still allows for usage of the “http” URI scheme in legacy content. With HSTS and the upgrade-insecure-requests CSP attribute, the “http” scheme can be automatically translated to “https” by the browser, and thus run securely.

Since the goal of this effort is to send a message to the web developer community that they need to be secure, our work here will be most effective if coordinated across the web community.  We expect to be making some proposals to the W3C WebAppSec Working Group soon.

Thanks to the many people who participated in the mailing list discussion of this proposal.  Let’s get the web secured!

Richard Barnes, Firefox Security Lead

Update (2015-05-01): Since there are some common threads in the comments, we’ve put together a FAQ document with thoughts on free certificates, self-signed certificates, and more.

Removing e-Guven CA Certificate

kwilson

3

The Certification Authority (CA) certificate owned by e-Guven Elektronik Bilgi Guvenligi A.S. will be removed in Firefox 38 due to insufficient and outdated audits.

The integrity of the secure Web depends on CAs issuing certificates that correctly attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. Inclusion of a CA certificate in Mozilla products involves a rigorous process and evaluation of the CA’s public-facing policy documentation and audit statements, in order to verify that the CA conforms to the criteria required by Mozilla’s CA Certificate Inclusion Policy.

The CA certificates included in the Mozilla list can be marked as trusted for various purposes, so that the software can use the CA certificates to verify certificates for (1) SSL/TLS servers, (2) S/MIME email users, and/or (3) digitally-signed code objects, without having to ask users for further permission or information. When a CA certificate is trusted for verifying certificates for SSL/TLS servers, Mozilla’s CA Certificate Inclusion Policy requires CAs to annually provide public-facing attestation from an independent party stating that they have audited the CA using one of the following two sets of criteria:

1) Clause 7, “Requirements on CA practice”, in ETSI TS 102 042 V2.3.1 or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to the “EVCP” and “EVCP+” certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates – baseline requirements, and any of the “NCP”, “NCP+”, or “LCP” certificate policies);
OR
2) WebTrust “Principles and Criteria for Certification Authorities 2.0″ or later and “SSL Baseline Requirements Audit Criteria V1.1” (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities

Despite many requests for E-Guven to provide current public-facing audit statements that meet the requirements of Mozilla’s CA Certificate Inclusion Policy, the audit statement that Mozilla has for E-Guven indicates that the last supervision of E-Guven was held in 2013 and was not performed according to either of the above sets of criteria. Therefore, discussion about this CA was held in the mozilla.dev.security.policy forum, and the consensus was that E-Guven’s root certificate should be removed.

As always, we recommend that all users upgrade to the latest version of Firefox. This particular change will be in Firefox 38 and future releases of Firefox.

Mozilla Security Team

Distrusting New CNNIC Certificates

kwilson

96

Last week, Mozilla was notified that a Certificate Authority (CA) called CNNIC had issued an unconstrained intermediate certificate, which was subsequently used by the recipient to issue certificates for domain names the holder did not own or control (i.e., for MitM). We added the intermediate certificate in question to Firefox’s direct revocation system, called OneCRL, and have been further investigating the incident.

After reviewing the circumstances and a robust discussion on our public mailing list, we have concluded that CNNIC’s behaviour in issuing an unconstrained intermediate certificate to a company with no documented PKI practices and with no oversight of how the private key was stored or controlled was an ‘egregious practice’ as per Mozilla’s CA Certificate Enforcement Policy. Therefore, after public discussion and consideration of the scope and impact of a range of options, we have decided to update our code so that Mozilla products will no longer trust any certificate issued by CNNIC’s roots with a notBefore date on or after 1st April 2015. We have put together a longer document with more details on the incident and how we arrived at the conclusion we did.

CNNIC may, if they wish, re-apply for full inclusion in the Mozilla root store and the removal of this restriction, by going through Mozilla’s inclusion process after completing additional steps that the Mozilla community may require as a result of this incident. This will be discussed in the mozilla.dev.security.policy forum.

The notBefore date that will be checked is inserted into the certificate by CNNIC. We will therefore be asking CNNIC for a comprehensive list of their currently-valid certificates, and publishing it. After the list has been provided, if a certificate not on the list, with a notBefore date before 1 April 2015, is detected on the public Internet by us or anyone else, we reserve the right to take further action.

We believe that this response is consistent with Mozilla policy and is one which we could apply to any other CA in the same situation.

Mozilla Security Team

Introducing Project Seasponge: Quick and Easy Threat Modeling

Jeff Bryner

2

Threat modeling is a crucial but often neglected part of developing, implementing and operating any system. If you have no mental model of a system or its strengths and weaknesses it is extremely difficult to secure it correctly.

In an effort to help make threat modeling easier a Mozilla Winter of Security (MWOS) team has developed Seasponge, a browser-based graphical threat modeling tool. Written specifically for the browser environment, the tool requires no special addons or plugins and allows one to quickly and easily diagram a system and its data flows and begin the important work of focusing on threats.

A demo is worth a thousand meetings and the team of Joel Kuntz, Sarah MacDonald, Glavin Wiechert, Mathew Kallada and professor Dr. Pawan Lingras from Saint Mary’s University in Halifax, Nova Scotia has been generous enough to put together a video explaining the project along with a quick demo:

The code for the project is available on github. A working client is continually posted here for you to try out. Have a look at it and if you spot a bug, or see a feature you’d like please contribute by filing a github issue or even better, by sending a pull request!

Revoking Trust in one CNNIC Intermediate Certificate

kwilson

96

Mozilla was recently notified that an intermediate certificate, which chains up to a root included in Mozilla’s root store, was loaded into a firewall device that performed SSL man-in-the-middle (MITM) traffic management. It was then used, during the process of inspecting traffic, to generate certificates for domains the device owner does not legitimately own or control. The Certificate Authority (CA) has told us that this action was not permitted by their policies and practices and the agreement with their customer, and they have revoked the intermediate certificate that was loaded into the firewall device. While this is not a Firefox-specific issue, to protect our users we are adding the revoked certificate to OneCRL, our mechanism for directly sending revocation information to Firefox which will be shipping in Firefox 37.

Issue
China Internet Network Information Center (CNNIC), a non-profit organization administrated by Cyberspace Administration of China (CAC), operates the “CNNIC Root” and “China Internet Network Information Center EV Certificates Root” certificates that are included in NSS, and used to issue certificates to organizations and the general public. CNNIC issued an unconstrained intermediate certificate that was labeled as a test certificate and had a two week validity, expiring April 3, 2015. Their customer loaded this certificate into a firewall device which performed SSL MITM, and a user inside their network accessed other servers, causing the firewall to issue certificates for domains that this customer did not own or control. Mozilla’s CA Certificate Policy prohibits certificates from being used in this manner when they chain up to a root certificate in Mozilla’s CA program.

Impact
An intermediate certificate that is used for MITM allows the holder of the certificate to decrypt and monitor communication within their network between the user and any website without browser warnings being triggered. An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. Such certificates could deceive users into trusting websites appearing to originate from the domain owners, but actually containing malicious content or software. We believe that this MITM instance was limited to CNNIC’s customer’s internal network.

Status
Mozilla is adding the revoked intermediate certificate that was mis-used in the firewall device to OneCRL which will be shipping in Firefox 37. Additional action regarding this CA will be discussed in the mozilla.dev.security.policy forum. When similar incidents have happened in the past, responses have included requiring additional audits to confirm that the CA updated their procedures, and using name constraints to constrain the CA’s hierarchy to certain domains.

End-user Action
We recommend that all users upgrade to the latest version of Firefox. Firefox 37 and future releases of Firefox (including Firefox 38 ESR) will contain OneCRL which will be used for this certificate revocation and for future certificate revocations of this type.

Credit
Thanks to Google for reporting this issue to us.

Mozilla Security Team

Introducing Masche: memory scanning for server security

Julien Vehent

winterOfSecurity_logo_dark_vertical2Mozilla operates thousands of servers to build products and run services for our users. Keeping these servers secure is the primary concern of the Operations Security team, and the reason why we have built Mozilla InvestiGator (MIG), a cross-platform endpoint security system.

MIG can inspect the file system and network information of thousands of hosts in parallel, which greatly helps increase visibility across the infrastructure. But until recently, it lacked the ability to look into the memory of running processes, a need that often arises during security investigations.

This is where Mozilla Winter of Security team Masche comes into play. Over the last 6 months, students Marco Vanotti, Patricio Palladino, Nahuel Lascano and Agustin Martinez Suñé from University of Buenos Aires, Argentina, have designed and built a memory forensics library that runs on Linux, Mac OS and Windows.

Masche provides basic primitives for scanning the memory of processes without disrupting the normal operations of a system. Compared with frameworks like Volatility or Rekall, Masche does not provide the same level of advanced forensics features. Instead, it focuses on searching for regexes and byte strings in the processes of large pools of systems, and does so live and very fast.

The source code of Masche is completely open source under the Mozilla Public License, version 2.0, and can be found on github at https://github.com/mozilla/masche.

The effort needed to implement a complex scanning solution across three operating systems, and complete this work in just a few months, was no easy feat. In the recording below, Marco, Patricio, Nahuel and Agustin present their work, the challenges they had to overcome, and the necessity to mix Go and C to access the lowest parts of the system.

We are now integrating Masche as a module for MIG with the goal to deploy it across our infrastructure. As we use it more for live memory forensics, we will continue to improve its scanning capabilities and contribute the results back to the community.

Revoking Intermediate Certificates: Introducing OneCRL

mgoodwin

Users of Firefox from Firefox 37 will be protected by a new feature called OneCRL. This is a new mechanism we have introduced to push lists of revoked intermediate certificates to the browser.

Using OCSP for certificate revocation doesn’t serve users very well. For online revocation checks, either you have a system that fails open or you accept the performance penalty of checks that are more strict (as is the case for EV certificates). OCSP stapling can remove the need for live revocation checks, but currently, only only around 9% of TLS connections use it.

OneCRL helps speed up revocation checking by maintaining a centralized list of revoked certificates and pushing it out to browsers. Currently, if a serious incident occurs that requires certificates to be revoked, we release an update to Firefox to address the problem. This is slow because it takes some time for users to get the security update and restart their browsers. There’s also cost involved in producing an update (and users downloading it).

Firefox already has a mechanism for periodically checking for things that may harm users called blocklisting. OneCRL extends the blocklist to include certificates which should be revoked in addition to the errant add-ons, plugins and buggy graphics drivers currently included. This lets users get the benefit of fresh revocation information without having to update or restart their browser.

The other major benefit of OneCRL is speed. For certificates covered by OneCRL, there is no need to do live OCSP checks, so revocation checking incurs no additional latency. The is especially important for EV certificates, where a positive OCSP response is required.

Right now, OneCRL only covers CA intermediate certificates (in order to limit the size of the blocklist). OneCRL is updated when a CA in Mozilla’s root program notifies Mozilla that an intermediate certificate needs to be revoked.

The initial version of OneCRL that we have today is an important step. It will speed up revocation checking, especially for sites that use EV certificates. But we’re not done yet. We’re working on scaling up OneCRL so that its benefits apply more broadly, and on automating the collection of revocation information so that it gets to browsers more quickly.

Getting Superfish out of Firefox

rbarnes

18

First things first: If you are reading this post on a recent Lenovo laptop, please click the lock icon in the URL bar, then click “More Information…”.  If you see “Verified by: Superfish, Inc.”, you are infected with Superfish, and you should follow these instructions to remove it.

The Superfish adware distributed by Lenovo has brought the issue of SSL interception back to the headlines.  SSL interception is a technique that allows other software on a user’s computer to monitor and control their visits to secure Web sites — however, it also enables attackers to masquerade as secure websites, in order to spy on users or steal personal information.  Firefox is affected by Superfish, but Mozilla is deploying a hotfix to Firefox that works with other disinfection software to ensure that Firefox is disinfected as well.

Like other SSL interception software, Superfish seeks to add functionality to the Web by intercepting secure Web connections and injecting content into Web sites.  In order to be able to inject content into secure connections, it adds a trusted root certificate to the Windows and Firefox root stores.  With this trusted authority in place, Superfish can effectively create a fake ID for any website, so that it can convince Firefox that the browser is connected to the real website — even though it’s actually connected to Superfish.

This would be no worse than garden-variety adware if not for the fact that Superfish uses the same root certificate for all infected computers, and the private key for this certificate has been extracted and published to the Internet.  Using this private key, anyone on the Internet (not just Superfish) can create a fake ID that a Superfish-infected browser will accept.  So if you’re using a Superfish-infected computer to connect securely to your bank, you might actually be  connected to a criminal that is presenting a fake ID for your bank.

It appears that on affected systems (e.g., Lenovo laptops pre-loaded with Superfish), Superfish infects Firefox by adding its root certificate to the root store.  The good news is that according to research by Facebook and EFF, it appears that relatively few Firefox users have been infected.  The bad news is that some of the current disinfection tools do not disinfect Firefox.

For users that wish to ensure that they are disinfected, the best thing to do is to follow Lenovo’s instructions for removing Superfish.  This will remove Superfish entirely from the computer, including removing it from Firefox.

Some other disinfection tools will remove Superfish from Windows, but not from Firefox.  In order to ensure that these users are not vulnerable, we are deploying a hotfix today that detects whether Superfish has been removed, and if so, removes the Superfish root from Firefox.  We do not remove the root certificate if the Superfish software is still installed, since that would prevent the user from accessing any HTTPS websites.

Finally, a word to software authors who might be considering SSL interception: If you want to add features to the Web, don’t intercept, make an extension.  All of the major browsers offer extension frameworks (see these links for Firefox, Chrome, IE, Safari, and Opera).   Using these toolkits helps you avoid violating users’ security, while also giving you more powerful, and easier-to-use tools than you can get from an interception system.  The Web works better when we build it together.