Google Security Blog

Bigger Rewards for Security Bugs

Google Security Blog - Thu, 07/18/2019 - 12:01pm
Posted by Natasha Pabrai and Andrew Whalley, Chrome Security Team

Chrome has always been built with security at its core, by a passionate worldwide community as part of the Chromium open source project. We're proud that community includes world class security researchers who help defend Chrome, and other Chromium based browsers.

Back in 2010 we created the Chrome Vulnerability Rewards Program which provides cash rewards to researchers for finding and reporting security bugs that help keep our users safe. Since its inception the program has received over 8,500 reports and paid out over five million dollars! A big thank you to every one of the researchers - it's an honor working with you.

Over the years we've expanded the program, including rewarding full chain exploits on Chrome OS, and the Chrome Fuzzer Program, where we run researchers' fuzzers on thousands of Google cores and automatically submit bugs they find for reward.

Today, we're delighted to announce an across the board increase in our reward amounts! Full details can be found on our program rules page but highlights include tripling the maximum baseline reward amount from $5,000 to $15,000 and doubling the maximum reward amount for high quality reports from $15,000 to $30,000. The additional bonus given to bugs found by fuzzers running under Chrome Fuzzer Program is also doubling to $1,000.

We've also clarified what we consider a high quality report, to help reporters get the highest possible reward, and we've updated the bug categories to better reflect the types of bugs that are reported and that we are most interested in.

But that's not all! On Chrome OS we're increasing our standing reward to $150,000 for exploit chains that can compromise a Chromebook or Chromebox with persistence in guest mode. Security bug in firmware and lock screen bypasses also get their own reward categories.

These new reward amounts will apply to bugs submitted after today on the Chromium bug tracker using the Security template. As always, see the Chrome Vulnerability Reward Program Rules for full details about the program.

In other news, our friends over at the Google Play Security Reward Program have increased their rewards for remote code execution bugs from $5,000 to $20,000, theft of insecure private data from $1,000 to $3,000, and access to protected app components from $1,000 to $3,000. The Google Play Security Reward Program also pays bonus rewards for responsibly disclosing vulnerabilities to participating app developers. Check out the program to learn more and see which apps are in scope.

Happy bug hunting!

Categories: Google Security Blog

How Google adopted BeyondCorp

Google Security Blog - Thu, 06/27/2019 - 12:00pm
Posted by Lior Tishbi, Program Manager and Puneet Goel, Product Manager

It's been almost five years since we released the first of multiple BeyondCorp papers, describing the motivation and design principles that eliminated network-based trust from our internal networks. With that anniversary looming and many organizations actively working to adopt models like BeyondCorp (which has also become known as Zero Trust in the industry), we thought it would be a good time to revisit topics we have previously explored in those papers, share the lessons that we have learned over the years, and describe where BeyondCorp is going as businesses move to the cloud.

This is the first post in a series that will focus on Google’s internal implementation of BeyondCorp, providing necessary context for how Google adopted BeyondCorp.
Why did we adopt BeyondCorp?With a traditional enterprise perimeter security model, access to services and resources is provided by a device being connected to a privileged network. If an employee is in a corporate office, on the right network, services are directly accessible. If they're outside the office, at home or in a coffee shop, they frequently use a VPN to get access to services behind the enterprise firewall. This is the way most organizations protect themselves.

By 2011, it became clear to Google that this model was problematic, and we needed to rethink how enterprise services are accessed and protected for the following reasons:

Improving productivity
  • A growing number of employees were not in the office at all times. They were working from home, a coffee shop, a hotel or even on a bus or airplane. When they were outside the office, they needed to connect via a VPN, creating friction and extending the network perimeter.
  • The user experience of a VPN client may be acceptable, even if suboptimal, from a laptop. Use of VPN is less acceptable, from both employees and admins perspectives, when considering growing use of devices such as smartphones and tablets to perform work.
  • A number of users were contractors or other partners who only needed selective access to some of our internal resources, even though they were working in the office.
