hpjadmadv.txt

`Product: HP Web JetAdmin Version 7.5.2546 (Others that use this codebase  
assumed vulnerable) Note: Only tested on the Windows Platform.  
Vulnerability: Denial of Service, Upload Any file to the filesystem to a  
known location, Write to any file on the file system, Read any file from   
the filesystem.  
Severity: Med/High Risk  
Status: Vendor Notified and an update will be released in Spring 2004.   
Workarounds can be found at the bottom of this advisory.  
  
  
Description:  
If an Administrator has not set a password in the HP Web JetAdmin product  
all of these actions can be taken by anyone who can access the HTTP server.   
HP uses a modified version of the Apache web server. Only a very few amount   
of modules are included with the Apache web server. There fore, this   
this vulnerability is not a critical risk. This service does run with  
SYSTEM level privileges.  
  
The only type of scripting we can do is HTS scripting, which is what  
this product is built on. A number of issues were found to exist in  
the scripting itself and some of the files that get included with the product.  
  
Vulnerabilities:  
1. Remote file upload (Any file with any extension):  
Using the /plugins/hpjwja/script/devices_update_printer_fw_upload.hts HTS  
script, any file may be uploaded to:  
https://victim:8443/plugins/hpjwja/firmware/printer/<filename> directory.  
Luckily these directories do not have execute permissions but, this script,  
used in conjunction with other vulnerable files allow us to use the  
directory (and files contained within) as an 'include' directory.  
  
2. File reading vulnerability as well as HTS script injection.  
https://victim:8443/plugins/hpjdwm/script/test/setinfo.hts?setinclude=../../../../../../../boot.ini  
No checks are done to verify if the user is allowed to access files outside  
of the web root. An 'authenticated' user who was not the admin account on the Jet Admin  
service could use this setinfo.hts script to read the local.users  
file and gain the encrypted passwords of all users which have a password  
set for the Jet Admin application.  
  
Example:  
https://victim:8443/plugins/hpjdwm/script/test/setinfo.hts?setinclude=../../../../../auth/local.users  
The malicious user could then use john the ripper or another password  
cracker to crack the htpasswd file.  
  
Using the setinfo.hts script and uploading a custom "hts" include file such as:  
https://victim:8443/plugins/hpjdwm/script/test/setinfo.hts?setinclude=../../../hpjwja/firmware/printer/test.inc  
An attacker can cause the setinfo script to execute the included hts code.  
This includes writing to ANY file on the host running the Jet Admin service.  
An example include file test.inc file containing the WriteToFile syntax:  
[=test net user heh h0h0h0 /add  
net localgroup Administrators heh /add  
=]  
[=__installdir C:\Documents and Settings\Administrator\Start  
Menu\Programs\Startup=]  
[[httpd:WriteToFile([$__installdir$]/[#test.bat#],[$test$])]]  
  
Since this service runs with SYSTEM we can write files anywhere. Now we can  
create files in the Administrators startup folder. Like say creating a  
batch script to add another administrator user. If IIS is installed this can   
be used to gain a interactive shell (/scripts or /msadc, or just write asp   
scripts).  
  
Another issue identified is a Denial of Service due to a bad call to  
stricmp.  
If in our include file we use this following line:  
[=dir C:\test=]  
[[httpd:RemoveCacheFiles($dir$)]]  
The hpwebjetd crashes due to an invalid read, I believe this is due to a  
bad call to the stricmp not expecting a second $ at the end of the dir  
variable.  
I did not investigate whether I could use this hts function to completely  
destroy the file system of the target machine but I can only guess it will.  
  
Oddly enough this DoS vulnerability can be exploited with out being set in  
an include file. Using a tool to modify HTTP variables I was able to cause  
the hpwebjetd.exe service to fail by removing a obj=<validcall> with my  
[[httpd:RemoveCacheFiles($dir$)]] variable instead.  
For instance:  
/plugins/hpjfpmui/script/wja_update_product.hts:  
(Changed the value of obj to our DoS function)  
<FORM onsubmit="return VerifyUpload(this)" action=wja_update_product.hts  
method=post encType=multipart/form-data>  
<INPUT type=hidden value=[[httpd:RemoveCacheFiles($dir$)]] name=obj> <INPUT  
type=hidden value=true name=__save>  
<INPUT type=hidden value=0 name=packageCount> <INPUT type=hidden  
value=blah.fpm name=goodFilename>  
  
Although I did not test, it may be possible to directly inject the hts scripting  
directly into the application using a tool like WebSleuth.  
  
Workarounds:  
First and foremost, HP has included a number of different methods of securing  
this web application. Anyone who uses this product should first set passwords  
for the service during setup. Secondly they provide mechanisms to lock down   
access certain IP Addresses, this feature should also be used, how often do   
you need to manage this from a machine other than your desktop? Once these   
are put in place, the only real security issues are if 'printer users' are   
configured and accessed by people other than Administrators. HP recommends  
also deleting the "test" directory.  
  
This folder is located (on a default install):  
C:\Program Files\HP Web Jetadmin\doc\plugins\hpjdwm\script\<test>  
  
`