Series of Demo Videos of Trusteer's Rapport

I am currently producing a series of videos demonstrating the anti-spyware capabilities of Trusteer's Rapport. So far I have looked at keylogging software and screen capture. Specifically, I have demonstrated it with Zemana ScreenLogger, Zemana KeyLogger and SpyShelter. I will be adding more videos over the next few days. The first two videos are embedded below. (Edit: 17/05/10 - I have now added three more videos covering Zemana SSL Logger, AKLT and Snadboy's Revelation V2.)





Links to the YouTube videos are below:

• Trusteer's Rapport Demo 1 - Zemana ScreenLogger
• Trusteer's Rapport Demo 2 - Zemana KeyLogger
• Trusteer's Rapport Demo 3 - SpyShelter
• Trusteer's Rapport Demo 4 - AKLT
• Trusteer's Rapport Demo 5 - Zemana SSL Logger
• Trusteer's Rapport Demo 6 - Snadboy's Revelation V2
• Trusteer's Rapport Demo 7 - Pharming Attack
• Trusteer's Rapport Demo 8 - Amecisco Invisible Keylogger Stealth
• Trusteer's Rapport Demo 9 - Anti-Phishing Protection

Keylogging Trusteer's Rapport

Let's get some perspective on this first: no security product is 100% secure and just because there may be an obscure way round a product doesn't mean you shouldn't use it and that it won't protect you against a lot of attacks. How secure is your Anti-Virus (AV) product? Certainly not 100%, so we need layers of security. Rapport is another layer of security and could help protect your machine.

I have said in my previous post about this issue how well Trusteer dealt with me. So, now to the method of keylogging Trusteer. It's quite simple really, but requires a special setup. Rapport hooks onto the keyboard driver to prevent keylogging. However, if you invoke the remote desktop feature in Windows then a different keyboard driver is invoked, which Rapport cannot hook onto. So, if you're using a remote desktop connection into your machine then Rapport will not be giving you the full protection (it still has other layers of protection that work in this scenario).

Is this such a special case that you don't need to worry about it? Well not necessarily. There are a plethora of remote access software solutions available to users who are increasingly using them to access their machines at home or at work. There is also another technology that can be leveraged to cause this effect whilst the user is at the actual machine. Microsoft have introduced RemoteApps to the Windows desktop environment to allow for legacy applications to appear to run seamlessly on Windows 7. This is done via Virtual PC running another OS and the RAIL QFE update to allow applications to be exposed from a desktop machine as RemoteApps. However, we can use this technique to look back at the machine and expose the web browser as a RemoteApp, which the user should not notice.



As I say, it's a special case and not one a user would normally encounter, but it is possible. There are other issues with Trusteer as well, being able to capture the screen of protected websites and information leakage as highlighted on ReviewMyLife.co.uk here. It doesn't mean you shouldn't use Rapport though, just know and trust the machine that you're using. Basically, don't ever connect to any secure site or service from an untrusted machine, no matter what's installed on it.

Trusteer's Response to Issues with Rapport

I have been getting a lot of hits on this blog relating to Trusteer's Rapport, so I thought I would take a better look at the product. During my investigations, I was able to log keystrokes on a Windows 7 machine whilst accessing NatWest. However, the cause is as yet unknown as Rapport should be secure against this keylogger, so I'm not going to share the details here yet (there will be a video once Trusteer are happy there is no further threat).

I have had quite a dialogue with Trusteer over this potential problem and can report that their guys are pretty switched on, they picked up on this very quickly and are taking it extremely seriously. They are also realistic about all security products and have many layers of security in place within their own product. No security product is 100% secure - it can't be. The best measure of a product, in my opinion, is the company's response to potential problems. I have to admit that Trusteer have been exemplary here.

Why do I keep saying it's a potential problem when I have logged keystrokes? Well, under normal operating conditions this isn't possible with the keylogger used. Most home users won't have a machine set up like the test machine in this case.

