RE: FileZilla weakly-encrypted password vulnerability: advisory + PoC
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@xxxxxxxxxxxxxxxxx [mailto:medhead@xxxxxxxxxxxxxxxxx]
> Sent: September 4, 2005 00:59
> To: bugtraq@xxxxxxxxxxxxxxxxx
> 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.