exploit the possibilities
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:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    16 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    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