lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B5D7BD7A-9845-49E7-B10F-FE12F4886885@mtu.edu>
Date: Mon, 11 Oct 2010 13:40:05 -0400 (EDT)
From: rdsears@....edu
To: Brandon McGinty <brandon.mcginty@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Filezilla's silent caching of
	user's	credentials

I mean it's a nice thought, but the steps to get something like that indexed are quite silly. You would have to have your webserver indexing your application data, which is clearly a HUGE mis-configuration on their part. I personally don't care because I don't know if it's really going to do any good, and the last thing I want to do is have to explain to people in detail with varying levels of technical capacity how to secure their own systems. I do that enough already :-/ 

If that's being indexed I think they have far bigger problems already and their servers are probably already compromised a few times over.

I'd say if you have a personal connection to any of those ~11 servers go for it, but otherwise I wouldn't waste my time. After all it is 11 out of the billions of external facing servers on the Internet. If you spent your time for every google dork privately disclosing to each owner the fact that their site is vulnerable, you wouldn't have enough time in your life to finish with them. Even if you tried to automate it. Plus there's a good portion of people who will just ignore you, I've had it done to me on pressing issues on a couple of occasions. It's just a part of the security world you have to live with.

I guess it just depends on how much you want to 'fix the interwebz'.

That's just my 2 cents though but it's a nice thought.

Regards,
Ryan Sears

On Oct 11, 2010, at 6:39 AM, Brandon McGinty <brandon.mcginty@...il.com> wrote:

> If this is the wrong list for this question, I appologize.
> Is there any precedent for notifying those whose results have popped up
> for the below referenced google search?
> I would be happy to send out an email to the domain owners?, to alert
> them of a problem, but I am not sure if this is recommended.
> 
> Brandon McGinty
> 
> 
> On 10/9/2010 11:00 AM, Vipul Agarwal wrote:
>> That's a live and good example. I hope that now they'll understand the
>> importance of the issue.
>> 
>> On Fri, Oct 8, 2010 at 11:28 AM, Shirish Padalkar
>> <shirish.padalkar@....com>wrote:
>> 
>>> 
>>> 
>>> http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=inurl:recentservers.xml&oq=inurl:recentservers.xml
>>> 
>>> :)
>>> 
>>> 
>>> From:
>>> Ryan Sears <rdsears@....edu>
>>> To:
>>> full-disclosure <full-disclosure@...ts.grok.org.uk>
>>> Date: 10/08/2010 08:52 AM Subject:
>>> [Full-disclosure] Filezilla's silent caching of user's credentials
>>> Sent by: full-disclosure-bounces@...ts.grok.org.uk
>>> ------------------------------
>>> 
>>> 
>>> 
>>> Hi all,
>>> 
>>> As some of you may or may not be aware, the popular (and IMHO one of the
>>> best) FTP/SCP program Filezilla caches your credentials for every host you
>>> connect to, without either warning or ability to change this without editing
>>> an XML file. There have been quite a few bug and features requests filed,
>>> and they all get closed or rejected within a week or so. I also posted
>>> something in the developer forum inquiring about this, and received this
>>> response:
>>> 
>>> "I do not see any harm in storing credentials as long as the rest of your
>>> system is properly secure as it should be."
>>> 
>>> Source:(http://forum.filezilla-project.org/viewtopic.php?f=3&t=17932)
>>> 
>>> To me this is not only concerning, but also completely un-acceptable. The
>>> passwords all get stored in PLAIN TEXT within your %appdata% directory in an
>>> XML file. This is particularly dangerous in multi-user environments with
>>> local profiles, because as we all know physical access to a computer means
>>> it's elementary at best to acquire information off it. Permissions only work
>>> if your operating system chooses to respect them, not to mention how simple
>>> it is *even today* to maliciously get around windows networks using
>>> pass-the-hash along with network token manipulation techniques.
>>> 
>>> There has even been a bug filed that draws out great ways to psudo-mitigate
>>> this using built-in windows API calls, but it doesn't seem to really be
>>> going anywhere. This really concerns me because a number of my coworkers and
>>> friends were un-aware of this behavior, and I didn't even know about it
>>> until I'd been using it for a year or so. All I really want to see is at the
>>> very least just some warning that Filezilla does this.
>>> 
>>> Filezilla bug report:(http://trac.filezilla-project.org/ticket/5530)
>>> 
>>> My feelings have been said a lot more eloquently than I could ever hope to
>>> in that bug report:
>>> 
>>> "Whoever keeps closing this issue and/or dismissing its importance
>>> understands neither security nor logical argument. I apologize for the slam,
>>> but it is undeniably true. Making the same mistake over and over does not
>>> make it any less of a mistake. The fact that a critical deficiency has
>>> existed for years does not make it any less critical a deficiency.
>>> Similarly, the fact that there are others (pidgin) who indulge in the same
>>> faulty reasoning does not make the reasoning any more sound." ~btrower
>>> 
>>> While it's true you can mitigate this behavior, why should it even be
>>> enabled by default? The total lapse in security for such a feature-rich,
>>> robust piece of software is quite disturbing, and I don't understand how the
>>> developers don't think this is an issue.
>>> 
>>> I just wanted to gauge the FD community on this issue, because with enough
>>> backing and explanation from the security community as to why this is a
>>> problem, this issue may finally be resolved (it's been doing this for years
>>> now).
>>> 
>>> Regards,
>>> Ryan Sears
>>> 
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> 
>>> 
>>> =====-----=====-----=====
>>> Notice: The information contained in this e-mail
>>> message and/or attachments to it may contain
>>> confidential or privileged information. If you are
>>> not the intended recipient, any dissemination, use,
>>> review, distribution, printing or copying of the
>>> information contained in this e-mail message
>>> and/or attachments to it are strictly prohibited. If
>>> you have received this communication in error,
>>> please notify us by reply e-mail or telephone and
>>> immediately and permanently delete the message
>>> and any attachments. Thank you
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