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.

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.

InfoSecurity Europe 2009

Well, a couple of weeks ago I went to InfoSecurity Europe 2009 at Earl's Court, as I do every year. If you've never been, but are at all interested in network and information security or are looking for vendors, then I highly recommend visiting. To my surprise, and for the first time I can remember, Microsoft wasn't there. Apart from that, however, all the usual players were there and, to be honest, it was all much the same as before. There was no new emerging technology or hot topic, just new developments of old technologies. A couple of years ago we had the hot topic of 'social engineering' and 'securing the user'; ok, we all knew that the users were our weak link and phrases like "we spend all our time securing the first 2000 miles and forget about the last 2 feet", and "our network would be totally secure, reliable and fully functional if we didn't let users login", have always been commonplace, but there were new mass threats, new education programmes and new tools at the disposal of net admins to deal with them.

However, this year was different; nothing really sprang out. OK, cloud computing and Software-as-a-Service (SaaS) has expanded and matured, but other than that we see the same products and services as before. What amazes me is how some vendors and speakers can get it so wrong and don't appear to understand the actual level of security offered or operating environment in which their products will be used. I'm not going to list actual vendors here, but how can an encryption solution for mobile users that doesn't encrypt the data at rest be viable? Encrypting network traffic is commendable, but not the only safeguard required. What if they now lose their laptop, mobile or pen drive? A secure USB pen drive vendor admitted, when questioned, that files were decrypted into the C:\Temp folder while in use, then deleted after encrypting for storage on the drive again. They couldn't tell me if this was a secure delete or a simple removal of the pointer in the file allocation table as normal. Regardless of the deletion process, however, how many applications can read and write to that folder? What's to stop me from writing a very small bit of code to monitor that folder every few seconds and take copies? This might be secure enough if it is on a corporate machine, but why not just store the file on it then and not bother with the drive?

Similarly, email security is always a problematic area, with almost no solution fitting the technology properly. The big advantage of email, and the reason we all use it, is that it is independent of firmware - i.e. it doesn't matter what hardware, OS or email app we use, it still works. Unfortunately, security was never built in to email, so every email is like sending an electronic postcard. However, I would argue that a solution that only allows you to send encrypted email within your organisation is of limited value. What about all your customers and partners? There are also still solutions that store your files on their servers and send a link to the recipient. Why trust your files to them? I asked several vendors how they deal with password transfer, only to be told that they don't. "It's up to the user how they tell the recipient what the password is," was a common reply. We know users are unreliable, why leave it to them? I had to transfer some confidential files to someone via email recently (the only transport method they would accept), only to be told that they didn't want the hassle of decrypting it, so could I send them in plaintext. Having got over that hurdle, they wouldn't give me a mobile phone number so that I could transfer the passphrase via a call or SMS (as people seem to need them written down), asking me to email it to them. I know there are technologies out there to solve these problems, but they aren't without any problems.

This is turning into a bit of a rant and I'm getting off topic, so back to InfoSec. I was pleased to see that there were some voices of caution out there about the wholesale adoption of virtualisation without considering the security implications. One that springs to mind is Steve Moyle who has produced 10 points to consider implementing on his blog here. Virtualisation is a good technology for a number of reasons, but it does bring in new security threats and it must be implemented with these in mind and secured accordingly. I do also think that cloud computing and SaaS could be very important to SMEs (Small to Medium-sized Enterprises) who don't have the in-house expertise or large budget. They can still have large enterprise-level configurability and security, without the overheads. Finally, people seem to be taking information governance and user education seriously rather than just paying lip-service to them. In all, the show was encouraging, but many vendors are not quite there yet, which only goes to highlight that the majority of organisations are not taking the new threat-landscape seriously enough and countermeasures must be lacking.