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:

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.

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.

Posted by Martin Pelikan, Giles Hogben, and Ulfar Erlingsson of Google’s Security and Privacy team
Mobile apps entertain and assist us, make it easy to communicate with friends and family, and provide tools ranging from maps to electronic wallets. But these apps could also seek more device information than they need to do their job, such as personal data and sensor data from components, like cameras and GPS trackers.

To protect our users and help developers navigate this complex environment, Google analyzes privacy and security signals for each app in Google Play. We then compare that app to other apps with similar features, known as functional peers. Creating peer groups allows us to calibrate our estimates of users’ expectations and set adequate boundaries of behaviors that may be considered unsafe or intrusive. This process helps detect apps that collect or send sensitive data without a clear need, and makes it easier for users to find apps that provide the right functionality and respect their privacy. For example, most coloring book apps don’t need to know a user’s precise location to function and this can be established by analyzing other coloring book apps. By contrast, mapping and navigation apps need to know a user’s location, and often require GPS sensor access.

One way to create app peer groups is to create a fixed set of categories and then assign each app into one or more categories, such as tools, productivity, and games. However, fixed categories are too coarse and inflexible to capture and track the many distinctions in the rapidly changing set of mobile apps. Manual curation and maintenance of such categories is also a tedious and error-prone task.

To address this, Google developed a machine-learning algorithm for clustering mobile apps with similar capabilities. Our approach uses deep learning of vector embeddings to identify peer groups of apps with similar functionality, using app metadata, such as text descriptions, and user metrics, such as installs. Then peer groups are used to identify anomalous, potentially harmful signals related to privacy and security, from each app’s requested permissions and its observed behaviors. The correlation between different peer groups and their security signals helps different teams at Google decide which apps to promote and determine which apps deserve a more careful look by our security and privacy experts. We also use the result to help app developers improve the privacy and security of their apps.

Apps are split into groups of similar functionality, and in each cluster of similar apps the established baseline is used to find anomalous privacy and security signals.

Posted by Wei Liu, Product Manager, reCAPTCHA
When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.

By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.

reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it’s important to keep the mobile applications and data safe. Today, on reCAPTCHA’s tenth birthday, we’re glad to announce the first reCAPTCHA Android API as part of Google Play Services.

With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.

reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.

The journey of reCAPTCHA continues: we’ll make the Internet safer and easier to use for everyone (except bots).

On 00:00:01 UTC of June 17th and 18th, 2017 we’ll be hosting the online qualification round of our second annual Capture The Flag (CTF) competition. In a ‘Capture the Flag’ competition we create security challenges and puzzles in which contestants can earn points for solving them. We will be inviting the top 10 finalist teams to a secret undisclosed location (spoiler alert: it’s Google) to compete onsite for a prize pool of over USD$31,337 and we’ll help subsidize travel to the venue for the finals to four participants for each of the ten finalist teams. In addition to grand prizes given at the finals, we’ll be rewarding some of the best and creative write-ups that we receive during the qualifying round. We want to give you an opportunity to share with the world the clever way you solve challenges.Why do we host these competitions?
There are three main reasons why we host these competitions.

First, as we've seen with our Vulnerability Reward Program, the security community’s efforts help us better protect Google users, and the web as a whole. We’d like to give the people who solve a single challenge or two in a very clever way a chance to teach us and the security community, even if they don’t qualify for the finals. We also think that these challenges allows us to share with the world the types of problems our security team works on every day.

Second, we want to engage the broader security community and reach out to as many people involved as possible. At the Google CTF last year the winning team, ‘Pasten’ from Israel, earned over 4,700 points competing against 2,400 teams out of which 900 were able to solve at least one of our challenges. Thanks to the community's feedback, we used what we learned last year to make our CTF even better this time.

Lastly, we also want to grow the security community. Upon observing how last year's competition engaged new players from all over the world, we want to continue to create a safe space for people to come and learn while trying to solve challenges and having fun. Our internal security team employs several people who actively compete in CTF competitions in their spare time, so we value this activity and want to give back to and help grow our community.

