the future of SRP: AppLocker

Thank you Ronjor for the correction.

 

Resurrection of this thread

A little more on this topic. What MS has done is account for the weaknesses of SRP without actually changing SRP. When any process is created with certain calls, the SAFER keys are examined. Independent of the group policy. If the item is in the monitored list extension and TransparentEnabled is not at None. If these are true, then Additional Rules and DefaultLevels are checked. Somewhere in this mix, things like microsoft installer is not handled. By design of course. Other types as well.

This AppLocker or ACP is MS way of now gaining some form of control over items not controlled by SRP. It has other functions as well, but this is most definatly seems to be a large part.

Now for some more tidbits and goodies. After having a need to examine autorun infections, the Regedit by Lucy prior to this is the surefire method. But there are also methods to stop Autorun and Autoplay. Autoplay in XP is the prompt that asks what you want to do with a media of certain type. However, as has been discussed before, these can be prone to failure. Mainly due to the MountPoint2 regkey. But, you can delete this key, as it will be remade upon next login for the user. Futher, this key would then have default values. It could then be modified for read only, which has some effects, but I have not tested heavily yet to see what they will be.

Using this in conjunction with the other autorun/autoplay killing regtweaks could leave one with safety from USB sticks etc. But one method that seems to work really well is creating at your drive root a directory called Autorun.inf. Subsequent attempts to create a file autorun.inf will fail with no apparent method to overwrite that directory. So you can stop autorun to begin with, using a reg tweak or other method, and also prevent every drive you have from having an autorun file created by making that directory. Works on both hdd and usb sticks. Seems a simple way to ensure your usb stick when in another computer does not inherit bad habits. I have only perfromed a quick test, I suppose there is a chance a virii etc could circumvent that. Maybe setting the attrib to readonly on that directory would help.

Now another one. Maybe some know this, maybe not, so I will ensure you can find it. I originally tried this with autorun.inf. Make a path rule in SRP like this
?:\program.exe

The ? is a wildcard, many probably know. Used like this, it will be active on every drive letter. That means usb hdds, flash drives, cdroms, etc etc. If you were to put ?:\setup.exe, perhaps you could cover a lot of ground. It will not work with autorun.inf. Even dictating a proper path, like D:\autorun.inf does not work. Well, it works, if you double click the .inf. But because autoplay would run the .inf, it is not protected that way. Just something to share.

Sul.

 

Thanks for your post Sul. I'm looking forward to using AppLocker in the future with the final release of Windows 7. In regard to autorun.inf globally, I was successful in SRP with *autorun* Disallowed. Tested on the root of the C Drive, on a USB flash drive (Drive E) and also a CD-RW disc (Drive D) Blocked in all cases.

 

Are you sure? I tried this on xp pro and home, where safer vals were created with deny option, using these syntax for the rules (path rules)
*autorun*
autorun*
?:\autorun*
?:\*autorun*

I tried as an admin, with enforcement for everyone including admin. I tried with both inclusion and exclusion of dlls setting (transparentEnabled).

I used a cd, and upon insertion every rule I made failed, as the autorun started the setup.exe

What could be different. Is this Vista?

Sul.

 

On XP Pro I tried adding reg value manually without use of group policy. Failed.

Next I tried adding that rule using secpol.msc (group policy). Failed.

How did you get it to work?

Sul.

 

My apologies. I have a laptop on a domain and the changes (SRP) hadn't replicated on the server yet, so I thought it was blocked. And I couldn't get ?:\setup.exe to work either.

 

Hmm. If I pick a program, convert.exe (a calculator), and add the deny path rule (manually to registry) using
?:\convert.exe

and then place a copy of convert.exe to every drive/partition, it blocks it on all of them.

Interesting.

Sul.

 

I tested with a Windows XP CD on a LUA. When the CD is placed into the CDROM, I am prompted with RunAs dialog box indicating that I need admin rights to run setup.exe. If setup.exe was blocked from starting, I wouldn't have been prompted with anything and the drive wouldn't have even give a whirl. I will keep testing. When it comes to autorun though, I have been successful using TweakUI along with an added registry entry and it has been working great. Using SRP for autorun is new to me. Thank you for your continued testing.

 

