Canon Printer Firmware Pro 100 Paper Hack

Canon Printer Firmware Pro 100 Paper Hack

Canon Pixma wireless printers take a spider web interface that shows information about the printer, for example the ink levels, which allows for test pages to be printed and for the firmware to exist checked for updates.


Figure i – Web Interface Pixma MG6450

This interface does not require user authentication assuasive anyone to connect to the interface.  At first glance the functionality seems to be relatively benign, yous could print out hundreds of test pages and use up all the ink and paper, and so what?  The effect is with the firmware update process.  While y’all can trigger a firmware update you can too change the web proxy settings and the DNS server.  If you tin can alter these then you tin can redirect where the printer goes to cheque for a new firmware.  So what protection does Catechism use to prevent a malicious person from providing a malicious firmware?  In a nutshell – nothing, at that place is no signing (the correct way to do it) but it does have very weak encryption. I will go into the nuts and bolts of how I broke that later in this blog post.  So we can therefore create our own custom firmware and update anyone’s printer with a Trojan prototype which spies on the documents existence printed or is used every bit a gateway into their network.  For demonstration purposes I decided to get Doom running on the printer (Doom as in the classic 90s computer game).  It was not straight forrad due to it needing all the operating system dependences to exist implemented in Arm without access to a debugger, or even multiplication or division. Only that’s a blog for another day. Here’southward the video (sorry the colours aren’t perfect):

