I’ll definitely try it this weekend 
Thanks.
Ok that was painlessly quicker than I envisioned all this time :). It works well, but I have some questions:
-
There are some executables (e.g. NTDETECT.COM, AUTOEXEC.BAT etc) on the root of my C:\ drive (and likewise in various C:\Windows and C:\Windows\System32 etc folders) that are potentially critical to the normal functioning of my OS. If those are blocked from executing, would I need to create various path exceptions or does the XP System account have priority over SRP and is actually doing all the background job?
-
By default there 4 paths (btw, isn’t the 2nd one redundant due to the 1st allowing all files to execute?) with unrestricted access. Does that mean I have to be cautious on where I save new executable downloads? I sure wouldn’t want an unknown .exe file to save to C:\Program Files, right?
-
That leads me to the biggest concern: the browser cache. Theoretical example: I visited a trusted website that has been hijacked. How can I fight against drive-by downloads that can save malicious files to C:\Program Files\Opera\cache or whatever? Or is that the 4th path in the exceptions only apply to the root of C:\Program Files and not its subdirectories?
-
The guide states “If you want to turn the Software Restriction Policy off again, just set Unrestricted as the default, and that’s the same as not having a Software Restriction Policy at all.”. Is there a registry or script tweak whereby I can just double-click on a .reg or .vbs file to toggle SRP on and off at will? Maybe even a right-click context menu ;D. Nah. Too confusing, but I’d rather not have to navigate through those branches to do that. I like it to be close to instantaneous if at all possible. At the very least, there should be a way manipulate a shortcut with gpedit.msc command to take me straight to that spot.
-
If I wanted to “uninstall” SRP ;D, how do I do that? There’s no right-click option. I know that most or all of gpedit.msc tweaks are really controlled by the registry, but it’s better if there was a way to remove them from within gpedit.msc.
[attachment deleted by admin]
The easy way to set up SRP is to allow admin accounts to execute any file so the system will be OK.
XP does not use autoexec.bat and I don’t know why NTDETECT.COM is in root. Vista and Windows 7 have nothing executable in the root. I thought XP was the same.
You need to run as limited user so you cannot write to c:\program files or sub directories of.
Use a browser that does not have it’s cache here. It needs to be under your user directory.
Just turn it off as in question 4. It will not matter if it is there but turned off.
I never modified my Administrator acount (I have the one and only original “Administrator” btw :D) permissions, so I guess I passed :-TU. I rebooted with Defense+ permanently deactivated and DEP system-wide protection on and so far my computer hasn’t blown up :). If my thought above was correct, it’s actually the System not my Administrator account that executes all those system files, so it’s all good.
Okay let me ponder about this under the LUA scenario… The .exe file is only allowed to save/write in C:\doc & settings<LUA account name>, but it can’t execute from there (not even under Admin account). It can only execute under those SRP default paths like C:\Program Files\ or C:\Windows. But I can’t even drag that file to those places because I don’t have write permissions. How would I be able to run it if I know it’s legit? The only way I know of at this stage is to logout of my LUA and back into my Admin account. To have to do that each time I want/need to update a program alone is impractical… I’m trying to think of a better procedure.
I’ve seen posts that state vbs files aren’t prevented by SRP by default. Then why did this script not launch when I tried to from my desktop? It’s something that I copied from a website, pasted into a text file and renamed as .vbs. I thought it was sort of obvious by the description.
[attachment deleted by admin]
Yes, it’s more painless than most people think. Well, “most people” haven’t even heard of SRP. And then when “most people” look at or read about LUA + SRP, they decide that it’s too difficult, and instead spend endless hours playing around with other third party security software haha.
And yes, any program that needs to write to C:\Program Files or C:\Windows is not a well written program at all, and you should not use it. The concept of LUA has been out on Windows platforms for a long time (more than 10 years I think?), so it’s no excuse anymore!
...but I'd rather not have to navigate through those branches to do that. I like it to be close to instantaneous if at all possible. At the very least, there should be a way manipulate a shortcut with gpedit.msc command to take me straight to that spot.
Yes, there is a way to create a shortcut to gpedit.msc, so that you don’t need to keep navigating through. I can’t recall exactly now (I’m not on my usual computer), but I think you basically just need to right click on the “Local Security Policy” shortcut in the “Administrative Tools” folder and create the shortcut on your desktop. I recall once the shortcut was created on my desktop, I moved it to my QuickLaunch bar for easy access (you can leave it on your desktop too I guess, as that’s fairly easy access too).
The .exe file is only allowed to save/write in C:\doc & settings\, but it can't execute from there (not even under Admin account)
Why can’t it execute from there under an Admin account? Of course it can, if you have configured your SRP to be exempt to Administrators (which is the right thing to do). And what is the big deal of having to move from your LUA to your Admin account etc? It only takes about 5 seconds to move back and forth right? You’re already spending many seconds answering pop-ups (classical HIPS), managing your rollback list (DefenseWall…not seconds, but sometimes hours haha…DefenseWall just isn’t good for the above average user in this sense, as they will tend to want to manage this rollback list to keep their system clean from malware fragments…in this case, Sandboxie is the answer for much easier emptying!) and what not.
And it’s not like you’re updating programs everyday or even every week. Logging into your administrator account once every couple of weeks is no big deal at all. And if you’re really that hard up about this, you should read about and learn to use SuRun. Just remember that SuRun 1.2.0.8 (latest stable version) works fine on Windows XP, but doesn’t work well on Windows 7 (for me anyway). However, 1.2.0.9 Beta 10 works fine on Windows 7 for me, but I’d wait for the stable version before installing on the REAL system.
With SuRun, you can run things as administrator in your LUA much easier, thus bypassing SRP if needed. I often use it if I’m wanting to run executables in Sandboxie in my LUA + SRP. I don’t think you can do this with “Run as administrator” context menu function in Vista/7. Furthermore, “Run as administrator” simply is no where near as versatile as SuRun - for example, if you use Shadow Defender, you’ll realise that it can only be opened with administrative rights. With SuRun, you can configure it so that Shadow Defender is automatically opened with administrative rights without any pop-ups etc. Without SuRun, you’d need to rely on Windows Vista/7’s “Run as administrator”, meaning you’ll always have to right click and use the context menu every time you want to open it.
No such option. I’ve quadrupled checked. I think it’s down to a .reg file, but I wouldn’t know where to start.
Actually, I’m still on my Admin account and configured SRP to apply to all accounts include local Administrators. Result: nothing can execute even within C:\Documents and Settings\Administrator, which is what I want. However, I seem to have overcome the issue with my browser cache and drive-by downloads by adding the rule. I could be totally wrong on this though, since if Opera is installed in C:\Program Files\ it must have admin permissions. Therefore it’s possible (though unlikely due it not being IE6 :P) to automatically execute executable files silently and without my consent. At least I know that rule works if a user (as opposed to the browser which may have Admin or System access) happened to run executables from within Opera. Can anyone confirm?
Update: Thanks to Zsoft Uninstaller and after many switching back and forth between gpedit and regedit, I was finally able to narrow it down to just one registry entry that controls SRP status :o
To disable SRP:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000
To enable SRP:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000
Just copy & paste each into Notepad and save as .reg files. With that in mind, I just have re-google how to import reg files with suppressed alert (IIRC it’s the /s switch). Somebody else might even be able to code a simple vb script file to with if else conditions to toggle it into one file. And to further expand, it’s possible to create shell context menus
[attachment deleted by admin]
Good to see that you’re discovering things yourself.
However, you need to quadruple check again. Why? Because I ran Admin + SRP once too, and it was very easy to create the short-cut to “Local Security Policy” without touching the registry directly. Hope you find it, but it looks like you have perhaps a faster way to enable/disable SRP anyway, so I’ll leave you to it.
I don’t use Opera myself, so I can’t confirm, but I’d be surprised if Opera saved files etc into C:\Program Files. I know IE 8 and Firefox certainly don’t exhibit that behaviour.
Anyway, glad you’re happy with SRP! Hope to see you using LUA in the future also - it’s a killer combination with SRP.
EDIT: oh, and just to clarify (you appear a little confused I think), if you configure SRP to include administrators, then all the rules in your SRP will apply in your administrator account also. This means that in order to execute outside of C:\Program Files and C:\Windows, you will need to configure separate path rules for the relevant areas you are wanting to execute from.
However, this obviously opens up a security hole, as this means there are folders that allow execution AND writing! This means that malware can potentially write to the folder, and also execute - theoretically dangerous. And this also brings the point of using LUA instead of Admin, because in an admin account, anyone can write to C:\Program Files and C:\Windows, which are the most common areas for malware to write.
For me, if I need to configure extra path rules to allow execution from separate folders in my LUA, I would ensure that these folders/paths are disallowed writing access.
If you can understand this, then you can understand why LUA + SRP complements each other so well.
That’s because of Opera’s classic installer. The regular one does save to the user’s folder. I’m going to create a LUA and test to see what happens when I launch Opera. Although I have the feeling it won’t work properly if it can’t write cache files in C:\Program Files…
BTW, can you test to see if these PDF’s can launch Windows’ command prompt and calculator? Don’t worry, they are just POC’s:
http://didierstevens.com/files/data/launch-action-cmd.zip
http://seclabs.org/fred/docs/sstic09/samples/actions/launch/calc.pdf
SRP certainly didn’t work. I wonder if LUA does.
Soya,
Open operaprefs_default.ini and change
Multi User=0 ; If enabled Opera will use Windows profiles to store individual user settings
to
Multi User=1 ; If enabled Opera will use Windows profiles to store individual user settings
Yes, doesn’t sound like Opera will work properly in a LUA like that.
And yes, I’ve tested those files a few days ago. SRP of course does not block those, as cmd.exe is allowed to run (and calc.exe also). But this is why you should block cmd.exe from running with a separate path rule with your SRP. I don’t think calc.exe poses any security risk, so there’s no need to block this, but cmd.exe certainly gives the possibility for further execution of a malware process.
Regardless, there are several other (potentially dangerous) executables you should block with your SRP, like wscript.exe and cscript.exe. If you are willing to wait a few days, I will release my article explaining my signature, and then you will have many more answers.
I admit that Classical HIPS can be very powerful against these rare attack vectors, but as you know Classical HIPS can be bypassed also, and often require a lot of computer “house work” to maintain whenever you update (or install new) applications etc. My article basically suggests a way to be “100%” protected against even these rare attack vectors, and it doesn’t involve any Classical HIPS, and only involves the use of one real-time third party security application (Sandboxie).
By the way, since you appear to be interested (like I am) about defending against extremely rare attack vectors, how are you going to protect yourself against this:
Have a good one!
Thanks JoWa. I didn’t know that. However, I won’t change my profile directory for various reasons (see the Opera thread).
My interest in security can range from null to somewhere out there, depending on my mood ;D. It’s been fun messing around with SRP and permissions lately. As an added bonus, certain obscure parts of my software seemed to have sped up ever since I disabled Defense+ (not that it had much of a performance impact to begin with).
Just a quick question: will there be undesirable consequences if I decided to convert my existing Administrator to LUA, rather than create a brand new account? I’m not sure this is possible given that it’s the original “Administrator”.
Yes, D+ certainly slowed the file moving process (particularly of larger executable files) when in Safe Mode, although I haven’t tested it with version 4 yet. Other than that, I remember D+ being extremely light on my system - I note that you are running a fairly old system, so that could be why you’re noticing more slow down in general.
Not sure if I’ve mentioned it before here (I certainly have stated it in my article), but do NOT strip your Admin account to a LUA. The reason for this is related to the windows file/folder permissions - essentially converting an Admin into a LUA will muck these permissions up, and your LUA files/folders will be allowed to carry out processes they normally would be denied from. To sum up, NEVER strip an Admin account into a LUA! This applies to Windows XP…I’m not certain if it applies to Vista/7 though, but I still wouldn’t recommend it.
That’s what I figured. And maybe because my XP has been refined (nLited 88), I might’ve removed some required services or files that were necessary to downgrade the built-in Administrator account; it didn’t work. I also tested by creating a brand new LUA and that was pretty nasty as well. A lot of my programs had errors (and there was no Run As context ability either). If and when I do upgrade to a newer PC and OS, that’ll be a different story. In the end, I re-installed CIS 3.14 and went back to my previous setup, which was more secure than Admin + SRP alone.
PS: The slow downs were actually miniscule and even then, I doubt a regular user would ever notice a difference with / without Defense+. Being a tweaker, I can catch little things ;). It may be old, but it can boot up in less than 30 seconds all the time, which is many times faster than my dual core work PC :).
LUA + SRP is ideal if security is your goal. Even on a Windows 2000 machine missing several critical patches, with LUA + SRP configured correctly you can test malware on malwaredomainlist or mbam forums until you are blue in the face and still not be able to infect the machine. If your the type who tests malware from malwaredomainlist against an Antivirus product and posts the videos on youtube you will be very bored with any tests involving LUA + SRP because nothing happens. Go and test for yourselves.
This method uses 0 resources and I tighten it up further by preventing any sort of high risk dl’s from taking place also by going to [HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
“1806”=dword:00000003
By making this reg key set to 3, high risk dl’s are instantly canceled before they can occur. Again, a simple way to harden windows that makes it very hard to infect a machine when you can’t dl sort of file which imposes a risk and doesn’t rely on a 3rd party program at all.
goodnight ladies
Very well said! And thanks for the idea about denying high risk dl’s. That sounds like a very good idea in some scenarios, and as you said, doesn’t require third party security software.
By the way, care to share how you have set up your SRP in detail? Thanks.
Yes, it was about 7 months ago when I decided to start off cleanly and use LUA + SRP. Since then, everything has been very smooth going, fast, and currently flawless.
Follow mechbgons guide #16 for the SRP settings mechBgon's guide for first-time PC builders... Best practices for ongoing security
HOWEVER, create a new account in any Windows version as a limited user account. MORE SPECIFICALLY, DO NOT CREATE A NEW ACCOUNT THAT IS AN ADMIN ACCOUNT THEN TURN IT INTO A LIMITED USER ACCOUNT AND EXPECT IT TO PERFORM AS A LIMITED ACCOUNT CORRECTLY. Keep in mind a limited account does not have write permissions to C:/Windows or C:/Program Files. If you create a new account as an admin and then turn it into a LUA it can still write about about half the folders in those directors. If you simply create a new Limited User Account, it will not have write permissions to C:Windows or C:/Program files, which are the only locations a file can execute with the SRP. Therefore nothing you DL can execute. You can test an accounts write permissions with the tool ‘ACCESSENUM’ found here - AccessEnum - Sysinternals | Microsoft Learn. If you create a new account as a limited account and apply mechbgons SRP rules as linked above, like I said even a Windows 2000 pc behind a router will be immune against all the malewaredomainlist and mbam forum stuff you guys can throw at it, regardless of what firewall/av/antimalware apps you have running.
Yes, I was just wondering if there was anything you have added to your SRP apart from the usual stuff. For example, are there any specific executables in C:\Windows or C:\Windows\system32 that you have blocked? I have put in several myself, including cmd.exe, command.com, regedit.exe etc etc. Fact is, 99.99% of users don’t need to regularly run the command prompt, nor edit their registry etc. In fact, they will probably never use it at all.
EDIT: oh and yes, accessenum is very useful, although there will be several areas of C:\Windows that appear to allow the user to write to. However, the user won’t be able to execute new files from these folders, as far as I know.
Endymion was asking me how I setup Sandboxie. Well, here’s how…and much more:
Perhaps you could consider to post a full sbie configuration meant for (eg.) Firefox :-TU