Date: Fri, 9 Apr 1999 16:12:26 -0700
From: "Saling, Kevin" <kevin.saling@VIVIDSEMI.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: NAV for MS Exchange & Internet Email Gateways

After installing the following Symantec products:
Norton AntiVirus for Internet Email Gateways 1.0.1.7 (NAVIEG)
Norton AntiVirus for MS Exchange 1.5 (NAVMSE)

...I was shocked to find the 'admin' password stored locally in CLEAR
TEXT.  These products use html-based configuration pages served from a
built-in webserver.  They use clear text authentication.  The 'admin'
password for these pages is requested during setup.  This is NOT related
to the NT local or domain admin.

NAVIEG:
After install, the admin password was found in the navieg.ini file.

NAVMSE:
After install, the password was found in the following registry key:
HKLM\Software\Symantec\NAVMSE\1.5\ModifyPassword.


After speaking with Symantec, we agreed on the following points:

1. The admin password IS stored in clear text in the registry and/or INI
file.

2. This registry key should already be inaccessible to
non-administrators, or could easily be made so by setting the security
permissions with REGEDT32.  Any INI file containing passwords could
(should) be secured with NTFS.

3. It is bad practice to store passwords in clear text (ever).  A design
change request has been submitted for the next release of NAVIEG and
NAVMSE to change this behavior.  IMHO, the passwords should be stored as
hashes or otherwise encrypted.  Even better, the applications should
leverage the underlying NT security and avoid storing any passwords.

4. Both products have built-in webservers for the config pages.  They
both use 'basic authentication' (clear text) to validate the admin.  A
design change request has been issued
for the next versions to suggest the addition of SSL, or some other
secure session technology.

Thinking out loud...
A possible workaround for the current version is to make the admin
password null (stop the service, change the password to null in the
registry, restart the service).  Then, restrict access to the ip address
of a local interface ONLY. Of course, this still leaves open the
possibility of spoofing the source address. (?!?!)

I should note that Symantec does NOT guarantee that any of these design
change requests will actually happen, but they did promise to notify me
if they make the cut.  Of course, I will pass along that info.
Meanwhile, I would suggest that users of these products take a close
look at these issues.

//Kevin