The objective of ExploitShield beta

UPDATE: the Trail of Bits post is technically incorrect. Read the end of this post for a clarification.

We released ExploitShield in its current beta form in order to provide the community with a free utility they could start using as part of a layered approach (users still need antivirus and other security mechanisms) to fight against the plague of exploit kits which are infecting thousands of users every day. And it seems to be doing its job as evidenced by our real-time feed of exploits being blocked in the wild.

Since the early ExploitShield prototypes and every day since then we have exposed ExploitShield to every single exploit kit URL in-the-wild we could get our hands on. And it has successfully blocked every single one of them. In addition we have exposed 5-month old prototypes to a handful of Internet Explorer and Java zero-day vulnerability exploits and it has also blocked all of them as evidenced in our videos. In total we have thrown well over 5000 different in-the-wild and canned Metasploit exploits during testing and all of them were blocked successfully by ExploitShield. At least to me that seems like a very good real-world improvement if compared with other exploit testing results reported by independent testers.

But in its beta form we are the first to realize that ExploitShield still has shortcomings and we are working on improvements all the time. After all beta versions serve not only to find and fix bugs but also to proof technical concepts and that is exactly the objective of ExploitShield beta. However since we released ExploitShield articles such as those by Trail of Bits have been published which publicize bypasses. They are really nothing new and most of it has been covered before already. After all the objective of the ExploitShield beta is not to be a final, unbreakable and in-penetrable solution but rather to protect users against the exploits currently in-the-wild. I explain the improvements we have been working on in relation to the the main gripes of Trail of Bits which are the following:

Security by obscurity. The article makes it sound as if ExploitShield relies on security by obscurity but this is obviously not the case. It is not hard to see how ExploitShield works if one were to look, as evidenced by the article. This is not the first post to have described to some degree how ExploitShield works. By releasing ExploitShield publicly we were aware that it was going to be scrutinized and analyzed in-depth and articles like these would come to light. Nonetheless we decided to release it to the public to (a) provide a much-needed install-and-forget solution for the benefit of the community and (b) get to know these techniques to better protect against them in the future and making the lives of the bad guys that much harder. A true “security by obscurity” approach would have been to keep ExploitShield private instead of releasing it publicly.

In its current beta form ExploitShield works by hooking user-land functions and this can be bypassed by calling another function to achieve the same functionality. Again this is not news as it has been written about before. Of course we are aware of this shortcoming in the beta and for future releases we have been working for some time now on hooking lower to the system to provide more comprehensive protection. Again, ExploitShield will evolve and adapt to protect against exploits in-the-wild as needed. It its current form ExploitShield still protects against all the exploits in-the-wild that we expose it to on a daily basis.

The article goes on mentioning interception implementation problems in the IOCTL interface, hook logic, etc. which are minor issues to be expected of an early beta. Of course these and other issues need to be improved prior to a general non-beta public release, especially in a Corporate Edition release. However going as far as saying that ExploitShield introduces another exploit vector is a bit of an exaggeration. Obviously having ExploitShield installed, even in its beta form, provides much more protection than not having it. This is a fact which for some reason the author fails to mention.

The author also claims that ExploitShield is “a time capsule containing the best host-based security technology that 2004 had to offer” which is again incorrect. While HIPS programs started using function hooks in 2004, the interception mechanism has nothing to do with the exploit blocking intelligence that is implemented in ExploitShield. Evidence of this is that until now no other security program has been as effective in stopping exploits in the wild as ExploitShield.

Finally the author claims that the success of ExploitShield is an impossibility as any defensive mechanism is dependent on obscurity and once attackers analyze it then it can be bypassed. Of course such a generalist comment is true of ANY security software and proof thereof are the hundreds of thousands of new malware variants released everyday which bypass anti-malware products. But that does not mean that everybody should stop using antivirus or other security products. Implementing a layered approach to security and knowing the limitations and shortcomings of each layer is still the best approach, and will be for a long time, to raising the bar against intrusions and infections. At the end of the day no security system is 100% and the real value of a security technology is measured hand in hand with the company behind it, its continued support of the technology and its customer service.

 

UPDATE:

We want to clarify some parts of the Trail of Bits post which are technical incorrect with two examples. It is not our intention to get into any prolonged discussion but we do want to defend our work especially when it is being misinterpreted and misrepresented.

1) Are the page permissions of the address RX (read-execute)?
This is not true. The following is the actual ExploitShield code where the comparison takes place:

VirtualQuery ((LPVOID)dwMemory, &mbi, sizeof(MEMORY_BASIC_INFORMATION));
if(mbi.AllocationProtect == PAGE_READWRITE)

In the case of Trail of Bits while reversing the ExploitShield.dll library they probably found this:

The comparison is done against the value 0×4 (CMP DWORD PTR SS:[EBP-18], 4) and that’s why their conclusion is totally incorrect because this value belongs to PAGE_READWRITE (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx).

It is possible that Trail of Bits has mistaken it with 0×40 which does equal to the PAGE_EXECUTE_READWRITE value mentioned in their article, but that has nothing to with our analysis and even less to do with our detection logic.

As you well know there are exploits that do not use ROP and which affect mainly XP machines where unfortunately the attacked program does not have DEP activated. Under these circumstances for the programs we protect, evaluating if the page which has called certain function comes from a PAGE_READWRITE memory area is a completely valid behavioral detection.

2) Is the address located within the bounds of a loaded module?

This logic as explained in their post is also incorrect since that is not the objective of ExploitShield. Rather we look for which loaded module the call comes from. With this explanation anybody can now probably get a good idea of the logic used in the ExploitShield analysis and the behavior of certain payloads.

“If either of these two tests fail, ExploitShield reports that it has discovered an exploit!”

Now I understand this comment. Initially we didn’t understand it because in addition to the checks mentioned above there are more things being considered in the equation. But I understand how based on a misunderstanding of how ExploitShield really works Trail of Bits arrived at this wrong conclusion.

– David Sanchez Lavado