Google Online Security Blog: 2018

Android Pie à la mode: Security & Privacy

20. Dezember 2018

[Cross-posted from the Android Developers Blog]

Platform hardeningFile-Based Encryptionmetadata encryptionBiometricPrompt APIApplication SandboxSELinuxAnti-exploitation improvementscompiler-based security mitigationsControl Flow Integrity (CFI)CFI in the Android common kernelInteger Overflow SanitizationContinued investment in hardware-backed securityAndroid Protected ConfirmationStrongBox Keymasterblog postrelease notesEnhancing user privacybehavior changesMAC address randomizationan attacker would not be able to access a user's backed-up application dataTLS by defaultDNS over TLSincreasing exploit difficultyindependent mobile security ratingsAcknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

New Keystore features keep your slice of Android Pie a little safer

12. Dezember 2018

Posted by Lilian Young and Shawn Willden, Android Security; and Frank Salim, Google Pay
[Cross-posted from the Android Developers Blog]

New Android Pie Keystore FeaturesKeystore Keyguard-bound keyssetUnlockedDeviceRequired(true)KeyGenParameterSpecKeyProtection Secure Key ImportSecureKeyWrapper

this training articlePURPOSE_WRAP_KEY

Tackling ads abuse in apps and SDKs

7. Dezember 2018

Posted by Dave Kleidermacher, VP, Head of Security & Privacy - Android & Playconstantly workingGoogle Play Install Referrer APIGoogle Play Developer policies

On Monday, we removed two apps from the Play Store because our investigation discovered evidence of app install attribution abuse.

We also discovered evidence of app install attribution abuse in 3 ad network SDKs. We have asked the impacted developers to remove those SDKs from their apps. Because we believe most of these developers were not aware of the behavior from these third-party SDKs, we have given them a short grace period to take action.

Google Ads SDKs were not utilized for any of the abusive behaviors mentioned above.

Our investigation is ongoing and additional reviews of other apps and third party SDKs are still underway. If we find evidence of additional policy violations, we will take action.

We will continue to investigate and improve our capabilities to better detect and protect against abusive behavior and the malicious actors behind them.

ASPIRE to keep protecting billions of Android users

5. Dezember 2018

Posted by Billy Lau and René Mayrhofer, Android Security & Privacy TeamAndroid Security and Privacy teamASPIRE

Submit an Android security / privacy research idea or proposal to the Google Faculty Research Awards (FRA) program.

Apply for a research internship as a student pursuing an advanced degree.

Apply to become a Visiting Researcher at Google.

If you have any security or privacy questions that may help with your research, reach out to us.

Co-author publications with Android team members, outside the terms of FRA.

Collaborate with Android team members to make changes to the Android Open Source Project.

Announcing the Google Security and Privacy Research Awards

29. November 2018

Posted by Elie Bursztein and Oxana Comanescu, Google Security and Privacy Groupfaculty research grantscloud creditsworking with visiting scholarsresearch interns2017 AwardeesLujo BauerResearch area: Password security and attacks against facial recognitionDan BonehResearch area: Enclave security and post-quantum cryptographyAleksandra KorolovaResearch area: Differential privacyDaniela OliveiraResearch area: Social engineering and phishingFranziska RoesnerResearch area: Usable security for augmented reality and at-risk populationsMatthew SmithResearch area: Usable security for developers

2016 AwardeesMichael BaileyResearch area: Cloud and network securityNicolas ChristinResearch area: Authentication and cybercrimeDamon McCoyResearch area: DDoS services and cybercrimeStefan SavageResearch area: Network security and cybercrimeMarc StevensResearch area: Cryptanalysis and lattice cryptographyGiovanni VignaResearch area: Malware detection and cybercrime

Industry collaboration leads to takedown of the “3ve” ad fraud operation

27. November 2018

Posted by Per Bjorke, Product Manager, Ad Traffic QualityWhite Opsannouncedhere
All about 3ve: A creative and sophisticated threat
Through our investigation, we discovered that 3ve was comprised of three unique sub-operations that evolved rapidly, using sophisticated tactics aimed at exploiting data centers, computers infected with malware, spoofed fraudulent domains, and fake websites. Through its varied and complex machinery, 3ve generated billions of fraudulent ad bid requests (i.e., ad spaces on web pages that advertisers can bid to purchase in an automated way), and it also created thousands of spoofed fraudulent domains. It should be noted that our analysis of ad bid requests indicated growth in activity, but not necessarily growth in transactions that would result in charges to advertisers. It’s also worth noting that 3+ billion daily ad bid requests made 3ve an extremely large ad fraud operation, but its bid request volume was only a small percentage of overall bid request volume across the industry.

