Anti-Executables - List of

Good point, thanks.

 

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

 

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.

 

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

 

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

 

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

 

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

----
rich

 

Some information on WMF from Dec/2005:

Update on Windows WMF 0-day
http://isc.sans.org/diary.html?storyid=975

----
rich

 

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

 

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.

 

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

 

NO! But Winsonar is fun!

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

Dave

 

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.

 

Totally understand, and point taken..

 

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

 

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.

 

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.

 

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

 

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.

Sorry, I don't know of any except that one which has been mentioned by others.

Can you give me an example of such an exploit?

thanks,

----
rich

 

I think you'll be left waiting for that example

 

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... https://www.wilderssecurity.com/showthread.php?t=252508

 

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.

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

 

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.

 

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:

​

Same result if attempting to open from the Command Line:

​

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