Author Archives: Aaron Stein

Decrypted: How Heather Adkins thinks about security

Heather was hacked and the rest is history. 

An 18-year veteran of Google’s security team, Heather Adkins’ interest in security was sparked when the small ISP she worked for in college suffered a data breach. Her reaction to the incident wasn’t exactly typical:


“Most people when they get hacked, panic. There's a sense of fear, and a sense of unknowing. But I did not panic or have any fear—I was really excited! I felt very curious: I wanted to know how the attackers did this, how they managed to bypass our security. And I fell in love with the role.”


In our latest edition of Public Key, Google's director of information security discusses the details of incident detection and response—“the function of security that looks for hackers and kicks them out of the network,” why COVID-19 marks a turning point in her team’s approach to securing people working and learning from home, how medieval history informs her work, and the future of online security.

More from this Series

Public Key

Googlers and academics share their thoughts about our approach to security and how product design, threats to high-risk users, research partnerships and medieval history (yup!) contribute to the ways we protect people online. 

View more from Public Key

Why design is important to security

Security is usually invisible. More often than not, we just protect you automatically and you don’t need to lift a finger. But sometimes, we’ll notify you and suggest that you take action to better secure your information, like check your Account activity after we block a suspicious attempt to sign in. Whether the issue is critical or less serious, getting these notifications right—making sure they’re written clearly and presented in a simple and useful way—is really important. These alerts shouldn’t just keep you safe, but help you feel safe too. 

Over the years, we’ve made changes to our notifications that have had a big impact on people’s security. In 2015 for example, we started using Android alerts to notify people about critical issues with their Google Accounts, like a suspected hack. Compared to email, we saw a 20-fold increase in the number of people that engaged with these new notifications within an hour of receiving them.

Today we announced a new type of critical alert that will display within the Google app you’re using. So we thought it was a good time to dive a bit deeper into the thinking behind how we develop useful security notices. In this video, Jonathan Skelker, a product manager who specializes in alerts and notifications, and Niti Arora, a UX designer for Google security, discuss how we think about communicating with users in our products to help them feel safe.

More from this Series

Public Key

Googlers and academics share their thoughts about our approach to security and how product design, threats to high-risk users, research partnerships and medieval history (yup!) contribute to the ways we protect people online. 

View more from Public Key

Public Key: Sharing our approach to security

In asymmetric cryptography, a common system for encrypting data, there are two decryption tools, or “keys.” The first is a private key that only the user knows, and the other is a public key, which is safe to share with everyone. 


Public Key is also the name of a new series about our approach to security, across Google. From home offices everywhere, Googlers and academics share their thoughts about how product design, threats to high-risk users, research partnerships, medieval history (yup!) and more, contribute to the ways we protect people online. We want to make sure people aren’t just aware of our automatic protections, but understand the thinking behind them too. That’s always been the case, but at this particular moment in time, it’s especially important.


You can think of this series as a public key, for Google security…on the Keyword. For a peek at what we’ll be covering, watch our video above. And stay tuned for more over the coming weeks.

More from this Series

Public Key

Googlers and academics share their thoughts about our approach to security and how product design, threats to high-risk users, research partnerships and medieval history (yup!) contribute to the ways we protect people online. 

View more from Public Key

Announcing new reward amounts for abuse risk researchers

It has been two years since we officially expanded the scope of Google’s Vulnerability Reward Program (VRP) to include the identification of product abuse risks.


Thanks to your work, we have identified more than 750 previously unknown product abuse risks, preventing abuse in Google products and protecting our users. Collaboration to address abuse is important, and we are committed to supporting research on this growing challenge. To take it one step further, and as of today, we are announcing increased reward amounts for reports focusing on potential attacks in the product abuse space.


The nature of product abuse is constantly changing. Why? The technology (product and protection) is changing, the actors are changing, and the field is growing. Within this dynamic environment, we are particularly interested in research that protects users' privacy, ensures the integrity of our technologies, as well as prevents financial fraud or other harms at scale.


Research in the product abuse space helps us deliver trusted and safe experiences to our users. Martin Vigo's research on Google Meet's dial-in feature is one great example of an 31337 report that allowed us to better protect users against bad actors. His research provided insight on how an attacker could attempt to find Meet Phone Numbers/Pin, which enabled us to launch further protections to ensure that Meet would provide a secure technology connecting us while we're apart.


New Reward Amounts for Abuse Risks


What’s new? Based on the great submissions that we received in the past as well as feedback from our Bug Hunters, we increased the highest reward by 166% from $5,000 to $13,337. Research with medium to high impact and probability will now be eligible for payment up to $5,000.


