Internal cyber attacks - more thoughts

I presented on a panel today at the European Information Security Summit 2015, entitled 'Should you launch an internal cyber attack?' We only had 45 minutes and I thought I'd share some of my thoughts, and what I didn't get to say, here.

Firstly, as we all know, the concept of a network perimeter is outdated and there is a real blurring of whether devices should be considered internal or external these days. It's not just about BYOD, but most organisations provide laptops for their employees. These laptops get connected at home, airports, hotels, etc. Any number of things could have happened to them during that time, so when they are reconnected to the network, they may have been compromised. For this reason, it should be every system for itself, to a certain extent, in the network, i.e. assume that the internal machines are compromised and try to provide reasonable levels of security anyway.

Secondly, the user is the weakest link. It has been said many times that we spend our time (and budget) on protecting the first 2000 miles and forget about the last 2 feet. This is less and less true these days, as security departments are waking up to the fact that education of the users is critical to the security of the information assets. However, the fact still remains that users make mistakes and can compromise the best security.

So, should we launch internal cyber attacks against ourselves? Yes, in my opinion - for several reasons.

Internal testing is about audit and improvements. If we launch an internal Pentest or Phishing attack, we can see the effectiveness of our controls, policies and user education. The critical point is to not use the results as an excuse to punish or name and shame - this is not Big Brother looking to punish you. If a user does click on a link in a Phishing email then we should see it as our failure to educate properly. If a user bypasses our controls then our controls haven't been explained properly or they are not appropriate (at least there may be a better way).

An example was discussed on the panel about people emailing a presentation to their home email account to work on it from home. In the example, this was a breach of policy and, if the categorisation of the presentation is confidential or secret, then they shouldn't be doing this. However, rather than punish the user immediately, try asking why they felt that they needed to email it to their home computer. Was it that they don't have a laptop? Or their laptop isn't capable enough? Or that they think they are doing a good thing by emailing it so that they don't have to take their corporate laptop out of the office as they know they're going to the pub for a couple of hours and are worried about it getting stolen? There are motivations and context to people's decisions. We see, and usually focus on, the effects without stopping to ask why did they do it? Most people are rational and have reasons for acting as they do. We need to get to the heart of those reasons.

Education is critical to any security system and as security professionals we need to learn to communicate better. Traditionally (and stereotypically) security people are not good at communicating in a clear, non-technical, non-jargon-filled way. This has to change if we want people to act in a secure way. We have to be able to explain it to them. In my opinion, you have to make the risks and downsides real to the user in order to make them understand why it is that we're asking them to do or not do something. If you just give someone a directive or order that they don't understand then they will be antagonistic and won't follow it when it is needed, because they don't see the point and it's a hassle. If they understand the reasoning then they are likely to be more sympathetic. Nothing does this better than demonstrating what could happen. Hence the internal attacks.

The next question we have to ask ourselves is what constitutes the internal part of an internal attack. Is it just our systems, or does it include all those third party systems that touch our data? I could quite happily write a whole blog post on outsourcing to third parties and the risks, so I won't delve into it here.

I do also have to say that it worries me that we seem to be educating our users into clicking on certain types of unsolicited emails that could easily be Phishing attacks. An example that I used was the satisfaction or staff survey that most companies perform these days. These often come from external email addresses and have obscured links. To my mind we should be telling our users to never click on any of these links and report them to IT security. Why shouldn't they ask our advice on an email they're unsure about? We're the experts.

One final point was suggested by a speaker, which I think is a good idea. If we educate users about the security of their family and assist them with personal security incidents and attacks as if they are those of our company, then we are likely to win strong advocates.

Encrypted ZIP Archives Leak Information

This post is just a quick note to remind people who use encrypted ZIP archives to store or transfer confidential information, that the headers of the archive are not encrypted. Therefore, the filenames, dates and sizes of all the files within the archive can be read by anyone, without the key. Is this a problem?

Well, I believe it is. Many people and organisations have naming conventions for files. How do you know which report to open if the filename doesn't give you some clue? Often filenames will include project names or codes, departments and even the names of the people writing the report. Would you give this information out to anyone walking down the street? I have seen targeted Spear Phishing attacks on users whereby emails have been sent with what look like project spreadsheets attached with the correct naming conventions and project codes. These attacks were very convincing for an unsuspecting user. Filenames can leak enough data to start launching social engineering attacks and to concentrate cracking effort on the correct files.

