Anti Executables are useless overtime

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

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

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

 

Kees1958,

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

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.....

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.

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.

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.

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

 

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.

 

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

Quote Blue:

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.
My setup ATM.

 

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.

 

Oh, i forgot:

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.

 

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.

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

 

Just wondering if you tried PowerShadow 2.8.2? If so, did it notify you stuff was written to sector 15?

SSM 2.3 or 2.0 Free?

Mike

 

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.

 

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

 

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

 

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

 

That quote was not by me, it was by @Kees1958.

Mike

 

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.

 

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.

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.

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

 

Kind of a Tripwire system... right?

Mike

 

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

 

Basically yes.

Blue

 

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.

 

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.
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. 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.
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.

 

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

 

herbalist,

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

 

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.

 

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

 

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