Sven, 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 work. 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 'ABCDUV' :) Have you talked to HP about this? Geoff -----Original Message----- From: Sven Pechler [mailto:helpdeskat_private] Sent: Monday, March 03, 2003 9:26 AM To: bugtraqat_private Subject: New HP Jetdirect SNMP password vulnerability when using Web JetAdmin Hello, 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 http://www.securityfocus.com/bid/3132 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) and older. -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: .iso.org.dod.internet.private.enterprises.hp.nm.system.net-peripheral.net- printer.generalDeviceStatus.gdPasswords (In numerical format: .1.3.6.1.4.1.11.2.3.9.1.1.13.0) An example on a Windows machine, using SNMPUTIL from the Windows Resource kit: C:\>snmputil get 131.155.120.118 public .1.3.6.1.4.1.11.2.3.9.1.1.13.0 Variable = .iso.org.dod.internet.private.enterprises.11.2.3.9.1.1.13.0 Value = String <0x41><0x42><0x43><0x44><0x55><0x56><0x3d><0x31><0x30><0x38><0 x3b><0x00><0x00><0x00><0x00> ..etc... The resulting string reads in ASCII: ABCDEF=108; The Web Jetadmin device password is the word before the '=' sign, in this case: ABCDEF 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 Sven Pechler University of Technology Eindhoven Faculty of Technology Management
This archive was generated by hypermail 2b30 : Mon Mar 03 2003 - 14:45:42 PST