Squid Proxy Server
Exposes Passwords in Communicator 4.0

Reported July 2, 1997 by Fred Albrecht

Systems Affected

Netscape Communicator 4.0 used with Squid Proxy Server 1.1.10 and 1.1.11

The Problem

When a user accesses an FTP site using a URL to login, that user"s password can be gleened from within Communicator 4.0 and from the Proxy Server "s log.

Method for testing:

1. Start NS Communicator 4.0
2. Enter a URL of the form ftp://user@host.domain.xxx
3. Communicator pops up a password entry dialog. Enter the password.
4. When the file list is displayed in the browser window, follow the Parent Directory link
5. Click the BACK button (seems to be optional in Linux)

The password is now plainly visible in the URL field, similar to the following:

We"ll explain this out a bit clearer below:

Normally, if a site allows anonymous FTP, this means you don"t need a username and password pair to login. You just use anonymous and your email addr for the password and you"re in - which is handled transparently by your browser when used for FTP access. But if the site is regulated, and requires a username password pair, then you"d be prompted by Communicator 4.0 if, and only if, you used Communicator to FTP to that protected site.

Let"s say you want to FTP to a site which is protected. You"d enter a URL like this: ftp://yourname@ftp.someftpsite.com - at which point Communicator connects to the site, and pops up a window asking you to enter your password that matches the yourname user account. You enter the password, click OK, and it sends it to the site for authentication. BUT, IT ALSO PUTS IT IN THE HISTORY FILE OF COMMUNICATOR in this format: ftp://yourname:password@ftp.someftpsite.com.

So you can see, in the beginning, the URL did not have the password included. But, once you enter the password using Communicator 4.0, it gets added to the URL and put in the history file.

Therefore, anyone with access to your Communicator would have access to your history file, and thus, the stored passwords - should there be any.

Be aware that it has been reported that JavaScript can access the history list, meaning a malicious Web page could be grabbing passwords from your browser without your knowledge.

ALSO - it appears that the Squid Proxy Server is in fact writing the user"s password in plain text to its own logs as well - which we should all know is a bad thing.

Netscape says the root of the problem lies in the Squid Proxy, not Communicator.

Stopping the Attack

Don"t use Communicator for FTP"ing to sites that require a username and password. Use a standalone FTP client instead, until Netscape releases a fix.

Netscape"s Response:

On July 2, 1997 it was reported that Netscape had been informed of this issue.

On July 4, Netscape contacted NTSecurity.NET with the following update:


* We first heard about the bug through a call from a reporter yesterday afternoon (7/3 @ 2;30 USA west coast).
* Next, our engineers started looking into the report, and we attempted to contact you and Squid.

Here"s What We Found:

   * The problem is a user name/password bug in the Squid Proxy.  In    general, users should be concerned authenticating via FTP is in the clear.
   * Squid takes user name and password, returns it in a URL, stores it in an HTML page and also stores it in its own log file.
   * On the client side, the user name and password ends up in the user"s history file.

The Risk:

   * Exploiting the bug would require that a hacker break into the Proxy or the client.
   * Proxy side.  If someone can access the server logs, they can get   the user name and password information for users.
   * No problem from the client side.  The reported issue exposes the   password to the user and the Proxy server operator only.  A hacker     would have to separately attempt to break into the user"s computer      to try and steal the information.  User information cannot be taken by exploiting reported privacy bug because it has been fixed.

What Netscape Is Doing:

   * We are working with Squid to assist them in patching their product.

To learn more about new NT security concerns, subscribe to NTSD.

Reported by Fred Albrecht.

Posted here at
NTSecurity.Net July 2, 1997 12:30pm