6

I'm trying to put in some meagre additional malware prevention measures, by restricting the execution of *.exe in a handful of locations -- in particular, the temporary folders that various compression tools unzip to, when a user might choose to open an executable straight from a Zip file.

From the TechNet article, http://technet.microsoft.com/nl-nl/library/cc786941%28v=ws.10%29.aspx:

You can use environment variables in a path rule. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %Windir%) allows a rule to adapt to a particular user’s environment.

...

A path rule can incorporate the ? and * wildcards, allowing rules such as "*.vbs" to match all Visual Basic Script files. The following examples illustrate the use of wildcards:

  • “\DC-??\login$” matches \DC-01\login$, \DC-02\login$
  • “*\Windows” matches C:\Windows, D:\Windows, E:\Windows
  • “c:\win*” matches c:\winnt, c:\windows, c:\windir

I have these Path rules (which I have applied both singularly and in various combinations):

  • %APPDATA%\*.exe
  • %APPDATA%\*\*.exe
  • %LOCALAPPDATA%\*.exe
  • %LOCALAPPDATA%\*\*.exe
  • %TEMP%\*.exe
  • %TEMP%\7z*\*.exe
  • %TEMP%\wz*\*.exe
  • %TEMP%\Rar*\*.exe

...which theoretically should represent executables directly under the user's temp folder, and executables in temp folders named in the manner that Winzip, WinRAR and 7-zip might name their temp folders (e.g. %TEMP%\7zSF20.tmp\the_file.exe).

The %APPDATA% and %LOCALAPPDATA% ones work; the %TEMP% ones don't. Executables appear to be blocked under %TEMP% but this is only because, in a default setup, they also match the %LOCALAPPDATA%\*\*.exe rule (Temp is under AppData\Local, by default).

I had originally thought this was an issue with wildcards in partial folder names, but it appears this is specific to the use of the %TEMP% variable (hence the rewrite).

The two workarounds I have confirmed (and why I'd prefer not to use them) are:

  1. using %LOCALAPPDATA%\Temp in place of %TEMP%

    • Strictly speaking, this is not correct, as the %TEMP% variable can be set to differ from %LOCALAPPDATA%\Temp.

  2. using %HKEY_CURRENT_USER\Environment\TEMP%

    • Registry-based path rules seem to apply to all subfolders -- I would prefer a slightly lighter touch (so I don't have to go around whitelisting everything else)
    • Registry-based rules appear to be limited such that you cannot have anything more specific, e.g. %HKEY_CURRENT_USER\Environment\TEMP%\7z*\*.exe
      • I have since discovered %HKEY_CURRENT_USER\Environment\TEMP%7z* will get close (the \ between the variable and the subfolder should not be specified, and you can't specify a filename mask afterwards)
    • It is also also technically incorrect, as this registry location only contains the value as it should be at the start of a process and not what it might be changed to during the course of that process -- e.g. it would not apply if you opened a Command Prompt, issued SET TEMP=C:\ and ran the program from the prompt).

(For what it is worth, I have tried configuring the SRP in both the Computer and User sections of the GPO, both independently and simultaneously, in case one overwrote the other, or %TEMP% was resolved differently at Computer and User level.)

What's so special about the %TEMP% variable that it would not apply here, whereas something like %LOCALAPPDATA%\Temp\\wz*\\*.exe would?

Update:

It appears that the limitation is specifically with the %TEMP% environment variable. I have edited the question, as such.

jimbobmcgee
  • 2,675
  • 4
  • 27
  • 43
  • It does but if you have the path rules like you wrote you have a typo in there writing `exe` instead of `tmp` – lsmooth Nov 27 '13 at 23:43
  • @lsmooth - looks like a formatting issue -- Markdown was escaping my * and \ characters -- fixed – jimbobmcgee Nov 27 '13 at 23:51
  • Actually, rereading @lsmooth's comment; the `.tmp` is not a typo -- 7zip does indeed create temp *folders* with a .tmp 'extension'. In any case, I can still execute a file under a folder called `7zABCDE.tmp` or `7zABCDEFG` and I don;t think I should be able to... – jimbobmcgee Nov 28 '13 at 03:05
  • My guess is the problem is `%TEMP%` exists twice and that for the purpose of SRP the System-`%TEMP%` is used instead of the User-`%TEMP%`. – lsmooth Nov 29 '13 at 22:39
  • @lsmooth - I had considered that too, but the system `%TEMP%` is (for me) C:\Windows\TEMP, and I can run an executable from there too -- unless, of course, since there are two versions, SRP doesn't know which to read and so just bails. – jimbobmcgee Dec 02 '13 at 16:54
  • For me is not working the %temp% variable to block the executions of executables files too. Did you find any workaround? – Marc Cals Apr 08 '15 at 15:58
  • @MarcCals - Just the ones that I listed in the question. I went with the registry-key version in the end, as the lesser of all evils, e.g. `%HKEY_CURRENT_USER\Environment\TEMP%*.exe`... – jimbobmcgee Apr 08 '15 at 17:20
  • @MarcCals - (minor correction), I went with the registry-key version as `%HKEY_CURRENT_USER\Envrionment\TEMP%subfolder`, and let SRP determine what was executable. I couldn't restrict it to *only* *.exe – jimbobmcgee Apr 08 '15 at 17:56

3 Answers3

1

The program might see a different contents of %TEMP% than you, when you check it in cmd.exe or command.com. Sometimes they are not the same.

But using Environment Variables in Software Restriction Policy is a bad idea anyway, because a malware can change the variable.

Klaus Hartnegg
  • 331
  • 1
  • 7
  • Secure and insecure variable expansion are covered in the Technet article linked to in the question. – ErikE Jul 18 '15 at 11:23
0

I use this to block exe files from %TMP% and %TMP%*\ , it looks weird, but it works here on Win7 pro clients, UAC enabled, no administrative permissions on the current user.

%HKEY_CURRENT_USER\Environment\TEMP%*exe
%TEMP%\*\*.exe

I tried to use %TEMP%\Rar*\*.exe and sucessfully blocked run from %TEMP%\Rar15\putty.exe and from %TEMP%\Rar14.tmp\putty.exe

I don't think %TEMP% may have anything special. I double checked, the registry key path I use doesn't affect %TEMP%\Rar*\*.exe

Zulgrib
  • 351
  • 5
  • 19
  • Are you saying that `%TEMP%\*\*.exe` works for you? It doesn't for me. – jimbobmcgee Aug 04 '14 at 13:15
  • Also, the `%HKEY_CURRENT_USER\Environment\TEMP%*exe` looks like it blocks anything in `Temp\fooexe` rather than `Temp` – jimbobmcgee Aug 04 '14 at 13:16
  • Yes, %TEMP%\\*\\*.exe worked for me on the computer i used for tests. Yes the registry path will block fooexe in addition to .exe files but i don't think it would be a blocking situation (never seen a temps folder that ends with exe), i didn't tried with *.exe for the registry path because i had trouble in the past having it apply correctly. – Zulgrib Aug 04 '14 at 16:53
0

Please try this:

%HKEY_CURRENT_USER\Environment\TEMP%7z*/*.exe

Where you omit the backslash (\) after closing % and then use forward slash (/) for subdirectories

I found this reference: https://www.sysadmins.lv/blog-en/software-restriction-policies-rule-creation.aspx

David Hatch
  • 101
  • 2