Advisories

NFC Beaming Bypasses Security Controls in Android [CVE-2019-2114]

nightwatchcyber Advisories

Summary

NFC beaming of applications between devices using Android OS bypasses some security controls (the “install unknown application” prompt). A rogue device like a payment terminal can use this vulnerability to infect devices with malware.

Affected versions of Android are version 8 (Oreo) and higher. The vendor assigned CVE-2019-2114 to track this issue and released a fix in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability.

Background

Android is an open source operating system developed by Google for mobile phones and tablets. It is estimated that over two billion devices exist worldwide running Android. Most Android devices are restricted in which applications can be installed by users – in particular, they must originate from the Google Play Store. Prior to version 8 (Oreo) a system-wide setting existed in the OS which allowed users to override this control and grant them ability to install applications from any source (“Settings” -> “Security”). In Android 8 (Oreo) this has been changed, and users must grant permission to each application that is trying to perform such install as opposed to a system-wide setting. See example:

Some Android devices support NFC (Near Field Communication) – set of protocols that allow devices to communicate within a very short distance. This is used for applications like contactless payments, pairing of devices and access control. Android devices also support NFC for transferring data between two devices including contracts, photos and applications via a feature called Android Beam.

Vulnerability Details

In Android 8 (Oreo) a new feature was introduced that requires users to opt-in to the “Install unknown apps” permission on a app by app basis. However, it appears that any system application that is signed by Google will be automatically whitelisted and would not prompt the user for this permission. On a standard Android OS device, the NFC service is one such system application that has the permission to install other applications. This means, that an Android phone that has NFC and Android Beam enabled, then touching a malicious phone or a malicious NFC payment terminal to the device may allow malware to be installed by bypassing the “install unknown apps” prompt.

To see these permissions, use any Android phone with NFC and running v8 or higher, go to “Settings”, search for “Install unknown apps” to find the permission. Tap through to view apps, and make sure to select “Show system” in the dropdown menu. You will see that the “NFC Service” is listed as being allowed to install applications by default (since it is a system application). See example:

image

Steps to Replicate

To actually replicate a malicious drive-by install, do the following:

  1. Setup two phones with NFC and Android beam enabled.
  2. Download any APK file on the “sender” phone (something like
    this APK from GitHub).
  3. Go to the file manager in the “sender” phone, tap the file and select “Share”. Then select “Android Beam” as the sharing method,
  4. Bring two phones together and complete the transfer.
  5. After this is done, go to the receiver phone, tap the “Beam completed” notification, and tap the file. It will skip directly to the install prompt, bypassing the “Install unknown apps” check.

Tested on Android 9 and Android 8.10.

Vendor Response and Mitigation

The vendor (Google) classified this issue as High and assigned CVE-2019-2114 to track this issue. A fix was released in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability. After applying the update, users are encouraged to check the “Install unknown apps” permission in settings to make sure the NFC Service is listed as “not allowed” to install applications.

This issue only affects Android version 8 (Oreo) or higher.

References

Android bulletin: October 2019 (2019-10-06)
CVE ID: CVE-2019-2114
Google Bug # 123651515 (Android ID # A-123700348)
Google Blog: Blog post about the changes in the “install unknown apps” permission

Bounty Information

This issue satisfied the requirements of the Android Security Rewards Program and a bounty payment has been paid by the vendor.

Credits

This advisory was written by Y. Shafranovich.

Timeline

2019-01-30: Initial report submitted to the vendor
2019-01-31: Vendor response received – issue under investigation
2019-02-01: Issue rated as High by the vendor
2019-03-02: Checking bug status, vendor communication
2019-04-06: Checking bug status, vendor communication
2019-04-29: Checking bug status, fix is still being worked on
2019-06-29: Checking bug status, vendor communication
2019-07-01: Vendor indicating that a patch is forthcoming, CVE assigned
2019-07-08: Notified vendor about upcoming talk
2019-07-10: Vendor informing that the fix has been delayed by a month
2019-07-28: Draft blog post sent to the vendor for review
2019-07-31: Blog post comments received from the vendor
2019-09-04: Follow-up communication with the vendor
2019-10-07: Fix released
2019-10-24: Public disclosure

