Fixes for CVE-2018-9581 and CVE-2018-9489 in Android 10

Two privacy issues with broadcasts in Android OS are expected to be fixed in Android Q / 10 which will be released in early September of 2019. You can see the details in Google’s security bulletin available here. Some of these fixes were not available for earlier version of Android.

We originally discovered these in the Spring of 2018 and they were disclosed via a talk at BSides DE late last year. Details are available as follows:



Path-Style Model for AWS S3 Can Lead to Namespace Squatting


Path-style model for AWS S3 and other services supporting S3 APIs can lead to namespace squatting. An attacker can create a bucket that shares the name with a special filename like “robots.txt” or “crossdomain.xml”, and insert their own content via filenames placed in that bucket. Services that rely on filename verification of domain ownership and are not precise about checking the content of such files, may end up verifying the ownership of the parent domain incorrectly. We have not yet been able to confirm this via testing.

AWS will be deprecating this functionality as of September 30th, 2020.


Amazon Web Services (AWS) provides a storage service called Simple Storage Service (S3) which allows users to storage data as files located inside separate locations called buckets (see docs). S3 currently supports two different addressing models: path-style and virtual-hosted style. The path-style looks like this:

The virtual-hosted style looks like this:

It is possible to name a bucket using a reserved name like “robots.txt”, “sitemap.xml” or “crossdomain.xml” and have that being available via the path-style addressing. HOWEVER, the only thing that would get returned is an XML-type directory listing. An attacker can add additional files into that bucket to try to influence the directory listing, but most parsers would disregard the entire file since it is malformed. What may end up happening is that the user will essentially squat this namespace.

It is not possible to reserve anything in the “.well-known” directory since it starts with a period and bucket names must start with a lowercase letter or a number. This it would not be possible to get an SSL certificate issued this way.

Additionally, if a third party service like Google WebMaster tools, Bing, etc. uses a domain validation approach to verify ownership by placing a file in the root directory, it may be possible to claim the “” domain as follows:

1. Create a bucket matching the verification name of the file.
2. Add the verification content as a key in that bucket.
3. Make the bucket public.

When the verification service hits the URL for “” they will hit the bucket listing that was created. If the service disregards the XML and uses the value it finds, it may end up registering the service domain in the user’s account.

In our testing we have not yet found a service like that – most services will not parse an XML file that the directory listing produces.

Vendor Response and Mitigation

The vendor provided the following response:

We do not believe the behavior you describe in this report presents a security concern, given what you have outlined is theoretical.

Additionally, AWS has announced that the path-style addressing model will be deprecated as of September 30th, 2020 (see here and here).


Text written by Y. Shafranovich.


2019-02-03: Initial report to the vendor
2019-02-06: Followup communication with the vendor
2019-02-12: Followup communication with the vendor
2019-02-18: Followup communication with the vendor
2019-02-19: Followup communication with the vendor
2019-05-03: Followup communication with the vendor
2019-07-28: Draft blog post sent to the vendor for review
2019-08-14: Public disclosure

Hazards of Encrypted/Confidential Mode for Email

Recently Office 365 and Gmail introduced encrypted or confidential mode for email. This is not true encryption like PGP or S/MIME where two parties exchange keys and then proceed to send and receive email. Rather, the entire experience remains hosted at the originating email provider, and the receiver can access the “secured” message via a web link, which can be opened using a one time code, an SMS code or a login. In the same vain, they can reply via the same mechanism to the sender – with the entire experience hosted by Office 365 or Gmail.

Some concerns with this approach:

  • Since all entire visual experience remains the same for most messages, it would be trivial for attackers to send phishing emails that looks identical to the real messages. With true encryption, this wouldn’t be an issue since the receiver would be able to verify the identity of the sender via keys exchanged prior to the email.
  • Since the links to read the message go to the same domain (““), it would be trivial for an attacker to register a look-alike domain (for example “” and “” are both unregistered). Again, not an issue with true encryption where the message is not hosted by the sender.
  • If combined with a password-protected file, it would be possible for phishers and malware producers to host and spread their content via these types of messages without having the receiver being able to scan these files. With true encryption, there is a key exchange that takes place before.
  • Since the real message content never travels through the email infrastructure, any existing controls that are in place to check and scan email will no longer apply. Organizations need to apply such controls on the web layer instead if the

