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

Sully,

Everybody agrees to say the security level o SRP will never be enough as long as the checking will be done from userland instead of from kernel. This said, the very same security level is sufficient as long as there is no proven large scale exploiting malware.

Concerning GUID, I said that the GUID for " by default" SRP rules remains constant through the different windows versions. I nevertheless guess that you can safely create a GUID on your own and use it. As an extra safety measure, you can compare it with the already existing GUID in a given registry, to ensure you will not get the same value twice. BTW, the probability to meet such a situation is definitely on your side.

Remember as well that SRP is a prevention tool. It means it doesn't necessarily have to check for service, as the service needs to be installed in the first place... Same goes with drivers (and LUA prevents this as well as raw disk access).

Concerning access to cmd.exe, can't it simply be denied to users from admin account (as regedit, registry...)?

 

Yes, GUID generators, do they not generate based upon machine? As to say, they themselves check and create unique value? But I ask, if you have tried, if you replace GUID for one of the default rules, does it have to be the same? Or do you do that because that is how it is across differing version? I ask because, if you found that it had to be the same guid or it would not work, that would see m to indicate that the guid is either somehow tied to those particular rules (i know them), or they are stored in gp database and therefore some errors occured if not removed using snap-in. Curiousity.

You are correct in a LUA invronment absolute. Many things like services and the like will be dependent upon the user rights assignments. They should block most things that could happen to, for instance, install a rogue service. Same for drivers etc. But for sake of theory, if using somethign like SuRun,which you allow for instace maybe a program to run as admin because you use often, perhaps you are tired of prompt for admin password, so you have SuRun remember. Now, it is to suppose that it is not difficult for exploit to try the same program that is now run as admin by default because of SuRun. Now if exploit exists, you have been no better off than running admin, because exploitable program can always start as admin, and create a hole for nasty to use into root.

This is of course theory, but I am examining hopefully all sides of the coin to better understand what possible weaknesses can be exposed. As for cmd, it is maybe hard for advanced users live in LUA without access to it. For me it would be. Yes then, as you say, prohibit it for user, which means no way for this environment variable exploit to occur. But again like with SuRun instance, or that user does want to start cmd even as admin or not, I don't know if this exploit is plausible. Testing must ensue, to which I will and no doubt spend too much time doing so . It will remain yet to be seen if there is a method to restrict that exploit. I find it curious that the acl should be seen as even mentioned my MS that it might be exploitable, as MS is heavy in use of SRP in mainly domain environment, where mostly only users exist, which should as you indicate protect registry areas from modification. I will test and see if those areas should be locked from user to change.

Very interesting.

Sul.

 

Another thing important to keep in mind for a basic user account: decrease the attack surface, especially where the user is not supposed to go...

So, to lower some of the potential weaknesses of SRP, I decided to forbid the access to some "dangerous" (I should say powerful) programs available in a computer:
Cscript
Wscript
To get rid of scripts

