Author Archives: Google Security PR

Securing communications between Google services with Application Layer Transport Security


At Google, protection of customer data is a top priority. One way we do this is by protecting data in transit by default. We protect data when it is sent to Google using secure communication protocols such as TLS (Transport Layer Security). Within our infrastructure, we protect service-to-service communications at the application layer using a system called Application Layer Transport Security (ALTS). ALTS authenticates the communication between Google services and helps protect data in transit. Today, we’re releasing a whitepaper, “Application Layer Transport Security,” that goes into detail about what ALTS is, how it protects data, and how it’s implemented at Google.

ALTS is a highly reliable, trusted system that provides authentication and security for our internal Remote Procedure Call (RPC) communications. ALTS requires minimal involvement from the services themselves. When services communicate with each other at Google, such as the Gmail frontend communicating with a storage backend system, they do not need to explicitly configure anything to ensure data transmission is protected - it is protected by default. All RPCs issued or received by a production workload that stay within a physical boundary controlled by or on behalf of Google are protected with ALTS by default. This delivers numerous benefits while allowing the system work at scale:

  1. More precise security: Each workload has its own identity. This allows workloads running on the same machine to authenticate using their own identity as opposed to the machine’s identity.
  2. Improved scalability: ALTS accommodates Google’s massive scale by using an efficient resumption mechanism embedded in the ALTS handshake protocol, allowing services that were already communicating to easily resume communications. ALTS can also accommodate the authentication and encryption needs of a large number of RPCs; for example, services running on Google production systems collectively issue on the order of O(1010) RPCs per second.
  3. Reduced overhead: The overhead of potentially expensive cryptographic operations can be reduced by supporting long-lived RPC channels.

Multiple features that ensure security and scalability

Inside physical boundaries controlled by or on behalf of Google, all scheduled production workloads are initialized with a certificate that asserts their identity. These credentials are securely delivered to the workloads. When a workload is involved in an ALTS handshake, it verifies the remote peer identity and certificate. To further increase security, all Google certificates have a relatively short lifespan.

ALTS has a flexible trust model that works for different types of entities on the network. Entities can be physical machines, containerized workloads, and even human users to whom certificates can be provisioned.

ALTS provides a handshake protocol, which is a Diffie-Hellman (DH) based authenticated key exchange protocol that Google developed and implemented. At the end of a handshake, ALTS provides applications with an authenticated remote peer identity, which can be used to enforce fine-grained authorization policies at the application layer.



ALTS ensures the integrity of Google traffic is protected, and encrypted as needed.

After a handshake is complete and the client and server negotiate the necessary shared secrets, ALTS secures RPC traffic by forcing integrity, and optional encryption, using the negotiated shared secrets. We support multiple protocols for integrity guarantees, e.g., AES-GMAC and AES-VMAC with 128-bit keys. Whenever traffic leaves a physical boundary controlled by or on behalf of Google, e.g., in transit over WAN between datacenters, all protocols are upgraded automatically to provide encryption as well as integrity guarantees. In this case, we use the AES-GCM and AES-VCM protocols with 128-bit keys.

More details on how Google data encryption is performed are available in another whitepaper we are releasing today, “Encryption in Transit in Google Cloud.”

In summary, ALTS is widely used in Google’s infrastructure to provide service-to-service authentication and integrity, with optional encryption for all Google RPC traffic. For more information about ALTS, please read our whitepaper, “Application Layer Transport Security.”


Additional protections by Safe Browsing for Android users



In our efforts to protect users and serve developers, the Google Safe Browsing team has expanded enforcement of Google's Unwanted Software Policy to further tamp down on unwanted and harmful mobile behaviors on Android. As part of this expanded enforcement, Google Safe Browsing will show warnings on apps and on websites leading to apps that collect a user’s personal data without their consent.

Apps handling personal user data (such as user phone number or email), or device data will be required to prompt users and to provide their own privacy policy in the app. Additionally, if an app collects and transmits personal data unrelated to the functionality of the app then, prior to collection and transmission, the app must prominently highlight how the user data will be used and have the user provide affirmative consent for such use.

