ZeroVulnerabilityLabs ExploitShield

Thanks @vojta


@ZeroVulnLabs
Have you take a look to this report?
-https://secunia.com/?action=fetch&filename=secunia_yearly_report_2011.pdf-
You can find there the most used software and if they are "exploitable" or not

I have seen that some or them are missing like
1 ms Microsoft XML Core Services (MSXML) 100% 1 0 Yes
3 ms Microsoft .NET Framework 99% 5 10 Yes
21 tp Adobe AIR 52% 38 28 Yes
...

Do you plan to include those in a future?

 

Good news, Trusteer has just notified me that they will white-list ExploitShield's processes.

 

Thanks for the update

 

Thanks for everything votja!!

 

Hi all
have just come across this...
not very flattering
http://blog.trailofbits.com/2012/10/29/ending-the-love-affair-with-exploitshield/

EDIT - apologies if this has already been posted - had a quick scan through and didn't see it.

 

The answer: http://www.zerovulnerabilitylabs.com/home/the-objective-of-exploitshield-beta/

 

HA!!
ok thanks guest
Don't know how I missed that
glad to see this rebuffed, ES is now one of the first things I install/recommend now I have seen how effective it is in the "real world"

 

Even with the corrections the the article makes some good points. it is worth a read.

I like the idea but implementation detail is very important

 

I just found that Webroot SecureAnywhere is blocking exploitshield64.dll from being injected into Firefox (looking in ProcessExplorer). However, ExploitShield still shows 1 program protected.

I tried setting the ES program files and the DLLs to Allowed in WSA, but that doesn't seem to help.

When WSA is shut down, Firefox does load the DLL.

I just opened a support ticket with Webroot. Strange that ES would still report the protected program.

It would probably be worth adding something in the browser UI to indicate that ES is protecting that app.

 

Thanks!!

Please keep us up-to-date here on what response you get from them.

 

Agreed. ES is virtually invisible unless it gets called into action, especially if the tray icon disappears, which unfortunately is a problem on my 64 bit system (not just with ES). It would be great to have a browser plugin that showed status.

 

Note: ES is not compatible with Webroot Secureanywhere. The injection shows it worked, ES reports it working, but it actually isn't working. I believe someone else in this thread noted this.

It does this for Chromium as well as Firefox. ES might want to get a hold of WR to report this issue.

 

The ExploitShield.dll does show up when the Firefox plugin container is running. ExploitShield does not show in Process Explorer when the plugin container is not running and WSA is running.
Allen

 

I reckon that it should show two shielded processes when working normally: One for Firefox and one for the plugin container. WSA must be protecting firefox.exe but not plugin-container.exe

 

It disappears too on XP SP3 while in a limited user account. As a workaround, I have a shortcut to the log "exploitshield" inside the installation folder. This way I can check what's happening from time to time.

 

I was wondering about what happens to the executables/payload that ExploitShield stops? I know there's a Files quarantined in the GUI, but does it really quarantine them, or by that it's meant that it blocks and deletes them?

 

The ones it can physically quarantine are sent to %ProgramFiles%\ZeroVulnerabilityLabs\ExploitShield\Quarantine directory with modified names and extensions to make them harmless. If they are new, never seen before payload based on MD5, they are also uploaded to the real-time information feed:
http://www.zerovulnerabilitylabs.com/home/services/security-intelligence/

There are however some exploit payloads which cannot be physically be moved as they are either memory-only attacks or some other techniques.

 

Sorry guest just realized I forgot to respond to your question.

The way ExploitShield works, any vulnerable library which is loaded within the browser (IE, FF, Chrome, etc.) is protected by ExploitShield. It does not matter if its Flash, Shockwave, Java, MSXML, Adobe plugin or whatever. In fact when the MSXML IE vuln came out (CVE-2012-1889) we made a video of a 2-month old ExploitShield prototype against the newly discovered vuln exploit to show how ExploitShield can protect against zero-days, without relying on signatures or white-listing:
http://www.youtube.com/watch?v=VYlS8fgsBXs

As another example of ES vs zero-days, here's another video of a 5-month old ExploitShield prototype against CVE-2012-1875 (IE zero-day) on the day the exploit was made public:
http://www.youtube.com/watch?v=uKZgDcOL_Ic

 

OK. Thanks the clarification.

-edit-

Regarding the payloads MD5, in addition to being sent to the information feed, will they (the MD5s) also be added to ES logs?

 

After taking a look at my system remotely, they found that they could reproduce it in-house, and so they're working on it now.

In the meantime you (we) can choose to disable WSA's protection for Firefox by setting the browser to Allow in the list of Protected Applications under Identity Shield. So it's just a question of which you'd rather have protecting the browser until they get a fix.

 

No, the MD5 are not shown on the logs in order to not confuse non-technical users. Technical users can get the files themselves from the disk and process them any way they want (send to VT, get a checksum, etc.).

Thanks for all your help Notok!!

 

I've also experienced the Windows Media Player problem which starts when ExploitShield is installed and goes back to normal operation once ExploitShield is removed from the system.

I have 2 systems, both Win7 x64 Ultimate. One does not exhibit the problem while the other does.

On the system with the WMP issue, I noticed strange things happening with the view of my music in WMP. All the music disappeared even though it still existed on the disk. Things went downhill from there to where the app would crash when I attempted to open WMP. I would get this error in the Event Log every time:

Faulting application name: wmplayer.exe, version: 12.0.7601.17514, time stamp: 0x4ce7a485
Faulting module name: SHLWAPI.dll, version: 6.1.7601.17514, time stamp: 0x4ce7b9e2
Exception code: 0xc0000005
Fault offset: 0x00013898
Faulting process id: 0x1b54
Faulting application start time: 0x01cdd276eb4e4840
Faulting application path: C:\Program Files (x86)\Windows Media Player\wmplayer.exe
Faulting module path: C:\Windows\syswow64\SHLWAPI.dll
Report Id: 2a565c08-3e6a-11e2-ac0b-005056c00008

Any ideas as to what could be going on? I am willing to experiment with this if that would help.

Thanks.

 

Thanks gor testing Skiaz!

We think this might be due to some incompatibility with other software, probably security software. Could you PM or email me a DDS log to support at zerovulnerabilitylabs dot com?
http://download.bleepingcomputer.com/sUBs/dds.scr

 

DDS log sent via email.

 

Did not receive them. Can you please re-send and double-check the email address?