norton.antivirus.passwd.txt

`Date: Fri, 9 Apr 1999 16:12:26 -0700  
From: "Saling, Kevin" <[email protected]>  
To: [email protected]  
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  
  
`