These data collection requirements apply to all functions of the app. For example, during analytics and crash reportings, the list of installed packages unrelated to the app may not be transmitted from the device without prominent disclosure and affirmative consent.

These requirements apply to apps in Google Play and non-Play app markets. The Google Play team has also published guidelines for how Play apps should handle user data and provide disclosure.

Starting in 60 days, this expanded enforcement of Google’s Unwanted Software Policy may result in warnings shown on user devices via Google Play Protect or on webpages that lead to these apps. Webmasters whose sites show warnings due to distribution of these apps should refer to the Search Console for guidance on remediation and resolution of the warnings. Developers whose apps show warnings should refer to guidance in the Unwanted Software Help Center. Developers can also request an app review using this article on App verification and appeals, which contains guidance applicable to apps in both Google Play and non-Play app stores. Apps published in Google Play have specific criteria to meet Google Play’s enforcement of the Unwanted Software policy; these criteria are outlined in the Play August 2017 announcement.

Tizi: Detecting and blocking socially engineered spyware on Android



Google is constantly working to improve our systems that protect users from Potentially Harmful Applications (PHAs). Usually, PHA authors attempt to install their harmful apps on as many devices as possible. However, a few PHA authors spend substantial effort, time, and money to create and install their harmful app on a small number of devices to achieve a certain goal.

This blog post covers Tizi, a backdoor family with some rooting capabilities that was used in a targeted attack against devices in African countries, specifically: Kenya, Nigeria, and Tanzania. We'll talk about how the Google Play Protect and Threat Analysis teams worked together to detect and investigate Tizi-infected apps and remove and block them from Android devices.
What is Tizi?

Tizi is a fully featured backdoor that installs spyware to steal sensitive data from popular social media applications. The Google Play Protect security team discovered this family in September 2017 when device scans found an app with rooting capabilities that exploited old vulnerabilities. The team used this app to find more applications in the Tizi family, the oldest of which is from October 2015. The Tizi app developer also created a website and used social media to encourage more app installs from Google Play and third-party websites.

Here is an example social media post promoting a Tizi-infected app:

What is the scope of Tizi?


What are we doing?

To protect Android devices and users, we used Google Play Protect to disable Tizi-infected apps on affected devices and have notified users of all known affected devices. The developers' accounts have been suspended from Play.

The Google Play Protect team also used information and signals from the Tizi apps to update Google's on-device security services and the systems that search for PHAs. These enhancements have been enabled for all users of our security services and increases coverage for Google Play users and the rest of the Android ecosystem.

Additionally, there is more technical information below to help the security industry in our collective work against PHAs.


What do I need to do?

Through our investigation, we identified around 1,300 devices affected by Tizi. To reduce the chance of your device being affected by PHAs and other threats, we recommend these 5 basic steps:
  • Check permissions: Be cautious with apps that request unreasonable permissions. For example, a flashlight app shouldn't need access to send SMS messages.
  • Enable a secure lock screen: Pick a PIN, pattern, or password that is easy for you to remember and hard for others to guess.
  • Update your device: Keep your device up-to-date with the latest security patches. Tizi exploited older and publicly known security vulnerabilities, so devices that have up-to-date security patches are less exposed to this kind of attack.
  • Google Play Protect: Ensure Google Play Protect is enabled.
  • Locate your device: Practice finding your device, because you are far more likely to lose your device than install a PHA.

How does Tizi work?

The Google Play Protect team had previously classified some samples as spyware or backdoor PHAs without connecting them as a family. The early Tizi variants didn't have rooting capabilities or obfuscation, but later variants did.

After gaining root, Tizi steals sensitive data from popular social media apps like Facebook, Twitter, WhatsApp, Viber, Skype, LinkedIn, and Telegram. It usually first contacts its command-and-control servers by sending an SMS with the device's GPS coordinates to a specific number. Subsequent command-and-control communications are normally performed over regular HTTPS, though in some specific versions, Tizi uses the MQTT messaging protocol with a custom server. The backdoor contains various capabilities common to commercial spyware, such as recording calls from WhatsApp, Viber, and Skype; sending and receiving SMS messages; and accessing calendar events, call log, contacts, photos, Wi-Fi encryption keys, and a list of all installed apps. Tizi apps can also record ambient audio and take pictures without displaying the image on the device's screen.