Hmm.

I made a rule, deny path, ?:\setup.exe, put my cd in. Autostart happens, but setup.exe fails due to SRP. Then double click drive same thing. Right click then hit Autoplay, same thing. And finally, double clicking setup.exe itself, same thing. All denied. I am doing this from admin account.

Sul.

 

Setup.exe from the Windows XP install CD still executes in a LUA with SRP enabled. The only thing that saves me is the LUA, I am still prompted to run the program through an admin account. The point I am trying to make is that this file still "runs" even though "EXE" is in the Designated File Types and should stop it. If I create a fake setup.exe elsewhere on desktop, it is succesfully blocked by the SRP. There is something about the Windows Setup.exe install file that the SRP lets through and won't block. I've been trying to locate and block the .dll file(s) responsible for successful execution, but so far I haven't found it.

 

I have been looking further about this new flavour of SRP:

Few quotes:

from http://www.betanews.com/article/Rus...note-with-Windows-7-AppLocker-demo/1242093669

from http://technet.microsoft.com/en-us/library/dd723689(WS.10).aspx

BTW for those who might be interrested, more on the subject on:
http://technet.microsoft.com/en-us/library/dd349779.aspx

For the ones who want to go deeper and deeper:
http://www.microsoft.com/downloads/...FamilyID=025cf2e8-b0ab-4419-b5bb-86ab2d5eca83

 

Interesting words from Russinovich! I wonder if that means what it sounds like it means: that SRP in Windows 7 happens in the kernel instead of user-mode like it is done in XP. That would be great - it would make bypassing SRP vastly more difficult.

Are you 100 % certain that the setup.exe is actually executing? Have you confirmed the process is actually running?

I ask, because I think it's not actually executing, at all. It's just that any file named setup.exe or install.exe will always pop up a Run As dialog if a limited user attempts to execute them in Explorer. Seeing the Run As dialog does not mean anything is actually executing. You could create an empty text file called setup.exe and doubleclick it in Explorer, and Windows would still give you a Run As dialog if you are LUA - even though the file is just an empty text file and obviously not a program! There is nothing special about Windows' own installer files that bypasses SRP. It's just a Run As dialog.

 

It is probably the Autorun.inf file on the XP install CD that launches the Setup.exe file. Does LUA/SRP not prevent this?

 

Autorun.inf files are not executable files. They are .inf files, and as such rundll32 or some other trigger is the actual executable. So, from every test and every article I have been able to dig up, there is no way to stop the execution of autorun.inf from SRP because there is no executable to block. Well, you could block the actual executable such as rundll32.exe, but I think you would break much functionality of the OS in doing so. I don't recall if rundll32 is the actual program or not, just using it as an example.

The only way native to the OS so far that I have found is to either deny executables named setup.exe (a crap-shoot at best if this is your only defense) or put in place a universal registry hack that stops all autoruns.

Sul.

 

On the XP install cd, it is of course the autorun.inf that "launches" the setup.exe. Neither SRP nor LUA does anything to prevent Windows from reading autorun.inf files and attempting to follow the commands given in such files. But SRP still blocks unauthorized autoruns. If that sounds complicated, it works like this:

1) Windows reads autorun.inf file and sees that there is a command to execute Setup.exe in there. So far, SRP has done nothing. The purpose of SRP is not to prevent Windows from reading text files, like .inf.

2) Based on instructions in the autorun.inf, Windows tries now to execute Setup.exe. Now SRP comes to life, and it checks Setup.exe against its set of rules. If the default rule is disallowed, and there is no additional rule that allows Setup.exe (there shouldn't be), then SRP blocks the execution of Setup.exe and the autorun.inf has effectively done nothing - it has not been able to execute anything. If it had been a malicious autorun file, nothing bad would have happened.

3) Well, that is how it would work if the file wasn't called Setup.exe. But because the file is called Setup.exe or Install.exe, what happens is that after step 1, Windows gives you a Run As dialog before even trying to execute the file, since it is coded to do so if you're running a LUA. Nothing has attempted to execute yet, so SRP doesn't even beep. If you choose to run as admin from the dialog, then SRP allows it unless your policy applies to admin as well. If you choose to proceed with the current account's credentials, then SRP blocks the file from running.