Keeping Google secure
  • The expanded use of public clouds and software-as-a-service (SaaS) apps meant that some of our corporate services were no longer deployed on-premises, further blurring the traditional perimeter and trust domain. This introduced new attack vectors that needed to be protected against.
  • There was ongoing concern about relying solely on perimeter defense, especially when the perimeter was growing consistently. With the proliferation of laptops and mobile devices, vulnerable and compromised devices were regularly brought within the perimeter.
  • Finally, if a vulnerability was observed or an attack did happen, we wanted the ability to respond as quickly and automatically as possible.
How did we do it?In order to address these challenges, we implemented a new approach that we called BeyondCorp. Our mission was to have every Google employee work successfully from untrusted networks on a variety of devices without using a client-side VPN. BeyondCorp has three core principles:
  • Connecting from a particular network does not determine which service you can access.
  • Access to services is granted based on what the infrastructure knows about you and your device.
  • All access to services must be authenticated, authorized and encrypted for every request (not just the initial access).


High level architecture for BeyondCorp
BeyondCorp gave us the security that we were looking for along with the user experience that made our employees more productive inside and outside the office.
What lessons did we learn?Given this was uncharted territory at the time, we had to learn quickly and adapt when we encountered surprises. Here are some key lessons we learned.
Obtain executive support early on and keep itMoving to BeyondCorp is not a quick, painless exercise. It took us several years just to get most of the basics in place, and to this day we are still continuing to improve and refine our implementation. Before embarking on this journey to implement BeyondCorp, we got buy in from leadership very early in the project. With a mandate, you can ask for support from lots of different groups along the way.

We make a point to re-validate this buy-in on an ongoing basis, ensuring that the business still understands and values this important shift.
Recognize data quality challenges from the very beginningAccess decisions depend on the quality of your input data. More specifically, it depends on trust analysis, which requires a combination of employee and device data.

If this data is unreliable, the result will be incorrect access decisions, suboptimal user experiences and, in the worst case, an increase in system vulnerability, so the stakes are definitely high.
We put in a lot of work to make sure our data is clean and reliable before making any impactful changes, and we have both workflows and technical measures in place to ensure data quality remains high going forward.
Enable painless migration and usageThe migration should be a zero-touch or invisible experience for your employees, making it easy for them to continue working without interruptions or added steps. If you make it difficult for your employees to migrate or maintain productivity, they might feel frustrated by the process. Complex environments are difficult to fully migrate with initial solutions, so be prepared to review, grant and manage exceptions at least in the early stages. With this in mind, start small, migrate a small number of resources, apps, users and devices, and only increase coverage after confirming the solution is reliable.
Assign employee and helpdesk advocatesWe also had employee and helpdesk advocates on the team who represented the user experience from those perspectives. This helped us architect our implementation in a way that avoided putting excess burden on employees or technical support staff.
Clear employee communicationsCommunicating clearly with employees so that they know what is happening is very important. We sent our employees, partners, and company leaders regular communications whenever we made important changes, ensuring motivations were well understood and there was a window for feedback and iteration prior to enforcement changes.
Run highly reliable systemsSince every request goes through the core BeyondCorp infrastructure, we needed a global, highly reliable and resilient set of services. If these services are degraded, employee productivity suffers.

We used Site Reliability Engineering (SRE) principles to run our BeyondCorp services.
Next timeIn the next post in this series, we will go deeper into when you should trust a device, what data you should use to determine whether or not a device should be trusted, and what we have learned by going through that process.

In the meantime, if you want to learn more, you can check out the BeyondCorp research papers. In addition, getting started with BeyondCorp is now easier using zero trust solutions from Google Cloud (context-aware access) and other enterprise providers.
Categories: Google Security Blog

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

Google Security Blog - Wed, 06/26/2019 - 12:00pm
Posted by Marshall Vale, Product Manager and Alexander Dupuy, Software Engineer

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!
Categories: Google Security Blog