AppLocker implementation

I guess this is self explanatory:


In wat0114's thread, Windchild explains it nicely.

 

Cool, thanks Lucy. I do not have the technical expertise to have been able to confirm what Windchild stated in that thread, although I could pretty much take his word for it. Still, I was not able to take it as gospel. Your hard evidence proves he's right. Are you able to produce something with regards to .inf extensions, time permitting of course? I tried last night for a bit but came up empty

 

Sorry, stopped dead in its tracks here. In fact, I needed UAC credentials escalation from my LUA just to access this directory in the first place.

 

Can you please check where this .pif extension is redirected to? I guess it is redirected to C:\Temp\PGS_v1\PGS (2).pif and that .pif file is again redirected to an exe file which is not in C:\Windows or C:\Program Files...I am not sure but let me know that....

 

In this case, I just renamed the PGS.exe in PGS.pif.

But you are reaching the limits of my knowledge.

From what I understood from windchild, AppLocker is checking at kernel level any compiled code, included in any kind of file, which requests execution.

An ini, pif or inf file doesn't need to be forbidden as long as no compiled executable code is inserted inside its body. What Windchild is saying, it is that any kind of such file will be stopped if it is the case.

Long story short, to test it, we need a non-offensive pif file containing compiled code (which shouldn't be).

On a side note, there is no pif file on my computer. As a strategy, one can decide to forbid the download of such kind of file at first hand.

 

Am i doing any offense? If i am then please forgive me. I think we are here to discuss the things, if you feel that i am asking like kids then i am pretty much sorry for the same.

 

Hi Avanash,

I think lucy is just saying we need a non-offensive file to test

The way I interpret Windchild's statement is that Applocker is stopping executables with unlisted file extensions such as .BIN when another executable tries to launch them?? Not sure exactly, but it seems that's what he's saying. Windchild, where are you?

 

That's what i am looking for. I m sure that AppLocker is limited to certain number of file extensions. My major concern are related to .pif and .inf files.

 

Right here, suffering grievously from all the file extension stuff, of course.

[start my boring rant]

One thing about file extensions: they're pretty much meaningless. A trojan executable called "malware.exe" will continue to be a trojan executable even if you rename it "malware.jpg" or "malware.blopgoogoo". Changing the file extension changes practically nothing. Software that works based on file extensions may behave differently with that file: instead of trying to run it as a program they may now try to open it as an image file for viewing. But the actual file hasn't changed: it's still an executable, still malware, and most importantly you can still execute it and use it for its intended purpose (of being malware). For a very primitive demonstration of this, you could copy notepad.exe from the Windows folder to any folder of your choice and rename it as notepad.jpg. If you now try to double-click the file open in Explorer, nothing much will happen, since Explorer looks at the file extension and thinks it's an image file - which it isn't. But if you use the command prompt, Luke, and tell the OS to "start notepad.jpg", guess what happens then? Yes, that "image file" executes and runs like the lovely little text editor program it is. Utterly disregarding the fact the file extension claims it's an image file.

Security based on file extensions is pretty silly. After all, you can name anything, well, anything, with any file extension. malware.exe? Renamed to malware.foo it still executes, and still does the job. So, what's the point in looking at file names and analyzing files for executable code? Why not just look at what's actually being done with the files? Opened in an image viewer for reading? Not likely to be a problem. Being created as a process for execution? Well, that might be a problem...

And, that's what AppLocker does. It monitors process creation, DLL loading - the works - and allows or denies different processes and libraries based on its ruleset. It really doesn't matter to AppLocker whether the trojan executable is called malware.exe or malware.jpg. If something wants to make a process out of that file, AppLocker will block it or allow it according to its ruleset.

Don't get caught up in the file extensions. They're really not something that should be relied upon in security in any way - since anyone can simply change a file extension into something completely different, without actually changing the file.

Let's look at it this way: Have you ever tried to execute an .inf file or a .pif? What's the concern? If the file is something.inf that's actually a program instead of being a text file, then AppLocker will block it if something tries to execute the file, assuming block is what the rules dictate. If the file is an honest-to-god text file, what's it going to do? Refer to another file that is actually a program and hope that Windows executes that file, by way of removable drive Autorun for example? Well, if that happens, then AppLocker jumps in, again, to decide whether to allow that new executable. AppLocker isn't limited to judging files based on their file extensions. That would be very unwise and insecure.


And really, why talk about it when one can just do it? If one has concerns over AppLocker's ability to do something, then all it takes is a little testing. Don't think AppLocker blocks anything except a couple of file extensions like .exe or .com? Then you can test that by renaming some executable as test.jpg or test.inf for example and then try to execute that to see what AppLocker says and whether the program actually runs. If AppLocker blocks the renamed executable, maybe AppLocker isn't really that interested in file extensions... Think that .inf files are a big threat that AppLocker does not address? Then create a malicious .inf file of your choice and try to get it to actually do something without AppLocker blocking it. If it turns out that your autorun.inf can't execute the worm executable it's supposed to get running, because AppLocker keeps blocking the actual worm executable, perhaps .inf files aren't that much of a concern...

AppLocker combined with limited user accounts isn't perfect, but it is plenty strong enough for current real-world scenarios.

[end my boring rant]

 

Excellent rant, not even one of your more epic rants, either Seriously, thank you so much for clarifying things. For one, I've had a hard time grasping this concept but you explain it perfectly

 

Thanks for explaining all of us...I am very glad to say that you are really a good "Rant Master"

 

Thank you Windchild!
You saved us

 

The call is CreateProcess in SRP, but I have not found if this is the same call in AppLocker. It was said that using NT_CreateProcess would have been a more secure method rather than just CreateProcess. I wonder if AppLocker has changed things up at all.

In XP/Vista, CreateProcess call does what Windchild is describing, creates a process. Windchild has described the difference between creating a process and having notepad open the file you are double clicking on. As he ways, the internals of the OS understands to check, regardless of extension, what to do with an object.

When the object is found to need to use CreateProcess, it will first examine the SAFER registry values. If SRP rules are in place, they will be examined, and then CreateProcess will either allow or deny the process creation. The process creation though can also be construed to start in different states, such as in admin state, or constrained, restricted, etc etc.

The familiar prompt that says "this program cannot start due to a software restriction policy" is given after CreateProcess has determined it needs to HALT creating the process, and then it tells you about it.

The process creation, if allowed by SRP SAFER values, is CreateProcessAsUser (AFAIK in most instances). This same method is used in DropMyRights, with some ther calls.

Understanding more indepth things can help to understand more basic things like extensions.

I wonder does anyone have any infos on how AppLocker might be different at this level?

Erm, could not help but post this. There is a LOT of SRP/AppLocker stuff going on here now, and perfect timing for myself thankfully.

Sul.

 

Whoaa! too technical for me, Sul I guess it's a good thing that tech-savvy heavyweights like yourself, Lucy and Windchild, for example, can break these applications down into their bare parts to figure out what they're really all about and whether they offer serious mettle, but in my few months use of Applocker and running only Win 7's two-way fw with my own ruleset, absolutely no 3rd party supplements, other than Mbam on-demand which of course uses no resources until I launch it, it's all I need - 100% convinced of this. According to what I've read on Applocker, it is better than SRP, at least in terms of ease of use and apparently the Publisher rules capabilities beat the hash rules because there is no maintenance overhead of having to update the rules whenever an app is updated(graded). I actually found SRP easy to use but the same can not be said, it seems, of some others who've used it. There are a number of threads where people are running into issues with it, though in fairness there's at least one similar regarding Applocker, but it looks to have been a browser issue now resolved.

 

Excellent summary/explanation!

For those who weren't involved in computer security five or six years ago, malware writers were playing around with fooling people with the double-extension trick. The second file extension is the one that Windows uses to associate with the program necessary to open the file.

Sober email worms would arrive as an email attachment, the message attempting to trick the user into opening a text document. Since PIF has been discussed, here is an example where PIF is the second extension. TXT doesn't enter into the picture, as far as Windows is concerned.

Depending on how the user's ZIP program window is configured, the second file extension may or may not show:

​

An alert user may or may not pick up on the "type" of program: MS DOS shortcut to a Program -- not a document! But the typical average user/victim had no clue about file extensions, hence, the huge success of these exploits. It was during this time that security measures began to focus on educating users about downloading, opening attachments, etc, so that email exploits are not as numerous these days.

If the user/victim extracts the file, the PIF file extension may or may not show in Windows Explorer. The user may or may not be suspicious of the filetype icon.

Moving to today: if a security program works on file extensions, unless the PIF file extension is on the block list, the exploit succeeds. Only security that monitors what the code in a file does would catch this exploit no matter the file extension, should the user attempt to open the file:

​

I assume from the discussion that AppLocker will also block this file from executing.

regards,

-rich

 

oops,
But I still had to wait until it comes to atleast to Beta version, as fix is now only on developers version...



nice post Rmus.

 

Yep, I understand what you are saying. I don't really 'doubt' that, but I do understand the mechanism that SRP employs, and to a degree why using a different method would have been better. So for me, I really want to see just what AppLocker is doing in this realm. I assume it is built upon the same house that SRP, but would be very pleasantly suprised if it were to use more secure measures. I am no expert/guru, I just know enough to be dangerous

I agree. I believe though that most who want to use it have a mis-conception about its use. I wish it was called something like SBL or SWL (software black list or software while list) or some form thereof. I think it might be easier to grasp the overall concept of a list of allowed/disallowed and exclusions rather than the terminology used. But then again, this is enterprise stuff likely not envisioned for home use, since home versions don't have it implemented.

I would be more interested in seeing capabilities to expose routines used in .inf files and thier like. Autorun and the like are handled by mechanisms with more complexity than just CreateProcess.

Sul.

 

Regarding the benefit of whitelisting over blacklisting - at least concerning Applocker, I don't know exactly where I got this from (it's in my notes), but it was one of the MS articles which states as follows:

