Gmail Android app insecure Network Security Configuration.

TL;DR

Current version of Gmail Android app (8.7.15.206199545 at the time of writing), has an insecure Network Security Configuration, opening the possibility for MITM via user supplied CAs on Android versions 7+ (~43% of the Android ecosystem).

Background

Android Nougat brought security improvements when it comes to certificate authorities (CAs). By default, all applications that target API level 24+, and are running on a device with Android 7+, implement a default Network Security Configuration that will not trust user supplied CAs configured on the system, invalidating MITM attacks scenarios when the user is lured into installing an attacker controlled CA.

User-added CAs

Protection of all application data is a key goal of the Android application sandbox. Android Nougat changes how applications interact with user- and admin-supplied CAs. By default, apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in. This safe-by-default setting reduces application attack surface and encourages consistent handling of network and file-based application data.

(https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html)

A custom Network Security Config allows to explicitly weaken the default behavior of the default one, by allowing the particular app to trust in user supplied CAs.

Gmail Android app

That brings us to Gmail Android app. While implementing the static analysis checks in Droidstat-x for this topic, I’ve tested the process against several apps and discovered this issue. The current version (8.7.15.206199545 at the time of writing) is explicitly trusting in user supplied CAs in the Network Security Config file by setting a custom trust anchor where user supplied CAs are trusted. This means that as soon as an attacker succeeds to lure a user to install a CA, he is able to intercept the app communication when in the same network segment.

The Network Security Config file is located in the /res/xml folder under the name network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
</base-config>

Using Burp Suite to simulate the MITM attack scenario, we installed Burp Suite Root CA on a non rooted Android device running Android 8.1.0.

As soon as we start the Gmail app, we can observe all app communication such as the new emails sync.

On other hand, if you try to use Google Play Store in the same setup, since the app is using the default Network Security Config, you cannot see any HTTP requests from the app and errors will be present in the Alerts tab of Burp Suite.

This issue also brings up the importance of certificate pinning. Even with a user supplied CA installed and trusted by the app, certificate pinning would invalidate this type of attack.

Takeaways

• Custom Network Security Config files should not implement trust anchors in the <base-config> and <domain-config> elements that trust user supplied CAs.
• For debug purposes or during development phase, the element <debug-overrides> should be used instead, only allowing the app to trust user supplied CAs when in debug mode.
• All current apps should target API levels 24+, so that when running on Android 7+, they take advantage of the default Network Security Configuration.
  • On a side note, new apps submitted to the Play Store are currently required to target at least API level 26 and starting from November 1, 2018, app updates will have the same requirement.
• Implement Certificate Pinning.

Timeline

• 30/5/2018 - Reported to Google Security
• 30/5/2018 - Issue 80482278 created
• 30/5/2018 - Google Security replies and changes status to Won’t Fix (Intended behavior):

We’ve investigated your submission and made the decision not to track it as a security bug.

It looks to us as the issue you’re describing can only result in social engineering, and we think that addressing it would not make our users less prone to such attacks. Please take a look at https://sites.google.com/site/bughunteruniversity/nonvuln/attacks-facilitating-phishing-or-social-engineering for more explanation.

This report will unfortunately not be accepted for our VRP. Only first reports of technical security vulnerabilities that substantially affect the confidentiality or integrity of our users’ data are in scope, and we feel the issue you mentioned does not meet that bar.

If you think we’ve misunderstood, please do let us know!”

• 30/5/2018 - We tried to argument that the base operating system implemented a feature to address exactly this type of attack, so this issue should not be discarded.
• 31/5/2018 - No reply to last comment. We tried to confirm if it was Google final decision.
• 4/6/2018 - Google Security replies:

Hey,

I don’t know why Android team made such decision. It’s not a security bug we would accept for Google VRP for the aforementioned reasons.

• 4/6/2018 - We replied, clearing that the end goal of exploring this vulnerability is not to facilitate phishing or social-engineering such as the example attacks in the previously sent link.
• 5/6/2018 - Google Security replies:

Having looked again, you’re right. I’m not sure if and why Gmail app does this, but it would make it opt out from the hardening settings present in Nougat - we’ll investigate.

• 8/6/2018 - Google Security replies:

Thanks for your report.

I’ve filed a bug based on your report. At first glance, this might not be severe enough to qualify for a reward, though the panel will take a look shortly.

The panel will evaluate your report at the next meeting and we’ll update you once we’ve got more information. All you need to do now is wait. If you don’t hear back from us in 2-3 weeks or have additional information about the vulnerability, let us know!

• 12/6/2018 - Google Security replies:

Hello,

Thanks for reporting this bug. We have notified the team about this issue; they will review your report and decide whether they want to make a change or not.

As a part of our Vulnerability Reward Program, we decided that it does not meet the bar for a financial reward, but we would like to acknowledge your contribution to Google security in our Hall of Fame:

http://www.google.com/about/appsecurity/hall-of-fame/distinction/

If you wish to be added to the page Hall of Fame, please create a profile here: https://bughunter.withgoogle.com/new_profile

Your ranking is based on the number of valid reports.

• 29/6/2018 - We informed Google that we were planning to release this information on the 28th of August to the public and confirmed if the date would be appropriate.
• 29/6/2018 - Google Security replies:

Hi, while we haven’t confirmed we are going to fix, I see no problem with that date at this time. Thanks for letting us know

• 28/8/2018 - Public release.

References

• https://developer.android.com/training/articles/security-config
• https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05g-Testing-Network-Communication.md#testing-the-network-security-configuration-settings