MRG Effitas Online Banking Browser Security Assessment Project Q3 2013 – Q1 2014

@ Sveta MRG

Ok, so the end conclusion is that most apps can´t protect against malicious browser extensions and cookie stealing. Apparently you need a safe (or armored) browser for that. Do these malicious extensions try to modify browser memory (SSL logging), like trojan bankings do?

I have a feeling it might fail, because in the last MRG test, apps like Zemana and Kaspersky could stop the Zeus trojan simulator, and now they can´t.

I´m a bit skeptical about this one, since it runs the browser on their server, it´s not running on your own PC, I don´t like this approach.

 

You know nothin' Jon Snow.

On a more related side note, have anyone used Quarri and give some info about it?

 

Are malicious extensions a widespread problem right now? If they are I really have missed a couple of chapters here.

If the intention of this test is to alert about a potential new trend in malware I guess it's ok.

 

Here's a link to their web site that describes Armored Browser: https://www.quarri.com/products/armored-browser/. This is a paid product BTW. I only tested their free product, Protect On Q, and I had issues with it as I posted previously. My Protect on Q does install and runs on your PC versus remotely for the Armored Browser as again noted previously.

 

After reading this article last year, I decided to get rid of all but one extension.

http://www.pcworld.com/article/2049...-serious-threat-and-defenses-are-lacking.html

 

The danger has always been clear but very few people has been affected by this. That article is mainly about proof-of-concept's.

 

If they would have done "as usual" having a clean system and then started the testing, wouldn't we have come to this step automatically if a product failed to detect/block the simulator and other product features would come into play automatically as well. Most products goal is to prevent an infection from happening in the first place whether it is a keylogger or some kind of banking malware or whatever but they had no chance to do that in this test. So I do agree with Mr Wosar.

 

Nice article, but I also think it´s up to browser developers to limit what extensions can do. Perhaps a bit less functionality and a bit more security would be a good idea. Especially Firefox and IE give extensions a lot of access rights.

Of course you could also choose to use a safe browser or use only a few trusted extensions. Now that I think of it, perhaps you could also use a sandboxed browser (Sandboxie), running in its own sandbox, with nothing installed.

 

Can you give a bit more info on this? How does it block extension installation, and which browsers are covered?

 

I also think it´s a bit weird that Trusteer and Avast where not included. They performed quite well in earlier tests.

 

At the moment only Internet Explorer is covered by EAM. For Chrome it seems kind of pointless given that Chrome won't install any extensions that aren't signed by Google by default. We are currently looking into implementing the same type of protection we have for Internet Explorer for Firefox.

 

In the future I would like to see more anti exploit tests. Perhaps you can also include apps like Exe Radar, AppGuard, Malwarebytes Anti-Exploit and HitmanPro.Alert v3.

Question: Can you perhaps give some info about how HIPS like Zemana, Webroot and Trusteer are blocking SSL logging, used by the MRG simulators? Do they alert about suspicious behavior, or do they automatically block it? And do they also protect when the system is already infected?

 

How will you monitor FF extension installation, is it enough to simply block (or alert about) .XPI files?

Also, do you think it´s technically possible to control extension behavior with HIPS?

 

By controlling the loading points used by Firefox and Thunderbird for add-on installation outside of the browser or mail client itself. This gives a few pointers on how extension installations work and which file system and registry locations need to be monitored:

https://developer.mozilla.org/en/docs/Building_an_Extension

Everything is possible. Is it practical? No.

 

@ Fabian Wosar

Quite interesting, so it should be possible to block extensions from loading, even when installed manually by the user? Question: does EAM´s behavior blocker also protect against banking Trojans? Can it block SSL loggers proactively, like Zemana and Webroot, for example?

About my question about HIPS, now that I think of it, apps like Webroot and Trusteer already try to isolate extensions from browser data and memory, so in fact, if they did fail this test, it´s a shame.

 

Pretty much, yes.

We essentially prevent programs from injecting code into the browser which is a per-requirement for the majority of SSL loggers these days. We don't target SSL loggers directly though the way some other products do.

 

Is there any reason why you (Emsisoft) chose not to offer these more aggressive methods? Because sometimes some legit apps need to inject code into the browser.

To be honest I´m still trying to figure out how tools like Zemana, Trusteer and G Data BankGuard (to name a few) are protecting against banking trojans. If I´m correct they can even protect a browser that has already been hooked in memory. Do they simply "unhook" the browser from malicious modifications?

 

And sometimes legit apps need to log SSL connections. Fiddler for example. You will need a white list anyways.

I didn't look into any of those programs. But most likely they will check whether the routines involved in SSL communication have been hooked or otherwise modified in memory. It would be interesting to check whether they actually look at the entire function or if they only check the beginning of the function where most hooks will be located. Unhooking would technically be possible, however it may not be safe. Personally I would recommend the user to clean up the infection instead of trusting any kind of unhooking mechanism.

 

Yes, this is the approach HitmanPro.Alert is taking, it just alerts about browser memory being compromised, it doesn´t try to block or unhook modifications made by trojans. But to me it´s quite fascinating how some HIPS try to protect an already infected machine. The question is, can they do it in a smooth way, for example, I´ve read a lot of bad stuff about Trusteer, that´s why I never tried it.

A technical question: do you think that in order to monitor (and battle against) malicious hooks, it´s always necessary for anti-malware tools (HIPS) to inject code into the browser? Or can you just monitor certain API´s?

 

To detect memory modifications like hooks, it's not strictly necessary. However, it is a lot more efficient to inject code to do the checks. Accessing memory that does not belong to your process has a whole bunch of nasty performance penalties.

 

Thanks for the feedback.

Another question: How to block these hooks? Can this be done from outside browser memory? For example, apps like Zemana and SpyShelter both claim that they can block SSL sniffers, but I´m not sure if they are using code injection, I still need to check that.

EDIT: To clarify, I mean: how to block these hooks when you have already allowed some malicious app to write to memory.

 

Btw, I´ve been reading about Wontok SafeCentral, and is it using a separate "safe" browser, or what?
One thing is for sure, it´s doing a better job than HIPS.

EDIT: But I´m not into cloud browsers at all, that´s why I´m asking this question.

https://wontok.com/wontok-safecentral-protection/

http://www.forbes.com/sites/adamtanner/2014/03/10/why-cloud-browsers-are-the-wave-of-the-future/

 

A new report is out. Bitdefender, Kaspersky and Webroot did quite well. Strange that they didn´t test Zemana and SpyShelter.
And to answer my own question, Wontok is indeed using a "safe browser and desktop" for protection.

https://www.mrg-effitas.com/current-tests/ (MRG Effitas Project 40)

 

All interesting! Thanks for the post and follow ups.

 

Btw, I forgot to mention, there are two reports, level 1 and level 2. Webroot failed the SpyEye test but they fixed it straight away, so they did get the MRG certification. I´m also surprised that so many tools failed the SSL MiTM Simulator test, all they had to do is monitor the DNS and SSL certificate settings.