This is why I have harped on this a few times already.

 

Wow. I must find the time to look into this. The hierarchy of SRP was clearly stated. I have not seen it yet for AppLocker. Sounds somewhat ambiguous.

What has your experience been with exceptions? In my first few attempts with AppLocker, I was unsure of exactly how it wieghted the different rules since the exceptions were part of the rule rather than a seperate rule.

Sul.

 

I'll have to check later when at home, but I don't know if I even bothered with exceptions. It's just something I never focused on yet. I do believe I have a couple rules, though, which could be refined for better efficiency if I create exceptions for them. One of them applies to the nVidia cp which I allowed only my lua account and the administrator's access to.

BTW, found the link highlighted as "Important":

http://technet.microsoft.com/en-us/library/ee460942(WS.10).aspx

Also to quote something interesting:

Sorry, another Edit

Basically the rules are very specific. The whitelist states what exactly can run, where exactly it can run from, and who exactly can run it (Everyone, Built-in users, specific user(s), administrators). Anything else that in any way contradicts these specifics will be prohibited from running.

 

Windchild's informative rant is precisely the type of thing I have to explain to Linux newbs all the time. They always ask about file extensions and I have to explain that file extensions mean absolutely nothing to the Linux or Unix kernel -- they are only there for humans to look at to distinguish what is what on the screen (and even this doesn't work if the extension is changed).

