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.