Maximising Windows VISTA security with LUA and SRP (even without ultimate)

Can you be more precise? With a better explanation
(note that it doesn't imply you didn't explain well, but rather that I am bit slow to understand )

 

I'll try.

OK. I added the following lines to the registry file I have to apply the software restriction policies, to exclude the path C:\Exclusões PRS:

This should make software restriction policies not apply to anything within this folder. At the image of what happens with C:\Program Files and C:\Windows*.

But, if a start any file, program, etc., placed at the excluded folder "Exclusões PRS", the warning saying that is forbidden by software restriction policies always appears.

I did a test with a batch file, by creating a shortcut in the Desktop linking to the batch file in the folder C:\Exclusões PRS. I clicked the shortcut and it started the batch file, without any problems.

So, in a way of speaking, the exclusions are working. But, my doubt is, shouldn't I be able to start any file, etc., placed at the excluded folder, since this an excluded path from srp?

I hope this helps you understand better my question. If not, I'll try explaining better, if I can.

Thanks

 

Ok.

Simply restart your computer and the new policy will be updated.

I managed to repeat your issue, and the reboot corrected the situation.

 

Shoot me in the head already!!!!

This issue was happening yesterday night. This morning, I didn't even check to see if it was still happening. I just did. Works fine!

Sometimes all it takes is a tiny detail to make things work!

I appreciate your feedback.

Thanks.

 

If you are making SAFER reg values by hand instead of with the snap-in, you must reload the registry for it to take effect. An easy way to do this is to open task manager and kill explorer.exe (the shell). Then use the Run command from task manager to start explorer.exe. All registry values will be reloaded and work.

Sul.

 

I've come across some strange situation. I don't know -and, somehow I doubt- if it is related with the software restriction policies.

The situation is the following. A few moments ago I was going to record an iso file to a dvd, but the dvd drive wouldn't recognize any of the empty dvds. I inserted a record dvd, but the dvd player still doesn't recognize it.
Then, I booted my system with Windows Vista dvd, and it boots. So, there is nothing wrong with the dvd player itself or it's controller.