But would anyone put their printer’south spider web interface on the Internet? Well nosotros sampled 9000 of the 32000 IPs that Shodan (http://www.shodanhq.com) indicated may have a vulnerable printer. 1822 of those IPs responded and 122 we believe have a vulnerable firmware version (around half dozen%). We therefore estimate there are at least 2000 vulnerable models connected directly to the Internet.
Even if the printer is not direct attainable from the Internet, for example behind a NAT on a user’s home network or on an role intranet, the printer is nevertheless vulnerable to remote attack. The lack of authentication makes information technology vulnerable to a cantankerous-site request forgery attacks (CSRF) that modify the printer’s configuration. A colleague (thanks Paul Stone) demonstrated this by making a web folio that first scans the local network for vulnerable printers (using a technique called JavaScript port scanning). Once the printer’south IP address has been found, the web page sends a request to the web interface to alter the proxy configuration and trigger a firmware update. Although the printer is not really on the Cyberspace, this is possible because the malicious spider web page initiates requests from the user’south browser which is on the same network every bit the printer.

Context contacted Canon back in March of this year and nosotros provided them with the information about this event.  They have informed the states that future versions of the printer will have username and password authentication on the web interface.  See at the finish of the blog for their total response.

This weblog mail contains a description of how the encryption was broken.  I will follow this blog upwardly with a description of how I went from the power to modify the firmware, to actually running custom code which could utilize the wireless network stack, manipulate the retentiveness and update the screen as shown in the video.  The firmware does non run an operating organization but is a unmarried lump of compressed ARM code which makes for an interesting reverse engineering challenge, particularly with no debugger or console and when it takes 10 minutes to update the printer, which we don’t desire to brick.

How the encryption was cleaved

In this section of the blog I will get into the nerdy details of how the encryption was cleaved.

Let’s start past looking at the encrypted firmware, information technology looks like this:


Figure 2 – Encrypted Firmware

You can see repeating patterns (one pattern highlighted above) in the encrypted firmware pregnant that the encryption is not industry best practice.  The repeating pattern gives us a clue as to the length of the key.  In this case the design is 0x30 long; therefore the key is either 0x30 or a factor of information technology.  Likewise past looking at the graphic symbol frequency it is clear that this is not good crypto:


Effigy four – Basic XOR Encryption

If this is the case and so the blocks are equally follows:

P0 ^ K = C0 P1 ^ K = C1 Pn ^ K = Cn

While we don’t know what the key is, what we can do is remove the primal from the encrypted data by XORing the first line of the information with the rest of the data.  Therefore:

P0 ^ K ^ C0 = 0
P1 ^ K ^ C0 = P1 ^ P0
Pn ^ K ^ C0 = Pn ^ P0

This ways that the offset block is nil and the residue of the blocks are its original plainly text XORed with the patently text of the kickoff block, hence no primal.  If nosotros can work out the plain text of the showtime cake then nosotros will get the full decryption.  If nosotros wait at the results we get his:


Figure 5 – Encrypted firmware with commencement cake XORed with the rest

The graph looks neater simply the resulting text is still gibberish.  What nosotros demand to do is to work out what the first block of data is and then we tin use that to return the original information.  Later a lot of playing around with dissimilar options, I found that older firmwares for Canon printers did non accept this ‘encryption’ and use the SRecord format (http://en.wikipedia.org/wiki/SREC_%28file_format%29).  This is a format that is commonly used for writing to the memory of embedded devices.  The format that the file takes is ASCII for example:


Figure 6 – SRecord instance (source Wikipedia)

The format only uses ASCII hex digits, newlines and the ‘S’ at the start of each line.  This provides a very useful crib into what will be at the outset of the Catechism’s firmware (I assuming they are using SRecords).  The first graphic symbol must be an ‘S’ followed past a serial of ASCII hex numbers.  So if we brand a guess at what the first line might be, for example:

S00000000000000000000000000000000000000000000000

And see the resulting decryption:


Figure vii – Outset attempt at decryption

The shape of the graph fits in roughly with ASCII text (values being mainly betwixt 0x30-0x7f) and we tin can encounter that the start column (highlighted in green) only contains ASCII values which is confirmation that nosotros have the start byte correct for the SRecord format.  However the second cavalcade has characters which are not valid for the file format (highlighted in blue) and therefore the 2nd character of the plain text is not a zero.  The third column (in orange) has a correct value every bit all the characters are valid; including the 0xd line feed character.  We tin can automate the brute forcing of the characters at this point because we know the subset of possible characters and so can validate the column to ensure that no invalid characters are decrypted.  After this procedure we find that the key length is actually 0x10 and we have a valid SRecord, SRecords have checksums which helps united states ensure nosotros take the valid key, the file looks like this:


Effigy 8 – Plainly text firmware

There is no other protection in the firmware file.  SRecords take a checksum on each line but there is no signing of the firmware and therefore because we tin can decrypt the firmware nosotros can modify the SRecords and then re-encrypt the file and update the printer with our own custom firmware.

Vendor Response Timeline

  • 14th March 2014 – Canon notified of the result.
  • 18th March 2014 – Canon request further information.
  • 19th May 2014 – Canon escalated the issue.
  • 29th May 2014 – Request permission to publish this blog postal service.
  • 5th June 2014 – Canon acknowledges the issue.
  • ninth June 2014 – Canon visit Context to discuss this release.
  • 12th Sept 2014 – Blog release in conjunction with a presentation at 44Con.

Canon provided the following statement regarding this event:

“We thank Context for bringing this issue to our attending; nosotros take whatever potential security vulnerability very seriously.  At Catechism we work difficult at securing all of our products, however with diverse and ever-changing security threats we welcome input from others to ensure our customers are as well protected as possible.

We intend to provide a fix as quickly as is feasible.  All PIXMA products launching from now onwards volition have a username/password added to the PIXMA web interface, and models launched from the second half of 2013 onwards volition too receive this update, models launched prior to this time are unaffected. This action will resolve the issue uncovered by Context.”

Recommendations

Context recommends that you do not put your wireless printers on the Internet, or any other ‘Internet of Things’ device.  To defend against the CRSF attack, well don’t follow any dodgy links is the best advice I tin come up up with.  Context is not aware of anyone in the wild actively using this type of assault, merely hopefully we can increase the security of these types of devices before the bad guys outset to. Finally, brand sure that y’all always utilize the latest available firmware to your devices. This is often not an automatic procedure and may require checking on the manufacturer’s website for updates.

Canon Printer Firmware Pro 100 Paper Hack

Read:  How to Set Up R4i Gold Wood Firmware

You May Also Like