Tizi can root the device by exploiting one of the following local vulnerabilities:
  • CVE-2012-4220
  • CVE-2013-2596
  • CVE-2013-2597
  • CVE-2013-2595
  • CVE-2013-2094
  • CVE-2013-6282
  • CVE-2014-3153
  • CVE-2015-3636
  • CVE-2015-1805
Most of these vulnerabilities target older chipsets, devices, and Android versions. All of the listed vulnerabilities are fixed on devices with a security patch level of April 2016 or later, and most of them were patched considerably prior to this date. Devices with this patch level or later are far less exposed to Tizi's capabilities. If a Tizi app is unable to take control of a device because the vulnerabilities it tries to use are are all patched, it will still attempt to perform some actions through the high level of permissions it asks the user to grant to it, mainly around reading and sending SMS messages and monitoring, redirecting, and preventing outgoing phone calls.


Samples uploaded to VirusTotal

To encourage further research in the security community, here are some sample applications embedding Tizi that were already on VirusTotal.

Package name
SHA256 digest
SHA1 certificate
com.press.nasa.com.tanofresh
4d780a6fc18458311250d4d1edc750468fdb9b3e4c950dce5b35d4567b47d4a7
816bbee3cab5eed00b8bd16df56032a96e243201
com.dailyworkout.tizi
7c6af091a7b0f04fb5b212bd3c180ddcc6abf7cd77478fd22595e5b7aa7cfd9f
404b4d1a7176e219eaa457b0050b4081c22a9a1a
com.system.update.systemupdate
7a956c754f003a219ea1d2205de3ef5bc354419985a487254b8aeb865442a55e
4d2962ac1f6551435709a5a874595d855b1fa8ab


Additional digests linked to Tizi

To encourage further research in the security community, here are some sample digests of exploits and utilities that were used or abused by Tizi.

Filename
SHA256 digest
run_root_shell
f2e45ea50fc71b62d9ea59990ced755636286121437ced6237aff90981388f6a
iovyroot
4d0887f41d0de2f31459c14e3133debcdf758ad8bbe57128d3bec2c907f2acf3
filesbetyangu.tar
9869871ed246d5670ebca02bb265a584f998f461db0283103ba58d4a650333be

Lock it up! New hardware protections for your lock screen with the Google Pixel 2


The new Google Pixel 2 ships with a dedicated hardware security module designed to be robust against physical attacks. This hardware module performs lockscreen passcode verification and protects your lock screen better than software alone.

To learn more about the new protections, let’s first review the role of the lock screen. Enabling a lock screen protects your data, not just against casual thieves, but also against sophisticated attacks. Many Android devices, including all Pixel phones, use your lockscreen passcode to derive the key that is then used to encrypt your data. Before you unlock your phone for the first time after a reboot, an attacker cannot recover the key (and hence your data) without knowing your passcode first. To protect against brute-force guessing your passcode, devices running Android 7.0+ verify your attempts in a secure environment that limits how often you can repeatedly guess. Only when the secure environment has successfully verified your passcode does it reveal a device and user-specific secret used to derive the disk encryption key.

Benefits of tamper-resistant hardware

The goal of these protections is to prevent attackers from decrypting your data without knowing your passcode, but the protections are only as strong as the secure environment that verifies the passcode. Performing these types of security-critical operations in tamper-resistant hardware significantly increases the difficulty of attacking it.
Tamper-resistant hardware comes in the form of a discrete chip separate from the System on a Chip (SoC). It includes its own flash, RAM, and other resources inside a single package, so it can fully control its own execution. It can also detect and defend against outside attempts to physically tamper with it.

In particular:
  • Because it has its own dedicated RAM, it’s robust against many side-channel information leakage attacks, such as those described in the TruSpy cache side-channel paper.
  • Because it has its own dedicated flash, it’s harder to interfere with its ability to store state persistently.
  • It loads its operating system and software directly from internal ROM and flash, and it controls all updates to it, so attackers can’t directly tamper with its software to inject malicious code.
  • Tamper-resistant hardware is resilient against many physical fault injection techniques including attempts to run outside normal operating conditions, such as wrong voltage, wrong clock speed, or wrong temperature. This is standardized in specifications such as the SmartCard IC Platform Protection Profile, and tamper-resistant hardware is often certified to these standards.
  • Tamper-resistant hardware is usually housed in a package that is resistant to physical penetration and designed to resist side channel attacks, including power analysis, timing analysis, and electromagnetic sniffing, such as described in the SoC it to EM paper.