Our objective
3ve’s focus, like many ad fraud schemes, was not a single player or system, but rather the whole advertising ecosystem. As we worked to protect our ad systems against traffic from this threat, we identified that others also had observed this traffic, and we partnered with them to help remove the threat from the ecosystem. The working group, which included nearly 20 partners, was a key component that shaped our broader investigation into 3ve, enabling us to engage directly with each other and to work towards a mutually beneficial outcome.

Industry collaboration helps bring 3ve down
While ad fraud traditionally has been seen as a faceless crime in which bad actors don’t face much risk of being identified or consequences for their actions, 3ve’s takedown demonstrates that there are risks and consequences to committing ad fraud. We’re confident that our collective efforts are building momentum and moving us closer to finding a resolution to this challenge.
For example, industry initiatives such as the Interactive Advertising Bureau (IAB) Tech Lab’s ads.txt standard, which has experienced and continues to see very rapid adoption (over 620,000 domains have an ads.txt), as well as the increasing number of buy-side platforms and exchanges offering refunds for invalid traffic, are valuable steps towards cutting off the money flow to fraudsters. As we announced last year, we’ve made, and will continue to make investments in our automated refunds for invalid traffic, including our work with supply partners to provide advertisers with refunds for invalid traffic detected up to 30 days after monthly billing.
Industry bodies such as the IAB, Trustworthy Accountability Group (TAG), Media Rating Council, and the Joint Industry Committee for Web Standards, who are serving as agents of change and collaboration across our industry, are instrumental in the fight against ad fraud. We have a long history of working with these bodies, including ongoing participation in TAG and IAB leadership and working groups, as well as our inclusion in the TAG Certified Against Fraud program. That program’s value was reinforced with the IAB’s requirement that all members need to be TAG certified by the middle of this year.

Successful disruption
A coordinated takedown of infrastructure related to 3ve’s operations occurred recently. The takedown involved disrupting as much of the related infrastructure as possible to make it hard to rebuild any of 3ve’s operations. As the graph below demonstrates, declining volumes in invalid traffic indicate that the disruption thus far has been successful, bringing the bid request traffic close to zero within 18 hours of starting the coordinated takedown.

Looking ahead
We’ll continue to be vigilant, working to protect marketers, publishers, and users, while continuing to collaborate with the broader industry to safeguard the integrity of the digital advertising ecosystem that powers the open web. Our work to take down 3ve is another example of our collaboration with the broader ecosystem to improve trust in digital advertising. We are committed to helping to create a better digital advertising ecosystem — one that is more valuable, transparent, and trusted for everyone.

Combating Potentially Harmful Applications with Machine Learning at Google: Datasets and Models

15. November 2018

Posted by Mo Yu, Damien Octeau, and Chuangang Ren, Android Security & Privacy Team[Cross-posted from the Android Developers Blog]previous blog postPotentially Harmful Applications (PHAs)

Using Machine Learning to Scale
PHA behaviorGoogle Play ProtectData Sources
embeddingfeature selectionfeature engineeringModels

Looking forward
successfully detected 60.3% of PHAs identified by Google Play Protect

Acknowledgements

Introducing the Android Ecosystem Security Transparency Report

8. November 2018

Posted by Jason Woloz and Eugene Liderman, Android Security & Privacy TeamUpdate: We identified a bug that affected how we calculated data from Q3 2018 in the Transparency Report. This bug created inconsistencies between the data in the report and this blog post. The data points in this blog post have been corrected.What's new in Android securityannual Android Security Year in ReviewAndroid Ecosystem Security Transparency ReportTransparency ReportGoogle Play ProtectPotentially Harmful ApplicationsDevices with Potentially Harmful Applications installed by market segment
2017 Year in ReviewDevices with Potentially Harmful Applications installed by Android version
Devices with Potentially Harmful Applications rate by top 10 countries
Year in ReviewDevices with Potentially Harmful Applications rate by top 10 countriesCheck out the report
Android Ecosystem Security Transparency ReportFAQs section of the Transparency Reportblog postvideo

A New Chapter for OSS-Fuzz

6. November 2018

Posted by Matt Ruhstaller, TPM and Oliver Chang, Software Engineer, Google Security TeamOSS-FuzzGoogle Cloud Platformlaunching9,000manually reportedresolvedPatch Rewards Programideal integrationherereviewOur goal is to admit as many OSS projects as possible and ensure that they are continuously fuzzed.
fuzz target

Announcing some security treats to protect you from attackers’ tricks

31. Oktober 2018

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

29. Oktober 2018

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

23. Oktober 2018

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

Android Protected Confirmation: Taking transaction security to the next level

19. Oktober 2018

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

17. Oktober 2018

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 attacks A closer look at Titan M

Titan (left) and Titan M (right)

Better security through transparency and innovation

Modernizing Transport Security

15. Oktober 2018

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

12. Oktober 2018

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

10. Oktober 2018

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

Security Blog