Category Archives: Online Security Blog

The latest news and insights from Google on security and safety on the Internet

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.


Better protection against Man in the Middle phishing attacks



We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.

What developers need to know

The solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.

Better protection against Man in the Middle phishing attacks



We’re constantly working to improve our phishing protections to keep your information secure. Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

However, one form of phishing, known as “man in the middle” (MITM), is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM intercepts the communications between a user and Google in real-time to gather the user’s credentials (including the second factor in some cases) and sign in. Because we can’t differentiate between a legitimate sign in and a MITM attack on these platforms, we will be blocking sign-ins from embedded browser frameworks starting in June. This is similar to the restriction on webview sign-ins announced in April 2016.

What developers need to know

The solution for developers currently using CEF for authentication is the same: browser-based OAuth authentication. Aside from being secure, it also enables users to see the full URL of the page where they are entering their credentials, reinforcing good anti-phishing practices. If you are a developer with an app that requires access to Google Account data, switch to using browser-based OAuth authentication today.

The Android Platform Security Model



Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss:
  • The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
  • The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
  • The complex threat model Android must address.
  • How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
  • How Android’s security systems have evolved over time to address the threat model.
Android is fundamentally based on a multi-party consent1 model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich

Notes


  1. The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. 

The Android Platform Security Model



Each Android release comes with great new security and privacy features. When it comes to implementing these new features we always look at ways to measure the impact with data that demonstrates the effectiveness of these improvements. But how do these features map to an overall strategy?
Last week, we released a whitepaper describing The Android Platform Security Model. Specifically we discuss:
  • The security model which has implicitly informed the Android platform’s security design from the beginning, but has not been formally published or described outside of Google.
  • The context in which this security model must operate, including the scale of the Android ecosystem and its many form factors and use cases.
  • The complex threat model Android must address.
  • How Android’s reference implementation in the Android Open Source Project (AOSP) enacts the security model.
  • How Android’s security systems have evolved over time to address the threat model.
Android is fundamentally based on a multi-party consent1 model: an action should only happen if the involved parties consent to it. Most importantly, apps are not considered to be fully authorized agents for the user. There are some intentional deviations from the security model and we discuss why these exist and the value that they provide to users. Finally, openness is a fundamental value in Android: from how we develop and publish in open source, to the open access users and developers have in finding or publishing apps, and the open communication mechanisms we provide for inter-app interactions which facilitate innovation within the app ecosystem.
We hope this paper provides useful information and background to all the academic and security researchers dedicated to further strengthening the security of the Android ecosystem. Happy reading!
Acknowledgements: This post leveraged contributions from René Mayrhofer, Chad Brubaker, and Nick Kralevich

Notes


  1. The term ‘consent’ here and in the paper is used to refer to various technical methods of declaring or enforcing a party’s intent, rather than the legal requirement or standard found in many privacy legal regimes around the world. 

Gmail making email more secure with MTA-STS standard



We’re excited to announce that Gmail will become the first major email provider to follow the new SMTP MTA Strict Transport Security (MTA-STS) RFC 8461 and SMTP TLS Reporting RFC 8460 internet standards. Those new email security standards are the result of three years of collaboration within IETF, with contributions from Google and other large email providers.

SMTP alone is vulnerable to man-in-the-middle attacks

Like all mail providers, Gmail uses Simple Mail Transfer Protocol (SMTP) to send and receive mail messages. SMTP alone only provides best-effort security with opportunistic encryption, and many SMTP servers do not prevent certain types of malicious attacks intercepting email traffic in transit.

SMTP is therefore vulnerable to man-in-the-middle attacks. Man-in-the-middle is an attack where communication between two servers is intercepted and possibly changed without detection. Real attacks and prevention were highlighted in our research published in November 2015. MTA-STS will help prevent these types of attacks.

MTA-STS uses encryption and authentication to reduce vulnerabilities

A MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.

Gmail is starting MTA-STS adherence. We hope others will follow

Gmail the first major provider to follow the new standard, initially launching in Beta on April 10th 2019. This means Gmail will honor MTA-STS and TLS reporting policies configured when sending emails to domains that have defined these policies. We hope many other email providers will soon adopt these new standards that make email communications more secure.

Email domain administrators should set up DNS records and web server endpoint to configure MTA-STS and TLS reporting policies for incoming emails. Use our Help Center to find out how to set up an MTA-STS policy with your DNS server. G Suite admins can use the G Suite Updates blog to see what MTA-STS means for G Suite domains.

Android Security & Privacy Year in Review 2018: Keeping two billion users, and their data, safe and sound


