Google Online Security Blog

Keeping 2 billion Android devices safe with machine learning

May 24, 2018

Posted by Sai Deep Tetali, Software Engineer, Google Play Protect[Cross-posted from the Android Developers Blog]Google Play Protect Security at scale

Training our machines

malicious behavior

Doubling down on securitysecurity experts and researchersPlay ProtectAcknowledgements: 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.

Google CTF 2018 is here

May 8, 2018

Posted by Jan Keller, Security TPMGoogle CTF 2017

Congratulations (for the second year) to the team pasten, from Israel, for scoring first place in both the quals and the finals. Also, for everyone who hasn’t played yet or wants to play again, we have open-sourced the 2017 challenges in our GitHub repository.

Hence, we are excited to announce Google CTF 2018:

Date and time: 00:00:01 UTC on June 23th and 24th, 2018
Location: Online
Prizes: Big checks, swag and rewards for creative write-ups

The winning teams will compete again for a spot at the Google CTF Finals later this year (more details on the Finals soon).

For beginners and veterans alike
Based on the feedback we received, we plan to have additional challenges this year where people that may be new to CTFs or security can learn about, and try their hands at, some security challenges. These will be presented in a “Quest” style where there will be a scenario similar to a real world penetration testing environment. We hope that this will give people a chance to sharpen their skills, learn something new about CTFs and security, while allowing them to see a real world value to information security and its broader impact.
We hope to virtually see you at the 3rd annual Google CTF on June 23rd 2018 at 00:00:01 UTC. Check g.co/ctf, or subscribe to our mailing list for more details, as they become available.

Why do we host these competitions?
We outlined our philosophy last year, but in short: we believe that the security community helps us better protect Google users, and so we want to nurture the community and give back in a fun way.
Thirsty for more?
There are a lot of opportunities for you to help us make the Internet a safer place:

Our Vulnerability Rewards Program: Report vulnerabilities in our infrastructure and get rewarded
(AutoFuzz) Patch Rewards Program: Fix vulnerabilities in open-source software to build your reputation and make an impact in the security community
Vulnerability Research Grants Program: Apply for a research grant to extensively test a component of our infrastructure at your own pace.

Leveraging AI to protect our users and the web

April 20, 2018

Posted by Elie Bursztein, Anti-Abuse Research Lead - Ian Goodfellow, Adversarial Machine Learning Research Leadfirst talksecond talkre-recordingthe slidesslides

DNS over TLS support in Android P Developer Preview

April 17, 2018

Posted by Erik Kline, Android software engineer, and Ben Schwartz, Jigsaw software engineer[Cross-posted from the Android Developers Blog]DNSIETFRFC 7858DNS over TLS in P

community-maintained listLinkProperties.isPrivateDnsActive()

Protecting users with TLS by default in Android P

April 12, 2018

Posted by Chad Brubaker, Senior Software Engineer Android Security[Cross-posted from the Android Developers Blog]announcedandroid:usesCleartextTrafficNetwork Security ConfigHow do I update my app?
Why should I use TLS?
blog postDeveloper Summit talkIsn't TLS slow?
No, it's not.How do I use TLS in my app?
SSLSocketFactorySocketFactorySSLSocketgetDefaultHostnameVerifier()HostnameVerifier.verify()I need to use cleartext traffic to
network security configAllow cleartext connections to a specific domain
<network-security-config> <domain-config cleartextTrafficPermitted="true"> <domain includeSubdomains="true">insecure.example.com</domain> <domain includeSubdomains="true">insecure.cdn.example.com</domain> </domain-config> </network-security-config>Allow connections to arbitrary insecure domains
<network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">example.com</domain> <domain includeSubdomains="true">cdn.example2.com</domain> </domain-config> <base-config cleartextTrafficPermitted="true" /> </network-security-config>
How do I update my library?isCleartextTrafficPermitted

Android Security 2017 Year in Review

March 15, 2018

Posted by Dave Kleidermacher, Vice President of Security for Android, Play, ChromeOSg.co/AndroidSecurityReport2017
Google Play Protectannounced

Protecting users' devices Play Protect automatically checks Android devices for PHAs at least once every day, and users can conduct an additional review at any time for some extra peace of mind. These automatic reviews enabled us to remove nearly 39 million PHAs last year.
We also update Play Protect to respond to trends that we detect across the ecosystem. For instance, we recognized that nearly 35% of new PHA installations were occurring when a device was offline or had lost network connectivity. As a result, in October 2017, we enabled offline scanning in Play Protect, and have since prevented 10 million more PHA installs.

