Allicient

According to this artcile in the Telegraph, a MI6 agent was being interviewed for BBC’s “The One” show when his fake moustache fell off. To be honest, I’m slightly baffled by this story and assuming its a bit of a joke. But in any event, I’m sure we’ll all feel safer in our beds tonight knowing whom the foreign security interests of our country are entrusted to.

Advisory note to up-and-coming foreign terrorist groups: if you come across a guy with an upper-class English accent, tweed jacket and dodgy moustache – shoot him first.

As a side note, I’ve recently found Opera (9.x versions) using about 80% – 100% CPU when browsing Javascript intensive sites; mainly GMail and Facebook.  It seems that others are having similar issues. GMail seems to be fixed by using the opposite of the advice given here, i.e. do an F12, then “Edit Site Preferences” -> “Network” Tab -> Change the Browser Identification “Opera”.  This could be a fluke, but it seems to have fixed things in GMail at least.

In my recent post I’d wrote about how useful it would be to have the facility in webmail services to check your past login times; well, this morning I signed into my GMail account and was presented with the facility to do just that, nice one (its right at the bottom of the page).  As you might say in Scotland – “oan yersel Google”.  Not only does it provide your current login details, and previous four login times with IP, but it also lets you clear any stale sessions from their authentication database – a very useful feature if you use a choppy internet connection like wireless or mobile broadband where you cannot assure you’ll always be able to “sign out”.

Now… I wonder what happens if I write something else… just kidding

While the issue of cybersquatting is generally very well documented, I think we’re just beginning to see the rise of a phenomena far more insidious and damaging – and it is likely to affect the average person-on-the-street much more than it does celebrity personalities or big business.  What I’m talking about is online identity theft, or maybe “profile theft”.  Most of the time when you hear the words “identity theft”, thoughts of horror stories start coming to mind, but have you considered your “online identity”?  By that, I mean social networking or “blogging” sites like Facebook, MySpace, Digg, and the likes – if you haven’t, then it may be something worth looking into.

In the days of olde, and by that I mean anything pre-dating circa 2000, most people didn’t have an online presence as such.  Email was really just beginning to be seen as something nifty, cool or vaguely useful (despite it being around since the ’70s).  When you wanted to contact someone, you’d use the phone, or you could send an SMS message on their funky new mobile phone, you could even write a note/letter.  At a pinch you could even go round to their place.  If you lost contact, you’d likely have to ask amongst your friends or family if they knew how to contact them.  Notice in all of these, you can easily establish someone’s identity – be it via face-to-face interactions, their voice on a phone, handwritting, etc – the act of communication itself carried enough information to identify that person as the person you think it is.

Now consider the situation we have today.  You want to find someone, you can use a multitude of online services from Facebook to Friends Reunited – that person may even have their own website.  You might be able to do a Google search and find online tracks left by them.  Unfortunately, there is little inate information carried online to actually identify a person unless you are directed to a specific URL or profile by someone you already trust.  So, what’s the problem; you can just make sure you’re a little more careful when you make contact with someone to make sure they are who you think they are.  But that belies the true natrue of the problem: other people may not use such stringent checks.

This might not seem a risk until you consider the scenario where someone else creates accounts and profiles in your name.  They may even take photos from your own legitimate profiles, or use publically available information about you to make it more convincing.  Somebody you knew years ago who is trying to look you up may inadvertantly make contact with the forgery (which if taken to an extreme could have some pretty serious consequences), or the impersonator may put up false information on the forged profile which is damaging to your reputation.

Preventing this is fairly difficult due to a number of factors:  there are a lot of sites where you can network or “locate” people, which means a massive work load if you wanted to check for impersonations; even if you manage to do this, then its difficult to get the forged profiles or accounts removed; it’s much easier and quicker for an impersonator to create new profiles or accounts, so you’re fighting a losing battle; any damage may already have been done – to use an old axiom, its like trying to lock the barn door after the horse has bolted.

