06 May 2008 | 6,149 views

Patch Window Shrinking – Semi-Automated Reverse Engineering

Check Your Web Security with Acunetix

As far as I know this has been happening for some time, sometimes a patch comes out for a vulnerability that many people don’t know about (including the hackers) so they will see what problem the patch fixes (possibly through reverse engineering) then develop an exploit to leverage on the flaw.

It seems things are a little more advanced now with some semi-automated tools to do the job.

The length of time between the development of security patches and the development of exploits targeting the security holes they address has been dropping for some time.

Hackers exploit this period of time – the so-called patch window – to launch attacks against unpatched machines. Typically, exploits are developed by skilled hackers versed in the arcane intricacies of reverse engineering.

However, hackers have now begun using off-the-shelf tools to at least partially automate this process, a development that might lead to exploits coming out hours instead of days after the publication of patches.

It certainly does make the time between patch and exploit a lot faster, and this is fairly new. Thankfully someone has taken it upon themselves to research this subject further and educate us all about it.

It’s a scary thought having a working exploit a few minutes after receiving a patch! As you know many people don’t keep patches up to date, and those that do might only apply it after a few days so it gives the bad guys a dangerous windows in which they can mass-exploit people.

Security researchers at Berkeley, the University of Pittsburgh, and Carnegie Mellon have launched a research project investigating the approach [PDF], which relies on comparing the configuration of patched and unpatched machines.

In some cases hackers are able to develop an exploit just minutes after receiving a patch. Fortunately, for now, the technique is rather hit and miss. More often than not the semi-automated process creates tools that only crash vulnerable applications, rather than creating a means to inject hostile code onto vulnerable machines.

Over time the technique is only likely to get more reliable.

I am certainly sure the technique will get refined and become more effecient over time as with everything, the fact that it exists shows the evolution of hacking and that the boundaries are always going to be pushed aside.

Certainly something interesting to keep an eye on.

Source: The Register



Recent in Exploits/Vulnerabilities:
- Everything You NEED To Know About Shellshock Bug In BASH
- drozer – The Leading Security Testing Framework For Android
- Twitter Vulnerability Allows Deletion Of Payment Details

Related Posts:
- eEye Binary Diffing Suite (EBDS)
- WATOBO – The Web Application Toolbox
- Donations Flood in for Guilty Security Researcher Guillaume Tena

Most Read in Exploits/Vulnerabilities:
- Learn to use Metasploit – Tutorials, Docs & Videos - 227,584 views
- AJAX: Is your application secure enough? - 119,114 views
- eEye Launches 0-Day Exploit Tracker - 85,061 views

Low-cost VPS Hosting

4 Responses to “Patch Window Shrinking – Semi-Automated Reverse Engineering”

  1. Reticent 6 May 2008 at 9:51 pm Permalink

    People need to be more aware of what the exploit is and how the affected system is vunerable. Many of these exploits require a particular port to be open, a service enabled, or an application installed. Many can also be rectified by good firewall ingress/egress policies. Sign up to a few security advisory services and learn how to be secure before patches are installed.

  2. Bogwitch 7 May 2008 at 6:25 pm Permalink

    I see the problem as twofold. First, it is becoming more and more essential to deploy patches in a timely manner. Second, it is vitally important to ensure patches do not disrupt business. The situation has been seen before where patches have caused considerable issues with company infrastructures. This is not limited to Microsoft patches, anti-virus software has been seen to produce similar problems.

    http://www.informationweek.com/news/management/showArticle.jhtml?articleID=181503325

    So, the risks to systems increase as managers decide whether to deploy patches untested or to leave systems vulnerable until the patches have been thoroughly checked.

  3. Catch_twotwo 8 May 2008 at 7:07 pm Permalink

    The issue of delaying patches in order to test them has always been a big issue. I used to be charged with testing the patches prior to deployment to our servers across Europe. There was always the issue of speed vs. quality.

    One possible protection while you test the patches is a good updated Intrusion Protection System (not just detection). Something like Snort in-line with the Emerging Threats ruleset to cover the latest things, or Tipping Point who seem to pay for the honour of having a up to date ruleset.

  4. Jinesh Doshi 21 May 2008 at 11:29 am Permalink

    Is there any method to decompile a windows dll? I need to understand one method call.