Are you actually trying to say that using port 9100 to send jobs to a networked printer is seldom used? If so, I suggest stepping into the real world. Virtually every person and company I know who has a print server (whether a separate device or integrated) uses port 9100. It's called "Standard TCP/IP Printing" by Windows, and every print server supports it, for a reason. It's about as seldom-used as using port 80 for WWW traffic.

And what is this "termination" you speak of? Do you mean sending a print job by sending data to the port?

In order to utilize this "attack", the attacker would first need to gain control of the user's computer. If they have that level of control, there are far worse things than your printer printing spam.

Given that people are regularly deluged by fax spam and a 5 or 6 years ago there were a lot Windows messenger service spams going around it seems a certainty this will be done. Most network printers I've seen do not seem inherently secure; if you know their IP address they are surprisingly chatty and most will display a nice page that will tell you their model, firmware, serial number, how much paper they have -- you could mine this information to plan attacks as there is frequently no security set on this. Printers seem hugely lacking in security and most depend on security by obscurity, you need to know their IP address before attacking it.

Do the new wifi attached printers for home networks use this port ? War spamming ? Drive by spamming ?

I can see your point, but this could basically be used in the same way as phishing emails (there was a recent-ish story about many employees at a top-security US government place thingy being fooled by email phishing) - couldn't somebody with a specific attack agenda, who has planned it out, send a fake but properly-formatted message to the printer? Whoever picks it up would most likely assume it's been printed locally and if it looks like an instruction, an incriminating personal email, whatever - that could do a lot of (social) damage to individuals within the organisation. Oh yes, I can see it right now.

This does not involve gaining full control of a users pc first.

Using javascript, you can determine the ip address of the workstation then portscan the subnet for open port 9100 addresses. Each one you find, send raw print data, then close the connection, out comes spam.

Trivial, and an annoying way for a spammer to waste your paper and toner.

We use OCE TDS-400 large format Laserprinters her at the office, and they use an "controller" which consists of a dell PC with some custom software on an embedded NT installation. Imagine, A0 sized "enlargement" messages... Given the large size of the plotfiles (~100Mb+ easily), they're connected via our LAN. Uncle sjohie reminds himself to check for updates from OCE really soon..

The first key statement was in the article, you need the IP address. You also need that IP address and port to be routable and accessible from the internet. If your firewall isn't specifically configured to let traffic through to the printer, it ain't going to happen.

So this is only possible if you can actually get to the printer from (a) the internet or (b) a compromised PC. You can make a user's PC the source of the attack by social engineering, but if you can compromise the PC then you're probably going to be looking to do something like keylogging rather than printing.

In another scenario, insufficiently secured wireless networks could easily be targetted, but again doing some printing doesn't seem like a hacker's priority.

Hmmm... now let me see... javascript MUST be insecure because a malicious person can do: alert('Press OK on this and the next box to continue'); followed by: window.print()

Lo and behold, with minimal luser intervention, javascript is able to print.

As for having it connected directly to a PC mitigating the attack... is that what this crossover cable does?

As a previous poster said, it's not a bug/security hole/anything else... it's things doing what they were intended to do. If javascript (or anything else) can port/subnet scan and connect to random ports, don't you think that port 25 is a far more lucrative target? The infected machine will (probably) be separate to the recipients network and thus won't be shut down to stop this crap coming out of it.

As an ex-print server developer, I can throw in a few comments here...

* If the print server is attached to a publicly accessible IP Address, then anyone can spam it. Just hope the printer understands the print job (i.e. don't send PCL5 printouts to a PostScript printer or vice-versa)

Could attempt to access the built in webserver and it's configuration page. This would then tell you the correct printer drivers to use. (This would need a human involved to read it)

But - why on earth would a sane company have a printer accessible to the outside world? That is just asking for trouble. I know - because we used to spam printers from our office "just for the laugh" back in the 90's. I remember hitting printers at Microsoft and The White House!! And being shocked by the lack of security to stop us (or even track us)

Also, the spammers are going to have to do a lot of "setup" this way... and only know if they get it right if they can watch "page counts" go up correctly after the send their spam. Far too much effort....

* If the printer is on a properly secured/firewalled internal network, then it can only be spammed from inside the company. Still untraceable, but will now need to have a PC compromised first before it can fire out that "spam".

For the cross site scripting thing to work, the hacker still needs the IP Address of the printer. So ends up with some form of brute force scanning for it.....

It also is going to have to rely on some stoopid employee to be looking at compromised sites... oh yeah - we are talking users... so highly likely!!

Now not being a web programmer, I don't understand WHY the browser should be allowed access to a printer via Javascript. Especially when one studies the method used - this is http'ing to the printer port....

hxxp://aaron.weaver2.googlepages.com/CrossSitePrinting.pdf

Not much that can really be done to stop this at the printserver though. The Direct Printing Protocol to port 9100 has no way of authenticating. No way of "checking" for legitimate print jobs. No way of adding a password to the printserver.

And no point in adding the password if the print job is being sent from a PC within the office anyway....

But why be worried about printers? Worse case, loss of paper and toner. I'd be much more worried about those door entry systems, finger print readers, etc. I know the company I used to work for was AWFUL for the security of these things. Basically shipping out "working betas" to secure banks!! NO security on the firmware update side. Horrendous!! And guess how the firmware was updated? Yep.... "printed" in through port 9100!!

(Now FIRMWARE compromises... that is an interesting one... imagine if someone managed to reverse engineer the firmware for the printserver... and added their own network sniffing code into it... then sneaked that back onto the printer. NOW we have a serious security risk without anyone being any the wiser....)

"doing what they were intended to do"? So's telnet - but I doubt anyone would argue against that being insecure.

Yes this is "FUD" at the moment, since there are so many reasons why this isn't a practical attack vector (e.g. javascript doing http requests - not 'raw' TCP/IP, you'd need to know what the IP is, and you also need to know what languages it understands) - but the principle stands that printers are insecure.

