Sony to send password reset email

Sony have detected someone trying to gain access to their various networks again, by using ID and password pairs that Sony conclude have been extracted from someone else's network. This may be a valid conclusion as it was only a small percentage of users that were affected (less than 0.1%, which is still 93,000). Sony have been upfront and quick to react, disabling the affected accounts and putting out a notice.

However, their next step, according to the notice given by their Chief Information Security Officer (CISO), is to send all the users who have been affected an email asking them to change their password.

Cue phishing scam!

Surely some bright spark will now construct a phishing email to send out to everyone saying that theirs was one of the 93,000 IDs compromised and could they now change their password. A simple copy of the site would then enable someone to lift thousands of valid credentials from accounts that weren't compromised. The problem is that Sony's users are now expecting an email to arrive to tell them to change their password. The work to trick someone to follow a link has already been done by Sony and the media.

How about not sending an email? Instead, publicise the attack and that some accounts have been disabled (Sony has done this). Next, let the users come to the Sony sites and try to log in. Then you can inform them that their account has been disabled and what the password reset procedure is.

McAfee Secure Short-URL Service Easy to Foil

McAfee have launched a Beta URL shortening service with added security features. As Brett Hardin pointed out they are a little late to the game. However, there are so many abuses of URL shortening services that I commend them for trying.

Basically, what their service does is allow you to create short easy URLs (like any other service). However, unlike other services, when you click on the link, it opens a frames page with the content in the bottom frame and the McAfee information in the top frame. This information includes details about the domain you are connecting to, the type of company it's registered to and a big green tick or red cross to tell you whether the site is safe or not. This is decided by their 'Global Threat Intelligence', which will block known bad URLs and phishing sites. That's good, if it works.

I said above that I commend them for trying to provide this service. There are some obvious failings in their solution though, that render their protections useless other than to make it easier for people to phish users as the page has the McAfee stamp of approval. Below is their site working properly to block a known bad phishing URL.


As you can see, this site was blocked and marked as a phishing URL, which it was. Excellent, it's working! Hold on a minute though. Have a look at the screenshot below where I can access the same URL through their service by embedding it in an iframe. I now get the big green tick and I'm told that it is safe. You can see from the source that the iframe is showing the exact same URL as was blocked before. Incidentally, the page says that the site is a Business Internet Services company, which is extremely misleading as I can assure you that this wasn't put on a domain run by a Business Internet Services company.


Also, what about if I code my page to not accept being in a frames page? Then the service falls down again. The screenshot below is of Twitter accessed through this service. The problem is that I can hide all sorts of other links in the page to fool McAfee and the user won't see them. I know McAfee will block these URLs in time, but they will only be blocking the host page and they will have to block all of them. Also, if you click on a link within the page that directs you to another domain, then that is not checked, so I could just redirect you to a phishing URL and you'll still get the big green tick.


It's a nice idea, but it just doesn't work. Interestingly, other services also have some security in them. TinyURL, for example, wouldn't allow me to create a short URL for this phishing site in the first place as it was recognised as such. McAfee happily let me produce the short URL, they just blocked it later - not such a good strategy in my opinion. I know that a new phishing URL would fool TinyURL as well, but I particularly chose a URL that had been around for the best part of a month to give them a chance and I think TinyURL has done better. Incidentally, TinyURL also allowed me to produce a short URL for my test page. One good thing about TinyURL is the preview facility, but that doesn't protect me against a site that looks like the real thing.

Moral: follow any links at your own risk and don't think that a green tick makes it safe!

Which Browser is the Most Secure?

I was recently talking to a fellow security professional who develops secure plug-ins for browsers and we started talking about the security of various different browsers. Most of the talk around browsers centres around how fast they are and what sort of features they have, but rarely do people talk about the security of their browser. Unfortunately, the browser is one of your weak points on the network as users have the ability to navigate to sites containing malware or phishing attacks as well as install plug-ins or run scripts that are malicious. So, which browser is the most secure? Any guesses?

All browsers (and all security products for that matter) have security weaknesses and vulnerabilities. However, the architecture of the browser and certain features can make browsing safer. The feature I'm going to put forward first is web browser protection against socially-engineered malware (phishing sites). According to many of the big AV and security vendors, phishing is on the rise and set to be the biggest headache of this year. Two statistics worth quoting are: according to Trend Micro, 53% of malware is delivered via Internet downloads against only 12% via e-mail; and Microsoft claim that 0.5% of the download requests through IE8 are malicious and they block a download for one in 40 users every week. In January 2010 NSS Labs tested five of the latest browsers against socially-engineered malware. Their full report is worth reading, but I have shamelessly reproduced their main graph here.