We're excited to release today the 2018 Android Security and Privacy Year in Review. This year's report highlights the advancements we made in Android throughout the year, and how we've worked to keep the overall ecosystem secure.
Our goal is to be open and transparent in everything we do. We want to make sure we keep our users, partners, enterprise customers, and developers up to date on the latest security and privacy enhancements in as close to real-time as possible. To that end, in 2018 we prioritized regularly providing updates through our blogs and our new Transparency Reports, which give a quarterly ecosystem overview. In this year-in-review, you'll see fewer words and more links to relevant articles from the previous year. Check out our Android Security Center to get the latest on these advancements.
In this year's report, some of our top highlights include:
  • New features in Google Play Protect
  • Ecosystem and Potentially Harmful Application family highlights
  • Updates on our vulnerability rewards program
  • Platform security enhancements
We're also excited to have Dave Kleidermacher, Vice President of Android Security and Privacy, give you a rundown of the highlights from this report. Watch his video below to learn more.

Managed Google Play earns key certifications for security and privacy


Posted by Mike Burr, Android Enterprise Platform Specialist

[Cross-posted from the Android Enterprise Keyword Blog]



With managed Google Play, organizations can build a customized and secure mobile application storefront for their teams, featuring public and private applications. Organizations' employees can take advantage of the familiarity of a mobile app store to browse and download company-approved apps.
As with any enterprise-grade platform, it's critical that the managed Google Play Store operates with the highest standards of privacy and security. Managed Google Play has been awarded three important industry designations that are marks of meeting the strict requirements for information security management practices.
Granted by the International Organization for Standardization, achieving ISO 27001 certification demonstrates that a company meets stringent privacy and security standards when operating an Information Security Management System (ISMS). Additionally, managed Google Play received SOC 2 and 3 reports, which are benchmarks of strict data management and privacy controls. These designations and auditing procedures are developed by the American Institute of Certified Public Accountants (AICPA).
Meeting a high bar of security management standards
To earn the ISO 27001 certification, auditors from Ernst and Young performed a thorough audit of managed Google Play based on established privacy principles. The entire methodology of documentation and procedures for managing other companies' data are reviewed during an audit, and must be made available for regular compliance review. Companies that use managed Google Play are assured their data is managed in compliance with this industry standard. Additionally, ISO 27001 certification is in line with GDPR compliance.
Secure data management
With SOC 2 and SOC 3 reports, the focus is on controls relevant to data security, availability, processing integrity, confidentiality and privacy, which are verified through auditing reports. In managed Google Play, the data and private applications that enter Google's systems are administered according to strict protocols, including determinations for who can view them and under what conditions. Enterprises require and receive the assurance that their information is handled with the utmost confidentiality and that the integrity of their data is preserved. For many companies, the presence of an SOC 2 and 3 report is a requirement when selecting a specific service. These reports prove that a service company has met and is abiding by best practices set forth by AICPA to ensure data security.
Our ongoing commitment to enterprise security
With managed Google Play, companies' private apps for internal use are protected with a set of verified information security management processes and policies to ensure intellectual property is secure. This framework includes managed Google Play accounts that are used by enterprise mobility management (EMM) partners to manage devices.
Our commitment is that Android will continue to be a leader in enterprise security. As your team works across devices and shares mission-critical data through applications hosted in managed Google Play, you have the assurance of a commitment to providing your enterprise the highest standards of security and privacy.

Open-sourcing Sandboxed API



Many software projects process data which is externally generated, and thus potentially untrusted. For example, this could be the conversion of user-provided picture files into different formats, or even executing user-generated software code.
When a software library parsing such data is sufficiently complex, it might fall victim to certain types of security vulnerabilities: memory corruption bugs or certain other types of problems related to the parsing logic (e.g. path traversal issues). Those vulnerabilities can have serious security implications.

In order to mitigate those problems, developers frequently employ software isolation methods, a process commonly referred to as sandboxing. By using sandboxing methods, developers make sure that only resources (files, networking connections and other operating system resources) which are deemed necessary are accessible to the code involved in parsing user-generated content. In the worst-case scenario, when potential attackers gain remote code execution rights within the scope of a software project, a sandboxing technique can contain them, protecting the rest of the software infrastructure.

Sandboxing techniques must be highly resistant to attacks and sufficiently protect the rest of the operating system, yet must be sufficiently easy-to-use for software developers. Many popular software containment tools might not sufficiently isolate the rest of the OS, and those which do, might require time-consuming redefinition of security boundaries for each and every project that should be sandboxed.

Sandbox once, use anywhere

To help with this task, we are open-sourcing our battle-tested project called Sandboxed API. Sandboxed API makes it possible to create security policies for individual software libraries. This concept allows to create reusable and secure implementations of functionality residing within popular software libraries, yet is granular enough to protect the rest of used software infrastructure.

As Sandboxed API serves the purpose of accessing individual software functions inside a sandboxed library, we are also making publicly available our core sandboxing project, Sandbox2. This is now part of Sandboxed API and provides the underlying sandboxing primitives. It can be also used standalone to isolate arbitrary Linux processes, but is considered a lower-level API.

Overview

Sandboxed API is currently implemented for software libraries written in the C programming language (or providing C bindings), though we might add support for more programming runtimes in the future.

