|
Contents
Introduction This morning, at around 05:30 UK Time an address in China accessed my main Gmail Account (via IMAP) and sent two e-mails to everyone in my contacts. Now there is no way that a dictionary based brute force would reveal my password, it's alphanumeric, unique to me and (more or less) impossible to guess, no matter how well you know me. So this raises three questions;
1. How did it happen? So why was the attacker allowed access to my account? There's three possible reasons;
Option 3 is highly unlikely as I never, ever, click links in e-mails. I also don't provide my password to anyone unless I've verified that the site is genuine. Option 1 is a possibility, although (one would hope) unlikely. This leaves us with Option 2: In a recent whitepaper, I wrote about the hazards of storing Plaintext passwords, and I believe I've been shafted (in part) through the laziness or incompetence of a developer. Part of the blame, however, must fall upon my shoulders - I've been far too lax recently and used the same password on multiple sites. Although I must shoulder part of the blame, it is time that the practice of storing passwords in plain text ended. Very few applications have a legitimate need to store credentials in this manner, and no website can objectively justify it. With that in mind, lets name and shame a couple of sites who's operators should know better;
A quick search would reveal I'm not the only person to have had their account accessed without their knowledge, Google's forums are chock full of angry users;
I'm the first to admit, I know better than to use one password across various services, but; How can we, as developers, expect the average user to follow best practice when we do not? Encouraging users to use different passwords for each service is nothing short of hypocritical if we then store those passwords in Plaintext. 2. Re-securing a compromised GMail Account So, we've looked into the possible sources of the breach. Now we need to lock the attacker out of the account. To do so, follow the steps below (Simply changing your password is Not enough); Account Security:
3. Preventing a Re-Occurrence So we've locked the attacker out of the system, and thoroughly checked our settings to ensure that no nasty surprises crop up at a later date. But, we need to take steps to prevent our account from being compromised again in the future. As I've already said developer laziness is only part of the issue. Although storing passwords in plaintext is unforgiveably bad practice, had I not shared the password across accounts, the attacker would not have been able to access my e-mail. Although Developers and SysAdmins often complain about users' apparant resillience against any form of education, from a users' point of view, it is equally difficult to ensure developers follow best practise. So although we'll always struggle to educate either group, you can change what you do. So let's take a look at what users can do to bolster their security; Secure Passwords A secure password should;
Methods of password generation vary between user, however the most common is as follows;
This works by allowing you to use the same password for multiple services, whilst minimising the damage a breach could cause. It does, however, require a bit of groundwork, and carries greater risk than utilising unique passwords. Creating a Tiered Structure Start by seperating the services/sites you use into several different groups (you may need to create additional groups, or even to use less);
Financial accounts encompass any system/service that allows you to make a payment without entering additional details (such as a card number), so this could include;
Never share passwords between the categories, and regularly re-asses the risk. If planned carefully, this method can reduce the number of passwords you need to remember, whilst not carrying as high a risk as sharing one password between all systems/services. Identify the Source of the Breach We've already established the various ways in which the attacker could have obtained our password, what we need to identify now is exactly how the breach occurred. A good place to start is to examine your recent usage: Have you provided the compromised password to anything/anyone recently? You may have provided your password to an application (On your phone/PDA/PC etc.), to a website (such as facebook), a shopping site. Create a list of any person, site or service that you have disclosed the compromised password to in the last month or so. Hopefully, the list will be quite short! Now you need to rely on those listed to be honest, contact them to see if they are aware of any recent security breach. Don't make the mistake of assuming that it must relate to a recent disclosure of the password, it may be that a site/service that you have used for years suffered a security breach. You may have such a long list of sites/services/people to contact that it seems unlikely the true source will ever be found. However, you should still contact the operator of these sites/services so that they are made aware of the issue. They may never admit to a breach, but you raising their awareness will help protect both yourself and other users from future breaches (especially if you complain about your password being stored in plaintext). For information on how to identify the IP address used to access your account, see the short HowTo at the bottom of this document. Regardless of whether you identify the source or not, you need to conduct a personal audit of your security arrangements. Ensure you change the compromised password wherever it is used, otherwise the attacker may compromise that account as well. Force yourself to institute and abide by password diversity controls, whether you opt to use the 'tiered' structure detailed above, or a unique secure password for each system/service. 4. Conclusion So now we've completed the three steps that should always follow a security breach;
We all get complacent from time to time, it's human nature to be lazy when no threat is apparant. Keep in mind, however, that these attacks could occur against anyone. It may simply be an inconvenient embarrasment (such as e-mailing your entire contact list), or it could be very costly (losing control of your Internet Banking account). It is far better to take preventative steps than to rely on re-active policies. It's far too easy to blame others, as the links to Google's forums show, the first reaction is to claim that Google are to blame. Perhaps their system has a hole? Perhaps the user/password database was leaked? These are both possible, but what does the user learn from it? If you don't accept responsibility for your mistakes, you'll make those same mistakes again and again. Do the right thing, send your contact list an apologetic message stating that your account had been compromised, re-secure the account and take steps to protect yourself from any further breaches. Even if Google were at fault, our account could still be compromised at a later date due to password sharing. Regardless of who's at fault, use it as an excuse to sit down and review your password control. It's becoming increasingly easy for users to find their accounts are compromised, as the number of Internet Users increases, so does the potential for 'cybercrime'. Take steps to protect yourself before the worst happens. 5. Final Note I was lucky, the spammer simply sent the following message to my contacts (in 2 batches of half my contact list); Dear friend i am glad to tell you a good news ,and i find a good website ww.ebbisr.com On this website ,you can find many new and original electronic products .Now they are holding sales promotion activity, all the product are solt at a discount. And i have bought sine products from this web, the quality is very good , the price is very cheap and competitive,the delivery is on time . Hope everything goes well. Greetings! However, it could easily have been far worse. As I've mentioned above, it's very easy to think "What would anyone want with my e-mail?" Here's a short list of the different uses the attacker could have had (scarily, it's far from exhaustive)
Technical Details The attacker accessed my GMail account using the Web Interface from IP address 115.49.39.211 at 05:34 on 5th of October 2010. The first e-mail sent was sent to approximately half my contact list, each of which was detailed in the CC: field. The second was sent to the remainder of my contact list with each recipient detailed in the same manner as the first. Google's new 'abuse prevention' system detected that the account was being accessed from China, and alerted me to this when I logged into the Web Interface. It did not, however, prevent the mail from being sent (it's not been designed to), which rather negates the point in running an intrusion detection system. Howto: View your account's access history in GMail If you don't know how to view which computers have connected to your GMail account, follow these simple steps;
I'm very keen to hear from any users who have been similarly affected, or even believe they may have been. Please use the Contact Me page to tell me your story. I'm happy to offer help for those struggling to clear up the mess afterwards, or to give more detailed advice on the steps that you can take to protect yourself. If you know any GMail users, please direct them to this page! |
|
This page contains a Benscomputer.no-ip.org Premium Article and is copyright Ben Tasker. No reproduction, distribution or adaption is permitted without express written authorisation being given in advance. If you would like to use this article, please use the Article Use option of the Contact Me form to request permission (please ensure you include contact details). |
||
All Images operate under a seperate license Please read this page for more information. The Full Image License can be read here |
|