Allicient

In the past few months, I have become increasingly aware of a glaring problem with the security model banks, utility companies, et al, use for their customer services. So a slightly irate and vitriolic post follows…

As online security gradually improves, the security of telephone based services has either stagnated or actually deteriorated. The old maxim of a chain being only a strong as it’s weakest link is sitting in eager anticipation of again being proven correct.

The problems can be split into some broad classifications:

i) the protection against replay attacks that (most) banks use for their online services are not used over the telephone;

ii) authentication credentials are often shared between strong online and weak phone services;

iii) static personal details are used as part of the authentication process over the telephone;

iv) there is an invalid assumption made that the phone call is private and secure;

v) telephone requests tend to “trump” anything done via online services;

vi) unsolicited calls are made from banks to customers that require only the customer to authenticate;

vii) catch phrases are overriding common sense.

The first problem highlighted above, (i), can be illustrated by example. Most banks request only a subset of a “PIN” or password when authenticating to an online banking service, however over the phone almost all banks ask for the full login credentials. For example, the Co-operative Bank has recently improved it’s online security immensely: logins only request a subset of details, there is a second stage of authentication whereby a random selection of one of four preset questions are asked, and most importantly before any transaction can be performed it must be authenticated via a smart card + card reader device. However, upon phoning, the automated service immediately asks for the full PIN. The problem is exacerbated by (iv), specifically that online services are at least encrypted using SSL/TLS, however phone calls are easily tapped if the attacker is physically in the local area.

The second problem, (ii), has some not-so-subtle ramifications. If a phone call to a bank’s customer services is monitored by an attacker, they will often have the credentials necessary to login online. From an anonymity point of view, it would be much more favourable for an attacker to action transactions using the online service as opposed to the telephone service.

The third problem, (iii), is that most telephone services use an automated system that verifies account number against “PIN” or password, then passes the call onto a real advisor. At this point, the advisor will attempt to further confirm the callers identity by asking the standard “name, address, postcode, date of birth” questions. Unfortunately, unless you are the Messiah, things like date of birth won’t change that often. So considering that these details are usually easy to come by and are exposed over an unsecure line anyway, it is worrying that so much trust is placed in them.

The fourth problem, (iv), is that most banks, government departments, etc assume that the telephone is a secure method of communication. It is not. Technologically, it is trivial to tap a person’s phone line. I have lost count of the amount of very personal details and information that I have had no choice but to submit over the phone.

The fifth problem, (v), is that once you’ve authenticated yourself to a bank or similar institution over the phone – they will usually action almost anything. So if an attacker has managed to garner your authentication credentials from previous phone calls, they will pretty much have carte-blanche.

Now onto (vi). This is probably the most concerning development. In the last six months I have had a bank, a utility company, and several other similar institutions phone me without my prior request, then ask me to authenticate myself to them. Each time I have illustrated that I do not know who they are, and they they could be a complete stranger calling to obtain my details. Out of the lot of them, the only one to both understand what I was saying and to be able to appropriately authenticate themselves to me first was Scottish Power.

The last one is more insidious than it first appears, (vii). When I challenged the customer services representatives over (vi), the response I got to every question was “but it’s Data Protection”. It was obvious that the person on the other end of the phone understood what I was saying but it seems company policy generally overrides the security beneficial attribute of common sense. So the public are now left trying to swallow a bunch of meaningless catch phrases like “data protection” and “passing security”: I wonder how many of the people writing the guidelines for these departments has ever read the contents of the Data Protection Act.

There are of course mitigating factors. The two that come to mind are using a 3G mobile which has half decent encryption as standard for (iv), and caller id for (vi). However these are not always available and are not addressing the core problems: namely that trust in the security of phone services are vastly over estimated.

Ah well, rant over.

UPDATED 12th April 2010: Added [] extra meaning in title; changed author.

How many times have you looked at an apparent security measure and wondered what on earth was going through the mind of the person who implemented it?  Take the example of the humble garden shed; usually constructed from painfully thin wood panels nailed to a dodgy timber frame.  Then you look at the door and you see a padlock that looks like is was bought in a fire-sale from Alcatraz.  In reality, anybody wanting to steal from the garden shed would just kick in a few of the wood panels.

This sad state of affairs is pretty much what we’ve got as far as web and email security these days.  The recent proof of concept that created a real rogue CA certificate using MD5 collisions is a prime example. Everybody has known for quite some time now that MD5 is not collision resistant, it is so broke that collisions can be found within minutes on any standard desktop or laptop. That combined with the normal issues that arise with the use of HTTPS as I discussed previously really does leave web security in a sorry state of affairs.

There are sites that use decent certificate authorities (the ones that issue their certs using the SHA family and do more thorough checks before issuing a cert in the first place), and also implement HTTPS in a proper and secure manner. Most financial institutions, for example, follow good practice. Unfortunately, banks and financial institutions have also tacitly instilled a sense of trust amongst the web user. We assume online banking is secure, and online banking uses SSL/TLS: so other sites that use SSL/TLS must also be secure – and there-in lies the problem. It is in part why phishing sites work so well, we know our online banking is secure and the website in front of me is my online banking site… well, er, it certainly looks the same. How many times have you actually read and checked the warning your browser periodically spits out about certificate validity? For me its 50/50 at best, and I know better.

