Friday, 16 March 2012

Windows Low Integrity Processes and Recycle Bin Metadata

Back in January we released a small tool to enumerate low integrity accessible items on Windows. During the course of releasing it we obviously ran it. As a result we identified a funny little issue (not security earth shattering) where low integrity processes have the ability to write to recycle bin metadata.

The impact of this vulnerability is that a low integrity process can modify where a file will be restored to when taken back out of the recycle bin.

When a file is deleted meta data gets created in a directory such as:
C:\\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001

In this directory there will be a meta data file e.g. '$IOM7SPO.txt'.

This file is accessible to low integrity processes:

C:\>GetLowIntegrityLevelObjects.exe
[*] Low integrity accessible - (c)2012 Recx Ltd
[*] http://www.recx.co.uk
[i] Low accessible directory    C:\\$Recycle.Bin
[i] Low accessible directory
C:\\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001
[i] Low accessible file
C:\\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001\$IOM7SPO.txt
[i] Low accessible file
C:\\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001\desktop.ini

This can also be verified with accessck:
C:\>accesschk.exe -w -e
C:\\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001\$IOM7SPO.txt
Accesschk v5.02 - Reports effective permissions for securable objects
Copyright (C) 2006-2011 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\$Recycle.Bin\S-1-5-21-3594361658-2603294332-2943340413-1001\$IOM7SPO.txt
  Low Mandatory Level [No-Write-Up]
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM
  RW ollierecx\ollie
This meta data file contains the path that the file will restored to. So when the user manually restores the file it is not placed in the original location but an alternate attacker controlled one. This alternate location in our particular demo was a UNC path (lame data ex-filtration as you could copy it anyway).

While the location is reported in the bottom of the toolbar the user my not in our humble opinion pay close attention to it.

We reported the issue to Microsoft who rightly responded with:
"Even though, the user can restore the file to a location other than where the file originally resided,  we were not successful in elevating privileges.  As a result, this issue does not hit the bar to be released as a security bulletin."
We thought about this and only came up with contrived routes such as:
  • You download an executable file from an untrusted source
  • Delete it
  • Then restore it, at which point it restores to a less ideal location such as the start-up folder
These steps are like asking a user to run cmd.exe as Administrator to add a user to the admin group and send you the password... so in short, another lesson in security research failure.

Anyway that's it... till next time...

No comments:

Post a Comment