Remote unauthorized print vulnerability caused by improper design of a printer of HP

Remote unauthorized print vulnerability caused by improper design of a printer of HP

The HP LaserJet M1536dnf MFP printer port 9999 has an unauthorized printing vulnerability. Any content sent to port 9999 can be printed, or the printer can always be printed by sending packets (DOS ).
May you say that printers are not something that everyone can use? However, if the printer opens a port, anyone can print packet loss in the past. This must be an improper design.
Of course, the internal network is not a problem, but if the port is exposed to the Internet, this is a risk. According to personal search, there are a large number of printers on the Internet.

0x00-cause

A few days ago, the company's network was connected to an O & M device, and the printer automatically printed things when no one printed them. I started to think it was caused by the Command issued by the O & M device through snmp, and then the SNMP that turned off the printer found that such a problem still exists, and caused me and the person in charge of O & M to force both sides, unpleasant. So I decided to analyze the cause.


0x01-culprit

Step 1: I guess the most likely Operation and Maintenance device is to scan the port of the entire network segment, so I used nmap to scan the printer.
 

Nmap first lists the port opening status, and then performs service identification. Then, the printer suddenly crashes.
 

Amount... It seems that I understand something. This is the packet requested during nmap scanning. After figuring this out, we only need to know which port has responded to the request, and we should know the root cause.

Step 2: Perform port tracing. I perform nmap scans on each port to find out which ports have responded to the nmap scan request.
 

The printer starts printing when port 9999 is scanned. Then I tried to test all the open ports that nmap scanned separately and found that the printer would print only when scanning port 9999. Therefore, we can confirm that port 9999 is the culprit.



0x02-packet capture Analysis

I scanned port 9999 again, but this time I used wireshark to capture port 9999 to analyze the specific nmap requests.
 

Let's look at the first package:
 

Let's take a look at the first printed:
 

Compare the second and third packages:
 

 

We believe that the order of sending packets is the same as that of printing.



0x03-OK

At this time, I have reason to believe that what content I send to port 9999 will be printed. So, try:

#coding:utf-8import socket#just for fun!data = '\x6A\x75\x73\x74\x20\x66\x6F\x72\x20\x66\x75\x6E\x21's = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.connect(('192.168.21.103', 9999))s.send(data)res = s.recv(1024)s.close()print res

 

0x04-impact Scope
 

The first port 9999 was open during the test, but it is not open for submission. GFW...
 

Solution:

Port 9999 uses encryption/authentication for communication | authorization