Preventing PHA downloads Devices that downloaded apps exclusively from Google Play were nine times less likely to get a PHA than devices that downloaded apps from other sources. And these security protections continue to improve, partially because of Play Protect’s increased visibility into newly submitted apps to Play. It reviewed 65% more Play apps compared to 2016.
Play Protect also doesn’t just secure Google Play—it helps protect the broader Android ecosystem as well. Thanks in large part to Play Protect, the installation rates of PHAs from outside of Google Play dropped by more than 60%.

Security updates

While Google Play Protect is a great shield against harmful PHAs, we also partner with device manufacturers to make sure that the version of Android running on users' devices is up-to-date and secure.
Throughout the year, we worked to improve the process for releasing security updates, and 30% more devices received security patches than in 2016. Furthermore, no critical security vulnerabilities affecting the Android platform were publicly disclosed without an update or mitigation available for Android devices. This was possible due to the Android Security Rewards Program, enhanced collaboration with the security researcher community, coordination with industry partners, and built-in security features of the Android platform.

New security features in Android Oreo

We introduced a slew of new security features in Android Oreo: making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, and more.
We highlighted many of these over the course of the year, but some may have flown under the radar. For example, we updated the overlay API so that apps can no longer block the entire screen and prevent you from dismissing them, a common tactic employed by ransomware.

Openness makes Android security stronger

We’ve long said it, but it remains truer than ever: Android’s openness helps strengthen our security protections. For years, the Android ecosystem has benefitted from researchers’ findings, and 2017 was no different.
Security reward programs We continued to see great momentum with our Android Security Rewards program: we paid researchers $1.28 million dollars, pushing our total rewards past $2 million dollars since the program began. We also increased our top-line payouts for exploits that compromise TrustZone or Verified Boot from $50,000 to $200,000, and remote kernel exploits from $30,000 to $150,000.
In parallel, we introduced Google Play Security Rewards Program and offered a bonus bounty to developers that discover and disclose select critical vulnerabilities in apps hosted on Play to their developers.
External security competitions Our teams also participated in external vulnerability discovery and disclosure competitions, such as Mobile Pwn2Own. At the 2017 Mobile Pwn2Own competition, no exploits successfully compromised the Google Pixel. And of the exploits demonstrated against devices running Android, none could be reproduced on a device running unmodified Android source code from the Android Open Source Project (AOSP).

We’re pleased to see the positive momentum behind Android security, and we’ll continue our work to improve our protections this year, and beyond. We will never stop our work to ensure the security of Android users.

Distrust of the Symantec PKI: Immediate action needed by site operators

March 7, 2018

Posted by Devon O’Brien, Ryan Sleevi, Emily Stark, Chrome security teampreviously announced
Chrome 66
Chrome Canarytrusted CA

An example of a certificate error that Chrome 66 users might see if you are using a Legacy Symantec SSL/TLS certificate that was issued before June 1, 2016.

The DevTools message you will see if you need to replace your certificate before Chrome 66.

Chrome 66 has already been released to the Canary and Dev channels, meaning affected sites are already impacting users of these Chrome channels. If affected sites do not replace their certificates by March 15, 2018, Chrome Beta users will begin experiencing the failures as well. You are strongly encouraged to replace your certificate as soon as possible if your site is currently showing an error in Chrome Canary.

Chrome 70

Starting in Chrome 70, all remaining Symantec SSL/TLS certificates will stop working, resulting in a certificate error like the one shown above. To check if your certificate will be affected, visit your site in Chrome today and open up DevTools. You’ll see a message in the console telling you if you need to replace your certificate.

The DevTools message you will see if you need to replace your certificate before Chrome 70.

If you see this message in DevTools, you’ll want to replace your certificate as soon as possible. If the certificates are not replaced, users will begin seeing certificate errors on your site as early as July 20, 2018. The first Chrome 70 Beta release will be around September 13, 2018.

Expected Chrome Release Timeline

The table below shows the First Canary, First Beta and Stable Release for Chrome 66 and 70. The first impact from a given release will coincide with the First Canary, reaching a steadily widening audience as the release hits Beta and then ultimately Stable. Site operators are strongly encouraged to make the necessary changes to their sites before the First Canary release for Chrome 66 and 70, and no later than the corresponding Beta release dates.

Release	First Canary	First Beta	Stable Release
Chrome 66	January 20, 2018	~ March 15, 2018	~ April 17, 2018
Chrome 70	~ July 20, 2018	~ September 13, 2018	~ October 16, 2018