The problem is basically down to the loss of authentication information that was present in the ways we used to do things.  You would recognise a person’s voice or handwritting, but that’s not there in an anonymous email or online profile.  Passing on of contact details also had a certain amount of inbuilt protection as there was an assumed trust in the person giving you the information and an ultimate authentication when you actually talked to the person you wanted to contact.  Ironically, a partial solution to this problem has been around since the early ’90s with the advent of a bit of software called PGP (Pretty Good Privacy), which was principally designed for secure email communication between people who didn’t have a secure channel to send passwords or encryption keys (the software’s designer, Phil Zimmerman ended up getting brought up on arms charges by the US government because of it, and is often praised for promoting free speech).  PGP brought with it the concept of a Web of Trust – which basically means that if you have met your good friend Bob in real life, then you can in the electronic world state that fact, in a very secure and unforgable sense.  Assuming both Bob and yourself have done this with your whole social circle, then if someone Bob knows wants to email someone you know but hasn’t yet met, they can email with some certainty that it is the correct person – and not have to meet in person or talk on the phone.  A simple situation where this would be useful is that one of Bob’s friend’s lives in the US but wants to do business with someone you know – timezones are difficult, so being able to email off-spec and know for certain its the correct person is a useful thing.

When I was in my early teens, I’d actually obtained one of the very first versions of PGP (through a 2.4Kbps modem dialup to a BBS… ahhh the days).  Immediately, I’d recognised the importance of the Web of Trust construction.  Unfortunately when you are still at school and all your friends live within a three mile radius, it has somewhat limited applicability.  I do however think this concept has yet to really manifest in the psyche of the general internet public, and when it does, we’ll approach our online relationships in a completely different manner.

Its all fine and well for me to talk about using webs of trust, but the problem exists now; so what can you realistically do?  Well, for starters create your own profiles on the major social networking sites.  You don’t have to use them, but having them established is a good start.  It means that if someone malicious creates a profile in your name then anyone looking for you will see a duplicate and alarm bells will be raised.  The second piece of advice would be to get at least a minimum number of people you talk to on a daily basis to be on your “friends list” – an impersonator will find this hard to do with people you talk to everyday and will increase the authenticity of your profile.  The third piece of advice actually flies in the face of the prevailing thoughts on identity protection: publish a physically verifiable contact detail; a mobile number would even suffice, just enough so that someone that wants to contact you can phone and actually determine its you.  If you’re worried about your personal details, “Pay-as-you-go” mobiles come in at little over £15 now, just use that as your online contact.

** Update, Tuesday 23rd September 2008: to see just how dangerous online impersonation can be, have a look at this article. This debarcle happening on Wikipedia no-less, who would have thought it. Ah-hem. The article here is also useful for background.

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.

Do you ever get the feeling that the information security industry is, well, missing the point? Yeah, intrusion detection sounds like a neat idea but if its “protecting” a network where an attacker can simply call up and trick someone into giving out the information – or at a pinch bung them £100 – then that £100k IDS appliance doesn’t seem quite as good an investment.

Somewhat ironically, I think the information technology industry of old had a better handle on things. They relied a bit more on trust, which in today’s world is seemingly a bad word. When you get down to the nitty-gritty, strong and layered trust models are the only way security can ever be successfully applied. For example, the *nix “last” utility – fairly innocuous at first sight, and been around for so long that its genius is sometimes overlooked – needs to be brought back out of the cupboard and dusted down (or at least the concept behind it). For the uninitiated, the principle of the “last” utility is that it shows a list of dates, times and terminals used to login to the system for each user, against which you can check your own login times and determine whether someone else has been using your account without your knowledge. Nice and simple. Given that you trust the system administrator to do their job and be fairly vigilant, the output of “last” should at least be accurate; now the onus is on you to regularly check that the output matches your use – which take almost no time at all. To cap it all off, on most *nix platforms you get a nice helpful message when you log in telling you when you last logged in – brilliant!

Now apply that scenario in the context of your web-mail account, whether that be Gmail, Yahoo, Hotmail or whatever; if your password is compromised how would you ever know your account is being accessed without your knowledge (unless the attacker is really stupid and decides to mess about with your mail)? There are a multitude of possible vectors for your password being compromised: key-logger at the internet café you’ve just used, malware on your home PC, phising attack, someone “shoulder-surfing”, the list goes on. To make matters worse, there’s no way of mitigating – you cannot apply IP address restrictions on your webmail account – its not available and just impractical anyway. Even if you change your password as frequently as once a day, if your account is compromised just once then all mail in your account is readable and now in the open. For me at least, I would appreciate the ability to check my login records to at least determine whether my password has been misused or not – and it would be at very little cost to the webmail providers (as far as I know, this information is kept anyway)**. And before I get shouted at, yes I have suggested this on many occasions to webmail providers with no response. Go figure.

** Update Thursday 18th September 2008: GMail now has this ability, cool huh?  See this post for more details.