This one has been rattling around in my head for a while, and since I’ve found myself with a few spare minutes, it’s time I wrote it up for your enjoyment and mine. This is certainly nothing new, but its one of those things that people seem to discount when performing penetration testing. After all, printers aren’t really cool anymore.
When it comes to stealing data, most of the time you’re going to need a valid username/password to gain access. Sure you can exploit systems, use pass the hash or go the social engineering route, but you’re going to need access. However in this day and age of the failed paperless office, why go to those lengths when you can just steal the documents straight from the print queue. We all know how to perform ARP or DNS poisoning to insert a system into the flow of traffic, but with printers this job can be made so much easier due to the overall lack of security on print devices.
There are four easy methods for stealing print jobs that spring to mind, other than using standard ARP or DNS spoofing attacks.
- Physical access – A majority of printers offer unprotected access to the menu. Through physical access you can change the printers IP address and assume the original for yourself.
- Telnet access – Not seen so often in modern printers, but can give you complete access if the passwords are blank or left at default. Again, reset the IP address and assume the original.
- Webserver access – Most modern printers offer a web interface for easy configuration. Brute-Force is an option here as they rarely enforce lockouts or use domain credentials. Again, reset the IP address and assume the original.
- Denial of Service – Crude but effective. This isn’t really a MITM attack, as you’d not be able to forward on the print job. Just drop the printer off the network (turn it off if you have to) and steal it’s IP.
Once you’ve gained access and stolen the IP address of the remote printer, there are a couple of ways to steal the print jobs. I started off by playing about with netcat using a simple netcat relay (and using tcpdump to copy the traffic).
mknod backpipe p
nc -l -p 9100 0<backpipe | nc <new printer ip> 9100 0>backpipe
The problem with this is that it would work on the first print job and then lockup. This is because the netcat relay would make the connection and leave it running. All subsequent print jobs would fail. Back to the drawing board.
My second attempt included the -w1 timeout for the second half of the netcat relay . This forces the connection to be dropped after 1 second of inactivity. This worked a little better but still not perfectly. I also threw in tee to prevent having to use tcpdump to capture the traffic (-a sets append).
mknod backpipe p
nc -l -p 9100 0<backpipe | tee -a capture.out | nc <new printer ip> -w1 9100 0>backpipe
The best results came from using the above command in a loop. I wrote a small bash script to do this. This is something to play with (your mileage may vary).
while true; do
echo “Print jobs captured = $i”
nc -l -p 9100 0<backpipe | tee -a capture-$i.out | nc $PRNIP -w1 9100 0>backpipe
As an alternative to netcat I also tested the use of iptables to perform a prerouting of the traffic.
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp — dport 9100 -j DNAT –to-destination <new printer ip>
The problem I can see here is that PREROUTING is performed before any of the traffic will be visible to TCPDUMP. So although we’re routing all the traffic to the printer, we can’t dump any of the print jobs. I’m no iptables expert by any stretch of the imagination. So maybe there is a way to do this easily without extra tools. I’ll have to try playing with the mangling rules and see if I can get some better results with iptables.