Android provides multiple layers of protections and warnings to help protect users from installing mobile fraud apps.
This year’s updated Android Security Paper details the platform’s latest protections.
October is the time when ghosts do their best haunting. Yet there are other unwelcome guests who cause havoc year-round, trying to sneak into your company phone and make real-world mischief.
Malware and other threats are always on the mind of mobile security professionals, which is why the issue gets special attention every October for Cybersecurity Awareness Month. While malware is something to guard against for all smartphone users, enterprises must be especially mindful of protecting sensitive corporate data.
It’s why Android ships with strong protections enabled through Google security services, with anti-phishing features coming from Google Safe Browsing and anti-malware features like Google Play Protect continuously monitoring for malware and removing any if discovered. With so much work taking place on mobile devices, built-in security features are essential.
We are committed to providing transparency into our efforts to reduce Potentially Harmful Application (PHA) rates on devices and in Google Play. Recently, we specifically analyzed Android Enterprise devices to gauge how our enterprise devices fare when they use Google Security Services and Android Enterprise as their sole anti-malware solution. We were pleased to find only .003 percent of devices with any active PHAs. That’s less likely than being hit by a comet or asteroid in the United States!
We’ve been able to keep the PHA rate on enterprise devices very low by combining built-in malware defense with management APIs so admins have the controls they need to minimize threats to their device fleets.
Google Play Protect scans over 100 billion apps every day, finding PHAs in real-time, notifying users of potential threats and removing them if necessary. Google Play Protect also works even if the device is offline and users can always perform a manual scan.
With machine learning and human analysis, we work to prevent the spread and impact of malicious apps.
Android Enterprise admins further tighten controls with managed Google Play. By using blocklist and allowlist they can control exactly which apps are allowed on devices, closing another potential opening for malware.
Admins can take other proactive steps such as forcing devices to install operating system updates and disabling the ability to install applications from unknown sources. EMM partners can leverage our APIs to implement security compliance into their mobility offerings. The SafetyNet Verify Apps API, for example, taps into our malware intelligence to help detect if any malware resides on the device.
The integration of our security services and Android Enterprise management tools give our partners and customers the security they need for today’s threats. Last year we also introduced the App Defense Alliance where we partnered with industry leaders to stop bad apps before they reach users’ devices. We’re pleased to see such positive results from these efforts and tangible evidence of how Android Enterprise management paired with our security services help provide comprehensive device protection. Learn more about Android Enterprise security and how to take advantage of these essential security services.
The surge in remote and mobile working has put an increased emphasis on how organizations should best manage and secure device access to critical information. New research from Omdia, in a survey of 700 IT decision makers, found that businesses are expanding and strengthening access controls now that many employees spend very little or no time in the office.
This has piqued interest in the Zero Trust security model, which is built on the premise that access to corporate resources should continuously be verified. In the Omdia survey, 31 percent of the respondents are currently using a Zero Trust, with another 47 percent planning to do so in the near future.
The Zero Trust security model enables a mobile and remote workforce to securely connect to company resources from virtually anywhere. Devices are vetted before being granted access to company resources. Companies can use tight, granular controls to specify the level of access whether the devices are connected to a corporate network, from home, or elsewhere.
An effective Zero Trust implementation requires numerous device signals, context and controls to make intelligent decisions about access. A key piece of a Zero Trust architecture is the enforcement point, which is the identity or network component that grants or denies access based on the various device and user signals that are available. For example, the enforcement point may decline access to devices that do not have the most recent security patch or show signs of running a compromised operating system.
A Zero Trust diagram showing how various device and user signals are used as part of contextual rules that dictate the control.
Android has a wealth of platform features and APIs that our enterprise mobility management and security partners leverage to safeguard backend services and resources. Let’s look at how Android provides the building blocks you need for a Zero Trust deployment.
Android provides a variety of device signals that administrators can use in building systems to verify the security and integrity of devices. In a Zero Trust model, these signals are used to assess whether a device should be allowed to access corporate information.
The first thing that needs to be checked is the OS version and Security Patch Level of the device. The SafetyNet Attestation API verifies a device has not been rooted, while the SafetyNet VerifyApps API checks for the presence of malware. Admins can also confirm if applications are complying with Android security standards. The NetworkEvent and SecurityLog logs provide data to check for any suspicious activity or anomalies on devices.
The next aspect is context:
Who is trying to access a particular resource—are we sure that this is in fact the right device and person?
What resource are they trying to access—is this resource restricted to a select audience or region?
When are they trying to access it—is this during work hours or after hours?
Where are they trying to access it from—are they in their normal region or traveling?
How are they attempting to access it—are they accessing this from a web app or native app, is the device fully managed or BYOD?
Why do they need to access it—is this someone who typically accesses this information?
Now that we have device security signals and the context we can decide how to control the access to the information.
Here are some examples:
If a user is on a rooted device — no access.
If a user is traveling international — limited access.
If a user is trying to access a resource for the first time in a while — prompt for a second factor during the authentication flow.
The Android platform provides the signals and intelligence in order to understand the context and define appropriate controls in a Zero Trust deployment. What makes Android unique as a Zero Trust endpoint is that unlike other operating systems where you need to rely on the Enterprise Mobility Management (EMM) solution to gather the appropriate device signals and attributes, on Android access to these signals can be delegated so that which ever component is acting as the enforcement point; whether it be the identity provider or the network access control component, can collect all of the necessary information directly off the endpoint device as opposed to integrating with a multitude of backend systems.
If you are currently using Zero Trust or moving in that direction, make sure to confirm that your EMM or your enforcement point can access the plethora of signals directly from the device. And check out the Omdia security report to learn more about growing adoption of Zero Trust security.
REVOKED or SUSPENDED, where revoked is permanent and suspended is temporary. The reason for the status is described as either KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED, or SOFTWARE_FLAW. A complete, up-to-date list of statuses and reasons can be found in the developer documentation. As part of our continuous commitment to improve the security of the Android ecosystem, we are partnering with Arm to design the memory tagging extension (MTE). Memory safety bugs, common in C and C++, remain one of the largest vulnerabilities in the Android platform and although there have been previous hardening efforts, memory safety bugs comprised more than half of the high priority security bugs in Android 9. Additionally, memory safety bugs manifest as hard to diagnose reliability problems, including sporadic crashes or silent data corruption. This reduces user satisfaction and increases the cost of software development. Software testing tools, such as ASAN and HWASAN help, but their applicability on current hardware is limited due to noticeable overheads.
MTE, a hardware feature, aims to further mitigate these memory safety bugs by enabling us to detect them with low overhead. It has two execution modes:
Arm recently published a whitepaper on MTE and has added documentation to the Arm v8.5 Architecture Reference Manual.
We envision several different usage modes for MTE.
We believe that memory tagging will detect the most common classes of memory safety bugs in the wild, helping vendors identify and fix them, discouraging malicious actors from exploiting them. During the past year, our team has been working to ensure readiness of the Android platform and application software for MTE. We have deployed HWASAN, a software implementation of the memory tagging concept, to test our entire platform and a few select apps. This deployment has uncovered close to 100 memory safety bugs. The majority of these bugs were detected on HWASAN enabled phones in everyday use. MTE will greatly improve upon this in terms of overhead, ease of deployment, and scale. In parallel, we have been working on supporting MTE in the LLVM compiler toolchain and in the Linux kernel. The Android platform support for MTE will be complete by the time of silicon availability.
Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are considering MTE as a possible foundational requirement for certain tiers of Android devices.
Thank you to Mitch Phillips, Evgenii Stepanov, Vlad Tsyrklevich, Mark Brand, and Serban Constantinescu for their contributions to this post.
TL;DR We increased the Chrome Fuzzer Program bonus from $500 to $1,000 as part of our recent update of reward amounts.
Chrome Fuzzer Program is a part of the Google Chrome Vulnerability Reward Program that lets security researchers run their fuzzers at scale on the ClusterFuzz infrastructure. It makes bug reporting fully automated, and the fuzzer authors get the same rewards as if they reported the bugs manually, plus an extra bonus ($1,000 as of now) on top of it for every new vulnerability.
We run fuzzers indefinitely, and some of the fuzzers contributed years ago are still finding security issues in ever changing Chrome code. This is a win-win for both sides, as security researchers do not have to spend time analyzing the crashes, and Chrome developers receive high quality bug reports automatically.
To learn more about the Chrome Fuzzer Program, let’s talk to Ned Williamson, who’s been a participant since 2017 and now works on the Google Security team.
Q: Hey Ned! It looks like you’ve received over $50,000 by participating in the Google Chrome Vulnerability Reward Program with your quic_stream_factory_fuzzer.
A: Yes, it’s true. I wrote a fuzzer for QUIC which helped me find and report two critical vulnerabilities, each worth $10,000. Because I knew my fuzzer worked well, I submitted it to the Chrome Fuzzer Program. Then, in the next few months, I received that reward three more times (plus a bonus), as the fuzzer caught several security regressions on ClusterFuzz soon after they happened.
Q: Have you intentionally focused on the areas that yield higher severity issues and bigger rewards?
A: Yes. While vulnerabilities in code that is more critical to user security yield larger reward amounts, I actually started by looking at lower severity bugs and incrementally began looking for more severe bugs until I could find critical ones. You can see this progression by looking at the bugs I reported manually as an external researcher.
Q: Would you suggest starting by looking for non-critical bugs?
A: I would say so. Security-critical code is generally better designed and more thoroughly audited, so it might be discouraging to start from there. Finding less critical security bugs and winning bounties is a good way to build confidence and stay motivated.
Q: Can you share an algorithm on how to find security bugs in Chrome?
A: Looking at previous and existing bug reports, even for non-security crashes, is a great way to tell which code is security-critical and potentially buggy. From there, if some code looks like it’s exposed to user inputs, I’d set up a fuzzing campaign against that component. After you gain experience you will not need to rely on existing reports to find new attack surface, which in turn helps you find places that have not been considered by previous researchers. This was the case for my QUIC fuzzer.
Q: How did you learn to write fuzzers?
A: I didn’t have any special knowledge about fuzzing before I started looking for vulnerabilities in Chrome. I followed the documentation in the repository and I still follow the same process today.
Q: Your fuzzer isn’t very simple compared to many other fuzzers. How did you get to that implementation?
A: The key insight in the QUIC fuzzer was realizing that the parts of the code that handled plaintext messages after decryption were prone to memory corruption. Typically, fuzzing does not perform well with encrypted inputs (it’s pretty hard to “randomly” generate a packet that can be successfully decrypted), so I extended the QUIC testing code to allow for testing with encryption disabled.
Q: Are there any other good examples of fuzz targets employing a similar logic?
A: Another example is pdf_formcalc_context_fuzzer that wraps the fuzzing input around with a valid hardcoded PDF file, therefore focusing fuzzing only on the XFA script part of it. As a researcher, you just need to choose what exactly you want to fuzz, and then understand how to execute that code properly. Looking at the unit tests is usually the easiest way to get such an understanding.
Useful links:
Happy fuzzing and bug hunting!
od2gf04pd9 and ac32dorbdq. This is illustrated in the IDA screenshot below. Depending on which one was provided, the binary either 1) ran the command given as an argument as root or 2) concatenated all of the arguments, ran that concatenation preceded by sh, then ran them as root. Either way, the app had to know the correct password to run the command as root. 
com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast), and Oupeng (com.oupeng.browser). The code was injected using the same technique described in our blog post about the Zen PHA family and in previously mentioned Kaspersky blog posts. 09 00 00 50 4B 01 02 14 00 14 00 08 00 08 00 4F ...PK..........OThe underlying data protocol changed periodically. It was either a simple JSON, a list of key-value pairs similar to the properties file, or a proprietary format as shown below.
91 F3 48 AE CF 91 D5 B1 04 00 00 52 09 00 00 04 ..H........R....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 32 33 38 36 50 4B 05 06 00 00 00 00 01 00 01 .2386PK.........
00 32 00 00 00 E3 04 00 00 00 00 .2.........
[collect_Head]device=Nexus 5XWhen Triada was discovered, we implemented detection that removed Triada samples from all devices with Google Play Protect. This implementation, combined with the increased security on newer Android devices, made it significantly harder for Triada to infect devices.
[collect_Space]xadevicekey=xxxxx
…
[collect_Space]collentmod=opappresultmode
[collect_Space]registerUser=true
[collect_End]
LABEL+13:This backdoored log function version of Triada was first described by Dr.Web in July 2017. The blog post includes a description of Triada code injection methods.
V18 = -1;
LABEL_18:
j___config_log_println(v7, v6, v10, v11, "cf89450001");
if ( v10 )
<MD5 of the process name>36.jmd. By using the MD5 of the process name, the Triada authors tried to obscure the injection target. However, the pool of all available process names is fairly small, so this hash was easily reversible. com.android.systemui (the System UI app) and com.android.vending (the Google Play app). The first target was injected to get the GET_REAL_TASKS permission. This is a signature-level permission, which means that it can’t be held by ordinary Android apps. getRecentTasks() method is deprecated to protect users' privacy. However, apps holding the GET_REAL_TASKS permission can get the result of this method call. To hold the GET_REAL_TASKS permission, an app has to be signed with a specific certificate, the device’s platform cert, which is held by the OEM. Triada didn’t have access to this cert. Instead it executed additional code in the System UI app, which has the GET_REAL_TASKS permission.
|
|
36.jmd, wasn’t encrypted. This is the MMD file name string mentioned before. 
36.jmd string and introduced changes to the code for compatibility with Android Nougat. 