What did not change? Identification of new product abuse risks remains the primary goal of the program. Reports that qualify for a reward are those that will result in changes to the product code, as opposed to removal of individual pieces of abusive content. The final reward amount for a given abuse risk report also remains  at the discretion of the reward panel. When evaluating the impact of an abuse risk, the panels look at both the severity of the issue as well as the number of impacted users.


What's next? We plan to expand the scope of Vulnerability Research Grants to support research preventing abuse risks. Stay tuned for more information!


Starting today the new rewards take effect. Any reports that were submitted before September 1, 2020 will be rewarded based on the previous rewards table.


We look forward to working closely together with the researcher community to prevent abuse of Google products and ensure user safety.


Happy bug hunting!

Vulnerability Reward Program: 2019 Year in Review



Our Vulnerability Reward Programs were created to reward researchers for protecting users by telling us about the security bugs they find. Their discoveries help keep our users, and the internet at large, safe. We look forward to even more collaboration in 2020 and beyond.

2019 has been another record-breaking year for us, thanks to our researchers! We paid out over $6.5 million in rewards, doubling what we’ve ever paid in a single year. At the same time our researchers decided to donate an all-time-high of $500,000 to charity this year. That’s 5x the amount we have ever previously donated in a single year. Thanks so much for your hard work and generous giving!
Since 2010, we have expanded our VRPs to cover additional Google product areas, including Chrome, Android, and most recently Abuse. We've also expanded to cover popular third party apps on Google Play, helping identify and disclose vulnerabilities to impacted app developers. Since then we have paid out more than $21 million in rewards*. As we have done in years past, we are sharing our 2019 Year in Review across these programs.
What’s changed in the past year?

  • Chrome’s VRP increased its reward payouts by tripling the maximum baseline reward amount from $5,000 to $15,000 and doubling the maximum reward amount for high quality reports from $15,000 to $30,000. The additional bonus given to bugs found by fuzzers running under the Chrome Fuzzer Program is also doubling to $1,000. More details can be found in their program rules page.
  • Android Security Rewards expanded its program with new exploit categories and higher rewards. The top prize is now $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. And if you achieve that exploit on specific developer preview versions of Android, we’re adding in a 50% bonus, making the top prize $1.5 million. See our program rules page for more details around our new exploit categories and rewards.
  • Abuse VRP engaged in outreach and education to increase researchers awareness about the program, presenting an overview of our Abuse program in Australia, Malaysia, Vietnam, the UK and US.
  • The Google Play Security Reward Program expanded scope to any app with over 100 million installs, resulting in over $650,000 in rewards in the second half of 2019.
  • The Developer Data Protection Reward Program was launched in 2019 to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions.
We also had the goal of increasing engagement with our security researchers over the last year at events such as BountyCon in Singapore and ESCAL8 in London. These events not only allow us to get to know each of our bug hunters but also provide a space for bug hunters to meet one another and hopefully work together on future exploits.

A hearty thank you to everyone that contributed to the VRPs in 2019. We are looking forward to increasing engagement even more in 2020 as both Google and Chrome VRPs will turn 10. Stay tuned for celebrations. Follow us on @GoogleVRP

*The total amount was updated on January 28; it previously said we paid out more than $15 million in rewards.

Google CTF 2019 is here



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

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

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

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

Ready? Here are the details:


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


Disclosing vulnerabilities to protect users across platforms



On Wednesday, February 27th, we reported two 0-day vulnerabilities — previously publicly-unknown vulnerabilities — one affecting Google Chrome and another in Microsoft Windows that were being exploited together.

To remediate the Chrome vulnerability (CVE-2019-5786), Google released an update for all Chrome platforms on March 1; this update was pushed through Chrome auto-update. We encourage users to verify that Chrome auto-update has already updated Chrome to 72.0.3626.121 or later.

The second vulnerability was in Microsoft Windows. It is a local privilege escalation in the Windows win32k.sys kernel driver that can be used as a security sandbox escape. The vulnerability is a NULL pointer dereference in win32k!MNGetpItemFromIndex when NtUserMNDragOver() system call is called under specific circumstances.

We strongly believe this vulnerability may only be exploitable on Windows 7 due to recent exploit mitigations added in newer versions of Windows. To date, we have only observed active exploitation against Windows 7 32-bit systems.