Security module in Pixel 2

The new Google Pixel 2 ships with a security module built using tamper-resistant hardware that protects your lock screen and your data against many sophisticated hardware attacks.

In addition to all the benefits already mentioned, the security module in Pixel 2 also helps protect you against software-only attacks:
  • Because it performs very few functions, it has a super small attack surface.
  • With passcode verification happening in the security module, even in the event of a full compromise elsewhere, the attacker cannot derive your disk encryption key without compromising the security module first.
  • The security module is designed so that nobody, including Google, can update the passcode verification logic to a weakened version without knowing your passcode first.
Summary

Just like many other Google products, such as Chromebooks and Cloud, Android and Pixel are investing in additional hardware protections to make your device more secure. With the new Google Pixel 2, your data is safer against an entire class of sophisticated hardware attacks.

New research: Understanding the root cause of account takeover


Account takeover, or ‘hijacking’, is unfortunately a common problem for users across the web. More than 15% of Internet users have reported experiencing the takeover of an email or social networking account. However, despite its familiarity, there is a dearth of research about the root causes of hijacking.

With Google accounts as a case-study, we teamed up with the University of California, Berkeley to better understand how hijackers attempt to take over accounts in the wild. From March 2016 to March 2017, we analyzed several black markets to see how hijackers steal passwords and other sensitive data. We’ve highlighted some important findings from our investigation below. We presented our study at the Conference on Computer and Communications Security (CCS) and it’s now available here.

What we learned from the research proved to be immediately useful. We applied its insights to our existing protections and secured 67 million Google accounts before they were abused. We’re sharing this information publicly so that other online services can better secure their users, and can also supplement their authentication systems with more protections beyond just passwords.


How hijackers steal passwords on the black market

Our research tracked several black markets that traded third-party password breaches, as well as 25,000 blackhat tools used for phishing and keylogging. In total, these sources helped us identify 788,000 credentials stolen via keyloggers, 12 million credentials stolen via phishing, and 3.3 billion credentials exposed by third-party breaches.

While our study focused on Google, these password stealing tactics pose a risk to all account-based online services. In the case of third-party data breaches, 12% of the exposed records included a Gmail address serving as a username and a password; of those passwords, 7% were valid due to reuse. When it comes to phishing and keyloggers, attackers frequently target Google accounts to varying success: 12-25% of attacks yield a valid password.

However, because a password alone is rarely sufficient for gaining access to a Google account, increasingly sophisticated attackers also try to collect sensitive data that we may request when verifying an account holder’s identity. We found 82% of blackhat phishing tools and 74% of keyloggers attempted to collect a user’s IP address and location, while another 18% of tools collected phone numbers and device make and model.

By ranking the relative risk to users, we found that phishing posed the greatest threat, followed by keyloggers, and finally third-party breaches.

Protecting our users from account takeover

Our findings were clear: enterprising hijackers are constantly searching for, and are able to find, billions of different platforms’ usernames and passwords on black markets. While we have already applied these insights to our existing protections, our findings are yet another reminder that we must continuously evolve our defenses in order to stay ahead of these bad actors and keep users safe.

For many years, we’ve applied a ‘defense in-depth’ approach to security—a layered series of constantly improving protections that automatically prevent, detect, and mitigate threats to keep your account safe.

Prevention

A wide variety of safeguards help us to prevent attacks before they ever affect our users. For example, Safe Browsing, which now protects more than 3 billion devices, alerts users before they visit a dangerous site or when they click a link to a dangerous site within Gmail. We recently announced the Advanced Protection program which provides extra security for users that are at elevated risk of attack.

Detection

