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

XSS in SSI printenv command – Apache Tomcat – CVE-2019-0221


Apache Tomcat had a vulnerability in its SSI implementation which could be used to achieve cross site scripting (XSS). This is only exploitable if SSI is enabled and the “printenv” directive is used which is unlikely in a production system.

The vendor has rated this as a Low severity issue. A fix was released in versions 7.0.94, 8.5.40 and 9.0.19. Users are encouraged to upgrade as soon as possible. CVE-2019-0221 has been assigned to track this issue.

Vulnerability Details

Server Side Includes (SSI) is a simple scripting language used server-side in some web servers for functionality like including files, echoing values of variables and displaying basic information about files. Note that these ARE NOT environment variables but are specific to SSI. They either have been set by the user or contain information about the incoming HTTP request (see full list here).

The “echo” directive prints out value of a single variable while the “printenv” directive prints out values of all variables. Both of these directives output HTML. The Apache Tomcat implementation correctly escapes XSS values when using the “echo” directive but not for the “printenv” directive. As the result, if an application is using this directive, an attacker can inject malicious input causing it to output and cause XSS.

Compare the code from the “echo” parameter which encodes the output correctly:

Screen Shot 2019-05-27 at 11.18.07 AM.pngVersus the code for the “printenv” parameter which DOES NOT encode the output:

Screen Shot 2019-05-27 at 11.21.13 AM.png

The fix is to add encoding as seen in this commit:

Screen Shot 2019-05-27 at 11.22.40 AM.png

In order to exploit this, several things have to true:

  1. SSI support has to be enabled in Apache Tomcat – either globally or on a specific web application. It is NOT ENABLED by default.
  2. A file with the “printenv” SSI directive must exist within the web application (usually “.shtml”).
  3. That file must be accessible to the attacker.

Steps To Replicate

1. Install a Java Runtime Environment (JRE) in Windows.

2. Download a vulnerable version of Tomcat and extract.

3. Modify the conf\context.xml file on line 19, to enable privileged context (this can also be done on individual applications instead of globally):

Context privileged="true">

4. Modify conf\web.xml to enable the SSI Servlet as per instructions here (this can also be done on individual applications instead of globally).

5. Put the following code in “webapps/ROOT/ssi/printenv.shtml”:

Echo test: <!--#echo var="QUERY_STRING_UNESCAPED" --><br/><br/>
Printenv test: <!--#printenv -->

6. Run Tomcat via the following command:

cd bin
catalina run

7. Call the following URLs to observe XSS (may need to use FireFox). Observe the difference between “echo” directive which escapes properly and the “printenv” directive which doesn’t escape properly




Screen Shot 2019-02-17 at 10.11.32 AM

Screen Shot 2019-02-17 at 10.10.55 AM.png

Vendor Response

This issue was responsibly reported to the vendor via the EU FOSSA bounty program operated by Intigriti. The vendor assigned CVE-2019-0221 to track this issue and provided a fix.

The vendor rated this issue as “Low Impact” on the following basis:

  • SSI is disabled by default
  • hardly anyone uses SSI
  • printenv is really a debug command that you would not expect to find
    used in a production system

The vendor also indicated that if there was a lower impact level, they would have used it as they consider the chances of a production system being exposed to this vulnerability to be very close to zero.

The vendor indicated that the following versions are vulnerable (no information is available on earlier versions):

  • Tomcat 9 – versions 9.0.0.M1 through 9.0.17 (9.0.18 is not affected)
  • Tomcat 8 – versions 8.5.0 to 8.5.39
  • Tomcat 7 – versions 7.0.0 to 7.0.93

Users are encouraged to upgrade to the following fixed versions or later:

  • Tomcat 9 – version 9.0.19 – details
  • Tomcat 8 – version 8.5.40 – details
  • Tomcat 7 – version 7.0.94 – details

Bounty Information

This report satisfied the requirement of the EU FOSSA bounty program and a bounty has been paid.


Apache SSI reference: see here – mod_include
CVE-ID: CVE-2019-0221
CVSS 2.0 Score: pending
CVSS 3.0 Score: pending
Tomcat SSI documentation: see here
Vendor advisory: see here


Text of the advisory written by Yakov Shafranovich.


2019-02-17: Initial report submitted to the platform
2019-02-19: Initial report validated by the platform
2019-03-12: Report accepted by the vendor
2019-05-17: Public advisory issued by the vendor
2019-05-27: Public disclosure by reporter

Exploring the File System via Jenkins Credentials Plugin Vulnerability – CVE-2019-10320


The recently fixed vulnerability in the Jenkins Credentials plugin (fixed in v2.1.19) allowed users with certain permissions to confirm existence of a file on the server’s file system. While this doesn’t allow an attacker to view the file content, the ability to obtain information about the file system can be leveraged for other attacks. In this post we will explain how to reproduce this vulnerability.

It is also possible to load credentials from a valid PKCS#12 files on the Jenkins server, and obtain access to the contents of those credentials via a job. That may be addressed in a future blog post.

PLEASE NOTE: This is only exploitable by users that have sufficient access to the Jenkins server to add or update credentials. Usually anonymous users do not have that level of access.


You will need to download, install and initialize Jenkins following these instructions. DO NOT install any plugin during the installation process. When done, you should be able to login to Jenkins via the following URL: “http://localhost:8080/“.

Installing the Vulnerable Plugin

1. Download the vulnerable plugin (v2.1.18) from the Jenkins update site as an HPI file:


2. Go to the Jenkins plugin manager, and click the advanced tab (“http://localhost:8080/pluginManager/advanced“) to get to the manual plugin installation page. Select the HPI file downloaded in the previous step and install it. Restart the Jenkins server (“http://localhost:8080/restart“) after the plugin has been installed.


3. Login to the Jenkins management page (“http://localhost:8080/manage“) and plugin manager (“http://localhost:8080/pluginManager/“) to confirm that the vulnerable plugin has been installed.



Getting to the Vulnerable Page

1. Login to Jenkins, then go to “Credentials”, “System”, “Global Credentials”. Click the new option “Add Credentials” that appears on the left side. The user that you are using MUST have sufficient permissions to add or update credentials. You can also reach this page by going directly to “http://localhost:8080/credentials/store/system/domain/_/newCredentials“.

Screen Shot 2019-05-23 at 11.11.51 PM

Screen Shot 2019-05-23 at 11.12.28 PM.png

2. In the “Kind” drop down box select “Certificate”, and from the two radio buttons select “From a PKCS#12 file on Jenkins master”.

Screen Shot 2019-05-23 at 11.12.52 PM.png


Put in a valid path in the “file” box and click anywhere in the page to refresh. You will get an error message “The file xxxx doesn’t exists” if the file is not present, OR “Could not load keystore” if the file does exists. This would allow an attacker to explore the file system and confirm whether specific files exist or not. While file content cannot be viewed (unless they are PKCS#12 files), the attacker can use this technique to help advance other attacks.

Screen Shot 2019-05-23 at 10.37.48 PM.pngScreen Shot 2019-05-23 at 10.37.40 PM.png


CVE-ID: CVE-2019-10320
Vendor advisory: see here