A thought regarding drive-by downloads

Thanks you. I am talking on default fresh Windows XP install. But I understand you.

But there are other folder with write access for LUA. Example is C:\Windows\Debug\UserMode.

I now find out that default fresh Windows XP install has safe policy. Mean that no need to add more rules in SRP. Happy?

 

Write access is not the problem, as far as being able to get around SRP is concerned - having both Write and Execute is (and also having Change Permissions or Take Ownership, since if you've got that, you can just give yourself Execute permission even if you don't have it by default).

Depending on how secure you want to go and how much trouble you want to go through, you can either be happy with the default SRP rules (which on XP do leave holes like the Windows\Temp folder) or you can check your file system for any folders that allow both Write and Execute (or Change Permissions) and are also allowed in SRP and then create Disallowed rules for those in SRP.

 

OK understand.

Only other folder by default is C:\Windows\system32\spool\PRINTERS. You should more be specific to let other learn. And I still dont understand how limited user can write to C:\Windows\system32\spool\PRINTERS and C:\Windows\Temp if can't read. Ok?

 

Sorry i write again.

Windchild smart man. I PM him and he tell me this:

So that how to bypass SRP. Thanks him!

But then I tell him to block cmd.exe with SRP...limited user should not use this any way? And question now is how else can bypass SRP to write and execute C:\Windows\temp? If no way, then why block folder. More safer to block cmd.exe any way? And if block this, no point add extra rule?

 

It's difficult to be very specific because it all depends on the system: most systems will come with the default permissions from MS, some will have permissions modified by the computer manufacturer, some have been modified by installed software, some by users. So, the best way to do this is just using one of the many methods available to check your permissions, so you'll know for sure how things are in your system - not in some other guy's system that might be very different from yours with regard to permissions. It's better to see for yourself than to trust someone else saying "this is how it should be." Tools like AccessChk and AccessEnum make this easy to do.

Limited users can write to Windows\Temp because while they do not have permission to list the contents of the folder and read all files inside the folder, they have permission to create new files and since that makes them owners of these files, they can then execute the files. You can see this for yourself by checking the permissions using the Security tab for example. Due to everyone - including limited users - having the Bypass traverse checking privilege, Windows only checks the permissions of the actual file you're trying to access, and does not check the permissions of any parent folders. This makes it possible to run into a situation where you have a folder that you cannot open in Windows Explorer and can't read (like Windows\Temp), but can still create and execute files inside that folder. Understanding file permissions may take a little getting used to - they can be fairly complicated.

Blocking cmd.exe isn't necessarily a good idea, and it certainly won't stop limited users from being able to write and execute stuff in Windows\Temp. Some people use the command prompt for useful things, so blocking it would be a no-no, unless you're sure you won't use it. I use the command prompt all the time as a limited user - often it's much faster to type commands than navigate through a million windows. But, I digress. The Bypass traverse checking privilege applies to your account, and therefore everything you're running, not just cmd.exe. So if your browser - that you must allow in SRP or you can't use it at all - happens to want to download some file to Windows\Temp\malware.exe and then execute it because a piece of code exploiting a vulnerability in the browser told it to do so, your browser has permissions to do this, and it won't matter whether cmd.exe is allowed in SRP or even deleted from the entire system. So, if you want to prevent stuff from executing from Windows\Temp, you'll need to create an SRP rule to block it (or you could change the actual file permissions for Windows\Temp, but unless you really know what you're doing, that's a very bad idea).

 

I was say describe it with default Windows XP install only. That is good information to pass on. What you say also good.

I dont know any one who uses cmd.exe. I don't use. But for you, you use, and that is OK. I just worry cmd.exe can be use for malware to cause harm.

Thanks you for explanation. You are talking on browser vulnerable with exploit. Is such exist ever? Also how can browser download file to folder it can't read? Not possible I think? Remember SRP apply to browser...and no code can execute under SRP. So how can code execute exploit and allow writing to C:\Windows\temp when it can't access?