We monitor every login attempt to your account for suspicious activity. When there is a sign-in attempt from a device you’ve never used, or a location you don’t commonly access your account from, we’ll require additional information before granting access to your account. For example, if you sign in from a new laptop and you have a phone associated with you account, you will see a prompt—we’re calling these dynamic verification challenges—like this:
This challenge provides two-factor authentication on all suspicious logins, while mitigating the risk of account lockout.

Mitigation

Finally, we regularly scan activity across Google’s suite of products for suspicious actions performed by hijackers and when we find any, we lock down the affected accounts to prevent any further damage as quickly as possible. We prevent or undo actions we attribute to account takeover, notify the affected user, and help them change their password and re-secure their account into a healthy state.

What you can do

There are some simple steps you can take that make these defenses even stronger. Visit our Security Checkup to make sure you have recovery information associated with your account, like a phone number. Allow Chrome to automatically generate passwords for your accounts and save them via Smart Lock. We’re constantly working to improve these tools, and our automatic protections, to keep your data safe.

Introducing the Google Play Security Reward Program



We have long enjoyed a close relationship with the security research community. To recognize the valuable external contributions that help us keep our users safe online, we maintain reward programs for Google-developed websites and apps, for Chrome and Chrome OS, and for the latest version of Android running on Pixel devices. These programs have been a success and helped uncover hundreds of vulnerabilities, while also paying out millions of dollars to participating security researchers and research teams.

Today, we’re introducing the Google Play Security Reward Program to incentivize security research into popular Android apps available on Google Play. Through our collaboration with independent bug bounty platform, HackerOne, we’ll enable security researchers to submit an eligible vulnerability to participating developers, who are listed in the program rules. After the vulnerability is addressed, the eligible researcher submits a report to the Play Security Reward Program to receive a monetary reward from Google Play.

With the ongoing success of our other reward programs, we invite developers and the research community to work together with us on proactively improving the security of some of the most popular Android apps on Google Play.

The program is limited to a select number of developers at this time to get initial feedback. Developers can contact their Google Play partner manager to show interest. All developers will benefit when bugs are discovered because we will scan all apps for them and deliver security recommendations to the developers of any affected apps. For more information, visit the Play Security Reward Program on HackerOne.

Introducing the Google Play Security Reward Program



We have long enjoyed a close relationship with the security research community. To recognize the valuable external contributions that help us keep our users safe online, we maintain reward programs for Google-developed websites and apps, for Chrome and Chrome OS, and for the latest version of Android running on Pixel devices. These programs have been a success and helped uncover hundreds of vulnerabilities, while also paying out millions of dollars to participating security researchers and research teams.

Today, we’re introducing the Google Play Security Reward Program to incentivize security research into popular Android apps available on Google Play. Through our collaboration with independent bug bounty platform, HackerOne, we’ll enable security researchers to submit an eligible vulnerability to participating developers, who are listed in the program rules. After the vulnerability is addressed, the eligible researcher submits a report to the Play Security Reward Program to receive a monetary reward from Google Play.

With the ongoing success of our other reward programs, we invite developers and the research community to work together with us on proactively improving the security of some of the most popular Android apps on Google Play.

The program is limited to a select number of developers at this time to get initial feedback. Developers can contact their Google Play partner manager to show interest. All developers will benefit when bugs are discovered because we will scan all apps for them and deliver security recommendations to the developers of any affected apps. For more information, visit the Play Security Reward Program on HackerOne.

Behind the Masq: Yet more DNS, and DHCP, vulnerabilities



Our team has previously posted about DNS vulnerabilities and exploits. Lately, we’ve been busy reviewing the security of another DNS software package: Dnsmasq. We are writing this to disclose the issues we found and to publicize the patches in an effort to increase their uptake.

Dnsmasq provides functionality for serving DNS, DHCP, router advertisements and network boot. This software is commonly installed in systems as varied as desktop Linux distributions (like Ubuntu), home routers, and IoT devices. Dnsmasq is widely used both on the open internet and internally in private networks.

We discovered seven distinct issues (listed below) over the course of our regular internal security assessments. Once we determined the severity of these issues, we worked to investigate their impact and exploitability and then produced internal proofs of concept for each of them. We also worked with the maintainer of Dnsmasq, Simon Kelley, to produce appropriate patches and mitigate the issue.

