Two vulnerabilities in Oracle’s iPlanet Web Server (CVE-2020-9315 and CVE-2020-9314)

SUMMARY

Two vulnerabilities were discovered in the web administration console of Oracle’s iPlanet Web Server which allow for sensitive data exposure and limited injection. The first issue allows read-only access to any page within the administration console without authentication, resulting in sensitive data exposure. The second issue allows for injection of external images which can be used for phishing and social engineering.

These vulnerabilities have been reported to the vendor (Oracle) but the vendor will not be issuing security patches because the affected product is no longer supported. Users are encouraged to implement other controls to mitigate these vulnerabilities such as restricting network access to the administration console from the Internet or switching to a supported platform.

Version 7 has been tested and found to be vulnerable, however, it is unknown whether earlier versions are affected. Latest versions of Oracle Glassfish and Eclipse Glassfish application server (v5) share common code with the affected product, have been tested and do not seem to be vulnerable. MITRE has assigned CVE-2020-9315 to track the sensitive data exposure issue and CVE-2020-9314 to track the injection issue.

ISSUE #1 – SENSITIVE DATA EXPOSURE / ADMIN GUI BYPASS (CVE-2020-9315)

A vulnerability exists in the web administration console of Oracle’s iPlanet Web Server which makes it possible to read information from any page within the console without authentication. This can result in sensitive data exposure of configuration information about the server including encryption keys, JVM configuration and other data. We did not perform testing to see whether this vulnerability allows for changes to be made within the console.

This is accomplished by replacing any URL for any page within the administration console as follows:

with:

To replicate, try the following URLs:

ISSUE #2 – IMAGE INJECTION IN THE ADMIN GUI (CVE-2020-9314)

The “productNameSrc” parameter in the administration console allows for injection of external images. When used in combination with the “productNameHeight” and “productNameWidth” parameters, this can be used to inject an external image into a site to facilitate phishing. This is due to an incomplete fix for CVE-2012-0516. The earlier fix added validation against XSS issues but didn’t add validation to make sure an external image is not loaded.

To replicate, try the following URLs:

VENDOR RESPONSE

Both vulnerabilities have been reported to the vendor (Oracle), however the vendor doesn’t plan to issue security patches since the product is no longer supported, as per the following responses:

Oracle iPlanet Web Server 7.0.x is no longer supported. Please see the life time support document.

And:

Thank you for your report regarding Oracle iPlanet Web Server 7.0.x, which is no longer supported by Oracle. Since Oracle no longer supports Oracle iPlanet Web Server 7.0.x, the policy is that there is no coordinated disclosure involving Oracle. Reporters who discover security vulnerabilities in products that Oracle no longer supports are free to disclose vulnerability details without Oracle participation. Oracle does not assign CVEs for products that are no longer supported. That means, if you want a CVE assigned you will need to contact Mitre.

CERT/CC concurred with the vendor’s assessment.

MITRE has assigned CVE-2020-9315 to track the sensitivity data exposure issue, and CVE-2020-9314 to track the injection issue.

AFFECTED VERSIONS AND MITIGATIONS

Version 7 has been tested and found to be vulnerable, however, it is unknown whether earlier versions are affected. Latest versions of Oracle Glassfish and Eclipse Glassfish application server (v5) share common code with the affected product but have been tested and do not seem to be vulnerable.

Users are encouraged to implement other controls to mitigate these vulnerabilities such as restricting network access to the administration console from the Internet or switching to a supported platform.

REFERENCES

CERT/CC ID: VU#343851
CVEs: CVE-2020-9315 and CVE-2020-9314
Oracle lifetime support documentation: see here
Related vulnerability regarding XSS: CVE-2012-0516 and advisory

CREDITS

We would like to thank Synack for assistance with the disclosure process. Text of the advisory was written by Y. Shafranovich.

TIMELINE

2020-01-19: Initial discovery
2020-01-24: Initial disclosure sent to vendor; rejected since product is not supported
2020-01-24: Clarification questions sent to the vendor
2020-01-27: Report again rejected by vendor; referred to MITRE for CVE assignment
2020-01-29: CVEs requested from MITRE
2020-02-07: Initial report sent to CERT/CC
2020-02-17: CVE request rejected by MITRE, resubmitted with more data
2020-02-18: Response received from CERT/CC
2020-02-20: CVE assignments received from MITRE
2020-02-20: CVEs and disclosure plans communicated to the vendor
2020-05-10: Public disclosure

Interesting two-factor (2FA) behavior in Facebook

We recently ran across an interesting behavior with two-factor authentication in Facebook. There are two methods supported: SMS to a phone and OTP via an app such as Google Authenticator. What is interesting is that when OTP is added as an 2FA method and SMS remains as backup, every login to Facebook still sends an SMS code (even though that method is supposed to be a “backup method” only if the OTP method fails). This is in contrast with other vendors such as Google where only one 2FA method is used at any given time.

The only way to get around this, is to setup OTP as the primary 2FA method and backup codes or a security key as the backup one. If you try to setup SMS as the backup method, it reverts to the behavior described above.

This was reported to Facebook on April 27th, 2020 and rejected as a security issue. The original report # is 554696145470552.

Screen Shot 2020-04-30 at 9.42.37 PM

Google Authenticator for Android Allows Screen Capture

Google offers an application for Android called “Google Authenticator” which is used to setup two-factor authentication (2FA). This application is used to generate standard OTP codes usually used for 2FA.

It appears that Google Authenticator allows screenshots to be taken of OTP codes. The implication is that if a user’s device ends up running a rogue app, that app can capture all generated OTP codes as they are shown by the app, and thus break two factor authentication.

[EDITED: 2020-03-23: This is only true for rogue apps with screenshot permissions (MediaProjection) BUT not those using accessibility (a11y) permissions. This is especially true since many such rogue apps use Android accessibility to scrape screenshots from running apps. However, using FLAG_SECURE may prevent that behavior even via accessibility permissions, although more research is needed to confirm that.]

UPDATE (2020-03-03): Disclosed publicly because of recent media reports

UPDATE #2 (2020-03-04): Multiple people noted that Microsoft Authenticator has the same issue. We blogged about that back in 2018 and the issue remains unfixed.

UPDATE #3 (2020-03-23): Although FLAG_SECURE may protect against malicious apps using the MediaProjection APIs, HOWEVER, as per the comment below from Yanick Fratantonio and his blog post, FLAG_SECURE doesn’t protect against attacks using accessibility services. See our follow-up post here.

Steps to Replicate

To replicate, try the following:

  1. Open the application.
  2. Add an account.
  3. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response

We filed a bug report with the vendor (Google) and the vendor filed an internal bug. The vendor never informed us whether the bug was fixed. Testing on the most recent version reveals that the bug is still present.

Screen Shot 2020-03-03 at 10.00.33 PM

References

  • GitHub issue filed by someone else – see here
  • Google Play link to the app – see here
  • Google Security Case # 8-2193000017345
  • Our earlier blog post about FLAG_SECURE on Android – see here
  • ZDNet report regarding Cerberus malware attacking this app – see here

Timeline

  • 2014-10-10: GitHub issue filed by someone else
  • 2017-05-10: Issue filed with the vendor, triaged and bug filed
  • 2017-05-11: Follow-up discussion regarding other vendor apps
  • 2017-05-12: Response regarding bounty received
  • 2020-02-27: Media story regarding malware targeting this app
  • 2020-03-03: Public disclosure
  • 2020-03-04: Added comment regarding Microsoft Authenticator
  • 2020-03-23: Added clarification regarding screenshot permissions and accessibility permissions

 

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

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

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

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

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

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

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

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