Author Archives: Google Security PR

Protecting Chrome users in Kazakhstan



When making secure connections, Chrome trusts certificates that have been locally installed on a user's computer or mobile device. This allows users to run tools to inspect and debug connections during website development, or for corporate environments to intercept and monitor internal traffic. It is not appropriate for this mechanism to be used to intercept traffic on the public internet.

In response to recent actions by the Kazakhstan government, Chrome, along with other browsers, has taken steps to protect users from the interception or modification of TLS connections made to websites.

Chrome will be blocking the certificate the Kazakhstan government required users to install:

Common Name
Qaznet Trust Network
SHA-256 Fingerprint
00:30:9C:73:6D:D6:61:DA:6F:1E:B2:41:73:AA:84:99:44:C1:68:A4:3A:15:
BF:FD:19:2E:EC:FD:B6:F8:DB:D2
SHA-256 of Subject Public Key Info
B5:BA:8D:D7:F8:95:64:C2:88:9D:3D:64:53:C8:49:98:C7:78:24:91:9B:64:
EA:08:35:AA:62:98:65:91:BE:50


The certificate has been added to CRLSet. No action is needed by users to be protected. In addition, the certificate will be added to a blocklist in the Chromium source code and thus should be included in other Chromium based browsers in due course.

New Research: Lessons from Password Checkup in action



Back in February, we announced the Password Checkup extension for Chrome to help keep all your online accounts safe from hijacking. The extension displays a warning whenever you sign in to a site using one of over 4 billion usernames and passwords that Google knows to be unsafe due to a third-party data breach. Since our launch, over 650,000 people have participated in our early experiment. In the first month alone, we scanned 21 million usernames and passwords and flagged over 316,000 as unsafe---1.5% of sign-ins scanned by the extension.
Today, we are sharing our most recent lessons from the launch and announcing an updated set of features for the Password Checkup extension. Our full research study, available here, will be presented this week as part of the USENIX Security Symposium.

Which accounts are most at risk?

Hijackers routinely attempt to sign in to sites across the web with every credential exposed by a third-party breach. If you use strong, unique passwords for all your accounts, this risk disappears. Based on anonymous telemetry reported by the Password Checkup extension, we found that users reused breached, unsafe credentials for some of their most sensitive financial, government, and email accounts. This risk was even more prevalent on shopping sites (where users may save credit card details), news, and entertainment sites.

In fact, outside the most popular web sites, users are 2.5X more likely to reuse vulnerable passwords, putting their account at risk of hijacking.
Anonymous telemetry reported by Password Checkup extension shows that users most often reuse vulnerable passwords on shopping, news, and entertainment sites.


Helping users re-secure their unsafe passwords

Our research shows that users opt to reset 26% of the unsafe passwords flagged by the Password Checkup extension. Even better, 60% of new passwords are secure against guessing attacks—meaning it would take an attacker over a hundred million guesses before identifying the new password.
Improving the Password Checkup extension

Today, we are also releasing two new features for the Password Checkup extension. The first is a direct feedback mechanism where users can inform us about any issues that they are facing via a quick comment box. The second gives users even more control over their data. It allows users to opt-out of the anonymous telemetry that the extension reports, including the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the domain involved for improving site coverage. By design, the Password Checkup extension ensures that Google never learns your username or password, regardless of whether you enable telemetry, but we still want to provide this option if users would prefer not to share this information.


We're continuing to improve the Password Checkup extension and exploring ways to implement its technology into Google products. For help keeping all your online accounts safe from hijacking, you can install the Password Checkup extension here today.

Awarding Google Cloud Vulnerability Research



Today, we’re excited to announce a yearly Google Cloud Platform (GCP) VRP Prize to promote security research of GCP. A prize of $100,000.00 will be paid to the reporter of the best vulnerability affecting GCP reported through our Vulnerability Reward Program (g.co/vulnz) and having a public write-up (nominations will be received here).

We’ve received vulnerability reports for various application security flaws in GCP over the years, but we felt research of our Cloud platform has been under-represented in our Vulnerability Reward Program. So, with the GCP VRP Prize, we hope to encourage even more researchers to focus on GCP products and help us identify even more security vulnerabilities.