regedit
regedt32
to refuse access to registry (are there any ways to access it. I guess so. But I don't know how. Anyone gives help?)

cmd.exe
command.com
to refuse access to the shell or command line (any other way to access it?)

format.com
for obvious reasons...

So far I got no problems whatsoever running under basic user account with this config.

Now come the strategy to reach it. 2 possibilities:
- through srp policy: easy, but maybe not so strong
- through NTFS ACL, I guess very strong, more time consumming. (you specifically deny full control over the specified files to your user account) - this is the option I took first.

What do you think is the best option?

 

Does your extention list deny those by default? If so, is this redundant?

Your registry permissions should already be set for user. Meaning most keys that would have effect to system other than startup ones should be locked. HKCU is mostly allowed, but not all.

I wonder, since you run in LUA, and everything starts as a user, just how much of this is needed? Are you imagining that something somehow gets root privelage, and then starts these? Are you denying these only for users? What is the security flaw? If user starts regedit, it is restricted. If you restrict user from starting regedit (not a bad idea), is it really any more secure?

I don't know the factual answer to those questions. I only know that the user by default is restricted, and propagates those same restrictions to child processes.

Good stuff to learn about for sure.

Sul.

 

Hi sully,

I was thinking of a very twisted and unlikely scenario in which an Excel file embedding a dll could possibly circumvent the srp. At this stage, it would use the shell, a script... to damage the computer.

Well...

As I thought about solutions to reduce the attack surface, I just proposed myself not to rely entirely on srp and that using NTFS file access rights could be a way to supply any possible srp lack.

 

Hey Lucy, I see you blocked : Cscript.exe and Wscript.exe. On my XP machine I also blocked vbscript.dll. This way NO macros/vb scripts run at all under my LUA with SRP enabled.

When I mean no, I really mean no. VB scripts don't even run in my browser/excel/word/etc.. with vbscript.dll disabled by SRP. With only Cscript and Wscript disabled vb scripts were able to run inside my browser/office apps.

You can test it if you want (disabling only Csscript and Wscript. And then disabling vbscript.dll). I found this test online (I didn't write it and it's not a virus or malware so it's safe to post on the forums) :

Make sure you don't have sandboxie or geswall sandboxing your browser because they can block the read access, we're testing SRP

With only Cscript and Wscript disabled by SRP this thing runs fine, but with vbscript.dll disabled by SRP it can't do anything. I've never run into a problem with disabling vbscript.dll in my LUA.

I also experimented with disabling scrrun.dll. But this makes the LUA unsuitable for my needs. With scrrun.dll disabled NO scripts : java, vbs, etc.. run anywhere. Open up your browser and all scripts are disabled, it's like a permanent noscript. So I removed the scrrun.dll disable rule.

 

Really great feedback zopzop.

Unfortunately, I make heavy use of VB in MS Access for my job. And I'm afraid this time, blocking vbscript.dll will be unsuitable for my needs.

So you forbid it with srp... Fair enough. I still don't know wether ACL is safer than srp for exception rules like this one...

 

Hmm. Yes, I undestand. However, this still leaves me to ask the same question.

If you are a user (LUA), and you do not make an exception for excel, and you start excel, how can anything escape the user's rights to promote itself to admin? Now, the environment weakness I mentioned, where a path or env variable could be changed would possibly be a case, but how else?

I am just thinking, and not able to see how it would happen. Not that it would not.

ACL, again, how would running as user (LUA) be any different? As the ACL is read/execute for those two files which reside in windows directory or subdirecotry, they can be run, but the calling process would have to have root to do anything different that what a user can do.

@zopzop, that is a neat trick. I will remember that one and play with in the future.

Sul.

 

Sorry to propose an answer so late,

But as you already know, malwares are often able to run in userland, and therefore do not rely on root access as you call it. Of course no damage will be done to the system.

But some damages can be done from user space as deleting user files (images, movies...) or encrypting it for ransom. And it is (highly? sorry just a wild guess from me) possible that this given malware will use one the following programs to perform his actions: format, C and Wscript, command, cmd, regedit... Of course some others could be used. And one can easily imagine, it can carry its own engine to perform the same tasks...

Anyway, one could even ask himself why and how come, windows gives access to registry, format.com... to a simple user. This should simply be denied by default. And I can tell that for 99.9% of the people, this would have strictly no consequence on windows usability.

To finish on this subject, more and more is developped the idea of risk mitigation. Security doesn't rely on one big perfect tool closing all holes at once, but on a collection of little actions whih, gathered together, may significantly leverage security. Sorry, I am not enough knowledgeable to answer wether or not my propositions are part of this or not, but I do know it has no consequence on my windows experience, and therefore can be done safely.

At the end this may look like a simple sanitary measure!
BTW, somebody has a list of other windows programs which should never be used under user account?

 

This reminds me of this post by Didier Stevens:

 

The instructions mentioned here could also be used for XP, correct? I checked my registry, and it seems the situation is the same for XP.

A quick summary: Key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths is for items that are to be run with 'Disallowed' security level. Key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\131072\Paths is for items that are to be run with 'Basic User' security level. Key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144 is for items that are to be run with 'Unrestricted' security level. I believe the second item was not mentioned in this thread before.

 

Correct, but Tlu did it there already:
https://www.wilderssecurity.com/showthread.php?t=200772

Yes, because I am running under basic user account, so it is useless, but Sully uses it extensively under admin account.

Hey mate, where do you think I got my information?

 

I believe that if the shellcode at http://blog.didierstevens.com/2008/10/23/excel-exercises-in-style/ were changed to use the local privilege vulnerability mentioned here, you would own the system.

 

Thanks Lucy, I had read that thread already, but it relies upon a .exe from a German magazine correct? I am not sure if it's legal or not, and some may not wish to run a .exe from there.

Thank you also for starting this thread .

 

wow, this would create a powerful specially crafted exploit...
that I will probably never see.

One of the real advantages of SRP is that it is very little used. It is called security through diversity, isn't it?. And it is a fact that people using it are necessarily knowledgeable users /admins on windows PRO machines, with group policy..., so they are far from being the primarily target of malwares.

 

Yes exactly, security through obscurity. If SRP became used more often, it would also become less secure, on average, because people would spend more time trying to circumvent it.

 

Have a look at the end of the thread, I believe tlu uplaoaded a special version of the reg file for XP, and he confirms that you don't need any of the programs listed at the beginning (the one from the german magazine or even the dlls from windows cd). You just need few reg keys

Well, I was just a bit curious, and very lucky. Happy if it can be of any help.

 

Thank you . Found it. Post #134.

 

Has anyone tried SetSAFER under Vista? Can be found at http://blogs.msdn.com/michael_howard/archive/2006/05/07/592136.aspx. Sully mentioned it earlier in this thread, but the first search result from Google has an older version.

 

You mean setsafer the xml script tool? The one that makes your srp (safer) rules? I have been scrounging on MS but they took away so many parts of those types of posts. I have the program I think, but have not tried it yet. Tell me, if you have used it, does it write any SRP policies to the GroupPolicy, or just to the registry?

As far as the whole bit with that exploit in the posts above, I have examined it and also seen others opinions. I would say it is the least of my concerns when running SRP. If I ever get hit by something like that, I will really have to think about where I have been and what I have been doing. Then I would really have to rethink my security. But I don't see it happening. The smacktards of the haxer/craxer world IMO are going to target the easy marks, not the hard case technogeeks.

If you are referring to the German exe, actually if it is used to put GP on xp home? If this is the case, and you are putting GP on xp home, be on the lookout for one thing. When I did it, I was able to start gpedit.msc and make SRP rules. But, they did not really work. Only when I was examining the registry did I notice the regvals did not exist. So even though the Group Policy database was showing the polices made in SRP as present, I had to delete them and manually put in the same things in with .reg files. Just something to look for.

I have been stripping apart some of those german files, the batch ones, to gain some more info. Might give some good ideas.

Sul.

EDIT: That is to say, I do have the first version, I think I have the second version somewhere. The first version I don't much care for. The second I have not tried. You say you are looking for version 2? I will look and see if I can locate it.

 

The original articles for 'Browsing the Web and Reading E-mail Safely as an Administrator' Parts 1 and 2 can be found at http://web.archive.org/web/20070301182208rn_2/msdn2.microsoft.com/en-us/library/ms972827.aspx and http://web.archive.org/web/20070223192725rn_2/msdn2.microsoft.com/en-us/library/ms972802.aspx. SetSAFER is mentioned in Part 2.

I have not tried SetSAFER (yet), since I have GPEdit.

 

Thanks, but no need, because I believe the latest version is found at http://blogs.msdn.com/michael_howard/archive/2006/05/07/592136.aspx. I was just asking because maybe it's easier to use SetSAFER?

 

SetSAFER works, but is not the best option. If you can hang tight for awhile, something else is in the works.

Sul.

 

I think the DMR approach is not the right one. First of all, there is at least one other process (namely explorer.exe) permanently running with admin rights which is an easy target for malware using Windows messaging. An interesting read is http://blogs.securiteam.com/index.php/archives/188 .

Secondly, even if you started, say, IE with limited rights there is always the danger that another instance of the browser is started indirectly by a casual click e.g. through local URL- and HTML-files and hyperlinks in Office and mail applications (DOC, XLS) or help files (CHM). These instances run with admin rights ! - and you probably wouldn't notice.

 

I have tested this with both DMR and SRP. I understand and would generally agree, however, this fails completely on my system. My default share c$ has been removed by me long ago. Using the trick of \\127.0.0.1\anything at all does nothing. It is not a recognizable address.

With DMR I could see the point of it. You start IE with user rights, and then accidentily start IE again but as admin.

However when using the Basic User level in SRP, IE is forced to start as a user, everytime, all the time. True it could be copied and renamed, so a path rule would not work. But that is why there are hash rules I suppose.

I would be interested to find some more ways to test this sort of 'flaw' in SRP, with other programs, and see if you really can escape your demoted self to run again as your normal self, that being admin.

Very good read for sure.

Sul.