Directory Traversal Affecting org.igniterealtime.openfire:xmppserver package, versions [3.10.0,][4.7.0,]

org.igniterealtime.openfire:xmppserver is an is a XMPP server licensed under the Open Source Apache License.

Affected versions of this package are vulnerable to Directory Traversal via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users. Path traversal protections were already in place to protect against exactly this kind of attack, but didn’t defend against certain non-standard URL encoding for UTF-16 characters, that were not supported by the embedded webserver that was in use at the time.

Impact:

The combination of the wildcard pattern matching and path traversal vulnerability allows a malicious user to bypass authentication requirements for Admin Console pages.

Note:

Users should be aware that the new configuration properties can interfere with the functionality of certain Openfire plugins. This is especially true for plugins that bind a (web)endpoint to the embedded webserver that serves the Openfire administrative console, like current versions of the REST API plugin do. For these plugins to remain functional and/or reachable, it might be required to toggle the property adminConsole.access.allow-wildcards-in-excludes to true, and to avoid binding the embedded webserver to the loopback network interface only.

When the server uses older versions of the following plugins, users should make sure to upgrade them:

• Random Avatar plugin, update to version 1.1.0 or later.
• Monitoring Service plugin, update to version 2.5.0 or later.
• HTTP File Upload plugin, update to version 1.3.0 or later.

Users can take any of the following steps to mitigate the risk:

Through Openfire plugins, the effectiveness of some mitigations listed below can be reduced, while other mitigations might affect the functionality of plugins. Particular care should be taken when using the Monitoring Service plugin, REST API plugin, User Service plugin and/or Random Avatar plugin.

1) Restrict network access

Use network security measures (network ACLs and/or firewalls, VPNs) to ensure only trusted members of your community have access to the Openfire Admin Console. As a general rule, never expose the Openfire Admin Console to the general internet.

Examples:

• On a linux machine running ufw, deny ports 9090 and 9091 on non-loopback interfaces
• On a Windows machine, restrict the rules that open ports 9090 and 9091 to only allow traffic from the IPv4 and/or IPv6 loopback addresses
• On AWS cloud infrastructure, use EC2 Security Groups to restrict ports 9090 and 9091 to trusted IP addresses. If the trusted range is necessarily too broad, consider opening and closing the ports only as necessary
• If using Docker, instead of docker run ... -p 5222:5222 -p 9090:9090 -p 9091:9091 openfire prevent remote access to the Admin Console with docker run ... -p 5222:5222 -p 127.0.0.1:9090:9090 -p 127.0.0.1:9091:9091 openfire

2) Modify runtime configuration file

To close the avenue of potential attack, a runtime configuration file of Openfire can be modified.

In Openfire's installation directory, find the file plugins/admin/webapp/WEB-INF/web.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find a <filter> element, that contains the <filter-name>AuthCheck</filter-name> child element. Depending on your version of Openfire, it will look similar to this:

<filter>
    <filter-name>AuthCheck</filter-name>
    <filter-class>org.jivesoftware.admin.AuthCheckFilter</filter-class>
    <init-param>
        <param-name>excludes</param-name>
        <param-value>
            login.jsp,index.jsp?logout=true,setup/index.jsp,setup/setup-*,.gif,.png,error-serverdown.jsp,loginToken.jsp
        </param-value>
    </init-param>
</filter>

The value inside of the param-value element is a comma-separated list of values. From this list, remove all * (asterisk) characters.

Save the file, and restart Openfire for the change to take effect.

Note that no guarantees can be given that this runtime configuration change persists over time. Ensure to monitor the presence of the fix. It is recommended to upgrade to a safe version of Openfire as soon as possible.

A side-effect of this change is that the Openfire web-based setup wizard will not function properly (functionality can be restored by reverting the change). This wizard is typically used only when initially installing Openfire.

3) Bind admin console to loopback interface

The Openfire admin console is a web-based application. By default, the corresponding webserver (that is embedded in Openfire) binds to all network interfaces of the host that it is running on.

The admin console can be configured to bind to a specific network interface. This will prevent it from being accessed through other network interfaces. By configuring the admin console to bind to the local loopback interface, it is accessible only to users on the server itself. This reduces the avenue of attack.

Note that several Openfire plugins expose part or all of their functionality through the admin console webserver. The REST API plugin, for example, serves its endpoints via this webserver. Availability of this functionality will be affected by binding the webserver to a specific network interface.

To bind the webserver of the Openfire admin console to a specific network interface, the 'openfire.xml' configuration file can be used.

In Openfire's installation directory, locate the file conf/openfire.xml. After creating a backup of this file, edit the original file.

The content of this file is XML. Find the <adminConsole> element that is a direct child element of the root <jive> element. Add a new element, named <interface> as a child element of <adminConsole>. The value of the <interface> element should be the name of the loopback interface or interface address. Setting value to 127.0.0.1 works on all tested environments (using values like lo on most Linux systems or lo0 on macOS will have the same effect).

The resulting fragment of the openfire.xml file will look similar to this:

<?xml version="1.0" encoding="UTF-8"?>
<jive>
  <adminConsole>
      <interface>127.0.0.1</interface>
      <port>9090</port>
      <securePort>9091</securePort>
  </adminConsole>

  ...

Save the file, and restart Openfire for the change to take effect.

4) Use AuthFilterSanitizer plugin

The Ignite Realtime community has made available a new plugin, called the AuthFilterSanitizer plugin. The plugin can be installed from the Openfire admin console, or can be downloaded from the plugin's archive page on the IgniteRealtime.org community website.

This plugin periodically removes entries for Openfire's authentication filter that are susceptible to abuse, closing the avenue of potential attack.

Note that this plugin might interfere with functionality that depends on the abuse-susceptible entries in the authentication filter that might be provided by plugins.

To test if an instance of Openfire is affected, follow these steps. Open a browser in incognito mode, or otherwise ensure that there is no authenticated session with the Openfire admin console. Open the following URL (possibly modified for the hostname of the server that is running Openfire):

http://localhost:9090/setup/setup-s/%u002e%u002e/%u002e%u002e/log.jsp

If this shows part of the openfire logfiles, then the instance of Openfire is affected by this vulnerability. Note that different versions of Openfire will show a different layout. Newer versions of Openfire can be expected to show log files on a dark background, while older versions will show a largely white page. (Depending on the content of the log file, this page might be empty, apart from a header!)

If there's a redirect to the login page, the instance is likely unaffected.

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys

• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release
• Jira Issue
• Nuclei Templates
• CISA - Known Exploited Vulnerabilities