We hope to virtually see you at the 2nd annual Google CTF on June 17th at 00:00:01 UTC. Check this site (g.co/ctf) for more details, as they become available.The Big Picture
At Google, we aim to reward the hard work of hackers and security researchers. One such avenue is our Google Vulnerability Rewards Programs. Many of the best bug hunters enjoy participating in ‘Capture The Flag’ contests, and great vulnerabilities have been discovered and disclosed at them. During last year's Google CTF we also received some security bug reports in our scoreboard, for which we gave out rewards under the VRP. Another way we reward this community is with our Vulnerability Research Grants Program and our Patch Rewards Program. We look forward to the best contestants taking some time to explore our other programs for opportunities to make some money and help improve the security of the internet.

Two years ago, we launched the Android Security Rewards program. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.

Here are some of the highlights from the Android Security Rewards program's second year:

There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise, our highest award amount possible.

We paid 115 individuals with an average of $2,150 per reward and $10,209 per researcher.

We paid our top research team, C0RE Team, over $300,000 for 118 vulnerability reports.

We’re constantly working to improve the Android Security Rewards program and today we’re making a few changes to all vulnerability reports filed after June 1, 2017.

Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we’re excited to increase our top-line payouts for these exploits.

Rewards for a remote exploit chain or exploit leading to TrustZone or Verified Boot compromise increase from $50,000 to $200,000.

Rewards for a remote kernel exploit increase from $30,000 to $150,000.

In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly security updates. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:

Source: Google, May 29, 2017Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed Program Rules. For tips on how to submit complete reports, see Bug Hunter University.

Posted by Sri Somanchi, Product Manager, Gmail anti-spam
Today we announced new security features for Gmail customers, including early phishing detection using machine learning, click-time warnings for malicious links, and unintended external reply warnings. In addition, we have also updated our defenses against malicious attachments.

Let’s take a deeper look at the new defenses against malicious attachments. We now correlate spam signals with attachment and sender heuristics, to predict messages containing new and unseen malware variants. These protections enable Gmail to better protect our users from zero-day threats, ransomware and polymorphic malware.

In addition, we block use of file types that carry a high potential for security risks including executable and javascript files.

Machine learning has helped Gmail achieve more than 99% accuracy in spam detection, and with these new protections, we’re able to reduce your exposure to threats by confidently rejecting hundreds of millions of additional messages every day.Constantly improving our automatic protections

These new changes are just the latest in our ongoing work to improve our protections as we work to keep ahead of evolving threats. For many years, scammers have tried to use dodgy email attachments to sneak past our spam filters, and we’ve long blocked this potential abuse in a variety of ways, including:

Rejecting the message and notifying the sender if we detect a virus in an email.

Five months ago, we announcedOSS-Fuzz, Google’s effort to help make open source software more secure and stable. Since then, our robot army has been working hard at fuzzing, processing 10 trillion test inputs a day. Thanks to the efforts of the open source community who have integrated a total of 47 projects, we’ve found over 1,000 bugs (264 of which are potential security vulnerabilities).

Breakdown of the types of bugs we’re finding

Notable results

OSS-Fuzz has found numerous security vulnerabilities in several critical open source projects: 10 in FreeType2, 17 in FFmpeg, 33 in LibreOffice, 8 in SQLite 3, 10 in GnuTLS, 25 in PCRE2, 9 in gRPC, and 7 in Wireshark. We’ve also had at least one bug collision with another independent security researcher (CVE-2017-2801). (Some of the bugs are still view-restricted so links may show smaller numbers.)

Once a project is integrated into OSS-Fuzz, the continuous and automated nature of OSS-Fuzz means that we often catch these issues just hours after the regression is introduced into the upstream repository, so that the chances of users being affected is reduced.

Fuzzing not only finds memory safety related bugs, it can also find correctness or logic bugs. One example is a carry propagating bug in OpenSSL (CVE-2017-3732).

Finally, OSS-Fuzz has reported over 300 timeout and out-of-memory failures (~75% of which got fixed). Not every project treats these as bugs, but fixing them enables OSS-Fuzz to find more interesting bugs.

Announcing rewards for open source projects

We believe that user and internet security as a whole can benefit greatly if more open source projects include fuzzing in their development process. To this end, we’d like to encourage more projects to participate and adopt the ideal integration guidelines that we’ve established.

Combined with fixing all the issues that are found, this is often a significant amount of work for developers who may be working on an open source project in their spare time. To support these projects, we are expanding our existing Patch Rewards program to include rewards for the integration of fuzz targets into OSS-Fuzz.