From a high-level perspective, Sandboxed API separates the library to be sandboxed and its callers into two separate OS processes: the host binary and the sandboxee. Actual library calls are then marshalled by an API object on the host side and send via interprocess communication to the sandboxee where an RPC stub unmarshals and forwards calls to the original library.

Both the API object (SAPI object) and the RPC stub are provided by the project, with the former being auto-generated by an interface generator. Users just need to provide a sandbox policy, a set of system calls that the underlying library is allowed to make, as well as the resources it is allowed to access and use. Once ready, a library based on sandboxed API can easily be reused in other projects.

The resulting API of the SAPI object is similar to the one of the original library. For example, when using zlib, the popular compression library, a code snippet like this compresses a chunk of data (error handling omitted for brevity):


void Compress(const std::string& chunk, std::string* out) {
 z_stream zst{};
 constexpr char kZlibVersion[] = "1.2.11";
 CHECK(deflateInit_(&zst, /*level=*/4, kZlibVersion, sizeof(zst)) == Z_OK);

 zst.avail_in = chunk.size();
 zst.next_in = reinterpret_cast<uint8_t*>(&chunk[0]);
 zst.avail_out = out->size();
 zst.next_out = reinterpret_cast<uint8_t*>(&(*out)[0]);
 CHECK(deflate(&zst, Z_FINISH) != Z_STREAM_ERROR);
 out->resize(zst.avail_out);

 deflateEnd(&zst);
}


Using Sandboxed API, this becomes:
void CompressSapi(const std::string& chunk, std::string* out) {
 sapi::Sandbox sandbox(sapi::zlib::zlib_sapi_embed_create());
 CHECK(sandbox.Init().ok());
 sapi::zlib::ZlibApi api(&sandbox);

 sapi::v::Array<uint8_t> s_chunk(&chunk[0], chunk.size());
 sapi::v::Array<uint8_t> s_out(&(*out)[0], out->size());
 CHECK(sandbox.Allocate(&s_chunk).ok() && sandbox.Allocate(&s_out).ok());
 sapi::v::Struct<sapi::zlib::z_stream> s_zst;
 
 constexpr char kZlibVersion[] = "1.2.11";
 sapi::v::Array<char> s_version(kZlibVersion, ABSL_ARRAYSIZE(kZlibVersion));
 CHECK(api.deflateInit_(s_zst.PtrBoth(), /*level=*/4, s_version.PtrBefore(),
                         sizeof(sapi::zlib::z_stream).ValueOrDie() == Z_OK));

 CHECK(sandbox.TransferToSandboxee(&s_chunk).ok());
 s_zst.mutable_data()->avail_in = chunk.size();
 s_zst.mutable_data()->next_in = reinterpet_cast<uint8_t*>(s_chunk.GetRemote());
 s_zst.mutable_data()->avail_out = out->size();
 s_zst.mutable_data()->next_out = reinterpret_cast<uint8_t*>(s_out.GetRemote());
 CHECK(api.deflate(s_zst.PtrBoth(), Z_FINISH).ValueOrDie() != Z_STREAM_ERROR);
 CHECK(sandbox.TransferFromSandboxee(&s_out).ok());
 out->resize(s_zst.data().avail_out);

 CHECK(api.deflateEnd(s_zst.PtrBoth()).ok());
}
As you can see, when using Sandboxed API there is extra code for setting up the sandbox itself and for transferring memory to and from the sandboxee, but other than that, the code flow stays the same.

Try for yourself

It only takes a few moments to get up and running with Sandboxed API. If Bazel is installed:
sudo apt-get install python-typing python-clang-7 libclang-7-dev linux-libc-dev
git clone github.com/google/sandboxed-api && cd sandboxed-api
bazel test //sandboxed_api/examples/stringop:main_stringop
This will download the necessary dependencies and run the project through its paces. More detailed instructions can be found in our Getting Started guide and be sure to check out the examples for Sandboxed API.

Where do we go from here?

Sandboxed API and Sandbox2 are used by many teams at Google. While the project is mature, we do have plans for the future beyond just maintaining it:

  • Support more operating systems - So far, only Linux is supported. We will look into bringing Sandboxed API to the Unix-like systems like the BSDs (FreeBSD, OpenBSD) and macOS. A Windows port is a bigger undertaking and will require some more groundwork to be done.
  • New sandboxing technologies - With things like hardware-virtualization becoming almost ubiquitous, confining code into VMs for sandboxing opens up new possibilities.
  • Build system - Right now, we are using Bazel to build everything, including dependencies. We acknowledge that this is not how everyone will want to use it, so CMake support is high on our priority list.
  • Spread the word - Use Sandboxed API to secure open source projects. If you want to get involved, this work is also eligible for the Patch Reward Program.
Get involved

We are constantly looking at improving Sandboxed API and Sandbox2 as well as adding more features: supporting more programming runtimes, different operating systems or alternative containment technologies.

Check out the Sandboxed API GitHub repository. We will be happy to consider your contributions and look forward to any suggestions to help improve and extend this code.

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.