Google Online Security Blog

Expanding our work with the open source security community

May 28, 2020

Posted by Eduardo Vela, Vulnerability Collector, Google Google Vulnerability Rewards Program (VRP)Google Kubernetes Engine (GKE)announcedfor Kubernetes
How it works
We have set up a lab environment on GKE based on an open-source Kubernetes-based Capture-the-Flag (CTF) project called kCTF. Participants will be required to:

Break out of a containerized environment running on a Kubernetes pod and,
Read one of two secret flags: One flag is on the same pod, and the other one is in another Kubernetes pod in a different namespace.

Flags will be changed often, and participants need to submit the secret flag as proof of successful exploitation. The lab environment does not store any data (such as the commands or files used to exploit it), so participants need the flags to demonstrate they were able to compromise it.

The rewards will work in the following way:

Bugs that affect the lab GKE environment that can lead to stealing both flags will be rewarded up to 10,000 USD, but we will review each report on a case-by-case basis. Any vulnerabilities are in scope, regardless of where they are: Linux, Kubernetes, kCTF, Google, or any other dependency. Instructions on how to submit the flags and exploits are available here.
Bugs that are 100% in Google code, qualify for an additional Google VRP reward.
Bugs that are 100% in Kubernetes code, qualify for an additional CNCF Kubernetes reward.

Any vulnerabilities found outside of GKE (like Kubernetes or the Linux kernel) should be reported to the corresponding upstream project security teams. To make this program expansion as efficient as possible for the maintainers, we will only reward vulnerabilities shown to be exploitable by stealing a flag. If your exploit relies on something in upstream Kubernetes, the Linux Kernel, or any other dependency, you need to report it there first, get it resolved, and then report it to Google. See instructions here.

The GKE lab environment is built on top of a CTF infrastructure that we just open-sourced on GitHub. The infrastructure is new, and we are looking forward to receiving feedback from the community before it can be actively used in CTF competitions. By including the CTF infrastructure in the scope of the Google VRP, we want to incentivise the community to help us secure not just the CTF competitions that will use it, but also GKE and the broader Kubernetes ecosystems.

In March 2020, we announced the winner for the first Google Cloud Platform (GCP) VRP Prize and since then we have seen increased interest and research happening on Google Cloud. With this new initiative, we hope to bring even more awareness to Google Cloud by experienced security researchers, so we can all work together to secure our shared open-source foundations.

Enhanced Safe Browsing Protection now available in Chrome

May 19, 2020

Posted by Nathan Parker, Varun Khaneja, Eric Mill and Kiran C Nair - Chrome Safe Browsing team Over the past few years we’ve seen threats on the web becoming increasingly sophisticated. Phishing sites rotate domains very quickly to avoid being blocked, and malware campaigns are directly targeting at-risk users. We’ve realized that to combat these most effectively, security cannot be one-size-fits-all anymore: That’s why today we are announcing Enhanced Safe Browsing protection in Chrome, a new option for users who require or want a more advanced level of security while browsing the web. Turning on Enhanced Safe Browsing will substantially increase protection from dangerous websites and downloads. By sharing real-time data with Google Safe Browsing, Chrome can proactively protect you against dangerous sites. If you’re signed in, Chrome and other Google apps you use (Gmail, Drive, etc) will be able to provide improved protection based on a holistic view of threats you encounter on the web and attacks against your Google Account. In other words, we’re bringing the intelligence of Google’s cutting-edge security tools directly into your browser. Over the next year, we’ll be adding even more protections to this mode, including tailored warnings for phishing sites and file downloads and cross-product alerts. Building upon Safe Browsing Safe Browsing’s blocklist API is an existing security protocol that protects billions of devices worldwide. Every day, Safe Browsing discovers thousands of new unsafe sites and adds them to the blocklist API that is shared with the web industry. Chrome checks the URL of each site you visit or file you download against a local list, which is updated approximately every 30 minutes. Increasingly, some sophisticated phishing sites slip through that 30-minute refresh window by switching domains very quickly. This protocol is designed so that Google cannot determine the actual URL Chrome visited from this information, and thus by necessity the same verdict is returned regardless of the user’s situation. This means Chrome can’t adjust protection based on what kinds of threats a particular user is seeing or the type of sites they normally visit. So while the Safe Browsing blocklist API remains very powerful and will continue to protect users, we’ve been looking for ways to provide more proactive and tailored protections. How Enhanced Safe Browsing works When you switch to Enhanced Safe Browsing, Chrome will share additional security data directly with Google Safe Browsing to enable more accurate threat assessments. For example, Chrome will check uncommon URLs in real time to detect whether the site you are about to visit may be a phishing site. Chrome will also send a small sample of pages and suspicious downloads to help discover new threats against you and other Chrome users. If you are signed in to Chrome, this data is temporarily linked to your Google Account. We do this so that when an attack is detected against your browser or account, Safe Browsing can tailor its protections to your situation. In this way, we can provide the most precise protection without unnecessary warnings. After a short period, Safe Browsing anonymizes this data so it is no longer connected to your account. You can opt in to this mode by visiting Privacy and Security settings > Security > and selecting the “Enhanced protection” mode under Safe Browsing. It will be rolled out gradually in M83 on desktop platforms, with Android support coming in a future release. Enterprise administrators can control this setting via the SafeBrowsingProtectionLevel policy. Tailored protections Chrome’s billions of users are incredibly diverse, with a full spectrum of needs and perspectives in security and privacy. We will continue to invest in both Standard and Enhanced Safe Browsing with the goal to expand Chrome’s security offerings to cover all users.