According to NSS Labs, Internet Explorer 8 blocked 85% of these malware sites using their SmartScreen Filter. The next nearest was Safari 4 at 29% and 0.2% behind that was Firefox 3.5. Chrome 4 was worse, on only 17%, and Opera 10 was bottom of the pile, achieving less than 1% blocking. By far the best of the pack was IE8, but even that still lets through 15% of malware. An interesting and noteworthy aside to this is that I believe Safari and Firefox use Google's Anti-Phishing API and achieve a 29% blocking rate, yet Google's Chrome only achieves 17%. If you want to see what the SmartScreen blocking looks like in IE8, you can see an example below, where IE8 is blocking it and Comodo's Dragon (a Chrome derivative) is not.

Also, again according to NSS Labs, Firefox had an 'average add time' of 5.7 hours, the fastest, versus Microsoft's 6.7 hours. The average add time is how long on average does a user have to wait before a visited malicious site is added to the block list. Speed is very important here, but it does actually have to get blocked in the end to make this a valid metric. These figures are better than the other three browsers, which scored: Safari - 9.0 hours; Chrome - 14.7 hours; Opera 82.4 hours.


Having mentioned Comodo's Dragon now I will give you a brief introduction, if you haven't heard of it before. It is a free Chrome derivative browser from Comodo. This browser has been designed to be more secure than the average browser. It doesn't perform well in the above tests, but has several other features up its sleeve centred around privacy. Some of the main features include not sending the HTTP Referrer so that you cannot be tracked from site to site, it won't send crash and problem reports (so your history remains on your machine only), it highlights DV only secured sites and will give a visit history with the certificates. If you don't know the difference between a DV and an EV SSL/TLS Certificate then read this blog post. An example of the DV certificate warning can be seen in the screenshot below.


One problem I have with the privacy tag associated with this browser is the UserAgent string. I have blogged about Cookieless Browser Tracking by using the UserAgent string before. The point is that the string sent to a web server by your browser to identify its and your machine's capabilities gives about a third of the information required to uniquely identify you. There will only be a handful of machines with the same UserAgent string, especially if you stray from the most common browsers (IE & Firefox). I also think that 'Never save passwords' should be the default setting and 'Allow all cookies' should not be the default setting. It is a new browser though, and I'm sure it will improve over time as the company is committed to security in many guises. Certainly its positive features are good and something that other browser vendors should follow.

The next point is about actual downloads from the Internet. Dragon, and other browsers, will give a warning when downloading executable files, but will just download ZIP, PDF, etc., and allow you to open them without warning. Bear in mind that PDFs and ZIP archives can contain malware. IE8, on the other hand, will ask you to confirm the software used to open a download, regardless of its type. This will always give you the chance to opt out if it wasn't what you were expecting. Also, IE8 will tell you if it is a signed or unsigned download, if it is a plug-in or an executable. Other browsers do not support this feature. What does it mean though? Well, if I am a software vendor, like Adobe, and I want you to download and install my plug-in I will sign it with a digital signature. When you download it, you can verify the signature, which will tell you that I (or Adobe) created and signed the download and that nobody has tampered with it in the meantime. If the download isn't signed, then how do you know that this isn't a phishing or pharming site pretending to be Adobe (or intercepting the download with a proxy) giving you a version containing a Trojan or some other malware? The answer is that you don't!

So, you should only download and install signed plug-ins and executables. Unfortunately, Internet Explorer is one of the few browsers that will control this for you and it makes a distinction between signed and unsigned plug-ins even when they are installed. Which brings me onto my final point (as this post is getting very long and a bit like a rant). Internet Explorer is, I believe, the most attacked browser as it has, until recently, been the most widely used. Due to this, Microsoft has had to build it in a secure fashion, controlling all plug-ins carefully. Firefox, on the other hand, performs many of its tasks by using a plug-in architecture, even for standard functionality. As far as I am aware, there is little or no distinction between a 'built-in' plug-in and one installed from a third party at a later date. This is very dangerous in my opinion. Firefox now enjoys the top position for browsers and it won't be long before the hackers make the switch from attacking IE over to Firefox. I think it will be harder to secure Firefox against this onslaught than it will be for Microsoft to keep up with their architecture.

It is interesting to note that the speed of the browser runs roughly inversely to the graph at the beginning of this post, i.e. Chrome is very fast and IE is considered the slowest of the big 4. However, security always comes at a price - processing being a big loser. Could it be that the reason why IE is such a leviathan and slower than its rivals is because they're doing much more checking and keeping you much more secure? I think so. Microsoft have a way to go though and can't rest on their laurels. I will be watching Comodo Dragon with interest to see if they can really push for the top spot in terms of a secure browser. It certainly does something for user education and privacy.

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post.