In Unix, a file is executable only if its file permissions allow it. It doesn't matter if its named "virus.txt" or "virus" or "virus.deb" or whatever, it will only execute based on whether the execute bit has been set in its permissions. And newly created files (e.g. those downloaded) do not have the execute bit set by default (this is called the "umask"). The user has to explicitly set the file to execute (unless they have set the umask to do differently).

I guess at the low levels (below the GUI), Windows works similarly -- that is, file extensions are only there for humans to be able to distinguish one file type from another, but mean nothing to the kernel of the OS. The file extensions also make it easy for other software that interacts with certain file types (image viewers, text editors, etc.) to be able to open the file upon a single or double click.

As Windchild said, AppLocker is smarter than relying on file extensions since AppLocker, no doubt, works at the kernel level and is able to intercept kernel calls, etc. I am not on my Windows partition right now, so I haven't been able to test unorthodox file extensions on executable files, but I am sure Applocker would block them since my policy is a white list designed to block everything I haven't specified as being allowed. This is why I often say that AppLocker configured with a default deny policy running from a LUA makes AV software, at best, superfluous.

 

LOL, you oughta post a sticky in the Linux forum Anyway, I'm glad I finally grasped the concept of that. It's something that doesn't get talked about much, but I do remember seeing one of your posts explaining it. Thanks for the info!

 

Hello folks,

I don't know whether or not you'll find this information regarding AppLocker useful, but I guess it won't hurt letting you know about it, in case don't already.

I haven't seen it personally, yet. I just came across it now.

Link: http://technet.microsoft.com/pt-pt/security/ee794675(en-us).aspx

In one of the earlier posts someone mentioned that AppLocker would overcome SRP (The same is said in the help file, for example).
While that's true, I've also read in the help file that if setting SRP and AppLocker in different GPOs, that it will allow interoperability between both.

Could you check it? I can't at the moment.


Thank you

 

Yes, but Applocker GPO policy will take precedence SRP GPO policy in Windows Server 2008 R2 and Win 7.

http://technet.microsoft.com/en-us/library/ee791851(WS.10).aspx

 

Ok please bear with me as I try to explain a couple things. I have applocker enabled as per Lucy's posts. After reboot I see that some programs have issues. Flash keeps crashing in IE8 which causes IE8 to crash. Also, Google Chrome will not start up unless I choose "run as admin". I am assuming other programs will need to "run as admin" protocol as well?

Here's my questions-
1. I read something about a white list above, is there an easy way to build a white list?
2. I am running as admin, do I still need a real time antivirus scanner? I have a few on demand scanners on hand. I also have prevx paid which can be ran and is no big deal. I just hate all the scanners going on all the time.
3. Running as admin with applocker do I need a HIPS or some sort of behavior monitor program, such as Comodo with D+ or MD?
4. If I choose to run a standard account with applocker is there some way to move all my programs and such things as browser favorites from admin to the standard account in one swoop?
5. If I choose to run as sandard account with applocker is there an easy way to white list programs?
6. Is there some fix for the flash in IE8 issue?