Trusteer have also pointed out that keyloggers are not the main threat facing the banks at the moment and are of less use now than in the past. Rapport has several layers of security protecting the machine beyond keyloggers and blocking screen capture. One of he major plus points about Rapport is their anti-phishing and anti-pharming technologies. Although, again, these aren't perfect, it's better than nothing.

I don't agree totally with Trusteer here though. The problem with being able to log typed characters comes back to weak passwords and single-factor authentication. In this case, NatWest seem to require a customer ID, consisting of the user's date of birth and a 4 digit ID in the format ddmmyyxxxx, a 4 digit PIN and only a short password. Now, they will let any Customer ID through in this format whether it's valid or not (good from a security point of view as you don't know if you've got a valid Customer ID or not). However, clearly they allow 6 character passwords and then ask for three of them. So with one capture I can have 3 out of 4 PIN digits and half the password. We know people choose weak passwords that can be guessed. This becomes a crossword puzzle to make a 6 character password given three known characters. I would agree with Trusteer that keyloggers and screen capture shouldn't be a problem now, but it still is, as the banks cling onto simple username and password authentication, often with poor password policies.

If the banks move to 2-factor authentication and one-time passwords then most of this would be redundant, and Trusteer could concentrate on pushing us off to the correct site to avoid phishing and pharming attacks. Of course, these will become even more prevelant and sophisticated. Technology can't stop this alone, it has to be coupled with user education. Screen capture can still cause problems with strong authentication solutions, such as those using images or on-screen grids to generate one-time passwords.

So, what's the bottom line? Since my earlier posts, Rapport has come a long way with compatibility, etc. The tone of the marketing has also changed for the better and is more realistic (although some of the 44 partner banks could be doing more). So Rapport could be an additional layer of security to protect you, but you will still have to be vigilant. You must have an up-to-date, legitimate anti-virus/anti-malware product, firewall protection, tight controls on your browser and a cautious and skeptical approach to all communiations and links. Without these, Rapport isn't going to help you anyway.

Edit: video in later post - Keylogging Trusteer's Rapport

Lack of true Identity Verification forces need for EV SSL Certificates

What are EV SSL Certificates? Simply they are Extended Validation SSL Certificates. What does this mean? Well, simply put the Certification Authority goes to more lengths to validate the identity of the person asking for (paying for) the certificate. The EV SSL Certificate then will make the browser address bar go green to certify that this really is the site you think it is and not a phishing or pharming site. It gives the user a very visual check of the validity of the website that they are using.

Isn't this what Digital Certificates were supposed to do in the first place? Yes, but the Certification Authorities were more interested in taking people's money than verifying that they actually were the people in question. This led to almost anybody being able to sign up for a certificate claiming to be almost anybody. This, obviously, isn't a workable situation, so EV SSL Certificates were introduced to do the intended job, only at a higher price than the standard SSL Certificate (in part due to the actual identity validation performed no doubt). That being said, they are not expensive in the grand scheme of things and should be used far more widely than they currently are - for example NatWest still doesn't use an EV SSL Certificate at the time of writing this, instead they have ended up implementing Trusteer's Rapport at a much higher cost.

To give you some idea of cost of a digital certificate, Comodo's price is £214 per year (US$359/€359) for a single fully qualified domain name (i.e. per website); this includes their 'Corner of Trust' logo. Compare this with somewhere near $1 per customer for Trusteer's Rapport or even hosting fees and business profits! Admittedly, their cheapest SSL Certificate is only £41.95 per annum, but is £214 too much to ask when you are giving customers peace of mind, assurances over authentication and tackling phishing & pharming?

Why aren't normal certificates secure? Well, the problem is that most Certification Authorities don't do very much checking. Usually they check your domain name by sending you an email to an address that has the same domain name extension. All this says is that someone who has access to an email address on that domain wants to set up a secure web server. They don't actually check who you are. They are more interested in whether you will pay than if they should issue the certificate. This was demonstrated at IPICS today, when it was shown that VeriSign had given out a Digital Certificate to someone using the name William Gates! They have also fallen for scams, where they were duped into issuing a code signing certificate for the Microsoft Corporation by someone proving the point that they are not careful enough.