How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't really any different from having a longer, stronger password, it's still single-factor.

The idea behind the Grid Card is that you have a set of random numbers shared between you and the bank that are very hard to guess. I only say very hard to guess because I don't know how they generate the cards in the first place and if this isn't truly random - which it almost certainly won't be - then you can predict parts of the grid given other parts of it. Randomness is a rare but essential commodity. There are 50 co-ordinates on the card and Coventry ask for 3 each time, giving 19,600 possible combinations, assuming they'll never ask for the same co-ordinate more than once per login (order doesn't matter as we're told which grid squares). Does this mean that someone would have to log all 19,600 combinations before they could regenerate the card? No. Each co-ordinate appears 1,176 times in the 19,600. Each pair of co-ordinates appears 48 times. There are only really 17 unique combinations of co-ordinates such that they aren't repeated (and that's a cheat, because one co-ordinate will appear twice if we have 17 as 17x3=51). However, it is unlikely that these 17 would get asked for in succession, so it would take significantly more observations before we have the whole grid, but we won't need the whole grid before we're very likely to be able to login. Indeed, there's a 17.3% chance that at least one co-ordinate will be repeated on the next login. Also, a shoulder surfer with camera phone (or CCTV cameras) could take a photo of the whole card in one go, so this is an authentication mechanism to be used only in the 'safety' of your own home.

This is, however, a step in the right direction, so they should be commended for it. What else do you need to login to Coventry? Well, a Web ID and date of birth, both of which are easily pharmed. So the security is based solely on the password and Grid Card, which is better than two passwords. They do also have an anti-phishing technique bundled in there as well. When you sign up you choose a picture that they will display during your login along with your last login date and time. If the picture or date is incorrect then this isn't Coventry (or your account has been compromised). It's good to add a picture here, because many people don't actually check the last login date and time even if it's put up on the screen. The picture is obvious and hard to miss though. These mechanisms don't really stop spear phishing (or targeted phishing), but they do stop blanket or mass phishing attacks.

It's about time more banks started issuing 2-factor authentication for login and Coventry should be congratulated on being amongst the first. However, we have to be careful about how it's implemented.

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

APWG Report 1st Half 2009

On 27th September the APWG released their First Half 2009 Phishing Trends Report. This provides some interesting/worrying reading. Most notably is the rise and rise of rogue anti-malware programs.

Rogue anti-malware programs are programs that run on a user's machine and falsely identify malware infections. They then inform users that the malware can be removed by purchasing their anti-malware program. The installed software, in many cases, does absolutely nothing. The malware author has made their money off the user and doesn't care about them or the fact that their machine is left vulnerable to other malware. However, there is another breed of rogue anti-malware that will install other malware onto the user's machine, often adding them to botnets or adding trojans and spyware. According to Panda Labs' Luis Corrons, rogue anti-malware programs are proliferating with "exponential growth. In the first quarter of 2009 alone, more new strains were created than in all of 2008. The second quarter painted an even bleaker picture, with the emergence of four times as many samples as in all of 2008."

Most of these rogue anti-malware programs have a common root - they even look the same. So how come they aren't detected as malware? Well, often they employ server-side obfuscation so that each version is slightly different, thus defeating some signature-based scans. Also, you have to remember that many of these don't perform any malicious actions and, therefore, don't trigger other alarms.

What can we do about rogue anti-malware? Well, simply don't trust anything on the Web saying that you are infected or that they will scan you for free. Do not install any anti-malware from a company that you do not know and always check for validity of links and downloads. There are many companies out there providing free basic anti-malware or sophisticated products for a relatively low price that are legitimate, such as: Panda Security, AVG, Comodo, Symantec, etc. If you do get infected by one of these programs then you need to remove it. Instructions for removing the most common ones can be found at http://www.anti-malware-blog.com/ - N.B. be warned that I have not assessed or validated their instructions and there is no guarantee that they won't cause other problems.

What about the rest of the report? Well, phishing is still on the increase, with reported phishing highs for the first half of the year exceeding those of last year significantly (about 7%). 21,856,361 computers were scanned to determine host infection rates. 11,937,944 were found to be infected (54%), which is an increase of over 66% from the last quarter of 2008. Banking trojan/password stealing crimeware infections rose by more than 186%. Finally, payment services have taken the top spot in the most targeted industry sector from the financial sector, although this is still a close second. To see how this compares, a previous blog post of mine on this shows how things have changed.

For more information about the Anti-Phishing Working Group, to report phishing attacks or to see their reports yourself, visit http://apwg.org/

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.