These patches have been upstreamed and are now committed to the project’s git repository. In addition to these patches we have also submitted another patch which will run Dnsmasq under seccomp-bpf to allow for additional sandboxing. This patch has been submitted to the DNSmasq project for review and we have also made it available here for those who wish to integrate it into an existing install (after testing, of course!). We believe the adoption of this patch will increase the security of DNSMasq installations.

We would like to thank Simon Kelley for his help in patching these bugs in the core Dnsmasq codebase. Users who have deployed the latest version of Dnsmasq (2.78) will be protected from the attacks discovered here. Android partners have received this patch as well and it will be included in Android's monthly security update for October. Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod. Other affected Google services have been updated.

During our review, the team found three potential remote code executions, one information leak, and three denial of service vulnerabilities affecting the latest version at the project git server as of September 5th 2017.

CVE
Impact
Vector
Notes
PoC
CVE-2017-14491
RCE
DNS
Heap based overflow (2 bytes). Before 2.76 and this commit overflow was unrestricted.
CVE-2017-14492
RCE
DHCP
Heap based overflow.
CVE-2017-14493
RCE
DHCP
Stack Based overflow.
CVE-2017-14494
Information Leak
DHCP
Can help bypass ASLR.
CVE-2017-14495
OOM/DoS
DNS
Lack of free() here.
CVE-2017-14496
DoS
DNS
Invalid boundary checks here. Integer underflow leading to a huge memcpy.
CVE-2017-13704
DoS
DNS
Bug collision with CVE-2017-13704



It is worth expanding on some of these:

  • CVE-2017-14491 is a DNS-based vulnerability that affects both directly exposed and internal network setups. Although the latest git version only allows a 2-byte overflow, this could be exploited based on previous research. Before version 2.76 and this commit the overflow is unrestricted. 
==1159==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62200001dd0b at pc 0x0000005105e7 bp 0x7fff6165b9b0 sp0x7fff6165b9a8
WRITE of size 1 at 0x62200001dd0b thread T0
  #0 0x5105e6 in add_resource_record
/test/dnsmasq/src/rfc1035.c:1141:7
  #1 0x5127c8 in answer_request /test/dnsmasq/src/rfc1035.c:1428:11
  #2 0x534578 in receive_query /test/dnsmasq/src/forward.c:1439:11
  #3 0x548486 in check_dns_listeners 
/test/dnsmasq/src/dnsmasq.c:1565:2
  #4 0x5448b6 in main /test/dnsmasq/src/dnsmasq.c:1044:7
  #5 0x7fdf4b3972b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
  #6 0x41cbe9 in _start (/test/dnsmasq/src/dnsmasq+0x41cbe9)

  • CVE-2017-14493 is a trivial-to-exploit DHCP-based, stack-based buffer overflow vulnerability. In combination with CVE-2017-14494 acting as an info leak, an attacker could bypass ASLR and gain remote code execution.
dnsmasq[15714]: segfault at 1337deadbeef ip 00001337deadbeef sp 00007fff1b66fd10 error 14 in libnss_files-2.24.so[7f7cfbacb000+a000]
  • Android is affected by CVE-2017-14496 when the attacker is local or tethered directly to the device—the service itself is sandboxed so the risk is reduced. Android partners received patches on 5 September 2017 and devices with a 2017-10-01 security patch level or later address this issue.
Proofs of concept are provided so you can check if you are affected by these issues, and verify any mitigations you may deploy.


We would like to thank the following people for discovering, investigating impact/exploitability and developing PoCs: Felix Wilhelm, Fermin J. Serna, Gabriel Campana, Kevin Hamacher, Ron Bowes and Gynvael Coldwind of the Google Security Team.

From Chrysaor to Lipizzan: Blocking a new targeted spyware family



Android Security is always developing new ways of using data to find and block potentially harmful apps (PHAs) from getting onto your devices. Earlier this year, we announced we had blocked Chrysaor targeted spyware, believed to be written by NSO Group, a cyber arms company. In the course of our Chrysaor investigation, we used similar techniques to discover a new and unrelated family of spyware called Lipizzan. Lipizzan’s code contains references to a cyber arms company, Equus Technologies.

