The latest news and insights from Google on security and safety on the Internet
OSS-Fuzz: Five months later, and rewarding projects
May 8, 2017
Posted by Oliver Chang, Abhishek Arya (Security Engineers, Chrome Security), Kostya Serebryany (Software Engineer, Dynamic Tools), and Josh Armour (Security Program Manager)
Five months ago, we
, Google’s effort to help make open source software more secure and stable. Since then, our robot army has been working hard at
, processing 10 trillion test inputs a day. Thanks to the efforts of the open source community who have integrated a total of
projects, we’ve found over
of which are potential security vulnerabilities).
Breakdown of the types of bugs we’re finding
OSS-Fuzz has found numerous security vulnerabilities in several critical open source projects:
in SQLite 3,
in gRPC, and
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 (
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
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
program to include rewards for the integration of
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
support (up to $5,000).
Fuzz targets are
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
(up to $5,000).
The last $5,000 is a “
” 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
to us in order to apply for our ideal integration rewards.
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.
Protecting You Against Phishing
May 5, 2017
Posted by Mark Risher, Director, Counter Abuse Technology
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
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.
warnings about dangerous links, within Gmail and across more than 2 billion browsers.
Preventing suspicious account sign-ins through dynamic, risk-based challenges.
Scanning email attachments for malware and other dangerous payloads.
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:
Google Security Checkup
, paying particular attention to any applications or devices you no longer use, as well as any unrecognized devices.
Pay attention to
warnings and alerts
that appear in Gmail and other products.
How G Suite admins can protect their users
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:
Review and verify current
OAuth API access by third-parties
OAuth Token audit log reports
to catch future inadvertent scope grants and set up automated email alerts in the Admin console using the
custom alerts feature
, or script it with the
Turn on 2-step verification for your organization and use
if you feel that an account may be compromised.
Help prevent abuse of your brand in phishing attacks by publishing a
policy for your organization.
and enforce rules for
Here is a list of more
tips and tools
to help you stay secure on the web.
Next Steps Toward More Connection Security
April 27, 2017
Posted by Emily Schechter, Chrome Security Team
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
Treatment of HTTP pages in Chrome 62
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
to get started.
New Research: Keeping fake listings off Google Maps
April 6, 2017
Posted by Doug Grundman, Maps Anti-Abuse, and Kurt Thomas, Security & Anti-Abuse Research
Google My Business
enables millions of business owners to create listings and share information about their business on Google Maps and Search, making sure everything is up-to-date and accurate for their customers. Unfortunately, some actors attempt to abuse this service to register fake listings in order to defraud legitimate business owners, or to
charge exorbitant service fees for services
Over a year ago, we teamed up with the University of California, San Diego to research the actors behind fake listings, in order to improve our products and keep our users safe. The full report,
“Pinning Down Abuse on Google Maps”
, will be presented tomorrow at the 2017
International World Wide Web Conference
Our study shows that fewer than 0.5% of local searches lead to fake listings. We’ve also improved how we verify new businesses, which has reduced the number of fake listings by 70% from its all-time peak back in June 2015.
What is a fake listing?
For over a year, we tracked the bad actors behind fake listings. Unlike email-based scams
selling knock-off products online
, local listing scams require physical proximity to potential victims. This fundamentally changes both the scale and types of abuse possible.
Bad actors posing as locksmiths, plumbers, electricians, and other contractors were the most common source of abuse—roughly 2 out of 5 fake listings. The actors operating these fake listings would cycle through non-existent postal addresses and disposable VoIP phone numbers even as their listings were discovered and disabled. The purported addresses for these businesses were irrelevant as the contractors would travel directly to potential victims.
Another 1 in 10 fake listings belonged to real businesses that bad actors had improperly claimed ownership over, such as hotels and restaurants. While making a reservation or ordering a meal was indistinguishable from the real thing, behind the scenes, the bad actors would deceive the actual business into paying referral fees for organic interest.
How does Google My Business verify information?
Google My Business currently verifies the information provided by business owners before making it available to users. For freshly created listings, we physically mail a postcard to the new listings’ address to ensure the location really exists. For businesses changing owners, we make an automated call to the listing’s phone number to verify the change.
Unfortunately, our research showed that these processes can be abused to get fake listings on Google Maps. Fake contractors would request hundreds of postcard verifications to non-existent suites at a single address, such as 123 Main St #456 and 123 Main St #789, or to stores that provided PO boxes. Alternatively, a phishing attack could maliciously repurpose freshly verified business listings by tricking the legitimate owner into sharing verification information sent either by phone or postcard.
Keeping deceptive businesses out — by the numbers
Leveraging our study’s findings, we’ve made significant changes to how we verify addresses and are even
piloting an advanced verification process
for locksmiths and plumbers. Improvements we’ve made include prohibiting bulk registrations at most addresses, preventing businesses from relocating impossibly far from their original address without additional verification, and detecting and ignoring intentionally mangled text in address fields designed to confuse our algorithms. We have also adapted our anti-spam machine learning systems to detect data discrepancies common to fake or deceptive listings.
Combined, here’s how these defenses stack up:
We detect and disable 85% of fake listings before they even appear on Google Maps.
We’ve reduced the number of abusive listings by 70% from its peak back in June 2015.
We’ve also reduced the number of impressions to abusive listings by 70%.
As we’ve shown, verifying local information comes with a number of unique anti-abuse challenges. While fake listings may slip through our defenses from time to time, we are constantly improving our systems to better serve both users and business owners.
An Investigation of Chrysaor Malware on Android
April 3, 2017
Posted by Rich Cannings, Jason Woloz, Neel Mehta, Ken Bodzak, Wentao Chang, Megan Ruthven
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 one or a very small number of devices. This is known as a
In this blog post, we describe Chrysaor, a newly discovered family of spyware that was used in a targeted attack on a small number of Android devices, and how investigations like this help Google protect Android users from a variety of threats.
What is Chrysaor?
Chrysaor is spyware believed to be created by
NSO Group Technologies
, specializing in the creation and sale of software and infrastructure for targeted attacks. Chrysaor is believed to be related to the Pegasus spyware that was
first identified on iOS
and analyzed by
Late last year, after receiving a list of suspicious package names from Lookout, we discovered that a few dozen Android devices may have installed an application related to Pegasus, which we named Chrysaor. Although the applications were never available in Google Play, we immediately identified the scope of the problem by using
. We gathered information from affected devices, and concurrently, attempted to acquire Chrysaor apps to better understand its impact on users. We’ve contacted the potentially affected users, disabled the applications on affected devices, and implemented changes in Verify Apps to protect all users.
What is the scope of Chrysaor?
Chrysaor was never available in Google Play and had a very low volume of installs outside of Google Play. Among the over 1.4 billion devices protected by Verify Apps, we observed fewer than 3 dozen installs of Chrysaor on victim devices. These devices were located in the following countries:
How we protect you
To protect Android devices and users, Google Play provides a complete set of security services that update outside of platform releases. Users don’t have to install any additional security services to keep their devices safe. In 2016, these services protected over 1.4 billion devices, making Google one of the largest providers of on-device security services in the world:
using people, systems in the cloud, and data sent to us from devices
Warn users about or blocking users from installing PHAs
Continually scan devices for PHAs and other harmful threats
Additionally, we are providing detailed technical information to help the security industry in our collective work against PHAs.
What do I need to do?
It is extremely unlikely you or someone you know was affected by Chrysaor malware. Through our investigation, we identified less than 3 dozen devices affected by Chrysaor, we have disabled Chrysaor on those devices, and we have notified users of all known affected devices. Additionally, the improvements we made to our protections have been enabled for all users of our security services.
To ensure you are fully protected against PHAs and other threats, we recommend these 5 basic steps:
Install apps only from reputable sources:
Install apps from a reputable source, such as
. No Chrysaor apps were on Google Play.
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.
Ensure Verify Apps is enabled.
Locate your device:
Practice finding your device with
Android Device Manager
because you are far more likely to lose your device than install a PHA.
How does Chrysaor work?
To install Chrysaor, we believe an attacker coaxed specifically targeted individuals to download the malicious software onto their device. Once Chrysaor is installed, a remote operator is able to surveil the victim’s activities on the device and within the vicinity, leveraging microphone, camera, data collection, and logging and tracking application activities on communication apps such as phone and SMS.
One representative sample Chrysaor app that we analyzed was tailored to devices running Jellybean (4.3) or earlier. The following is a review of scope and impact of the Chrysaor app named com.network.android tailored for a Samsung device target, with SHA256 digest:
Upon installation, the app uses known framaroot exploits to escalate privileges and break Android’s application sandbox. If the targeted device is not vulnerable to these exploits, then the app attempts to use a superuser binary pre-positioned at /system/csk to elevate privileges.
After escalating privileges, the app immediately protects itself and starts to collect data, by:
Installing itself on the /system partition to persist across factory resets
Removing Samsung’s system update app (com.sec.android.fotaclient) and disabling auto-updates to maintain persistence (sets Settings.System.SOFTWARE_UPDATE_AUTO_UPDATE to 0)
Deleting WAP push messages and changing WAP message settings, possibly for anti-forensic purpose.
Starting content observers and the main task loop to receive remote commands and exfiltrate data.
The app uses six techniques to collect user data:
use alarms to periodically repeat actions on the device to expose data, including gathering location data.
dump all existing content on the device into a queue. Data collectors are used in conjunction with repeated commands to collect user data including, SMS settings, SMS messages, Call logs, Browser History, Calendar, Contacts, Emails, and messages from selected messaging apps, including WhatsApp, Twitter, Facebook, Kakoa, Viber, and Skype by making /data/data directories of the apps world readable.
framework to gather changes in SMS, Calendar, Contacts, Cell info, Email, WhatsApp, Facebook, Twitter, Kakao, Viber, and Skype.
captures an image of the current screen via the raw frame buffer.
record input events by hooking
IPCThreadState::Transact from /system/lib/libbinder.so, and intercepting android::parcel with the interface com.android.internal.view.IInputContext.
silently answers a telephone call and stays connected in the background, allowing the caller to hear conversations within the range of the phone's microphone. If the user unlocks their device, they will see a black screen while the app drops the call, resets call settings and prepares for the user to interact with the device normally.
Finally, the app can remove itself through three ways:
Via a command from the server
Autoremove if the device has not been able to check in to the server after 60 days
Via an antidote file. If /sdcard/MemosForNotes was present on the device, the Chrysaor app removes itself from the device.
Samples uploaded to VirusTotal
To encourage further research in the security community, we’ve uploaded these sample Chrysaor apps to Virus Total.
Additional digests with links to Chrysaor
As a result of our investigation we have identified these additional Chrysaor-related apps.
Lookout has completed their own independent analysis of the samples we acquired, their report can be viewed
Updates to the Google Safe Browsing’s Site Status Tool
March 29, 2017
Posted Deeksha Padma Prasad and Allison Miller, Safe Browsing
Google Safe Browsing
gives users tools to help protect themselves from web-based threats like malware, unwanted software, and social engineering. We are best known for our warnings, which users see when they attempt to navigate to dangerous sites or download dangerous files. We also provide other tools, like the
Site Status Tool
, where people can check the current safety status of a web page (without having to visit it).
We host this tool within Google’s
Safe Browsing Transparency Report
. As with other sections in Google’s
we make this data available to give the public more visibility into the security and health of the online ecosystem. Users of the
Site Status Tool
input a webpage (as a URL, website, or domain) into the tool, and the most recent results of the Safe Browsing analysis for that webpage are returned...plus references to troubleshooting help and educational materials.
We’ve just launched a new version of the
Site Status Tool
that provides simpler, clearer results and is better designed for the primary users of the page: people who are visiting the tool from a Safe Browsing warning they’ve received, or doing casual research on Google’s malware and phishing detection. The tool now features a cleaner UI, easier-to-interpret language, and more precise results. We’ve also moved some of the more technical data on associated ASes (autonomous systems) over to the
malware dashboard section of the report
While the interface has been streamlined, additional diagnostic information is not gone: researchers who wish to find more details can drill-down elsewhere in
Safe Browsing’s Transparency Report
, while site-owners can find additional diagnostic information in
. One of the goals of the Transparency Report is to shed light on complex policy and security issues, so, we hope the design adjustments will indeed provide our users with additional clarity.
Reassuring our users about government-backed attack warnings
March 24, 2017
Posted by Shane Huntley, Google Threat Analysis Group
, we’ve warned our users if we believe their Google accounts are being targeted by government-backed attackers.
We send these out of an abundance of caution — the notice does not necessarily mean that the account has been compromised or that there is a widespread attack. Rather, the notice reflects our assessment that a government-backed attacker has likely attempted to access the user’s account or computer through phishing or malware, for example. You can read more about these warnings
In order to secure some of the details of our detection, we often send a batch of warnings to groups of at-risk users at the same time, and not necessarily in real-time. Additionally, we never indicate which government-backed attackers we think are responsible for the attempts; different users may be targeted by different attackers.
Security has always been a top priority for us. Robust, automated protections help prevent scammers from signing into your Google account,
Gmail always uses an encrypted connection
when you receive or send email, we filter more than
99.9% of spam
— a common source of phishing messages — from Gmail, and we show users when messages are from an
unverified or unencrypted source
An extremely small fraction of users will ever see one of these warnings, but if you receive this warning from us, it's important to
take action on it
. You can always take a two-minute
, and for
maximum protection from phishing
, enable two-step verification with a Security Key.
Diverse protections for a diverse ecosystem: Android Security 2016 Year in Review
March 22, 2017
Posted by Adrian Ludwig & Mel Miller, Android Security Team
Today, we’re sharing the third annual Android Security Year In Review, a comprehensive look at our work to protect more than 1.4 billion Android users and their data.
Our goal is simple: keep users safe. In 2016, we improved our abilities to stop dangerous apps, built new security features into Android 7.0 Nougat, and collaborated with device manufacturers, researchers, and other members of the Android ecosystem. For more details, you can read the
full Year in Review report
or watch our
Protecting users from PHAs
It’s critical to keep people safe from
Potentially Harmful Apps (PHAs)
that may put their data or devices at risk. Our ongoing work in this area requires us to find ways to track and stop existing PHAs, and anticipate new ones that haven’t even emerged yet.
Over the years, we’ve built a variety of systems to address these threats, such as application analyzers that constantly review apps for unsafe behavior, and Verify Apps which regularly checks users’ devices for PHAs. When these systems detect PHAs, we warn users, suggest they think twice about downloading a particular app, or even remove the app from their devices entirely.
We constantly monitor threats and improve our systems over time. Last year’s data reflected those improvements: Verify Apps conducted 750 million daily checks in 2016, up from 450 million the previous year, enabling us to reduce the PHA installation rate in the top 50 countries for Android usage.
Google Play continues to be the safest place for Android users to download their apps. Installs of PHAs from Google Play decreased in nearly every category:
Now 0.016 percent of installs, trojans dropped by 51.5 percent compared to 2015
Now 0.003 percent of installs, hostile downloaders dropped by 54.6 percent compared to 2015
Now 0.003 percent of installs, backdoors dropped by 30.5 percent compared to 2015
Now 0.0018 percent of installs, phishing apps dropped by 73.4 percent compared to 2015
By the end of 2016, only 0.05 percent of devices that downloaded apps exclusively from Play contained a PHA; down from 0.15 percent in 2015.
Still, there’s more work to do for devices overall, especially those that install apps from multiple sources. While only 0.71 percent of all Android devices had PHAs installed at the end of 2016, that was a slight increase from about 0.5 percent in the beginning of 2015. Using improved tools and the knowledge we gained in 2016, we think we can reduce the number of devices affected by PHAs in 2017, no matter where people get their apps.
New security protections in Nougat
Last year, we introduced a
variety of new protections in Nougat
, and continued our ongoing work to
strengthen the security of the Linux Kernel
: In Nougat, we introduced file-based encryption which enables each user profile on a single device to be encrypted with a unique key. If you have personal and work accounts on the same device, for example, the key from one account can’t unlock data from the other. More broadly, encryption of user data has been required for capable Android devices since in late 2014, and we now see that feature enabled on over 80 percent of Android Nougat devices.
New audio and video protections
: We did significant work to
improve security and re-architect
how Android handles video and audio media. One example: we now store different media components into individual sandboxes, where previously they lived together. Now, if one component is compromised, it doesn’t automatically have permissions to other components, which helps contain any additional issues.
Even more security for enterprise users
: We introduced a
variety of new enterprise security features
including “Always On” VPN, which protects your data from the moment your device boots up and ensures it isn't traveling from a work phone to your personal device via an insecure connection. We also added security policy transparency, process logging, improved wifi certification handling, and client certification improvements to our
growing set of enterprise tools
Working together to secure the Android ecosystem.
Sharing information about security threats between Google, device manufacturers, the research community, and others helps keep all Android users safer. In 2016, our biggest collaborations were via our monthly security updates program and ongoing partnership with the security research community.
Security updates are regularly highlighted as a pillar of mobile security—and rightly so. We
launched our monthly security updates program
in 2015, following the public disclosure of a bug in Stagefright, to help accelerate patching security vulnerabilities across devices from many different device makers. This program expanded significantly in 2016:
More than 735 million devices from 200+ manufacturers received a platform security update in 2016.
We released monthly Android security updates throughout the year for devices running Android 4.4.4 and up—that accounts for 86.3 percent of all active Android devices worldwide.
Our carrier and hardware partners helped expand deployment of these updates, releasing updates for over half of the top 50 devices worldwide in the last quarter of 2016.
We provided monthly security updates for all supported Pixel and Nexus devices throughout 2016, and we’re thrilled to see our partners invest significantly in regular updates as well. There’s still a lot of room for improvement, however. About half of devices in use at the end of 2016 had not received a platform security update in the previous year. We’re working to increase device security updates by streamlining our security update program to make it easier for manufacturers to deploy security patches and releasing
to make it easier for users to apply those patches.
On the research side, our Android Security Rewards program grew rapidly: we
paid researchers nearly $1 million dollars
for their reports in 2016. In parallel, we worked closely with various security firms to identify and quickly fix issues that may have posed risks to our users.
We appreciate all of the hard work by Android partners, external researchers, and teams at Google that led to the progress the ecosystem has made with security in 2016. But it doesn’t stop there. Keeping users safe requires constant vigilance and effort. We’re looking forward to new insights and progress in 2017 and beyond.
Detecting and eliminating Chamois, a fraud botnet on Android
March 13, 2017
Posted by Security Software Engineers—Bernhard Grill, Megan Ruthven, and Xin Zhao
Google works hard to protect users across a variety of devices and environments. Part of this work involves defending users against
Potentially Harmful Applications
(PHAs), an effort that gives us the opportunity to observe various types of threats targeting our ecosystem. For example, our security teams recently discovered and defended users of our ads and Android systems against a new PHA family we've named Chamois.
Chamois is an Android PHA family capable of:
Generating invalid traffic
through ad pop ups having deceptive graphics inside the ad
artificial app promotion
by automatically installing apps in the background
premium text messages
Downloading and executing additional plugins
Interference with the ads ecosystem
We detected Chamois during a routine ad traffic quality evaluation. We analyzed malicious apps based on Chamois, and found that they employed several methods to avoid detection and tried to trick users into clicking ads by displaying deceptive graphics. This sometimes resulted in downloading of other apps that commit SMS fraud. So we blocked the Chamois app family using
and also kicked out bad actors who were trying to game our ad systems.
Our previous experience with ad fraud apps like this one enabled our teams to swiftly take action to protect both our advertisers and Android users. Because the malicious app didn't appear in the device's app list, most users wouldn't have seen or known to uninstall the unwanted app. This is why Google's
is so valuable, as it helps users discover PHAs and delete them.
Under Chamois's hood
Chamois was one of the largest PHA families seen on Android to date and distributed through multiple channels. To the best of our knowledge Google is the first to publicly identify and track Chamois.
Chamois had a number of features that made it unusual, including:
: Its code is executed in 4 distinct stages using different file formats, as outlined in this diagram.
This multi-stage process makes it more complicated to immediately identify apps in this family as a PHA because the layers have to be peeled first to reach the malicious part. However, Google's pipelines weren't tricked as they are designed to tackle these scenarios properly.
: Chamois tried to evade detection using obfuscation and anti-analysis techniques, but our systems were able to counter them and detect the apps accordingly.
Custom encrypted storage
: The family uses a custom, encrypted file storage for its configuration files and additional code that required deeper analysis to understand the PHA.
: Our security teams sifted through more than 100K lines of sophisticated code written by seemingly professional developers. Due to the sheer size of the APK, it took some time to understand Chamois in detail.
Google's approach to fighting PHAs
Verify Apps protects users from known PHAs by warning them when they are downloading an app that is determined to be a PHA, and it also enables users to uninstall the app if it has already been installed. Additionally, Verify Apps monitors the state of the Android ecosystem for anomalies and investigates the ones that it finds. It also helps finding unknown PHAs through behavior analysis on devices. For example, many apps downloaded by Chamois were highly ranked by the
. We have implemented rules in Verify Apps to protect users against Chamois.
Google continues to significantly invest in its counter-abuse technologies for Android and its ad systems, and we're proud of the work that many teams do behind the scenes to fight PHAs like Chamois.
We hope this summary provides insight into the growing complexity of Android botnets. To learn more about Google's anti-PHA efforts and further ameliorate the risks they pose to users, devices, and ad systems, keep an eye open for the upcoming "Android Security 2016 Year In Review" report.
VRP news from Nullcon
March 2, 2017
Posted by Josh Armour, Security Program Manager
We’re thrilled to be joining the security research community at
this week in Goa, India. This is a hugely important event for the
Google Vulnerability Rewards Program
and for our work with the security research community, more broadly. To mark the occasion, we wanted to share a few updates about the VRP.
Tougher bugs, bigger rewards
Since the launch of our program in 2010, Google has offered a range of rewards: from $100 USD for low severity issues, up to $20,000 USD for critical vulnerabilities in our web properties (see
rewards). But, because high severity vulnerabilities have become harder to identify over the years, researchers have needed more time to find them. We want to demonstrate our appreciation for the significant time researchers dedicate to our program, and so we’re making some changes to our VRP.
Starting today we will be increasing the reward for “Remote Code Execution” on the Google VRP from $20,000 USD to $31,337 USD. We are increasing the reward for “Unrestricted file system or database access” from $10,000 USD to $13,337 USD as well. Please check out the
for more details and specifics.
Also, we are now donating rewards attributed to reports generated from our internal web security scanner; we have donated over $8000 to
this year so far.
Cloud Security Scanner
allows App Engine customers to utilize a version of the same tool.
Growing the security research community in India
2016’s VRP Year in Review
, we featured Jasminder Pal Singh, a longtime contributor who uses rewards to fund his startup, Jasminder Web Services Point. He’s emblematic of the vibrant and fast-growing computer security research community in India. We saw that new momentum reflected in last year’s VRP data: India was surpassed only by two other locations in terms of total individual researchers paid. We received reports from ~40% more Indian researchers (as compared to 2015) and gave out 30% more rewards which almost tripled the total, and doubled the average payout (both per researcher and per reward). We are excited to see this growth as all users of Google’s products benefit.
Globally, we’ve noticed other
. Russia has consistently occupied a position in the top 10 every year the last 7 years. We have noticed a 3X increase in reports from Asia, making up 70% of the Android Security Rewards for 2016. We have seen increases in the number of researchers reporting valid bugs from Germany (27%), and France (44%). France broke into our top 5 countries in 2016 for the first time.
In 2016, we delivered technical talks along with educational trainings to an audience of enthusiastic security professionals in Goa at the Nullcon security conference. This year, we continue our investment at Nullcon to deliver
focused on the growing group of bug hunters we see in India. If you are attending Nullcon please stop by and say “Hello”!
Give us feedback in our
Official Google Blog
Public Policy Blog
Lat Long Blog
Ads Developer Blog
Android Developers Blog