Question

Page 1 of 2 1, 2  Next

View previous topic View next topic Go down

Question

Post by Rico on 25/1/2011, 11:55

I remember that with the release of 5.0 the HIPS had trouble blocking DLLs from execution. Is that still the case or was this addressed?

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 25/1/2011, 11:57

Yes, I'm pretty sure it's still the case. And it's intentional by Comodo.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by p2u on 25/1/2011, 12:47

ssj100 wrote:Yes, I'm pretty sure it's still the case. And it's intentional by Comodo.
As is the case with Faronics Anti-Executable 3, by the way. Remember how beautifully version 2 blocked most everything even from downloading? I would call that almost ideal protection. But ideal is too good. Those who provide that are either bought out or forced to weaken their protection mechanisms. Same with all those "trusted-untrusted", "signed-unsigned" groupings. Seems like they all do this to get the MS "compatible with" logo... Very Happy

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 25/1/2011, 12:53

p2u wrote:As is the case with Faronics Anti-Executable 3, by the way. Remember how beautifully version 2 blocked most everything even from downloading?
Yes indeed, and this is the reason why I do my testing with Faronics Anti-Executable version 2 and not version 3. However, I do remember reading that Rmus wrote to Faronics and that they were going to implement DLL blocking back. Not sure if this has happened yet?

With regards to Comodo, egeman said that implementing DLL blocking back would be considered in the future. The question is, why was it taken out in the first place? That's what I really don't understand. One thing to disable DLL blocking (as default), but it's another thing to remove it completely.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 25/1/2011, 21:08

p2u wrote:As is the case with Faronics Anti-Executable 3, by the way. Remember how beautifully version 2 blocked most everything even from downloading? I would call that almost ideal protection.

Its intentional that they don't provide protection thats worth a crap nowadays or hinder and screw over developers that do. The reasons being are intentional backdoor planting and also it suits Microsoft's economic model where the OS becomes inevitably infested with crapware forcing users to move on and buy new pcs.


Btw, how is that driveby downloading was stopped by older versions of Faronics AE? I thought that it was possible to stop execution of downloaded code only.

Now regarding the DLL blocking in Sandboxie, this is feasible according to Tzuk and already possible as per his response;

http://www.sandboxie.com/phpbb/viewtopic.php?t=9794

Since that is the case is it possible for you guys to compile an executable file extensions list so I can add it to my start/run list? I would really like that it would be a great thing to reference. Sandboxie is so flexible essentially leaving its AE capabilities open ended.

Couple of related questions:
-can Faronics AE v2 work on x64 Windows? Can it operate on Vista and 7?
-Is it possible to obtain the v2 installer from a trusted source or has it completely disappered from the face of the planet?

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 25/1/2011, 23:24

Hmm, I'm not sure about that DLL blocking in Sandboxie - for example, what if the extension name doesn't end as .DLL (but it is a DLL file)? I might try to do some testing with it later.

With regards to Faronics Anti-Executable version 2:
1. I don't think it's 64-bit compatible and I'm pretty sure it doesn't run on Vista/7.
2. As far as I'm aware, it's not possible to obtain the installer from a "trusted" source anymore.

EDIT: just did a quick test regarding Sandboxie and DLL's, and I don't think it's currently practical to block DLL's "universally" with that setting. Give it a try and you'll know what I mean.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 00:40

Rico wrote:Btw, how is that driveby downloading was stopped by older versions of Faronics AE? I thought that it was possible to stop execution of downloaded code only.
Which driveby are you talking about?

By the way, I'm off my main PC at the moment, but I'm thinking about possible methods to include .DLL blocking as well as other executable code with Sandboxie.

