Using Sandboxie as least interactive security solution

IMPORTANT: The thread discussion after post no.5 has shifted to Applocker.

Hello everyone,

Am trying to configure my cousins laptop with minimal interactive
security setup in win 7 Ultimate.

How much is Applocker effective against malwares in excel, pdf, jpg or some media file if I follow the path rule based procedure with Mr.Brians exceptions??
I want to use Sandboxie primarily for protection against browser based exploits and for executing executables, both known as well as unknown, for temporary period.I dont want to use SB for any other purpose which would increase its interaction with the user for eg.Immediate recovery of an edited file.

Do you think this strategy is correct or do you guys recommend SB protection for the above mentioned files?

NOTE: Am also configuring SUA, EMET, NIS 2012 which virtually does not have any interaction with an average user considering he uses the laptop strictly for office use.

 

I have set different security up for lots of folks. The degree of experience from not even knowing how to use the mouse to very experienced programmers. I find it is always a case by case basis, with all security software.

If we look at LUA or UAC, it only works for those people who follow a protocol. For those that just click ok, or just RunAs or log into admin to install things, there is not much you can do. Some users just don't want to be bothered. An AV is about all I do for them, and hope they don't call me very soon lol.

But for others, they try to be aware of what is going on. These are the ones you can give some help to. In the realm of Sandboxie, if I am dealing with these types of users, I set the sandbox up based on thier knowledge of the file structure. Sometimes its delete the contents of the box on closing, sometimes it more auto recovery options.

My point is, some people just won't follow protocols or don't know enough, and Sandboxie is a PITA to them. You have to choose what is best for the user. If your user you are doing this for is somewhat knowledgeable and willing to follow protocols, then you have a good number of options at your disposal with Sandboxie.

For example, you could explain to them to download everything to one location, and give that location direct access. Then there is no recovery needed. They just need to know that one place holds all downloads. Of course you have to figure out how to secure that location if they might download untrusted files.

I use Sandboxie quite a bit, and really don't see any interactive prompts other than message prompts that something is not allowed or the like. And those don't happen that often.

Sul.

 

Thanks for the reply Sully. This cousin of mine isn't that tech savvy which is the main purpose I want as little interaction as possible of him with any of the security solutions I configure on his system.

Reading about the different attack vectors, I realized that the browser is the most sought after attack vector. Also he surfs ALOT and goes on random sites ALOT hence was thinking about configuring Sandboxie just to protect the browser even more. He doesn't mind that extra SB box to click to save a file from the web.

However he does not install random stuff on his laptop which prompted me to ask how safe is applocker against malwares in excel, pdf, jpg and media files?

Configuring SB for office, pdf and media files will involve more interaction with SB which he does not want. But if you think that Applocker, SUA, EMET, updated apps, NIS 2012 is not enough for protection against the above mentioned files then I'll have no option but to configure it.

Please advise

 

I think all of the tools you are thinking of using have merit. Which ones to use, well, hard to say.

My line of thinking is pretty simple these days. If it originates from the internet, it has to be from a trusted source to execute on the real system, or it has to start in a sandbox (or VM for me).

If I download a .doc file, and use office, and I don't know anything about it, I open it with word but in a sandbox. I don't care about making exceptions or configuring SBIE at all. I simply don't trust it, and flat out don't open it outside of the sandbox.

If I want to keep the file, then I save it to my docs or something, that will prompt for auto-recovery.

This is where the paid version is worth the small $$ you pay. You can set a few different boxes up to handle pretty much everything, without any prompts. It is the "force" feature I use the most, and what makes it so easy.

I have a sandbox for each browser, a sandbox for media players etc, and a sandbox for downloads. All are forced. The only way something from the net gets to my real system is if I go into my downloads directory with windows explorer and copy it to my real system.

If your cousin doesn't install lots of apps, then it sounds like if I were you I would just purchase SBIE and educate him on using it. You don't even need an AV if you delete the sandbox on exit. The only threat you have (realistically) is when you actually do want to keep something and copy it from the downloads directory to the real system.

Of course you would want to play around with this first to see how it all interacts, but you would probably be suprised at how easy it can be if the user is somewhat savvy with the OS and file system. I will say though if you don't delete the sandbox on exit, then there is the worry that the sandbox, while segregated from the real system, can still contain virii etc. There are ways around this of course, but it is important to understand a sandboxed environment is not free from infection. Keyloggers etc may easily reside within the sandbox, as it is not SBIEs job to handle that sort of thing.

Sul.

 

Hello Sully,

While you did explain the SB part very well the part regarding Applocker
remains unanswered. How well do you think can Applocker (alongwith SUA + NIS 2012 + EMET) stand up against malwares in pdf, excel, jpg and other media files ??

 

