Google Online Security Blog: 10月 2018

Announcing some security treats to protect you from attackers’ tricks

2018年10月31日

Posted by Jonathan Skelker, Product ManagerProtecting you before you even sign in Chances are, JavaScript is already enabled in your browser; it helps power lots of the websites people use everyday. But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users (0.1%) choose to keep it off. This might make sense if you are reading static content, but we recommend that you keep Javascript on while signing into your Google Account so we can better protect you. You can read more about how to enable JavaScript here.

Keeping your Google Account secure while you’re signed in
Last year, we launched a major update to the Security Checkup that upgraded it from the same checklist for everyone, to a smarter tool that automatically provides personalized guidance for improving the security of your Google Account.
We’re adding to this advice all the time. Most recently, we introduced better protection against harmful apps based on recommendations from Google Play Protect, as well as the ability to remove your account from any devices you no longer use.

More notifications when you share your account data with apps and sites
It’s really important that you understand the information that has been shared with apps or sites so that we can keep you safe. We already notify you when you’ve granted access to sensitive information — like Gmail data or your Google Contacts — to third-party sites or apps, and in the next few weeks, we’ll expand this to notify you whenever you share any data from your Google Account. You can always see which apps have access to your data in the Security Checkup.

Helping you get back to the beginning if you run into trouble
In the rare event that your account is compromised, our priority is to help get you back to safety as quickly as possible. We’ve introduced a new, step-by-step process within your Google Account that we will automatically trigger if we detect potential unauthorized activity.
We'll help you:

Verify critical security settings to help ensure your account isn’t vulnerable to additional attacks and that someone can’t access it via other means, like a recovery phone number or email address.

Secure your other accounts because your Google Account might be a gateway to accounts on other services and a hijacking can leave those vulnerable as well.

Check financial activity to see if any payment methods connected to your account, like a credit card or Google Pay, were abused.

Review content and files to see if any of your Gmail or Drive data was accessed or mis-used.

Online security can sometimes feel like walking through a haunted house—scary, and you aren't quite sure what may pop up. We are constantly working to strengthen our automatic protections to stop attackers and keep you safe you from the many tricks you may encounter. During Cybersecurity Month, and beyond, we've got your back.

Introducing reCAPTCHA v3: the new way to stop bots

2018年10月29日

Posted by Wei Liu, Google Product Manager[Cross-posted from the Google Webmaster Central Blog]reCAPTCHA v3A frictionless user experience
More Accurate Bot Detection with "Actions"

Fighting bots your waydeveloper site

Google tackles new ad fraud scheme

2018年10月23日

Posted by Per Bjorke, Product Manager, Ad Traffic QualityTechnical DetailTechSnabChrome Cleanup

Android Protected Confirmation: Taking transaction security to the next level

2018年10月19日

Posted by Janis Danisevskis, Information Security Engineer, Android Security[Cross-posted from the Android Developers Blog]

Transaction Authentication NumberAndroidKeyStoreKeystore AttestationWhat's new in Android security
DTMoStDTMoStAndroid Protected Confirmation training article

Building a Titan: Better security through a tiny chip

2018年10月17日

Posted by Nagendra Modadugu and Bill Richardson, Google Device Security Group[Cross-posted from the Android Developers Blog]Made by GoogleKeyword BlogTitan familypost

Storing and enforcing the locks and rollback counters used by Android Verified Boot.

Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.

Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel's side buttons, so a remote attacker can't fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.

Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.

Ensuring that even Google can't unlock a phone or install firmware updates without the owner's cooperation with Insider Attack Resistance.

RowhammerSpectreMeltdownside channel attacksA closer look at Titan M

Titan (left) and Titan M (right)

Better security through transparency and innovation

Modernizing Transport Security

2018年10月15日

Posted by David Benjamin, Chrome networking*Updated on October 17, 2018 with details about changes in other browsersTLS 1.0TLS 1.2now brokenPCI-DSS compliantdocumentAppleMicrosoftMozilla

TLS 1.2 or later.

An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are those using AES-GCM or ChaCha20-Poly1305. ECDHE_RSA_WITH_AES_128_GCM_SHA256 is the recommended option for most sites.