Introducing portability of Google Authenticator 2SV codes across Android devices

May 7, 2020

Posted by Dongjing He, Software Engineer; Teddy Katz, Software Engineer; Christiaan Brand, Product Manager
2-Step Verification

Transferring accounts from one device to another with Google Authenticator

Using 2SV, 2-Factor Authentication (2FA) or Multi-Factor Authentication (MFA) is critical to protecting your accounts from unauthorized access. With these mechanisms, users verify their identity through their password and an additional proof of identity, such as a security key or a passcode.

Google Authenticator makes it easy to use 2SV on accounts. In addition to supplying only a password when logging in, a user also enters a code generated by the Google Authenticator app on their phone. This is a safer alternative, used by millions of users, compared to passcodes via text message.

Users place their trust in Google Authenticator to keep their accounts safe. As a result, security is always a high priority. We made several explicit design decisions to minimize the attack surface while increasing the overall usability of the app.

We ensured that no data is sent to Google’s servers during the transfer -- communication is directly between your two devices. Your 2SV secrets can’t be accessed without having physical access to your phone and the ability to unlock it.
We implemented a variety of alerting mechanisms and in-app logs to make sure users are aware when the transfer function has been used.

You can find more information about the Google Authenticator and its usage guide here.

Research Grants to support Google VRP Bug Hunters during COVID-19

April 20, 2020

Posted by Anna Hupa, Senior Strategist, Trust & Safety at GoogleVulnerability Research GrantVulnerability Research GrantVulnerability Reward Program (VRP) rulesVulnerability Research Grant@GoogleVRP

Introducing our new book “Building Secure and Reliable Systems”

April 8, 2020

Posted by Royal Hansen, VP of Security Engineering, Google

Site Reliability Engineers (SREs) and security engineers tend to break and fix, as well as build.

Their work encompasses operations, in addition to development.

SREs and security engineers are specialists, rather than classic software engineers.

They are often viewed as roadblocks, rather than enablers.

They are frequently siloed, rather than integrated in product teams.

The new book can be downloaded for free from the Google SRE website, or purchased as a physical copy from your preferred retailer.

Announcing our first GCP VRP Prize winner and updates to 2020 program

March 11, 2020

Posted by Harshvardan Sharma, Information Security Engineer, Googleannouncedherevideo

1st prize: $133,337

2nd prize: $73,331

3rd prize: $73,331

4th prize: $31,337

5th prize: $1,001

6th prize: $1,000

Like last year, submissions should have public write-ups in order to be eligible for the prize. The number of vulnerability reports in a single write-up is not a factor. You can even make multiple submissions, one for each write-up. These prizes are only for vulnerabilities found in GCP products. If you have budget constraints regarding access to testing environments, you can use the free tier of GCP. Note that this prize is not a replacement of our Vulnerability Reward Program (VRP), and that we will continue to pay security researchers under the VRP for disclosing security issues that affect Google services, including GCP. Complete details, terms and conditions about the prize can be found here.

Thank you to everyone who submitted entries in 2019! Make sure to nominate your VRP reports and write-ups for the 2020 GCP VRP prize here before December 31, 2020 at 11:59 GMT.

How Google Play Protect kept users safe in 2019

March 10, 2020

Posted by Rahul Mishra, Program Manager, Android Security and Privacy Team

malware and other harmful appsAdvanced similarity detectionon the deviceWarnings for apps targeting lower Android versionsAndroid OS

Uploading rare apps for scanning