Pursuant to Google’s vulnerability disclosure policy, when we discovered the vulnerability we reported it to Microsoft. Today, also in compliance with our policy, we are publicly disclosing its existence, because it is a serious vulnerability in Windows that we know was being actively exploited in targeted attacks. The unpatched Windows vulnerability can still be used to elevate privileges or combined with another browser vulnerability to evade security sandboxes. Microsoft have told us they are working on a fix.

As mitigation advice for this vulnerability users should consider upgrading to Windows 10 if they are still running an older version of Windows, and to apply Windows patches from Microsoft when they become available. We will update this post when they are available.

Open sourcing ClusterFuzz



[Cross-posted from the Google Open-Source Blog]

Fuzzing is an automated method for detecting bugs in software that works by feeding unexpected inputs to a target program. It is effective at finding memory corruption bugs, which often have serious security implications. Manually finding these issues is both difficult and time consuming, and bugs often slip through despite rigorous code review practices. For software projects written in an unsafe language such as C or C++, fuzzing is a crucial part of ensuring their security and stability.

In order for fuzzing to be truly effective, it must be continuous, done at scale, and integrated into the development process of a software project. To provide these features for Chrome, we wrote ClusterFuzz, a fuzzing infrastructure running on over 25,000 cores. Two years ago, we began offering ClusterFuzz as a free service to open source projects through OSS-Fuzz.

Today, we’re announcing that ClusterFuzz is now open source and available for anyone to use.
We developed ClusterFuzz over eight years to fit seamlessly into developer workflows, and to make it dead simple to find bugs and get them fixed. ClusterFuzz provides end-to-end automation, from bug detection, to triage (accurate deduplication, bisection), to bug reporting, and finally to automatic closure of bug reports.

ClusterFuzz has found more than 16,000 bugs in Chrome and more than 11,000 bugs in over 160 open source projects integrated with OSS-Fuzz. It is an integral part of the development process of Chrome and many other open source projects. ClusterFuzz is often able to detect bugs hours after they are introduced and verify the fix within a day.

Check out our GitHub repository. You can try ClusterFuzz locally by following these instructions. In production, ClusterFuzz depends on some key Google Cloud Platform services, but you can use your own compute cluster. We welcome your contributions and look forward to any suggestions to help improve and extend this infrastructure. Through open sourcing ClusterFuzz, we hope to encourage all software developers to integrate fuzzing into their workflows.

Android Pie à la mode: Security & Privacy

Posted by Vikrant Nanda and René Mayrhofer, Android Security & Privacy Team

[Cross-posted from the Android Developers Blog]


There is no better time to talk about Android dessert releases than the holidays because who doesn't love dessert? And what is one of our favorite desserts during the holiday season? Well, pie of course.

In all seriousness, pie is a great analogy because of how the various ingredients turn into multiple layers of goodness: right from the software crust on top to the hardware layer at the bottom. Read on for a summary of security and privacy features introduced in Android Pie this year.
Platform hardening
With Android Pie, we updated File-Based Encryption to support external storage media (such as, expandable storage cards). We also introduced support for metadata encryption where hardware support is present. With filesystem metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based encryption (such as, directory layouts, file sizes, permissions, and creation/modification times).

Android Pie also introduced a BiometricPrompt API that apps can use to provide biometric authentication dialogs (such as, fingerprint prompt) on a device in a modality-agnostic fashion. This functionality creates a standardized look, feel, and placement for the dialog. This kind of standardization gives users more confidence that they're authenticating against a trusted biometric credential checker.

New protections and test cases for the Application Sandbox help ensure all non-privileged apps targeting Android Pie (and all future releases of Android) run in stronger SELinux sandboxes. By providing per-app cryptographic authentication to the sandbox, this protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data widely accessible.
Anti-exploitation improvements
With Android Pie, we expanded our compiler-based security mitigations, which instrument runtime operations to fail safely when undefined behavior occurs.

Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of compiled code. In Android Pie, it has been enabled by default within the media frameworks and other security-critical components, such as for Near Field Communication (NFC) and Bluetooth protocols. We also implemented support for CFI in the Android common kernel, continuing our efforts to harden the kernel in previous Android releases.

Integer Overflow Sanitization is a security technique used to mitigate memory corruption and information disclosure vulnerabilities caused by integer operations. We've expanded our use of Integer Overflow sanitizers by enabling their use in libraries where complex untrusted input is processed or where security vulnerabilities have been reported.
Continued investment in hardware-backed security

