Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: FileZilla weakly-encrypted password vulnerability: advisory + PoC
From: "Mark Senior" <Mark.Senior () gov ab ca>
Date: Wed, 7 Sep 2005 12:30:24 -0600

I understand that you're not necessarily endorsing the developer's
stance, so please take no offence.

The below posting is evidence that the FileZilla developers are infected
with a DOS mentality - the assumption that every computer will be used
by only one person.

The developer is being disingenuous when he lists:

3. Encrypt settings using a master password, don't save the 
master password at all, request it from the user on startup. 
Not implemented in FileZilla, partially because of
4. Use the tools the operating system provides to protect 
data, that is access rights and file encryption. Though 
obviously the user has to setup this for himself.

In fact, the user doesn't have to set up 4. for himself - the OS has
already set up ACLs for his home directory on his behalf.  The user may
even have set up encryption for his home directory too.  Having done
this, a user should be able to assume that he has done his bit, and his
programs won't go littering his passwords all over the filesystem and
the registry.

The correct place for a file that contains a user's passwords in
plaintext (obfuscated or not) is under the user's home directory, which
is already protected by filesystem ACLs.  Writing a user-specific XML
file in a globally accessible directory is actually actively avoiding
the tools the operating system provides.  Putting the file under
%PROGRAMFILES%\FileZilla\ (and correspondingly requiring that every user
have write access to that folder - effectively requiring that the
program be run as a local admin) is just dumb.

As for point 3. it's not a bad idea either, and could perhaps be
usefully be done in addition to 4.  (a la PasswordSafe)

Regards
Mark


-----Original Message-----
From: medhead () flagmandesign com [mailto:medhead () flagmandesign com] 
Sent: September 4, 2005 00:59
To: bugtraq () securityfocus com
Subject: Re: FileZilla weakly-encrypted password 
vulnerability: advisory + PoC

QUOTED FROM FILEZILLA FORUM POST: I AM IN NO WAY CONNECTED 
WITH FILEZILLA DEVELOPMENT, NOR DO I SPEAK ON BEHALF OF 
FILEZILLA. WHAT IS WRITTEN BELOW HAS BEEN COPIED FROM THE 
FILEZILLA FORUM POST.

http://filezilla.sourceforge.net/forum/viewtopic.php?t=1328

Preface: There is no know security vulnerability in 
FileZilla, the reported vulnerability is a hoax.

Recently someone reported an alleged security vulnerabilty in 
FileZilla. But very quickly it became visible that the 
problem is not a vulnerability at all, but infact a 
fundamental issue of every single program that can store 
passwords transparently.
Despite my reply the vulnerabilty got releases to several 
security sites. Someone even posted some sort of exploit: 
Sourcecode that decrypts the stored passwords of FileZilla. 
But how could this be an exploit? In order to connect to a 
server with the encrypted passwords, FileZilla itself has to 
decrypt it. And since FileZilla is open source (basically 
every single program is, just look at the machine code), 
everyone can decrypt the passwords with little effort.

The used encryption method to store the passwords is a very 
simple algorithm. It hasn't been designed to be 
cryptographically strong, it shouls just obscure passwords.
In fact it is impossible to transparently store passwords 
securly, see below for reasons.

So since the vulnerabilty report got released despite my 
explanations, I can only assume that the author has either 
very little experience or, what I don't hope, this is an 
attempt to discredit FileZilla.

--------

FILEZILLA DEVELOPER REPLIES TO ORIGINAL EMAIL

--------

Hi,

thanks for your concern about FileZilla. I would like to 
clarify that this is not a security vulnerabilty. The 
password encryption has never been designed to be secure, 
it's just meant to obfuscate the password.

In order to use the stored passwords, FileZilla itself has to 
be able to decrypt the passwords, for this it needs the 
encryption key to be stored along with the encrypted 
passwords. In this case the key is stored inside the executable.
This is no different than with any other program that can 
store passwords transparently: It's never secure and can 
always be cracked with very little effort. This is especially 
true for open source software where everyone can inspect the 
encryption code.

But there are a few ways to store passwords in a secure. I'll 
add a few comments on all of them

1. Don't save passwords at all. Implemented in FileZilla, 
chose "Secure mode" during setup.
2. Don't store the password itself, store hashes. This won't 
work for FTP as FTP needs to send original passwords and 
hashes aren't reversible.
3. Encrypt settings using a master password, don't save the 
master password at all, request it from the user on startup. 
Not implemented in FileZilla, partially because of 4. Use the 
tools the operating system provides to protect data, that is 
access rights and file encryption. Though obviously the user 
has to setup this for himself.

Thus said, for FileZilla 3 I even plan to omit password 
obfuscation by default. Transparent password storage is 
equally secure when passwords are stored in plaintext.

Regards,
Tim Kosse


This email and any files transmitted with it are confidential and intended solely for the use of the individual or 
entity to whom they are addressed. If you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the individual named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.


This email and any files transmitted with it are confidential and intended solely for the use of the individual or 
entity to whom they are addressed. If you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the individual named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]