Integration with Google’s Files appGoogle’s Files app

Play Protect visual updates visual redesign

developers.google.com/android/play-protectAaron Josephs, Ben Gruver, James Kelly, Rodrigo Farell, Wei Jin and William Luh

How Google does certificate lifecycle management

March 10, 2020

Posted by Siddharth Bhai and Ryan Hurst, Product Managers, Google Cloud
Google Transparency Report

Percentage of pages loaded over HTTPS in Chrome by platform (Google Transparency Report)CA/Browser ForumACME
As we round off this exciting tour of recent TLS history, we’d be remiss if we didn’t mention Let’s Encrypt - the first publicly trusted non-profit CA. Their focus on automation and TLS by default has been foundational to this massive increase in TLS usage. In fact, Let’s Encrypt just issued their billionth (!) certificate. Google has been an active supporter of Let’s Encrypt because we believe the work they do to make TLS accessible is important for the security and resilience of the Internet's infrastructure. Keep rocking, Let’s Encrypt!
Simplifying certificate lifecycle management for Google’s users

With the adoption numbers cited above, it’s clear that TLS, Web PKI, and certificate lifecycle management are foundational to every product we and our customers build and deploy. This is why we have been expanding significant effort to enable TLS by default for our products and services, while also automating certificate renewals to make certificate lifecycle management more reliable, globally scalable, and trustworthy for our customers. Our goal is simple: We want to ensure TLS just works out of the box regardless of which Google service you use.
In support of that goal, we have enabled automatic management of TLS certificates for Google services using an internal-only ACME service, Google Trust Services. This applies to our own products and services, as well as for our customers across Alphabet and Google Cloud. As a result, our users no longer need to worry about things like certificate expiration, because we automatically refresh the certificates for our customers. Some implementation highlights include:

All Blogger blogs, Google Sites, and Google My Business sites now get HTTPS by default for their custom domains.

Google Cloud customers get the benefits of Managed TLS on their domains. So:

Developers building with Firebase, Cloud Run, and AppEngine automatically get HTTPS for their applications.
When deploying applications with Google Kubernetes Engine or behind Google Cloud Load Balancing (GCLB), certificate management is taken care of if customers choose to use Google-managed certificates. This also makes TLS use with these products easy and reliable.

creation of a CAA record
While everyone appreciates TLS working out of the box, we also know power users have specialized needs. This is why we have provided rich capabilities in Google Cloud Load Balancing to let customers control policies around TLS termination.

In addition, through our work on Certificate Transparency in collaboration with other organizations, we have made it easier for our customers to protect their and their customers’ brands by monitoring the WebPKI ecosystem for certificates issued for their domains or those that look similar to their domains, so they can take proactive measures to stop any abuse before it becomes an issue. For example, Facebook used Certificate Transparency Logs to catch a number of phishing websites that tried to impersonate their services.

We recognize how important security, privacy, and reliability are to you and have been investing across our product portfolio to ensure that when it comes to TLS, you have the tools you need to deploy with confidence. Going forward, we look forward to a continued partnership to make the Internet a safer place together.

FuzzBench: Fuzzer Benchmarking as a Service

March 2, 2020

Posted by Jonathan Metzman, Abhishek Arya, Google OSS-Fuzz Team and László Szekeres‎, Google Software Analysis TeamFuzzBenchFuzzing12often have shortcomingsexampleOSS-Fuzz projectsten fuzzershereHow to ParticipateFuzzBench repo

Helping Developers with Permission Requests

February 27, 2020

Posted by Sai Teja Peddinti, Nina Taft and Igor Bilogrevic from PDPO Applied Privacy Research, and Pauline Anthonysamy from Android Security and Privacy.12Reducing Permissions Requests in Mobile Apps3

3Project Strobeour guidelines on permissions best practicesour requirements around safe traffic handlingAcknowledgementsGiles Hogben, Android Play Dashboard and Pre-Launch Report teams References[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of Usenix Symposium on Privacy & Security (SOUPS) 2014.[2] Using Personal Examples to Improve Risk Communication for Security & Privacy Decisions, by M. Harbach, M. Hettig, S. Weber, and M. Smith. In Proceedings of the SIGCHI Conference on Human Computing Factors in Computing Systems, 2014.[3] Reducing Permission Requests in Mobile Apps, by S. T. Peddinti, I. Bilogrevic, N. Taft, M Pelikan, U. Erlingsson, P. Anthonysamy and G. Hogben. In Proceedings of ACM Internet Measurement Conference (IMC) 2019.

Security Blog