One of the highlights of Android Pie is Android Protected Confirmation, the first major mobile OS API that leverages a hardware-protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. Developers can use this API to display a trusted UI prompt to the user, requesting approval via a physical protected input (such as, a button on the device). The resulting cryptographically signed statement allows the relying party to reaffirm that the user would like to complete a sensitive transaction through their app.

We also introduced support for a new Keystore type that provides stronger protection for private keys by leveraging tamper-resistant hardware with dedicated CPU, RAM, and flash memory. StrongBox Keymaster is an implementation of the Keymaster hardware abstraction layer (HAL) that resides in a hardware security module. This module is designed and required to have its own processor, secure storage, True Random Number Generator (TRNG), side-channel resistance, and tamper-resistant packaging.

Other Keystore features (as part of Keymaster 4) include Keyguard-bound keys, Secure Key Import, 3DES support, and version binding. Keyguard-bound keys enable use restriction so as to protect sensitive information. Secure Key Import facilitates secure key use while protecting key material from the application or operating system. You can read more about these features in our recent blog post as well as the accompanying release notes.
Enhancing user privacy

User privacy has been boosted with several behavior changes, such as limiting the access background apps have to the camera, microphone, and device sensors. New permission rules and permission groups have been created for phone calls, phone state, and Wi-Fi scans, as well as restrictions around information retrieved from Wi-Fi scans. We have also added associated MAC address randomization, so that a device can use a different network address when connecting to a Wi-Fi network.

On top of that, Android Pie added support for encrypting Android backups with the user's screen lock secret (that is, PIN, pattern, or password). By design, this means that an attacker would not be able to access a user's backed-up application data without specifically knowing their passcode. Auto backup for apps has been enhanced by providing developers a way to specify conditions under which their app's data is excluded from auto backup. For example, Android Pie introduces a new flag to determine whether a user's backup is client-side encrypted.

As part of a larger effort to move all web traffic away from cleartext (unencrypted HTTP) and towards being secured with TLS (HTTPS), we changed the defaults for Network Security Configuration to block all cleartext traffic. We're protecting users with TLS by default, unless you explicitly opt-in to cleartext for specific domains. Android Pie also adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. This protects information about IP addresses visited from being sniffed or intercepted on the network level.


We believe that the features described in this post advance the security and privacy posture of Android, but you don't have to take our word for it. Year after year our continued efforts are demonstrably resulting in better protection as evidenced by increasing exploit difficulty and independent mobile security ratings. Now go and enjoy some actual pie while we get back to preparing the next Android dessert release!

Making Android more secure requires a combination of hardening the platform and advancing anti-exploitation techniques.


Acknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

Combating Potentially Harmful Applications with Machine Learning at Google: Datasets and Models



[Cross-posted from the Android Developers Blog]

In a previous blog post, we talked about using machine learning to combat Potentially Harmful Applications (PHAs). This blog post covers how Google uses machine learning techniques to detect and classify PHAs. We'll discuss the challenges in the PHA detection space, including the scale of data, the correct identification of PHA behaviors, and the evolution of PHA families. Next, we will introduce two of the datasets that make the training and implementation of machine learning models possible, such as app analysis data and Google Play data. Finally, we will present some of the approaches we use, including logistic regression and deep neural networks.

Using Machine Learning to Scale

Detecting PHAs is challenging and requires a lot of resources. Our security experts need to understand how apps interact with the system and the user, analyze complex signals to find PHA behavior, and evolve their tactics to stay ahead of PHA authors. Every day, Google Play Protect (GPP) analyzes over half a million apps, which makes a lot of new data for our security experts to process.

Leveraging machine learning helps us detect PHAs faster and at a larger scale. We can detect more PHAs just by adding additional computing resources. In many cases, machine learning can find PHA signals in the training data without human intervention. Sometimes, those signals are different than signals found by security experts. Machine learning can take better advantage of this data, and discover hidden relationships between signals more effectively.

There are two major parts of Google Play Protect's machine learning protections: the data and the machine learning models.

Data Sources

The quality and quantity of the data used to create a model are crucial to the success of the system. For the purpose of PHA detection and classification, our system mainly uses two anonymous data sources: data from analyzing apps and data from how users experience apps.

App Data

Google Play Protect analyzes every app that it can find on the internet. We created a dataset by decomposing each app's APK and extracting PHA signals with deep analysis. We execute various processes on each app to find particular features and behaviors that are relevant to the PHA categories in scope (for example, SMS fraud, phishing, privilege escalation). Static analysis examines the different resources inside an APK file while dynamic analysis checks the behavior of the app when it's actually running. These two approaches complement each other. For example, dynamic analysis requires the execution of the app regardless of how obfuscated its code is (obfuscation hinders static analysis), and static analysis can help detect cloaking attempts in the code that may in practice bypass dynamic analysis-based detection. In the end, this analysis produces information about the app's characteristics, which serve as a fundamental data source for machine learning algorithms.

