what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

fileZillaDisclose.txt

fileZillaDisclose.txt
Posted Oct 6, 2005
Authored by Adrian Pastor | Site adrianpv.com

The FileZilla client versions 2.2.15 and below suffer from a local credential compromise vulnerability due to improper storage.

tags | advisory, local
SHA-256 | b25fd57dbac01135b458f4ef6c6bb6f19a6c44cfc31b81c5109a0ffe085b399e

fileZillaDisclose.txt

Change Mirror Download
Title:       FileZilla (client) public credentials vulnerability
Risk: Medium
Versions affected: <=2.2.15
Credits: pagvac (Adrian Pastor)
Date found: 10th September, 2005
Homepage: www.ikwt.com
www.adrianpv.com
E-mail: m123303 [ - a t - ] richmond.ac.uk


Background
----------
FileZilla client is an open source Windows FTP/SFTP client.


Vulnerability Description
-------------------------
FileZilla client stores all users' credentials (including passwords)
in a globally public directory under Windows which allows all users
with local access (including restricted users) to dump the credentials
of all users and decrypt their passwords.

The directory is %programfiles%\FileZilla\

where %programfiles% is usually "C:\program files".

The default Windows ACLs grants *read* access to %programfiles% to all
users. This means that even restricted accounts can dump any user
credentials (including the administrators' credentials) from "FileZilla.xml"

This would *not* be possible if the developers had programmed the FileZilla
client to save the config file under %homepath% which would be
"C:\Documents and Settings\username\FileZilla.xml" by default.

The advantage of the %homepath% directory is that, by default, only its owner
and users within the "administrators" group have read access (rather than all
users).


Disclaimer
----------
If I get a response from the project developers arguing that the previous
security flaw is not a vulnerability but rather a feature, I will simply
*not* answer.

No offence, but I'm not willing to waste my time with the common "insecure
by design" debate. In my humble opinion applications should *never* store
user credentials in locations in the file system that are readable by all
users (unless you want all users to steal your passwords).


PoC
---
I coded a small tool which dumps all users' credentials from
"FileZilla.xml" and the registry and decrypts all passwords found.

In order to exploit this vulnerability the credentials need to be
saved in "FileZilla.xml" (rather than the registry).

Luckily, the XML file is the default location used to save
the credentials :-)

In case the credentials were stored in the registry, then you would
need to run this tool as the user you want to dump the credentials from
(this is because the credentials are saved under "HKEY_CURRENT_USER"
rather than HKEY_LOCAL_MACHINE).

Executable and source code along with Visual Studio project file:

http://www.ikwt.com/projects/filezilla-pwdump.zip
http://www.adrianpv.com/projects/filezilla-pwdump.zip

I tested this tool in Windows XP SP1 by running it with restricted accounts
from the "Users" and "Guests" groups and it successfully dumped all users
credentials (including admins').

This is possible because the default Windows ACLS of the %programfiles%
directory grants *read* access to all users. As far as I know this is
true in Windows 2000 SPX and Windows XP SPX as well (please correct me
if I'm wrong as I'm *not* a computer security guru).


Solution
--------
Choose to save user settings in the Windows registry or select
"Use secure mode" during the installation (this disables
FileZilla client from saving passwords at all), lockdown your client
machines where the FileZilla client is installed.

Alternitavely you can try convincing the FileZilla developers to modify
the application so that each user's credentials are stored in his/her
home folder.




Regards,

pagvac (Adrian Pastor)
Earth, SOLAR SYSTEM
Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    17 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close