For AppLocker, it depends on the user I guess. It isn't a very hard concept to understand really, you define what may be executed by a given user or group. It is an administrative tool designed to allow/restrict users. I remember you in a number of conversations about AppLocker, and I think you understand it enough to deploy it. I wouldn't worry about it failing in your case because the most likely scenario would be something downloaded to the user profile, which AppLocker would handle.

I would have 2 concerns deploying this for your cousin. First, are all file types included that need to be included? Maybe also construed as are all paths included that need to be. What the OS defines as an executable and a script is not always what will be executable.

Second, is it too restrictive for your cousin? The answer is probably no, but it is best to ask the question. A good example is you restrict cmd.exe for him. He doesn't need it. Or maybe you restrict .bat filetypes. But one day he has a problem and needs to use cmd or you send him a batch file. What do you do then?

I see AppLocker/SRP as great ways to lock down a computer that you administrate. However, if you aren't there to administrate it, it can be so "secure" the user or others trying to help administrate that not much can be done. These aren't "make or break" issues really, just things to consider.

Personally, I like SBIE approach better because it seems somehow easier. But I wouldn't really hesitate to use AppLocker either if the user could handle the restrictions and I knew the rulesets were sufficient.

As far as EMET goes, I think you should put it on regardless. I don't really think it is a magic bullet that you absolutely must have. I have used one system without it since win7 came out, no ill effects. But at the same time, it is free, it is easy to use and it does add some extra security that is relevant, so why not use it. I did install it on my main PC, but don't know if it has ever come into play because, well, how can you know really lol?

Finally, for NIS, I have no idea at all. I have had a rather severe hate for norton products for a very long time, primarily because I fixed so many computers that had the Norton Virus. Of all the AV out there, it is the lowest on my list. In all fairness though, for the last few years I have heard much better reports about it. And the last few computers I worked on that had Norton installed actually allowed me to remove it, so that is a step forward I guess. And I like some of thier products, like the UAC tool for Vista and I use thier DNS service. I have a grudge against them I guess for all the hours of work I had to do over the years that I never got paid for because thier POS software wouldn't uninstall. Hard to charge so much for simply removing a program that requires a lot of registry work to actually remove. It was such a PITA.

May not have answered as you had liked, but if you understand the underlying reasons of what AppLocker or EMET does, you know they work, its just that setting this stuff up on others systems is not always "will it work" but "is it best". And that is a very hard question to answer, for anyone. I struggle with this everytime I help someone. It seems what I do is different almost every time because each user seems to have such different amounts of knowledge etc.

Sul.

 

I thrive on discussions about AppLocker

It's a great tool, imo, if you have the available version of Windows7/8. MrBrian's approach is probably the easiest to use and especially to manage. As with any approach you follow, however, you will no doubt run into "unconventional" scenarios especially in the user\appdata directories where the paths and file names are often rather extensive in terms of length as well as only temporary and dynamic in nature, making the use of wildcards a must. The following two examples (which I use) show the user path with the use of wildcards. Adobe has been especially notorious for making rule management in AppLocker a hair pulling affair for me

Code:

C:\USERS\*\APPDATA\ROAMING\ADOBE\FLASH PLAYER\NATIVECACHE\*\*\ADOBECP*.DLL

C:\USERS\son's_name\APPDATA\LOCAL\ROBLOX\VERSIONS\VERSION*\ROBLOXSTUDIOBETA.EXE

In non-protected directories like the latter, I would prefer to use either Publisher or Hash rules, but Publisher rules are rarely available on all or any of the program's files in these locations, and using Hash rules will result in a nightmare to manage because every time the files changes, which is often, the Hash value has to be re-calculated or it won't execute.

 

Am using the path based default rules with Mr.Brians exceptions. I find it easier to manage than Publisher and Hash rules.However I've noticed an anamoly though, I can install & update firefox addons in the Standard Users %appdata% folder!!! Is there any workaround??

Can you please elaborate on that??

Assuming that a standard user has full access to cmd.exe what damage can be done? If any damage is possible can I restrict him to use only ping and ipconfig and no other commands in cmd.exe?? I was surprised to see batch files executing in SUA when Applocker is configured!! What are the executables or scripts that can still execute even after Applocker is configured with path restrictions?? (only execute from Program files and Windows folders)

Thanks wat you've posted the exact issue that I've raised above. How can a file execute in the users %appdata% folder when its clearly mentioned in the path rules that executables can only execute from program files and windows folder and nowhere else??

 

Well, that's where you have to create whatever's needed in %appdata% directories. The defaults don't account for these locations.

As for scripts, I have a few bat files that run daily or weekly, and Applocker would block them if not for the path rules I had created for them.

 

But does this not contradict windchilds explanation about extensions in one of the posts where he explained that execution has nothing to do with extensions and that Applocker looks inside the file rather than its extension?? In case of firefox its the .xpi extension which is executing.

 