Google Play Data

In addition to analyzing each app, we also try to understand how users perceive that app. User feedback (such as the number of installs, uninstalls, user ratings, and comments) collected from Google Play can help us identify problematic apps. Similarly, information about the developer (such as the certificates they use and their history of published apps) contribute valuable knowledge that can be used to identify PHAs. All these metrics are generated when developers submit a new app (or new version of an app) and by millions of Google Play users every day. This information helps us to understand the quality, behavior, and purpose of an app so that we can identify new PHA behaviors or identify similar apps.

In general, our data sources yield raw signals, which then need to be transformed into machine learning features for use by our algorithms. Some signals, such as the permissions that an app requests, have a clear semantic meaning and can be directly used. In other cases, we need to engineer our data to make new, more powerful features. For example, we can aggregate the ratings of all apps that a particular developer owns, so we can calculate a rating per developer and use it to validate future apps. We also employ several techniques to focus in on interesting data.To create compact representations for sparse data, we use embedding. To help streamline the data to make it more useful to models, we use feature selection. Depending on the target, feature selection helps us keep the most relevant signals and remove irrelevant ones.

By combining our different datasets and investing in feature engineering and feature selection, we improve the quality of the data that can be fed to various types of machine learning models.

Models

Building a good machine learning model is like building a skyscraper: quality materials are important, but a great design is also essential. Like the materials in a skyscraper, good datasets and features are important to machine learning, but a great algorithm is essential to identify PHA behaviors effectively and efficiently.

We train models to identify PHAs that belong to a specific category, such as SMS-fraud or phishing. Such categories are quite broad and contain a large number of samples given the number of PHA families that fit the definition. Alternatively, we also have models focusing on a much smaller scale, such as a family, which is composed of a group of apps that are part of the same PHA campaign and that share similar source code and behaviors. On the one hand, having a single model to tackle an entire PHA category may be attractive in terms of simplicity but precision may be an issue as the model will have to generalize the behaviors of a large number of PHAs believed to have something in common. On the other hand, developing multiple PHA models may require additional engineering efforts, but may result in better precision at the cost of reduced scope.

We use a variety of modeling techniques to modify our machine learning approach, including supervised and unsupervised ones.

One supervised technique we use is logistic regression, which has been widely adopted in the industry. These models have a simple structure and can be trained quickly. Logistic regression models can be analyzed to understand the importance of the different PHA and app features they are built with, allowing us to improve our feature engineering process. After a few cycles of training, evaluation, and improvement, we can launch the best models in production and monitor their performance.

For more complex cases, we employ deep learning. Compared to logistic regression, deep learning is good at capturing complicated interactions between different features and extracting hidden patterns. The millions of apps in Google Play provide a rich dataset, which is advantageous to deep learning.

In addition to our targeted feature engineering efforts, we experiment with many aspects of deep neural networks. For example, a deep neural network can have multiple layers and each layer has several neurons to process signals. We can experiment with the number of layers and neurons per layer to change model behaviors.

We also adopt unsupervised machine learning methods. Many PHAs use similar abuse techniques and tricks, so they look almost identical to each other. An unsupervised approach helps define clusters of apps that look or behave similarly, which allows us to mitigate and identify PHAs more effectively. We can automate the process of categorizing that type of app if we are confident in the model or can request help from a human expert to validate what the model found.

PHAs are constantly evolving, so our models need constant updating and monitoring. In production, models are fed with data from recent apps, which help them stay relevant. However, new abuse techniques and behaviors need to be continuously detected and fed into our machine learning models to be able to catch new PHAs and stay on top of recent trends. This is a continuous cycle of model creation and updating that also requires tuning to ensure that the precision and coverage of the system as a whole matches our detection goals.

Looking forward

As part of Google's AI-first strategy, our work leverages many machine learning resources across the company, such as tools and infrastructures developed by Google Brain and Google Research. In 2017, our machine learning models successfully detected 60.3% of PHAs identified by Google Play Protect, covering over 2 billion Android devices. We continue to research and invest in machine learning to scale and simplify the detection of PHAs in the Android ecosystem.

Acknowledgements

This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Damien Octeau, Sebastian Porst, Chuangang Ren, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, Zhikun Wang, and Mo Yu.