Google Online Security Blog

How we fought bad apps and malicious developers in 2018

February 13, 2019

Posted by Andrew Ahn, Product Manager, Google Play[Cross-posted from the Android Developers Blog]

Google Play Protect

Protecting User Privacyannounced

Developer integrity

Harmful app contents and behaviorsblog postPotentially Harmful Applications How useful did you find this blog post?
★ ★ ★ ★ ★

Open sourcing ClusterFuzz

February 7, 2019

Posted by Abhishek Arya, Oliver Chang, Max Moroz, Martin Barbella and Jonathan Metzman (ClusterFuzz team)[Cross-posted from the Google Open-Source Blog]Fuzzingmemory corruption bugsserioussecurityimplicationsunsafeprovide these featuresOSS-FuzzClusterFuzz

bisection16,00011,000160bugsGitHub repositoryinstructionsproductionGoogle Cloud Platform

Introducing Adiantum: Encryption for the Next Billion Users

February 7, 2019

Posted by Paul Crowley and Eric Biggers, Android Security & Privacy Team

allAndroid Gosmart watchesTVsrequiredChaCha20 stream cipherin 2014 Google selected ChaCha20Poly1305 authenticatorRFC7539noncemessage integrityAdiantumHCTRHCH

Additional resourcesAdiantum: length-preserving encryption for entry-level processorsAndroid common kernels v4.9 and highermainline Linux kernel v5.0 and higherhttps://github.com/google/adiantumenable AdiantumAndroid Compatibility Definition DocumentAcknowledgements: This post leveraged contributions from Greg Kaiser and Luke Haviland. Adiantum was designed by Paul Crowley and Eric Biggers, implemented in Android by Eric Biggers and Greg Kaiser, and named by Danielle Roberts.

Protect your accounts from data breaches with Password Checkup

February 5, 2019

Posted by Jennifer Pullman, Kurt Thomas, and Elie Bursztein, Security and Anti-abuse researchUpdate (Feb 6)prevention, detection, and mitigationthird-party data breachesten times the riskPassword Checkup Chrome extension

Key design principles

Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.

Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.

Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.

Settling on an approach
At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, and private set intersection with blinding.
Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.
A look under the hood
Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.

Protecting your accounts
Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.
Acknowledgements
This post reflects the work of a large group of Google engineers, research scientists, and others including: Niti Arora, Jacob Barrett, Borbala Benko, Alan Butler, Abhi Chaudhuri, Oxana Comanescu, Sunny Consolvo, Michael Dedrick, Kyler Emig, Mihaela Ion, Ilona Gaweda, Luca Invernizzi, Jozef Janovský, Yu Jiang, Patrick Gage Kelly, Nirdhar Khazanie, Guemmy Kim, Ben Kreuter, Valentina Lapteva, Maija Marincenko, Grzegorz Milka, Angelika Moscicki, Julia Nalven, Yuan Niu, Sarvar Patel, Tadek Pietraszek, Ganbayar Puntsagdash, Ananth Raghunathan, Juri Ranieri, Mark Risher, Masaru Sato, Karn Seth, Juho Snellman, Eduardo Tejada, Tu Tsao, Andy Wen, Kevin Yeo, Moti Yung, and Ali Zand.

PHA Family Highlights: Zen and its cousins

January 11, 2019

table, th, td { border: 1px solid black; Posted by Lukasz Siewierski, Android Security & Privacy TeamGoogle Play ProtectPotentially Harmful Applicationsmachine learningZen Background Apps with a custom-made advertisement SDK

Click fraud apps{ "data": [{ "id": "107", "url": "<ayud_url>", "click_type": "2", "keywords_js": [{ "keyword": "<a class=\"show_hide btnnext\"", "js": "javascript:window:document.getElementsByClassName(\"show_hide btnnext\")[0].click();", { "keyword": "value=\"Subscribe\" id=\"sub-click\"", "js": "javascript:window:document.getElementById(\"sub-click\").click();"show_hide btnnextclick() Rooting trojansVerified Bootstatistics() The Zen trojanenabled_accessibility_servicesif (!title.containsKey("Enter the code")) { if (!title.containsKey("Basic information")) { if (!title.containsKey(new String(android.util.Base64.decode("SG93IHlvdeKAmWxsIHNpZ24gaW4=".getBytes(), 0)))) { if (!title.containsKey("Create password")) { if (!title.containsKey("Add phone number")) {

system_serversystem_serverLmt_INJECTSELinux protection

The source process checks the mapping between a process id and a process name. This is done by reading the /proc/[pid]/cmdline file.
This very first step fails in Android 7.0 and higher, even with a root permission. The /proc filesystem is now mounted with a hidepid=2 parameter, which means that the process cannot access other process /proc/[pid] directory.

A ptrace_attach syscall is called. This allows the source process to trace the target.

The source process looks at its own memory to calculate the offset between the beginning of the libc library and the mmap address.

The source process reads /proc/[pid]/maps to find where libc is located in the target process memory. By adding the previously calculated offset, it can get the address of the mmap function in the target process memory.

The source process tries to determine the location of dlopen, dlsym, and dlclose functions in the target process. It uses the same technique as it used to determine the offset to the mmap function.

The source process writes the native shellcode into the memory region allocated by mmap. Additionally, it also writes addresses of dlopen, dlsym, and dlclose into the same region, so that they can be used by the shellcode. Shellcode simply uses dlopen to open a .so file within the target process and then dlsym to find a symbol in that file and run it.

The source process changes the registers in the target process so that PC register points directly to the shellcode. This is done using the ptrace syscall.

Summary

Open your Android device's Google Play Store app.

Tap Menu>Play Protect.

Look for information about the status of your device.

Hashes of samples

Type

Package name

SHA256 digest

Custom ads

com.targetshoot.zombieapocalypse.sniper.zombieshootinggame

5d98d8a7a012a858f0fa4cf8d2ed3d5a82937b1a98ea2703d440307c63c6c928

Click fraud

com.counterterrorist.cs.elite.combat.shootinggame

84672fb2f228ec749d3c3c1cb168a1c31f544970fd29136bea2a5b2cefac6d04

Rooting trojan

com.android.world.news

bd233c1f5c477b0cc15d7f84392dab3a7a598243efa3154304327ff4580ae213

Zen trojan

com.lmt.register

eb12cd65589cbc6f9d3563576c304273cb6a78072b0c20a155a0951370476d8d

Google Public DNS now supports DNS-over-TLS

January 9, 2019

Posted by Marshall Vale, Product Manager and Puneet Sood, Software Engineerover eight years agoDNS-over-TLS protocolTLSthe RFC 7766 recommendationsTLS 1.3Use DNS-over-TLS today
documentationstubbydnsprivacy.orgcreate an issue on our trackerdiscussion group

Android Pie à la mode: Security & Privacy

December 20, 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

December 12, 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

December 7, 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

December 5, 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.

Security Blog