Posted by Eduardo Vela, Vulnerability Collector, Google 

At Google, we’ve always believed in the benefits and importance of using open source technologies to innovate. We enjoy being a part of the community and we want to give back in new ways. As part of this effort, we are excited to announce an expansion of our Google Vulnerability Rewards Program (VRP) to cover all the critical open-source dependencies of Google Kubernetes Engine (GKE). We have designed this expansion with the goal of incentivizing the security community to work even more closely with open source projects, supporting the maintainers whose work we all rely on.

The CNCF, in partnership with Google, recently announced a bug bounty program for Kubernetes that pays up to $10,000 for vulnerabilities discovered within the project. And today, in addition to that, we are expanding the scope of the Google VRP program to also include privilege escalation bugs in a hardened GKE lab cluster we've set up for this purpose. This will cover exploitable vulnerabilities in all dependencies that can lead to a node compromise, such as privilege escalation bugs in the Linux kernel, as well as in the underlying hardware or other components of our infrastructure that could allow for privilege escalation inside a GKE cluster.

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.

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.

Posted by Dongjing He, Software Engineer; Teddy Katz, Software Engineer; Christiaan Brand, Product Manager

Today is World Password Day, and we found it fitting to release an update that'll make it even easier for users to manage Google Authenticator 2-Step Verification (2SV) codes across multiple devices. We are introducing one of the most anticipated features - allowing users to transfer their 2SV secrets, the data used to generate 2SV codes across devices that have Google Authenticator installed. For instance, when upgrading from an old phone to a new phone. This feature has started rolling out and is available in the latest version (5.10) of Google Authenticator on Android.

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.