I decided to see if this was the case with other organisations, and it is. I have set up an SSL certificate just by being able to view an email sent to an address on that domain. I also wanted to know if I could be Steve Ballmer - the new Bill Gates. So, I set up an email account: Steve.Ballmer@live.co.uk using details about him, such as his year of birth: 1956. I then decided to try Thawte out, as they provide free email certificates for personal use. Sure enough, after entering the data below, I was sent an email to my address with codes to verify myself. I now have a digital certificate to sign emails from Steve.Ballmer@live.co.uk.

Surname: Ballmer
Forenames: Steve
Date Of Birth: 1956/03/24
Nationality: the United States
Email: steve.ballmer@live.co.uk
Where were you born? Detroit
Where did you go to school? Detroit Country Day School
First company you worked for? Procter & Gamble
What is your spouse's Name? Connie Snyder
How many children do you have? 3

Now, Thawte has a little trick up its sleeve here, which aides security. Before they will assign the name Steve Ballmer to the certificate, I must pass their Web of Trust, i.e. I must convince some other users that I am indeed Steve Ballmer first by meeting them face-to-face. However, if I could supply them with details such as passport number and social security number, then I'd be set. So, I can still sign my email, but if users look closely at the signature and check the certificate, they will see that I haven't been verified. However, if they don't actually look at this carefully, and with knowledge of what it means, then they will be fooled into thinking I really am Steve Ballmer. Why should the ordinary user know about this? Comodo and VeriSign, on the other hand, provide no such backup. So, I can now sign my email as Steve Ballmer. Here's my Public Key for Steve Ballmer from Comodo showing that I really am Steve Ballmer!

This isn't really good enough in this day and age of phishing scams.

Post Script Edit
Two things have happened since writing this blog post. Firstly, I have become aware of an attack on SSL Certificates by using a null value inserted in the domain name to trick the CA into issuing a certificate on an invalid domain. For example, www.natwest.com[null value].phishers.org will result in an SSL certificate being issued for www.natwest.com to the phishers.org site, which will appear valid in many browsers (but not all). Link to blog post. This won't (shouldn't) affect EV SSL Certificates though, only the Domain Validated ones.

Secondly, Comodo, to their credit, do admit that this is a problem and are takling it. They have sent me a link via email to a video clip, which in turn links to more information. That can be found here. The bottom line really is that these EV certificates are more secure, don't cost that much and should be the norm. As an industry we should be educating users into recognising and looking for these security features.

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this.

Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most other companies would say their DNS is secure. They do also have an automatic update process, which needs to be tested in my opinion, as this could be the target of attack.

Another alarming thing I have discovered is the following:

"To protect you against phishing attacks Rapport learns the password (and
sometimes even the username) you use with protected websites"(ref).