No harm create SRP rule to block those 2 folders any way. And if don't use cmd.exe, block cmd.exe make system even better secure.

 

Tons of browser vulnerabilities around, and new ones are discovered as old ones are fixed. The vulnerability also does not have to be in a browser - it was just an example. Any software used to open untrusted content will do - office software, email clients, browser plugins, multimedia players and so on.

Easily, just like your cmd.exe can copy files to a folder it can't read. The browser does not need to read the folder (in other words, list the contents of the folder) at all. If the user account the browser is running in has permission to create new files in that folder, the browser can download files in there all day long, even if the user has no read permission to the folder itself. As I explained above, this is because of how Windows checks for permissions: it checks only permissions for the specific file you're trying to access, not parent folders, because it's the fastest way to do permission checks.

That's the thing. Lots of code can execute under SRP, or you wouldn't be able to do anything much with the computer. Your browser surely can execute, and if there's a vulnerability in the browser, and it is exploited by an infected web site you visited, the malicious exploit code runs inside the browser and will not be blocked by SRP. What happens when the malicious code runs depends on your system's configuration and what the malicious code was designed to do. Typically, it'll just try to download and execute some trojan downloader executable without specifying where to download it - in which case the malware ends up in places like the browser cache or the userprofile temporary folder, and SRP will then block it from executing since the "usual" SRP rules don't allow running programs from browser cache or user temp folders. However, if the malicious code tries to download the malware to some folder that is allowed by SRP and the file permissions allow writing and executing, then SRP will not help and the malware will execute. Things like that are reasons why we might not want many holes in our SRP rules that allow limited users to both write and execute files in paths that are allowed by SRP.

But, that's of course a simplification. SRP does not cover all methods of executing code, such as MS Office macros, and those have been used to demonstrate bypassing SRP in proof of concept attacks. Lots of discussion on this topic has been going on in this forum during the years. But really, even with the "default" SRP rules that allow Windows and Program Files folders and don't blacklist any folders like Windows\Temp, typical drive-by-downloads are blocked, so SRP is quite effective even without additional rules.

 

Sorry to harp on about Applocker, but this is why it's superior to SRP. You simply create the whitelist rules for the apps already on the system and everything else that even "thinks" about trying to execute - no matter from which directory - is default denied. it seems with SRP, correct me if I'm wrong, it's necessary to create a multitude of blacklist rules for all those temp and other directories that limited users can write to and/or execute files from.

BTW, good to see you you posting here, Windchild You always explain it best

**EDIT**

1. hopefully to at least partially mitigate some nervousness amongst those who're concerned about the cmd.exe file launching threat: I tried it again under XP, limited account w/SRP enabled, but this time with a Windows installer file and the results are seen in the nice picture
   
2. Yet a second time with SRP disabled.

 

Sorry you don't answer my question or I dont understand. I not clear on how I ask sorry. I ask on how the browser or office doc like you say, can access C:\Windows\temp? Remember it cant read. If you try manual yourself, you cant access it to write in it. This because of limited user restriction, not SRP. Maybe you say exploit can bypass limited user restriction? I dont understand how exploit in browser or office doc can write C:\Windows\temp when browser or office doc are running with limited user restriction...can't access C:\Windows\temp. Sorry if not clear. Maybe what you saying is exploit bypass limited user restriction. If say that then can say any thing like Applocker bypass by privilege escalation in limited user. but where proof.

Best to give example. All theory for now unless u give example of browser or doc or plugin or media play that bypass limited restriction and use same command as cmd.exe to access folder that cant read. And yes otherwise same thing say that SRP bypass with Excel macro. All theory only.

Maybe I ask like:

And you say easy. But I no understand how still. All you say is easy. Before you smart and tell how to do with cmd.exe, but I tell cmd.exe blocked. Now no tell? Also no tell on risk of run cmd.exe? I say no one I know use it and so it not need for me and us. So safer to block.

 

Why not? I have no problem using the mouse to copy/paste an executable into the C:\windows\temp folder. I don't even need to supply UAC credentials in Win 7 to do so. Remember, read and write are two different things.