Simple as that.

So, while SRP does not block the reading of autorun.inf (what use would that be, anyway?) it will block the actual execution of anything that the autorun.inf instructs to be executed, unless it was already set to unrestricted by some SRP rule.

Knowing this, SRP is a good defense against attacks based on autorun.inf. With a default disallowed SRP, the only things that can execute based on instructions from an autorun.inf are files that are already set to unrestricted by SRP rules, anything else is blocked from running. This is very easy to test, too, for those unbelievers who doubt my words.

First, enable autorun functionality if you have disabled it, for the purposes of the test.

Create an autorun.inf file on your favourite removable media that has shellexecute=rundll32.exe user32.dll,LockWorkStation and then test it. What happens now is that Windows locks your workstation, as rundll32.exe and user32.dll are allowed to execute because they are in the Windows\System32 folder. Is this bad? No. SRP is doing as it should, allowing stuff in System32 to execute. By the way, this is something I've seen people misunderstand all of the time. If you put a copy of user32.dll on your removable media, and use an autorun file like that, you're still not executing anything from the removable media. Windows already knows where user32.dll is supposed to be (System32) and loads the dll from there, even if you have a copy in some other location. The only way to get Windows to load the copy is to give a direct, full path to it, or rename it to something that isn't a known Windows dll.

Next, create another autorun.inf. For that one, you can try whatever you wish. You can copy some exe file on the removable media and rename it file.exe, and then put a shellexecute=file.exe line in the autorun.inf. Or, you could mimic Conficker, and copy that user32.dll on the media and rename it to file.dll, and then change the autorun.inf to shellexecute=rundll32.exe file.dll,LockWorkStation. Whichever you choose, go and test what happens. What happens is that SRP blocks the execution of file.exe and file.dll, just like it should, and nothing potentially harmful could execute. Rundll32.exe does execute in the latter example, because it's an allowed file, but it cannot load the disallowed dll, and gives you an access denied.

No special tricks are required for SRP to protect against typical autorun attacks. SRP also blocks setup.exe or install.exe automatically, without any trouble or additional rules. Don't be fooled by the Run As dialog. Instead, check to see if the process is actually executing or not.

Autorun.inf is not an executable file, correct. Therefore it cannot be executed. Something that cannot be executed cannot be stopped from executing, because it never even tries to execute in the first place. Just like you can't stop a car that is parked somewhere, because the car is not moving and you can only stop things that are moving.

However, autorun.inf contains instructions to execute other files that are in fact executable. SRP can, and does, prevent the execution of those files. So, in fact, SRP does prevent autorun.inf from being used to execute anything that is not already allowed by SRP rules.

There is no need to block anything. As explained above, SRP already blocks anything that is not allowed by a rule from being executed based on instructions in autorun.inf files. Also, it's not rundll32.exe that runs whatever autorun.inf instructs the OS to run. It is a function of Windows Explorer, so you're dealing with Explorer.exe and Shell32.dll, and blocking those is not an option. But then again, there is no need to.

Again, no need, for reasons explained above. Just because you see a Run As dialog for files called setup.exe or install.exe does not mean those files somehow bypass SRP. That Run As dialog for Setup.exe and Install.exe is basic Windows functionality gods only know how old.


SRP is effective in disallowed by default mode. In any other, it is easy to bypass. SRP also cannot be used for things like blocking autorun.inf when you are an admin and have an unrestricted default rule. It's really not what SRP is meant for.

 

I kind of remember seeing the RunAs dialog before I disabled Autorun.inf, so I will take your word for it, Windchild. BTW, very nicely explained

 

This is interesting. I hope you are correct, but I will say I have doubts, only because I created my own executable setup.exe, and my own autorun.inf, in differing flavors, after reading much of what Rmus was talking about concerning them.

My tests, from USB and optical media, show that the method the .inf file uses is not affected by SRP at all. Indeed, only explicitly stating the file setup.exe to be denied has ever worked.

My testing was in a blacklist mode from admin, so that without specific deny rules anything would run. Was your test performed in LUA using default-deny aka whitelisting?

