Message-ID: <CA+75c3AxqJPuq0zod-aeJwzU0wwSOW70E1Z00Ve3ZsMdwZp6kw@mail.gmail.com>
Date: Mon, 18 May 2015 21:32:40 -0400
From: Jean-François Gingras
	<jean.francois.gingras@...il.com>
Cc: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
Subject: Re: [FD] KL-001-2015-002 : Piriform CCleaner Wiped Filename Recovery

Maybe I missed something, but why is this a vulnerability? This behavior is
directly caused by NTFS. The way information is stored in the MFT and in a
INDEX_ALLOCATION (for large directories) will cause this problem to any
secure delete program.

IIRC, if your file is located in a large directory, the records (mainly the
FILENAME attribute) for this directory are not hold in a resident attribute
(INDEX_ROOT - 0x90) in the MFT, they are hold in a non-resident attribute
(INDEX_ALLOCATION - 0xA0) somewhere on some cluster(s) on the disk. Those
records are organized into B-trees. Meaning that any modification to a
filename will result in a rebalancing of the B-Tree. This can leave the
original filename (complete or partial) in between records in the index on
the disk because INDEX can have free spaces in them.

Even SDelete from System Internal can't handle this (taken from
Microsoft[1]) :

*The reason that SDelete does not securely delete file names when cleaning
disk free space is that deleting them would require direct manipulation of
directory structures. Directory structures can have free space containing
deleted file names, but the free directory space is not available for
allocation to other files. Hence, SDelete has no way of allocating this
free space so that it can securely overwrite it.*


Am I wrong?

[1] https://technet.microsoft.com/en-us/sysinternals/bb897443.aspx

On Mon, May 18, 2015 at 3:35 PM, KoreLogic Disclosures <
disclosures@...elogic.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> KL-001-2015-002 : Piriform CCleaner Wiped Filename Recovery
>
> Title: Piriform CCleaner Wiped Filename Recovery
> Advisory ID: KL-001-2015-002
> Publication Date: 2015.05.18
> Publication URL:
> https://www.korelogic.com/Resources/Advisories/KL-001-2015-002.txt
>
>
> 1. Vulnerability Details
>
>      Affected Vendor: Piriform
>      Affected Product: CCleaner
>      Affected Version: 3.26.0.1988 - 5.02.5101
>      Platform: Microsoft Windows 7 x64 Service Pack 1
>      CWE Classification: CWE-200: Information Exposure
>      Impact: Information Exposure
>      Attack vector: Local
>      CVE-ID: CVE-2015-3999
>
> 2. Vulnerability Description
>
>      The use of CCleaner is encountered at times during forensic
>      investigations of computer systems. It has a secure deletion
>      mode where it can overwrite data, filenames, and free
>      space. Overwriting files and filenames removes the chance to
>      recover the data and subject it to further analyses. Due to
>      how the software works, CCleaner will actually tell you the
>      names of files that it wiped.
>
> 3. Technical Description
>
>      Filenames are overwritten with the letter "Z" when CCleaner
>      is tasked to overwrite files. On an NTFS formatted drive,
>      the filename records in the Master File Table are replaced
>      with the letter "Z". For example, a file named "TEST.TXT"
>      will have each character in the name overwritten with the
>      letter Z and will be renamed to "ZZZZ.ZZZ" after the process is
>      completed. For example, as CCleaner was executing, the filename
>      "TEST.TXT" was seen being written out to disk a few times,
>      followed by the pattern "ZZZZ.ZZZ". The other filenames being
>      overwritten were handled in the same fashion. This pattern of
>      overwriting filesnames was found in the unallocated space of
>      the hard drive. The search results looked like this:
>
>        TEST.TXT
>        TEST.TXT
>        TEST.TXT
>        ZZZZ.ZZZ
>        ZZZZ.ZZZ
>        ZZZZ.ZZZ
>
>        TEST1.TXT
>        TEST1.TXT
>        TEST1.TXT
>        ZZZZZ.ZZZ
>        ZZZZZ.ZZZ
>        ZZZZZ.ZZZ
>
>      Once some original filenames are recovered, the analyst can
>      attempt to use that to locate other references, or fragments in
>      unallocated space, etc.
>
> 4. Mitigation and Remediation Recommendation
>
>      None
>
> 5. Credit
>
>      This vulnerability was discovered by Don Allison of KoreLogic
>      Security, Inc.
>
> 6. Disclosure Timeline
>
>      2015.02.18 - Initial contact; requested PGP key from Piriform.
>      2015.02.23 - Second contact attempt.
>      2015.02.25 - Piriform responds, asks for KoreLogic to submit
>                   details to support@...iform.com.
>      2015.03.02 - KoreLogic submits vulnerability report to Piriform.
>      2015.03.02 - Piriform confirms receipt of the report.
>      2015.04.22 - KoreLogic requests an update on the status of this
>                   issue.
>      2015.05.04 - 45 business days have elapsed since Piriform
>                   acknowledged receipt of the KoreLogic report.
>      2015.05.15 - KoreLogic requests CVE from Mitre.
>      2015.05.15 - Mitre issues CVE-2015-3999.
>      2015.05.18 - Public disclosure.
>
> 7. Proof of Concept
>
>      N/A
>
> The contents of this advisory are copyright(c) 2015
> KoreLogic, Inc. and are licensed under a Creative Commons
> Attribution Share-Alike 4.0 (United States) License:
> http://creativecommons.org/licenses/by-sa/4.0/
>
> KoreLogic, Inc. is a founder-owned and operated company with a
> proven track record of providing security services to entities
> ranging from Fortune 500 to small and mid-sized companies. We
> are a highly skilled team of senior security consultants doing
> by-hand security assessments for the most important networks in
> the U.S. and around the world. We are also developers of various
> tools and resources aimed at helping the security community.
> https://www.korelogic.com/about-korelogic.html
>
> Our public vulnerability disclosure policy is available at:
>
> https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVWj77AAoJEE1lmiwOGYkMk7EH/3vT8zR3kG5tJk+T+WQr1k4g
> LQED7JEfL10XiwQooTihRbxOjG06oy1wRT1LJjnrg6iJFxg9q9IfHnzhYnV7Pm71
> znZPLXtjGXP7HgwQp2rH2wMI+4q92Kd46G/nMXFezgqjGv32ctT/nHYrQWRYLRRs
> 1fivJgIiJ9iwaMylFvS5Lhzfo84nQ7xSALQjhOWVnfp+qomFFi7jIHUQF5B240AC
> RFOwzyjwUPWshivZ5iccfBGLaLRLvSyiPLKCrRB+Ht8digB/epOXzxl6SF1ImPJc
> XwzM7x+Tz7y1+ZypJr39zGh2yoltmCYC4qmfrQzfqZzrBpTRaJhsDvkK+VS7+4U=
> =Ym/t
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/
>



-- 
Jean-François Gingras

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists