Rapport versus commercial keyloggers

Inspired by the excellent results by Trusteer Rapport in recent MRG Banking Tests I tried to play with this a little. I tried it against three commercial keyloggers.

1- All in one keylogger
2- Advanced keylogger
3- Elite Keylogger

http://www.keylogger.org

Tested on XP SP2 with CTM, alongwith CIS( disabled) and GesWall( disabled ), used IE6( yes, my XP test sanpshots have IE6). I opened paypal page and tried to see how ell it protects the credentials. Rapport protected my password in all cases, though not the user name in all cases.

A very nice feature that I noted is that it protects against screenshots too.

 

I found that Rapport protects against phisphing in a unique and effective way. No need for any blacklists( which are in fact never completely effective). You can see this in the screenshots below.

A problem with Rapport is that it doesn,t work with sanboxes like SBIE, GesWall etc. Not a problem in my opinion. In case of SBIE, delete the sandbox and launch a clean instance of browser outside of SBIE for banking.

In case of GesWall ( and may be DefenceWall too), terminate all untruted/ isoalted process and then launch a clean instance of browser outside of geswall for banking, shopping etc. In all cases don,t do/ any other activity in another browser window/ tab etc until you finish your banking, online shopping etc.

 

for some reason its working on GesWall now, not working on SBie though

 

even if it's "working" with Geswall does not men every thing works well.

using Geswall and Rapport together is not recommended and unless someone has the testing expertise, there's no way to know if the security of either or both has been compromised by using both products.

 

I tested it with Spyshelter POC.
Keystrokes are scrambled on protected sites.
Screenshot blocked by Rapport as well.
Untrusted files are listed and can be removed by GesWall (no problems either)

but yeah I guess you are right...

 

They recommend to run browser out of geswall for Rapport to work, if you are using both.

 

Aigle

Better than last time you tested it aye?

Nice thing about rapport, is that you can also set ALLWAYS on most options. This prevents some hassling with the browser process, especially with IE9, so it won't only increase protection for the sites you have added manually, but also increases general surfing protection.

Most browsers use injection (dll injection is a normal Windows mechanism, which can be easily misused). When you use a HIPS, you have to allow this action. When the HIPS does not have parent-child granularity (but just allows the action of the parent process), you effectively loose the protection on this action for the browser (you tell your HIPS, I don't mind when IE9 changes Explorer for instance). Adding Trusteer with ALLWAYS settings as much as possible, narrows down this 'weak spot' because IE9 (or any supported browser) can't be messed from the outside.

So when your HIPS does not has parent - child granularity (e.g. PCtools firewall) it is a nice add-on. Note that some programs have a build in set and apply default deny (like AppGuard) and have a far more granular control on memory protection so you need not worry with these type of programs when it lacks a classic HIPS parent-child control mechanism.

Regards

 

@aigle did you tweak the policy or it performed under default policy? please let me know..Thanks

 

Default for paypal as it,s already a secured site by Rapport.

Custom plocy for gmail as it was not a secured site by deafault, so I added it manually to the secured sites and then added screenshot protection for it as well.

 

yes, sure. And thanks for your tip about advanced settings in another thread. I had always missed those.

Will check this option later.

I will disagree on this one.

Why a browser will inject a malicious dll? Malware needs to manipulate the browser to do this and even a HIPS without a granular control will intercept it. So no problem with simple user friendly HIPS IMO.

 

I also with you , javascript for instance runs inside the browser, so when the browser injects itself (which is common with most browsers) and a Simple HIPS (e.g. PC Tools FireWall) allows the browser to inject everything, a javascript exploiting a weakness will also be seen as the browser process, thus the HIPS would fail to prevent the malicious javascript injecting explorer for instance. A parent - child granularity would prevent this leak, a HIPS which monitors dlls will also prevent this by the way (take in mind your complaint about Comodo on which I agree with you that OA has implemented this more robustly). In the old days a german site called fake security (scheinsicherheit) had all sorts of nice test to illustrate this (it is outdated now). Some programs are strong on PoC or artficial tests (e.g. Matousec), but fail misarably with real malware (using egg hunter buffer overflows for example).

Regards Kees

 

Downloaded to my filedrive for eventual future use. Thanks guys for testing.

 

Is this simply clicking "Protect this Website"? Or is there another step for adding screenshot protection? Thanks.

 

You need to go to security policy in rapport console and change the settings for block screen capturing to on partner and sensitive websites.

 

yep, like this.

 

Hi

Very interesting thread. How does SafeOnline stack up under similar conditions?

Indeed any comments on the worthiness of one versus the other.

Thanks

Terry

 

So is it normal for IE9 to inject dll? Spyshelter issued an alert that IE9 was injecting a remote dll to some process every time I started IE9. Is it OK if I disallow such injection because IE9 continued to work after I denied the injection.

 

After reading the MRG banking tests, I downloaded Trusteer Rapport from my bank and am using it with IE just for banking.

 

But, isn't it like a double-edged sword, though?

What if someone with physical access to a user's computer, who happens to know this user's username and password for X service (this user has no idea!), and then Rapport simply gives a warning similar text was entered in ABCD services?

I don't know, I feel it's a like double-edged sword.

 

I did not get it but why to give physical acess to some one.

 

Whether someone gives or not physical access to their systems, be it friends, co-workers or relatives is not really important, IMO.

What's important is that, if they do get access to the computer and try to use the username and password, that they somehow became aware of this user has for X service, then if Rapport is protecting the credentials, Rapport will give an alert on which services the credentials have been used for.

So, if I were one of these people who got physical access, I would then know that this person has an account in Gmail, Paypal, etc (whatever service) and even other services I may not be aware of.

I knew the username and password of a single service, but now I know the credentials can also be used in more services and which ones, actually.

That's why I see this as a double-edged sword.

-edit-

Obviously, I'm considering situations where users are using the same credentials for these different services.

 

It is normal. That also surprised me when I did that with other HIPS, some functionality must be broken by the deny, but I did not seem to miss it

 

True, but software can never compensate for user stupidity (A giving someone the credentials, B using the same password+user id over and over again).

Also it is possible to enter several passwords + user-id's for this Trusteer feature, so in the case the user has different user id's/nicknames and passwords, it would not help the stranger/other person having phisical access to the computer.

Most confusion is caused due to self-reference interpretation, so I bet you use ONLY one user-id/nickname + passwords on most, because you are convident on your security, just a guess

Regards Kees

 

I do
but I never use this Rapport feature

 

I agree with that. But, I never talked about someone giving someone their username and password for X service.

Simply, what if person A discovers person B's credentials for X service. Person A already has access to person B's X service. But, that's it. Person A has no access to other services, nor has any idea about what other services person B makes use of.

And, we do know that people use the same username and password for many services, even some of the so-called security experts.

Correct, but I never talked about person B having different usernames and passwords for every service. I talked about having the same credentials, and person A already knows the username and password for one service.

Person A is already in possession of a username and password for X service, and Rapport will help Person A, who managed to get physical access to Person B's computer, to know in what other services person B is using the same credentials. Perhaps, even other services Person A wasn't aware they existed.

So, now Person A knows that the same credentials can be used for services XYZ.

So, while I agree that software cannot compensate for user stupidity, in this case Rapport isn't being helpful either, IMO.