The Anatomy Of The Twitter Attack(techcrunch.com)
techcrunch.com
The Anatomy Of The Twitter Attack
http://www.techcrunch.com/2009/07/19/the-anatomy-of-the-twitter-attack/
44 comments
In addition to what you listed, I think the article's point about one's password being findable in their mailfile is a great catch.
In order to be aware that someone has compromised your mail, it's essential that they not be able to reset your password to its old value. Therefore, your password for e-mail should never be findable in your mailfile, nor should it be the same password you use for any other web service. Because you never know what stupid web service will send your password to you in cleartext upon request.
Of course, it's not a good idea to share passwords among different services in general, but keeping your mail password separate is particularly important.
In order to be aware that someone has compromised your mail, it's essential that they not be able to reset your password to its old value. Therefore, your password for e-mail should never be findable in your mailfile, nor should it be the same password you use for any other web service. Because you never know what stupid web service will send your password to you in cleartext upon request.
Of course, it's not a good idea to share passwords among different services in general, but keeping your mail password separate is particularly important.
Mail and commerce. Those require separate and unique and crazily difficult to guess passwords. The problem is too many people just can't bother with the perceived hassle
I deliberately set up a secondary email address that I use for nothing else and has a unique but memorable password.
Then I just mashed the keys for the security question.
Then I just mashed the keys for the security question.
It's a pity that google docs doesn't have that SSL option
Google will have to eventually respond (with action) to that and more security concerns outlined in this June 2009 open letter to the Google CEO demanding 'security by default' from 38 leading security researchers including Bruce Schneier and Ron Rivest.
http://files.cloudprivacy.net/google-letter-final.pdf
http://files.cloudprivacy.net/google-letter-final.pdf
They did respond. Kind of.
http://googleonlinesecurity.blogspot.com/2009/06/https-secur...
http://googleonlinesecurity.blogspot.com/2009/06/https-secur...
but the original attack wouldn't have changed one bit with SSL. Peter Guttman wrote a great paper on how we defend where the attackers aren't attacking. SSL in this case would have been one such example. Of course, SSL has value in other cases (sniffing, ensuring you're talking to the right site, etc) but is no panacea.
It does for me, the link to Google Docs from my Gmail is HTTPS. Same for Calendar and Sites. Going directly to docs.google.com redirects me to the secure version--I think it works off the SSL by default setting in Gmail.
They were really cranking up the word count:
Now going back to Hacker Croll and his list of Twitter employees and other information. Twitter just happens to be one of a number of a new breed of companies where almost the entire business exists online. Each of these employees, as part of their work, share data with other employees - be it through a feature of a particular application or simply through email. As these users become interwoven, it adds a whole new attack vector whereby the weak point in the chain is no longer just the weakest application - it is the weakest application used by the weakest user. For an attacker such as Hacker Croll looking to exploit the combination of bad user habit, poorly implemented features and users mixing their personal and business data - his chances of success just got exponentially greater. Companies that are heavily web based rely largely on users being able to manage themselves - the odds are not only stacked against Twitter, they are stacked against most companies adopting this model.
Could be summarized as "Twitter used Google docs." Everything else in this paragraph repeats things from earlier. (And things from earlier repeat things from earlier.)
Now going back to Hacker Croll and his list of Twitter employees and other information. Twitter just happens to be one of a number of a new breed of companies where almost the entire business exists online. Each of these employees, as part of their work, share data with other employees - be it through a feature of a particular application or simply through email. As these users become interwoven, it adds a whole new attack vector whereby the weak point in the chain is no longer just the weakest application - it is the weakest application used by the weakest user. For an attacker such as Hacker Croll looking to exploit the combination of bad user habit, poorly implemented features and users mixing their personal and business data - his chances of success just got exponentially greater. Companies that are heavily web based rely largely on users being able to manage themselves - the odds are not only stacked against Twitter, they are stacked against most companies adopting this model.
Could be summarized as "Twitter used Google docs." Everything else in this paragraph repeats things from earlier. (And things from earlier repeat things from earlier.)
So if a hotmail account expires, they allow just anyone to re-register it as their own email address?
That sounds completely irresponsible.
That sounds completely irresponsible.
sure. but more irresponsible is that gmail doesn't recognize that the secondary address expired. It's fairly easy (with most MTAs) to structure a smtp session to discover if a recipient still exists. Google should be doing this regularly so they can alert users that they have a potential security risk if that email stops working.
more fundamentally, the idea of being able to reset passwords like that is kind of insane. I'm a fan of one of the paypal models- they verify credit cards by sending a unique verification pin to the registered billing address. Not saying that would work here, but it's a nice example of mixing online and real world, and institutes a time lag.
more fundamentally, the idea of being able to reset passwords like that is kind of insane. I'm a fan of one of the paypal models- they verify credit cards by sending a unique verification pin to the registered billing address. Not saying that would work here, but it's a nice example of mixing online and real world, and institutes a time lag.
I'm amused that some commenters (here and at TechCrunch) are accusing Google as the primary fault. I would say the opposite. Gmail is not perfect, but it has plenty of security measures compared to other mail services.
For most users, the idea of that kind of password reset is convenient. And it's not easy as you claim nor practical to regularly check the existence of alternate emails, especially with the amount of users Gmail have. And by the way, they already have a new feature wherein you can use your mobile number to retrieve a password reset code.
There is a feature in Gmail where you can see other currently and some previously logged in sessions. Perhaps it can be made more visible to the user, but it worked for me and had actually used it once to halt an intrusion (not really hacked, my password was automatically saved from another computer's Firefox).
Lastly, another feature that makes me feel safer with Gmail is HTTPS and the ability to force your session to HTTPS whenever you log in.
For most users, the idea of that kind of password reset is convenient. And it's not easy as you claim nor practical to regularly check the existence of alternate emails, especially with the amount of users Gmail have. And by the way, they already have a new feature wherein you can use your mobile number to retrieve a password reset code.
There is a feature in Gmail where you can see other currently and some previously logged in sessions. Perhaps it can be made more visible to the user, but it worked for me and had actually used it once to halt an intrusion (not really hacked, my password was automatically saved from another computer's Firefox).
Lastly, another feature that makes me feel safer with Gmail is HTTPS and the ability to force your session to HTTPS whenever you log in.
Perhaps it can be made more visible to the user
It's pretty highly visible, especially when more than one person is logged in at once - it's highlighted you bright yellow. It's a brilliant touch - I check this every once in awhile, but have yet to find anything.
It's pretty highly visible, especially when more than one person is logged in at once - it's highlighted you bright yellow. It's a brilliant touch - I check this every once in awhile, but have yet to find anything.
Yep. I tried to log into an old hotmail account last month and found that it had expired. I had no problem re-registering it. This is an inexcusable security flaw that should be obvious.
I'm guessing it is because all email providers recyle email ids/usernames after a period of inactivity. I don't know what Hotmail does but if I remember, they have a lockdown period (which is quite long) after which the username becomes available to the general public. I'm pretty sure Yahoo and Gmail do the same thing.
http://help.msn.com/%28cHJvamVjdD1ob3RtYWlscGltX2ZhcSZtYXJrZ...
A free Hotmail account becomes inactive if you do not sign in for 30 days, or within the first 10 days after signing up for an account. Once an account becomes inactive, all messages, folders, and contacts are deleted, but the account name is still reserved. If the account stays inactive for a further 90 days, it is permanently deleted.
I'm almost positive that the account I had to recreate was no more than 6-9 months inactive.
A free Hotmail account becomes inactive if you do not sign in for 30 days, or within the first 10 days after signing up for an account. Once an account becomes inactive, all messages, folders, and contacts are deleted, but the account name is still reserved. If the account stays inactive for a further 90 days, it is permanently deleted.
I'm almost positive that the account I had to recreate was no more than 6-9 months inactive.
Seriously? If I go traveling without internet access for over 30 days, they delete all of my stuff? Wow, no wonder GMail is kicking their ass :-/
Gmail accounts use to expire after a year of inactivity, but now will never expire on their own.
I'm pretty sure they have never recycled old addresses automatically.
I'm pretty sure they have never recycled old addresses automatically.
Disregarding the human "holes", I think the biggest hole here is Hotmail allowing expired accounts' usernames to be registered again. That should be a no-no considering the importance of the use of email as an identity. They can purge the account as it expires, but they should not let others use the username again.
Most others are just "best practices" that try to keep balance between security and usability. Except for the practice of emailing a password in clear text which compromises a lot of security for little usability gain.
Most others are just "best practices" that try to keep balance between security and usability. Except for the practice of emailing a password in clear text which compromises a lot of security for little usability gain.
Wow, a 3,900-word magnum opus. The nutshell:
(1) Hacker deduced from Google password reset that a Twitter employee had a Hotmail account as their secondary email for a personal Google login.
(2) Was able to re-register that dormant Hotmail address (!) -- and thus get the Gmail password reset.
(3) Saw a cleartext password confirmation from another web service among the Gmail archives; reverted the Google account password to that, in the hopes it would allow the compromise to evade the user's detection. That worked; the user continued to use their personal Gmail as normal.
(4) From there, extended compromise to other of that user's accounts elsewhere, including a separate Google Apps for Twitter account, which used the same password. Used information now visible -- internal Twitter docs, private coworker profiles, etc. -- to crack other employee accounts, likely by also deducing password-reset security-questions. Accounts compromised included Evan Williams and Biz Stone.
There's some hand-waving at this last step, but if the early-compromised employees were admin assistants, HR, or sysadmins, and/or if Twitter as a matter-of-course trusted Gmail-to-Gmail internal email as being a safe place to share setup passwords and other private information, it's plausible.
This branching-out to multiple accounts included "AT&T for phone logs, Amazon for purchasing history, MobileMe for more personal emails and iTunes for full credit card information" -- as there's said to be a flaw in ITunes that sometimes echoes back full credit card numbers.
(1) Hacker deduced from Google password reset that a Twitter employee had a Hotmail account as their secondary email for a personal Google login.
(2) Was able to re-register that dormant Hotmail address (!) -- and thus get the Gmail password reset.
(3) Saw a cleartext password confirmation from another web service among the Gmail archives; reverted the Google account password to that, in the hopes it would allow the compromise to evade the user's detection. That worked; the user continued to use their personal Gmail as normal.
(4) From there, extended compromise to other of that user's accounts elsewhere, including a separate Google Apps for Twitter account, which used the same password. Used information now visible -- internal Twitter docs, private coworker profiles, etc. -- to crack other employee accounts, likely by also deducing password-reset security-questions. Accounts compromised included Evan Williams and Biz Stone.
There's some hand-waving at this last step, but if the early-compromised employees were admin assistants, HR, or sysadmins, and/or if Twitter as a matter-of-course trusted Gmail-to-Gmail internal email as being a safe place to share setup passwords and other private information, it's plausible.
This branching-out to multiple accounts included "AT&T for phone logs, Amazon for purchasing history, MobileMe for more personal emails and iTunes for full credit card information" -- as there's said to be a flaw in ITunes that sometimes echoes back full credit card numbers.
The million dollar question: would we have been so interested in how the attack was made if we hadn't had at least a glimpse of the compromised information? In other words, could TC argue that publishing the confidential information was a valid way of raising awareness of the security issue? I'm not convinced, but it's a tough one.
That's just about the worst excuse I've ever heard for unethical conduct. In my mind, this is the equivalent of "I trashed your house, peed on your couch and stole your wine cellar to show you how important a axe proof front door is."
I was talking about TC, not the hacker. Also, I made it clear that whilst I didn't agree, the question is a valid one.
[deleted]
After reading the TSID (Twitter's Secret Internal Documents) which basically tells Twitter plans to "dominate the world" with their Service, is that TC does not deserve any credibility publishing an advertorial making it looks like a revelation from the "underground" hackers; that's cheating.
"iTunes has a security hole that shows credit card information in clear text..."
Where are their auditors, their bankers, and their trading partners?
SOX won't let us fart on Tuesdays but a public company can store credit card information in clear text? Unbelievable.
Where are their auditors, their bankers, and their trading partners?
SOX won't let us fart on Tuesdays but a public company can store credit card information in clear text? Unbelievable.
The PCI (Payment Card Industry) compliance folks should be interested to know that as well, assuming it is true.
Very interesting, but I still think Techcrunch is way beyond the ethical line in this whole farce.
I think the only unique thing to come out of this is the supposed clear-text-credit-card-number iTunes exploit. That would be a story worth telling, where exposing information is in the public interest.
Everyone here is probably fairly well aware of how easy it is to compromise accounts on these online services. I hope most HN users recognize that the appropriate course of action after hacking a service like this is to notify the account holder to help them improve their security before revealing the details.
If you really aren't doing this for profit, and you really don't want to hurt the victim of the attack, (as Hacker Croll claims) then don't disclose the information you stole to major press outlets. This attack is really in poor taste, and I think we all of us here at HN should recognize the difference between pointing out the dangers of the internet and being one of the dangers ourselves.
If you really aren't doing this for profit, and you really don't want to hurt the victim of the attack, (as Hacker Croll claims) then don't disclose the information you stole to major press outlets. This attack is really in poor taste, and I think we all of us here at HN should recognize the difference between pointing out the dangers of the internet and being one of the dangers ourselves.
"We’ve waited to post exactly what happened until Twitter had time to close all of these security holes."
Unless you're saying that techcrunch should have waited until gmail/hotmail update their security policies?
I've ignored (or tried to at least) most of the twitter documents hype - but I thought this was an interesting and well written article.
Unless you're saying that techcrunch should have waited until gmail/hotmail update their security policies?
I've ignored (or tried to at least) most of the twitter documents hype - but I thought this was an interesting and well written article.
This story illustrates something that I enforce with users that I deal with. I don't allow them to choose their own passwords. This is especially important when they have access to a shared resource like Google Docs, a company wiki, subversion repository, etc. where a compromised account could expose sensitive company documents. It is also a good argument not to use those kinds of services and keep them 'in house' where you have better control and auditing of access to them.
If you are running a company 'in the cloud' you need to make sure you or your system administrators have control over the user's account and passwords. They can't be trusted to choose decent passwords.
If you are running a company 'in the cloud' you need to make sure you or your system administrators have control over the user's account and passwords. They can't be trusted to choose decent passwords.
Oh, that's real smart. So when you assign "Oc3j$ool>93*dl" as some user's password, they're just going jot it down on PostIt notes all over their desk, leave little .txt files on their desktop with it, add it to their cellphone as the "Password" contact, and stash it for "safekeeping" in all their email accounts. Great security you've got there.
Or they could, y'know, put it in their wallet. Like their SSN and their credit card number.
Password complexity requirements don't really help. Most people just wind up picking password001 or password #001. In fact, we almost ensure that people will write passwords down when we make them remember weird, long strings and make them change it every few months as part of an arbitrary password change policy. I remember reading a paper (can't find the reference now) on how password change policies originated in the 60s and there's no data to support that they actually help with security.
It boggles the mind that SSNs and CC#s are supposed to be secret. You, literally, give them out to anyone who asks.
Most people give out their passwords to anyone who asks as well (e.g. the "password for a chocolate bar" test.) People just aren't in the habit of asking for that.
They do all of those things already, or hadn't you noticed?
What's more likely? A cracker breaking into the office and copying down their password? Or an electronic attack against their lame passwords? Electronic attacks are far more likely than a physical attack.
What's more likely? A cracker breaking into the office and copying down their password? Or an electronic attack against their lame passwords? Electronic attacks are far more likely than a physical attack.
I think part of the problem is that we have so many places to keep track of(email/passwords wise).
I can pretty much guarantee that there is a way for some of my accounts to get compromised with an email address I haven't used in 4 years.
Why? Because at this point I probably have a few thousand accounts, and there is just no way to keep track of all of them, when updating your password/email.
I can pretty much guarantee that there is a way for some of my accounts to get compromised with an email address I haven't used in 4 years.
Why? Because at this point I probably have a few thousand accounts, and there is just no way to keep track of all of them, when updating your password/email.
The most important lesson here is that no amount of security on a website/server/physical piece of hardware will stand up to the test if the user is lax in their usage.
Social engineering is the new wave of security breaches and it would seem that strict password policies etc are just as important as an intrusion proof system/network.
Social engineering is the new wave of security breaches and it would seem that strict password policies etc are just as important as an intrusion proof system/network.
the post would have been a more interesting read if it didnt have so much rambling
Techcrunch = TwitterCrunch
Like many others, I gradually gave up my internal resistance on Google knowing most everything about me and have adopted Gmail as my primary mailbox.
1) Enable SSL by default on Gmail
https://mail.google.com/mail/#settings
Scroll down to bottom and choose 'Always use HTTPS' for 'Browser Connection'. Click 'Save settings'
2) Change your Gmail security question (you may want to do this now because you may have forgotten the answer to your own question that you set way back when you registered)
http://mail.google.com/support/bin/answer.py?hl=en&answe...
3) If you can't answer your Gmail security question, it will send a password reset email to your secondary email address. Consider the risks of having the secondary email address compromised (and decide whether to remove it or change it to one with a secure 'secret question' process - e.g. if you work for a company, your work email)
http://mail.google.com/support/bin/answer.py?hl=en&answe...