I will revisit this again. Thanks for sharing.

Sul.

EDIT: oh, I see you do mention this is for default deny. I should have read a little better lol. I am still looking for a way to stop autorun on certain drives as admin without killing autorun completely. Tweakers are never truly satisfied

 

Yeah, it's for default disallowed. Anything else is a crap shoot with SRP, really: bypassing a default unrestricted SRP is so easy that it is not even fun, although it can still be somewhat useful to have SRP restrict only some locations like Temp or browser cache folders.

As for your tests, though, I would need to know what exactly you tested to explain the results. The main point, though, is that with regards to autorun.inf SRP has no special functionality, that is to say, no functionality to disable autorun.inf in particular. So, to use SRP as protection from autorun attacks, one would have to make rules that disallow anything the autorun.inf is likely to run, such as exe files from removable media (drive names that do not belong to hard disks). Disallowing the autorun.inf itself does nothing, since it is not executable and never tries to execute anyway - it only contains instructions that tell Explorer what it should launch. If we have a removable drive called H, a disallow path rule of H:\ in SRP should prevent any autorun.inf file on that drive from "executing" anything that resides on that drive, regardless of what the default SRP rule is. This would defeat Conficker, for example. Haven't actually tested that myself, though, so I cannot be sure - for all I know, there could be one of those mysterious Vista bugs making SRP disregard such a rule. Probably not, though.

For blocking specific drives from being able to autorun stuff, there's also the NoDriveTypeAutoRun key: http://support.microsoft.com/kb/967715/en-us With the MS patch, that actually works as advertised.

But really, it's the Run As dialog that Windows pops up for anything named setup.exe or install.exe when logged on with a LUA that makes people think SRP has somehow been bypassed, even though that is not the case at all. The Run As dialog is an Explorer feature. It doesn't actually execute anything, until you tell it what to do, at which point SRP comes in.

 

Here is my test. It is a custom executable that checks that autostart reg key, reads and write and deletes a value in the registry, copies and renames itself to the root drive as well as copies and renames a secondary .inf file to root. It leaves those files on root, but does delete the test registry value.

It does nothing other than test. It assumes the autorun.inf file executes it, but you can also execute the setup.exe and see if other protections are available. Obviously, running other protections such as Threatfire or similar will prompt the user because it writes reg vals and copies to root.

Check it out if you like
http://mrwoojoo.com/sg/SG-Autorun-test.rar

Sul.

 

Ok. Now I know what the test file actually does, once executed. Looks like a good little simulation test for some HIPS to detect. But, the really relevant question is how did you test SRP with this file? I mean, I see the contents of your autorun.inf here, with the Open line referring to setup.exe. That means that if autorun is not disabled, Windows will try to CreateProcess that setup.exe file, and that is when SRP comes in, and either allows or blocks based on the ruleset. And that is my question: what were the SRP rules that you tested, to try to stop this setup.exe from being launched by the autorun.inf file? Because, for SRP, it really doesn't matter what the file itself does. All that matters is how the file is being executed and what the rules say about it.

For example, if you tried to use SRP to block the execution of this setup.exe by making a disallow path rule for "autorun.inf", that would never work - because autorun.inf is not an executable, and nothing ever tries to execute it (CreateProcess is only called on the setup.exe file, never on autorun.inf). For the same reason, any variation like "autorun.*" or "*:\autorun.inf" and so on, would fail to block the execution of setup.exe. These rules would block autorun.inf, though, if it was in reality a real program file just renamed autorun.inf for some reason, and if something then tried to execute it (like running start autorun.inf on the command line perhaps). But I've never seen anyone try that!

However, if you made a disallow path rule of "X:\" where X is the removable drive you want to block, then SRP would successfully block setup.exe from being executed as well as any other executable file on the X removable drive - although the Run As dialog would still happen, as it always does, if the user is LUA.

So, if you remember the SRP rules you tested while trying to prevent setup.exe from running, I can certainly tell why SRP failed or succeeded.

 

Erm, yes you can default deny a drive with SRP. But that is not denying autorun, only every executable file type on the drive. While that does work, I don't see that as a method to stop autorun itself. I mean, I want to stop autorun with SRP, but not stop every executable on the drive.