Note that we will continue to pay hundreds of thousands of dollars to our top bug hunters through our Vulnerability Research Grants Program even when no bugs are found, and to reward up to tens of thousands of dollars per bug to the most impactful findings. This prize is meant to create an additional incentive for more people to focus on public, open security research on GCP who would otherwise not participate in the reward program.

This competition draws on our previous contests, such as Pwnium and the Project Zero Prize, and rather than focusing bug hunters on collecting vulnerabilities for complex bug chains, we are attempting a slightly different twist and selecting a single winner out of all vulnerabilities we receive. That said, this approach comes with its own challenges, such as: defining the right incentives for bug hunters (both in terms of research as well as their communications with our team when reporting vulnerabilities); or ensuring there are no conflicting incentives, either when our own team is looking for similar vulnerabilities (since we aren't eligible for collecting the prize).

For the rest of the year, we will be seeking feedback from our top bug hunters and the security community to help define what vulnerabilities are the most significant, and we hope we can work together to find the best way to incentivize, recognize, and reward open security research. To further incentivize research in 2019, we will be issuing GCP VRP grants summing up to $100,000 to our top 2018 researchers.

Head over here for the full details on the contest. Note that if you have budget constraints for access to testing environments, you can use the free tier of GCP.

We look forward to our Vulnerability Rewards Programs resulting in even more GCP customer protection in the following years thanks to the hard work of the security research community. Follow us on @GoogleVRP.

Google Public DNS over HTTPS (DoH) supports RFC 8484 standard



Ever since we launched Google Public DNS in 2009, our priority has been the security of DNS resolution. In 2016, we launched a unique and innovative experimental service -- DNS over HTTPS, now known as DoH. Today we are announcing general availability for our standard DoH service. Now our users can resolve DNS using DoH at the dns.google domain with the same anycast addresses (like 8.8.8.8) as regular DNS service, with lower latency from our edge PoPs throughout the world.

General availability of DoH includes full RFC 8484 support at a new URL path, and continued support for the JSON API launched in 2016. The new endpoints are:

  • https://dns.google/dns-query (RFC 8484 – GET and POST)
  • https://dns.google/resolve (JSON API – GET)
We are deprecating internet-draft DoH support on the /experimental URL path and DoH service from dns.google.com, and will turn down support for them in a few months.

With Google Public DNS, we’re committed to providing fast, private, and secure DNS resolution through both DoH and DNS over TLS (DoT). We plan to support the JSON API until there is a comparable standard for webapp-friendly DoH.


What the new DoH service means for developers

To use our DoH service, developers should configure their applications to use the new DoH endpoints and properly handle HTTP 4xx error and 3xx redirection status codes.
  • Applications should use dns.google instead of dns.google.com. Applications can query dns.google at well-known Google Public DNS addresses, without needing an extra DNS lookup.
  • Developers using the older /experimental internet-draft DoH API need to switch to the new /dns-query URL path and confirm full RFC 8484 compliance. The older API accepts queries using features from early drafts of the DoH standard that are rejected by the new API.
  • Developers using the JSON API can use two new GET parameters that can be used for DNS/DoH proxies or DNSSEC-aware applications.
Redirection of /experimental and dns.google.com

The /experimental API will be turned down in 30 days and HTTP requests for it will get an HTTP redirect to an equivalent https://dns.google/dns-query URI. Developers should make sure DoH applications handle HTTP redirects by retrying at the URI specified in the Location header.

Turning down the dns.google.com domain will take place in three stages.
  1. The first stage (in 45 days) will update the dns.google.com domain name to return 8.8.8.8 and other Google Public DNS anycast addresses, but continue to return DNS responses to queries sent to former addresses of dns.google.com. This will provide a transparent transition for most clients.
  2. The second stage (in 90 days) will return HTTP redirects to dns.google for queries sent to former addresses of dns.google.com.
  3. The final stage (in 12 months) will send HTTP redirects to dns.google for any queries sent to the anycast addresses using the dns.google.com domain.
We will post timelines for redirections on the public‑dns‑announce forum and on the DoH migration page. You can find further technical details in our DoH documentation, and if you have a question or problem with our DoH service, you can create an issue on our tracker or ask on our discussion group. As always, please provide as much information as possible to help us investigate the problem!

Better protection against Man in the Middle phishing attacks



We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.

What developers need to know

The solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.

Better protection against Man in the Middle phishing attacks



We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.

What developers need to know

The solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.

Gmail making email more secure with MTA-STS standard



We’re excited to announce that Gmail will become the first major email provider to follow the new SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 and SMTP TLS Reporting RFC 8460 internet standards. Those new email security standards are the result of three years of collaboration within IETF, with contributions from Google and other large email providers.

SMTP alone is vulnerable to man-in-the-middle attacks

Like all mail providers, Gmail uses Simple Mail Transfer Protocol (SMTP) to send and receive mail messages. SMTP alone only provides best-effort security with opportunistic encryption, and many SMTP servers do not prevent certain types of malicious attacks intercepting email traffic in transit.

SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection. Real attacks and prevention were highlighted in our research published in November 2015. MTA-STS will help prevent these types of attacks.

MTA-STS uses encryption and authentication to reduce vulnerabilities

A MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.

Gmail is starting MTA-STS adherence. We hope others will follow

Gmail the first major provider to follow the new standard, initially launching in Beta on April 10th 2019. This means Gmail will honor MTA-STS and TLS reporting policies configured when sending emails to domains that have defined these policies. We hope many other email providers will soon adopt these new standards that make email communications more secure.

Email domain administrators should set up DNS records and web server endpoint to configure MTA-STS and TLS reporting policies for incoming emails. Use our Help Center to find out how to set up an MTA-STS policy with your DNS server. G Suite admins can use the G Suite Updates blog to see what MTA-STS means for G Suite domains.

Open-sourcing Sandboxed API



Many software projects process data which is externally generated, and thus potentially untrusted. For example, this could be the conversion of user-provided picture files into different formats, or even executing user-generated software code.
When a software library parsing such data is sufficiently complex, it might fall victim to certain types of security vulnerabilities: memory corruption bugs or certain other types of problems related to the parsing logic (e.g. path traversal issues). Those vulnerabilities can have serious security implications.

In order to mitigate those problems, developers frequently employ software isolation methods, a process commonly referred to as sandboxing. By using sandboxing methods, developers make sure that only resources (files, networking connections and other operating system resources) which are deemed necessary are accessible to the code involved in parsing user-generated content. In the worst-case scenario, when potential attackers gain remote code execution rights within the scope of a software project, a sandboxing technique can contain them, protecting the rest of the software infrastructure.

Sandboxing techniques must be highly resistant to attacks and sufficiently protect the rest of the operating system, yet must be sufficiently easy-to-use for software developers. Many popular software containment tools might not sufficiently isolate the rest of the OS, and those which do, might require time-consuming redefinition of security boundaries for each and every project that should be sandboxed.

Sandbox once, use anywhere

To help with this task, we are open-sourcing our battle-tested project called Sandboxed API. Sandboxed API makes it possible to create security policies for individual software libraries. This concept allows to create reusable and secure implementations of functionality residing within popular software libraries, yet is granular enough to protect the rest of used software infrastructure.

As Sandboxed API serves the purpose of accessing individual software functions inside a sandboxed library, we are also making publicly available our core sandboxing project, Sandbox2. This is now part of Sandboxed API and provides the underlying sandboxing primitives. It can be also used standalone to isolate arbitrary Linux processes, but is considered a lower-level API.

Overview

Sandboxed API is currently implemented for software libraries written in the C programming language (or providing C bindings), though we might add support for more programming runtimes in the future.

From a high-level perspective, Sandboxed API separates the library to be sandboxed and its callers into two separate OS processes: the host binary and the sandboxee. Actual library calls are then marshalled by an API object on the host side and send via interprocess communication to the sandboxee where an RPC stub unmarshals and forwards calls to the original library.

Both the API object (SAPI object) and the RPC stub are provided by the project, with the former being auto-generated by an interface generator. Users just need to provide a sandbox policy, a set of system calls that the underlying library is allowed to make, as well as the resources it is allowed to access and use. Once ready, a library based on sandboxed API can easily be reused in other projects.

The resulting API of the SAPI object is similar to the one of the original library. For example, when using zlib, the popular compression library, a code snippet like this compresses a chunk of data (error handling omitted for brevity):


void Compress(const std::string& chunk, std::string* out) {
 z_stream zst{};
 constexpr char kZlibVersion[] = "1.2.11";
 CHECK(deflateInit_(&zst, /*level=*/4, kZlibVersion, sizeof(zst)) == Z_OK);

 zst.avail_in = chunk.size();
 zst.next_in = reinterpret_cast<uint8_t*>(&chunk[0]);
 zst.avail_out = out->size();
 zst.next_out = reinterpret_cast<uint8_t*>(&(*out)[0]);
 CHECK(deflate(&zst, Z_FINISH) != Z_STREAM_ERROR);
 out->resize(zst.avail_out);

 deflateEnd(&zst);
}


Using Sandboxed API, this becomes:
void CompressSapi(const std::string& chunk, std::string* out) {
 sapi::Sandbox sandbox(sapi::zlib::zlib_sapi_embed_create());
 CHECK(sandbox.Init().ok());
 sapi::zlib::ZlibApi api(&sandbox);

 sapi::v::Array<uint8_t> s_chunk(&chunk[0], chunk.size());
 sapi::v::Array<uint8_t> s_out(&(*out)[0], out->size());
 CHECK(sandbox.Allocate(&s_chunk).ok() && sandbox.Allocate(&s_out).ok());
 sapi::v::Struct<sapi::zlib::z_stream> s_zst;
 
 constexpr char kZlibVersion[] = "1.2.11";
 sapi::v::Array<char> s_version(kZlibVersion, ABSL_ARRAYSIZE(kZlibVersion));
 CHECK(api.deflateInit_(s_zst.PtrBoth(), /*level=*/4, s_version.PtrBefore(),
                         sizeof(sapi::zlib::z_stream).ValueOrDie() == Z_OK));

 CHECK(sandbox.TransferToSandboxee(&s_chunk).ok());
 s_zst.mutable_data()->avail_in = chunk.size();
 s_zst.mutable_data()->next_in = reinterpet_cast<uint8_t*>(s_chunk.GetRemote());
 s_zst.mutable_data()->avail_out = out->size();
 s_zst.mutable_data()->next_out = reinterpret_cast<uint8_t*>(s_out.GetRemote());
 CHECK(api.deflate(s_zst.PtrBoth(), Z_FINISH).ValueOrDie() != Z_STREAM_ERROR);
 CHECK(sandbox.TransferFromSandboxee(&s_out).ok());
 out->resize(s_zst.data().avail_out);

 CHECK(api.deflateEnd(s_zst.PtrBoth()).ok());
}
As you can see, when using Sandboxed API there is extra code for setting up the sandbox itself and for transferring memory to and from the sandboxee, but other than that, the code flow stays the same.

Try for yourself

It only takes a few moments to get up and running with Sandboxed API. If Bazel is installed:
sudo apt-get install python-typing python-clang-7 libclang-7-dev linux-libc-dev
git clone github.com/google/sandboxed-api && cd sandboxed-api
bazel test //sandboxed_api/examples/stringop:main_stringop
This will download the necessary dependencies and run the project through its paces. More detailed instructions can be found in our Getting Started guide and be sure to check out the examples for Sandboxed API.

Where do we go from here?

Sandboxed API and Sandbox2 are used by many teams at Google. While the project is mature, we do have plans for the future beyond just maintaining it:

  • Support more operating systems - So far, only Linux is supported. We will look into bringing Sandboxed API to the Unix-like systems like the BSDs (FreeBSD, OpenBSD) and macOS. A Windows port is a bigger undertaking and will require some more groundwork to be done.
  • New sandboxing technologies - With things like hardware-virtualization becoming almost ubiquitous, confining code into VMs for sandboxing opens up new possibilities.
  • Build system - Right now, we are using Bazel to build everything, including dependencies. We acknowledge that this is not how everyone will want to use it, so CMake support is high on our priority list.
  • Spread the word - Use Sandboxed API to secure open source projects. If you want to get involved, this work is also eligible for the Patch Reward Program.
Get involved

We are constantly looking at improving Sandboxed API and Sandbox2 as well as adding more features: supporting more programming runtimes, different operating systems or alternative containment technologies.

Check out the Sandboxed API GitHub repository. We will be happy to consider your contributions and look forward to any suggestions to help improve and extend this code.

Protect your accounts from data breaches with Password Checkup



Google helps keep your account safe from hijacking with a defense in depth strategy that spans prevention, detection, and mitigation. As part of this, we regularly reset the passwords of Google accounts affected by third-party data breaches in the event of password reuse. This strategy has helped us protect over 110 million users in the last two years alone. Without these safety measures, users would be at ten times the risk of account hijacking.

We want to help you stay safe not just on Google, but elsewhere on the web as well. This is where the new Password Checkup Chrome extension can help. Whenever you sign in to a site, Password Checkup will trigger a warning if the username and password you use is one of over 4 billion credentials that Google knows to be unsafe.

Password Checkup was designed jointly with cryptography experts at Stanford University to ensure that Google never learns your username or password, and that any breach data stays safe from wider exposure. Since Password Checkup is an early experiment, we’re sharing the technical details behind our privacy preserving protocol to be transparent about how we keep your data secure.
Key design principles

We designed Password Checkup with three key principles in mind:

  • Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.
  • Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.
  • Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.
Settling on an approach

At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, private information retrieval, and a technique called blinding.

Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.

A look under the hood

Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.

Protecting your accounts

Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.

Acknowledgements

This post reflects the work of a large group of Google engineers, research scientists, and others including: Niti Arora, Jacob Barrett, Borbala Benko, Alan Butler, Abhi Chaudhuri, Oxana Comanescu, Sunny Consolvo, Michael Dedrick, Kyler Emig, Mihaela Ion, Ilona Gaweda, Luca Invernizzi, Jozef Janovský, Yu Jiang, Patrick Gage Kelly, Guemmy Kim, Ben Kreuter, Valentina Lapteva, Maija Marincenko, Grzegorz Milka, Angelika Moscicki, Julia Nalven, Yuan Niu, Sarvar Patel, Tadek Pietraszek, Ganbayar Puntsagdash, Ananth Raghunathan, Juri Ranieri, Mark Risher, Masaru Sato, Karn Seth, Juho Snellman, Eduardo Tejada, Tu Tsao, Andy Wen, Kevin Yeo, Moti Yung, and Ali Zand.

Google Public DNS now supports DNS-over-TLS



Google Public DNS is the world’s largest public Domain Name Service (DNS) recursive resolver, allowing anyone to convert Internet domain names like www.example.com into Internet addresses needed by an email application or web browser. Just as your search queries can expose sensitive information, the domains you lookup via DNS can also be sensitive. Starting today, users can secure queries between their devices and Google Public DNS with DNS-over-TLS, preserving their privacy and integrity.

The DNS environment has changed for the better since we launched Google Public DNS over eight years ago. Back then, as today, part of Google Public DNS’ mission has been to improve the security and accuracy of DNS for users all over the world. But today, there is an increased awareness of the need to protect users’ communication with their DNS resolvers against forged responses and safeguard their privacy from network surveillance. The DNS-over-TLS protocol specifies a standard way to provide security and privacy for DNS traffic between users and their resolvers. Now users can secure their connections to Google Public DNS with TLS, the same technology that protects their HTTPS web connections.

We implemented the DNS-over-TLS specification along with the RFC 7766 recommendations to minimize the overhead of using TLS. These include support for TLS 1.3 (for faster connections and improved security), TCP fast open, and pipelining of multiple queries and out-of-order responses over a single connection. All of this is deployed with Google’s serving infrastructure which provides reliable and scalable management for DNS-over-TLS connections.

Use DNS-over-TLS today

Android 9 (Pie) device users can use DNS-over-TLS today. For configuration instructions for Android and other systems, please see the documentation. Advanced Linux users can use the stubby resolver from dnsprivacy.org to talk to Google’s DNS-over-TLS service.

If you have a problem with Google Public DNS-over-TLS, you can create an issue on our tracker or ask on our discussion group. As always, please provide as much information as possible to help us investigate the problem!