MRG Effitas Online Banking/Browser Security Q2 2015

Discussion in 'other anti-virus software' started by IBK, Aug 15, 2015.

  1. IBK

    IBK AV Expert

    Joined:
    Dec 22, 2003
    Posts:
    1,819
    Location:
    Innsbruck (Austria)
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    I guess many AV vendors tested that have HIPS don't care about this test? Most could have passed the simulator test and got certified by simply creating default HIPS rules for whatever browser/s that were installed on the PC.
     
  3. Sveta MRG

    Sveta MRG Registered Member

    Joined:
    Aug 16, 2009
    Posts:
    207
    These tests are designed to spread awareness about the lack of browser security and dangers of online banking. HIPS is not the answer here, dedicated browser security is.

    If you take a closer look you will see that most of the vendors are developing their own browser security components, some do this via secure browsers some “harden” the existing browser.

    Do vendors care? Well they seem to care more than you think, in the past they created signatures for simulators, blocked public results page…. Now things are much better as they are more focused on improving and addressing the core of the issue rather than temporarily “patching” it.

    It may be hard for some to believe, but we are all working on creating a safer environment for the end user.


    Cheers,

    Sveta
     
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Yes. And that discussion been had in detail here many times on Wilders.

    However, assuming that the simulator did not employ memory exploit methods, a browser HIPS rule with the following mitigations would have stopped it:

    1. global hooking
    2. application state modification

    and I always add

    3. event interception - to block keyloggers.

    Additionally, some of the products tested do not enable SSL protocol scanning by default e.g. Eset Smart Security. Those that do e.g. Avast, etc. passed all the simulator tests.
     
  5. lordraiden

    lordraiden Registered Member

    Joined:
    Jan 30, 2006
    Posts:
    3,077
    Why avira doesnt have a 100% ? Just because it doesnt have a special protection for browsers? It blocked all the malware
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,046
    Location:
    The Netherlands
    What do you mean with that? Isn't HIPS supposed to block all this stuff? And is it my imagination, or have you once again decided not to report how the tested products managed to pass certain tests? With that I mean, did they block it with signature or by behavior blocker?
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,046
    Location:
    The Netherlands
    It missed a couple of samples of real life malware. But for some reason it was able to block the simulators, to my surprise. Even a specialized tool like Zemana failed this test.
     
  8. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,046
    Location:
    The Netherlands
    About which HIPS are you talking? I don't understand how you can be so sure that this would have blocked all the tests, it all depends on the HIPS. For example, Zemana blocks API hooking of the browser, but apparently, it doesn't watch for these specific hooking techniques. Perhaps someone from Zemana will be able to answer why they failed this simulator test.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Appears to me that the simulator used encrypted HTTPs input to deliver it's payload. So, if the AV product didn't filter that type of connection, it slipped right past the front-end AV network/proxy monitoring i.e heuristics w/sandboxing etc..-EDIT- Looking at the minimal info on the similulator again, appears it was used to simulate a MITB and capture traffic prior to outbound encryption by the browser. Really don't know the relevance of this kind of testing. If your infected and doing online banking, you're bound to get nailed. Whole purpose of security software is to keep the bad guys out of your PC.

    Almost all HIPS can monitor the browser itself for global hooking and process modifications if so instructed to do so by a specific rule. It doesn't matter if the malware actor is hidden or not. But if an exploit with its harder to detect memory injection did the activity, it could zip right by the HIPS process modification rule.
     
    Last edited: Aug 16, 2015
  10. ida15

    ida15 Registered Member

    Joined:
    Jun 18, 2015
    Posts:
    202
    Location:
    Bosnia and Herzegovina, Sarajevo
    Hi Sveta,

    Great to see you on Wilders :) Thanks for the amazing response.

    Best regards,

    Ida from Zemana :)
     
  11. ida15

    ida15 Registered Member

    Joined:
    Jun 18, 2015
    Posts:
    202
    Location:
    Bosnia and Herzegovina, Sarajevo
    We will improve ZAL's features, test like these make us see what we need to improve :) @Emre TINAZTEPE correct? :)

    Best regards,

    Ida
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    This might help a bit in what the simulator did. It used reflective DLL injection and then set the hook afterwards.

    The process of reflective DLL injection is as follows:

    1.Open target process with RWX permissions and allocate memory large enough for the DLL.
    2.Copy the DLL into the allocated memory space.
    3.Calculate the memory offset within the DLL to the export used for doing reflective loading.
    4.Call CreateRemoteThread (or an equivalent undocumented API function like RtlCreateUserThread) to start execution in the remote process, using the offset address of the reflective loader function as the entry point.
    5.The reflective loader function finds the Process Environment Block (PEB) of the target process using the appropriate CPU register, and uses that to find the address in memory of kernel32.dll and any other required libraries.
    6.Parse the exports directory of kernel32 to find the memory addresses of required API functions such as LoadLibraryA, GetProcAddress, and VirtualAlloc.
    7.Use these functions to then properly load the DLL (itself) into memory and call its entry point, DllMain
    .
    Ref: https://disman.tl/2015/01/30/an-improved-reflective-dll-injection-technique.html

    An example of its use:

    How I would bypass ExploitShield(aka MBAE's predecessor) is creating a buffer in memory, and using reflective DLL injection (optional, just to avoid AV detection, and forensics). I’d load that DLL into another process (AFAIK ExploitShield does not hook CreateRemoteThread()) and then execute it in the context of another, unshielded process, or really any process, shielded or not, because it won’t detect an exploit in Pidgin if I exploited Firefox. The details are a bit more complex, if they detect process ID enumeration, or one of the other steps, that’s that. But I think with just a bit of extra ROP you can prevent their detection.
    Ref: http://www.insanitybit.com/tag/exploit/

    -EDIT- Also use of reflective DLL injection discussed previously in Wilder's in this thread starting at reply #177: https://www.wilderssecurity.com/threads/fileless-malware-detection.370944/page-8

    Here is an example of a bypass of heuristic AV protection using reflective DLL injection: http://www.yap0wnb.com/2014/07/bypassing-antivirus-heuristic-detection.html

    Finally, there is the question of just how safe are armored products such as Bitdefender's Safe Pay stand-alone version if major banks won't accept its usage due to outdated browser use? Ref.: http://forum.bitdefender.com/index.php?showtopic=57852. Or the practical usage of feature incorporated into AV products given the numerous complaints of bugs and overall unsuitability as noted in the various vendor forums.
     
    Last edited: Aug 17, 2015
  13. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,047
    Location:
    Saudi Arabia/ Pakistan
    Interesting. I have two questions.

    Can a classical HIPS or a sandbox block this?

    Is there a POC?

    Thanks
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    The mentioned ExploitShield bypass is theoretical. Don't know if he ever got around to doing a POC. Probably not since most issues were fixed in later releases of MBAE which author notes toward the end of the blog posting. I posted it since I believe the technique could get around armored browser protection.

    Depending on the HIPS used, a rule against process/memory modification could catch the injections. However, you would have to apply said rule to commonly used processes. Beside my browser, I protect svchost.exe, explorer.exe, rundll32.dll, winlogon.exe, and notepad.exe. These are the processes commonly targeted for injection. I believe Defense+ protects all the mentioned processes plus others by default. Ditto for Outpost Pro HIPS and I suspect Online Armor HIPS.
     
  15. aigle

    aigle Registered Member

    Joined:
    Dec 14, 2005
    Posts:
    11,047
    Location:
    Saudi Arabia/ Pakistan
    Ok, If this is the case why Zemana failed against the simulator?
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Zemana is behavior based i.e. uses heuristics. That type of software ineffective against reflective DLL injection. Note the previous example I posted of AVG being bypassed.
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    For a HIPS to catch reflective DLL injection, most retail versions would have to catch the allocation of memory in the browser and/or the writing to that memory as noted in the above steps 1 and 2 of injection detail. Same goes for exploit blockers. After that, it's pretty much over as detection goes. Note that this whole reflective DLL scenario is prefaced on the ability for the malware/simulator to get read, write, execute privileges to your browser. I use Eset's HIPS and it doesn't care about privileges as far as source processes goes in its rules. Nothing is allowed including signed OS processes.

    Now some commercial HIPS's have the capability for specifying all .dlls a process uses in a rule and blocking any other .dll injection. This of course would catch the reflective .dll injection.
     
  18. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,078
    Which rules do you create in Eset's HIPS to prevent this injection? Also, which apps do you protect? Do you use Ask or Deny action? Thnx.
     
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Below are the two browser rules I use. Everything is blank elsewhere in rules except that shown in the screen shots.

    Note: you will have to allow and create additional rules on browser startup for anything normal that accesses the browser such as iexplore.exe x64 for iexplore.exe x86, iexplore.exe for itself, explorer.exe, svchost.exe, etc.. Just let Eset HIPS tell you what else is needed.

    You might also consider checking the debugging operation since it appears that is exactly what the simulator was using to dissect kernel32.dll for addresses.

    Also short of running the MRG simulator on my PC, I can't guarantee these rules would stop the reflective DLL injection they used.

    Eset IE Rule 1.png

    Eset IE Rule 2.png
     
  20. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,078
    OK, thank you itman. Might try it out and see how it goes.
     
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    Just tested IE x64 with a DLL injection test tool. Using CreateRemoteThread injection method, the Eset HIPS rule setting of "modify state of another application" stopped it dead in its tracks. This was the only x64 injection method the test tool supported.

    Note that Eset in default settings for ThreatSense realtime scanner has advanced heuristics/DNA/smart signatures disabled on file execution. One possible explanation why the MRG simulator activity was not detected? Eset does have that turned on for web protocol scanning; assumption being the threat is coming from inbound web traffic.

    Finally have to add that Emsisoft behavior blocker detected the test tool injection activity before it even got to the Eset HIPS. I allowed to see if my Eset HIPS rule would catch it.
     
    Last edited: Aug 18, 2015
  22. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    3,771
    Location:
    Outer space
    Afaik, for most of the HIPS, if you create rules for example Firefox against DLL injection, hooking etc, it will block the application for which the rule is created(in this example Firefox) from doing these actions. That won't stop another process(for example a MitB malware) from doing these actions against Firefox.
    Your screenshots from ESET seem to indicate that it can actually protect a possible target application instead of restricting a possible offender application, but I don't think most HIPS can do that, only restricting possible offenders.
     
  23. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,078
    It depends on HIPS. Malware Defender has an option to prevent modification of target process if I remember correctly.
     
  24. SweX

    SweX Registered Member

    Joined:
    Apr 21, 2007
    Posts:
    6,429
    No, AH is enabled by default for "on file execution". I know that applies to both V9 (beta) and V8, plus earlier versions as well.

    If one enable AH to be used during realtime scanning then it is used all the time, and not only at file execution.
    AH is disabled for realtime scanning by default as it can affect the system performance in some cases, but is enabled for "on execution" as that is a critical moment when we talk about malware so it is important to leave it enabled.

    I add two screenshots so we know that we talk about the same settings.

    AH disabled by default for realtime scanning.....
    eset.JPG

    AH enabled by default for "on file execution".....

    eset1.JPG

    But, Heuristics, Advanced heuristics/DNA/Smart signatures is indeed enabled by default for the Web Access Protection.
     
    Last edited: Aug 19, 2015
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    As far as I am aware of, most HIPS's will allow target rules to be created against any source app. Here's how you do it in Defense+: https://help.comodo.com/topic-72-1-284-3027-Defense -Rules.html ; use custom policy.

    Now behavior blocking software only monitors the target behavior. However as I indicated, Emsisoft's BB was equally effective against catching the DLL injection from test tool. I believe so because the test tool was unsigned and not trusted by the cloud and therefore constantly monitored.
     
    Last edited: Aug 19, 2015
Loading...