During an external penetration test, White Oak Security discovered an instance of the Extensis Portfolio software which was deployed publicly on the internet with default administrative credentials. Using black-box web application testing techniques, White Oak Security was able to achieve remote code execution via an unrestricted file upload. This was a newly discovered (“zero day”) vulnerability in the software, making Extensis Portfolio Server a subject for further research. White Oak Security applied its comprehensive white box application penetration testing program to recreate the environment locally and began analyzing the source code for additional vulnerabilities.
As part of this research, White Oak Security discovered five (5) High-Risk flaws within the Extensis Portfolio application (Versions 4.0 and Version 3.6.3):
- Main & Admin Portals: Authentication Bypass – Hard-Coded Credentials (CVE-2022-24255)
- Main Portal: Authenticated Unrestricted File Upload Resulting in Remote Code Execution (CVE-2022-24251)
- Main Portal: Authenticated Unrestricted File Upload + Path Traversal Resulting in Remote Code Execution (CVE-2022-24252)
- Admin Portal: Authenticated Archive Zip-Slip Path Traversal Resulting in Remote Code Execution (CVE-2022-24254)
- Admin Portal: Authenticated Unrestricted File Upload Resulting in Remote Code Execution (CVE-2022-24253)
For a temporary fix of the authentication bypass, please check this blog post.
Extensis Portfolio Overview
Extensis Portfolio is a digital asset management platform used by content teams to organize their digital media into various content catalogs and provides a hosting platform for digital assets. Extensis Portfolio is made up of three (3) core applications: a user-facing content management application (referred to as “main”), an administrative portal, and a content hosting application. Typically, only the main portal application is exposed on the internet. However, several administrative portals have been found exposed to the internet as well. A majority of the application features deal with the management of multimedia files, including the ability to upload and download images and videos.
Unfortunately, Extensis was not receptive to the disclosure of these vulnerabilities and has not made a patch available at this time. As such, White Oak Security is compelled to disclose these issues publicly. For additional information around our disclosure timeline, please refer to the end of this post.
Extensis Portfolio Vulnerability Analysis
Main & Admin Portals: Authentication Bypass – Hard-Coded Credentials
CVE-2022-24255
One of the first findings White Oak Security discovered was an instance of Hard-Coded Credentials within the main and admin portal applications’ authentication flow. These credentials are a ‘backdoor’ password into the applications, gaining the permissions of an administrative user. A malicious threat actor can use these capabilities to exploit the remainder of the issues described in this post.
First, an administrator creates or updates their account with a non-default password. In the example below, the administrative user will have a unique password set.
Next, a user attempts to authenticate into the main portal application as the administrative user with an invalid password. The application correctly denies the authentication since the password is incorrect.
Then, the user authenticates into the same application with the hard-coded backdoor password. (Note: This password is not included in this disclosure at this time as a patch for this issue has not been made available by Extensis.)
The application successfully processes this authentication request and the user authenticates as the administrative user.
Note, this authentication bypass also works for the admin portal as the authentication flow implements the same code path.
Using the hard-coded password, a user can gain access to a visually limited administrative view into the application. However, this user’s administrative session does have full permissions over the application.
Using the session generated with the hard-coded credentials, a malicious user can craft a request to the /user/ API and modify the current administrator’s password to a value of their choosing. Note: This password is hashed client side and the value can easily be generated by performing a sample login request to get the generated value.
Successful password update for the administrator account.
Authenticating into the administrator portal with these new credentials allows for full UI access into the other administrative settings granting full control over the application. This password change also applies to the main portal application, granting full administrative control over that application as well.
This vulnerability exists because of hard-coded credentials implemented in
C:\Program Files (x86)\Extensis\Portfolio Server\applications\tomcat\servers\main\webapps\ROOT\WEB-INF\lib\portfolio-classes.jar.Main Portal: Authenticated Unrestricted File Upload Resulting In Remote Code Execution
CVE-2022-24251
White Oak Security discovered a chain of events during typical file uploads within the main portal application that can result in remote code execution. First, the application does not properly allow list and perform content inspection on the files that are uploaded to the catalog. By default, any file can be uploaded to the portal application. A malicious threat actor can upload a JSP file that contains a simple web shell to achieve code execution against the underlying web server.
Next, the application provides built-in functionality to “export” uploaded files to any location on the local system. It is unclear why this is a feature of the application, but at the very least, the application should be allow listing the specific directories that a file could be exported to on the local system.
Therefore, it becomes trivial to export a malicious JSP file into the web root of the application which results in code execution.
The file is successfully copied to the web root:
The malicious JSP file can be used to execute operating system commands, such as “whoami”, demonstrating code execution as SYSTEM:
Main Portal: Authenticated Unrestricted File Upload + Path Traversal Resulting in Remote Code Execution
CVE-2022-24252
White Oak Security identified a second instance of an unrestricted file uploads within the Main Portal application:
Extensis Portfolio provides functionality for custom scripts to be executed server-side (1) using the Nashorn scripting engine. While the use of the Nashorn scripting engine can be secure, a default implementation is often configured to load arbitrary classes (and consequently, execute remote code) if no class allow list protections are in place (2).
These scripts must be placed within the “custom-scripts” directory in the application root to be executed. However, the “custom-scripts” directory is not created by default in a standard Extensis Portfolio installation.
Therefore, the following vulnerabilities must be exploited within Extensis Portfolio in order for remote code execution to occur:
- Unrestricted Directory Creation
- Lack Of Class Allow List Within The Nashorn Scripting Engine
- Unrestricted File Upload + Path Traversal
Unrestricted Directory Creation
The “custom-scripts” directory does not exist in a default Portfolio installation. This folder would be created by a developer within the “data/” directory.
The good news for a malicious actor is that the Portfolio application exposes an API (/identity/verify-folder) which will create any arbitrary local directory specified on the server. The “create” URL parameter is what enables this directory creation within the source code.
It’s important to note for exploitation purposes, any script placed within this directory will be automatically executed when a user authenticates into the Portfolio application. This is the default behavior of scripts placed within this directory, as these scripts are intended to be used to provide extra functionality for the web application. The scripts are automatically executed based on default interactions with the application (and subsequent API requests) as a user interacts with the Portfolio application UI.
Lack Of Class Allow Listing Within The Nashorn Scripting Engine
White Oak Security crafted a custom script that will be executed by the scripting engine. This script uses reflection to load an instance of the Java Runtime, which allows arbitrary commands to be executed. After analyzing the source code and configuration files, no class allow listing was in place within the Extensis Portfolio application. Any arbitrary class can be loaded within these scripts. The following script, when executed, will establish a session on a remote victim host using a simple reverse shell. This script could add a web shell, create user accounts, or do any other malicious actions against the underlying server to give an attacker full control over the application.
function getProperties() {
return {
triggerPoints: [ 'onCataloged', 'onMetadataUpdated', 'onGalleryChanged', 'onJobInitialize', 'onJobEachAsset', 'onJobFinalize' ],
scheduleInfo: { cronExpression: '0 0 0/4 * * ?', eventId: 'my-scheduled-script' },
displayName: 'Test Script',
permissions: [ 'canAdministerCatalog' ],
hasDownloadResult: false,
processCurrentOrganizer: true,
processNoAssets: false
};
}
function onCataloged(catalogId, assetId) {
portfolio.log('onCataloged called for catalog ' + catalogId + ', asset ' + assetId);
}
function onGalleryChanged(catalogId, galleryId, wereItemsAdded, assetQuery, assetCount) {
portfolio.log('onGalleryChanged called for catalog ' + catalogId + ', gallery ' + galleryId + ', ' + assetCount + ' assets ' + (wereItemsAdded ? 'added' : 'removed'));
}
function onMetadataUpdated(catalogId, assetId, changes) {
portfolio.log('onMetadataUpdated called for catalog ' + catalogId + ', asset ' + assetId);
}
function onSchedule() {
portfolio.log('scheduled script running');
}
function onJobInitialize(data) {
portfolio.log('onJobInitialize called for catalog ' + data.catalogId);
}
function onJobEachAsset(data) {
portfolio.log('onJobEachAsset called for catalog ' + data.catalogId + ', asset ' + data.itemState.assetId);
}
function onJobFinalize(data) {
portfolio.log('onJobFinalize called for catalog ' + data.catalogId);
}
function getIndexOfMethod(methodArray, methodName){
var count = 0;for each (var method in methodArray){if(method.toString() == methodName){return count;}count++;}return null;
}
// Payload goes here
var command = "<payload here>";
// Create an instance of class 'Class'
var obj = ''['class'];
// Get the list of all the methods
var methods = obj.getClass().getMethods();
// Find the index of 'forName()' method
var forNameString = "public static java.lang.Class java.lang.Class.forName(java.lang.String) throws java.lang.ClassNotFoundException";
var forNameMethodIndex = getIndexOfMethod(methods, forNameString);
// Find the index of 'getRuntime()' method
var runTimeMethods = methods[forNameMethodIndex].invoke(null, 'java.lang.Runtime').getMethods();
var getRuntimeString = "public static java.lang.Runtime java.lang.Runtime.getRuntime()";
var getRunTimeMethodIndex = getIndexOfMethod(runTimeMethods, getRuntimeString);
// Execute the command
runTimeMethods[getRunTimeMethodIndex].invoke(null).exec(command);Unrestricted File Upload + Path Traversal
Next, White Oak Security needed an unrestricted file upload vulnerability to place this script within the “custom-scripts” directory. An unrestricted file upload vulnerability was discovered within the FileTransferServlet. A tainted file name containing relative paths will place this file on an arbitrary location on a disk. In this case, the “custom-scripts” directory was targeted.
Successful file upload response to the targeted location.
However, when navigating to the “custom-scripts” directory, the file was not there. White Oak Security observed that this file upload does not actually persist on disk. The file is only created temporarily and then deleted from the file system. White Oak Security monitored the custom-scripts directory and observed that the “aaaa.js” file was created and then immediately deleted during the upload request.
White Oak Security analyzed the source code for this file upload flow and found that the function is vulnerable to a time of check to time of use race condition (3). The application creates a temporary file from the uploaded file content, moves this file to the arbitrary location in the filename, and saves the file content to the database to store metadata used for image previews. Once the database save occurs, the file is subsequently deleted from the disk. If files are uploaded over and over within a short period of time, due to a lack of file locks, the web server will not be able to delete the file before a user can interact with the web server. Therefore, a period of time exists between the creation and deletion of the file where a user can actually execute the script. In this case, the script contains malicious code which could be used to gain command execution against the underlying server. In this proof of concept, White Oak Security will execute a reverse shell which gains remote system access against the web server.
White Oak Security used Burp Suite Intruder to execute upload requests sequentially over a short period of time with no delay between requests. An alternative method to exploitation could be to keep a single request open rather than sending the “close” connection header.
Observing the local file system, it was observed that several scripts are successfully uploaded to the custom-scripts directory before being deleted since the application does not lock the files before deletion.
At the same time as the first intruder upload requests, White Oak Security used Burp Suite Intruder to constantly poll the web server while the file upload was occurring. Since the custom scripts will actually execute on nearly every API request and the scripts do not have to be accessed directly, an example API request below will trigger the command execution if the script exists within the “custom-scripts” directory when this API request is called.
White Oak Security monitored the attacker host for incoming connections and observed the results of the command execution. Multiple sessions were opened as the race condition attack was successful over multiple attack iterations. White Oak Security was able to retrieve the current working directory of a given reverse shell using the ‘pwd’ command as an example to demonstrate remote code execution. Since the application (rather than the file) is the executing process, the reverse shell is persistent even after the temporary files are deleted after the race condition requests are complete.
Admin Portal: Authenticated Archive Zip-Slip Path Traversal Resulting in Remote Code Execution
CVE-2022-24254
White Oak Security also analyzed the Admin Portal application and identified two more vulnerabilities which result in remote code execution. While the Admin Portal is not typically supposed to be exposed on the internet, instances of the admin portal can be found on the internet at the time of this blog’s creation. An instance of the Zip-Slip vulnerability was discovered within the flow for restoring the application from an archive backup.
Zip Slip (4) is a form of directory traversal that can be exploited by extracting files from an archive to an arbitrary location. The premise of the directory traversal vulnerability is that an attacker can extract a file to parts of the file system outside of the target folder in which the extracted files should reside.
First, White Oak Security created a zip archive with the expected Portfolio Server backup archive structure. A sample archive can be generated from a backup request within the admin portal, which can be used as a template for this exploit. The database content (dbdump.out) is not necessarily required, but several metadata checks from the file content do occur before the zip-slip vulnerability is triggered (such as an inspection of default data from the .data/preferences file); therefore maintaining the expected directory and file structure is highly recommended.
Next, White Oak Security used a python script, evilarc (5), to create a malicious zip file containing a JSP web shell. The web shell’s archive path was modified using the tool to include path traversal characters. Since the portfolio admin application is vulnerable to zip-slip, the web shell will be placed within the public web directory when the archive is extracted.
White Oak Security navigated to the Backup functionality within the admin portal and chose ‘Restore From Backup’.
The backup archive module is built to restore from a local backup on disk. However, the request can be captured using an HTTP proxy tool, such as Burp Suite, and the path can be modified to point to a remote web server location. An alternative exploitation path could use any of the unrestricted file upload vulnerabilities within this post.
The application will begin the backup process. The archive backup will most likely fail if the backup archive has been tampered with or the exact database is not restored.
However, even if the job fails, the embedded malicious file will have been successfully extracted to the destination path. In this case, the web root of the admin portal application successfully contains the web shell.
The web shell executed successfully on the admin portal application.
Admin poRtal: Authenticated Unrestricted File Upload + Path Traversal Resulting in Remote Code Execution
CVE-2022-24253
White Oak Security discovered an unrestricted file upload vulnerability within the AdminFileTransferServlet “brandingupload” functionality. An arbitrary file can be uploaded with any given filename (such as a malicious JSP containing a web shell). This filename can include path traversal characters to upload the file to a specific directory. In this example, the web shell was uploaded to the web root.
The file was successfully created within the target location inside of the web root.
The web shell executed successfully on the admin portal application.
Unofficial Mitigation for Authentication Bypass
White Oak Security recommends a temporary mitigation to the hard-coded administrative credentials. An organization can perform assembly byte patching of the Extensis jar file that handles authentication to change or remove the hard-coded credentials. Check this blog about editing Bytecode.
This hardcoded password can be found in extensis.portfolio.server.manager.ManagerUtils.authenticateUser() in the following jar file:
C:\Program Files (x86)\Extensis\Portfolio Server\applications\tomcat\servers\main\webapps\ROOT\WEB-INF\lib\portfolio-classes.jarAdditionally, White Oak Security recommends ensuring the default administrator password has been changed on your Portfolio Server install.
Extensis Suggested Mitigation for Unrestricted File Upload
Extensis provided White Oak Security with the following instructions for mitigating the initial unrestricted file upload:
This can likely be resolved via the following Portfolio Admin configuration settings :
- Cataloging only known filetypes ( recommended ) :
- Portfolio Admin > Catalogs > [ Catalog Name ] > Ingest > File Types > Catalog Only.
- Excluding specific filetypes :
- Portfolio Admin > Catalogs > [ Catalog Name ] > Ingest > File and Folder Exclusions > Ends with “.jsp”
White Oak Security has not tested these mitigations or attempted bypasses at the time of writing these blog posts and cannot comment on the effectiveness of these controls.
Disclosure Timeline
White Oak Security followed responsible disclosure guidelines by giving Extensis significant time to remediate these High-Risk issues. White Oak Security repeatedly asked Extensis for a timeline for expected remediation. However, after 164 days since initial contact regarding the vulnerabilities, Extensis informed White Oak Security that these security issues had not been prioritized and Extensis did not have an expected date for remediation.
As of 2/17/22, Extensis has not provided White Oak Security any indication that these vulnerabilities will be fixed. White Oak Security has disclosed these issues according to our vulnerability disclosure policy.
As it took White Oak Security over a month just to initiate contact with Extensis, we highly recommend Extensis create a specific security disclosure email address or contact form to facilitate and expedite future communication.
8/16/21: Attempted to contact Extensis via official Contact Form – No Response
8/25/21: Attempted to contact Extensis via official Contact Form – No Response
8/26/21: Contacted Extensis via Sales form. A sales member informed White Oak Security they will provide White Oak with a security contact. Security contact was not provided.
9/17/21: Follow up with the sales team about security contact. – Sales did not respond.
9/27/21: Contacted Extensis via Twitter DM for security contact – Extensis Twitter account informed White Oak that we cannot contact Extensis without an active contractual service agreement.
9/29/21: Leveraged a client contact to open a service ticket on behalf of White Oak Security – White Oak successfully disclosed details of an initial Unrestricted file upload vulnerability and Extensis confirmed receipt of those disclosure details.
9/29/21: Extensis informs White Oak Security that we need to test this vulnerability on the latest version of Portfolio Server (4.0.0), as several fixes have been made since the version we originally tested (3.6.3). White Oak confirms this issue is likely still present in version 4.0.0 and asks if this specific issue was remediated in the update, as the vulnerability was not described in the Patch Notes.
10/22/21: White Oak re-confirms for Extensis that the vulnerability was valid in 4.0.0 – Extensis does not respond. White Oak informs Extensis several other vulnerabilities were discovered and asks for their preferred file transfer method for sharing these details securely.
11/2/21: White Oak Security disclosed an additional four (4) vulnerabilities to Extensis – Extensis provides potential mitigation steps for unrestricted file upload.
12/6/21: White Oak Security asks for a status update on the remediation timeline – Extensis acknowledges vulnerabilities but declines to provide an ETA.
1/3/21: White Oak Security asks for a status update on the remediation timeline – Extensis acknowledges vulnerabilities but declines to provide an ETA.
1/27/21: White Oak Security asks for a status update on remediation timeline – Extensis acknowledges vulnerabilities and states that no timeline has been created for these issues, no security patch has been scheduled, and that the vulnerabilities have not been prioritized within their development queue.
2/17/22: White Oak Security publicly discloses the issues per our vulnerability disclosure policy.
Sources:
- https://doc.extensis.com/api/portfolio-scripting/script-interface/script-interface/index.html – Extensis Script API
- https://www.roguesecurity.in/2019/07/27/nashorn-remote-code-execution/ – Nashorn Remote Code Execution example
- https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use – Time of Check to Time of Use Software Bug
- https://snyk.io/research/zip-slip-vulnerability – Zip-Slip Vulnerability Overview
- https://github.com/ptoomey3/evilarc – Zip-Slip archive generation tool
