Anti Executables are useless overtime

[Kees1958]

Hi all,

That is a bold statement I would like to argue with you all.


An Anti-executable allows only white listed applications. Within a given time frame this provides excellent (the strongest?) protection. Problem arises when you are about to install a new program.

How to check whether it is a legitemate program with NO ZERO DAY THREAT?

A) Buy only programs which are marked safe by third party organisations (e.g. thru some form of security certification). They are tested officially so they should be fine. Problem is that most "home user" software providers in their battle to be competitive do not want to take the extra costs of these certificates.

B) Trust the white list that comes with the AE (note this marks all AE's like ProSecurity and SSM as useless, because they do not have that feature). Not a real hard safety test, but because the white list is of a security provider it is reasonable to asume they are safe and have the software tested mentioned in their white list. Still the procedure is misty at the least (how good have they tested, according to what method?)

C) Submit the file to a Norman Sandbox like service and hear what they have to say about the program

D) Buy only from known and trustworthy resellers and download sites. This becomes a bit dodgy because these sites test against known virusses and malware WHICH ARE BLACK LISTS. So you do not have any gaurantee that it does not contain a zero day threat. AND THAT WAS THE REASON YOU INSTALLED AN ANTI EXECUTABLE IN THE FIRST PLACE (and did not rely on black list security solely!).

E) Use common sense. What knowledge do you need? What criteria do you keep? What test does it pass? Now we are starting to get in a very dodgy area. Only Napoleon security equivalent like users consider this as the best option.

F) Run the program in a virtual environment. Then again how long does this program needs to behave and do not damage anything on you computer. How do you check what is changed? What tests does it has to pass. What about the rumours that malware is able to check whether it is in a virtual environment and does not release its damaging activities?


Conclusion safe steps are:
1. When an AE faces you with a question to trust or not you can not say yes on programs which have do not have a security certificate?
2. Only AE's with their own black and whitelist like Anti Executable, Online Armour and PrevX would qualify becaise they reduce the weak spot question (AM I ALLOWING THIS PROGRAM TO RUN?)
3. When you are faced with a such a question, the best practise would be to run this program in a virtual environment. So at best you will watch behavior for a few days/weeks/months? Against what criteria and measurement tools.
In essence running in VM is behavior watching, which could be best dealt with by behavior blockers. An average PC users can not beat the EQSecure configured as behavioral blocker, CyberHawk Pro (with registry and file protection custom rules), Sana Security First Response or A2 Malware V3.0

My claim:
AE's have a weak spot (like Achilles), due to this weak spot their protection force over a longer period can not match that of a behavior blocker, because one day or another you will add aprogram to your software list.

Most AE owners have not spend their money on a VM environment with a proper or smart behavior blocker, so their protection level over time is even worse than that of behavior blockers.

So having a policy management HIPS for every day protection (DefenseWall, GeSWall), reduces the risk of damage by unintendantly started code (same effect as AE, only covers ALL code from threat gates). For new installs I would be better of with a behavior blocker as a second line of defense (ideally in a VM environment).

;) Regards Kees

;D Come on I know there is a whole SSM/OA/AE/PS/DSA comunity living on Wilders? Give me something to chew on!

:P Still no reaction: AE's like ProSecurity, DSA and SSM provide fake security FEELING.

[BlueZannetti]

{QUOTE-> That is a bold statement I would like to argue with you all. <-QUOTE}Kees1958,

I'm not where you're going with this, but details matter - see below.

{QUOTE-> An Anti-executable allows only white listed applications. Within a given time frame this provides excellent (the strongest?) protection. Problem arises when you are about to install a new program.

How to check whether it is a legitemate program with NO ZERO DAY THREAT? <-QUOTE}Well, after day zero I guess it wouldn't be a zero day threat, now would it? It's a trivial example, but it does work to refrain from demanding to be always on the bleeding edge and poised to get cut. Not sure of something? Wait a bit.....

{QUOTE-> D) Buy only from known and trustworthy resellers and download sites. This becomes a bit dodgy because these sites test against known virusses and malware WHICH ARE BLACK LISTS. So you do not have any gaurantee that it does not contain a zero day threat. AND THAT WAS THE REASON YOU INSTALLED AN ANTI EXECUTABLE IN THE FIRST PLACE (and did not rely on black list security solely!). <-QUOTE}Actually, that might not be the only reason you installed an anti-executable, perhaps it's a measure to control installed executables on your children's machine or something similar.