A fine example of this misplacement of trust was no better demonstrated than in a conversation I had the other day. The conversation in question was about how PGP public keys are exchanged. I’d highlighted that you have to get the fingerprint verified (either in person, over the phone, or by a trusted third-party keysign) before accepting or signing someone else’s public key. The response I received was somewhat dismissive – and this was from a group of information security professionals. Missing that one critical step may seem insignificant but it completely defeats the entire security model, hence rendering the use of cryptography in that situation nothing more than a big padlock on a wobbly garden shed.

So what’s my point? Firstly, technologies that employ the use of cryptography have to do it properly, or not at all. This blasé, half-assed, approach by developers and users alike is actually harmful; it takes hard earned trust from one area and transfers it into a wide-spread false sense of security. The second and more important point is that developers and system designers really need to shoulder much more of the responsbility. It’s not your email provider that’s going to have to deal with the fall-out of your account being hacked, it’s you. The business that’s purchased a cert from a CA that uses MD5 and had a load of their customers defrauded will have its reputation in gutter while the CA sits pretty.

The result of this is that its in our hands. If our browser spits out a warning about a site certificate, check it and find out why, then promply complain to the company in question. If your webmail provider isn’t using SSL/TLS properly then complain, if it’s not fixed then move providers. Probablty the best example of what end users screaming about an issue en masse can do is with Microsoft: for years their products were pretty bad in the security stakes, I would argue that there have been vast improvements since.

UPDATED 12th April 2010: Added [] extra meaning in title.

I recently wrote about keeping things simple .  Well, here’s an excellent illustration of what can happen when things get complicated….

The security, or more appropriately the lack of it, in online services is generally very badly understood (even by many IT professionals) and implemented even more so.  This is no more true than when it comes to session handling and the use of SSL or TLS.

For example, most webmail systems DO NOT provide any real sort of security when your local network is open (e.g. in most corporate LANs, on unsecured wireless like at the airport or your local cafe).  The reason, you may ask?  Well, at best most webmail systems only secure the login stage when your password is being sent (using the encryption and authentication provided by SSL/TLS protocols, aka HTTPS when talking about web sessions), it then reverts back to plaintext HTTP transfers for the rest of the session, i.e. when you’re reading or sending your emails (the only main-stream exception I know of is Google’s GMail which allows SSL/TLS sessions for everything, but is still weak for other reasons).  This situation is dismal on so many levels, but principally:

• the initial login page was sent over plaintext, so an attacker can modify it before your browser receives it and insert modified code to send (HTTP POST for example) your login details to their own servers first before redirecting you to the official login – SSL/TLS certificate verification probably wont help here as this stage is usually processed very quickly and the attacker can get a cert for their fake domain and servers quite easily – so most users will never notice;
• when you have passed the initial login, then a unique session id is created and is used to identify your browser to the webserver for each further page load (usually via “cookies” which are sent in the HTTP header by your browser) – unfortunately any attacker can also use this unique id in exactly the same manner as your browser (remember it is transmitted in plain text, only the initial login was HTTPS);
• all data you transmit and receive is readable as its in plaintext, so all the mail you read and send is counted here – this is perfect for those attackers who are a bit more lazy or non-intrusive;
• most webmail sites are also vulnerable to a more “classic” attack – when there’s a secure method of doing something and an insecure method implemented, at the same time, in the same system – an attacker is just going to force things back to the insecure method which in our scenario equates to being able to login to your webmail using either HTTP or HTTPS (which is often the case), if port 443, where https is usually served, is blocked by an attacker then most users will just use HTTP logins, see this article on a chip and pin attack for an elegant example of how this idea has been exploited in the past.

Most of these problems can be mitigated by doing the obvious (you would have thought); forcing all transactions with the web server for the secure services to be done via SSL/TLS, set the https-only flag on the cookies, have the secure service on a different domain (or subdomains) and don’t even open port 80 for that domain.  This means your browser will never send your session id in a cookie unencrypted, or it is at least several orders of magnitude more difficult for an attacker to force your browser to do so.  If you want to build in some ancillary assurance, an additional session id in the HTTP URLs and/or permutating the session id doesn’t hurt.  Disregarding the last two addition suggestions, an HTTPS only setup is much easier to confirgure and maintain than a mixed HTTP and HTTPS setup (anyone who has touched virtual host configs in Apache should understand why).  Unfortunately since HTTPS requires a lot more CPU effort (or a dedicated crypto processor), providers usually run a mixed setup to improve performance; which means in practice, usually either all further page loads are done over HTTP which renders the session completely open, or HTTP and HTTPS are mixed which is totally futile.  On a positive note, GMail is generally better than others but still has serious issues, see here and here for details.

These problems are not confined only to webmail systems, its not uncommon for major sites to be vulnerable in a similar manner despite using SSL/TLS (again the problems stem from basic design flaws), see this article at The Register for more information (Bank of America is in there).  For further technical discussion, and from what I can understand also soon to be available software, see some of the posts on fscked.org.

So, when using supposedly secure web applications, caveat emptor.

UPDATED 12th April 2010: Added [] extra meaning in title.