New exploit area: Cross Site Printing (XSP) By Brad C. Johnson

One of the true benefits of a networked environment is that it makes resources readily available to you regardless of where they are physically deployed. One of the true realities of a networked environment, however, is that it can be difficult to manage those resources securely. How do you make sure that only the appropriate people (authentication) with the appropriate rights (authorization) can use that resource at the appropriate times (access control) and you know who did it (auditing)?

Most organizations are aware of this management problem for their own Intranets and are painfully aware of the difficulty in deploying resources safely and securely on the Internet. One of the most prevalent types of network/Web oriented exploits – Cross Site Scripting or XSS – has expanded into a new area and is called Cross Site Printing or XSP. This topic started popping up in articles in late 2007 and early 2008 but has recently started to garner some traction.

XSP is a logical variation of XSS in that it is a Web oriented code injection technique. XSP allows you to get access to Intranet printers through a Web portal. Many network printers often listen for printing requests on a well known TCP port: port 9100. If you are "on" the same network or LAN as this printer and it has not been configured to restrict access to it (a common occurrence), you can send anything to that port. If a Web application happens to be on the same network as one of the network printers, you can construct an HTML request to send something to that printer. An article from Net Security describes this capability.

Just to point out how simple this request can be, here is an example of sending a request to a network printer using HTTP:

http://[PRINTER]:9100/FILE-REQUEST

"[PRINTER]" is the IP address or the domain name of the network you are on. This simple HTTP construct would send an HTTP GET request to the printer trying to GET the file /FILE-REQUEST.

As the Net Security article points out, that simple HTTP request would result in basic HTML header information being printed but one could instead send a POST and create a properly formatted request to the printer. This is just the start of a variety of exploits that could be constructed and sent to the device.

At a minimum, this exploit could be used to send SPAM to the printer, or possibly perform a denial of service by sending a lot of requests and tying it up. What’s probably more interesting is that today’s sophisticated printers do a lot more than just print. They scan and store pictures or images that could contain sensitive information that could be viewed or possibly modified if one could interact with the printer interface.

Unless the printer is appropriately secured, then, it would be possible to send data to be printed, possibly change the printer’s configuration, or use the other functions (e.g., FAX or access other network resources) that the printer offers.