Here are 2 threads to look at.
https://www.wilderssecurity.com/search.php?searchid=3036695
https://www.wilderssecurity.com/showthread.php?t=240319
I wish there were a way with SRP to selectively stop autoruns from USB drives or other drives without killing all executable functionality. At least for my use where I don't want to create a whitelist, but a blacklist.

Sul.

 

Correct, that is not denying autorun. It's just preventing autorun from executing anything that is not allowed, and blocking pretty much any autorun-based malware attack. But it is true that it is not a method to stop autorun itself, and is not meant to be that. SRP is not meant to stop autorun. It is meant to control execution of programs, and nothing more. If all you want to do is stop autorun, SRP is not the solution. It was never meant to be. The same can be said of any execution blocker, really. There is no way to use SRP to block Windows from reading autorun.inf and attempting to execute stuff as instructed in the autorun.inf. With SRP, you can only block the actual execution of whatever bad stuff the autorun.inf refers to. Good enough for me.

 

Say, I've got a question for you experts, and I'm sorry for steering the topic away from the current focus on Autorun.inf, but hopefully this will be relatively quick and painless I set up SRP according to instructions here on one of my XP pro machines a couple weeks ago and it worked perfectly off the bat. However, Last night I followed the exact steps again on my other XP Pro machine but the problem is it blocks all executables under the limited accounts! Nothing opens, including Firefox, IE, Sandboxie... you name it. The administrator account is fine.

So, today at work I did some more careful reading (not so tired eyes ) on the site I linked, and I see the following:

So it immediately occured to me the one difference with the problem pc compared to the other is that I have my installed programs under a different partition labled "D" instead of the typical drive letter "C". So, could this be the stumbling block, and will I simply need to just create an approved path for this location? Thanks in advance!

 

@Windchild
Of course you are correct. I can use reg values to stop autorun. I can use SRP to stop executions. I seek of course a built-in approach to stopping autorun but not execution, and also stopping autorun but not autoplay (insert notifications). There are a few ways to do it, but having SRP flat out deny autorun.inf would have been so nice.

@wat0114
I don't consider myself an expert lol, but I think I understand SRP enough to help you.

That website helps you create a default-deny approach for LUA. Remember that a User is allowed by default to execute and read in c:\windows and c:\program files. The default values used with SRP leave those areas open for execution, so as not to lock you out from running things. The method you are using has you block everything outside of those areas. The method also removes the .lnk file extension. So what you have is the blocking of starting executables themselves, while allowing the .lnk to run the executable. It is a pretty nice method of controlling execution because a malware type program would have to create a shortcut and then execute the shortcut.

Your problem if I am understanding correctly does stem from the non-default location. A good example would be if you had this directory
d:\program files
and that is where you installed programs to, you could create an allow rule just like the default that allowed unrestricted execution for that 'other' program files directory.

You know, the overall idea is pretty simple. You have defaults that allow windows and program files executables to run. If you navigate to those areas and execute, it is all fine. Because the User account (LUA) does not give you rights to modify in those areas, you can run them. Then the idea goes further, where you want to deny any other location for executing. So if you place notepad.exe on your desktop and run it, it fails because desktop is not an unrestricted path. So it is cool, you download a rogue app into my documents, it cannot execute under normal instances. The removal of .lnk file extension helps you to easily create shortcuts to things.

So your case of this place on d:\ is no different than if you tried to execute from my documents. With no rule to allow unrestricted execution, only a shortcut would work. You place an unrestricted path rule, and it will work.

Sul.

 

If you carefully follow the philosophy of Mechbgon, you have two things to do:
1- the obvious one to allow execution on D:\
2- the second one is to make sure your administrator has or take ownership of D:\ AND that only administrator (and system..., but not standard users)can save, create, modify D:\

This is the basic: separate your computer in two wide areas:
1- right to read and execute (basically system and programs), but no modification (except admin)
OR (and never AND)
2- right to save, read and modify (basically datas like pictures, office docs...), but no execution (except admin)

Tlu made great articles on this subject in different threads on this forum:
https://www.wilderssecurity.com/showthread.php?t=200772