Google Online Security Blog: June 2019

The Wayback Machine - https://web.archive.org/web/20220414041728/https://security.googleblog.com/2019/06/

How Google adopted BeyondCorp

June 27, 2019

Posted by Lior Tishbi, Program Manager and Puneet Goel, Product Manager, Justin McWilliams, Engineering Manager
the first of multiple BeyondCorp papersBeyondCorp Why did we adopt BeyondCorp?Improving productivity

A growing number of employees were not in the office at all times. They were working from home, a coffee shop, a hotel or even on a bus or airplane. When they were outside the office, they needed to connect via a VPN, creating friction and extending the network perimeter.

The user experience of a VPN client may be acceptable, even if suboptimal, from a laptop. Use of VPN is less acceptable, from both employees and admins perspectives, when considering growing use of devices such as smartphones and tablets to perform work.

A number of users were contractors or other partners who only needed selective access to some of our internal resources, even though they were working in the office.

Keeping Google secure

The expanded use of public clouds and software-as-a-service (SaaS) apps meant that some of our corporate services were no longer deployed on-premises, further blurring the traditional perimeter and trust domain. This introduced new attack vectors that needed to be protected against.

There was ongoing concern about relying solely on perimeter defense, especially when the perimeter was growing consistently. With the proliferation of laptops and mobile devices, vulnerable and compromised devices were regularly brought within the perimeter.

Finally, if a vulnerability was observed or an attack did happen, we wanted the ability to respond as quickly and automatically as possible.

How did we do it?

Connecting from a particular network does not determine which service you can access.

Access to services is granted based on what the infrastructure knows about you and your device.

All access to services must be authenticated, authorized and encrypted for every request (not just the initial access).

High level architecture for BeyondCorp
What lessons did we learn? Obtain executive support early on and keep it Recognize data quality challenges from the very beginning Enable painless migration and usage Assign employee and helpdesk advocates Clear employee communications Run highly reliable systemsSite Reliability Engineering (SRE) Next timeBeyondCorp research papersGoogle Cloud (context-aware access)This post was updated on July 3 to include Justin McWilliams as an author.

Google Public DNS over HTTPS (DoH) supports RFC 8484 standard

June 26, 2019

Posted by Marshall Vale, Product Manager and Alexander Dupuy, Software Engineeredge PoPs

https://dns.google/dns-query (RFC 8484 – GET and POST)

https://dns.google/resolve (JSON API – GET)

We are deprecating internet-draft DoH support on the /experimental URL path and DoH service from dns.google.com, and will turn down support for them in a few months.
With Google Public DNS, we’re committed to providing fast, private, and secure DNS resolution through both DoH and DNS over TLS (DoT). We plan to support the JSON API until there is a comparable standard for webapp-friendly DoH.

What the new DoH service means for developers
To use our DoH service, developers should configure their applications to use the new DoH endpoints and properly handle HTTP 4xx error and 3xx redirection status codes.

Applications should use dns.google instead of dns.google.com. Applications can query dns.google at well-known Google Public DNS addresses, without needing an extra DNS lookup.
Developers using the older /experimental internet-draft DoH API need to switch to the new /dns-query URL path and confirm full RFC 8484 compliance. The older API accepts queries using features from early drafts of the DoH standard that are rejected by the new API.
Developers using the JSON API can use two new GET parameters that can be used for DNS/DoH proxies or DNSSEC-aware applications.

Redirection of /experimental and dns.google.com

The /experimental API will be turned down in 30 days and HTTP requests for it will get an HTTP redirect to an equivalent https://dns.google/dns-query URI. Developers should make sure DoH applications handle HTTP redirects by retrying at the URI specified in the Location header.
Turning down the dns.google.com domain will take place in three stages.

The first stage (in 45 days) will update the dns.google.com domain name to return 8.8.8.8 and other Google Public DNS anycast addresses, but continue to return DNS responses to queries sent to former addresses of dns.google.com. This will provide a transparent transition for most clients.
The second stage (in 90 days) will return HTTP redirects to dns.google for queries sent to former addresses of dns.google.com.
The final stage (in 12 months) will send HTTP redirects to dns.google for any queries sent to the anycast addresses using the dns.google.com domain.

We will post timelines for redirections on the public‑dns‑announce forum and on the DoH migration page. You can find further technical details in our DoH documentation, and if you have a question or problem with our DoH service, you can create an issue on our tracker or ask on our discussion group. As always, please provide as much information as possible to help us investigate the problem!

Helping organizations do more without collecting more data

June 19, 2019

Posted by Amanda Walker, Engineering Director; Sarvar Patel, Software Engineer; and Moti Yung, Research Scientist, Private Computinginvest in new researchPassword Checkupprivate set intersection (PSI)open-source availabilitysecure multi-party computation Collaborating with data in privacy-safe ways A deeper look at the technology

Private set intersection allows two parties to privately join their sets and discover the identifiers they have in common. We use an oblivious variant which only marks encrypted identifiers without learning any of the identifiers.