Media Coverage

See:

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

nightwatchcyber Advisories

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:

 

 

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

nightwatchcyber Advisories ,

Summary

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.

Background

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.

Details

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.

References

Chrome Bug Report: 933637

Bounty Information

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

Credits

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

 

Upcoming Advisory for an Android OS Vulnerability – CVE-2019-2114

nightwatchcyber Advisories

We will be releasing an advisory on a security vulnerability that was reported to the Google, specifically in Android OS. This issue is being tracked under CVE-2019-2114. The advisory is expected to be published later this year once a fix is released by the vendor.

UPDATE: The advisory and fix for this issue have been released – see our blog post here.

Two Bugs in Google Chrome

nightwatchcyber Advisories ,

Summary

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 (“https://www.gstatic.com/chrome/ntp/suggested_sites_DEFAULT_5.json“). 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.

Screenshots:

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.

Screenshots:

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.

References

Chromium Bugs: 788055 and 927139

Credits

Advisory written by Y. Shafranovich.

Timeline

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

nightwatchcyber Advisories, Research

Summary

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”:

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

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

http://localhost:8080/ssi/printenv.shtml?%3Cbr/%3E%3Cbr/%3E%3Ch1%3EXSS%3C/h1%3E%3Cbr/%3E%3Cbr/%3E

http://localhost:8080/printenv.shtml?%3Cscript%3Ealert(%27xss%27)%3C/script%3E

Screenshots:

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.

References

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

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

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

Upcoming Advisory for Apache Tomcat Vulnerability – CVE-2019-0221

nightwatchcyber Advisories , ,

We will be releasing an advisory on a security vulnerability that was reported to the Apache Software Foundation, specifically in Apache Tomcat. This issue is being tracked under CVE-2019-0221. The issue was discovered by Nightwatch Cybersecurity Research and reported to Apache via the EU FOSSA-2 project, hosted by Intrigri.

UPDATE: Advisory has been posted here.

Related links:

  • Apache advisory – here
  • CVE entry – here
  • Tomcat security pages – v7, v8 and v9

Finding Unlisted Public Bounty and Vulnerability Disclosure Programs with Google Dorks

nightwatchcyber Advisories , ,

Introduction

Bug bounty/vulnerability disclosure platforms are used by companies to coordinate the reporting, triaging and in some case, rewarding,  of security vulnerabilities. In many platforms the various programs are not always public – some may be public, some maybe unlisted but public, some may be private and some may be invite-only. In this post we outline how we found a set of public programs that were not listed on the platform site but were findable via Google searches.

Embedded Forms

While most platforms host the program information, policies and submission pages on their own sites, their customers may occasionally want to embed or host a particular program on the site owned by the customer or one that is agnostic, not the platform. For these uses cases, some platforms have an embedding feature which allows customers to embed a submission form for vulnerabilities within the customer owned website or host it via a website that doesn’t appear to be connected to the platform vendor. Here is documentation for some of the platforms:

The problem is that if a company ends up embedding a form, it will get indexed by Google and can be found via a Google search. The trick is to look for something unique in the text of the form. Here is for example a vulnerability reporting form for Walmart, provided by BugCrowd – as you can see it says “Powered by BugCrowd”

Screen Shot 2019-05-02 at 7.40.02 PM

If you check the BugCrowd public list of programs, WalMart will not be listed:

Screen Shot 2019-05-02 at 9.10.49 PM

However, it may appear on the list such as the one from Disclose.IO:

Screen Shot 2019-05-04 at 11.48.15 PM.png

Google Dorking Other BugCrowd Embedded Forms

Now if you put the text from the form into Google as follows, you can find a bunch of other ones as well:

"powered by bugcrowd" -site:bugcrowd.com

These do not appear in the BugCrowd public list, and many of them are not in the Disclose.IO list. Example:

Screen Shot 2019-05-02 at 9.08.36 PM

What About HackerOne?

For HackerOne, a blog post shows an example of a form which looks very similar to a standard one.

Screen Shot 2019-05-02 at 9.19.01 PM

We tried Googling for the following query got no results:

"powered by hackerone" "submit vulnerability report"

Eventually, we just Google for the following and got many unrelated results:

"submit vulnerability report"

Among those, we were able to find a single embedded form from HackerOne for a non-public program. Because HackerOne uses an image for their “Powered By” message, it is probably harder to find or maybe not that many programs use the HackerOne forms yet 🙂 [Based on some additional feedback it looks like HackerOne forms are generated dynamically and may not be indexable by Google, see Lyft as an example]

Screen Shot 2019-05-02 at 9.21.34 PM

Screen Shot 2019-05-02 at 9.23.10 PM

Screen Shot 2019-05-02 at 9.24.50 PM

What About Synack?

While Synack doesn’t operate any public programs, they do offer a managed disclosure process which is hosted by “responsibledisclosure.com”. A simple Google Search against that site shows a bunch of programs (these are listed in Disclose.io):

site:responsibledisclosure.com

Screen Shot 2019-05-02 at 9.34.33 PM.png

Other Platforms?

We haven’t explored other platforms but feel free to do so yourself 🙂

Responses from the Platforms

This issue was reported to the three platforms listed above, here are their responses:

BugCrowd:

“We don’t guarantee that all public programs are listed directly on Bugcrowd.com – a number of companies leverage our Embedded Submission Form to host a Bugcrowd submission form (like you’re finding via these searches) directly on their own sites. Even though these programs aren’t directly advertised on our Programs page, they’re not meant to be considered private/secret. It’s up to the companies choosing to use this form to decide how and where they display it.

Nothing is being “leaked,” as any companies who do choose to run private programs that include an intake via our Embedded Submission Form understand what they’re doing: The Embedded Submission Form integration enables you to host a submission form from your own website rather than through Bugcrowd. This integration provides a streamlined workflow so that researchers can easily submit vulnerability reports directly to you, while allowing you to continue to manage and track submissions through Crowdcontrol.

You can manage and track submissions through Crowdcontrol for private and public programs. These are companies choosing to host our ESF on public/indexed pages, so the fact that they’re not listed at https://bugcrowd.com/programs is exactly what you’d expect.”

HackerOne:

“This feature is not intended to be private but to help ease programs’ engagement with the larger hacker community. We do caution programs, prior to setting up the feature, to understand that their program will no longer be private if the form is exposed in a public way. Beyond that, the program benefits from our normal private experience, and we do not include other call outs or invitations to the programs on HackerOne unless explicitly requested.

Some companies, like Punchh, use this feature to allow researchers to submit reports to their vulnerability disclosure program via their own website.”

Synack:

“Although we do not advertise our Responsible Disclosure programs, they are publicly accessible and not considered to be private information”

Timeline

2019-02-20: Reported to Synack and rejected
2019-02-22: Reported to BugCrowd and rejected
2019-05-02: Draft blog post shared with HackerOne, Synack and BugCrowd
2019-05-03: Comments received from platform vendors
2019-05-04: Blog post published

Remote Code Execution (RCE) in CGI Servlet – Apache Tomcat on Windows – CVE-2019-0232

nightwatchcyber Advisories, Research

Summary

Apache Tomcat has a vulnerability in the CGI Servlet which can be exploited to achieve remote code execution (RCE). This is only exploitable when running on Windows in a non-default configuration in conjunction with batch files.

The vendor released a fix in Tomcat versions 7.0.94, 8.5.40 and 9.0.19. Users are encouraged to upgrade as soon as possible. CVE-2019-0232 has been assigned to track this issue.

Vulnerability Details

Common Gateway Interface (CGI) is a standard protocol to allow web servers to execute command line programs / scripts via web requests. This protocol also allows passing of command line arguments to the script or program being executed via URL parameters. The protocol itself is defined in RFC 3875.

The following CGI request:

  • http://localhost:8080/cgi/test.bat?&dir

converts to:

  • test.bat &dir

Apache Tomcat supports execution of CGI scripts / programs in a non-default configuration via a special CGI servlet. This servlet also parses URL parameters and translates them into command line arguments. The actual execution of the CGI scripts happens via Java Runtime Environment (JRE)’s java.lang.Runtime class, exec() function.

When CGI support is enabled in Apache Tomcat in Windows, and command line argument passing is enabled, it is possible to cause command injection via parameter interpolation when calling a batch file (*.bat / *.cmd). This happens because “cmd.exe” performs interpolation on some special characters before execution which can cause other shell commands to be called. Neither Apache Tomcat or the Windows JRE perform any kind of input validation for these special characters. A partial list of these characters can be found here and here. Additional information about why this issue is specific to the Windows JRE can be found in this blog post by Markus Wulftange.

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:

<Context privileged="true">

4. Modify conf\web.xml to enable the CGI Servlet by removing the comments around line 387 as follows and adding the following parameters (enableCmdLineArguments is only needed for Tomcat 9):

<servlet>
<servlet-name>cgi</servlet-name>
<servlet-class>org.apache.catalina.servlets.CGIServlet</servlet-class>
<init-param>
  <param-name>cgiPathPrefix</param-name>
  <param-value>WEB-INF/cgi</param-value>
</init-param>
<init-param>
  <param-name>executable</param-name>
  <param-value></param-value>
</init-param>
<init-param>
  <param-name>enableCmdLineArguments</param-name>
  <param-value>true</param-value>
</init-param>
<load-on-startup>5</load-on-startup>
</servlet>

5. Enable the CGI servlet by removing comments around this – you also need to change the URL pattern to match the one in the previous step (“cgi”):

<servlet-mapping>
<servlet-name>cgi</servlet-name>
<url-pattern>/cgi/*</url-pattern>
</servlet-mapping>

6. Create a folder for the CGI files:

mkdir webapps\ROOT\WEB-INF\cgi

7. Place the following text into a batch file located in “webapps\ROOT\WEB-INF\cgi\test.bat”

@echo off
echo Content-Type: text/plain
echo.
echo Hello, World!

8. Run Tomcat via the following command:

cd bin
catalina run

9. Trigger the following URLs and observe the dir command being run:

http://localhost:8080/cgi/test.bat?&dir

s1

Additional Notes – Environment Variables and Path

By default, Tomcat doesn’t pass all of the environment variables from the parent process that runs Tomcat itself. That means that if you run “set”, you will not see any environment variables other than those set by Tomcat itself. This also means that you would need to spell out the directory path of the command you are trying to run. However, if the “passShellEnvironment” parameter is set to true, the variables from the parent process will be passed through and you can call any command in PATH as well as view those variables. If the command cannot be found, there will be a error in the console log “XXXX is not recognized as an internal or external command”.

Example of trying to run a command without a full directory including the Tomcat console logs:

s5 s6

Examples of running with the parameter being set or spelling out the directory path:

s8s9.PNG

Example of trying to view the environment variables without and with the passShellEnvironment parameter being set to “true”:

s3

s2.PNG

Additional Notes – Memory Leaks / Denial of Service

If the command being executed is a long running command, it maybe possible to cause a denial of service or a memory leak. This happens because Tomcat waits for the OS process to complete.

Here is an example of netstat being triggered:

screen4

screen3

Additional Notes – Other Commands and STDERR

The “executable” parameter indicates which executable should be used to run the script. By default, this is set to “perl” with the expectation that the files being executed are Perl scripts. If this is set to empty, then it is possible to execute batch files since those are executed by “cmd.exe”. HOWEVER, it seems that the command interpolation only happens with batch files – if this is set to real program, then command interpolation doesn’t necessary occur and this vulnerability may be not exploitable.

Also, if the command being triggered outputs to STDERR instead of STDOUT, that output doesn’t get piped back to the web request – instead it goes to the Tomcat console log.

Here is an example when “java.exe” is set as the executable parameter and produces output to STDERR:

b3

Vendor Response

This issue was responsibly reported to the vendor via the EU FOSSA bounty program operated by Intigriti. Vendor analysis indicated that the core cause for this issue has to do with the way the Java Runtime Environment (JRE) interprets command arguments in Windows specifically and doesn’t impact Apache Tomcat when used with other operating systems. The vendor assigned CVE-2019-0232 to track this issue and provided a fix.

The vendor fix consists of two parts:

  • Disabling command line arguments from being passed to the CGI servlet in the default configuration (“enableCmdLineArguments” set to “false“) for Tomcat 7 and 8  – this was already disabled by default in Tomcat 9.
  • Adding a new configuration parameter (“cmdLineArgumentsDecoded“) to the default CGI configuration that will be used for input validation if passing of command line arguments is enabled and will be set to the following regular expression (OS specific). Note that if the user changes this parameter, they may become vulnerable again. 
    • Windows - [[a-zA-Z0-9\Q-_.\\/:\E]+]
    • Other operating systems - [.*]

Affected Versions and Mitigation

Apache Tomcat is only vulnerable to this issue if the following conditions are met:

  • Running on Windows
  • CGI support is enabled either via the web.xml for a specific web application or the server as whole (see documentation). This is disabled by default.
  • The “privileged” setting is set to “true” in the Context element. This is “false” by default.
  • Tomcat 9 only – enableCmdLineArguments is set to “true” (enabled by default in Tomcat 7 and 8)
  • The “executable” parameter is empty, and the the CGI scripts being executed are batch files (either .bat or .cmd). It is not clear if other commands that use “cmd.exe” are vulnerable as well.

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:

IMPORTANT NOTE: even when running a fixed version, you SHOULD NOT change the “cmdLineArgumentsDecoded” configuration parameter to a different value. If you do, your installation may become vulnerable. If an upgrade is not possible, users can apply one of the following mitigations:

  • Disable CGI support (it is disabled by default)
  • Or set the “enableCmdLineArguments” parameter to “false“. This setting will disable command line arguments from being passed via the CGI servlet.

Bounty Information

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

References

Blog post on JRE behavior: see here (Markus Wulftange)
CGI Standard: RFC 3875
CVE-ID: CVE-2019-0232
CVSS v2.0 Score: 9.3 – (AV:N/AC:M/Au:N/C:C/I:C/A:C)
CVSS v3.0 Score: 8.1 – (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Tomcat CGI Servlet source code: see GitHub
Vendor advisory: see here

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

2019-02-14: Initial report submitted to the platform
2019-02-17: Initial report validated by the platform
2019-03-03: Report acknowledged by the vendor
2019-03-14: Interim evaluation received from the vendor
2019-03-22: Communication with the vendor
2019-04-10: Public advisory issued by the vendor
2019-04-30: Public disclosure by reporter

Upcoming Advisory for Apache Tomcat Vulnerability – CVE-2019-0232

nightwatchcyber Advisories , ,

We will be releasing an advisory on a security vulnerability that was reported to the Apache Software Foundation, specifically in Apache Tomcat. This issue is being tracked under CVE-2019-0232. The issue was discovered by Nightwatch Cybersecurity Research and reported to Apache via the EU FOSSA-2 project, hosted by Intrigri.

UPDATE: The advisory has been published here.

Related links:

  • Apache advisory – here
  • CVE entry – here