Firstly, we need to establish if such blocking is reliable. As I mentioned already, we would need to ensure Sandboxie doesn't just look at file extension (I suspect it does). For example, a functional .DLL file could be "disguised" as something like "virus.TEH". One method to test this is to load the "disguised" .DLL file via a (sandboxed) command prompt. If it's still blocked (with Sandboxie's "Blocked Access") successfully, then that's probably good enough.

If we establish that Sandboxie is reliable enough at blocking such file types and execution, then we can proceed to setting up a configuration. To avoid blocking valid and required .DLL loading in the sandbox, while still covering potential "holes", this is what I would suggest (probably needs more tweaking):
1. Within the sandbox, configure READ ONLY access to C:\Windows and C:\Program Files. This essentially means that within the sandbox, no file can write to those areas. I'm pretty sure this should be more effective and/or complete than the Drop Rights configuration. The reason for doing this is so that we can still load valid and required .DLL files from those "trusted" areas, but no new .DLL file (or any file) can be written there.
2. Within the sandbox, configure "Blocked Access" of .DLL files to the user directory. Here, we could also emulate SRP's extension list and include other file extensions considered to lead to "executable" code.

However, we have come across another practical issue. C:\Windows, C:\Program Files and the user folder are not the only areas where malicious code could write and execute - there are plenty of other areas. Much more configuration within Sandboxie will be needed (not sure if it's even feasible) to cover these areas while still allowing "white-listed" files to load. As I said, I don't think it's going to be very practical. However, if you're wanting to block eg. foreign DLL loading in your "banking" sandbox, then configuring as above may give you more security than not.

tzuk was of course referring to blocking files from specific folders. Sandboxie simply doesn't have a "white-listing" component in order for it to behave as a fully fledged and practical Anti-Executable. That's my take on it anyway. Hope to see what others think.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 06:26

ssj100 wrote:
Which driveby are you talking about?

I mispoke, what I meant is drivebys in general. All drivebys in general seem to follow the same process:

1-Shellcode injection phase: Code that subverts the web browser is downloaded by exploiting a vulnerability in the web browser.
2-Shellcode execution phase: The downloaded code is then injected into the browser's process.
3-Covert binary install phase: The web browser, now compromised, tries to retrieve malware from the attacker’s web server. That code installs on the victim’s computer and does its dirty deed.

Now how does Faronics AE v2 stop the download of code? - execution prevention is self explanatory, but the download of code would still be possible because holes in the webfacing app simply allow it. The only way to prevent it is to use a browser that is immune to the initial vulnerability. Therefore no code will be downloaded in the first place right?

Also does v2 run on vista/7 ?-- just out of curiosity

ssj100 wrote:Firstly, we need to establish if such blocking is reliable. As I mentioned already, we would need to ensure Sandboxie doesn't just look at file extension


Yes please test this as it has many significant implications. Hopefully it succeeds. I know that such a setup and compilation is bound to take some work, but I believe that its worth it in the end. It would be permanently a set and forget setup.
It would be nice if a specific file type is not allowed if it was downloaded in a sandbox but matches a file type that is whitelisted. Like how if an app downloaded in a restricted sandbox can't execute even if it matches a whitelisted app name.


Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 07:26

Rico wrote:Now how does Faronics AE v2 stop the download of code? - execution prevention is self explanatory, but the download of code would still be possible because holes in the webfacing app simply allow it. The only way to prevent it is to use a browser that is immune to the initial vulnerability. Therefore no code will be downloaded in the first place right?
Some good musings. I must say, I don't have any clear answers for this. All I understand is that with Anti-Executable version 2, it will at least prevent .EXE files (and probably .DLL files) from being downloaded. I have no idea how or why it works.

Given that most (all?) malicious exploits in-the-wild eventually tries to download a .EXE file, Faronics Anti-Executable will successfully block this "payload" and therefore prevent any harm to the system.
Rico wrote:Also does v2 run on vista/7 ?-- just out of curiosity
No, I don't think it does. I will try to confirm that for you in my Windows 7 VM though.
Rico wrote:I know that such a setup and compilation is bound to take some work, but I believe that its worth it in the end. It would be permanently a set and forget setup.
Not only will such a setup and compilation take some work, but I believe it will also leave a lot of holes (for the reasons I have already stated/implied in my previous post). Therefore for me personally, I don't see any benefit of this (for now), particularly given my security setup/approach with Sandboxie.

Rico wrote:It would be nice if a specific file type is not allowed if it was downloaded in a sandbox but matches a file type that is whitelisted. Like how if an app downloaded in a restricted sandbox can't execute even if it matches a whitelisted app name.
That's not how Sandboxie's "Blocked Access" functions though. It's quite a different mechanism to the start/run restrictions function. "Blocked Access" simply denies anything in the sandbox from even READING specific files or folders. Start/run restrictions directly blocks execution of .EXE files.

I think we are trying to use "Blocked Access" for much more than what it was intended for. The main use of it is to prevent sandboxed programs from eg. READING sensitive data in specific files/folders (such as in the case of a malicious keylogger). What we're trying to use it for here is to (indirectly) block execution of other "executable" file types (excluding .EXE, but including .DLL, .BAT, .JS etc). In fact, we'd not be really blocking execution of these file types, but we'd actually be preventing programs in the sandbox from READING these files types. So only in an indirect sense would we be "blocking" them.

Anyway, I'll hopefully get time to do some experimentation tonight.

EDIT: I can confirm that Faronics Anti-Executable version 2 fails to install on Windows 7.
EDIT2: I can confirm that Sandboxie's start/run restrictions will block .EXE files from running even if the file extension is renamed. Good to know. However, I'm struggling to test the Blocked access function in the same way for .DLL files.


Last edited by ssj100 on 26/1/2011, 09:05; edited 1 time in total

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by p2u on 26/1/2011, 09:03

ssj100 wrote:All I understand is that with Anti-Executable version 2, it will at least prevent .EXE files (and probably .DLL files) from being downloaded.
Rmus demonstrated the difference between versions 2 and 3 here: AE 2-3
As we can see, even when the extension is renamed, version 2 blocks dll's, and version 3 doesn't. It is not able to block executables that are a result of Didier Stevens' tricks with VBA Macros, but I think that's forgivable.

Paul


Last edited by p2u on 26/1/2011, 09:09; edited 1 time in total

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 09:08

p2u, could you guide me on how to test DLL loading? I'll obviously need a DLL file to start. Thanks.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 10:04

By the way, here's some experimentation:
http://ssj100.fullsubject.com/t5-sandboxie-configurations#2902

I'm now fairly sure that Sandboxie would not be able to directly block new DLL files. Of course, Sandboxie can easily be configured to block DLL or whatever files that are already known on the system - you'd need to know the exact path and/or filename and configure it appropriately.

However, as I finally realised, you can configure a sandbox environment which doesn't allow any new file to be introduced, thus indirectly acting as an ultimate Anti-Executable.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 10:36

Well thanks for trying this out. It seems nothing can stop DLLs headon anymore Smile o well.

This security config that you wrote up sounds very robust. So would enabling writing to one custom folder in the Documents and Settings mitigate any unintended, driveby execution, yet also provide me with the functionality of saving files if needed? Lets say I create a folder named 'Saved Files' on the desktop and allowed access to it only with all the other read/ block access applying, then no driveby can take advantage of that and execute right?

ssj100 wrote:Given that most (all?) malicious exploits in-the-wild eventually tries to download a .EXE file, Faronics Anti-Executable will successfully block this "payload" and therefore prevent any harm to the system.

So what you're saying is that the whole point of a DLL is to assist in the website in download and running an exe file, in other words on its own its useless but it serves as a drawbridge opeing the way for the actual virii?
The other thing I wanted to know is driverby sys files are pretty much useless since Sandboxie blocks drivers from loading correct?

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 10:38

On a sidenote I cant remember whether Sandboxie allows access to a subfolder of a blocked folder... In that case my first scenario could work.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 10:48

Rico wrote:On a sidenote I cant remember whether Sandboxie allows access to a subfolder of a blocked folder...
No, as far as I know, it does not. This is why I said it's not going to be very practical. By the way, please re-read that configuration - I've edited it at the bottom.
Rico wrote:So what you're saying is that the whole point of a DLL is to assist in the website in download and running an exe file, in other words on its own its useless but it serves as a drawbridge opeing the way for the actual virii?
Not really. I'm basically saying that all in-the-wild malware seems to call a .EXE file. If someone has an example of in-the-wild malware which only operates via a .DLL file, please PM me the sample.
Rico wrote:The other thing I wanted to know is driverby sys files are pretty much useless since Sandboxie blocks drivers from loading correct?
I'm not sure about that. Probably best to ask tzuk. I'm pretty sure Sandboxie allows some drivers to load, for the sake of functionality. But again, Sandboxie's main aim is not to block things from running. Sandboxie's main aim is to allow everything to run while keeping it isolated from the REAL system.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 11:05

I'm pretty sure that sandboxed drivers that dont exist on the real system can't load. They are allowed to if only if you enable that option in the lowlevel access options in sandboxie's menu.


Now to make the setup more practical yet effective, one could block access to each directory present in the User folder on say Vista/7 yet keep the desktop accessible. Would allowing wrote access to the desktop give a chance for anything to install? I wouldnt think so since the appdata folder is probably the only main folder that could be used to install anything under the user directory.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 11:08

Rico wrote:I'm pretty sure that sandboxed drivers that dont exist on the real system can't load. They are allowed to if only if you enable that option in the lowlevel access options in sandboxie's menu.
Yes, that sounds correct.
Rico wrote:Now to make the setup more practical yet effective, one could block access to each directory present in the User folder on say Vista/7 yet keep the desktop accessible. Would allowing wrote access to the desktop give a chance for anything to install? I wouldnt think so since the appdata folder is probably the only main folder that could be used to install anything under the user directory.
Wouldn't allowing write access "anywhere" allow something to potentially execute/run? By the way, for argument's sake, what about malware which only exists in memory? This is why a good "approach" is also necessary to make full use of Sandboxie (eg. reserve a separate web browser for banking and delete contents after each session).

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 11:13

The thing here though is even if it does run, where can it go? It cant write anywhere else but that folder, hence cant really install anything. Also most exploits tend to allow stealth downloads to a browser's cache.

Considering that I know what I am downloading is trusted, that should be a non issue. As then I would explicitly allow it to download to my desktop.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 11:20

Rico wrote:The thing here though is even if it does run, where can it go?
I don't think it needs to "go" anywhere to cause problems. For example, some malware only needs the executable file to run and doesn't require to be "installed" anywhere. Classic examples are scare-ware and ransom-ware.
Rico wrote:Also most exploits tend to allow stealth downloads to a browser's cache.
I think you're right, but then most (all?) exploits' payloads would be stopped dead with Sandboxie's start/run restrictions.
Rico wrote:Considering that I know what I am downloading is trusted, that should be a non issue. As then I would explicitly allow it to download to my desktop.
This is what I do all the time - recover specific files on to my REAL desktop (in a "Downloads" folder).

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 11:25

Memory only malware, how common is that? Smile it seems that there s always some little Achilles heel somewehere...

Well, if its as rare as kernel mode vulnerabilities that can bypass all security software I think I should be good. The real problem is that Windows wasnt designed with security in mind.

I think whats great about Sandboxie is the number of roadblocks and restrictions it hurls against conventional malware. I think getting the most out of the program depends on how much you can really lockdown.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 11:27

Sandboxie certainly has a steep learning curve if you want to dig deep!

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by Sadeghi85 on 26/1/2011, 20:07

ssj100 wrote:If someone has an example of in-the-wild malware which only operates via a .DLL file, please PM me the sample.

Don't know if Stuxnet counts?

Sadeghi85
Member
Member

Posts : 66
Join date : 2010-07-22

View user profile

Back to top Go down

Re: Question

Post by Rico on 26/1/2011, 21:21

While testing with the read only access IE 8 works fine. Chrome blurts out an alert that things might not function as expected, nonetheless everything works well. There is one thing I dont understand though; in principle browsers need to download a page to be able to display it right? Or can it render content without downloading it?

I also noticed the Registry Read only setting, how would I configure the whole registry to be read only? I know its not that necessary but since I came this far I might as well do this.

Rico
Advanced Member
Advanced Member

Posts : 118
Join date : 2010-06-18

View user profile

Back to top Go down

Re: Question

Post by ssj100 on 26/1/2011, 23:21

Yes, that's certainly what I observed in my testing too - IE seems to work fine. However, Firefox doesn't.

I think the browser does still "download" and render a web-site. It doesn't need to specifically download and write new files on the system to do this.

I don't think it's possible to configure the whole registry to be read only.

_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
avatar
ssj100
Administrator
Administrator

Posts : 1389
Join date : 2010-04-14

View user profile http://ssj100.fullsubject.com

Back to top Go down

Re: Question

Post by p2u on 26/1/2011, 23:37

ssj100 wrote:p2u, could you guide me on how to test DLL loading? I'll obviously need a DLL file to start. Thanks.
Hm... Compiling, programming, debugging? I think you'd better find or ask ready examples, no? Rmus must have something left, I think. Dll's can be readily downloaded from online resources, but if you have "copy"-protection on in AE2, the download will be blocked. How about the Firehole leaktest by Robin Keir? It's harmless and it's a nice place to start. It creates a dll on the fly: http://keir.net/firehole.html
Read the explanation to see what it does. The download link is in the middle of the page.

Paul

p2u
Valued Member
Valued Member

Posts : 211
Join date : 2010-12-14

View user profile

Back to top Go down

Re: Question

Post by Sponsored content


Sponsored content


Back to top Go down

Page 1 of 2 1, 2  Next

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum