85.85.170.170 IP address and other printer badness

85.85.170.170 IP address and other printer badness

It seems that anyone who spends enough time around network printers will eventually build up a personal library of technical insanity stories. I've definitely seen my share of garbage, and most of it came from JetDirect cards.

One time, I saw a printer claiming to be 85.85.170.170. That was not one of our networks, obviously. I spotted the pattern right away, but I'm weird like that. Hint: 85 decimal is 55 hex, and 170 decimal is AA hex.

If that doesn't help, try this: 85 is 01010101 and 170 is 10101010. Got that? Walking zeroes and ones. They're a sure sign of badness.

This particular printer was relatively far away, and I didn't feel like driving out there just to deal with it. Given that I had root on a Linux box out there (yep, CD towers again), I just stood up an eth0:0 config which would match up with its 85.85.170.170 insanity. With that in place, I was able to telnet in and knock it over the head.

Normally the thing to do would be enable DHCP mode. It refused, saying:

Failed to save parameters, make sure interdependencies are resolved

I had no intention of figuring out what that meant. It was time to go nuclear. I hit it with a cold reset and it gave me the following sob story:

A cold reset of TCP configuration parameters has been initiated

You must power down the peripheral after 1 minute Then you may move the peripheral to another LAN

*** TCP parameters have been initialized to factory defaults ***

... okay then. I logged out and let it rot. Someone would discover it and power-cycle it later. I never saw it try that stupid trick again.

Another time, I got this little gift from some broken situation:

Aug 17 22:06:17 time1 ntpd[1094]: recvfrom(x.x.64.41) fd=6: Connection refused
Aug 17 22:07:33 time1 last message repeated 2 times

That basically meant that someone had configured two different devices with the same static IP address. One of them was trying to do time syncs over NTP, and the other one would receive it and send back an error because it didn't match a pending request.

Just seeing it once would be a fluke, but having it repeat throughout the day meant something was wrong. Poking around on that printer's local network shed some more light on the story:

22:23:19.582675 arp who-has x.x.64.41 tell x.x.64.251
22:23:19.583666 arp reply x.x.64.41 is-at 0:60:b0:c0:63:fd
22:23:19.585323 arp reply x.x.64.41 is-at 0:1:e7:cb:75:0

Yep. IP overloading badness. So how do you fix it? That's easy. Set a static ARP entry on that Linux box pointing the IP at one of the hardware addresses, and telnet in. You'll land on exactly the one you want and nothing else.

I'm sure this could be used for some nefarious purpose. You could overload bunches of addresses as long as you didn't have to cross a router to do useful things. Just cram it in your ARP cache and get busy.

It looks like the word about printers being used to attack networks is finally getting around. They've been capable of horrible things for long enough, and now the deliberate use of them is becoming known. I can't wait for a printer-based worm. It should be fun!