What can you do? Either don't use encrypted ZIP archives to send sensitive data, or rename every single file to random names before adding them to the encrypted archive (remember that you should really do this to all files every time you want to add anything to an encrypted archive, even if the filename doesn't reveal anything as otherwise you will again be potentially advertising the really sensitive files).

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.

Password Protect Your Mobile

I know that many security 'professionals' will scaremonger and preach doom and gloom at every turn in order to drive up sales. However, they're not always wrong. I read the article 'Mobile device users fail to take basic steps to protect themselves, survey finds' and wanted to relate an event that happened this weekend. Many people are saying that mobile device security threats are hype and that nobody is actually exploiting them. That's possibly true to a certain extent at the moment, but for how long? Another article claims that identity theft is now more profitable than car theft! A mobile phone is a very good start for this purpose.

An interesting figure that comes from the article above is that 160,000 mobile phones are lost or stolen every day. I assume that this is just in America, as in Britain the figure is around 20,000 a day. Whether or not these figures are accurate is immaterial, the fact remains that a lot of phones go missing. What do you have access to from your mobile?

The recent incident that I mentioned above happened on Sunday. Someone left their iPhone at a sports training ground I was at. On inspection of the phone, there was no authentication set on it at all. I was able to see photographs, names, addresses and telephone numbers of family and friends. In addition to this, they had a Facebook App, which was still signed in. It would have been very easy to update their status with a malicious link for all their friends to visit. Worse than this, however, was the fact that they had access to their corporate email and address book from the phone - a FTSE 100 company. Again, this was still signed in with no additional authentication required. What corporate information could I have gained access to?

As it was, a phone call to the telephone number entered as 'Home' enabled the phone to be returned without stripping data off it or sending phishing messages. However, what if someone else had picked it up? The survey in the article stated that, of those interviewed, over 65% used their mobile phone to access corporate email and networks. "Do you send or receive sensitive information via email?" should have been the next question.

Businesses and employees should think carefully about the data held on their devices and the level of access they have to the corporate network. At the very least people should always have some form of authentication set on their phone, e.g. a PIN, password or stronger authentication. The majority of users leave applications, such as email and social media accounts, perpetually logged in and many users leave their devices unlocked. Even when they are forced to lock them due to policies, they don't always really secure the device. I have seen many users with corporate phones that require passwords use simple passwords (such as 'qwerty') so that they are easy to type. They site difficulties in typing complex passwords as being the major reason for choosing simple passwords, which is in line with the findings of the survey.

The bottom line is that these devices are part of the corporate network, whether the IT department is aware of them or not. They need protection. Even as an individual, protect your identity and your contacts by employing automatic locking of your mobile with passwords or long PIN numbers and don't leave apps permanently logged in. (I find it surprising/worrying that I have to give this warning/advise!)

City Link and Gathering Data for Spear Phishing

I have just been sent an email giving me a tracking number for a City Link parcel due to be delivered. On checking this on their website, I found that I only need the tracking number to track the parcel and no other information. Is this a problem?

Well, I think it is. Via my tracking number I am able to find the company name of the sender and my postcode. Now, postcodes normally only relate to around a dozen properties at most. However, that's not the end of the story. By entering different numbers (based on the one that I received) I was able to get the details of other parcels being sent around. Incidentally, their format is AAAddddd - representing three uppercase letters followed by sequential numbering.

Does this matter? Well, by going backwards through the sequential numbering system I was able to find a parcel that had just been delivered (at 13.50 to be precise) to a postcode in West Yorkshire - BD22 (I have omitted the last part of the postcode here). Helpfully, they include the surname of the person that signed for the parcel. Then it was a simple matter of doing a quick search on the properties to find someone with the correct surname. I found Denise and Jonathan X living at that address for a number of years and was able to find additional information, such as the fact that Jonathan worked for a local University. Crucially, I was able to find email addresses for them. It would now be very simple for me to launch a phishing attack on them as I have real details with which to trick them. There is simply a privacy issue here as well. Do you want anyone and everyone knowing what deliveries you receive and from which organisations? This could make a very good profile.

