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>