The server signature should use SHA-2. Note this is not the signature in the certificate, made by the CA. Rather, it is the signature made by the server itself, using its private key.

The older options—CBC-mode cipher suites, RSA-encryption key exchange, and SHA-1 online signatures—all have known cryptographic flaws. Each has been removed in the newly-published TLS 1.3, which is supported in Chrome 70. We retain them at prior versions for compatibility with legacy servers, but we will be evaluating them over time for eventual deprecation.

None of these changes require obtaining a new certificate. Additionally, they are backwards-compatible. Where necessary, servers may enable both modern and legacy options, to continue to support legacy clients. Note, however, such support may carry security risks. (For example, see the DROWN, FREAK, and ROBOT attacks.)

Over the coming Chrome releases, we will improve the DevTools Security Panel to point out deviations from these settings, and suggest improvements to the site’s configuration.

Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 until January 2021.

Google and Android have your back by protecting your backups

2018年10月12日

Posted by Troy Kensinger, Technical Program Manager, Android Security and PrivacyAndroid’s Backup ServiceGoogle Cloud’s Titan TechnologyTitan security chipNCC Group’shereWe want to acknowledge contributions from Shabsi Walfish, Software Engineering Lead, Identity and Authentication to this effort

Control Flow Integrity in the Android kernel

2018年10月10日

Posted by Sami Tolvanen, Staff Software Engineer, Android Security & Privacy[Cross-posted from the Android Developers Blog]hardening the kernelcompiler-based security mitigationsControl Flow Integrity (CFI)CFI support available in Android kernel versions 4.9 and 4.14 Protecting against code reuse attacks

Figure 1. In an Android device kernel, LLVM's CFI limits 55% of indirect calls to at most 5 possible targets and 80% to at most 20 targets. Gaining full program visibility with Link Time Optimization (LTO)

Figure 2. A simplified overview of how LTO works in the kernel. All LLVM bitcode is combined, optimized, and generated into native code at link time.4.94.14LDFLAGS += -plugin-opt=-inline-threshold=0 \ -plugin-opt=-unroll-threshold=0 Implementing CFI in the Linux kernelLLVM's CFI4.94.14cross-DSO CFI

Figure 3. An example of a cross-DSO CFI check injected into an arm64 kernel. Type information is passed in X0 and the target address to validate in X1. Enabling kernel CFI for an Android deviceclangbinutilsCONFIG_LTO_CLANG=y CONFIG_CFI_CLANG=yCFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80): ------------[ cut here ]------------ kernel BUG at kernel/cfi.c:32! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP … Call trace: … [<ffffff8752d00084>] handle_cfi_failure+0x20/0x28 [<ffffff8752d00268>] my_buggy_function+0x0/0x10 … Figure 4. An example of a kernel panic caused by a CFI failure.static int __nocfi address_space_conflict() { void (*fn)(void); … /* branching to a physical address trips CFI w/o __nocfi */ fn = (void *)__pa_symbol(function_name); cpu_install_idmap(); fn(); cpu_uninstall_idmap(); … } Figure 5. An example of fixing a CFI failure caused by an address space conflict.KASAN ConclusionShadow Call Stack

Trustworthy Chrome Extensions, by Default

2018年10月1日

Posted by James Wagner, Chrome Extensions Product Manager[Cross-posted from the Chromium blog]Chrome Web Storeout-of-process iframesremoval of inline installationUser controls for host permissionshost access

transition guideChanges to the extensions review process
narrowly-scopedNew code reliability requirements

Removal of whitespace, newlines, code comments, and block delimiters

Shortening of variable and function names

Collapsing the number of JavaScript files

If you have an extension in the store with obfuscated code, please review our updated content policies as well as our recommended minification techniques for Google Developers, and submit a new compliant version before January 1st, 2019.

Required 2-step verification
In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.
For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.

Looking ahead: Manifest v3
In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.
Some key goals of manifest v3 include:

More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
Additional, easier mechanisms for users to control the permissions granted to extensions
Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.
We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.

Security Blog