For most people working in IT, security is never far from the top of the priority list, and for PleaseTech we seem to get hit all ways because we’re an ISV but also a SaaS provider, our software often integrates with other applications (whether in the enterprise or the cloud), and we’re a distributed company that relies on many cloud and internet systems to get our job done.
We got off lightly with the Heartbleed virus because it does not affect Microsoft IIS, and by definition PleaseReview only works on IIS.
Heartbleed was a very interesting bug because it was such a simple coding mistake that could be understood, if not by everyone, then at least by non-programmers, whereas most attack vectors we see in software vulnerabilities are extremely sophisticated. Essentially what happens in a Heartbleed attack is that the client asks the server to “echo” back some data to show it’s still connected but, by lying about how much data it has sent, it can force the server to copy more data into the response than it should, and that extra data (which is just whatever happened to be stored in server memory at the time) could theoretically contain useful secrets.
Like many security glitches, this one comes down to the fact that C, the language used to implement SSL, allows a program to access blocks of “raw” memory rather than checking the start and end point of each variable being used. Because the attacker can’t choose which piece of memory to retrieve, he would have to rely on persistence and a large amount of luck to get anything useful, but the mass panic came because there was a theoretical chance of retrieving extremely sensitive information and nobody knew (or indeed still knows) to what extent it might have been exploited in the real world.
You can see that in this case, if you are a customer of, say, Dropbox, and a hacker uses the Heartbleed attack and happens to retrieve your password or credit card details, there is absolutely nothing you could have done to stop them.
Outside of direct PleaseTech business, I was affected by another internet security problem which is also quite simple and (hopefully) interesting to understand, and it is related to Hotmail hijacks.
If you’ve got friends or family that use Hotmail (which has recently been renamed Outlook, but let’s not confuse matters) you’ve probably received emails which appear to originate from them but are actually spam. Whenever this has happened to me in the past I have replied to the person in question saying that their Hotmail account may have been hacked and recommending them to change their password, but I’ve never really understood why this seems to happen with Hotmail (and less frequently Yahoo) but rarely or never to other providers. However, recently I was fortunate/unfortunate enough to witness a Hotmail hijack first-hand. Here’s how it works:
DISCLAIMER: I have described the nature of the attack to the best of my knowledge. I consider myself to be a pretty clever computer guy but there’s a chance I’ve gotten completely the wrong end of the stick about this whole thing. If you know better, let me know and I will happily withdraw this.
My girlfriend (who is emphatically not a computer geek) received an email apparently from a friend’s Hotmail account with a short piece of text and a hyperlink. Due to the format, I suspected it was spam but the text was something like “video of my recent holiday” so she had clicked on it before I could dissuade her. Up popped a video about a weight loss pill or something, so she realised it was spam and closed the window. Soon afterwards she noticed a lot of undeliverable and out-of-office replies coming into the inbox, so we checked the sent items and there were hundreds of them, all containing a short paragraph of text plus a hyperlink, and all sent during the few seconds she had the weight loss video on the screen.
This is called a "cross-site request forgery" (CSRF or XSRF). Basically because you are already logged in to Hotmail in one window, another window can also send requests to Hotmail which will automatically be executed under your Hotmail session. This was interesting to me because we have done work in PleaseReview to guard against exactly this type of attack.
There are well documented ways to guard against this kind of attack and recent versions of Microsoft’s own ASP.NET web development framework even have them built in. Why Hotmail doesn't use any of them is a mystery to me but it certainly explains why naïve users can have their Hotmail account hacked even when they have a secure password, whereas Gmail users don't suffer from the problem at all.
Hotmail detected the large amount of sent items, deduced there had been an attack and then made my girlfriend change her password and reset her security details. This might make the user feel like they have done something to counteract the spammers but as you can see, it doesn't make the slightest bit of difference to security because the attack doesn't depend on the spammer knowing your Hotmail password or any personal details, just on you clicking the link.
So how can you guard yourself against this kind of attack? This bug has been around for at least five years so don’t hold your breath waiting for Microsoft to fix it! Treat email hyperlinks that look like spam (i.e. where the text in the message doesn’t seem like the kind of thing your friend would normally write) with extreme suspicion and if you decide you want to click anyway just to find out, copy the URL and open it in another browser or in “private” browsing mode.
Following on from this, just last week there was an Internet Explorer vulnerability which could allow a hacker to access a user’s PC and run his own code. This was considered so serious by Microsoft that they even broke their rule of “XP support ends on April 8th” to release an immediate fix for XP. This isn’t quite so straightforward to explain but it basically comes down again to the fact that the software was written in C and so has no memory protection.
Similar to the Hotmail attack, this one means the attacker has to lure the user to a malicious web page but as we’ve seen, for many users that’s not difficult to do.
For all of us, both as suppliers and users of IT, it’s clear that online security is going to be an ever increasing part of our world. Even though bugs like these can be resolved, it would be extremely naïve to think we’ll ever solve them all when software is being produced at an ever increasing rate.
Plus of course, there are plenty of attacks that don’t rely on faulty software at all. In my own case I had to cancel my cell-phone account with EE because someone else was repeatedly calling up their support line claiming to be me but to have forgotten their password, then they would change their home address and order a new phone to be charged to my account. Even though this happened around 10 times in the course of a single month, EE seemed unable to put in place even the most basic measures to stop it (like calling me on me mobile phone which would have quickly enabled them to ascertain that the “me” trying to change the account details didn’t even have access to the phone connected to the account).
So the only lessons here for suppliers as well as customers are to be continually vigilant, understand what security threats exist and do your best to mitigate them, but don’t rely on any “silver bullet” to resolve your security issues..