### TL;DR
* Many multi-function printers made by FujiFilm Business Innovation Corporation (Fujifilm) which includes Apeos, ApeosPro, PrimeLink and RevoriaPress brands as well as Xerox Corporation (Xerox) which includes VersaLink, PrimeLink, and WorkCentre brands, allow administrators to store credentials on them to allow users to upload scans and other files to FTP and SMB file servers.
* With the default configuration of these printers, it’s possible to retrieve these credentials in an encrypted format without authenticating to the printer.
* A vulnerability in the encryption process of these credentials means that you can decrypt them with responses from the web interface. This has been given the ID CVE-2023-46327.
### Credential Decryption from Fujifilm Multi-Function Printers
CVSS 5.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N Base Score: 5.4
Multiple MFPs (multifunction printers) provided by FUJIFILM Business Innovation Corp. and Xerox Corporation provide a facility to export the contents of their Address Book encrypted, but the encryption strength is insufficient.
The affected devices and versions are [listed here]().
### Retrieving credentials
On an internal infrastructure test, I ([@Root_Kunal]()) identified a Xerox multi-function Printer which I was trying to enumerate for common vulnerabilities like default credentials or easily guessable credentials for the admin interface etc. I could see there were entries in the Address Book, When looking at the Address Book, I could see that there were entries in there but when I clicked any of them, I was given a “You do not have permission to use this feature” error.
I decided to see what the request for these contacts looked like and noticed that nothing was being sent to the web server when clicking a contact name and receiving the error. This usually means that the data has been requested already and there is a JavaScript check to see if the user has permission to access the data. In other words, I could retrieve the contact information even though I seemingly did not have permission.
I navigated away from the Address Book section of the device and clicked it again. The request that was made looked like this:
The response was a SOAP XML document with embedded JSON data which includes all the entries that existed within the Address Book. It also included **encrypted credentials** for the SMB and FTP servers (if any) which the users’ scans could upload to. An entry from the Address Book in the JSON looked something like this:
KeyName and CipherValue definitely piqued my interest! I asked around internally if anyone could give me a hand at trying to find out:
1. If the data provided in the response is enough to decrypt the credentials.
2. And if so, how to decrypt them.
### Decrypting the credentials
My [colleague]() had a look at the response and identified that the KeyName was a Base64 encoded SHA-1 hash and that the plaintext for this hash was an easily guessable value.
This led him to reverse engineering the firmware to identify how the CipherValue (AKA the password) was derived. Once the code for encryption was identified, the decryption process was just the reverse of this and it was as follows:
1. Generate a MD5 hash of the SHA1 hash of the static key.
2. Base64 decode the value returned in the CypherValue attribute.
3. Take the first 16 bytes of the decoded value. This is the IV for the encryption algorithm.
4. Take the remaining bytes of the decoded value, this is the encrypted password for the Address Book entry in blocks of 16 bytes AES CBC.
5. Use the key generated previously (step 1) with AES encryption in ECB mode to obtain the decrypted IV.
6. Use this decrypted IV with the AES encryption Algorithm in CBC mode and the key generated previously to decrypt the password from step 4 while removing any padding.
We’ve withheld a POC script for this for the moment to ensure that all devices have had an opportunity to be patched.
### Extra research
We then looked to Shodan to identify how widespread this issue was or if this was an isolated issue. We identified 1917 of these devices exposed on the internet. During some internal research, we also identified two other static keys in use.
### Mitigations
There are configuration options across the devices which can prevent anonymous users from being able to request the Address Book from an unauthenticated perspective. These should be implemented to ensure that access to the Address Book is configured with the “Restrict” or “Locked” settings rather than the “Hide” setting (as we saw cases where it was hidden but it was possible to still request the Address ). Refer to your printer’s manual for instructions on how to perform this action as it varies from device to device.
An update has been released by FujiFilm and Xerox for these devices which will prevent the data being sent in the API:
[https://www.fujifilm.com/fbglobal/eng/company/news/notice/2023/1031_addressbook_announce.html]()
Xerox have released their publication here:
[https://security.business.xerox.com/en-us/documents/bulletins/]()
Japanese Vulnerability Notes have released their publication here:
[https://jvn.jp/en/vu/JVNVU96482726/]()
### Disclosure timeline
* 21st June 2023 – Initial disclosure to FujiFilm.
* 30th June 2023 – Acceptance of vulnerability.
* 8th September 2023 – Research by FujiFilm confirmed at minimum 160 devices/models were affected. FujiFilm detailed that the access control issue on the Address Book could be remediated through configuration changes on the devices and that fix is being developed for encryption issues.
* 15th September 2023 – PTP requested clarification on the access control vulnerability to ensure it could be remediated.
* 31st October 2023 – Advisories and patches released.
The post [FujiFilm printer credentials encryption issue fixed]() first appeared on [Pen Test Partners]().Read More