How hard would it be for City Link to require some additional information before giving out the detail? A simple solution would be to ask for the correct postcode in addition to the tracking number, then it would be much harder for someone to extract the details. They have included a captcha that kicks in after a few attempts, but this doesn't work, and simply entering anything in the field over the minimum required length and containing a space will be accepted. Also, cycling through IP addresses or performing the requests slowly will bypass this requirement. Anyway, I'm off to write a script to extract the details for the postcodes of City Link employees, MPs and newspaper reporters to see where they shop...

Skype Phishing from ONLINE HELP

It seems that many users are receiving Phishing phone calls through Skype from a profile called 'ONLINE HELP'. This call, if answered, plays a recorded message telling the user that their computer is not protected and that they must go to visit www.hosog.com. If you do visit this site, it is riddled with malware. This is a phishing scam!

The user account that I have observed is drationlinehelpgb and shows as being registered in the US, but seems to have been taken down now. However, others have reported a user account of drajizonlinehelp, which appears to be registered in Afghanistan. This one is still live at the time of writing and is using the same 'ONLINE HELP' profile name. It would appear that new accounts are being created as the old ones are blocked by people and reported for abuse to Skype.

It is slightly worrying the number of people who are reporting having answered this call. If you receive any unsolicited calls through Skype from users outside your contacts, don't answer them. Indeed you should actually change your privacy settings in Skype if you haven't already. Choose the Privacy... menu item in the Skype menu to open up the Privacy settings tab in the Options dialog. Make sure that all the options are set to people in my Contact list only. I suggest that you also don't share your online status on the Web. You shouldn't now receive calls out of the blue from scammers.

The problem is that people are becoming trained into accepting connections in social media sites and it spills out into their other online activities. People still think that SPAM and phishing scams only happen over email. Actually, people are usually fairly vigilant with their email, so it is more likely to be successful if they try other avenues. Sophos did an experiment at the end of 2009 where they created two fictitious Facebook users, one with a profile picture of a rubber duck. They had thousands of people sign up to 'friend' them. How carefully do users check links from their 'friends'? It opens up a very good channel for SPAM and phishing attacks. As a general rule of thumb don't connect or share details with anyone you don't personally know through social media, voip, email, etc. Also, if you use these media channels a lot, you should think about investing in a security product to help protect you.

Google email Accounts Compromise

I was asked to comment yesterday on the story that emerged about the Google mail accounts that were compromised over the last few days, so I thought I'd put some of my answers down here. First off, Google wasn't compromised; a set of phishing emails were sent out and a fake Gmail login set up to harvest login details. These were used to set up forwarding rules to copy mail to another account.

Unfortunately, although a large number of people are aware of phishing and are (to a certain extent) vigilant, it only takes one person within the organisation to fall for the attack to compromise security. The scammers are becoming better at targeting people and making the initial phishing contact more believable to some people. Phishing is not just about email, although that is the most common avenue for the initial contact. Social media is also commonly used and we have seen the use of SEO to force phishing sites to the top of search engine rankings as well. User education is the only real way out of this.

Could this be cyber espionage? I would think that is most likely given the profile of those targeted. Information is worth a lot of money and political weight. In recent years we have seen a decrease in attacks designed to deface/destroy/delay/deny services and information. Instead, we are now seeing information and identity theft as major goals. Viruses won't necessarily stop your computer from working, but they will use Trojans to steal your login credentials. Malware now will silently sign your machine up to botnets rather than perform an obviously malicious action.

What can companies like Google do to stop this? Well, they can improve their SPAM filtering for a start. It is possible to eliminate the vast majority of phishing emails, which would drastically reduce the problems. However, many of the major vendors aren't strong enough on this. Secondly, user education would help a lot, but can't always help you against the best social engineers. To be honest, though, the governments and organisations that these people work for shouldn't allow the use of gmail, or other accounts (which have fewer controls than a corporate email setup), for official business and should educate their users to use different passwords, be vigilant, etc.

Spear phishing is a more difficult one to combat as it targets a specific user or group of users that the attacker has knowledge of. If I know your habits and who your friends are then I can use that information to trick you much more easily. If you receive an email or Facebook message from your partner, do you hesitate before opening it? The reason this doesn't happen more is that it takes background research and, by definition, targets very few people. This technique is only relevant if you want what that specific user has access to. Hence it is more likely to be information that they were after.

