Author Archives: Eugene Liderman

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

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.

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

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.

What’s New in Android Q Security

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

Queue the Hardening Enhancements

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.

Quantifying Measurable Security

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.

The Android Platform Security Model

Posted by Jeff Vander Stoep, Android Security & Privacy Team

Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss:
  • The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
  • The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
  • The complex threat model Android must address.
  • How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
  • How Android’s security systems have evolved over time to address the threat model.
Android is fundamentally based on a multi-party consent1 model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich

Notes

  1. The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. ↩

The Android Platform Security Model

Posted by Jeff Vander Stoep, Android Security & Privacy Team

Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss:
  • The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
  • The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
  • The complex threat model Android must address.
  • How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
  • How Android’s security systems have evolved over time to address the threat model.
Android is fundamentally based on a multi-party consent1 model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich

Notes

  1. The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. ↩

Android Security & Privacy Year in Review 2018: Keeping two billion users, and their data, safe and sound

Posted by Meghan Kelly, Android Security & Privacy Team
We're excited to release today the 2018 Android Security and Privacy Year in Review. This year's report highlights the advancements we made in Android throughout the year, and how we've worked to keep the overall ecosystem secure.
Our goal is to be open and transparent in everything we do. We want to make sure we keep our users, partners, enterprise customers, and developers up to date on the latest security and privacy enhancements in as close to real-time as possible. To that end, in 2018 we prioritized regularly providing updates through our blogs and our new Transparency Reports, which give a quarterly ecosystem overview. In this year-in-review, you'll see fewer words and more links to relevant articles from the previous year. Check out our Android Security Center to get the latest on these advancements.
In this year's report, some of our top highlights include:
  • New features in Google Play Protect
  • Ecosystem and Potentially Harmful Application family highlights
  • Updates on our vulnerability rewards program
  • Platform security enhancements
We're also excited to have Dave Kleidermacher, Vice President of Android Security and Privacy, give you a rundown of the highlights from this report. Watch his video below to learn more.

Managed Google Play earns key certifications for security and privacy


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.

Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerability at a time

Posted by Patrick Mutchler and Meghan Kelly, Android Security & Privacy Team


[Cross-posted from the Android Developers Blog]

Helping Android app developers build secure apps, free of known vulnerabilities, means helping the overall ecosystem thrive. This is why we launched the Application Security Improvement Program five years ago, and why we're still so invested in its success today.

What the Android Security Improvement Program does

When an app is submitted to the Google Play store, we scan it to determine if a variety of vulnerabilities are present. If we find something concerning, we flag it to the developer and then help them to remedy the situation.

Think of it like a routine physical. If there are no problems, the app runs through our normal tests and continues on the process to being published in the Play Store. If there is a problem, however, we provide a diagnosis and next steps to get back to healthy form.

Over its lifetime, the program has helped more than 300,000 developers to fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users with the same security issues present, which we consider a win.

What vulnerabilities are covered

The App Security Improvement program covers a broad range of security issues in Android apps. These can be as specific as security issues in certain versions of popular libraries (ex: CVE-2015-5256) and as broad as unsafe TLS/SSL certificate validation.

We are continuously improving this program's capabilities by improving the existing checks and launching checks for more classes of security vulnerability. In 2018, we deployed warnings for six additional security vulnerability classes including:

  1. SQL Injection
  2. File-based Cross-Site Scripting
  3. Cross-App Scripting
  4. Leaked Third-Party Credentials
  5. Scheme Hijacking
  6. JavaScript Interface Injection

Ensuring that we're continuing to evolve the program as new exploits emerge is a top priority for us. We are continuing to work on this throughout 2019.

Keeping Android users safe is important to Google. We know that app security is often tricky and that developers can make mistakes. We hope to see this program grow in the years to come, helping developers worldwide build apps users can truly trust.