Admin password - uac, lua, applocker.

Does having the admin account, setup during a Windows 7 install, passworded affect the usefulness of using Applocker (default rules) in a standard user account with UAC enabled to help thwart malware? - Is there the possibilty of malware to give itself admin rights in an lua in such a way that having a password set up for the admin account would prevent it?

 

I don't know why you'd want to use UAC from a user account. UAC is just a way to convince more people (specifically developers) to use LUA's and is not meant to be a security boundary.

Since the idea is to run from the LUA (and not the admin account) then malware wont be able to give itself admin access since it wont have access to the admin account in the first place. Moreover, the entire purpose of AppLocker is to stop anything not specifically listed in its whitelist from executing.

Now there are such things as privilege escalation vulns, which are exploits that allow an attacker to elevate from LUA to admin, but those are rare and Applocker should prevent them from executing at all. Keep in mind, nothing is 100% (it's possible in theory to bypass Applocker with the right kernel exploit, but it would take a perfect storm of sorts to pull it off. If an attacker gets "ring 0" he can do anything, including bypassing access controls).

 

UAC enforces Internet Explorer Protected Mode, which will make IE run with a WIL (Windows Integrity Level) of Low, which will restrict what IE can actually do in the system. So, IE running with a WIL of Low won't be able to access anything with a WIL of Medium or High.

Otherwise, it would run with a WIL of Medium, which would allow any malware exploiting an IE vulnerability to have the same WIL, allowing it to read objects with a WIL of Low and Medium. This would be dangerous if any sensitive information is placed on the system.

I'm just referring to WILs here. Just to explain why UAC becomes also important. UAC isn't just some stupid thing. It's not meant to provide the full security we all what (What does, actually?), but it sure helps a lot.

 

There is also UAC Virtualization which makes some apps work correctly under LUA that wouldn't work otherwise.

 

Yes, indeed.

I'm still to understand why so many people freak out with UAC and how come they see so many alerts. I wonder what the heck they do in their systems.

I'm not saying anyone mentioned it in here, because no one has, but it is a reality.

I only see alerts (since Vista) when I install some application, which, truly requires Administrator privilege. Most of times, if possible, I just extract what is need from an application from the installer and place it under Program Files. Easy and not installed with any Administrator privileges. Easier than this is impossible.

It would be great, though, that Microsoft would make UAC detect what truly an application needs, rather than just treating every executable has needing Administrator rights to be installed. Why not one secondary Administrator account (with LUA-like rights), I wonder, and let the user decide which or advice, at least, which one to use, and still let us decide which one to use.

Minor glitches. But, overall, UAC was long needed, in my most honest opinion. It has to evolve, that's it.

 

I'll add another thing UAC does to those already provided by m00nbl00d and Sadeghi85: UAC prevents most forms of tampering by lower integrity processes of high integrity processes running in the same desktop.

I made a list of some consequences of disabling UAC at http://www.sevenforums.com/system-security/92159-bad-turn-off-user-account-control-7.html#post800206.

 

MrBrian, you summed it up nicely at that forum. UAC doesn't get the credit it deserves, just because some security experts, including MS Technical fellow Mark Russinovich, state it's not a security boundary. In fact, it does offer a measure of security, as pointed out by those above in this thread. It puzzles me to this day that it's been downplayed so much by those in the security industry.

 

Are you sure one must be in an admin account to take advantage of the Windows MIC? You can have UAC enabled in a user account if need be. In any case, if Microsoft made it so one must use UAC to utilize the MIC levels, then they made a bad design decision.

 

It works in a standard account also.

 

Ok. Then do you have to have UAC enabled to take advantage of MIC even when in a LUA? If so, that is silly imo.

 

Yes it does. As an example, disable UAC and then go into a standard account. Open Internet Explorer. Notice that Protected Mode, which uses integrity levels, will be off.

 

Lets pose a simple scenario and find out from you guys what your take is on it.

Assume that a user installs windows 7/vista, and begins to use it, everything at default. Suppose that they use IE and do the typical things that an average user will do: check email, watch videos, listen to music and of course download programs and files from the internet to thier machine.

Now lets suppose that they execute a file they have downloaded, or they are on a website and something is executed, whether they have triggered it or it is scripted etc.

When the user sees the UAC prompt, because the process wishing to start requires admin rights, how will UAC have any further protection for the user if the executable is malicious in nature?

Now also apply to that a 3rd party browser such as Firefox.

I have read a lot of the infos on UAC, and for the most part understand what it can do, but I see it failing all the same when the user simply clicks OK. But I am curious to know in what sequnces or circumstances might exist where the choise of OK to UAC is not enough to take it out of the equation.

Lets not get into a dispute over whether UAC is good or not, blah blah. Just some sharing of facts on how it plays a role after the user has seen it and answered "let the program do its thing".

Sul.

 

The security it can provide, the way I see it, is it triggers on something the user doesn't expect, with an alert that will indicate the application is either:

1. signed by Windows,
2. signed by another known Publisher,
3. or not signed at all...

the latter of which should arouse suspicion. Unfortunately, I doubt most people understand or even notice the three possible (actually four possible, but the "Blocked" is unlikely to occur) color-coded alerts that will be generated. Obviously for any application willlingly downloaded and intended to be installed, UAC is probably not going to help much, if at all, unless the user understand the UAC alerts and thinks twice upon seing an unverified publisher alert.

The other security benefit it provides is for those who stubbornly refuse to work in a standard account, because UAC at least places a standard token on explorer.exe, so that applications like the web browser inherit the limited privileges the token imposes in the administrator account.

 

Let's suppose that while using your standard account, you get a Microsoft Excel spreadsheet from a friend that contains a macro. Perhaps you open the spreadsheet, because you trust your friend. However, unbeknownst to you, it was actually malware on your friend's computer that sent the spreadsheet, and the macro is malicious. AppLocker won't stop the macro from running. Suppose the macro attempts to elevate, and guesses your admin password correctly. Even in this scenario, as far as I know, you'll still get a UAC prompt that you will have to OK in order for elevation to proceed.

 

What do you folks think of this proposed change to UAC? In a UAC prompt, an extensive Microsoft-maintained hash whitelist and blacklist is consulted and the results are presented to the user. Furthermore, there is an option to automatically elevate if an executable is on the hash whitelist.

 

That is how I see it as well. A tool of use, but if you just click OK blindly, not much use really. I have been helping people fix issues because they simply elevate when needed and don't understand why they still have problems with these "more secure" versions of windows.

Sul.

 

I have thought about this before. Not sure if it is overkill or not. Someone around here (or many) stated that you can't expect UAC to actually know about everything in order to give you a choise option. I agree. White/black lists could narrow that down to perhaps a form that would be manageable. I suppose the down side of this sort of thing is that it starts to lean towards HIPS type logic, where you get to see ever more prompts.

I just don't see UAC in the same way as a lot of people do. I see it of more use to advanced users than novice uses. I don't think novice users have the skill to understand it, where advanced users might be more annoyed by it, but would surely pay attention to it. This idea of black/white lists in union with UAC would be even better for advanced users, and IMO even worse for novice users.

I don't pretend to have all the answers or be absolute in any of this. I simply have a lot of questions on UAC and how the best method of implementation would be for the differing types of users skill levels.

Sul.

 

Sully, all you say is correct, but then I can say the all about AppLocker, SRP, LUA, etc. Everything.

Once the user trusts the Installer, well... it is trusting the installer.

But, now imagine this:

A user using Protected Mode IE. This makes IE run with a WIL (Windows Integrity Level) of Low. Besides restricting what can actually happen in the system, it will also, in the possibility of an exploit due to browser vulnerability, make this other malicious process run with the same WIL. (At least, this what I understand it happens. Unless I'm missing something.)

Windows Integrity Levels main job is not to secure users, rather to prevent objects with a WIL of Low to mess with objects with a WIL of Medium and High.

Still, by design, it will only prevent writing to objects with Medium and High ILs. It won't prevent Read. That means that an object with a WIL of Low will read objects with Medium and High ILs.
One way to prevent this is to set what you consider containing sensitive information, besides setting it with a High IL, to prevent Read. Unfortunately, icacls by Microsoft does not allow it; it is very limited in what it does. But, I've found a tool that does just that (http://www.minasi.com/apps/) named chml.

By doing what I mentioned, even in the possibility of infection, it won't be possible for any other object to read other object with a NoReadUp (NR) applied. You may even apply NoExecuteUp (NX).

I've set my Chromium executable (chrome.exe) to a Low IL, after applying all different settings I wanted for my different profiles. Afterwards, no way to tamper with it. It won't even allow to mess with the profiles.

Microsoft could do things a lot easier, as I mentioned above. But, we have what we have, and we go to take the most out of it.

By the way, there's no need to install every application with Administrator rights. Just because UAC intercepts an installer, that doesn't mean that UAC itself is the culprit. UAC reads the executable and if the manifest file requests Administrator privileges, then it will elevate it. Blame the programmers.
One example is 7-zip. Why would it need for Administrator rights to be installed? Crazy? A way around? Unpack the application and place under %ProgramFiles%. Done deal. Works fine. You can do the same to many other applications.
From all existing applications, I'd say only a small % actually needs and requires Administrator approval.
Perhaps, it's time we all blame the software developers. It seems that UAC hasn't made them change their minds at all. At least for the most of them, IMHO.

 

The blacklist would, I feel, make it too much like antivirus behaviour. I like the whitelist idea, though, because it should be far easier to keep up to date as oppposed to a blackilist, and instead of hash values, I’d rather see, like AppLocker can use, Publisher signatures preffered, then hash values if necessary. Hash values change whenever an application with one is updated, requiring the hash rule to be updated as well. With a Publisher rule it’s nice because you can have a rule that states, for example: File version 1.0.0.1 or greater, Product name, file name, and signed by Techsmith.. This is the way (there are other possibilities too) it can be set up in AppLocker Publisher rules.

 

As stated by M$

If I am understanding this correctly then, the IL of Low would already reduce the rights of the process started (the subject) would not have access to files of the user that were deemed to have a higher IL (the object). I am unclear of whether applies also to address space (memory area) only or also to actual objects/containers (files and directories).

It seems that the OS creates the MLACE (mandatory label access) to relatively few containers/objects, leaving the real rights in the hands of the DAC (discrestionary access control).

The IL of Medium or greater had no reference I could see that would prohibit the reading of higher IL objects. As the OS supplies few object mandatory label access control entries, I am unsure what this means. Does it mean that since only few objects will have a mandatory label by the OS, all is residing on the DAC? Or the lack of a MLACE implies that there are no restrictions unless specifically stated?

I think, but not sure yet, that the inheritance settings of the IL that can be modified by icacls is the answer. If I read it correctly, setting the proper inheritance on the IL can either allow read or deny read, depending on the parent and other hierarchies.

It is all quite muddy, especially considering there is no UI yet (as of vista) that allows you to mess with the MLACE at all. I have been looking at the SDDL a little bit, but there is soooo much going on here that is just a little different from XP. But there is good news, there is plenty of references to APIs to use with this stuff if one can only grasp it. I have a feeling that tweaking this IL mechanism is the answer to a lot of little things that could be interesting to an admin.

I am not sure I follow your logic here. You must be wording it differently. You have to have admin rights (or power user etc) to modify in the Program Files directory. No way around it. Are you saying that you don't need UAC if you are manually copy/pasting it to Program Files? You certainly are not doing this from a standard user account, unless you have modified the rights of that user. Program Files container carries a GRGX for the BU, meaning you must be admin (or PU,SU etc) to modify things there.

We can blame software developers for housing information in Program directory, instead of %userprofile% directory. Data used with the program would then be stored in the proper location, making users unaware that the actual binaries and dependencies live in a restricted directory. But how would you design a program correctly that does not live in program files? For sake of security in a LUA environment, the best place for the binaries is an off-limits area to a user. Maybe you are confusing some other aspect with this or have mixed up how you said it? Or maybe I didn't read it quite right too

Nice post, always enjoy reading others SDDL/ACE/DACL/SID/RID type stuff.

Sul.

EDIT: I think I am get this IL of medium now. The option of a program to share its memory space is used a lot in windows so that other programs can access what one program has in memory. Think copy/paste and clipboard. The IL of low has the ability to severely limit usage because it gives the process no rights to access IL of med or highers address spaces. The default of medium (such as explorer.exe is supposed to use) denies the process from modifying etc higher level IL processes, but does give it access to read, so that it can copy/paste etc. IE is supposed to be in IL low in 'protected mode', so it cannot get to the address space of higher levels. Also I read that there are directories in the %userprofile% that are created to allow a process such as IE with IL of low to be able to access. I haven't seen which directories these might be, but haven't looked yet either. It will be interesting to see what directories are given this status, as one could possibly utilize those or create your own with this low level. Then you might play with different ILs for different processes and use those directories to some advantage.

You know, just more random and clearly "out of the box" things to look at... just the way I like it

 

I guess I didn't explain my self enough. Sorry.

Taking the example I gave, 7-zip. To install it, you don't actually need Administrator rights, since it won't require access to the most important parts of the system, so to speak. Of course, it will require access to be able to install under %ProgramFiles%.

But, imagine that I would install 7-zip by elevating the installer. It would install itself to HKLM\Software. So, it would install to %SYSTEMDRIVE%\Program Files\ directory and to the HKLM\Software.

By just copying & pasting the extracted application from the installer, then it will only load for the current user (HKCU\Software).

So, basically, I'm giving Administrator rights so that the application can place itself at %SYSTEMDRIVE%\Program Files, but without actually giving full privileges. It would be like I was giving rights to install with a more restricted Administrator account, I guess.

Not an elegant way, sure, but it works for me.

As I mentioned, it would be great for Microsoft to have two distinct Administrator accounts: one which we would choose to install applications like, for example, antiviruses, which need to load drivers, etc. And one other for stuff like installing 7-zip, which does not require full Administrator rights to be installed.

It may sound confusing... But, at this hour of the night, I can't think quite clear.

I'm using that approach with Chromium browser.

By design every object running with the least-privileged rights will run at a Medium IL. It is possible to modify this by making use of icacls, and make "chrome.exe" become a Low IL object. Also the same for Chromium's different profiles that I have.

No other objects are allowed to write to it.

For example, you could also harden some folder you consider containing sensitive information.
In this case, you'd want to turn this sensitive folder, say C:\sensitiveinfo, into a High IL object and deny Write, Read and Execution.
If, say, an infection would occur, those objects with a, in this case, IL of Low, wouldn't be able to even Read.

By the way, to make this sensitive folder have NoReadUp and NoExecuteUp, you need to use the tool I mentioned above, chml, because icacls doesn't have those options. It is something done by design, which only has NoWriteUp (NW).

 

Ok, you are saying that the installer for the program 7zip will extract the program to %ProgramFiles% and create registry entries in HKLM. It needs admin rights to do these things, and a properly coded installer today needs to have the AdminRequired manifest to work properly.

Ok, here you are treating the program 7zip as a stand-alone application, which has no dependencies that need to be installed. Simply put, you can place it anywhere, and it will run. You further state that only the HKCU registry values will be needed or created.

Here you are stating that because 7zip can be placed anywhere and will run, and that it only writes to HKCU when doing this, the only admin rights you might need is to place the 7zip directory in the %ProgramFiles% directory. Because the installer was not used, and elevated to admin rights, you keep the whole context of ownership and registry to the User profile, not the admin.

It sounds like what you are doing is circumventing the installer, and manually placing the objects to %programfiles% yourself. When you extract the 7zip installer and you end up with the program data, it is created with what account? The admin account or a real User group account (a LUA account)? If you create it with the Admin account (on which UAC is on), the owner is still the same user no matter what rights he is restricted to with UAC?

Further, if you create the program data for 7zip (be extracting) with the User who is admin when elevated, and you move/copy the program data to %programfiles% and the HKCU entries are created, isn't the same User then elevated to admin to move them? And this same user is also the HKCU SID?
So IF all of this is true, regardless of if the User, who is admin, but reduced with UAC, still the owner of it all anyway? So when you are restricted admin, and you do something to any of these objects, the fact that you are the owner, even though reduced, has what bearing to you?

It is not confusing, but what might be confusing is just how the ownership comes into play when you are admin utilizing UAC. You have taken steps to circumvent creating HKLM entries, but you have created HKCU entries, of which the User (you) are the owner. If the user (you) use UAC and are restricted, don't you still have ownership, the same way as when the user (you) is elevated with UAC to full admin rights, are still the owner.

Until now I had not thought much about how the psuedo-admin account that you are given would handle such a situation. Does the UAC mechanism segregate ownership differently when it is technically the same account? Are there flags set that disallow the reduced admin processes from accessing the full admin processes based on whether the object/container were made in one or the other context?

I know, sort of hard to follow, but the admin account that is locked down with UAC to less-than-admin is still the same user, and I wonder what is happening.

On a side note the SDDL now has a flag of ML in the ACE for Mandatory Label. The inheritance of both the object/container as well as the usage of it in regards to the IL have some bearing, I just haven't figured out exactly how it plays yet.

Sul.