{QUOTE-> 2. Only AE's with their own black and whitelist like Anti Executable, <-QUOTE}Faronics AE does not have a prepackaged whitelist, it is created dynamically on the machine based on applications installed while AE is disabled. Basically, it assumes a clean machine at start and that all installations executed while disabled are valid applications. That's not really an onerous constraint in many instances.

{QUOTE-> My claim:
AE's have a weak spot (like Achilles), due to this weak spot their protection force over a longer period can not match that of a behavior blocker, because one day or another you will add aprogram to your software list. <-QUOTE}with the counter statement that one day or another you won't block a malicious behavior or will block a critically needed behavior and the whole house of cards falls.

{QUOTE-> Still no reaction: AE's like ProSecurity, DSA and SSM provide fake security FEELING. <-QUOTE}Anyone can weave a specific scenario to get around any measure contemplated. Perhaps it involves ninja hackers skulking around in the dead of night, perhaps it is simple loss of focus by a user.

However, if you base structural decisions around elaborate low probability events, I'd say that you're focusing on the wrong questions and getting the wrong answers. The simple fact of the matter is that there are dozens of equally solid solutions to this problem and looking for the global best is misguided due to the fluidity of the challenge, an equally misguided approach is one which implements complex hierarchies of multiple discrete solutions with each add-on trying to plug the infinitesmal hypothetic holes in the remaining assembly. At least that's IMHO..., of course, for the masses I still believe an AV is generally the best first (and often last or next to last) step.

Blue

[Pedro]

I'll answer this to my reason for running SSM free. It is password protected, where i can "disconnect UI" and let anyone use the computer (policy is written), and blocks executables.
Blocking executables, why? Because of those odd situations where i could open for example (recent discussion) a spoofed gif file which is an executable, or a script that downloads an executable, and infects behind my back.

Put it simply: it's a visual confirmation that i run only what i want to run. Everything else is as usual: it's me on the chair, doing whatever. I cannot stop thinking. I must employ my criteria to download programs. Last resort: ask here at Wilders.

NoScript is actually the first Whitelist/ barrier i have. Same thing, it's me saying i want to run scripts on this website, or i want this video to run, nothing more. I don't say so, nothing happens.

And before these two, my firewall, to allow the trafic i need/ say so, no more.

And, compare this to the sandbox: what's the difference? You can't stop using your head, can you.

An anti-executable either fits your habits or not. You either can use it or not. Prevx certainly takes it a step further, but it's not just an AE.

I say the contrary: AE are most valuable over time. Over time my machine is more and more stable, with less "new" software. I chose my programs, and update them or trade for something else i already tried/ liked/ trust.

I can go on, but prefer to read your answer.

[Franklin]

No AVs here and running in a VM with Sandboxie the only other app installed in all besides the named VM.

Quote Blue:
{QUOTE-> IMHO..., of course, for the masses I still believe an AV is generally the best first (and often last or next to last) step. <-QUOTE}
To be honest I have to agree.

Cleaned up a young fellas laptop of an infection and after putting Sandboxie, Winpatrol and PS on his machine with instructions he was back after a month with the same infection using limewire outside of sandboxie, not in PS mode and allowed the auto start when Winpatrol threw up a warning.

So I had to concede and installed Active Shield.:ouch:
My setup ATM.
190822

[ErikAlbert]

Kees,
I have two whitelists :
1. Freeze Storage = whitelist of all objects of each installed legitimate software on my system partition.
My system partition = Windows + Applications and NO DATA.
My data partition = folders and data files.
Each time I reboot FDISR compares my ACTUAL system partition with my Freeze Storage and UNDOES any change until my actual system partition = freeze storage.
That is the expertise of FDISR : FDISR UNDOES CHANGES (= GOOD and BAD changes).

2. Anti-Executabe = whitelist of all executable objects of each installed legitimate software on my system partition.
If Anti-Executable fails or Look'n'Stop fails or DefenseWall fails, FDISR will UNDO any change during reboot.
In other words FDISR RECOVERS any mistake of my security softwares.

3. So I have a 99% REMOVAL tool and I only need security softwares that STOP the installation and/or execution of any infection during the period of two reboots.

In theory this is a foolproof security system, but NOTHING is foolproof, although it is very close to foolproof.
If I scan my Freeze Storage each month with online-scanners, I'm even closer to foolproof.

[Pedro]

Oh, i forgot:
{QUOTE-> At least that's IMHO..., of course, for the masses I still believe an AV is generally the best first (and often last or next to last) step.

Blue <-QUOTE}
I now agree with this. My time spent here and testing programs give me that impression. Not even Cyberhawk is usable.
From all thse programs, i can only imagine someone using Prevx2, but even that, on the second question, it's smoked out of the computer.
I mean, even the AV is seen as uncomfortable by many! So, bottom line is, you're either up to it or not.
I'm not going to advise anyone of any program besides the obvious. I don't need headaches explaining to someone who doesn't care.
I'll tell them to use Firefox or Opera, remove the exceptions in Windows FW (or allow as needed), and get Avast!. Don't open unknown attachments, visit the odd sites (how... lol). Anything else do it in another computer.. if you care.

[herbalist]

{QUOTE-> An Anti-executable allows only white listed applications. Within a given time frame this provides excellent (the strongest?) protection. Problem arises when you are about to install a new program. <-QUOTE}
The problem here isn't the anti-executable. It's the lack of a security strategy that addresses what is a common situation. Apps like SSM weren't designed to defend a system from user initiated installs. That's not their purpose. They're at their best when they can prevent changes to your system. Your system is at its most vulnerable during updates and installs. You're allowing unknowns (to you and your system) to run and changes to your system and registry to be made. The best way to deal with unwanted or potentially malicious changes done by software installs or updates is to make a system backup before you start the install. Always leave yourself a way to undo things. Malicious behavior is only part of the problem with every software install or update. A piece of bad coding or a conflict with an existing app can be just as damaging to your system as any malware.

Whenever I install new software or update an existing app, I start with making a system backup. The install process itself is monitored by InCtrl5, which records all file, folder, and registry changes made by the installer and stores it as a file. On my system, every software install, update, patch, etc was monitored by Inctrl5, starting when I formatted the drive. By doing this, I have records of where every file, folder, driver, etc came from and what app is responsible for it. FYI, Inctrl5 works just as well with web installs, including drive-by sites.

Both SSM and Kerio 2.1.5 stay on during software installs, whether the software wants it shutdown or not. This way, if the installer tries to connect out, I'm notified. I'm also notified about any new autostart entries, services, drivers, etc as they happen, giving me the option of killing the install if I don't like what I'm seeing. Software installs and updates are not the time to lower your defenses, whether the apps vendor likes it or not. Some may call it paranoid, but when an installer wants me to disable my AV or firewall, I start looking to see what they're hiding.

{QUOTE-> How to check whether it is a legitimate program with NO ZERO DAY THREAT? <-QUOTE}
Zero day threats or exploits are seldom put in a program installer. That would be a very inefficient way to use one. While it's not unusual to find adware or malware bundled into software installers, you're not likely to find unknown or new exploits used this way. They're generally used in malicious sites, e-mails, and other vectors that would reach a lot more people before the AV vendors can react. That said, it should be standard practice to scan all updates and installers with every tool at your disposal. I used to scan them with the 3 AVs I had on hand. Now I use VirusTotal in addition to the local scanners.

Kees, your statements in the first post point to a bigger problem that isn't being addressed here. Anti-executable apps like SSM are powerful, but they're not a total package or the answer to all situations. The same applies to frozen snapshots, backups, sandboxes, VMs, whatever. No matter how good any of these are, no one app can deal with all situations. An app that can undo every change made to your system doesn't help if your account passwords were stolen during that 2 minutes that your defenses were breached. On my PC for example, I trust SSM to prevent malicious code from executing, but I don't expect it to identify malicious code, or provide detailed control of internet traffic, or filter maliciously used Javascript. It's not intended to do those things. Users need to understand that no app or suite is a total solution. Each is part of a package. The more users understand the limitations of the security apps they use, the better they're able to assemble a secure strategy and choose and configure apps that will provide complete coverage.
Rick

[flinchlock]

{QUOTE-> Whenever I install new software or update an existing app, I start with making a system backup. The install process itself is monitored by InCtrl5, which records all file, folder, and registry changes made by the installer and stores it as a file. On my system, every software install, update, patch, etc was monitored by Inctrl5, starting when I formatted the drive. <-QUOTE}Just wondering if you tried PowerShadow 2.8.2? If so, did it notify you stuff was written to sector 15?

{QUOTE-> Both SSM and Kerio 2.1.5 stay on during software installs... <-QUOTE}SSM 2.3 or 2.0 Free?

Mike

[EASTER.2010]

{QUOTE-> Still no reaction: AE's like ProSecurity, DSA and SSM provide fake security FEELING. <-QUOTE}

Sorry. No such thing as feeling on my production units. System Safety Monitor (FULL) is a real-time interceptor/blocker. Have you ever tried to run any rootkits with SSM installed? If it's executable it better have mapped internally the $M core tables as well as circumvent the SDDT Table or at the very least replace some of those "hooks" to even get some quality air-time into the circuitry loop.

Nope. This it's not a feeling but a valid result of SSM stopping cold ALL executables signalling to the core system and passing that data/path to the screen per user for determining a decision to allow or deny.

Hit rootkit.com or surf some blackhat sites and pick up a few rootkit/hiders (DKOM even) samples for yourself to run at SSM.

I can't speak for AE but it's a sure bet that program is likely even more aggressive than SSM in some ways.

[Kees1958]

{QUOTE-> Kees1958,

I'm not where you're going with this, but details matter - see below.

1. Well, after day zero I guess it wouldn't be a zero day threat, now would it?

2. Actually, that might not be the only reason you installed an anti-executable, perhaps it's a measure to control installed executables on your children's machine or something similar.

3. Faronics AE does not have a prepackaged whitelist, it is created dynamically on the machine based on applications installed while AE is disabled. Basically, it assumes a clean machine at start and that all installations executed while disabled are valid applications.

4. With the counter statement that one day or another you won't block a malicious behavior or will block a critically needed behavior and the whole house of cards falls.


Blue <-QUOTE}

Okay here is my reply

1. AE's advertise protection against threats not yet known to your AV. With several AV's in the world and different update frequencies of user a threat does have a zero day status until most AV's and users have downloaded their updated black list. Nice word joke, but it does not hold

2. Okay this is legitemate reason to use AE's, not protection against unknown code.

3. That makes Anti Executable even worse. Do you realise what you are saying. Hey let's buy additional protection to my AV. But pitty pitty pitty as a starting point I have to rely on my AV (????), so why buy this additional security in the first place?

4. Yes is a problem of behavioral blockers, only Sana Security and Emsi are quite on their way to tackle this problem. The explination of A2 are so clear, you understand what the behavior is. Still it is a valid argument you make. It is only a weak debating trick, throw something else in the accusers face.

Therefore let me bring you back to the central question: how does a average PC is going to establish new code is save?

With the prerequisite that this determination process (whether it is good or bad) goes any further than the knowledge an AV will provide you?

Thanks for the reaction

Gr. K

[Kees1958]

{QUOTE-> Oh, i forgot:

I now agree with this. <-QUOTE}

Pedro I made the same journey, first adding AE's then polishing Behavioral Blockers, but I could not make EQS silent and fool proof the average digi-illiterate PC user behavior.

Still the following configurations survived:
PC 1 (the average digillitterate pc user): Antivir free, A2 Malware (with intelligent BB IDS) and DefenseWall (absolutely quite, wife is not complaining on DW)

PC2 (power user - my son): ANtivir free, EQSecure configured as prompt + block anomaly detector and GeSWall Pro

Regards K

[Kees1958]

{QUOTE-> The problem here isn't the anti-executable. It's the lack of a security strategy that addresses what is a common situation. The more users understand the limitations of the security apps they use, the better they're able to assemble a secure strategy and choose and configure apps that will provide complete coverage.
Rick <-QUOTE}

Herbalist I tottally agree.

Gartner or Forrester have a simple way of monitoring your overall strategy defense. It is a simple two dimensional table, it has recently been updated On the vertical diminsion the flow of events on the horizontal dimension the strength of the defense (from weak to strong = hardening, blacklisting, behavioral monitoring, white listing).

The flow of events start with

1. Network Access (firewall and IDS of protocol level)
2. Threat gates (typically the area's where Sandboxes like Defense Wall and GesWall on focus: P2P, e-mail, chatt, internet, DVD/CD/Floppy etc.)
3. Trigger (typically the area where AE's on focus, preventing the bad guys from starting)
4. Damage (to data, system/control files or other processes, typically the area of AV's and where a Behavioral blocker on focusses, because it allows a process to start or being saved to your PC, but only kicks in when it does something strange)
5. Exit/escape (data theft)

When you depend only on a AE, you have to realize that you voluntary lower your fences when installing/updating programs.

Reg K

[flinchlock]

{QUOTE-> {QUOTE-> Still no reaction: AE's like ProSecurity, DSA and SSM provide fake security FEELING. <-QUOTE} <-QUOTE}That quote was not by me, it was by @Kees1958. ;)

Mike

[besafe]

Well, no program can account for end user error.

I think Anti executeable type programs provide excellent protection myself. But no solution is fool proof.

[BlueZannetti]

{QUOTE-> 1. AE's advertise protection against threats not yet known to your AV. With several AV's in the world and different update frequencies of user a threat does have a zero day status until most AV's and users have downloaded their updated black list. Nice word joke, but it does not hold <-QUOTE}Kees1958,

Not all AE's are focused on threats. Some of designed to deal with unauthorized executables of any form. They could be "good" or "bad", it doesn't matter, if they are unauthorized they are denied.

{QUOTE-> 3. That makes Anti Executable even worse. Do you realise what you are saying. Hey let's buy additional protection to my AV. But pitty pitty pitty as a starting point I have to rely on my AV (????), so why buy this additional security in the first place? <-QUOTE}No, it doesn't. It simply means that their design objective is a little different than what you might be hoping to achieve. The primary installed base for Faronics AE is fixed configuration institutional PC's (educational sites, enterprise locations, public access PC's) where the installed application base is determined and managed at an institutional level. AE is similar to NAT routers and system restoration utilities - they have clear security implications in some contexts, but their primary design focus is not necessarily security in the same context we generally discuss here. Again, with Faronics AE, the implicit assumption revolves around infrequent installation of "known to be good" applications, much in the same way that the installation is to a system presumed to be clean. You might not agree with the design ethic, but it is internally consistent.

{QUOTE-> Therefore let me bring you back to the central question: how does a average PC is going to establish new code is save?

With the prerequisite that this determination process (whether it is good or bad) goes any further than the knowledge an AV will provide you? <-QUOTE}Unless an you're advocating that the average PC user acquire software reverse engineering skills that matches professional malware analysts, or that they place their trust in understanding in detail how an application interacts with the OS it is installed under (which means that they really should have a fairly profound appreciation of OS internals...), they should rely on the evaluation by professionals who do this full time - in other words, rely on the analytic database provided by an AV. Now, I'll grant you that many times you don't have to rely on this professional level advice, sometimes it is obvious. However, making the upfront presumption that it will always be obvious is fraught with danger.

Blue

[flinchlock]

{QUOTE-> The primary installed base for Faronics AE is fixed configuration institutional PC's (educational sites, enterprise locations, public access PC's) where the installed application base is determined and managed at an institutional level.
(...)
Again, with Faronics AE, the implicit assumption revolves around infrequent installation of "known to be good" applications, much in the same way that the installation is to a system presumed to be clean. <-QUOTE}
Kind of a Tripwire system... right?

Mike

[BlueZannetti]

{QUOTE-> When you depend only on a AE, you have to realize that you voluntary lower your fences when installing/updating programs. <-QUOTE}Kees1958,

This is always the case, even with valid security or other types of applications since they potentially may conflict with your current configuration and compromise it.

Blue

[BlueZannetti]

{QUOTE-> Kind of a Tripwire system... right?

Mike <-QUOTE}Basically yes.

Blue

[Pedro]

To complete with my experience with SSM: the first time i used it i got prompts i didn't know how to answer, lots of them. It had bugs that made it prompt me for the same things, other annoyances too. I uninstalled it, and got errors on boot (worst uninstall ever maybe). I had to edit the registry, no regcleaner did the job. I pratically banned it.

But then from discussions here, Herbalist's posts which get more consistent over time (congrats btw), on how he approaches it, the disconnect ui concept, Alphalutra1 is another such member that refered it, etc. Then the whole "if it can't execute.." premise, how infections start. So now i know what i want. I reinstall SSM, and i know how to use it. I got a stable version now, and surprise, it fits. :)

All i needed to know is where i'm going. What am i trying to achieve, concerning what threats. I'm only puzzled by the exploits (that don't envolve executables). Some refer them, but it's been vague. My strategy to make bold statements to incite replies ("your wrong because..") fails. Questions on these matters sometimes are not answered. I bet it's scattered in this forum though, somewhere. :)

[herbalist]

{QUOTE-> All i needed to know is where i'm going. What am i trying to achieve, concerning what threats. I'm only puzzled by the exploits (that don't envolve executables). Some refer them, but it's been vague. My strategy to make bold statements to incite replies ("your wrong because..") fails. Questions on these matters sometimes are not answered. I bet it's scattered in this forum though, somewhere. <-QUOTE}
When you say "exploits", I'm assuming that you mean code that's intended to exploit vulnerabilities found in software or operating system components, either newly discovered vulnerabilities or unpatched ones. It's a difficult subject to address when it's not about a specific type or individual exploit, especially if you're talking about future "zero day" exploits. It's like waiting to be attacked by an unknown adversary that uses weapons you've never before seen. Not an easy scenario to plan for.

The sad truth here is that most any code can be exploited. All code is vulnerable to something. There's little any of us can do that will stop some malware writer from finding a vulnerability and writing code to make use of it. That part is beyond our control. As long as there's money to be made, someone will find them.

Think of vulnerabilities as limited access points. A vulnerability is like a locked car that has the windows down a half an inch. It doesn't provide enough access to get a hand in but will allow a wire tool. The exploit code is like a homemade tool a thief sticks thru that crack, trying to grab the door lock. For this example, he can't break the windows without calling attention to himself and getting caught. The thief wants to quietly open a door to get to the wallet that's on the seat, which is like the financial data and account passwords stored on your PC. It won't fit thru the gap at the top of the window, but that's all he has to work with. If his skill and the tools he has on him are sufficient, he gets the wallet. If the cars owner (or the manufacturer) were smart, they already made his job more difficult. If the owner replaced the standard lock buttons with smooth ones that most things like clothes hangers can't grab or put some kind of obstruction in the way to block access to the lock button, his wallet is safe. Even though the thief found the vulnerability at the window top and exploited it with a homemade tool, he couldn't gain access to the locks.

The above analogy shows the kind of approach one can take to defend their system from being successfully exploited. With software and Windows operating systems, those half inch wide cracks are everywhere. They're just not obvious. That's the nature of the beast. The vulnerabilities will be there and will be exploited. You don't know where the next one will turn up. That's the bad news. The vulnerabilities and the code that's used to exploit them is where the problem starts, but is not usually what does the damage. A vulnerability is only a starting point, a small access that's of little value in itself, but one a malware writer hopes he can use to gain access to something better. This is where the user can set his defenses. A common goal of the writer of an exploit is Privilege Escalation. (http://en.wikipedia.org/wiki/Privilege_escalation)
Copied from Wikipedia:{QUOTE-> Privilege escalation is the act of exploiting a bug in an application to gain access to resources which normally would have been protected from an application or user. The result is that the application performs actions with a higher security context than intended by the application developer or system administrator. <-QUOTE}
Most of the time, the app or file that's exploited is not the target. The attacker wants to use it to gain access to something better. Look at an exploit on a malicious web page for instance. The attacker may try to use a browser exploit to get your system to download a much more powerful piece of malware. If your security apps don't allow that piece of malware to start and/or won't allow an autostart entry for it to be added to your registry, you're no worse off. Yes, your browser was successfully exploited, but the attacker didn't manage to make use of it.

The successful usage of exploits is primarily due to the way Windows is designed. For the most part, any app can run any other app. More than anything else, it's this behavior that's being exploited. Take this screenshot for instance.190862
I used Sea Monkey on Win98 for the image but most any user app will do. Notice both the item being selected and "Open" in the context menu. On my 98 box, I can use Sea Monkey to launch the command interpreter. It'll be somewhat different on XP, but if you run XP in administrator mode, check out what you can launch this way from different apps, not that malicious code would need to use a visible file menu. Some exploits make use of this idea to gain access to critical system executables. This is where apps like SSM can help protect you. Using the above image as an example, if I selected "Open" on that menu, I'll get an "Access Denied" message because Sea Monkey isn't allowed to parent Command.com. By limiting what apps and executable files can do, what processes they're allowed to parent, what is allowed to parent them, which can install drivers, set hooks, etc, you severely limit what an application can do to the rest of your system if it's successfully exploited. You also greatly increase the chances of the attack being detected. When the attackers hidden code tries to make a process access something it isn't allowed to, the "Access Denied" message tells you that something is going on that you wouldn't be aware of otherwise.

In order for an app like SSM to be effective against potential exploits, it needs to be set to its most restrictive settings. On my 98 box, that's the free version on Paranoiac setting. In addition, on the advanced properties for each application, the default parent and child settings are all changed to "Ask". So are the default settings on the libraries and drivers tabs of each rules advanced menu. Each executable can only parent (launch) or be parented by (launched, child process) the specific executables that it needs to for normal operations. I don't consider updating or patching to be normal operation. For me, those are administrative tasks and are treated as such in the rules. Most of the updaters on my system can't run unless the SSM UI is connected. I consider SSM to be in user mode when its UI is disconnected and in administrator mode when it is connected. Most of the time, it runs in user mode. All administrative functions and executables are blocked from running when SSM is in user mode. Firewall administration isn't allowed unless SSM is in admin mode. This is the most time consuming way to configure SSM and does result in the most prompts during setup, but the control it gives you is tight. When its UI is disconnected, all those "Ask" settings on the advanced properties screens get treated as "Block", because SSM doesn't ask when its UI isn't connected.

It's this ability to undo that insecure "anything can run anything else" behavior of windows that makes SSM valuable against exploit code. An attacker doesn't want normal functions. They want administrative or command access and try to use apps that don't have it to access ones that do.

There are more things users can do to reduce the risk of apps or system components being exploited that are outside the subject of this thread but are just as important. Topping this list is reducing your attackable surface. That means blocking access to some apps and limiting access to others to and from the internet. If an app doesn't absolutely need to receive incoming traffic (server rights) block it. Many apps and system components don't need internet access at all to function, but will ask for it. If you don't need it, shut it off. Get control over Windows services and shut down what you don't need. Many services open ports, which are potential points of attack. Close as many as you can. Don't just hide them with a firewall but actually close them. Give each only what it needs to work, no more. If an attacker can't reach an app that he has exploit code for, that code is useless.

Filter out malicious web content whenever possible using the tool that fits you. This is being covered in several other threads. Make sensitive data like account numbers and passwords hard to access. Use a separate browser for financial data or set up a separate user profile in the browser if it has that feature. Put what an attacker might want out of reach.

Rick

Sorry for being so long winded.

[poirot]

Sorry?? thanks A LOT, Herbalist!
I always learn something new from your writings, both theoretically and practically.

[wat0114]

herbalist,

I nominate your last post to be posted as a sticky in this forum. An excellent and very informative write-up :thumb:

[Pedro]

{QUOTE->
In order for an app like SSM to be effective against potential exploits, it needs to be set to its most restrictive settings. On my 98 box, that's the free version on Paranoiac setting. In addition, on the advanced properties for each application, the default parent and child settings are all changed to "Ask". So are the default settings on the libraries and drivers tabs of each rules advanced menu. Each executable can only parent (launch) or be parented by (launched, child process) the specific executables that it needs to for normal operations. I don't consider updating or patching to be normal operation. For me, those are administrative tasks and are treated as such in the rules. Most of the updaters on my system can't run unless the SSM UI is connected. I consider SSM to be in user mode when its UI is disconnected and in administrator mode when it is connected. Most of the time, it runs in user mode. All administrative functions and executables are blocked from running when SSM is in user mode. Firewall administration isn't allowed unless SSM is in admin mode. This is the most time consuming way to configure SSM and does result in the most prompts during setup, but the control it gives you is tight. When its UI is disconnected, all those "Ask" settings on the advanced properties screens get treated as "Block", because SSM doesn't ask when its UI isn't connected.
Topping this list is reducing your attackable surface. That means blocking access to some apps and limiting access to others to and from the internet. If an app doesn't absolutely need to receive incoming traffic (server rights) block it.
(...)
Filter out malicious web content whenever possible using the tool that fits you. (...) <-QUOTE}
That's basically how i'm handling it. Learning mode was a short period. I answer prompts with parent-child specs, etc. I then move on and one by one, i set the process to advanced by setting default actions to ask. It then prompts me again at my pace (as i turn them to advanced), and i set the rules to match exactly what i need to run. Block IE7 because it's in ask (discon. ui blocks it etc.).
Then there's NoScript and all that. But to me, apart from all that tightening, i face it as an execution blocker. It gets simpler that way to start.

[Kees1958]

{QUOTE-> Sorry. No such thing as feeling on my production units. System Safety Monitor (FULL) is a real-time interceptor/blocker. Have you ever tried to run any rootkits with SSM installed? If it's executable it better have mapped internally the $M core tables as well as circumvent the SDDT Table or at the very least replace some of those "hooks" to even get some quality air-time into the circuitry loop.

Nope. This it's not a feeling but a valid result of SSM stopping cold ALL executables signalling to the core system and passing that data/path to the screen per user for determining a decision to allow or deny.

Hit rootkit.com or surf some blackhat sites and pick up a few rootkit/hiders (DKOM even) samples for yourself to run at SSM.

I can't speak for AE but it's a sure bet that program is likely even more aggressive than SSM in some ways. <-QUOTE}

Easter you added first defense to you software list, anything else added lately. How usefull was SSM when you lowered your defenses?

See post 10 and 12 of this topic

[Kees1958]

{QUOTE-> Kees1958,


Unless an you're advocating that the average PC user acquire software reverse engineering skills that matches professional malware analysts, or that they place their trust in understanding in detail how an application interacts with the OS it is installed under (which means that they really should have a fairly profound appreciation of OS internals...), they should rely on the evaluation by professionals who do this full time - in other words, rely on the analytic database provided by an AV. Now, I'll grant you that many times you don't have to rely on this professional level advice, sometimes it is obvious. However, making the upfront presumption that it will always be obvious is fraught with danger.

Blue <-QUOTE}

See first post in this topic. That is my point AE's are effective until you are up to add a new program. Code from unknown source is checked by an AV, so all zero day threats will pass. Security is as strong as the weakest link in the chain. Therefore I argue, although security theory says that behavioral blockers are weaker in theory than whitelist AE, but stronger than Black lists. Using a behavioral blocker gives more consistent level of security also when you install a new program.

Regards K

[Kees1958]

{QUOTE-> The vulnerabilities and the code that's used to exploit them is where the problem starts, but is not usually what does the damage. A vulnerability is only a starting point, a small access that's of little value in itself, but one a malware writer hopes he can use to gain access to something better. This is where the user can set his defenses. A common goal of the writer of an exploit is Privilege Escalation. (http://en.wikipedia.org/wiki/Privilege_escalation)
Copied from Wikipedia:
Most of the time, the app or file that's exploited is not the target. The attacker wants to use it to gain access to something better. Look at an exploit on a malicious web page for instance. The attacker may try to use a browser exploit to get your system to download a much more powerful piece of malware. If your security apps don't allow that piece of malware to start and/or won't allow an autostart entry for it to be added to your registry, you're no worse off. Yes, your browser was successfully exploited, but the attacker didn't manage to make use of it.

The successful usage of exploits is primarily due to the way Windows is designed. <-QUOTE}

Rick first thanks for joining this discussion.

You and blue are fueling evidence for the basic statements I am making:

1. An AV although blacklist (see post 12 in this topic) is problably the most consistent and reliable level of security for the average PC user.

2. A user friendly behavior blocker (like A2) does provide a sustainable level of defense (also when installing a program, because behavioral blockers are directed to minimising damage through abnormal behavior).

3. A user friendly policy/rights/privaliges manager ('Sandbox') is as effective as the average AE of preventing malware from damaging your system. A policy manager like DefenseWall is so simple to use. In stead of focussing on preventing code to starting it lowers the right of these possible 'carriers' of exploits (like your webbrowser) or files created by these carriers (e.g. limewire downloads).

So my comment is: A lot of experienced members of Wilders nearly always advice to go for the best (often a AE) to new members. This 'best' is true as long as they do not install new programs.

When you use a AE, you should like you check with Inctrl5 what a program does when you install it for the first time on a Virtual Machine.

When this practise is above your head using an AV + Behavior Blocker and Policy Right Manager gives more overall and consistent protection.

Regards Kees

[bellgamin]

{QUOTE-> 2. A user friendly behavior blocker (like A2) <-QUOTE}I have not seen A2 refer to itself as a "behavior blocker" but rather as an "Intrusion Detection System" (IDS). I do not make this comment as a *gotcha!* but because I am truly seeking to learn ...

What exactly is the difference between (1) behavior blocker, (2) HIPS, (3) IDS & (4) anti-executable?

and

WHICH of those categories is most descriptive of A2?

[EASTER.2010]

{QUOTE-> Anti Executables are useless overtime <-QUOTE}

If thats the case then my machine would be a total mess by now.

Courtesy ONLY system safety monitor/power shadow/kerio 2.15, for many months now this trio has afforded me as a malware researcher/hunter to hit any drive-by site as well as launch the fiercest of rootkits locally without sustaining any repercussions whatsoever and that's chiefly been directly related to System Safety Monitor's ability to 100% SUSPEND in mid-air if you will, any virus/trojan executable and pass data/path on to my attention where i can easily scoop (Copy) up these malicious creations and forward them on to vendors as well as run them locally and follow what they change on the system so they can be categorized as either severe or lesser type threats.

Useless OverTime? Not from this end in what i've experienced over time.

Regards EASTER :)

[Peter2150]

I would have to agree with Easter.

Kees your assumption that AE's become useless is only true if you also cease using your head.

If you download some program from a garbage site and install it, yep you are right. But using your head if you download a program from a trusted source, then your risk from installing a new program is nil, and the AE's work just fine.

Obviously if you are going to play with risky stuff you better take additional steps.

In my opninion AE's only become useless when common sense has been uninstalled.

Pete

[EASTER.2010]

Another good point there Kee's, that Peter2150 points out.

How many times have you installed a perfectly good program but it was hard coded to RUN AT START-UP and you don't need it to do that. In case anyone needs to know, i always use HijackThis to "FIX" those start-up entries and that's the end of that. I do it all the time as in routine.

Also like mentioned you can get hold of what you perceive as a safe program but for whatever reason the server's files were compromised and so some clever witted gent decides to emplant a nice little virus into the program. Still happens.

[wat0114]

{QUOTE-> Code from unknown source is checked by an AV, so all zero day threats will pass. <-QUOTE}

Why is it an unknown source? If we are not expecting an executable to launch especially after visiting an unknown source then of course common sense dictates we block it after an AE warning. If we are downloading code from a crack or warez site, then we are not willing to pay for it and we are also willing to take the chance that it is harmless code so we allow it in hopes of gaining free software. Tough luck if it screws your machine, because we are looking for something for nothing.

If you want software and you are willing to pay for it then you will acquire it from the proper source and will not worry about it infecting your machine when you install it. The purpose of the AE is to alert on unexpected executable launches, as well as for controlling the behaviour of parent-child activity. There is a real educational benefit to using the AE as long as we read and try to understand the alerts. It is an added layer of defensive security that will alert on activity that an av might miss.

[Kees1958]

{QUOTE-> 1. There is a real educational benefit to using the AE as long as we read and try to understand the alerts. 2. It is an added layer of defensive security that will alert on activity that an av might miss. <-QUOTE}

Ad1.
Yes AE provide a real edductational benefit, but how many are willing to know that level of detail (using a PC as a consumer product to do other things, like surfing, downloading music files, etc)

Ad2.
How different is that of a behavioral blocker? Only when installing programs a behavioral blocker keeps working and attending you on anomalies. The weak point of behavioral blockers is the clearness of their information pop-ups (e.g. EQSecure only explains what happens technically, but A2 gives a sound explanation to what threat this behavior might relate to) and the smartness of their rules (therefore again Emsi with A2 and Sana Security, score better than for instance CyberHawk).

regards K

[Kees1958]

{QUOTE-> Another good point there Kee's, that Peter2150 points out.

How many times have you installed a perfectly good program but it was hard coded to RUN AT START-UP and you don't need it to do that. In case anyone needs to know, i always use HijackThis to "FIX" those start-up entries and that's the end of that. I do it all the time as in routine.

Also like mentioned you can get hold of what you perceive as a safe program but for whatever reason the server's files were compromised and so some clever witted gent decides to emplant a nice little virus into the program. Still happens. <-QUOTE}

Thansk Easter could be my arguments on Watt0114's post

Regards Kees

[Peter2150]

This argument is like the chicken and egg and can go on and on and on and on, and in the end prove absolutely nothing.

I am not a carpenter and am border line useless with a hammer. Does that mean a hammer is useless over time. To me yes, to a carpenter no. Same thing is true of AE's. True now and will still be true a thousand posts later.:D

Pete

[trjam]

Unless you use the hammer, to hit the chicken in the head. Then it ends.::)

[wat0114]

{QUOTE-> Ad1.
Yes AE provide a real edductational benefit, but how many are willing to know that level of detail (using a PC as a consumer product to do other things, like surfing, downloading music files, etc) <-QUOTE}

Does it matter how many are willing to know? All that really matters is an AE might be the right fit for those in this category.

{QUOTE-> Ad2.
How different is that of a behavioral blocker? Only when installing programs a behavioral blocker keeps working and attending you on anomalies. The weak point of behavioral blockers is the clearness of their information pop-ups (e.g. EQSecure only explains what happens technically, but A2 gives a sound explanation to what threat this behavior might relate to) and the smartness of their rules (therefore again Emsi with A2 and Sana Security, score better than for instance CyberHawk).
<-QUOTE}

I can't answer this because I have not used any of those behavioral blockers, unless the component control and/or anti-leak options in Outpost fw Pro count as behavioral blockers. They might to some extent. All I can say is that there are so many security choices suitable for different folks. Some are comfortable with AE's, some are comfortable with behavioral blockers, some with firewalls. Some with all or a combination of the above. We could throw in sandboxes and antiviruses into the mix too.

I would agree 100% that an AE is useless if the person responding to the prompts simply ok's everything just to get on with their installs or surfing, because they don't understand the prompts, nor care about them because they are too excited about trying out their new software or loading the activex so they can view the girly movie. The same could be said about behavioral blockers, firewalls, and, to some extent, antivirus, though I would think a virus warning might be taken more seriously, even by those who lack the knowledge or patience. Besides,aAntivirus apps are generally installed by default on new machines and have been around for eons.

In use by the right person, any security app has a certain degree of usefulness. In the wrong hands, they all become that much more useless.

[Kees1958]

{QUOTE-> This argument is like the chicken and egg and can go on and on and on and on, and in the end prove absolutely nothing.

Pete <-QUOTE}

Then return the my first statement and I will change the question

On this forum most members use AE's to have an additional layer against zero day threats. My claim is that this is (only) true as long as you keep the system stable (no new code).

The defense is as strong as the weakest link. So what counter measures do AE fan's use to determine whether new code is 'safe'.

I think Rick (Herbalist) made clear to me that he checks new code in depth

Regards K

[Pedro]

{QUOTE->
On this forum most members use AE's to have an additional layer against zero day threats. My claim is that this is (only) true as long as you keep the system stable (no new code).

The defense is as strong as the weakest link. So what counter measures do AE fan's use to determine whether new code is 'safe'.
<-QUOTE}
I think what you need to clarify is where is it any different than any other program.

Opening documents, pdfs, jpegs, movies, etc., i am not expecting any executables. Even if i don't disconnect UI, any prompt is easy to answer: Deny. But i do disconnect it.

Anything i install intentionally, unless the AV gets something, even a BB will give you a hard time interpreting the results. A-Squared seems to be in the right direction, yes, but i did have FP's.

Any solution you employ, will do little if you intentionally install something.
Like the man (http://www.pc-help.org/www.nwinternet.com/pchelp/security/advice.htm) says,
{QUOTE-> Run only programs you have good reason to trust and from a known source. Once you fire up a process, your system is in the hands of whoever wrote it. Would you invite just anyone to drive your car? Neither should you let just anyone run your computer. <-QUOTE}
To me, a defense is more and more about what i didn't ask for (default deny).
I think this is what the others are saying too.
An open discussion is if something like a sandbox will provide more protection than execution interception, or parent-child control. Anything else is what i intentionally did.

[herbalist]

Kees, About the only way your "useless overtime" argument hold up is if it's in reference to a typical user who knows nothing about how a PC works. To one of them an app like SSM is useless, but so is every piece of software that doesn't figure out everything for them. If their PCs were cars, they wouldn't be able to get a drivers license because they couldn't pass the test. The logic you're using would call the car useless because those individuals couldn't drive it.
{QUOTE-> I would agree 100% that an AE is useless if the person responding to the prompts simply ok's everything just to get on with their installs or surfing... <-QUOTE}
I'd disagree. The AE is doing its job. It's that persons decision making that's useless.

You can use whatever standard you want, including vendor supplied white lists. I'm glad SSM doesn't come with one. The white list of sites that originally came with NoScript was one of the main reasons I stopped using it. I don't want some vendor telling me who or what I should trust. Just because I'm running windows doesn't mean I should trust Microsoft. I don't.

As soon as you start depending on a vendor maintained whitelist, you're back to the same problem that exists in AVs blacklists. Never complete, never up to date. Not reliable. Nothing gained. My application whitelist contains the executables for the applications and windows components on my system that are necessary for normal usage, no installers, no updaters, no unnecssary windows components. As long as SSM stays in user mode, (disconnected UI) that is all that can run. Useless? Not even!
Rick

[wat0114]

{QUOTE->
I'd disagree. The AE is doing its job. It's that persons decision making that's useless. <-QUOTE}

Very true. I should have worded it better, but that is basically what I meant :)

[Peter2150]

{QUOTE-> So what counter measures do AE fan's use to determine whether new code is 'safe'.



Regards K <-QUOTE}

Common sense. If I download from an unsite, I assume it's bad and act accordingly. If I open a box of software from Microsoft which I get as a Microsoft partner, I assume its fine, which it is. If I download from one of the sites whose programs I beta test, I assume it's safe but might be buggy. When I update my accounting program, and get their CD, I assume it's safe. etc.

Just good common sense. It has worked fine. What the AE's alert me to is something unexpected.

Pete

[glentrino2duo]

I started a somewhat similar thread a while ago here: http://www.wilderssecurity.com/showthread.php?t=165308

I'd say AEs might seem useless in the meantime, but they can really be useful over time. :)

[lucas1985]

{QUOTE-> So what counter measures do AE fan's use to determine whether new code is 'safe'. <-QUOTE}
In a relatively static machine, you shouldn't be expecting new executables. Otherwise, there's a good amount of tools/practices/questions to verify the legitimacy of a file with low chances of making mistakes.
- Did I request that file?
- The file was downloaded/written to disk with my consent?
- From where/who did I get that file?
- Checksum verification (if provided).
- Which kind of file (http://www.wilderssecurity.com/showthread.php?t=176969) is it?
- May it contain hidden executables and/or shellcode/exploits (http://www.wilderssecurity.com/showthread.php?t=177908)?
- On demand scanning with AV/AT/AM.
- Imput from Jotti/Virustotal.
- Imput from automated experts (i.e. Norman Sandbox, Sunbelt Sandbox, PC Tools Expert).
- Imput from the viruslab (if possible/feasible).

- Execute in a restricted environment (VM, sandbox, manual checking of scripts in text editor, doc viewing without macros/scripts (http://www.wilderssecurity.com/showthread.php?t=158624)).
- EULAlyzer, TCPView, firewall prompts/logs, install monitor.
- Etc.