Catching in-progress memory management exploits?

Discussion in 'other anti-malware software' started by Gullible Jones, Jun 13, 2014.

  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    I recently had cause to change some ulimit settings in a shell, and was struck by a realization: memory exploits would have an effect on what a program looked like in terms of physical memory usage. This would especially hold, I'd think, for current generation stuff using NOP slides, heap spraying, and other heap based attacks. Some of those can briefly allocate enormous amounts of address space for instance.

    And I wondered: would it be possible to have heuristics for recognizing that a program may be about to be compromised? Have a DLL library that is loaded by the program perhaps, intercepts memory management syscalls, and looks at where they go and how big they are. If they fit certain patterns, then make them fail and/or kill the program. Kind of like AV heuristics, only aimed at the exploit stage rather than the payload stage.

    Is this feasible? Have I just described part of EMET or something? Or is memory management too unpredictable for this to work in most cases?
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Well Emsisoft Antimalware realtime version already does this using it's behavior blocker aka Mamatu. It won't always stop the exploit in it's tracks but will warn you of abnormal behavior in which instance you can investigate further. I got burned because the behavior blocker alert was for IE10 and I stupidly allowed it since it appeared to be safe activity.

    EMET is great but only for the programs explicitly defined to it.
     
  3. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Thank you, that sounds like what I was thinking (but actually done right).

    That's from 2010... Inspiration for EMET?
     
  5. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    You're welcome :).
     
  6. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    From Assessment of run-time malware detection through critical function hooking and process introspection against real-world attacks:
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
  8. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,040
    Appguard also clearly does this with it's memory guard. You can tested it with Process Explorer
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    I don't think so, the techniques that are described are similar to the ones that are used by EMET/MBAE/HMPA. In order to apply such protection methods, you need to inject code into every app, and AG does not do this. Memory Guard does something else, and is not focused on blocking exploits in "stage 1". This is exactly what was discussed in the infamous "AG vs EMET" discussion.
     
    Last edited: Nov 8, 2014
  10. syrinx

    syrinx Registered Member

    Joined:
    Apr 7, 2014
    Posts:
    334
    Actually if the app being exploited is guarded with the memwrite protection enabled I'd imagine peter got it right. It shouldn't be able to modify the memory of any other process and as such appguard doesn't have to inject/modify into every app-just control the source app. I'll admit I haven't investigated this personally as I don't have any malware/exploit samples but that is my (hopefully not sorely mistaken) opinion.
     
  11. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Anyway those you guys are now talking about is not directly relevant to what OP interested in.
    Even EMET's heapspray mitigation is not because it previously allocates some memory address as a 'trap'.
    I agree, surely NOP sled and Heapspray must look anomaly.
    So far only HeapLocker is what OP's seeking for with it's memory monitoring and NOP sled detection, but its website says NOP sled detection causes too many FPs.
    Maybe better heuristic with less FPs is possible?
    And while it's not original interest for OP, yes kinds of runtime detection in exploited process will also be useful.
     
  12. erikloman

    erikloman Developer

    Joined:
    Jun 4, 2009
    Posts:
    3,027
    Location:
    Hengelo, The Netherlands
    HitmanPro.Alert 3 Dynamic Heap Spray mitigation monitors memory allocations in a continuous fashion.

    This in contrast to EMET's static Heap Spray mitigation where you have to specify which addresses you want to pre-allocate so specific attacks using those addresses won't work.

    With the static approach you have to know the addresses the attacker is using, whereas with the dynamic approach you do not have to know.

    The CTP4 of Alert 3 comes with an Exploit Tester to simulate various heap spray attacks, including NOP-sleds, polymorphic NOP-sleds and a few more heap spraying techniques.
     
  13. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Sounds very interesting.
    I think there's no conflicts reported with Kapersky IS, is it right?
     
  14. erikloman

    erikloman Developer

    Joined:
    Jun 4, 2009
    Posts:
    3,027
    Location:
    Hengelo, The Netherlands
    There are no known conflicts with Kaspersky or other AVs.

    There is a conflict with Malwarebytes Anti-Exploit 1.04. If you use that, update to MBAE 1.05. Also EMET 5 has issues with Alert. Downgrade to EMET 4.1 to use Alert 3. Microsoft is working on a fix for EMET 5.1.

    If you find any issues, please post in the HitmanPro.Alert thread, or send me a PM.
     
  15. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,066
    Location:
    Netherlands
    Do it yourself hardening tricks

    There is some simple hardening possible by placing some speed bumps and spike strips on the road for the average script kiddy using standard exploit-kits: For instance use group policy or registry tweaks to deny access to 16 bits applications, windows command shell and scripts, Use EMET to block jscript.dll,vbscript.dll to load (in addition to default flash using ASR feature of EMET) of rich content applications (like Office Aps). Use services.msc to disable sharing, remote and assistance services (risk-ware) when you are not using them.

    When you have problems using MBAE, HPMA there are freeware alternatives (in addition to EMET). Use Chrome and add ublock to block third party scripts and iframes. Install AVG Linkscanner Free to block known scipt based triggers of exploits. Chrome seems to handle emet 5.0 well on my PC (it is light years ahead on exploit mitigation anyway)
     
    Last edited: Nov 9, 2014
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    Like I said, this already has been discussed. An exploit tries to modify the memory of an attacked process (memory corruption), so in stage 1, it's not about protecting memory of another process. AG's Memory Guard is not designed to block exploits from running, it's more of a "containment" feature. And the "AG vs EMET" discussion was about in which stage exploits/payloads are stopped.

    Stage 1: Block exploit/shellcode from running
    Stage 2: Block payload/malware from running
    Stage 3: Block payload/malware from modifying system (containment)

    Apps with stage 1 protection: EMET
    Apps with stage 2 protection: VoodooShield, EXE Radar
    Apps with stage 1 and 2 protection: MBAE, HMPA
    Apps with stage 2 and 3 protection: AppGuard and Sandboxie
     
  17. erikloman

    erikloman Developer

    Joined:
    Jun 4, 2009
    Posts:
    3,027
    Location:
    Hengelo, The Netherlands
    HMPA also does stage 3 with Vaccination, Hollow Process, Application Lockdown and CryptoGuard.
     
  18. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    Yes good point, but then we're talking about malware that's already running on the system, while HMPA's main purpose is to stop them from running at all via exploit protection. But yes, if you run some malicious app, HMPA will also be able to mitigate some risk with the features that you mentioned.
     
  19. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,066
    Location:
    Netherlands
    Heap spraying is writing multiple code sniplets to the program’s heap, the area of memory used for dynamic memory allocation. (http://en.wikipedia.org/wiki/Heap_spraying)

    buffer overflow is when where a program, while writing data overruns the buffer's boundary and overwrites adjacent memory (http://en.wikipedia.org/wiki/Buffer_overflow)

    So when when MemoryGuard blocks this code to be written to memory, how can that code be executed? You seem to know all the ins and outs by just reading a program's user manual. So may be you would be so kind to explain it in layman's terms to people with less technical knowledge like me.
     
  20. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,026
    Location:
    The Netherlands
    Are you serious, didn't we already discuss this? I think Barb_C already confirmed that AG can not stop "stage 1 attacks". AFAIK "Heap spraying" is used in stage 1 to corrupt memory from the attacked process (like the browser). AG's Memory Guard is not designed to stop this. Memory Guard is designed to stop code injection from one process into ANOTHER process, and then we're talking about stage 3, because malware is already running.
     
  21. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,066
    Location:
    Netherlands
    Yes, No, Where did any formal representative of Blueridge confirm this?
     
    Last edited: Nov 9, 2014
  22. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Thanks, I'm interested in and also have other question, but I'll ask in that thread.
    I currently use MBAE, but I'm in transformation of my security.
    I'll drop MBAE if I use HMPA even though there's no known conflicts in v1.05.
     
  23. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Kees, Rasheed is right.
    Heapspraying and buffer-overflow have to be done within the targeted process such as firefox.exe.
    And while AppGuard's memory protection can forbid firefox.exe to write to another process' memory, it can't block it's own memory space.
    Of course firefox.exe have to write its own memory so it can't be blocked.

    I saw once Brab_C confirmed when FleischmannTV helped her to understand what Rasheed mean, but sorry now I can't found that post but probably Rasheed can post.
     
  24. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    BTW, are you aware of this?
    Exactly speaking, exploit code is not equal to shellcode and payload is not equal to malware.
    I found even wikipedia describes wrong definition though its reference source says correct.
    But you can safely say exploit code most often includes shellcode (though meaning of 'shellcode' changed much from its original def), and payload most often includes malware.
     
  25. Windows_Security

    Windows_Security Registered Member

    Joined:
    Mar 2, 2013
    Posts:
    3,066
    Location:
    Netherlands
    Thx Yuki,

    Long ago I talked to Eirik when they were in the process of developing memory guard. Eirik was a product manager before Barc succeeded him as representative here at Wilders.

    Their objective was to prevent an application reading and to writing outside the bounderies of the dynamically allocated (virtual) memory space of a guarded process. This way firefox for instance could be prevented by executing a script which caused a buffer overflow to get access to memory outside Firefox allocated memory space.

    I can't find the blueridge document anymore in which it proved to be more effective as early EMET in regard to exploit protection. This was just before they gained a large US military contract. In the documentation of the corporate version Memory Lock is now mentioned as a separate feature (preventing memory scraping makes it it harder to determine the offsets of the usual targeted system dll's). So for compatibility sake they may have changed the ambition level of the MemoryGuard module, that is why I asked for a reference of a Blueridge representative.
     
    Last edited: Nov 10, 2014
Loading...