What? Where and how does it store these? What hash function or encryption is it using? This is potentially a massive security flaw. I did try this feature out and it does ask if you want to remember the details, but in my opinion it should never do this. Now the hacker doesn't need a keylogger anyway, as they can attack the storage of the password! Talking of keyloggers, I was sure that Rapport couldn't protect against rootkits, malicious drivers and all malware keyloggers, and the proof can be found here (a video of someone logging the keystrokes when Rapport is used to protect the ING Direct login showing that Trusteer's Rapport can be bypassed or cracked). I know that some will say that this requires particular malware and this may be detected with your existing AV product. However, don't forget that Trusteer 'guarantee' security even on an infected system. They are also encouraging lax attitudes towards using AV products with their rhetoric.

With these problems in mind, I decided to install Rapport on a virtual Vista machine with no AV and start logging a few things. The install writes to the file system (obviously) and the registry. However, in use, it is writing to the file system, specifically a set of encrypted log files. Further investigation shows that they are using encrypted JavaScript files to access and write to these log files. Rapport also runs a service on your machine called RapportService and was using about 10MB RAM on my VM. This service protects the Rapport files from deletion or modification as far as I can see. On install, the boot sector is updated to run this service at startup. However, if you stop this, then you can play around with the files. (To do this you will need to boot into Safe Mode by running msconfig.exe and selecting this option in the Boot tab. If you do this, then Windows Defender may block Rapport from restarting.)

The files of interest seem to be stored on a per-user basis. There are lots of log files that are accessed each time you hit a Rapport site. The main ones seem to be rooksbas.log, koan.log, backend.log and backend-cfg.log. Of interest though are the .cfg files and the JavaScript files. You have to enter a code during install, which may be just for registration, but may also be some kind of seed for the key, because the program itself must have the encryption key for these files. In which case, it should be a matter of reverse engineering the code to find that key and then everything becomes open (but this is just a guess on my part and may not be true). They don't tell you what algorithms they use for this encryption though, which isn't always a good sign.

Running packet sniffing software on the machine whilst connecting to http://www.rbs.co.uk/ I found a few things. Firstly, RBS is using ATDMT to track users' habits and install tracking cookies - a form of malware! Rapport didn't pick up on this tracking cookie or block it. Also, it doesn't appear to contact Trusteer directly, however, it does tell the server that it is running, as "Trusteer-Rapport/3.5.0903" was added to the userAgent string and the following data was also sent to http://www.rbsdigital.com/: "X-Trusteer-Rapport: ver=3.5.0903.22; ak=C056E35A634C288C2BA683A7B21DBC6274417C4CBF7FCE0CBB561651EE30EB60; av=a0; rs=0.01372". This makes me wonder how their secure DNS server comes into play. This wasn't the first time I had gone to the RBS site though, so maybe it is cached, but again, where? Presumably in those encrypted log files.

The problem for Trusteer is that the more successful Rapport is, the more it will become a target for attack, and the less use it will be. They are trying to do something good and it is another level of protection, but the false claims make it dangerous. I believe that this product will make users complacent and take less care of their machine and credentials. Why bother having any form of AV product if Rapport protects my details anyway? People are being educated into thinking that if they see the green box at the top of the browser then they are safe and I think they will then throw caution to the wind. Even worse is that if they use a browser other than IE, then they have no protection at all. I don't think this is drummed into the users enough on the third party sites that use this.

It goes to show the old addage that a little learning is a dangerous thing. You are teaching users only part of the story and they will get lost in marketing hype and false claims. Trusteer should be open and honest about the capabilities of Rapport and push for more user education, then I would recommend their product. As it is (forgetting the compatibility issues) I cannot recommend that system administrators install this on their machines and let users believe that they are safe no matter what.

Edit: I have a new post here and a series of demo videos of Rapport blocking spyware.

Edit (10/4/10): I am still getting a lot of hits on this blog post so I thought that I ought to point out that Rapport as a product has matured a lot in the last year and many of the problems with compatibility, etc., have been sorted out. Also, the marketing has changed a lot to be much more realistic. If this is used as a layer in your overall security arsenal and is combined with user education, then it will help to protect your machine, data and identity. Download a keylogger for yourself and try using it before and after installing Rapport and you might see why your Banks are pushing it. I still think that the Banks have a duty to educate their users and to standardise the process of conducting online transactions and authentication to help users and stop many of the attack vectors currently being exploited.

Trusteer's Rapport

NatWest have just sent through an important information letter to their customers highlighting a new security solution to help secure their online banking. They are using Trusteer's Rapport product (more info). Anything people do to combat malware, phishing, pharming, etc., is a good thing, and for this they should be commended. However, Trusteer make some bold claims and I'm wondering how true they really are. This needs a lot more investigation than reading through their sales rhetoric, but I'm going to get some of my initial thoughts down here, then see what I can find out.

The problem statement is well defined by Trusteer and centres around lack of user education. In a previous blog entry I wrote about 2 successful phishing attacks against an organisation that only needed one person to send an email containing their password to bring the whole network down (here). Users need to be educated into not handing out secret or personal information to anyone who asks, e.g. a bank will never ask for your PIN number - why would they? Again, see my previous blog entry as to what is happening with phishing, pharming and brand hijacking. One thing I find alarming is their statement:

"Recent malware in the wild have proved to be capable of bypassing the most advanced multi-factor authentication and security controls put in place... At Trusteer labs we have identified malware that bypass device identification, hardware and software tokens, client-side certificates, SMS authentication and transaction verification, and even card-readers..."

Well, I can see how some of these can be done relatively easily, but not all. I realise that a man-in-the-middle attack will defeat most, but if we can secure ourselves from the man-in-the-middle attack then we're fine in most cases. This is a big IF, of course, but SSL goes some way towards this (although it is also flawed in many implementations, but not in the way most phishers mount their attacks). The problem also comes from particular implementations being predictable, e.g. the RSA token that can be cracked if you know the Serial Number and the codes.

On to the Rapport solution. They claim that they can protect against: Man-in-the-Browser, Man-in-the-Middle, Keyloggers, Session Hijacking, Screen Capturing, Pharming, Phishing and Phishing Malware. Without going through all of these I will look at a few points. Firstly, let's look at keyloggers. This can't combat hardware keyloggers. It claims that it can combat software keyloggers by encrypting "all keystrokes from keyboard to browser." As I don't have an encrypting keyboard or driver, how does this work? Rapport is a browser plug-in, not a new driver. How does this stop me from rewriting the drivers on the machine and logging all the keystrokes? One wonders about the case for stopping this as well, because most banks only get you to enter three random characters of your passphrase anyway, and most have drop-down lists of numbers to select from for online PIN numbers (not card PIN numbers, which are never asked for). Also, what's the value of logging my one-time password? It's not valid by the time the attacker gets it. Having said that, combating keyloggers is a worthy goal and something we should implement if available.

Man-in-the-Middle attacks and Pharming attacks are both defeated, because Rapport "diverts traffic to the real website." How? If I have poisoned an external DNS server to point to my IP address, how do you know it's wrong, unless you have a store of my IP address already? Where do you store that? Can I update it? If not, what happens when the bank does change its servers? If this is done via strong authentication, how does that work? Is this like SSL, which has to have a valid certificate? A Pharming website won't have a valid certificate, so does this mean I'm safe? Only if I take heed of the warnings and assuming they can't update the local machine's store of the certification authorities (which you can do). Rapport supports automatic updates; are these secure or can I break into the update process?

"Rapport transparently terminates the connection to the proxy server and
diverts traffic directly to the real website."

Again, how without a list of the servers? Also, what about technologies like Microsoft's CardSpace? I know, it's Microsoft, so can we trust it, etc. However, by utilising something like CardSpace, the user doesn't enter information via the keyboard or in normal usage; it is done in a protected mode. Users can't enter their PIN number into a card that doesn't accept that information - indeed users wouldn't be the originator of the card in this scenario, so wouldn't be able to add information to it anyway. This looks to see if you are submitting the 'card' to the same site as before, by looking at things like IP address, etc. Doesn't this help against Phishing, Pharming, keyloggers and man-in-the-middle attacks? Incidentally, Rapport is only supported on XP and Vista - the same as CardSpace.

I will try to have a better look at this product and see if I can find out what the exact technologies are behind it. It may well be that their technology is secure and does help guard against these attacks, but it seems on the surface to be a collection of current technologies rather than anything new. In the mean time, NatWest should follow many other banks and institutions and get an EV SSL certificate so that the browser bar goes green and the site is authenticated by the browser with the certification authority directly. This seems as though it should be done even if other mechanisms are in place. However, I do admit that this only truly works alongside user education, but so does any security solution, including Rapport.