Google Security Blog

Syndikovat obsah
The latest news and insights from Google on security and safety on the Internet.
Aktualizace: 58 min 1 sek zpět

PHA Family Highlights: Zen and its cousins

21 Květen, 2019 - 20:03
table, th, td { border: 1px solid black;
Posted by Lukasz Siewierski, Android Security & Privacy Team
Google Play Protect detects Potentially Harmful Applications (PHAs) which Google Play Protect defines as any mobile app that poses a potential security risk to users or to user data—commonly referred to as "malware." in a variety of ways, such as static analysis, dynamic analysis, and machine learning. While our systems are great at automatically detecting and protecting against PHAs, we believe the best security comes from the combination of automated scanning and skilled human review.
With this blog series we will be sharing our research analysis with the research and broader security community, starting with the PHA family, Zen. Zen uses root permissions on a device to automatically enable a service that creates fake Google accounts. These accounts are created by abusing accessibility services. Zen apps gain access to root permissions from a rooting trojan in its infection chain. In this blog post, we do not differentiate between the rooting component and the component that abuses root: we refer to them interchangeably as Zen. We also describe apps that we think are coming from the same author or a group of authors. All of the PHAs that are mentioned in this blog post were detected and removed by Google Play Protect.
BackgroundUncovering PHAs takes a lot of detective work and unraveling the mystery of how they're possibly connected to other apps takes even more. PHA authors usually try to hide their tracks, so attribution is difficult. Sometimes, we can attribute different apps to the same author based on a small, unique pieces of evidence that suggest similarity, such as a repetition of an exceptionally rare code snippet, asset, or a particular string in the debug logs. Every once in a while, authors leave behind a trace that allows us to attribute not only similar apps, but also multiple different PHA families to the same group or person.
However, the actual timeline of the creation of different variants is unclear. In April 2013, we saw the first sample, which made heavy use of dynamic code loading (i.e., fetching executable code from remote sources after the initial app is installed). Dynamic code loading makes it impossible to state what kind of PHA it was. This sample displayed ads from various sources. More recent variants blend rooting capabilities and click fraud. As rooting exploits on Android become less prevalent and lucrative, PHA authors adapt their abuse or monetization strategy to focus on tactics like click fraud.
This post doesn't follow the chronological evolution of Zen, but instead covers relevant samples from least to most complex.
Apps with a custom-made advertisement SDKThe simplest PHA from the author's portfolio used a specially crafted advertisement SDK to create a proxy for all ads-related network traffic. By proxying all requests through a custom server, the real source of ads is opaque. This example shows one possible implementation of this technique.

This approach allows the authors to combine ads from third-party advertising networks with ads they created for their own apps. It may even allow them to sell ad space directly to application developers. The advertisement SDK also collects statistics about clicks and impressions to make it easier to track revenue. Selling the ad traffic directly or displaying ads from other sources in a very large volume can provide direct profit to the app author from the advertisers.
We have seen two types of apps that use this custom-made SDK. The first are games of very low quality that mimic the experience of popular mobile games. While the counterfeit games claim to provide similar functionality to the popular apps, they are simply used to display ads through a custom advertisement SDK.
The second type of apps reveals an evolution in the author's tactics. Instead of implementing very basic gameplay, the authors pirated and repackaged the original game in their app and bundled with it their advertisement SDK. The only noticeable difference is the game has more ads, including ads on the very first screen.
In all cases, the ads are used to convince users to install other apps from different developer accounts, but written by the same group. Those apps use the same techniques to monetize their actions.
Click fraud appsThe authors' tactics evolved from advertisement spam to real PHA (Click Fraud). Click fraud PHAs simulate user clicks on ads instead of simply displaying ads and waiting for users to click them. This allows the PHA authors to monetize their apps more effectively than through regular advertising. This behavior negatively impacts advertisement networks and their clients because advertising budget is spent without acquiring real customers, and impacts user experience by consuming their data plan resources.
The click fraud PHA requests a URL to the advertising network directly instead of proxying it through an additional SDK. The command & control server (C&C server) returns the URL to click along with a very long list of additional parameters in JSON format. After rendering the ad on the screen, the app tries to identify the part of the advertisement website to click. If that part is found, the app loads Javascript snippets from the JSON parameters to click a button or other HTML element, simulating a real user click. Because a user interacting with an ad often leads to a higher chance of the user purchasing something, ad networks often "pay per click" to developers who host their ads. Therefore, by simulating fraudulent clicks, these developers are making money without requiring a user to click on an advertisement.
This example code shows a JSON reply returned by the C&C server. It has been shortened for brevity.
{
"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();"Based on this JSON reply, the app looks for an HTML snippet that corresponds to the active element (show_hide btnnext) and, if found, the Javascript snippet tries to perform a click() method on it.
Rooting trojansThe Zen authors have also created a rooting trojan. Using a publicly available rooting framework, the PHA attempts to root devices and gain persistence on them by reinstalling itself on the system partition of rooted device. Installing apps on the system partition makes it harder for the user to remove the app.
This technique only works for unpatched devices running Android 4.3 or lower. Devices running Android 4.4 and higher are protected by Verified Boot.
Zen's rooting trojan apps target a specific device model with a very specific system image. After achieving root access the app tries to replace the framework.jar file on the system partition. Replicating framework.jar allows the app to intercept and modify the behavior of the Android standard API. In particular, these apps try to add an additional method called statistics() into the Activity class. When inserted, this method runs every time any Activity object in any Android app is created. This happens all the time in regular Android apps, as Activity is one of the fundamental Android UI elements. The only purpose of this method is to connect to the C&C server.
The Zen trojanAfter achieving persistence, the trojan downloads additional payloads, including another trojan called Zen. Zen requires root to work correctly on the Android operating system.
The Zen trojan uses its root privileges to turn on accessibility service (a service used to allow Android users with disabilities to use their devices) for itself by writing to a system-wide setting value enabled_accessibility_services. Zen doesn't even check for the root privilege: it just assumes it has it. This leads us to believe that Zen is just part of a larger infection chain. The trojan implements three accessibility services directed at different Android API levels and uses these accessibility services, chosen by checking the operating system version, to create new Google accounts. This is done by opening the Google account creation process and parsing the current view. The app then clicks the appropriate buttons, scrollbars, and other UI elements to go through account sign-up without user intervention.
During the account sign-up process, Google may flag the account creation attempt as suspicious and prompt the app to solve a CAPTCHA. To get around this, the app then uses its root privilege to inject code into the Setup Wizard, extract the CAPTCHA image, and sends it to a remote server to try to solve the CAPTCHA. It is unclear if the remote server is capable of solving the CAPTCHA image automatically or if this is done manually by a human in the background. After the server returns the solution, the app enters it into the appropriate text field to complete the CAPTCHA challenge.
The Zen trojan does not implement any kind of obfuscation except for one string that is encoded using Base64 encoding. It's one of the strings - "How you'll sign in" - that it looks for during the account creation process. The code snippet below shows part of the screen parsing process.
if (!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")) {
Apart from injecting code to read the CAPTCHA, the app also injects its own code into the system_server process, which requires root privileges. This indicates that the app tries to hide itself from any anti-PHA systems that look for a specific app process name or does not have the ability to scan the memory of the system_server process.
The app also creates hooks to prevent the phone from rebooting, going to sleep or allowing the user from pressing hardware buttons during the account creation process. These hooks are created using the root access and a custom native code called Lmt_INJECT, although the algorithm for this is well known.
First, the app has to turn off SELinux protection. Then the app finds a process id value for the process it wants to inject with code. This is done using a series of syscalls as outlined below. The "source process" refers to the Zen trojan running as root, while the "target process" refers to the process to which the code is injected and [pid] refers to the target process pid value.
  1. 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.
  2. A ptrace_attach syscall is called. This allows the source process to trace the target.
  3. The source process looks at its own memory to calculate the offset between the beginning of the libc library and the mmap address.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
This diagram illustrates the whole process.

SummaryPHA authors go to great lengths to come up with increasingly clever ways to monetize their apps.
Zen family PHA authors exhibit a wide range of techniques, from simply inserting an advertising SDK to a sophisticated trojan. The app that resulted in the largest number of affected users was the click fraud version, which was installed over 170,000 times at its peak in February 2018. The most affected countries were India, Brazil, and Indonesia. In most cases, these click fraud apps were uninstalled by the users, probably due to the low quality of the apps.
If Google Play Protect detects one of these apps, Google Play Protect will show a warning to users.
We are constantly on the lookout for new threats and we are expanding our protections. Every device with Google Play includes Google Play Protect and all apps on Google Play are automatically and periodically scanned by our solutions.
You can check the status of Google Play Protect on your device:
  1. Open your Android device's Google Play Store app.
  2. Tap Menu>Play Protect.
  3. 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
Kategorie: Hacking & Security

New research: How effective is basic account hygiene at preventing hijacking

17 Květen, 2019 - 19:19
Posted by Kurt Thomas and Angelika Moscicki
Every day, we protect users from hundreds of thousands of account hijacking attempts. Most attacks stem from automated bots with access to third-party password breaches, but we also see phishing and targeted attacks. Earlier this year, we suggested how just five simple steps like adding a recovery phone number can help keep you safe, but we wanted to prove it in practice.
We teamed up with researchers from New York University and the University of California, San Diego to find out just how effective basic account hygiene is at preventing hijacking. The year-long study, on wide-scale attacks and targeted attacks, was presented on Wednesday at a gathering of experts, policy makers, and users called The Web Conference.
Our research shows that simply adding a recovery phone number to your Google Account can block up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks that occurred during our investigation.


Google’s automatic, proactive hijacking protection
We provide an automatic, proactive layer of security to better protect all our users against account hijacking. Here’s how it works: if we detect a suspicious sign-in attempt (say, from a new location or device), we’ll ask for additional proof that it’s really you. This proof might be confirming you have access to a trusted phone or answering a question where only you know the correct response.
If you’ve signed into your phone or set up a recovery phone number, we can provide a similar level of protection to 2-Step Verification via device-based challenges. We found that an SMS code sent to a recovery phone number helped block 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks. On-device prompts, a more secure replacement for SMS, helped prevent 100% of automated bots, 99% of bulk phishing attacks and 90% of targeted attacks.


Both device- and knowledge-based challenges help thwart automated bots, while device-based challenges help thwart phishing and even targeted attacks.
If you don’t have a recovery phone number established, then we might fall back on the weaker knowledge-based challenges, like recalling your last sign-in location. This is an effective defense against bots, but protection rates for phishing can drop to as low as 10%. The same vulnerability exists for targeted attacks. That’s because phishing pages and targeted attackers can trick you into revealing any additional identifying information we might ask for.
Given the security benefits of challenges, one might ask why we don’t require them for all sign-ins. The answer is that challenges introduce additional friction and increase the risk of account lockout. In an experiment, 38% of users did not have access to their phone when challenged. Another 34% of users could not recall their secondary email address.
If you lose access to your phone, or can’t solve a challenge, you can always return to a trusted device you previously logged in from to gain access to your account.


Digging into “hack for hire” attacks
Where most bots and phishing attacks are blocked by our automatic protections, targeted attacks are more pernicious. As part of our ongoing efforts to monitor hijacking threats, we have been investigating emerging “hack for hire” criminal groups that purport to break into a single account for a fee on the order of $750 USD. These attackers often rely on spear phishing emails that impersonate family members, colleagues, government officials, or even Google. If the target doesn’t fall for the first spear phishing attempt, follow-on attacks persist for upwards of a month.


Example man-in-the-middle phishing attack that checks for password validity in real-time. Afterwards, the page prompts victims to disclose SMS authentication codes to access the victim’s account.
We estimate just one in a million users face this level of risk. Attackers don’t target random individuals though. While the research shows that our automatic protections can help delay, and even prevent as many as 66% of the targeted attacks that we studied, we still recommend that high-risk users enroll in our Advanced Protection Program. In fact, zero users that exclusively use security keys fell victim to targeted phishing during our investigation.



Take a moment to help keep your account secure
Just like buckling a seat belt, take a moment to follow our five tips to help keep your account secure. As our research shows, one of the easiest things you can do to protect your Google Account is to set up a recovery phone number. For high-risk users—like journalists, activists, business leaders, and political campaign teams—our Advanced Protection Program provides the highest level of security. You can also help protect your non-Google accounts from third-party password breaches by installing the Password Checkup Chrome extension.
Kategorie: Hacking & Security

Advisory: Security Issue with Bluetooth Low Energy (BLE) Titan Security Keys

16 Květen, 2019 - 17:28
Posted by Christiaan Brand, Product Manager, Google Cloud

We’ve become aware of an issue that affects the Bluetooth Low Energy (BLE) version of the Titan Security Key available in the U.S. and are providing users with the immediate steps they need to take to protect themselves and to receive a free replacement key. This bug affects Bluetooth pairing only, so non-Bluetooth security keys are not affected. Current users of Bluetooth Titan Security Keys should continue to use their existing keys while waiting for a replacement, since security keys provide the strongest protection against phishing.

What is the security issue?

Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key -- within approximately 30 feet -- to (a) communicate with your security key, or (b) communicate with the device to which your key is paired. In order for the misconfiguration to be exploited, an attacker would have to align a series of events in close coordination:

  • When you’re trying to sign into an account on your device, you are normally asked to press the button on your BLE security key to activate it. An attacker in close physical proximity at that moment in time can potentially connect their own device to your affected security key before your own device connects. In this set of circumstances, the attacker could sign into your account using their own device if the attacker somehow already obtained your username and password and could time these events exactly.
  • Before you can use your security key, it must be paired to your device. Once paired, an attacker in close physical proximity to you could use their device to masquerade as your affected security key and connect to your device at the moment you are asked to press the button on your key. After that, they could attempt to change their device to appear as a Bluetooth keyboard or mouse and potentially take actions on your device.

This security issue does not affect the primary purpose of security keys, which is to protect you against phishing by a remote attacker. Security keys remain the strongest available protection against phishing; it is still safer to use a key that has this issue, rather than turning off security key-based two-step verification (2SV) on your Google Account or downgrading to less phishing-resistant methods (e.g. SMS codes or prompts sent to your device). This local proximity Bluetooth issue does not affect USB or NFC security keys.

Am I affected?

This issue affects the BLE version of Titan Security Keys. To determine if your key is affected, check the back of the key. If it has a “T1” or “T2” on the back of the key, your key is affected by the issue and is eligible for free replacement.

Steps to protect yourself

If you want to minimize the remaining risk until you receive your replacement keys, you can perform the following additional steps:

iOS devices:

On devices running iOS version 12.2 or earlier, we recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your key to sign into your Google Account on your device, immediately unpair it. You can use your key in this manner again while waiting for your replacement, until you update to iOS 12.3.

Once you update to iOS 12.3, your affected security key will no longer work. You will not be able to use your affected key to sign into your Google Account, or any other account protected by the key, and you will need to order a replacement key. If you are already signed into your Google Account on your iOS device, do not sign out because you won’t be able to sign in again until you get a new key. If you are locked out of your Google Account on your iOS device before your replacement key arrives, see these instructions for getting back into your account. Note that you can continue to sign into your Google Account on non-iOS devices.

On Android and other devices:

We recommend using your affected security key in a private place where a potential attacker is not within close physical proximity (approximately 30 feet). After you’ve used your affected security key to sign into your Google Account, immediately unpair it. Android devices updated with the upcoming June 2019 Security Patch Level (SPL) and beyond will automatically unpair affected Bluetooth devices, so you won’t need to unpair manually. You can also continue to use your USB or NFC security keys, which are supported on Android and not affected by this issue.

How to get a replacement key

We recommend that everyone with an affected BLE Titan Security Key get a free replacement by visiting google.com/replacemykey.

Is it still safe to use my affected BLE Titan Security Key?

It is much safer to use the affected key instead of no key at all. Security keys are the strongest protection against phishing currently available.

Kategorie: Hacking & Security

What’s New in Android Q Security

9 Květen, 2019 - 22:31

Posted by Rene Mayrhofer and Xiaowen Xin, Android Security & Privacy Team

[Cross-posted from the Android Developers Blog]

With every new version of Android, one of our top priorities is raising the bar for security. Over the last few years, these improvements have led to measurable progress across the ecosystem, and 2018 was no different.

In the 4th quarter of 2018, we had 84% more devices receiving a security update than in the same quarter the prior year. At the same time, no critical security vulnerabilities affecting the Android platform were publicly disclosed without a security update or mitigation available in 2018, and we saw a 20% year-over-year decline in the proportion of devices that installed a Potentially Harmful App. In the spirit of transparency, we released this data and more in our Android Security & Privacy 2018 Year In Review.

But now you may be asking, what’s next?

Today at Google I/O we lifted the curtain on all the new security features being integrated into Android Q. We plan to go deeper on each feature in the coming weeks and months, but first wanted to share a quick summary of all the security goodness we’re adding to the platform.

Encryption

Storage encryption is one of the most fundamental (and effective) security technologies, but current encryption standards require devices have cryptographic acceleration hardware. Because of this requirement many devices are not capable of using storage encryption. The launch of Adiantum changes that in the Android Q release. We announced Adiantum in February. Adiantum is designed to run efficiently without specialized hardware, and can work across everything from smart watches to internet-connected medical devices.

Our commitment to the importance of encryption continues with the Android Q release. All compatible Android devices newly launching with Android Q are required to encrypt user data, with no exceptions. This includes phones, tablets, televisions, and automotive devices. This will ensure the next generation of devices are more secure than their predecessors, and allow the next billion people coming online for the first time to do so safely.

However, storage encryption is just one half of the picture, which is why we are also enabling TLS 1.3 support by default in Android Q. TLS 1.3 is a major revision to the TLS standard finalized by the IETF in August 2018. It is faster, more secure, and more private. TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions. From a security perspective, TLS 1.3 removes support for weaker cryptographic algorithms, as well as some insecure or obsolete features. It uses a newly-designed handshake which fixes several weaknesses in TLS 1.2. The new protocol is cleaner, less error prone, and more resilient to key compromise. Finally, from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.

Platform Hardening

Android utilizes a strategy of defense-in-depth to ensure that individual implementation bugs are insufficient for bypassing our security systems. We apply process isolation, attack surface reduction, architectural decomposition, and exploit mitigations to render vulnerabilities more difficult or impossible to exploit, and to increase the number of vulnerabilities needed by an attacker to achieve their goals.

In Android Q, we have applied these strategies to security critical areas such as media, Bluetooth, and the kernel. We describe these improvements more extensively in a separate blog post, but some highlights include:

  • A constrained sandbox for software codecs.
  • Increased production use of sanitizers to mitigate entire classes of vulnerabilities in components that process untrusted content.
  • Shadow Call Stack, which provides backward-edge Control Flow Integrity (CFI) and complements the forward-edge protection provided by LLVM’s CFI.
  • Protecting Address Space Layout Randomization (ASLR) against leaks using eXecute-Only Memory (XOM).
  • Introduction of Scudo hardened allocator which makes a number of heap related vulnerabilities more difficult to exploit.

Authentication

Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and iris. Since the launch, we’ve seen a lot of apps embrace the new API, and now with Android Q, we’ve updated the underlying framework with robust support for face and fingerprint. Additionally, we expanded the API to support additional use-cases, including both implicit and explicit authentication.

In the explicit flow, the user must perform an action to proceed, such as tap their finger to the fingerprint sensor. If they’re using face or iris to authenticate, then the user must click an additional button to proceed. The explicit flow is the default flow and should be used for all high-value transactions such as payments.

Implicit flow does not require an additional user action. It is used to provide a lighter-weight, more seamless experience for transactions that are readily and easily reversible, such as sign-in and autofill.

Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu. To support this, we’ve added a new BiometricManager class. You can now call the canAuthenticate() method in it to determine whether the device supports biometric authentication and whether the user is enrolled.

What’s Next?

Beyond Android Q, we are looking to add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license. Apps such as these have a lot of security requirements and involves integration between the client application on the holder’s mobile phone, a reader/verifier device, and issuing authority backend systems used for license issuance, updates, and revocation.

This initiative requires expertise around cryptography and standardization from the ISO and is being led by the Android Security and Privacy team. We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications. You can expect to hear more updates from us on Electronic ID support in the near future.

Acknowledgements: This post leveraged contributions from Jeff Vander Stoep and Shawn Willden
Kategorie: Hacking & Security

Queue the Hardening Enhancements

9 Květen, 2019 - 17:35

Posted by Jeff Vander Stoep, Android Security & Privacy Team and Chong Zhang, Android Media Team

[Cross-posted from the Android Developers Blog]

Android Q Beta versions are now publicly available. Among the various new features introduced in Android Q are some important security hardening changes. While exciting new security features are added in each Android release, hardening generally refers to security improvements made to existing components.

When prioritizing platform hardening, we analyze data from a number of sources including our vulnerability rewards program (VRP). Past security issues provide useful insight into which components can use additional hardening. Android publishes monthly security bulletins which include fixes for all the high/critical severity vulnerabilities in the Android Open Source Project (AOSP) reported through our VRP. While fixing vulnerabilities is necessary, we also get a lot of value from the metadata - analysis on the location and class of vulnerabilities. With this insight we can apply the following strategies to our existing components:

  • Contain: isolating and de-privileging components, particularly ones that handle untrusted content. This includes:
    • Access control: adding permission checks, increasing the granularity of permission checks, or switching to safer defaults (for example, default deny).
    • Attack surface reduction: reducing the number of entry/exit points (i.e. principle of least privilege).
    • Architectural decomposition: breaking privileged processes into less privileged components and applying attack surface reduction.
  • Mitigate: Assume vulnerabilities exist and actively defend against classes of vulnerabilities or common exploitation techniques.

Here’s a look at high severity vulnerabilities by component and cause from 2018:

Most of Android’s vulnerabilities occur in the media and bluetooth components. Use-after-free (UAF), integer overflows, and out of bounds (OOB) reads/writes comprise 90% of vulnerabilities with OOB being the most common.

A Constrained Sandbox for Software Codecs

In Android Q, we moved software codecs out of the main mediacodec service into a constrained sandbox. This is a big step forward in our effort to improve security by isolating various media components into less privileged sandboxes. As Mark Brand of Project Zero points out in his Return To Libstagefright blog post, constrained sandboxes are not where an attacker wants to end up. In 2018, approximately 80% of the critical/high severity vulnerabilities in media components occurred in software codecs, meaning further isolating them is a big improvement. Due to the increased protection provided by the new mediaswcodec sandbox, these same vulnerabilities will receive a lower severity based on Android’s severity guidelines.

The following figure shows an overview of the evolution of media services layout in the recent Android releases.

  • Prior to N, media services are all inside one monolithic mediaserver process, and the extractors run inside the client.
  • In N, we delivered a major security re-architect, where a number of lower-level media services are spun off into individual service processes with reduced privilege sandboxes. Extractors are moved into server side, and put into a constrained sandbox. Only a couple of higher-level functionalities remained in mediaserver itself.
  • In O, the services are “treblized,” and further deprivileged that is, separated into individual sandboxes and converted into HALs. The media.codec service became a HAL while still hosting both software and hardware codec implementations.
  • In Q, the software codecs are extracted from the media.codec process, and moved back to system side. It becomes a system service that exposes the codec HAL interface. Selinux policy and seccomp filters are further tightened up for this process. In particular, while the previous mediacodec process had access to device drivers for hardware accelerated codecs, the software codec process has no access to device drivers.

With this move, we now have the two primary sources for media vulnerabilities tightly sandboxed within constrained processes. Software codecs are similar to extractors in that they both have extensive code parsing bitstreams from untrusted sources. Once a vulnerability is identified in the source code, it can be triggered by sending a crafted media file to media APIs (such as MediaExtractor or MediaCodec). Sandboxing these two services allows us to reduce the severity of potential security vulnerabilities without compromising performance.

In addition to constraining riskier codecs, a lot of work has also gone into preventing common types of vulnerabilities.

Bound Sanitizer

Incorrect or missing memory bounds checking on arrays account for about 34% of Android’s userspace vulnerabilities. In cases where the array size is known at compile time, LLVM’s bound sanitizer (BoundSan) can automatically instrument arrays to prevent overflows and fail safely.

BoundSan instrumentation

BoundSan is enabled in 11 media codecs and throughout the Bluetooth stack for Android Q. By optimizing away a number of unnecessary checks the performance overhead was reduced to less than 1%. BoundSan has already found/prevented potential vulnerabilities in codecs and Bluetooth.

More integer sanitizer in more places

Android pioneered the production use of sanitizers in Android Nougat when we first started rolling out integer sanization (IntSan) in the media frameworks. This work has continued with each release and has been very successful in preventing otherwise exploitable vulnerabilities. For example, new IntSan coverage in Android Pie mitigated 11 critical vulnerabilities. Enabling IntSan is challenging because overflows are generally benign and unsigned integer overflows are well defined and sometimes intentional. This is quite different from the bound sanitizer where OOB reads/writes are always unintended and often exploitable. Enabling Intsan has been a multi year project, but with Q we have fully enabled it across the media frameworks with the inclusion of 11 more codecs.

IntSan Instrumentation

IntSan works by instrumenting arithmetic operations to abort when an overflow occurs. This instrumentation can have an impact on performance, so evaluating the impact on CPU usage is necessary. In cases where performance impact was too high, we identified hot functions and individually disabled IntSan on those functions after manually reviewing them for integer safety.

BoundSan and IntSan are considered strong mitigations because (where applied) they prevent the root cause of memory safety vulnerabilities. The class of mitigations described next target common exploitation techniques. These mitigations are considered to be probabilistic because they make exploitation more difficult by limiting how a vulnerability may be used.

Shadow Call Stack

LLVM’s Control Flow Integrity (CFI) was enabled in the media frameworks, Bluetooth, and NFC in Android Pie. CFI makes code reuse attacks more difficult by protecting the forward-edges of the call graph, such as function pointers and virtual functions. Android Q uses LLVM’s Shadow Call Stack (SCS) to protect return addresses, protecting the backwards-edge of control flow graph. SCS accomplishes this by storing return addresses in a separate shadow stack which is protected from leakage by storing its location in the x18 register, which is now reserved by the compiler.

SCS Instrumentation

SCS has negligible performance overhead and a small memory increase due to the separate stack. In Android Q, SCS has been turned on in portions of the Bluetooth stack and is also available for the kernel. We’ll share more on that in an upcoming post.

eXecute-Only Memory

Like SCS, eXecute-Only Memory (XOM) aims at making common exploitation techniques more expensive. It does so by strengthening the protections already provided by address space layout randomization (ASLR) which in turn makes code reuse attacks more difficult by requiring attackers to first leak the location of the code they intend to reuse. This often means that an attacker now needs two vulnerabilities, a read primitive and a write primitive, where previously just a write primitive was necessary in order to achieve their goals. XOM protects against leaks (memory disclosures of code segments) by making code unreadable. Attempts to read execute-only code results in the process aborting safely.

Tombstone from a XOM abort

Starting in Android Q, platform-provided AArch64 code segments in binaries and libraries are loaded as execute-only. Not all devices will immediately receive the benefit as this enforcement has hardware dependencies (ARMv8.2+) and kernel dependencies (Linux 4.9+, CONFIG_ARM64_UAO). For apps with a targetSdkVersion lower than Q, Android’s zygote process will relax the protection in order to avoid potential app breakage, but 64 bit system processes (for example, mediaextractor, init, vold, etc.) are protected. XOM protections are applied at compile-time and have no memory or CPU overhead.

Scudo Hardened Allocator

Scudo is a dynamic heap allocator designed to be resilient against heap related vulnerabilities such as:

  • Use-after-frees: by quarantining freed blocks.
  • Double-frees: by tracking chunk states.
  • Buffer overflows: by check summing headers.
  • Heap sprays and layout manipulation: by improved randomization.

Scudo does not prevent exploitation but rather proactively manages memory in a way to make exploitation more difficult. It is configurable on a per-process basis depending on performance requirements. Scudo is enabled in extractors and codecs in the media frameworks.

Tombstone from Scudo aborts

Contributing security improvements to Open Source

AOSP makes use of a number of Open Source Projects to build and secure Android. Google is actively contributing back to these projects in a number of security critical areas:

Thank you to Ivan Lozano, Kevin Deus, Kostya Kortchinsky, Kostya Serebryany, and Mike Logan for their contributions to this post.

Kategorie: Hacking & Security

Quantifying Measurable Security

8 Květen, 2019 - 22:19
Posted by Eugene Liderman, Android Security & Privacy Team
With Google I/O this week you are going to hear about a lot of new features in Android that are coming in Q. One thing that you will also hear about is how every new Android release comes with dozens of security and privacy enhancements. We have been continually investing in our layered security approach which is also referred to as“ defense-in-depth”. These defenses start with hardware-based security, moving up the stack to the Linux kernel with app sandboxing. On top of that, we provide built-in security services designed to protect against malware and phishing.
However layered security doesn’t just apply to the technology. It also applies to the people and the process. Both Android and Chrome OS have dedicated security teams who are tasked with continually enhancing the security of these operating systems through new features and anti-exploitation techniques. In addition, each team leverages a mature and comprehensive security development lifecycle process to ensure that security is always part of the process and not an afterthought.
Secure by design is not the only thing that Android and Chrome OS have in common. Both operating systems also share numerous key security concepts, including:
  • Heavily relying on hardware based security for things like rollback prevention and verified boot
  • Continued investment in anti-exploitation techniques so that a bug or vulnerability does not become exploitable
  • Implementing two copies of the OS in order to support seamless updates that run in the background and notify the user when the device is ready to boot the new version
  • Splitting up feature and security updates and providing a frequent cadence of security updates
  • Providing built-in anti-malware and anti-phishing solutions through Google Play Protect and Google Safe Browsing
On the Android Security & Privacy team we’re always trying to find ways to assess our ongoing security investments; we often refer to this as measurable security. One way we measure our ongoing investments is through third party analyst research such as Gartner’s May 2019 Mobile OSs and Device Security: A Comparison of Platforms report (subscription required). For those not familiar with this report, it’s a comprehensive comparison between “the core OS security features that are built into various mobile device platforms, as well as enterprise management capabilities.” In this year’s report, Gartner provides “a comparison of the out-of-the-box controls under the category “Built-In Security”. In the second part, called “Corporate-Managed Security, [Gartner] compares the enterprise management controls available for the latest versions of the major mobile device platforms”. Here is how our operating systems and devices ranked:
  • Android 9 (Pie) scored “strong” in 26 out of 30 categories
  • Pixel 3 with Titan M received “strong” ratings in 27 of the 30 categories, and had the most “strong” ratings in the built-in security section out of all devices evaluated (15 out of 17)
  • Chrome OS was added in this year's report and received strong ratings in 27 of the 30 categories.
Check out the video of Patrick Hevesi, who was the lead analyst on the report, introducing the 2019 report, the methodology and what went into this year's criteria.

You can see a breakdown of all of the categories in the table below:


Take a look at all of the great security and privacy enhancements that came in Pie by reading Android Pie à la mode: Security & Privacy. Also be sure to live stream our Android Q security update at Google IO titled: Security on Android: What's Next on Thursday at 8:30am Pacific Time.
Kategorie: Hacking & Security

Google CTF 2019 is here

4 Květen, 2019 - 00:50
Posted by Jan Keller, Security Technical Program Manager

June has become the month where we’re inviting thousands of security aficionados to put their skills to the test...

In 2018, 23,563 people submitted at least one flag on their hunt for the secret cake recipe in the Beginner’s Quest. While 330 teams competed for a place in the CTF Finals, the lucky 10 winning teams got a trip to London to play with fancy tools, solve mysterious videos and dine in Churchill’s old chambers.

This June, we will be hosting our fourth-annual Capture the Flag event. Teams of security researchers will again come together from all over the globe for one weekend to eat, sleep and breathe security puzzles and challenges - some of them working together around the clock to solve some of the toughest security challenges on the planet.

Up for grabs this year is $31,337.00 in prize money and the title of Google CTF Champion.

Ready? Here are the details:


  1. The qualification round will take place online Sat/Sun June 22 and 23 2019
  2. The top 10 teams will qualify for the onsite final (location and details coming soon)
  3. Players from the Beginner's Quest can enter the draw for 10 tickets to witness the Google CTF finals
Whether you’re a seasoned CTF player or just curious about cyber security and ethical hacking, we want you to join us. If you’re just starting out, the “Beginner's Quest” is perfect for you. Sign up to learn skills, meet new friends in the security community and even watch the pros in action. See you there! For the latest announcements, see g.co/ctf, subscribe to our mailing list or follow us on @GoogleVRP.

Kategorie: Hacking & Security

Managed Google Play earns key certifications for security and privacy

3 Květen, 2019 - 16:00

Posted by Mike Burr, Android Enterprise Platform Specialist

[Cross-posted from the Android Enterprise Keyword Blog]



With managed Google Play, organizations can build a customized and secure mobile application storefront for their teams, featuring public and private applications. Organizations' employees can take advantage of the familiarity of a mobile app store to browse and download company-approved apps.
As with any enterprise-grade platform, it's critical that the managed Google Play Store operates with the highest standards of privacy and security. Managed Google Play has been awarded three important industry designations that are marks of meeting the strict requirements for information security management practices.
Granted by the International Organization for Standardization, achieving ISO 27001 certification demonstrates that a company meets stringent privacy and security standards when operating an Information Security Management System (ISMS). Additionally, managed Google Play received SOC 2 and 3 reports, which are benchmarks of strict data management and privacy controls. These designations and auditing procedures are developed by the American Institute of Certified Public Accountants (AICPA).
Meeting a high bar of security management standards
To earn the ISO 27001 certification, auditors from Ernst and Young performed a thorough audit of managed Google Play based on established privacy principles. The entire methodology of documentation and procedures for managing other companies' data are reviewed during an audit, and must be made available for regular compliance review. Companies that use managed Google Play are assured their data is managed in compliance with this industry standard. Additionally, ISO 27001 certification is in line with GDPR compliance.
Secure data management
With SOC 2 and SOC 3 reports, the focus is on controls relevant to data security, availability, processing integrity, confidentiality and privacy, which are verified through auditing reports. In managed Google Play, the data and private applications that enter Google's systems are administered according to strict protocols, including determinations for who can view them and under what conditions. Enterprises require and receive the assurance that their information is handled with the utmost confidentiality and that the integrity of their data is preserved. For many companies, the presence of an SOC 2 and 3 report is a requirement when selecting a specific service. These reports prove that a service company has met and is abiding by best practices set forth by AICPA to ensure data security.
Our ongoing commitment to enterprise security
With managed Google Play, companies' private apps for internal use are protected with a set of verified information security management processes and policies to ensure intellectual property is secure. This framework includes managed Google Play accounts that are used by enterprise mobility management (EMM) partners to manage devices.
Our commitment is that Android will continue to be a leader in enterprise security. As your team works across devices and shares mission-critical data through applications hosted in managed Google Play, you have the assurance of a commitment to providing your enterprise the highest standards of security and privacy.
Kategorie: Hacking & Security