To qualify for these rewards, a project needs to have a large user base and/or be critical to global IT infrastructure. Eligible projects will receive $1,000 for initial integration, and up to $20,000 for ideal integration (the final amount is at our discretion). You have the option of donating these rewards to charity instead, and Google will double the amount.

To qualify for the ideal integration reward, projects must show that:

Fuzz targets are checked into their upstream repository and integrated in the build system with sanitizer support (up to $5,000).

Fuzz targets are efficient and provide good code coverage (>80%) (up to $5,000).

Fuzz targets are part of the official upstream development and regression testing process, i.e. they are maintained, run against old known crashers and the periodically updated corpora (up to $5,000).

The last $5,000 is a “l33t” bonus that we may reward at our discretion for projects that we feel have gone the extra mile or done something really awesome.

We’ve already started to contact the first round of projects that are eligible for the initial reward. If you are the maintainer or point of contact for one of these projects, you may also reach out to us in order to apply for our ideal integration rewards.

The future

We’d like to thank the existing contributors who integrated their projects and fixed countless bugs. We hope to see more projects integrated into OSS-Fuzz, and greater adoption of fuzzing as standard practice when developing software.

As many email users know, phishing attacks—or emails that impersonate a trusted source to trick users into sharing information—are a pervasive problem. If you use Gmail, you can rest assured that every day, millions of phishing emails are blocked from ever reaching your inbox.

This week, we defended against an email phishing campaign that tricked some of our users into inadvertently granting access to their contact information, with the intent to spread more phishing emails. We took quick action to revoke all access granted to the attacker as well as steps to reduce and prevent harm from future variants of this type of attack.

Here’s some background to help you understand how the campaign worked, how we addressed it, and how you can better protect yourself against attacks.

How the campaign worked and how we addressed it

Victims of this attack received an email that appeared to be an invite to a Google Doc from one of their contacts. When users clicked the link in the attacker’s email, it directed them to the attacker’s application, which requested access to the user’s account under the false pretense of gaining access to the Google Doc. If the user authorized access to the application (through a mechanism called OAuth), it used the user's contact list to send the same message to more people.

Upon detecting this issue, we immediately responded with a combination of automatic and manual actions that ended this campaign within an hour. We removed fake pages and applications, and pushed user-protection updates through Safe Browsing, Gmail, Google Cloud Platform, and other counter-abuse systems. Fewer than 0.1% of our users were affected by this attack, and we have taken steps to re-secure affected accounts.

We protect our users from phishing attacks in a number of ways, including:

Using machine learning-based detection of spam and phishing messages, which has contributed to 99.9% accuracy in spam detection.

Providing Safe Browsing warnings about dangerous links, within Gmail and across more than 2 billion browsers.

In addition, we’re taking multiple steps to combat this type of attack in the future, including updating our policies and enforcement on OAuth applications, updating our anti-spam systems to help prevent campaigns like this one, and augmenting monitoring of suspicious third-party apps that request information from our users.

How users can protect themselves

We’re committed to keeping your Google Account safe, and have layers of defense in place to guard against sophisticated attacks of all types, from anti-hijacking systems detecting unusual behavior, to machine learning models that block malicious content, to protection measures in Chrome and through Safe Browsing that guard against visiting suspicious sites. In addition, here are a few ways users can further protect themselves:

Take the Google Security Checkup, paying particular attention to any applications or devices you no longer use, as well as any unrecognized devices.

We’ve separately notified G Suite customers whose users were tricked into granting OAuth access. While no further admin or user action is required for this incident, if you are a G Suite admin, consider the following best practices to generally improve security:

In January, we began our quest to improve how Chrome communicates the connection security of HTTP pages. Chrome now marks HTTP pages as “Not secure” if they have password or credit card fields. Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.

Treatment of HTTP pages in Chrome 62

Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we’re ready to take the next steps.

Passwords and credit cards are not the only types of data that should be private. Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the “Not secure” warning when users type data into HTTP sites.

Treatment of HTTP pages with user-entered data in Chrome 62

When users browse Chrome with Incognito mode, they likely have increased expectations of privacy. However, HTTP browsing is not private to others on the network, so in version 62 Chrome will also warn users when visiting an HTTP page in Incognito mode.

Eventually, we plan to show the “Not secure” warning for all HTTP pages, even outside Incognito mode. We will publish updates as we approach future releases, but don’t wait to get started moving to HTTPS! HTTPS is easier and cheaper than ever before, and it enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.