My opinion, timestand, is don't get all worked up over this. The trouble is people are stating facts, and that is good, but the facts can obscure one's perception of how secure their system really is. They think that because something is in fact possible, they have some sort of gaping security breech in their system unless it gets expediently patched

Besides, I thought I'd already demonstrated just how harmless an installer type executable (as opposed to a single file/per user execuatble) is even with SRP disabled under a limited - very important! XP account.

 

No problem. File permissions can be complicated if you're not familiar with them. It takes some learning to understand how they work, but once there, it'll all start making a lot more sense. There's lots of excellent reading on the subject, and even the help files included in Windows are fairly good and can help explain how permissions work. It's a little difficult to explain it all quickly (well, at least for me it is, but I was never good at explaining stuff).

But, the issue here is that you need to understand the different sorts of permissions, and how they are used. Having read permission on a folder, like Windows\Temp, is one thing - all that means is you can read the contents of that folder, it gives you no other abilities and it's only needed if you want to view all the contents of the folder, otherwise it's useless. Having permission to create new files in the folder is a different thing - the Create Files (as well as Write) permissions allow you to create new files, even inside folders that you can't read. The important thing here is this: you don't need Read permission on the parent folder in order to create new files inside that folder, you only need the Create Files permission. You can check the folder properties of your Temp folder in Windows Explorer. Look under the Security tab and click Advanced, and Effective Permissions. Select your user account or the Users group and you'll see that the permissions for your Temp folder don't allow reading for limited users, but do allow creating new files. That's what causes all of this. If you don't see the Security tab, you're running a Home version of Windows - you could see the Security tab in Safe Mode, though.

There is absolutely no bypassing or exploit or flaw involved in limited users being able to write to Windows\Temp. This is exactly how Windows normally works, and should work and will continue to work - there's no patch coming out to change this (between releases of Windows like 2000 or XP or Vista the default permissions can and do change, however, as Microsoft sees fit). What you called "limited user restrictions" are just a certain set of privileges (privileges apply to user accounts and groups of user accounts, and let you do things like load drivers or change the system time) and permissions (permissions are attached to objects like files and folders and registry keys and tell you what various user groups and users have permission to do with that object) that Microsoft has seen fit to set up in the default Windows installation (others can later change privileges given and permissions set if they want to and have the admin credentials needed). There is no limited user restriction that says "you can't access Windows\Temp, period, you can't read and you can't write." There is only a set of permissions that don't allow you to read the contents of the Temp folder, but do allow you to create new files inside the folder and then execute the files you created. The proof of this is easily seen: you can view the permissions manually like I explained above, you already proved it by copying a file to the Temp folder and running it with the command prompt, and so on.

So, if you're running your browser as a limited user and meet a site that tries to exploit a vulnerability in the browser, the exploit code can just happily download and execute stuff in Windows\Temp, because the file permissions allow this by design. In Windows XP, that is.

See above. There's no bypassing, and you already saw the proof. This is not a theory, it's just how things are. Cmd.exe isn't special: it can create new files in Windows\Temp just like any program running as a limited user, including browsers. As for the Excel macro, it's not theory either, it was already done a long time ago, and has been discussed multiple times all over.

But really, there's no point in worrying about this stuff too much, like wat0114 said already. Practically nothing is foolproof and 100 % secure. As long as it's secure enough, that should be good. Besides, AppLocker fixes most flaws of SRP that I can think of.

 

For those who want to tighten up on anti-executable protection (with SRP, AppLocker, or whatever else), \windows\temp may not be the only folder/file where a limited user can write and execute. In Windows 7 x64, for example, the list of folders that a limited user can write and execute include those listed at https://www.wilderssecurity.com/showpost.php?p=1658981&postcount=31. As Windchild noted, your results may vary due to the installation of third party programs.

