Author: dleinich
Publication Date: 11/13/2015 15:26

A recent blog entry by FoxGlove Security and also heise.de discloses a vulnerability that affects a core Java functionality. Abusing this vulnerability allows an attacker to remotely execute arbitrary code on the server system with server permissions.

Today we want to provide information about how the vulnerability affects FirstSpirit and its ecosystem as well as details on how we handle the issue and what you can do to secure your systems.

Be aware that this vulnerability affects many Java applications as it is a general Java issue. The information contained in this article is thus not showing the whole picture but is focused solely on FirstSpirit.

FirstSpirit Core

The FirstSpirit Content Management System is not affected by the known variants of the vulnerability using the libraries commons-collections, groovy or spring. It is possible that there are unknown attack vectors using the vulnerability which are not yet known so we continue to actively investigate this matter and will update this article as we learn more.

Update 2015-11-17: We released a Hotfix Build (5.2.212) containing a generic fix for this vulnerability. This fix implements functionality protecting against unknown attack vectors abusing the serialization vulnerability. If you run FirstSpirit in an unprotected environment or think you may be vulnerable to other attack vectors we recommend updating to this version to enhance the overall security of your FirstSpirit installation. If you experience any problems with this update, please contact the Technical Support team like you are used to. Make sure to test the Hotfix Build in a non productive environment first.

Update 2015-12-02: The latest release of FirstSpirit 4.2R4 (4.2.507) now also includes the aforementioned general fix and is available through the Technical Support.

Course of action: If you want to secure your FirstSpirit installation against the known attack vectors, no action is required. For enhanced security in unprotected environments we recommend updating to the latest Hotfix Build (5.2.212) providing a more generic fix. Please also keep your FirstSpirit 4.2R4 installations up to date to benefit from the latest bug fixes including the security fix mentioned above.

FirstSpirit Modules (product extensions)

You are able to extend the functionality of the core FirstSpirit system using modules. The so called product extensions you can also find on our Marketplace are implemented by e-Spirit or its partners. We did identify the following product extensions that are using known vulnerable libraries:

• FirstSpirit Object Service (FOS)
• FormEdit
• UX-Bridge
• Pixelboxx Connect
• SocialNetworking
• SocialWeb
• Liferay Portal Integration EE (through FOS/UX-Bridge)

Depending on the configuration of the aforementioned modules and their availability within your network the risks do vary. As these uses are specific to your project we can not provide a universally valid risk estimation.

We are actively working to identify the exact nature of the vulnerability and develop fixes, both for the modules developed by e-Spirit and also in close cooperation with our partners providing product extensions.

Please keep an eye on this article and the FirstSpirit community in general to get informed about fixed versions or updates we will provide as we go along.

Course of action: Estimate the risk for your specific use of the product extensions and take action according to the information below.

FirstSpirit Object Service (FOS)

The FirstSpirit Object Service module (FSM) contains the library commons-collections but is not using the vulnerable functions contained therein. We will provide a release without the library shortly.

Update 2015-12-02: A new release of the FirstSpirit Object Service (2.0.2) is available that does not include the vulnerable commons-collections library anymore. The release is not available for direct download but only used as infrastructure within other modules.

FormEdit

The FormEdit component running on the servlet-container (live environment) contains a vulnerable commons-collections library but is not using the vulnerable functions contained therein. The library is required for the captcha functionality. We will provide a new release that contains a fix shortly.

Update 2015-12-02: Release 5.10 is now available. This release has the vulnerable commons-collections library replaced with a more recent version that is known to not be vulnerable anymore.

UX-Bridge

The UX-Bus component (based on Apache ActiveMQ) ships with the commons-collections library which is not mandatory. To be safe you can delete the commons-collections-3.2.1.jar from the <UX-BUS-INSTALLATION-DIRECTORY>/libs/optional/ directory. In addition, using an authentication mechanism can provide additional security.

The UX-Bridge release ships with example source code. That code has commons-collections as a dependency. Please check your implementations based on our example code for vulnerabilites.

Update 2015-12-02: The latest release of the UX-Bridge (1.6.5) has the vulnerable commons-collections library removed as it was not mandatory. It is still used in the example source code, though.

Pixelboxx Connect

Pixelboxx Connect does use java deserialization for storing its configuration. It is only vulnerable if an attacker can manipulate the serialized files. This requires write access to the filesystem which should only be the case if the server has already been compromised.

SocialNetworking

SocialNetworking does use java deserialization for storing its configuration. It is only vulnerable if an attacker can manipulate the serialized files. This requires write access to the filesystem which should only be the case if the server has already been compromised.

SocialWeb

The SocialWeb component running on the servlet-container (live environment) contains a vulnerable commons-collections library but is not using the vulnerable functions contained therein. The library is required for the captcha functionality.

Liferay Portal Integration EE

The Liferay Portal Integration EE makes use of the UX-Bridge and FirstSpirit Object Service. Please have a look at the corresponding sections for UX-Bridge and FirstSpirit Object Service above.

Update 2015-12-02: See the respective sections above for information about the fixed versions of the FirstSpirit Object Service and the UX-Bridge.

FirstSpirit Modules (project solutions)

Using the FirstSpirit API you and/or your implementation partners are able to develop FirstSpirit modules on their own, so called project solutions. As e-Spirit is not aware of the implementation details of specific project solutions we can not provide a risk estimation.

Course of action: Check your project solutions regarding this vulnerability and take respective measures. Do talk to your implementation partners to have them check the modules they have developed for you.

General Workarounds and Security Considerations

A Java-Agent that can be included upon starting a Java application is available at https://github.com/kantega/notsoserial. This agent makes well known vulnerable classes non-deserializable by rewriting their byte code when the class loads. This may be a hotfix for your applications but may also cause unexpected and unwanted side effect we currently can not assess. e-Spirit is in no way affiliated with the developers of the agent and can not be made responsible for any side effect or damages its use may cause.

Using Deep Packet Inspection (DPI) it is possible to identify and handle malicious packets that include vulnerable Java class names. According to our own research, filtering for the following classes helps preventing attacks using the known attack vectors: AnnotationInvocationHandler, InvokerTransformer and MethodClosure.

To make it more difficult for an attacker detecting and injecting serialized Java objects in the communication between a FirstSpirit client and the server it is advised to only allow encrypted connections between these two. You can enforce this using the ALLOWED_ENCRYPTIONS parameter in the fs-server.conf which is explained in our Manual for Administrator in chapter 4.3.1.1.

If you operate an Internet facing FirstSpirit installation it is generally important to put a focus on securing the application, just like you would do with any other application available from the Internet. Please see the following document on enhancing the overall security in a scenario like this using a web application firewall (WAF) and web access management (WAM): https://community.e-spirit.com/docs/DOC-1881.

Further Information

We will update this article as we learn more. Please also keep an eye on the community in general, especially the customer space of the community to immediately learn about product extension releases fixing known vulnerabilities.

To dive deeper into the vulnerability in general we recommend the following articles:

• Vulnerability Description by FoxGlove Security
• Remotely Exploitable Java Zero Day Exploits through Deserialization by InfoQ
• Zero-Day-Alarm für viele Server mit Java by heise.de

If you have any questions regarding this matter, please contact our Technical Support team who will provide answers and help keeping your FirstSpirit system secure to our best knowledge.