As wat0114 states, this is user profile land. You EXPECT the user to have rights there. Since many browsers now install to userland, you have rights there. You should have rights there, it is your private little space you know. I haven't studied AppLocker as in-depth as I did SRP, so I don't know if there is a native exclusion for userland paths. But if what you and wat0114 are describing is accurate, it makes sense that you should be allowed to do so. If you still cannot figure it out or someone else doesn't pop in and solve this mystery, it just might convince me to have another go with AppLocker. I do like a good mystery after all

I am refering to something that is installed on your computer and a specific filetype that would go with it. Batch files are a great example because they are not really compiled binaries, but rather use a binary to execute. Remember that windows ships with what it knows about, and that usually entails the most common. If you put some script engine on your machines, and then don't include the script extension, then that is a possible weak area. I am not saying there are holes or things that are wrong with AppLocker, just that you need to be aware of things like this.

The assumption is that code can be ran via cmd.exe. It isn't how or if, only that it could. I am not saying you should or should not, just that it is one thing you can do to tighten things up. Here is a list of things I had available for my PGS project. It includes a few filetypes that were not monitored by SRP in XP and some different items that might want to be denied execution. This is just an example of things you might do, not that you should or that AppLocker doesn't. I am not trying to give you specific instructions here, but to get you to understand the idea behind what I am talking about.

You can see, there are some directories and files that could have been denied to bolster security. Were they all needing to be denied? I don't know, it depends on the user. Those are the ones "we" came up with in discussions though, at least those are the ones we figured would be in a windows install and almost sure to exist. If you had other "dangerous" files or paths, you would have to make that distinction yourself.

Sul.

 

I was under the impression that it only worked for .msi and .vbs or other M$ scripting filetypes. If I remember correctly, that was one thing I really wasn't that impressed about was that the scripting portion of AppLocker only applied to M$ and not the other common situations.

Of course I could be wrong lol. Windchild is a smart cookie.

Sul.

 

The file's extension doesn't matter when either Publisher or Hash rules are used. The Publisher rule looks at the file's signature while the Hash rule looks at the file's checksum. An example of this is Surun has one executable in %Windir% directory named Surun32.BIN. Even though AppLocker doesn't specify .BIN as executable file types, it still allows me to create a hash rule for it (it's not digitally signed) by manually typing in the name including extension in the filename field, then generating it's hash checksum once "Open" is hit.

File extenions do matter with Path rules, which is why I don't particularly like using them for files in non-protected directories, but of course the hash rule is a royal PITA maintenance-wise when the file(s) aren't digitally signed which support the Publisher rule type.

As for examples, keep in mind a Path rule: "C:\Program Files (x86)\Internet Explorer\*" will allow any file type under the directory to execute.

If you create: "C:\Program Files (x86)\Internet Explorer\*.exe" then only files with .exe extension can execute.

If you create: "C:\Program Files (x86)\Internet Explorer\iexplore.exe" then only iexplore.exe can execute

@Sully, I'm not sure about scripts, but you could try navigating to the script's directory location using the Hash rule type, then manually type it's full name including extension, <Open> and see if AppLocker will generate a hash value for it. Also, can you not just do the same for a Path rule even though the script type isn't listed under Applocker scripting file types?

 

I just put a .exe and .bat files in my Standard User profile and both of them did not execute. So I think since the browsers are running from an allowed Applocker path i.e.Program Files, their addons/extensions are part of the allowed process hence downloading and executing/updating?? So ultimately it all comes down to the right source from where you download your addons which also applies to any other executable anyways?

 

It's hard to comment on this because I don't know how you have your Applocker rules set up. If you are using MrBrian's from here, then it makes sense that those files would be blocked, because the rule set has no provisions for allowing anything to execute in a user's directories.

It is for this reason why you have to create additional rules for anything legitimately required that executes from within a user's directories, especially the %appdata% locations.

Assuming again you are using MrBrian's rule set, then this makes complete sense.

If I understand your question correctly, then yes you are right. The whole idea is to obviously install verified safe applications, then create, if necessary, rules for them.

 

This is why I don't use AppLocker, and why I liked SRP when used with the Basic User option while logging in as an admin. I experiment and change things too much, it is a PITA. But it has always been a solid way to do things, that much is for sure.

Sul.

 

Does SRP in Basic user mode still offer some sort of protection? I suppose with Applocker one could temporarily configure enforcement to "audit only", then the logs would reveal what would have been denied if the "enforce rules" had been enabled.

 

Unfortunately SRP and the Basic User option only works in XP and Vista. In win7 it no longer functions like it did, so isn't really usable.

The protection offered was that you could start a given process at reduced rights, much like what Integrity Levels can do now. It was a convenient tool for those who logged in as admin to create a "black list" of files and directories to reduce rights on. If I didn't do so much stuff on a daily basis that needed root, I could just use AppLocker or SRP along with UAC and everything would be easy.

Sul.

 

What I meant by 'put' was that I was able to paste those files in my SUA appdata directory which is definitely possible since all users have write permissions to their own user profile. But I definitely could not execute them which means my Applocker rules are running fine