Of course, it's much more fun (on HPs at least) to change the status message to "HELP - ON FIRE" rather than printing spam.

What about the copier companies that have a remote service contract with the client and their copier "phones home" if it needs service? That means that the printer/copier could potentially be directly accessed over the web via HTTP right?

If you want something to worry about, how about someone sniffing around the copiers hard drive for the data files that have been recently printed. Now that's scary!

I see a whole new virus scanner industry for networked printers coming to a workplace near you soon.

A lack of imagination abounds - I guess few ppl on El Reg have ever spent much time on the greyer side of security.

How's about a buffer overflow in the firmware, or rewriting it, adding code to look out for bank details etc in print jobs and then tunnelling out and reporting the info to a drop server?

Reverse shell?

Packet sniffing on old networks?

Spam relay?

Thinking that because it's a printer you can't do anything with it other than print because that's all it is meant to do is like thinking all anyone can do to IE is make you view a web page.

In other words, an insecure protocol that is endemic in millions of businesses *is* an IT issue. A lot of printer firmware is available for download so if ppl want to explore buffer overflows, undocumented functions etc then the resources are there.

Many printers also have a FTP server that can be used for printing. I have sometimes used that in desperation, but I'm sure that most people are unaware of it.

"But why be worried about printers? Worse case, loss of paper and toner."

No, you're missing the point again. This sort of attack is more likely to be a specifically-targetted revenge attack. Disgruntled employees, and so forth. Forging stuff is one possibility (as AC above pointed out), but apart from just loss of paper and toner, there's also the potential problem of not having a backup printer while the primary is otherwise engaged. Many (smaller-sized) companies only have one, and if that goes balls-up, then no invoices printed, no instructions printed, no addresses printed, no timesheets printed, no letters printed... even one afternoon of this could seriously mess up a small company's scheduling. If I were a disgruntled former employee that's a good place to start. Hmmm...

that the last software update to my HP 3210 makes it crash (tiny BSOD) if I attach it to a network. Forced me to hard-connect it to the nearest computer. Also made it a PITA to use from other machines, but hey, Thanks, HP, for saving me from this exploit (maybe?)

well i been doing some research on grabbing a users local NAT there are a few methods of doing this - as long as the pc has not been locked down it will work on iether linux windows etc

google

MyAddress.class

getLocalAddress

in perl lookup

$ENV{'HTTP_X_FORWARDED_FOR'}; prxjdg.cgi

...assigns a routable IP address to a print server?

Barring a completely cretinous sysadmin, attacking a standard TCP/IP print server *will* require compromising a PC within the network first.

If that happens, printers and print servers are the least of your worries.

Oh, and advice to Anonymous Coward: "Many (smaller-sized) companies only have one, and if that goes balls-up," then go down to the nearest Dell outlet and buy a new, full-color network-attached printer for US$250, or something less fancy for less money. If the company is so strapped they can't afford to replace the most-likely-to-fail component (the printer) on their network, then they're f*cked anyhow.

.. "What about the copier companies that have a remote service contract with the client and their copier "phones home" if it needs service? That means that the printer/copier could potentially be directly accessed over the web via HTTP right?" ..

Short answer: No, it doesn't work that way. Periodically establishing an outgoing connection does not mean that an incoming connection is ever available. Even without a firewall, being able to open a socket and transmit does not mean that a socket is open and waiting on your machine all of the time. Think of it this way, your desktop machine may use POP3 to retrieve email from a mail server that sits on the Internet, but it does not mean that your workstation will answer any attempts from another machine trying to use POP3 to retrieve mail from you. It is the difference between a "Client" and a "Server".

Frankly, if any computing environment is configured so that the printers have live, outside, non-firewalled, routable IP addresses then chances are that the workstations that use the printer are also sitting in the same IP block and would make much more tempting and potentially more-productive targets, making this entire attack a non-issue. The SNMP vulnerabilities in many older print servers would be much more worrisome.

A few ppl here saying "but if your PC is compromised who cares about a printer?"

