Admin rights to data should be given sparingly (or not at all)

I was reading a well-known telco’s document on the trade-off between productivity and network security recently. A lot of what they said is fair comment and they do have some helpful suggestions. However, their response to security risks, like those of many organisations, jumps straight for the technology solution with only a thin veneer of trying to deal with people.

Many organisations will talk about people and process and how important they are and that you need education programmes (most of which miss the point and are not terribly effective), but they say it as if they have been told to and don’t really believe it themselves. At the end of the day they will jump on the technology bandwagon and sell you/buy the latest bit of kit.

One statement in this document stood out though: “...full administration rights to all data are rarely appropriate for the entire workforce.” What? When are they EVER appropriate for the entire workforce? When is full admin rights over all data ever appropriate for even one person in the organisation?

I’ll give an example. Suppose you are an organisation that stores the financial data of your clients in a database. Should the network administrator have full admin rights over the data? Certainly not! Under what circumstance does the network administrator require any access to that data? What about the database administrator? Again, no. The DB administrator needs administrator rights to the database management system, but they don’t need to be able to read the actual data contained in the database. What about those users that may need access to the data contained in the database? Well, they can be granted access, but you wouldn’t give a user administrative rights over the data surely?

This also highlights the problem that many organisations have with leaking data. If you give people rights over the database they can extract the data, store it on their local machine and lose it or transmit it. What’s wrong with keeping the data in the database and accessing it from there? If you download it, you will only have a snapshot anyway. Leave the data in the database and protect it from everyone who doesn’t need access to it, which includes the IT department!

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.

IPICS 2010 Network Security Slides

My slides on Network Security and Steganography, presented at the Intensive Programme on Information and Communication Security (IPICS) 2010 can be downloaded below. The topics covered under Network Security are: Access COntrol Devices, Firewalls, Network Protection, Network Authentication Protocols, TLS, VPNs & Remote Access. The Steganography slides cover examples of: Image, Network, HTTP and Twitter Steganography.

A PDF of the Network Security slides can be downloaded from here.

A PDF of the Steganography slides can be downloaded from here.

Human Factors in Information Security - Errors & Violations

Human failures are often described as Slips, Lapses, Mistakes and Violations. These are grouped into two categories: Errors and Violations. The difference here is the intent - violations result from conscious decisions to disregard policies and procedures, whereas errors have no malicious intent. Also, violations often involve more than one form of misconduct, whereas errors are often isolated.

Don Turnblade has stated that in his experience "well trained staff had a 3.75% unintentional non-compliance rate; they did not realize that installed software compromised data security. About 0.4% of end users were intentionally non-compliant, generally willful persons with strong technical skill or organizational authority who were unaccustomed to complying with computing restrictions."

So what are the different types of error? Dealing with each in turn, we have Slips, Lapses and Mistakes.

• Slips - actions not carried out as intended, e.g. pressing the wrong key by accident. Slips usually occur at the task execution stage.
• Lapses - missed actions or omissions, e.g. forgetting to log out, or a step in a configuration process.
• Mistakes - occur due to an incorrect intention, whilst believing it to be correct, i.e. they are deliberate actions with no malicious intent, e.g. misconfiguration of a firewall. Mistakes usually occur at the planning stage.

So who causes the error or violation and how do we combat them? Slips and Lapses are usually the fault of the user, but can be mitigated by making it more difficult for the user to make the error, e.g. by having confirmation dialogs for slips and better training for lapses. Mistakes tend to be the fault of designers and are slightly more difficult to combat as designer education is required or outside technical expertise needs to be brought in. However, this doesn't always solve the problem if they don't have the skills and knowledge required. Finally, violations can often be laid at the door of the managers. It is often the case that a culture of violations is accepted by senior management, who fail to impose proper sanctions or take the threat seriously.

All of these have to be dealt with to have a secure system and most of it boils down to having proper user education and training in place.

Trusteer or no trust 'ere...

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

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

Another alarming thing I have discovered is the following:

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

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

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

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

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

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

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

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

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

Trusteer's Rapport

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

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

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

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

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

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

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

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

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

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.