Allicient

I love it when you can determine something about the hidden internals of a system only from superficial behaviour.  For example, the idea of being able to detect the presence of a black hole from it gravitational effect on other visible objects like starts struck me as pretty neat.  Anyway, not quite as stellar, but I’ve noticed a curious Gmail phenomena: if you look into the “spam” folder, then for almost every page load, the advertisement that appears above the mail list is for some type of Spam food product (seriously, try it).

More intriguing than the sheer variety of Spam products advertised is how Google’s contextual placement is deciding to put those advertisements there.  It hasn’t come from the contents of the emails, unless I happen to be the only person on the planet receiving a load of spam mail about Spam (oh, the irony, ah-hem) – so the only possible answers must be that either its been hard-coded in (and the advertisers probably deserve a discount), or Google’s contextual system is not only basing its decisions on the content of the emails but the surrounding page structure.

I’m guessing it must be hard-coded, as I doubt any user would want to see advetisements based on the content of spam email – you really never know what it would generate.  Which means at some point they’ve tweaked those adds only to generate advertisements for products containing Spam…hehe.  Monty Python lives on.

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

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.