Homomorphic encryption allows certain types of computation to be performed directly on encrypted data without having to decrypt it first, which preserves the privacy of raw data. Throughout the process, individual identifiers and values remain concealed. For example, you can count how many identifiers are in the common set or compute the sum of values associated with marked encrypted identifiers – without learning anything about individuals.

infographic

Private Join and Compute

Using multi-party computation to solve real-world problemsmaking privacy technology more widely availablecollaborative machine learning

Public policy - if a government implements new wellness initiatives in public schools (e.g. better lunch options and physical education curriculums), what are the long-term health outcomes for impacted students?
Diversity and inclusion - when industries create new programs to close gender and racial pay gaps, how does this impact compensation across companies by demographic?
Healthcare - when a new preventative drug is prescribed to patients across the country, does it reduce the incidence of disease?
Car safety standards - when auto manufacturers add more advanced safety features to vehicles, does it coincide with a decrease in reported car accidents?

Private Join and Compute keeps individual information safe while allowing organizations to accurately compute and draw useful insights from aggregate statistics. By sharing the technology more widely, we hope this expands the use cases for secure computing. To learn more about the research and methodology behind Private Join and Compute, read the full paper and access the open source code and documentation. We’re excited to see how other organizations will advance MPC and cryptography to answer important questions while upholding individual privacy.

Acknowledgements

Product Manager - Nirdhar Khazanie
Software Engineers - Mihaela Ion, Benjamin Kreuter, Erhan Nergiz, Quan Nguyen, and Karn Seth
Research Scientist - Mariana Raykova

New Chrome Protections from Deception

June 18, 2019

Posted by Emily Schechter, Chrome Product Manager Suspicious Site Reporter extension

Help us protect web users by reporting dangerous or deceptive sites to Google Safe Browsing through the Suspicious Site Reporter extension.

Starting in the current version of Chrome (75), you’ll see a warning when the page URL might be confused for URLs of sites you’ve visited recently.

This new warning works by comparing the URL of the page you’re currently on to URLs of pages you’ve recently visited. If the URL looks similar, and might cause you to be confused or deceived, we’ll show a warning that helps you get back to safety.

install the new extension

Improving Security and Privacy for Extensions Users

June 12, 2019

No, Chrome isn’t killing ad blockers -- we’re making them saferPosted by Devlin Cronin, Chrome Extensions Teamannounced a number of changesrestricting inline installationpreventing the use of deceptive installation practiceslimiting the data collected by extensions

here

Use your Android phone’s built-in security key to verify sign-in on iOS devices

June 12, 2019

Posted by Kaiyu Yan and Christiaan BrandintroducedSecurity keysFIDOstrongestpresentation

CTAP2 protocol

User experience on an iPad with Pixel 3
It’s easy to get started

Add your personal or work Google Account to your Android 7.0+ (Nougat) phone.

Make sure you’re enrolled in 2-Step Verification (2SV).

On your computer, visit the 2SV settings and click "Add security key".

Choose your Android phone from the list of available devices.

On both of your devices, make sure Bluetooth is turned on.

On your iPhone or iPad (iOS version 10.0 or up), sign in to your Google Account with your username and password using the Google Smart Lock app.

Check your Android phone for a notification.

Follow the instructions to confirm it’s you signing in.

hererequire the use of security keysGoogleother vendors

PHA Family Highlights: Triada

June 6, 2019

Posted by Lukasz Siewierski, Android Security & Privacy Team

PHA family highlightsspam apps History of Triadaa blog post on the Kaspersky Lab websitea follow-up blog postod2gf04pd9ac32dorbdqshweight watchingweight

su binary accepts two passwords com.android.browsercom.qihoo.browsercom.oupeng.browserour blog post about the Zen PHA family09 00 00 50 4B 01 02 14 00 14 00 08 00 08 00 4F ...PK..........O 91 F3 48 AE CF 91 D5 B1 04 00 00 52 09 00 00 04 ..H........R.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 32 33 38 36 50 4B 05 06 00 00 00 00 01 00 01 .2386PK......... 00 32 00 00 00 E3 04 00 00 00 00 .2......... [collect_Head]device=Nexus 5X [collect_Space]xadevicekey=xxxxx … [collect_Space]collentmod=opappresultmode [collect_Space]registerUser=true [collect_End] When rooting doesn’t work…LABEL+13: V18 = -1; LABEL_18: j___config_log_println(v7, v6, v10, v11, "cf89450001"); if ( v10 ) described by Dr.Web in July 2017

<MD5 of the process name>36.jmdcom.android.systemuicom.android.vendingGET_REAL_TASKSgetRecentTasks()GET_REAL_TASKSGET_REAL_TASKSGET_REAL_TASKS

下载请求
下载结果
安装请求
安装结果
激活请求
激活结果
拉活请求
拉活结果
卸载请求
卸载结果

download request
download result
install request
installation result
activation request
activation result
pull request
pull the results
uninstall request
uninstall result

Communication mechanisms of Triada Reverse engineering countermeasures and development

Android framework strings 36.jmdfunction padding

Example of function padding 36.jmd OEM outreach

Production process with malicious party SummaryAndroid Security 2018 Year in Review report