author avatar
By Casey ErdmannSecurity Engineer

*Views, thoughts, and opinions expressed in this post belong solely to the author, and not necessarily to SemanticBits.

During a private software security audit of the Liferay Portal application, a new persistent cross-site scripting (XSS) vulnerability was discovered that impacts Liferay software versions 7.1.0 – 7.2.1. This article will provide details around how the vulnerability was discovered, the disclosure timeline with Liferay, and what the specific impact is.

CVE: CVE-2020-7934

What is Persistent XSS?

Persistent XSS is a specific category of “cross-site scripting” vulnerability that allows some malicious code (commonly JavaScript) to persist, or store itself, in the application it is exploiting. In the case of the Liferay Portal, this code can be stored in values that are modified by the user, such as their name, which is stored in the database connected to the application. This means that any time someone views a vulnerable page that would normally display another user’s name, the JavaScript code will execute instead. This will happen everytime the name fields are rendered until the value is changed in the infected user’s profile.

Authenticated Persistent Cross-Site Scripting (XSS) in Liferay Portal 7.1.0 – 7.2.1

At Semanticbits, the security team is very involved in risk assessments around applications. Security engineers constantly conduct routine audit activity, penetration testing, and vulnerability research to ensure the software it is either building or using in its environments is secure and up to the standards of its clients.

Liferay Portal was in consideration for use as a product to serve a static website for a particular project. This site would be providing content to support informational aspects of the actual application built for that project. All software products that the Semanticbits team decides to use for this project undergo a strict vetting process that includes risk assessments for vulnerabilities of a particular software product. In many cases Semanticbits’ security engineers may actually need to perform proper vulnerability research to ensure that public vulnerabilities do actually apply to a particular software product and its use case within a given project’s environment. 

In the case of the Liferay Portal, various vulnerabilities existed in previous versions. So, we wanted to be sure that the latest version of the product was still meeting standards for us to make a sound decision on tooling for this particular project. A penetration test was conducted against a simple local instance of the application with the goal of identifying any and all vulnerabilities that may not be accounted for in the documented public research. As a result, a new XSS vulnerability was discovered while testing for XSS in the Liferay Portal application.

The vulnerability exists within the MyAccount Portlet component, and the XSS payload is executed by the returned results of a user search.

Specifically, the First Name, Middle Name, and Last Name fields for user accounts are all vulnerable to a Persistent XSS issue. Any user can modify these fields on their own profile with a particular XSS payload and it will be stored in the database “infecting” the user. The payload will then be rendered when a user utilizes the search feature to search for other users. If the infected user is displayed as a search result, the XSS payload will execute.

Researcher: Casey Erdmann, Security Engineer

Date Discovered: 10/17/2019

Date Disclosed: 10/18/2019

Disclosure Timeline:

Date Description of Communications
10.18.2019  

An encrypted email was sent to Liferay containing an explanation of the disclosure and a full technical report. Disclosure advises industry standard remediation within 90 days. Disclosure also relays intent comply with Liferay’s vulnerability disclosure program to keep the findings private until a fix is released.

https://www.liferay.com/security-statement

10.21.2019 Liferay responds to the disclosure report and verifies that the findings are valid. Line of communication is established to receive updates on remediation.
10.28.2019 Liferay reports back that the root cause of the vulnerability has been fully confirmed and they are working to backport a fix to affected branches.
11.18.2019 Researcher reaches out with a request for updates.
11.19.2019 Liferay responds, but the key correspondence contact is unable to provide new information, and states they will follow up as soon as they have updates.
11.21.2019 Liferay provides an update that remediation is still in progress for all supported products.
12.16.2019 Researcher reaches out with a request for new updates.
12.18.2019 Liferay provides an update that the backports for fixes are complete but the releases are still pending.
01.13.2020 Researcher reaches out with a request for new updates.
01.15.2020

Liferay provides an update that the fix is partially released, but will not have it released before the 90 day period has ended. 

While the original intent was to withhold disclosure until a fix was released, Liferay was transparent about being unaware of an exact timeline for release. Because of this, Liferay states they support the public disclosure of this vulnerability, and will assist in providing accurate information for a CVE listing and Public Disclosure.

SemanticBits team decides to proceed with Public Disclosure.

Impact

Vulnerabilities of this nature allow the user to do many things. Commonly, XSS vulnerabilities are used to hijack session tokens, deface websites, phish users, and steal sensitive information. This vulnerability is no different but, due to some of the features within Liferay, it provides the potential for more damaging impacts beyond the client side.

To exploit this vulnerability requires proper access to login to the Liferay Portal. This is an Authenticated Persistent XSS issue and cannot be arbitrarily triggered without a user account. This vulnerability allows an attacker to execute arbitrary JavaScript code in the context of any user that triggers the XSS payload via a search. In a practical sense, this can lead to privilege escalation from a non-privileged user to an administrative user. It can also lead to lateral movement in taking over other accounts. Anything that can be executed via JavaScript can be exploited in the context of another user.

Proof of concept payloads are being withheld from this disclosure report for the time being. While it will not be demonstrated in this report, one such payload is able to load in fully external script references. This means an attacker can easily use complex JavaScript files and reference them externally instead of needing to fit an entire payload into the application itself.

Most of the important Session Cookies are flagged as HttpOnly in the default Liferay Portal configuration. This is good, as it mostly prevents simple session hijacking techniques. That said, it should be noted that users viewing the page with older browsers are even more impacted by this thanks to XST attacks.

While session hijacking is difficult, JavaScript is still executed in the context of another user’s session. An attacker can make use of AJAX requests in their payload to perform request actions on behalf of an impacted user. This is especially true since a full external script reference can be loaded with relative ease. One critical impact to note for this is that Admin users can execute Gogo Shell and Groovy Script Commands in the Liferay Portal as a supported feature. As such, this vulnerability provides the possibility to chain a properly crafted payload together with the features of the application in a way that can result in unintended Remote Code Execution (RCE) on the host. In other words, a normal user of the Liferay Portal could attempt to exploit an Admin user’s context to gain RCE via a properly crafted XSS payload.

Remediation

Unfortunately, there is no fix from Liferay at the time of this report. We will provide an update and full proof of concept disclosures in due time when fixes are available.

As a general guidance, this vulnerability requires authentication to exploit. It is recommended that you are enforcing strong password policies for your user accounts to prevent unauthorized individuals from gaining access to accounts. Employing a WAF solution in front of your Liferay instance can also potentially mitigate some of the risk.