Flawed code hooking engines open endpoints to compromise

Discussion in 'other anti-malware software' started by ronjor, Jul 19, 2016.

  1. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    57,727
    Location:
    Texas
    https://www.helpnetsecurity.com/2016/07/19/flawed-code-hooking-engine
     
  2. ropchain

    ropchain Registered Member

    Joined:
    Mar 26, 2015
    Posts:
    331
    Sounds familiar =)
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Nice to see that Eset is not on the list.
     
  4. Fabian Wosar

    Fabian Wosar Developer

    Joined:
    Aug 26, 2010
    Posts:
    787
    Location:
    Germany
    The list is actually not comprehensive at all. Not really sure what caused them to ignore certain products in their list. Maybe they don't name their customers? Who knows.
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    I was surprised actually to see Emsisoft on the list. My tests of the behavior blocker showed it to be extremely effective at hook detection w/default settings. I believe this bypass is a result of using detours which most security solutions are vulnerable to.

    Also the original article has been updated today:

     
  6. Fabian Wosar

    Fabian Wosar Developer

    Joined:
    Aug 26, 2010
    Posts:
    787
    Location:
    Germany
    It had nothing to do with detecting hooks. Essentially some hooking engines leave some memory at guessable addresses both write- and executable. Ours is based on a commercial product that is used by a lot of other vendors (Panda, Malwarebytes, McAfee, to name a few) and that product essentially left some memory write- and executable.

    In itself this doesn't create an exploitable vulnerability. It just makes exploitation of other vulnerabilities easier.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Found an article that explains the situation a bit more in detail: http://breakingmalware.com/vulnerabilities/captain-hook-pirating-avs-bypass-exploit-mitigations/ . Will have to wait to Black Hat 2016 conference findings are published for more specifics:

     
  8. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    But was this a matter of bad coding or design? I wasn't shocked by this discovery though, I mean this all is complex stuff. But I do wonder if these flaws were really that easy to exploit. I also wonder if API hooking is really necessary for certain stuff.

    A while back I already discussed this with you, but I believe that for example SpyShelter, is able to block API hooking of the browser (to stop banking trojans), without actually having to hook the browser itself. I believe it uses a driver to achieve this.

    Interesting link. Remember, in the HIPS thread we discussed this stuff quite a lot. I hope you now understand what I meant with "there is a difference between global/window hooking and API hooking."
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    I knew this thread would get your attention noting that you're obsessed with API hooking.

    Note that this is about flaws in the commercial hooking engines; HackTool SDK, MadCodeHook, EasyHook, etc. used by the majority of AV vendor, etc. products.. -EDIT- I believe EMET uses Detours as its hooking engine. At least MS will be patching that in early Aug.. We'll have to wait till the Blackhat presentation notes are published or news feeds publish details on same.

    I don't believe Eset is affected since I don't believe it uses a commercial hooking engine. Believe they developed their own internally.
     
    Last edited: Jul 23, 2016
  10. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    OK, so developers aren't to blame? And I didn't even know that security tool developers used these hooking engines, I do know that HMPA uses a hooking method that they developed themselves.