Lipizzan is a multi-stage spyware product capable of monitoring and exfiltrating a user’s email, SMS messages, location, voice calls, and media. We have found 20 Lipizzan apps distributed in a targeted fashion to fewer than 100 devices in total and have blocked the developers and apps from the Android ecosystem. Google Play Protect has notified all affected devices and removed the Lipizzan apps.

We’ve enhanced Google Play Protect’s capabilities to detect the targeted spyware used here and will continue to use this framework to block more targeted spyware. To learn more about the methods Google uses to find targeted mobile spyware like Chrysaor and Lipizzan, attend our BlackHat talk, Fighting Targeted Malware in the Mobile Ecosystem.

How does Lipizzan work?

Getting on a target device

Lipizzan was a sophisticated two stage spyware tool. The first stage found by Google Play Protect was distributed through several channels, including Google Play, and typically impersonated an innocuous-sounding app such as a "Backup” or “Cleaner” app. Upon installation, Lipizzan would download and load a second "license verification" stage, which would survey the infected device and validate certain abort criteria. If given the all-clear, the second stage would then root the device with known exploits and begin to exfiltrate device data to a Command & Control server.

Once implanted on a target device

The Lipizzan second stage was capable of performing and exfiltrating the results of the following tasks:

  • Call recording
  • VOIP recording
  • Recording from the device microphone
  • Location monitoring
  • Taking screenshots
  • Taking photos with the device camera(s)
  • Fetching device information and files
  • Fetching user information (contacts, call logs, SMS, application-specific data)


The PHA had specific routines to retrieve data from each of the following apps:

  • Gmail
  • Hangouts
  • KakaoTalk
  • LinkedIn
  • Messenger
  • Skype
  • Snapchat
  • StockEmail
  • Telegram
  • Threema
  • Viber
  • Whatsapp

We saw all of this behavior on a standalone stage 2 app, com.android.mediaserver (not related to Android MediaServer). This app shared a signing certificate with one of the stage 1 applications, com.app.instantbackup, indicating the same author wrote the two. We could use the following code snippet from the 2nd stage (com.android.mediaserver) to draw ties to the stage 1 applications.



Morphing first stage

After we blocked the first set of apps on Google Play, new apps were uploaded with a similar format but had a couple of differences.

The apps changed from ‘backup’ apps to looking like a “cleaner”, “notepad”, “sound recorder”, and “alarm manager” app. The new apps were uploaded within a week of the takedown, showing that the authors have a method of easily changing the branding of the implant apps.
The app changed from downloading an unencrypted stage 2 to including stage 2 as an encrypted blob. The new stage 1 would only decrypt and load the 2nd stage if it received an intent with an AES key and IV.

Despite changing the type of app and the method to download stage 2, we were able to catch the new implant apps soon after upload.

How many devices were affected?

There were fewer than 100 devices that checked into Google Play Protect with the apps listed below. That means the family affected only 0.000007% of Android devices. Since we identified Lipizzan, Google Play Protect removed Lipizzan from affected devices and actively blocks installs on new devices.

What can you do to protect yourself?




  • Ensure you are opted into Google Play Protect
  • Exclusively use the Google Play store. The chance you will install a PHA is much lower on Google Play than using other install mechanisms.
  • Keep “unknown sources” disabled while not using it.
  • Keep your phone patched to the latest Android security update.


List of samples

1st stage



Newer version 


Standalone 2nd stage



Final removal of trust in WoSign and StartCom Certificates



As previously announced, Chrome has been in the process of removing trust from certificates issued by the CA WoSign and its subsidiary StartCom, as a result of several incidents not in keeping with the high standards expected of CAs.

We started the phase out in Chrome 56 by only trusting certificates issued prior to October 21st 2016, and subsequently restricted trust to a set of whitelisted hostnames based on the Alexa Top 1M. We have been reducing the size of the whitelist over the course of several Chrome releases.

Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and StartCom root certificates and all certificates they have issued.

Based on the Chromium Development Calendar, this change is visible in the Chrome Dev channel now, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

Sites still using StartCom or WoSign-issued certificates should consider replacing these certificates as a matter of urgency to minimize disruption for Chrome users.