Security Reference Guide

Exploiting Scan to PC/Desktop Applications

Last updated Aug 22, 2008.

In the previous section we introduced the Kyocera Mita File Utility solution and started to take a look at some of the bugs in the product. We were able to bypass authentication, remotely extract the password from the client, and perform an identification enumeration attack. In this section we are going to build on these flaws and illustrate how the scan to PC solution can be abused to give a remote attacker the ability to upload fake documents to a victims PC — and more.

Inject Spoofed Documents

The main function of the Kyocera scan to PC software is to provide a method for converting hard copy into a digital file that automatically is transferred to the users desktop. A key element of this process is trust — trust that the document is coming from a valid user, and trust that the document is valid. Without this inherent piece of the solution, a fraudulent document could be created and uploaded to the user's PC. In addition, if the default settings are left in place, any existing document could be overwritten. As a result, it would be trivial for an attacker to wait for an important document to be transferred to the users PC, capture the name of that document via a sniffer, and then upload an alternate document. Given that one popular use of the scan to PC software is to create email-friendly copies of documentation, including contracts and other important data, it is easy to imagine several ways this type of attack can be used against an unsuspecting victim.

As we previously illustrated, the desktop side component of the Kyocera solution does not include any real security mechanisms to prevent an attacker from interacting with it. This includes the file transfer process. The end result is that it is trivial for a remote attacker to create a document and transfer it to the end user without authentication. With only a little data massaging, an attacker can specify the file name and replace the PDF file that is sent to the user's desktop. The following packet data details how this information is passed. This is the third packet passed by the printer during the transfer process.

0x00, 0x54,				#Control Information
0x30,					    #Packet Size
0x01,0x00, 0x05, 0x00, 0x00, 
0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 	
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x53, 0x43, 	#Start of file name (SCAN0840.pdf)
0x41, 0x4e, 0x30, 0x38, 0x34, 0x30, 0x5f, 0x30, 
0x30, 0x30, 0x2e, 0x70, 0x64, 0x66, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00

The following is the first few bytes of the fourth packet, which contains the actual file content.

0x60, 0x00, 				                #File size
0x25, 0x50, 0x44, 0x46, 0x2d, 0x31, 		# PDF Header

Inject a Payload

Once we determined the Kyocera File Utility would accept any PDF file, the next thing to test was to see if we could upload any file to the user's PC. To test this, we stripped out the PDF file from the transfer process and replaced it with a small string of characters. In addition to this, we also modified the name of the file to Kyocera.txt and submitted the "document" to the File Utility listener, which accepted it as valid.

We next altered the content of the file to "calc.exe" and changed the name of the file to Kyocera.bat, which again was accepted. This tells us the File Utility does not perform any content checking on the data it is accepting from the "copier." As a result, we now know that we can upload executables, images, and more.

The final test was to see if the File Utility program filtered out special characters that do not belong in a file name. To test this, we changed the name of the file to "../../start menu/programs/startup/Kyocera.bat" and spoofed the transfer process. The client accepted the filename and placed a copy of Kyocera.bat in the Start Up folder, which would be executed at the next startup. In this case we only inserted a batch file with a command of "calc.exe;" however, it is also possible to inject an executable, which would launch on a reboot.

00000226 00 54 30 01 00 05 00 00 ff ff ff ff 00 00 00 00 .T0	..... ........
00000236 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 	........ ........
00000246 00 00 00 00 00 24 2e 2e 2f 2e 2e 2f 73 74 61 72	 .....$.. /../star
00000256 74 20 6d 65 6e 75 2f 70 72 6f 67 72 61 6d 73 2f t	 menu/p rograms/
00000266 73 74 61 72 74 75 70 2f 6b 79 6f 63 65 72 61 2e 	startup/ kyocera.
00000276 62 61 74 00 00 00 00 00 00 08 63 61 6c 63 2e 65 	bat..... ..calc.e
00000286 78 65                      			xe

Denial of Service to Process

In addition to the various spoofing and data altering bugs that exist in the File Utility, the client can be remotely locked or killed via a malformed document or request. This is fairly trivial and is accomplished by inserting incorrect field length values and padding the actual data that passed during the communication session.

Summary of Issues and Resolution

In this two part series on Kyocera’s scan to PC solution, we discovered that not only can the File Utility be tricked into accepting a document from an untrusted source, but a remote attacker can also upload any file and, depending on the version of File Utility, place that file almost anywhere on the victim’s machine. This was made possible thanks to a poorly designed authentication system, revealing error messages, a lack of encryption, and no validation to ensure the document came from the printer and not some third party, such as an attacker.

To fix the problem, Kyocera should use a certificate-based encryption scheme to authenticate both the File Utility and the Printer and encrypt the traffic passing between the two parties. This would prevent someone from sniffing sensitive data off the wire, and also ensure the printer and PC are communicating with a permitted device. With such protection in place, all of the attacks discussed in this article would be nullified.

White Wolf Labs has posted a Metasploit Module that automates the enumeration process, extracts the password from the File Utility, and allows a user to specify a custom sender, file name, upload location, as well as the files content.