Another way to combat these types of attack is to use one-time passwords as well, so that intercepting a single logon only gives you access during that session, and isn't valid in the future. However, tokens are prohibitively expensive for Google to hand out to everyone. There are other solutions such as SMS tokens, but these aren't all that cheap, when multiplied up by the number of gmail users, and aren't without their problems. Software token solutions such as Swivel, GrIDsure, FireID, etc., are possibly cost-effective enough to be implemented and could drastically reduce the success of these attacks. However, none of these stop the man-in-the-middle (MITM) attack, so you could still hijack the session and set up a forwarding rule to obtain a copy of all their mail. Google do allow you to set up alerts and have to validate changes through a 2-step process, but you have to enable this. This should be the default for all of these services. Perhaps they could also add a footer to all versions of the email to specify where it has been forwarded to.

How worrying is this sort of attack? Well, that depends. Most people can be socially engineered - look at Derren Brown! For the individual, spear phishing is unlikely to be a problem, but with a lack of education they may well fall for a bulk phishing scam anyway (thousands do or nobody would bother). However, for those with access to secrets or other valuable information, it is a serious issue. It all comes down to how good the attacker is. I believe that HM Treasury is the most attacked entity in this country and that is mostly for information rather than evading tax or performing Denial-of-Service, etc. They should be worried about this type of attack.

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!

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

Surveys or Phishing Emails?