I wondered if could had been the Windows updates that occured yesterday night causing this issue. I restored the system to a previous state (Windows restore), and the dvds would be played again. (By the way, I had to update Windows Defender manually, because Windows Update seems not to find any for it, since 2009-04-23.

So, just to be sure if were or not the updates, I re-applied the registry tweaks for the software restriction policies. The dvd no longer recognizes any dvd.
I then disabled the software restriction policies, but, the dvd player still doesn't recognize the dvds.

Now, why do I say I doubt that is related to the software restriction policies? Well, yesterday night I could create an imagine of a dvd. And, the software restriction policies were already applied for a while. And, besides that, one other system has the same restriction policies and the dvd player recognizes the dvds.

But, could it be related to the software restriction policies?


Thanks

 

To disable SRP in registry, set the value TransparentEnabled to 0, which is apply SRP to no files basically. Reload the registry by restarting explorer or reboot.

My experience with SRP and drives has been explicitly declared j:\ or wildcard ?:\ will stop execution of files with extensions in the list SRP monitors for. I cannot imagine why SRP, as an executable stopping mechanism would be doing this. If you have the default rules to allow applications in %windir%, %programfiles% and c:\, you would think anything that MIGHT be related to your issue would be there. I personally don't think that is the issue though, as you say as well.

Have you examined the device manager to see if there is a conflict? Maybe IRQ. Or maybe, as you say, the windows upate is borked. My money is on that if it worked prior.

Sul.

 

No. There is no method I have got working for manual registry entries to work in SRP. The only way to get it to work is with the mmc snap-in. The same applies to AppLocker. Only with the snap-in can it work. I tried many services that were not running, but no love. Unless this is a bug that will be addressed, or there is another service that needs to be running or a value to toggle this effect, it does not work anymore on win7. I wonder what versions of win7 will have SRP/AppLocker and which will not.

Such a shame.

Sul.

 

Disabling SRP didn't do the trick. I don't even think its related with it, as I already said. I also say it, because, for what I know, while booting in Safe Mode SRP is not applied. Correct me if wrong. So, if the SRP were the culprit, then in Safe Mode it should work, right?

Yes, I've examined the device manager. For what I could see there are no errors over there. I even uninstalled the driver and then reinstalled. No deal.

It crossed my mind, that, no so long ago, and I hope I'm not wrong, Windows Defender updates were causing cd/dvd players not to work. So far I haven't come across any info on the net. I'm still digging, though.

Anyway, thanks for your feedback.

 

Yes, safe mode disables SRP.

I have seen this issue with optical drives before. Often it is hardware dependent to produce the issue. I don't know why or what causes it, but in your case it seems some update is breaking it. I never figured out why this happens, usually just swapping optical drives fixes it. Sometimes flashing the firmware in the optical fixes it. I have even seen 2 exact same drives, where one does not work in my machine but does in my wifes. Hers then works in either, but obviously has a new home in mine. And these were brand new. After windows install, the drive refuses to work.

It must be something MS changes in updates that has an effect on certain hardware combinations, or thier updates don't play well with certain driver and hardware combos.

Good luck tracking that one down. I usually try for a bit, then if it looks to be sucking too much time, swap something out to rule out hardware.

Sul.

 

I've just found an interesting SRP leak.

Before everything else, this is how I have my SRP applied:

- Everything in C:\Windows and C:\Program Files\ runs as unrestricted.

- Everything else has no permissions to run, at all.

I was going to edit a JScript file, which I had in a folder, and I forgot that the extension *.js is being blocked by the SRP from being executed. So, before I even remembered it was being blocked by the SRP, I first right-clicked the file and opened it with Notepad. Well, a error shows up due to the SRPs. Makes sense, after all, though Notepad is in a path which is excluded from SRP, the JScript file is not.
Just out of fun (I don't know why I even tried it. ), I tried to open it with Notepad++, and it opened.
Now, this shouldn't happen, because the JScript file was in a folder where it can't start.

A leaky SRP or an abusive Notepad++?

 

I am thinking about setting up an SRP to block execution of double extension files ending with *.*.exe and *.*.vbs as a lot of malicious files try to hide their extension by using something like "filename.txt.vbs" to fool the user into thinking this is a text file when it is a script. Good idea, or are there any problems this may cause that I am overlooking?

 

xxJackxx

Or you could use AnalogX Script Defender free from http://www.analogx.com/contents/download/System/sdefend/Freeware.htm

Been using it for years with no problems. Takes up NO resources whatsoever normally, as it only jumps in when it detects something you've asked it to.

I've included all the following for protection against - .ADE,.ADP,.ASF,.BAS,.BAT,.CHM,.CPL,.CRT,.CSS,.EMF,.EML,.HTA,.JS,.JSE,.PIF,.SCT,.SHA,.SHB,.SHS,.VBS,.VBE,.WMD,.WMF,.WSC,.WSF,.WSH

 

I have mine like that, as well. I have, so far, one extra block, besides those you mention, which is *..scr

But, if you fear to be tricked into open a false *.txt file, for example, you could just set Windows to show known extension file types.

Just to Windows Explorer, Tools - Folder options- See, and clear the box where it says to hide known extension file types.


Regards

 

Well, why use some extra tool, when Windows already provides the means to do it?

 

m00nbl00d

Yes i agree, and i have always had every version of Windows configured to show extension file types, and hidden ones.

( why use some extra tool, when Windows already provides the means to do it? )

It took me about 2 minutes to download and install AnalogX Script Defender and copy and paste all those settings into it. But the main thing is, i install on average Jo's PC's as they arn't very alert to watching out for extensions etc etc, and/or find it all confusing, along with lots of other things. It makes life easier for them, me too !

The reason i excluded .SCR on my PC, is so i don't have to keep allowing it when it kicks in. Valid reason to include for some people though i concur. I personally wouldn't allow any unwanted .SCR or .Whatever loose on my PC.

 

I'm going to have to agree with this thought, though I do appreciate the suggestion. I work for a software company and have a legitimate use for some scripting. I just want to stop any double extension ones from executing.

 

I believe that would be easily achieved by SRP, by for each *.xxx extension we block, we also block *..xxx. (the face with the 3 question marks, are 3 question marks... bloody faces )

For example:

*.xxx is *.exe

By blocking *..exe, everything with double extension ending in ".exe", would be blocked.

I'm not saying that AnalogX is a bad idea. I believe one uses what one feels most comfortable with.

 

Script Defender is excellent for what it does, but has a weakness.

Script Defender will intercept if the user clicks on the file. Using the Finjan.vbs test file:



However, if executed directly via a Script Engine, such as used in an autorun.inf exploit, for example:

Code:

wscript.exe finjan.vbs

then the file happily executes:



Script Defender (and similar programs) work by modifying the Registry to pass the OPEN command for script files directly to SD. This is in effect using the Windows file associations to control executing the files.



But the wscript script engine used as a direct command does not depend on Windows file associations, so SD doesn't see the command to execute the file.

This is the weakness in such programs.

One user of SRP has a rule to block wscript.exe and cscript.exe which takes care of any method by which script files are executed.



----
rich

 

m00nbl00d

Sure, blocking .exe's wouldn't be a good idea as you noted. But in the block list i provided, i excluded .exe for precisely that reason !

Rmus

Of course you're correct, but i and others have found that on a number of occasions that AnalogX Script Defender helped prevent something dodgy from launching. Though in my case it was deliberate as i was testing nasties.

I disabled wscript.exe on my 98SE PC with no side effects. Had forgotten to do so on my XP PC. Not sure if doing so on XP and/or Vista would break anything serious ? The same goes for cscript.exe. If it's feasable, then simply slightly renaming both those .exe's would do the trick, as in my 98SE. Though in XP/Vista's case in might need to be done in Safe Mode to prevent windows from automatically replacing them straightaway. I have found in the past if you're really quick in renaming, it works without Safe Mode !

Do you forsee any real negative effects on this idea for XP/Vista ? Your input would be very welcome.

 

Also not to forget, when c/vb scripting is to be needed, that you may be able to just open a hole for specific scripts or a specific directory to house scripts. Then you have scripts you made or trust that can still run, but you deny by default others.

Sul.

 

That is what I am currently testing, the *. followed the the 3 question marks followed by .exe and another set followed by .vbs and so far I have no issues. The thing I don't like is with the 3 ? it will block anything with 1, 2, or 3 characters in that spot, rather than looking for 3. Basically *.txt.exe fails to execute, as does *.tx.exe, and *.t.exe. Hopefull there aren't too many .exe files with an extra "." in them that will fit that pattern. I don't care as much with the .vbs. If they don't run, they don't run.

 

But, wouldn't that be the point? Normally, and considering we're talking about a legit and safe executable, an *.exe file will come as [some_name].exe, and not as [some_name]..exe.

Most users don't even have Windows set to show known file types extensions, and they would be running [some_name]., believing it was a legit [some_name].doc file, for example.

So, having SRP like that, would prevent such from running. So, if some *.exe file fills those patterns, as you mentioned, then this is what we want SRP to block, be it *.*.exe, *.**.exe or *.***.exe.

Why wouldn't you want SRP to block all three possible situations? (I'm not aware of the existence of legitimate *.exe files with double extension. After all, if it is legitimate, it has no reason to hide it's true nature.)


Cheers

 

You wouldn't be able to run any script files that use the Windows Script Host.

I've never renamed a system protected file in XP, so I don't know!

----
rich

 

Correct to a point. But then you get those installation programs that have a version number included. I feel it is poor form to do that with a "." character, but that doesn't stop everyone. Looking through my downloads folder I see Windows debugging tools. dbg_x86_6.9.3.113.exe is the filename. It would refuse to execute. Easily renamed, but not something that was intended to be blocked. I'll keep the rule I made, but little gotchas like this are annoying.