Dubious security vulnerability: Messing with the Recycle Bin


Today's dubious security vulnerability goes like this:

The $RECYCLE.BIN directory can be used to drop files into an arbitrary directory. To do this, navigate into a user's Recycle Bin directory and find a file in it. Edit the file to contain the data you would like to drop, and edit the Recycle Bin database to say that the file in question should be restored to a directory of your choosing. When the user opens the Recycle Bin in Explorer, right-clicks the file, and selects Restore, the file will be dropped in the directory you chose.

The idea here is that you can falsify the information in the Recycle Bin so that it looks like the attack file was deleted from the attack directory, so that "restoring" the file will drop the file into the directory.

Sure, but you're only messing with yourself.

It's like going into your kitchen pantry, opening a box of cookies, and replacing the cookies with rocks. Now, the next time you go to the pantry to get some cookies, you open the box, and instead of cookies, you get rocks! W00t! Security vulnerability!

There is no vulnerability here, because you are just attacking yourself. You have access to the pantry because it's your pantry. You have access to the box of cookies because it's your box of cookies. If you want to put rocks in a box labeled Cookies, then more power to you.

There is no elevation because the Restore operation will not be able to drop the file anywhere the user doing the restoring doesn't already have write access to. If you say "Um, yeah, this file should be restored to C:\Windows," then the Restore operation will say, "Sorry, you don't have access there. But if you enter the administrator password, then I can do it."

The default security on the Recycle Bin folder grants access only to Administrators, System, and the owner of the Recycle Bin. Therefore, the only person who can carry out this attack is the user himself. And if you want to drop a file in a directory a much easier way to do this is to use the COPY command.

Comments (20)
  1. Cesar says:

    It could be part of a sort of “social engineering” attack:

    – User deletes a file
    – Malware edits the recycle bin to say it came from C:\WINNT
    – User changes his mind and decides to restore the file
    – Windows asks for the administrator password
    – User trusts the UAC prompt because he trusts Windows, and the prompt is clearly for the operation he just requested
    – Profit!

    If it weren’t able to show a UAC prompt, I’d agree that messing with your own recycle bin could not be considered a vulnerability. But IMHO UAC changes the rules a bit.

    1. DWalker says:

      @Cesar, that sounds, perhaps, a bit far-fetched. It’s possible, but any time you trick a user into replying to the UAC prompt, then anything can happen. Interesting scenario, though.

      1. Ross Presser says:

        The Malware itself could start the deletion, throw up a window like “now deleting all .DOCX files in My Documents”, then move the DOCX files to the Recycle Bin, messing with one of them along the way. The panicked user goes to the Recycle Bin, breathes a sigh of relief, selects all his DOCX files and tells Windows to restore them. “Huh? A UAC prompt? Oh well, whatever, as long as it gives me back my resumés and cover letters!” And, boom.

        1. Mark Y says:

          As Raymond is fond of saying, if malware is running on the users machine, it’s already on the other side of the airtight hatchway. It’s not likely that UAC is going to slow it down much at this point.

    2. Mike says:

      If you are able to execute code as the user (i.e. because you are a malware able to edit the users recycle bin) there are many ways to trick the user into confirming the UAC dialog. You could – for example – just wait for the user to download some .exe file that looks like an installer and replace it by your own code. A user who has the right to become Admin is likely to install some piece of Software sooner or later.

      1. Vulpini says:

        The security-conscious user (ha!) would look at the Publisher field, assuming the original installer was signed correctly.

        Then again, the security-conscious user would also notice that the restore target in the elevation request (it’s listed there, I checked) is not where they might expect.

        1. Mike says:

          You know the security-conscious user? Who is he? Is he actually real? Can you give me his phone number?

          1. Ron O says:

            > Can you give me his phone number?

            I could, but his security prevents me from doing so.

          2. Every security-conscious administrator sets up protection for his unsuspecting and not so security-concious users:
            0. he disables any temptation through UAC (see https://technet.microsoft.com/en-us/dd835564.aspx):
            [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
            “ConsentPromptBehaviorUser”=dword:0
            “EnableInstallerDetection”=dword:0
            1. he creates “standard” user accounts for them;
            2. he sets up SAFER: see http://home.arcor.de/skanthak/SAFER.html

      2. Josh B says:

        Not to mention that the UAC prompt and admin rights in general aren’t a serious target anymore. You can encrypt everything a user has and extort hundreds of dollars without ever needing admin rights, unless someone uses separate accounts for everything they do on a PC.

  2. brianvan (@brianvan) says:

    Sure but what about automated attacks that operate on arbitrary files in the Recycle Bin without the user’s knowledge? It’s a low-chance thing, but the user may restore a file and make assumptions about its contents being benign, without knowing about the substitution.

    If I were to leverage this, I would probably put some really nasty stuff in any .doc or .docx file that landed in the Bin database. The user would then be surprised to find a macro trying to run when they opened their restored document, and there’s again a non-zero chance that someone who hasn’t had their morning coffee yet will click “yes” on a dialog box not really thinking of the implications.

    That said, there are likely much more reliable ways to put the moves on someone who hasn’t had their morning coffee…

    1. Much more reliable would be to change the “Microsoft Word” shortcut (or some other popular app) on the Start menu to point to a Trojan horse app.

  3. Joshua says:

    [There is no elevation because the Restore operation will not be able to drop the file anywhere the user doing the restoring doesn’t already have write access to.]

    This. I wish certain people would think before submitting vulnerabilities.

    1. SimonRev says:

      I don’t. I enjoy these occasional light pokes at overzealous “researchers.”

  4. Yukkuri says:

    People sure are desperate to prove that they have pwned Microsoft.

    Also, wow Firefox: ‘pwned’ is in your spell check dictionary?

    1. Desperate? Microsoft’s immense monetary award is enough motive for non-desperate people too.

  5. cheong00 says:

    Off topic post about the blogging site: Seems Raymond’s auto posting program started posting to the old blog site again. The articles of past few days appears in my RSS reader (IE11) and transfers to the old site without comments. :P

    1. Neil says:

      Worse, this article didn’t appear in my RSS reader, so I had to manually navigate to it…

      1. This article did appear on my RSS feed but today, three old posts with the old not-so-pleasant theme and no comment section appeared. Links are different, so I am still able to navigate to the old topics with this new theme.

  6. cheong00 says:

    I think it can probably be problematic for someone who is mandated to use EFS (say officers of government bodies which process sensitive data) if the Recycle folder is not encrypted with the user’s credential.

    Not sure if that’s the case, though.

Comments are closed.

Skip to main content