Google Online Security Blog

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.

Announcing the Google Security and Privacy Research Awards

November 29, 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

November 27, 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

November 15, 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

November 8, 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

Security Blog

PHA Family Highlights: Zen and its cousins

Google Public DNS now supports DNS-over-TLS

Android Pie à la mode: Security & Privacy

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

Tackling ads abuse in apps and SDKs

ASPIRE to keep protecting billions of Android users

Announcing the Google Security and Privacy Research Awards

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

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

Introducing the Android Ecosystem Security Transparency Report

Labels

Archive

Feed

Company-wide

Products

Developers