RE: New HP Jetdirect SNMP password vulnerability when using Web JetAdmin
Date: Mon, 03 Mar 2003 14:27:08 -0600 From: "firstname.lastname@example.org" <email@example.com> To: Sven Pechler <firstname.lastname@example.org>, email@example.com
I have been doing some research on the same issue, and it appears that
some of the new firmware versions from HP actually fix this
vulnerability by replacing the web server with a newer version that
doesn't rely on client-side java to verify the password.
The issue at hand stems from the fact that the web server in older
firmware versions (and some of the newer firmware versions) relied on
client-side java to validate the administrator login. This
implementation did not encrypt and send the password to the web server
to validate, but retrieved the password through snmp (read: plaintext)
from the printer and validated the login on the client side.
As far as the fixes go, neither of the fixes that you outlined will
remedy the situation:
1. If you set the snmp community string to anything other than the
default, 'internal' (the default for the JetAdmin Web Server) will still
work. The snmp community string of 'internal' is, as far as I have been
able to tell, unremovable. Once the snmp community strings have been
set to whatever non-default string you want, 'internal' still seems to
2. If you do not set a password on the JetAdmin Web Server, anyone can
change the settings without authentication.
The best solution in this case is to disable the JetAdmin Web Server (if
you cannot upgrade the firmware to include the Web Server that isn't
written with client-side java) by typing 'ews-config: 0' at the telnet
prompt. Once this is done, the password can still be retrieved through
the snmp object you mentioned, however no access will be granted (make
sure your telnet password is different). If you upgrade the printer
firmware, an easy check to see if the new version is vulnerable is to
access the web server: if you see the old, mostly-blue colored page,
you're still vulnerable. The new web server will still reply to the
snmp request, but from what I've seen, it's always null (all 0x00, 0x00,...)
One more side note: in your example, the raw ascii string is actually
Have you talked to HP about this?
From: Sven Pechler [mailto:firstname.lastname@example.org]
Sent: Monday, March 03, 2003 9:26 AM
Subject: New HP Jetdirect SNMP password vulnerability when using Web
During an analysis of some HP Jetdirect cards I discovered a security
issue that could lead to full access to a networked printer.
It looks like the vulnerability described in
http://www.securityfocus.com/bid/5331, but the OID is different and you
can only obtain one specific password.
It is also different from the password vulnerability described in
It applies to the following situation:
- Any operating system
-HP Jetdirect cards JetDirect 300X, (J3263A), JetDirect EX Plus (J2591A),
JetDirect 400N (J2552A, J2552B), JetDirect 600N (J3110A, J3111A, J3113A)
-The Jetdirect card is being managed from HP Web Jetadmin.
-A Web Jetadmin "device password" had been set on the JetDirect card.
(This password must be set from Web Jetadmin and has nothing to do with
the Telnet password or the SNMP Set community name)
In the above situation the Web Jetadmin device password is readable as
plain ASCII tekst from the JetDirect card using SNMP.
How to check your printers for this vulnerability:
Use an SNMP toolkit to read the following OID from your printer:
(In numerical format: .220.127.116.11.18.104.22.168.22.214.171.124.13.0)
An example on a Windows machine, using SNMPUTIL from the Windows Resource
C:\>snmputil get 126.96.36.199 public .188.8.131.52.184.108.40.206.220.127.116.11.13.0
Variable = .iso.org.dod.internet.private.enterprises.18.104.22.168.22.214.171.124
Value = String
The resulting string reads in ASCII: ABCDEF=108;
The Web Jetadmin device password is the word before the '=' sign, in this
How to protect your printer:
1. Keep the Web Jetadmin device password EMPTY (don't do this on
newer cards than the ones mentioned above)
2. Define a 'Set community name' instead
Additional means of protection (does not address the SNMP vulnerability):
3. Define a telnet password (do not keep it empty)
4. Create an 'allow list' from the Telnet console to restrict access
from defined IP-addresses
University of Technology Eindhoven
Faculty of Technology Management