Here is what it looks like by the receiver on Gmail (Office 365 screenshots coming):

Screen Shot 2019-07-28 at 7.28.18 PMScreen Shot 2019-07-28 at 7.30.05 PM


New Tool – airflowscan – A security checklist and static analysis tool for Apache Airflow

We just release a new set of tools. The intent of this project is provide a basic security checklist for hardening Apache Airflow installations, and a static analysis tool that can be used to analyze the Airflow configuration file for insecure settings. More information can be found at GitHub:


Brief Notes on Gmail for Android and Confidential Mode

Recently Google launched “Confidential Mode” for Gmail which seeks to protect sensitive information from unauthorized access – details here.

Some brief notes:

  • On the web version of Gmail, when replying to a confidential message, the reply is also sent as confidential. However, when using Gmail for Android that is not true – instead you get a warning that the message will not be sent with confidential mode.
  • When viewing confidential mode emails with Gmail for Android, FLAG_SECURE is not used (see our post here). That means other applications on the same device with the screen capture permissions can capture this content as well. This was reported to Google (issue # 112838515) and they do not consider it a security issue.

Another Download Protection Bypass in Google Chrome – BIN files in Mac OS


BIN files on Mac OS bypass the download protection mechanism offered by Google’s Chrome browser. This was reported and fixed by the vendor, then pushed via a component update to users in March 2019.


The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”). Additional background details can be found in our earlier post. We had previously reported multiple instances of download protection bypass in Chrome to the vendor – this post describes another one that was found more recently.


The BIN file extension on Mac OS is opened by default via the Archive Mounter utility. That means that you can take a compressed file such as ZIP and rename it as a BIN file. When downloaded via Chrome, the browser will not do safety checks on this file yet the file can carry dangerous content. The root cause is the fact that the BIN file type is whitelisted as being not dangerous. This issue only affects users on Mac OS.

The vendor fixed the issue and pushed it via a component update. Users do not need to update the actual browser – as long as connectivity exists for component updates, this should be fixed automatically.


Chrome Bug Report: 933637

Bounty Information

This issue qualified for the Chrome Rewards security bounty program and a bounty has been paid.


Advisory written by Y. Shafranovich.

Timeline Summary

2019-02-19: Report submitted
2019-02-27: Vendor fix is committed
2019-03-25: Vendor fix is released to users
2019-07-02: Public disclosure


Two Bugs in Google Chrome


Google Chrome has two places (credits pages and default sites) where HTTP links are used instead of HTTPS, which can lead to MITM attacks on a hostile network. The vendor doesn’t consider these to be security bugs and they remain unfixed.

Bug Details – Default Sites

On startup, Chrome for Android displays a search bat and 8 icons of commonly accessed sites. If the browser has not yet collected any history data, those icons default to the ones provided by a Google-hosted service (““). These default sites are country specific. However, not all of these links use HTTPS – some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker.

While this issue was seen in Android, it may affect other platforms.


Screenshot_20171122-215523 Screen Shot 2019-05-27 at 12.37.41 PM

Bug Details – Credits Page

Chrome has a credits page (“chrome://credits“) that contains licensing information and links to various open source projects. Not all of these links use HTTPS, instead some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker. This can be seen by going to the URL (“chrome://credits“) or going to “Help”, “About”, “Open Source Licenses”.

This impacts all platforms that Chrome supports including Linux, Windows, Android, iOS, MacOS and ChromeOS.


Screenshot_20190527-123241 Screenshot_20190527-123253  Screenshot_20190527-123307

Vendor Response

The vendor doesn’t consider these to be security bugs and they remain unfixed.


Chromium Bugs: 788055 and 927139


Advisory written by Y. Shafranovich.


2017-11-22: Default sites bug (#788055) reported to the vendor
2017-11-23: Initial vendor response (#788055), not considered a security bug
2017-11-23: Vendor response (#788055)
2019-01-30: Credits bug (#927139) reported to the vendor
2019-01-30: Initial vendor response (#927139), not considered a security bug
2019-01-30: Vendor response (#927139)
2019-04-01: Checking with vendor regarding disclosure (#788055)
2019-05-27: Public disclosure for both