Think about privileges ppl. If there are exploitable printers out there then all you need is some JavaScript to run in a local users browser. Yes the PC has technically been compromised, but the JS is only running in the context of the browser, and with limited privileges. However, by exploiting a printer you get *more* privileges and thus more resources with which to carry out more attacks. The PC may well be fully patched making further inroads impossible, but poorly programmed priinter firmware opens up new avenues to an attacker.

The PC does not need to be rooted to get to the printer, and this is the whole point - it's very similar to the ADSL router attack through your browser. Do you think that having your nameservers changed by a malicious piece of JavaScript is nothing to concern yourself with? Or do you protect your router with a password? Yeah, I thought so.

...is probably a good idea.

Have you tried googling for: inurl:hp/device/this.LCDispatcher

I still can't believe how many printers can be found online....

People complaining about routable addresses being assigned to printers are missing the point. The whole point is that the code executes in the client's browser, inside the LAN. Thus they can connect to printers and all sorts of other interesting TCP/IP-using services, especially HTTP-based ones.

A sane browser would enforce ip-based and/or hostname-based security restrictions to address this. "Content from outside the local network may not through JavaScript or any other method request data from address ranges set by the security policy as intranet or host-local addresses". In fact, I was under the impression that MSIE has been doing this for years, though I could easily be mistaken.

If such a policy isn't enforced, a whole lot more than network printers can be attacked. Think Sharepoint, for example, for companies dependent on that sort of thing. While it's usually locked down by some sort of access control, that can often by NTLM based single-sign-on that the js code could just ride on using the user/browser's credentials.

Additionally, if browser-embedded JavaScript has enough control to be able to generate arbitrary requests, WebDAV and IPP (Internet Printing Protocol) as well as many other HTTP related protocols are likely to be an issue.

The issue here isn't JetDirect/socket based printing. It's allowing remote code (be it JavaScript or anything else) to automatically execute on hosts inside the network without proper sandboxing and access control. The article would have benefitted from focusing on this point.

Was delivered by a group out of germany a few years ago at Defcon. They had managed to re-write the firmware of a couple of HP models so that when you sent a print job to them you got a error message that told you to read the display on the printer.

Upon inspection of the printer you would be greeted with a message that said "please insert coin".

Friggin hilarious, but the point being, this is nothing new. I laughed so hard when they delivered their presentation, they were hilarious but they really really new their stuff.

The attack described does not involve publicly accessible printers.

Consider a web page with a form like:

<form action="http://printer-address-here:9100" enctype="text/plain" method="post">

<textarea name="text">Hello world</textarea>

</form>

and some javascript to automatically submit the form on page load (possibly hiding the form, and targetting it at a hidden iframe for good measure).

While it may not let me print arbitrary data, it will probably print something (even if it only prints plain text it might be classed as successful).

Get someone inside the firewall to visit the web page and the spam gets printed. No need to take over anyone's PC.

...for the fact that the P.O.S. HP Laserjet 8100 which I am obliged to hit with a hammer a Several of times a day rarely keeps running long enough to fall victim to this.

When I rule the world, I will track down every single HP printer designer who ever lived, forcibly relocate them to Edmonton and feed them only with old toner cartridges and dead dogs.

sup,

Using port 9100(the jetdirect port) for nefarious activities is not something new. I first discovered how easy it was to exploit them in about 2001, and indeed, the topic of using networked printers as your own personal storage space was covered in one of the "Stealing the Network" books. In my professional life, I have always tried to point out the vulnerabilities that lie in Networked printers which get over looked from a security point of view. In a job I held a few years ago, I put up the time and place of my leaving party on the display of the printer in the office from home.

Unfortunately, exploitation of printers continues because unless you print out "This printer has been hacked" 20,000 times, or leave it flashing on the display, no one notices any difference with whats happening inside the printer. If the printer has been left with a connection to the outside world, with the default password then you can bet no one is paying much attention to log files. I am sorry to say, I dont think things are going to improve until spammers actually start exploiting printers to print out spam. Only then will companies who are complacent regarding security , sit up and take notice.

428 printers are available according to Google - quite a few of them in educational establishments.

This is all a bit like those companies that leave CCTV cameras accessible over the net - Google will give you a lot more than 428 if you search for the commoan URL string for Axis cameras.

The main problem is: Should an internet site be allowed to direct a browser to post or access an intranet resource?

Maybe a better approach is to designate intranet/internet zones like they have in IE, but warn you if an internet site is accessing internal resources. Then their wouldn't be an issue of being able to scan the intranet using javascript, change router default passwords, access printer resources etc.

Some years back my employer decided to set permissions on the print server to allow server-based auditing and control printing costs on what was, at the time, a very expensive colour laser printer.

Naturally we were so far down the food chain we weren't allowed to use it. But none of management realised that a direct TCP/IP connection to the printer's IP address would bypass the print server and all their careful permissions and logging. I think there were about 20 of us doing this and I believe they ended up calling out HP to try and find out what was causing the discrepancy between the printer's counter and the server's logs... Happy days!