You should IMHO audit your system's permissions after every program installation, or batch of programs. Some tools for auditing permissions are Windows Permission Identifier and AccessChk. If you're using AccessChk, make sure you're using at least v5.00 on affected operating systems due to this bug. Also, be sure you're running AccessChk with a full admin token.

Those who are using Internet Explorer with Protected Mode on are further protected from drive-by malware due to the use of integrity levels.

 

I tell you before I understand file permission. But thanks you for your explain (again).

No, I understand but I still dont know how browser or media play or plugin can write and execute C:\Windows\temp? You show me how with cmd.exe with good explain. Now explain how with maybe Internet Explorer? Thanks you.

 

OK I forget to tell you one thing. If use Applocker auto-generate rule, then won't mean if you install new program or update program, you need to update your rule again? If so this is not good? It annoying OK?

 

From Windows 7 AppLocker Executive Overview:

 

That only on update program. What about install new program. Can be problem OK?

More easier to apply default rules and then block folder which allow write and execute.

 

Nope, the blacklist approach is definitely not easier.

 

Maybe you right. But seems need to add many rules in Applocker then. If many program can maybe cause slow down with many many rules.
Have you try Win 7 Applocker. I see you on XP still? Which folder you block then since no Applocker on XP.

Sorry I think on another problem. What if program you update not digital sign? Then you must add more rules to Applocker when upate?

 

I'd suggest reading the following before you start:

AppLocker: Frequently Asked Questions

AppLocker Technical Resources

Notably, the stuff on default rules, exceptions, rule conditions, applying the rules to particular group/user only.

You don't need to manually create many rules, there's a wizard to do the job automatically. Also, it generally doesn't slow down anything unless you decide to apply DLL rules as well (not really suggested at this point).

Also, bear in mind that AppLocker/SRP is there to restrict stuff you can run. So, if you want to implement it in a way that anyone can install anything anywhere and run it without having to do anything else, at that point it becomes clearly pointless.

 

You miss my question. Sorry I not clear on ask. I know Applocker. I no understand why you say your last part.
I try ask again. When apply automatic generate rule, it use publisher rule. But if no publisher digital sign, then it will use file hash or path rule. If use file hash then if you update then your file hash will change and it wont work any more until you update your Applocker rule. If use path rule then may be OK.
Also you no answer me on SRP and XP?

 

Yes, of course. That's the entire point of hash rule. What's the problem with that? You can use path rule instead if the above is inconvenient for you, however you must make sure no limited user is able to write to that location. Once again, if you want to create rules that allow anything to run, no matter who installs/runs it and no matter whether the files change or not, it's pointless as it fails to provide any protection.

The question was exactly what? I block all folders that are not specifically whitelisted. Essentially, normal users won't be able to run anything from anywhere else but from %ProgramFiles% and %WinDir% (that's the default both in SRP and AppLocker BTW) with the exception of CDROM/DVD drives which are forced sandboxed by SBIE. The only exception needed here is Dropbox.exe due to it's sucky install location (I avoid Chrome for exact same reason).

 

Problem is that if you update then need to make new Applocker rule. Annoying as I say before. Oh and sorry, forget to mention. If use path rule then still need to use extra block rule for folder where user limited can write to in C:\Windows. As I say before easier to use default rule and use extra block rule for C:\Windows folders where user limited can write and execute.

There are some folder in C:\Windows that user limited can write to. You need block these also.

 

Sigh... once again: use a path rule instead if it's annoying to you.

No, not really, no such folders anywhere here.

 

Sorry, I make change to post before. As I say if use path rule instead then still problem with user limited can write to folders in C:\Windows. This unless you do it manual which is a lot work. If use auto generate then same problem. You still need to make extra block rule. Sigh.

You check all? I can tell you some folder which let user limited write and execute on XP:
C:\WINDOWS\Tasks
C:\Windows\system32\spool\PRINTERS
C:\Windows\Temp

Unless you make change to folder permission or add SRP block rule. I add SRP block rule and all nice!

 

Pardon, but I don't see how's write access to %WinDir% related to your hash/path rules in %ProgramFiles% question really?