I was recently sent a survey from a well-known survey company (actually, on second thoughts, I'll name them: Capita) and it made me very cross. Why so cross? Well, I spend a considerable amount of time trying to educate people about their role in the security of the network and about phishing/social engineering. This is all undone by survey companies such as the one in question. See for yourself the email sent and use it as a template for future 'white-hat' testing.

Have your Say! Fill in your Staff Survey today!

Dear Colleague

It’s important to complete the Staff Survey to ensure your voice is heard! The purpose of the survey is to make further improvements to staffs’ working lives at Target Organisation.

Your responses will come direct to Capita Surveys & Research Unit, and will be totally anonymous. No one outside the research team – and certainly no one at Target Organisation – will know who has responded or be able to identify individual responses. The survey findings will be analysed by Capita Surveys & Research Unit and only aggregate results will be reported.

To ensure that you have adequate opportunity to participate, the survey closure date is date month year.

In order to participate in the survey visit:

https://sas.capitasurveys.co.uk/targetorganisation

and enter your password: AAdddd

If you have any queries or require support completing the survey please contact us at Capita Surveys & Research Unit on 0800 587 3115.

Yours sincerely

Cheryl Kershaw
Director of Surveys and Research
Capita Surveys & Research Unit

What's wrong with this? Many things! Phishing scams are on the increase and are one of the biggest threats to security at the moment. Targeted phishing, or spear phishing, is also on the increase and these surveys could easily fall foul of this type of attack. The survey emails are in a standard format with no personalisation. It appears as a classic phishing email, albeit with better grammar. It would be easy to exploit this 'legitimate' survey to ask for additional personal details. Points to consider:

1. There is no personalisation – ‘Dear Colleague’
2. The email doesn’t come from the organisation in question – staffsurveys@Capita.co.uk
3. The URL does not point to the organisation in question – https://sas.capitasurveys.co.uk/organisationname
4. There is no contact within the organisation presented in the email for confirmation – contact Capita Surveys & Research Unit on 0800 587 3115
5. They do not use an EV SSL certificate on their site, only DV – QuoVadis Global SSL ICA certifying that this is sas.capitasurveys.co.uk, which could be a phishing site for all a user knows, as it isn’t certified to be Capita or Capita Surveys & Research Unit (see post on EV versus DV certificates)

This would be very easy for someone to impersonate, particularly if they register a similar URL, such as https://sas.crapitasurveys.co.uk/organisationname and then use masking as well. Users are being conditioned into clicking on links without questioning their validity. All I would have to do is know (or guess) that this organisation conducts surveys of this type from an organisation like this. OK, Capita suggests that organisations publicise the survey, but this isn't always done well and can be used to produce a fake version before the real one goes live.

It gets worse though. When I phoned Capita Surveys, a nice helpful lady called Liz told me who they were currently providing surveys for (I won't give out the organisation names here as that would be irresponsible, but if Capita would like to check with me I can prove this). It would be very easy to quickly knock up a copy of their site with a similar URL and registered SSL Certificate, add in a few extra questions, send those emails and wait for the information to roll in. Well done Capita! They say they take people's security seriously and that answers are secure because they use SSL. However, I would beg to differ.

Capita aren't the only culprit though; I was also recently sent a survey for Microsoft from Mori, which was just as bad. They have to take steps to ensure that their surveys can't be hijacked for targeted attacks. There are anti-phishing technologies and techniques available that, whilst not infallible, would help, so why aren't they used?

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.

Anti-Phishing Sender Verification with GrIDsure

I have tried out GrIDsure with a set of users now to see how easy it was to use. I was using the Windows client 2-factor authentication solution I blogged about here. (If you don't know their product you must read either their website or my other blog post above before reading this post as it won't make a lot of sense otherwise.) It turns out that the users had no problem setting it up and using the login - no training required other than a simple explanation of how it works. Doing this trial reminded me of discussions I had with GrIDsure about their Enterprise version of their product, which is fairly new and has more features being added all the time. One feature that I thought was noteworthy is their anti-phishing verification.

Phishing, as you will know from here, is a big problem and is often spread by obscured links in emails, such as http://www.microsoft.com.phishers.org/, which has absolutely nothing to do with Microsoft, but is just a sub-domain of phishers.org. There are many ways to combat phishing, the best of which is user education and awareness. I have, for a while, thought that a solution similar to that of MasterCard's SecureCode could be applied to many emails and on-screen login pages to verify the sender. If you're not familiar with MasterCard's SecureCode, when you set up your credit card to have SecureCode, you enter a password and a phrase that is personal to you (any phrase so long as you recognise it and someone else wouldn't guess it). When you confirm payment for something you are presented with your phrase on screen and asked to enter three characters from your password. The point is that if you don't see your phrase then it isn't MasterCard, so don't enter your password characters. The problem would be spear-phishing, targeting individual users. In this case you could just copy the phrase and fool the user. However, you can't just attack a batch of users or all MasterCard users, for example.

GrIDsure have done something along the same lines to authenticate the sender of emails and other messages (with their SDK it could be made to do this for any number of situations). What their system does is send you a code which, along with your unique key, generates a particular grid. Only you can generate that grid, as only your devices have that key (devices plural, as this could be a desktop application and on your mobile phone). They then tell you what your PIN is on that grid. The verification is simple; enter the code on your device and read your PIN off the resulting grid, if it matches the one in the email it's valid, otherwise delete the email and ignore it.

This is just a very simple way to verify an email to make sure that it is not a phishing scam. Of course there is one issue - replay attacks. If an attacker copied the code and PIN from the email then they could verify any email to that user. However, this does limit it to spear-phishing individual users rather than a mass blanket phishing attack. This could be reduced if a timestamp were introduced as well, e.g. entering the date as part of the code to generate the grid, reducing the window of opportunity to the same day. I would like to see GrIDsure push this and eliminate replay attacks to help stop people falling for phishing scams. More people need to think about technologies like this to verify their emails - alternatively, they could just digitally sign them all as practically all email clients have the ability to verify a digital signature.

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

Cookieless Browser Tracking

We all know about tracking cookies and privacy. However, according to EFF it isn't necessary to use cookies to do a fair job of tracking your browser activities. According to their research browsers give 10.5 bits of identifying information in the userAgent string, which is supplied to the web server with every request. This is around a third of the information required to uniquely identify you.

They have set up a website to gather more data and give you a 'uniqueness' indicator for your browser, which you can find here. This data set is growing quite rapidly and will tell you how many of the userAgent strings they have received that are the same as yours. I managed to find a machine to test that was unique amongst the 195,000 machines they have tested. This means that someone could potentially track that machine even if cookies are disabled. Even if you come out with the same userAgent string as others, you can be narrowed down by using geolocation of your IP, browser plugins, installed fonts, screen resolution, etc. This isn't a new idea and others have tried it, like browserrecon. Of course if you have a static IP address then you are fairly easy to track anyway.

Various suggestions are made to help protect yourself, such as don't allow scripts to run on untrusted websites, which is fairly obvious. However, although this may reduce the amount of data given out from highs of 15.5 bits on a Blackberry or 15.3 bits on Debian, this won't stop the whole problem. It seems like the worst devices for giving out identifying information are Blackberry and Android phones, with minimum figures of over 12 bits. The best combination would seem to be FireFox running on Windows, which can be controlled down to only 4.6 bits (although highs are around double this), but this could just be because it's the most common combination.

What can you do? Don't visit untrusted sites. Also, you could change your userAgent string. It is just a text string stating the capabilities of your machine so that the web server can customise content to suit you. However, there is no real harm in tweaking this to fall in line with more common strings so that you are harder to track. You have to be careful here, because just removing most of the information will probably make your userAgent string unique. Alternatively, you could regularly change the string. Perhaps browsers should change the string with every connection? Plugins could do this, like User Agent Switcher. This would allow you to use different strings across different sites. Maybe hiding certain activities by temporarily switching the userAgent string would be useful.

FireFox and Opera are both quite easy to configure - type about:config or opera:config in the address bar respectively and navigate to the userAgent options. Internet Explorer is slightly more trickey, in that you have to make a registry change to alter the userAgent string. Navigate to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent] in regedit. Here you can create string values for 'Compatible', 'Version' and 'Platform' to control what is sent. Under the 'Post Platform' key are a whole bunch of additional parameters that will be added to the string, so you can change or remove these.

Proposed Pseudo-Code for Hacking Process

It is quite common in Information Systems to use pseudo code to describe a process. I have often thought that the same principle can be applied to the process of hacking an organisation, which may help people understand the process and how to protect themselves. Below is my proposal for this pseduo-code for the hacking process. This is very much a work in progress. I would welcome feedback on it and I will update it as suggestions are made or as I feel it needs revising.

organisation = proposed target
organisation.footprint(value, effort, risk)
profit = value - (effort * risk)
if profit > 0 then
  organisation.enumerate()
  select attack_type
    case DoS
      engage_botnet(myBotnet)
      myBotnet.launchDDoS(organisation)
    case Access
      organisation.gainAccess(myAccount)
      myAccount.Elevate()
      organisation.installBackdoor(myAccount)
      organisation.cleanUP()
  end select
else
  exit
end if

This highlights the fact that we only need enough security to make it not worthwhile attacking, i.e. it will cost the attacker more to compromise our system than they will gain. Who would spend £1m to get £10 worth of information? We don't need (indeed cannot have) absolute security, just enough to protect our system. It also highlights another interesting point. Perhaps we should make our countermeasures public - not the actual implementational details or versions, but the fact that they are in place, e.g. that we have an IDS. Consider blatant versus hidden CCTV cameras. Cameras in plain sight deter most criminals, whereas hidden cameras spy on criminals while they perpetrate their crime.

We want to make the risk of being caught/prosecuted value high, so that hackers require a higher value:effort ratio, which we won't give them. Given two identically protected organisations with the same value, would you attack the one that doesn't monitor activity or the one that does?

Obviously, the above is very vague and doesn't provide methods to complete these tasks, but that is not the point of this post. Backdoors and Trojans are usually relatively easy to install if you have the right level of access to the system, so much of your security is going to hang on stopping a hacker from gaining access. Gaining access to an organisation is usually performed in one of four main ways:

• Malware
• Sniffing
• Direct Attack
• Social Engineering

There are ways to protect yourself, up to a point. Some of the most critical are:

• Installing Antivirus/Antispyware
• Latest OS and Application Patches
• Enterprise-level firewall, with IDS/IPS, AV, etc.
• Personal firewalls on all mobile devices
• Secure, hardened configurations
• Browser lock-down
• Encrypted communication (e.g. SSL/TLS, VPN, etc.)
• User Education!

The last point is often overlooked as a critical security practice. Please feel free to comment.

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.

User-Friendly Multi-Factor Authentication with GrIDsure

I have been tasked with rolling out a trial multi-factor authentication system that must be user-friendly, secure, low-cost and have zero impact on the existing network and users who won't be on the trial. That should be simple!

A trawl round the InfoSecurity Europe show always helps, as you can get the latest state of play from all the major vendors. This year there were the obvious keyring tokens, SmartCards, USB tokens, SMS solutions and some innovative software solutions, including GrIDsure. Before making any decisions about the solution to go for, several things need to be decided, among which are: how much security is required? What is considered user-friendly to a normal, non-technical user? What metrics should we use for authentication?

To answer these we need to look at what authentication is first: Authentication is the binding of an identity to a subject. The subjects we're talking about in this case are users and we're trying to bind their digital identity, i.e. user ID, to them as an individual. There are four metrics we can use to query identity, namely:

• What they know - e.g. password, PIN, secret/personal information, etc.


• What they have - e.g. token, SmartCard, phone, etc.


• What they are - i.e. biometrics


• Where they are (in space and time) - e.g. particular terminal, logon hours, etc.

The most common form of authentication is username/password, but this is outdated, insecure and, usually, fairly easily cracked (but that's another post). The problem is that each of these on their own is not very secure (yes, even biometrics are not that secure used on their own in a large environment). If we use a combination then we can obtain secure, strong authentication (by strong authentication we mean that we are sure about the identity of this subject as it would be very hard to have all the required metrics otherwise). RSA-type tokens and SmartCards combined with a PIN or password are easy and obvious choices to deploy, but they have issues. They are expensive to deploy, as you have hardware costs as well as the authentication servers. From a user perspective, they have to carry round something else with them. That's not usually too much of a problem, as these are small devices or credit-cards, but you have to have a reader for a SmartCard. Lost or damaged hardware (or tokens that have run out of battery) have to be replaced at a cost.

OK, so we could use SMS, whereby a text message is received by the user containing a one-time password. This is often done by sending one on-demand to the user when they start the login process. What if the network is down? What if there are delays on the network? Well, we can deliver the password up front, i.e. when they log off we can send them the password to use next time they want to login, but then it's hanging around on their phone, which they might lose. So what's the solution? Well, I saw two products that are noteworthy: Swivel Authentication Solutions and GrIDsure.

Swivel's solution relies on either secure SMS or a Turing image (one that is human-readable but not computer-readable). The Turing image will show two rows of numbers, the first is 0 to 9 and the second is the numbers in a random order. The idea is that you have a PIN number that you remember and you read off a one-time PIN from the image. So, if your PIN was 2468 then your one-time PIN for this login attempt would be 7193 from the image below. If someone uses a keylogger, then it will be defeated by this, as that PIN won't be valid next time and it hasn't revealed the base PIN number that you remember. However, if someone uses keylogger and screen capture malware, then it could be read off and deduced - possibly a big ask. However, you could shoulder-surf the pattern as well. That being said, this is very easy to deploy and relatively cheap. Users find it fairly simple to use as well, and it has to be better than a static PIN.

However, there is another solution - GrIDsure. With GrIDsure, you choose a pattern on a grid to remember. The grid size and pattern length is configurable, but the standard is to have a four square pattern on a 5x5 grid. You remember this pattern and then, when you attempt to login, you will be presented with a 'random' grid of numbers. You then read off the numbers in your pattern. For example, if your pattern is the tick that GrIDsure use as their demo and you are presented with the grid shown below, then your one-time PIN number would be 0649. This would change every time you log in. This now defeats keyloggers and shoulder surfing, as each digit will appear more than once. So, even if you see or log the grid and someone typing 0649, there are 81 patterns that would result in this PIN on the grid shown below. It is important to remember that you do not type or click the grid. The grid is just an image; you type the PIN in on a standard keypad.

This can be made more secure by deploying the grid on your mobile phone as a Java applet rather than in the web page, thus defeating screen capture. The grids, in this instance, are seeded from the phone's unique ID, so someone else has to have your actual phone, not just the applet running on their phone. This is true multi-factor authentication, as it requires the physical phone and a pattern that the user knows, without both you cannot authenticate. Also, this is a cheap to deploy solution as most users will already have a mobile phone, and those that don't can drop back onto the single-factor one-time passcode by displaying the grid in a browser. Users also find this very simple to use, as many people already remember their PIN numbers as a pattern anyway. This also 'plays nicely' with other authentication, i.e. you can still use username and password for some users and GrIDsure for others as the desktop client accepts both. Similarly, the web portal is able to interface with virtually any web-based application as a single-sign-on solution. Of course existing users can still hit the services direct and use traditional authentication until this has been deployed to all.

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.