For information about the release timeline for a particular version of Chrome, you can also refer to the Chromium Development Calendar which will be updated should release schedules change.

In order to address the needs of certain enterprise users, Chrome will also implement an Enterprise Policy that allows disabling the Legacy Symantec PKI distrust starting with Chrome 66. As of January 1, 2019, this policy will no longer be available and the Legacy Symantec PKI will be distrusted for all users.

Special Mention: Chrome 65

As noted in the previous announcement, SSL/TLS certificates from the Legacy Symantec PKI issued after December 1, 2017 are no longer trusted. This should not affect most site operators, as it requires entering in to special agreement with DigiCert to obtain such certificates. Accessing a site serving such a certificate will fail and the request will be blocked as of Chrome 65. To avoid such errors, ensure that such certificates are only served to legacy devices and not to browsers such as Chrome.

A secure web is here to stay

February 8, 2018

Posted by Emily Schechter, Chrome Security Product Managergraduallymarking

In Chrome 68, the omnibox will display “Not secure” for all HTTP pages.Progress last year

Over 68% of Chrome traffic on both Android and Windows is now protected

Over 78% of Chrome traffic on both Chrome OS and Mac is now protected

81 of the top 100 sites on the web use HTTPS by default

now availablelatest Node CLI Lighthouse

Lighthouse is an automated developer tool for improving web pages.easier and cheaperset-up guides

Vulnerability Reward Program: 2017 Year in Review

February 7, 2018

Posted by Jan Keller, Google VRP Technical Pwning Master2014201520162017, By the Numbers

Vulnerability Research Grants ProgramPatch Rewards ProgramA few bug highlights

In August, researcher Guang Gong outlined an exploit chain on Pixel phones which combined a remote code execution bug in the sandboxed Chrome render process with a subsequent sandbox escape through Android’s libgralloc. As part of the Android Security Rewards Program he received the largest reward of the year: $112,500. The Pixel was the only device that wasn’t exploited during last year’s annual Mobile pwn2own competition, and Guang’s report helped strengthen its protections even further.

Researcher "gzobqq" received the $100,000 pwnium award for a chain of bugs across five components that achieved remote code execution in Chrome OS guest mode.

Alex Birsan discovered that anyone could have gained access to internal Google Issue Tracker data. He detailed his research here, and we awarded him $15,600 for his efforts.

Making Android and Play even safer
Over the course of the year, we continued to develop our Android and Play Security Reward programs.
No one had claimed the top reward for an Android exploit chain in more than two years, so we announced that the greatest reward for a remote exploit chain--or exploit leading to TrustZone or Verified Boot compromise--would increase from $50,000 to $200,000. We also increased the top-end reward for a remote kernel exploit from $30,000 to $150,000.

In October, we introduced the by-invitation-only Google Play Security Reward Program to encourage security research into popular Android apps available on Google Play.

Today, we’re expanding the range of rewards for remote code executions from $1,000 to $5,000. We’re also introducing a new category that includes vulnerabilities that could result in the theft of users’ private data, information being transferred unencrypted, or bugs that result in access to protected app components. We’ll award $1,000 for these bugs. For more information visit the Google Play Security Reward Program site.

And finally, we want to give a shout out to the researchers who’ve submitted fuzzers to the Chrome Fuzzer Program: they get rewards for every eligible bug their fuzzers find without having to do any more work, or even filing a bug.

Given how well things have been going these past years, we look forward to our Vulnerability Rewards Programs resulting in even more user protection in 2018 thanks to the hard work of the security research community.
* Andrew Whalley (Chrome VRP), Mayank Jain (Android Security Rewards), and Renu Chaudhary (Google Play VRP) contributed mightily to help lead these Google-wide efforts.

Announcing turndown of the deprecated Google Safe Browsing APIs

January 24, 2018

Posted by Alex Wozniak, Software Engineer, Safe Browsing TeamintroducedGoogle Safe Browsing API (v4)3 billion devicesGitHubSafetyNet Safe Browsing APIGetting startedSafe Browsing Google Groupour website

Security Blog

Keeping 2 billion Android devices safe with machine learning

Google CTF 2018 is here

Leveraging AI to protect our users and the web

DNS over TLS support in Android P Developer Preview

Protecting users with TLS by default in Android P

Android Security 2017 Year in Review

Distrust of the Symantec PKI: Immediate action needed by site operators

A secure web is here to stay

Vulnerability Reward Program: 2017 Year in Review

Announcing turndown of the deprecated Google Safe Browsing APIs

Labels

Archive

Feed

Company-wide

Products

Developers