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.

Wireless Network Security Recommendations

Wireless Networks are still causing businesses problems. By their very nature they are insecure, as they are a broadcast network that frequently extends beyond your physical boundary - remember radio signals don't stop at your door. There ARE security mechanisms to make them secure, but too often these are not implemented properly or are circumvented by users. It is vital that all traffic on the wireless network be encrypted, and connections authenticated, otherwise anyone with a laptop can view all your traffic. There are many mechanisms for achieving this, but at the very least you should use WPA with long pass phrases (not simple passwords) and MAC address authentication.

Don't use WEP; it can be broken easily. I won't bore you with details here, but I refer you to Google instead. However, there are several flaws such as using a linear Integrity Check Value, such that predictable bit-flipping can be used to send invalid messages that will appear to be valid. Secondly, the 40-bit shared secret is 'extended' by use of a 24-bit per-packet Initialising Vector. As any cryptographer will tell you, the more often you use the same key, the easier it is to recover the plaintext (particularly if you have known plaintext, which we do have in the headers of network packets of course). IV collisions happen surprisingly quickly, especially on corporate wireless networks, as they will usually have reasonably heavy load. TKMaxx found this out the hard way when they lost half a million credit card details to a hacker sitting in their car park. This also shows that they almost certainly didn't segregate the traffic and force it through a firewall.

So what can we do about this? Well, all modern equipment will support Wi-Fi Protected Access (WPA) and WPA2. A standard implementation of this is to use a Pre-Shared Key (PSK), i.e. a pass phrase, and the AES block cipher for encryption. This is the minimum requirement for a wireless LAN. Again, don't use simple passwords, as the security of your system is relying on them. You should use long complex pass phrases, with punctuation. Another idea is to encrypt a pass phrase using itself (or another) as a key in an encryption tool; then use the resulting base-64 encoded string as your PSK. However, automatic key negotiation and the use of digital certificates is a better option in a corporate environment (remember for wireless access you can run your own internal certificate server so that you don't incur additional costs).

This doesn't solve everything though. A little while ago the head of a department in an organisation I was involved with decided that he didn't want to have to use the docking station for his laptop as it constrained where he could work in his office. So, he didn't contact the IT department, but instead went to his local IT retailer and bought a cheap wireless access point. He plugged this into the network and, not only did he not configure any security, but he didn't even change the default password on the device. Do you categorically know that you don't have a rogue access point on your network? This can be stopped by using technologies such as 802.1X port-based authentication and a RADIUS server.

Wireless networks also need to be treated as insecure and separated from your wired network via a firewall, with real-time virus checking and an Intrusion Detection System. This doesn't mean that they have to be unprotected themselves; you should still protect them from outside attack by firewalling them off from the Internet. The important point is not to let traffic flow, unchallenged, from the wireless network onto the wired network. This is not often done though. I was in Vienna recently on business and the hotel I was staying at had free wireless access for guests. However, one night I couldn't get access and asked why. I was told that they had switched it off as someone was trying to access their servers (they weren't very proficient or experienced hackers fortunately). The point that I found more worrying was that their public wireless network was directly connected to their servers, which the hold names, addresses and payment details of guests and even the door card programming details! You can imagine what could happen if someone were to get into the servers...

Wireless networks and wired networks should not coexist on the same subnets. This is for two reasons. Firstly, it is easier to attack and, therefore, attach to a wireless network, so you don't know categorically that all stations are legitimate. Secondly, most wireless networks are used to connect mobile devices, such as laptops and netbooks, to the network. Do you know that these haven't picked up any malware whilst not connected to your corporate LAN? You can address the latter with network access control, but that's a different topic. However, all traffic from the wireless network should be treated with a level of suspicion and therefore separated. You don't have to have a separate Internet connection or new wiring to achieve this; VLANs (or Virtual LANs) can solve the problem by logically segregating the traffic into the firewall. This also allows you to provide public wireless access for visitors/customers as you can run two separate, VLANed wireless networks through the same access points onto the network - one with limited access to the corporate LAN and the other with none.

Wireless networks can be implemented securely, but remember to separate your wired and wireless networks and implement secure encryption and authentication.

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.