Twitter Hacker Says Admin Password Was 'Happiness'(blog.wired.com)
blog.wired.com
Twitter Hacker Says Admin Password Was 'Happiness'
http://blog.wired.com/27bstroke6/2009/01/professed-twitt.html
43 comments
Limiting attempts is a great way to allow people to remotely execute a DoS on your admin site. They can keep you out for awhile before you block them. If your company has a password lockout policy, keep guessing the CEO or CIOs password constantly for a few days and the policy will be changed pretty quickly. The other suggestions are good.
You don't lockout the account, you lockout the attacking client, typically by IP address. It still allows the attacked accounts access from non-attacking IP addresses.
and if the attacking client is someone sitting on the corporate internet? way to block the entire corp from logging in ...
I would think that if you have an attacker on the intside of your corporate network trying to brute force accounts on an external service, you have wayyy more problems than locking out everyone else from the corporate network.
And I still don't care if everyone else on your network can't access my service; until you find the hacker and put a stop to it, why should I have any trust in your network address? The street goes both ways here.
And I still don't care if everyone else on your network can't access my service; until you find the hacker and put a stop to it, why should I have any trust in your network address? The street goes both ways here.
It seems like the three main strategies are locking the account, blocking the IP, or forcing a password reset. What if instead, the account login name automatically got changed after a few missed attempts but the password remained the same. That would get around the DoS problem and also the corporate IP / AOL problem.
I think rate limiting is a better option. If you only allow one log in attempt per X seconds, it becomes much harder to do a dictionary attack in a reasonable amount of time.
This to me is the way to do it. You can limit it to something pretty large like even or 3 tries, wait ten seconds or something. Basically making it normal speed for a human but waaay slow for a computer is the trick to me. A dictionary attack has to try tens of thousands of words and combinations to crack an account.
what? wouldn't that mean that anyone could try to log in to barackobama n times, get his login name changed, and then get barackobama's name?
You wouldn't get his followers, but you'd get a premium name easy.
You wouldn't get his followers, but you'd get a premium name easy.
That assumes that the login name is the same as the account name.
[deleted]
He also realized he hadn't used a proxy to hide his IP address, potentially making him traceable. He didn't think the intrusion was important draw for law-enforcement attention, and "didn't think it would make headlines.
I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines.
I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines.
This was when he was just running a dictionary attack on a random Twitter account, before he even had any idea he was hitting a privileged login.
He didn't hijack those accounts; he gave out the credentials in a forum thread and others jumped on it.
Technically you're correct, but by giving out the credentials in a public forum he should have known better.
DG is an unique place.
I don't understand how he thought hi-jacking Obama, Britney and Fox News twitter accounts wouldn't make headlines.
He was hijacking a random account on some totally unknown site called twitter.
I know this is hard to grasp outside the valley, but most people have not ever heard about twitter and will probably assume it's about as important to the internet as zombo.com.
He was hijacking a random account on some totally unknown site called twitter.
I know this is hard to grasp outside the valley, but most people have not ever heard about twitter and will probably assume it's about as important to the internet as zombo.com.
Actually CNN mentions Twitter quite often and especially during the elections a lot of people started hearing of Twitter way outside of the valley. If my parents learned about Twitter from watching TV I assume it's a safe bet that many other people have as well.
The last sentence of the article:
"He said he'd never even heard of Twitter until he saw someone mention it on YouTube. "This is again a reason why you shouldn't make accessing internal company services too easy. Yeah, it can be a pain but once someone figures out a little piece of the puzzle, they can run amok in your network. In hindsight, tying customer service methods to employee Twitter accounts was the big mistake.
Sure was a heck of a guess to end up with a staffer.
This does bring up a good tech question -- how do you prevent people from doing a rapid password attack?
Anyone have an article or some ideas on how this could be done? Is limiting attempts the simplest way?
Even if you do limits, aren't these session-based? I'm guessing a cracker isn't going to respect sessions.
Anyone have an article or some ideas on how this could be done? Is limiting attempts the simplest way?
Even if you do limits, aren't these session-based? I'm guessing a cracker isn't going to respect sessions.
Presume that you have some sort of table with userIDs and password hashes (with salt). You should also consider adding some columns like:
1 - LastLoginAttemptedDateTime
2 - LastLoginAttemptedIPAddress
3 - LastSuccessfulLoginDateTime
4 - LastSuccessfulLoginIPAddress
5 - MustChagePasswordAtNextLogin - a boolean flag to indicate they must change their password. You'll set that flag when they're recovering a password, or you've emailed them a temporary password.
6 - UnsuccessfulLoginCount - some number that your logic will use to determine how long they must wait, or if they sit in the penalty box.
7 - AccountLocked - boolean flag, some pointy haired bosses will not permit accounts to be locked out, like mine. And mine refuses to allow passwords to be one-way hashes (his words: we must be able to email the user the password they use). Depending on the security you need, the user of a locked account either has to phone up an unhelp desk, or show up in person.
8 - UserAgreementID - As you change user agreements, you'll want to keep track of what agreement the user agreed to, what day and time. This is something you'll want to log, and if you make substantial changes to the user agreement, you may want to force them to re-agree to the terms of use. You will also want to keep every version of the user agreement stashed away in a table somewhere, in case the lawyers get involved.
9 - UserAgreementDateTime - see #8
Along with a LoginTransaction table that captures attempts - both successful and not to log in, with usernames, date/time, IPaddress. This table should locked down so that a hacker can't delete entries, entries can be added, but not deleted nor changed. You'll do that with triggers ("instead of" triggers for sql server folks).
Perhaps your business logic says that a user can have 3 attempts in a 5 minute window (with no lockouts).
Your code would do something like...user has made 3rd bad attempts, set LastLoginAttemptedDateTime = Now, set UnsuccessfulLoginCount = 3.
Now the user tries to log in 1 minute later...If LastLoginAttemptedDateTime + 5_minutes < Now then log the attempt, LastLoginAttemptedDateTime = Now, reject login attempt EndIf.
If they log in successfully, log that event, set UnsuccessfulLoginCount = 0, set LastSuccessfulLoginDateTime and LastSuccessfulLoginIPAddress to the appropriate values.
1 - LastLoginAttemptedDateTime
2 - LastLoginAttemptedIPAddress
3 - LastSuccessfulLoginDateTime
4 - LastSuccessfulLoginIPAddress
5 - MustChagePasswordAtNextLogin - a boolean flag to indicate they must change their password. You'll set that flag when they're recovering a password, or you've emailed them a temporary password.
6 - UnsuccessfulLoginCount - some number that your logic will use to determine how long they must wait, or if they sit in the penalty box.
7 - AccountLocked - boolean flag, some pointy haired bosses will not permit accounts to be locked out, like mine. And mine refuses to allow passwords to be one-way hashes (his words: we must be able to email the user the password they use). Depending on the security you need, the user of a locked account either has to phone up an unhelp desk, or show up in person.
8 - UserAgreementID - As you change user agreements, you'll want to keep track of what agreement the user agreed to, what day and time. This is something you'll want to log, and if you make substantial changes to the user agreement, you may want to force them to re-agree to the terms of use. You will also want to keep every version of the user agreement stashed away in a table somewhere, in case the lawyers get involved.
9 - UserAgreementDateTime - see #8
Along with a LoginTransaction table that captures attempts - both successful and not to log in, with usernames, date/time, IPaddress. This table should locked down so that a hacker can't delete entries, entries can be added, but not deleted nor changed. You'll do that with triggers ("instead of" triggers for sql server folks).
Perhaps your business logic says that a user can have 3 attempts in a 5 minute window (with no lockouts).
Your code would do something like...user has made 3rd bad attempts, set LastLoginAttemptedDateTime = Now, set UnsuccessfulLoginCount = 3.
Now the user tries to log in 1 minute later...If LastLoginAttemptedDateTime + 5_minutes < Now then log the attempt, LastLoginAttemptedDateTime = Now, reject login attempt EndIf.
If they log in successfully, log that event, set UnsuccessfulLoginCount = 0, set LastSuccessfulLoginDateTime and LastSuccessfulLoginIPAddress to the appropriate values.
And if the attacker doesn't care which userID they compromise, so they spread their guesses over all userIDs?
This is a very real concern, however it is significantly less likely for such a horizontal attack to succeed. I recommend the grand parent post's solution for startups who aren't yet approaching critical mass and only require protection from the vertical.
Small user sets, such as the Twitter admin accounts, would not be large enough to be successful with a horizontal attack. Provided, of course, that every user has a minimum password complexity, which they did not. Even without complexity requirements, the list of simple words is still prohibitively large in most cases.
That said, if you have even one user among millions with the password "qwerty", he is certainly at risk. However, once you are at a scale prone to this kind of attack, a more sophisticated rate limiting scheme is probably required even for regular web requests.
Small user sets, such as the Twitter admin accounts, would not be large enough to be successful with a horizontal attack. Provided, of course, that every user has a minimum password complexity, which they did not. Even without complexity requirements, the list of simple words is still prohibitively large in most cases.
That said, if you have even one user among millions with the password "qwerty", he is certainly at risk. However, once you are at a scale prone to this kind of attack, a more sophisticated rate limiting scheme is probably required even for regular web requests.
I'm sure I'm preaching to the choir, but wow - not using one way hashes is an absolutely terrible security hole.
[deleted]
Look at how programs like Fail2Ban, and many SSH-specific monitoring services work.
Specifically, Fail2Ban follows auth logs for various services, and when it finds clients exceeding per-service configured limits, it adds IPTables rules that ban the offending IP address for a configurable amount of time.
Fail2Ban is packaged in many distributions, including Debian and Ubuntu, and can be compiled on just about any system. I personally use it exclusively to thwart brute force attacks on SSH, SMTP/Postfix, IMAP/Dovecot, and HTTP/Apache.
It should be trivial to add a new set of filter/jail rules for any web application that can log bad authentication attempts to a file, and then you have instant "protection" from most brute force attacks.
Specifically, Fail2Ban follows auth logs for various services, and when it finds clients exceeding per-service configured limits, it adds IPTables rules that ban the offending IP address for a configurable amount of time.
Fail2Ban is packaged in many distributions, including Debian and Ubuntu, and can be compiled on just about any system. I personally use it exclusively to thwart brute force attacks on SSH, SMTP/Postfix, IMAP/Dovecot, and HTTP/Apache.
It should be trivial to add a new set of filter/jail rules for any web application that can log bad authentication attempts to a file, and then you have instant "protection" from most brute force attacks.
You could double the response time for every successive attempt from the same IP. You'd still need an absolute limit on the account, in case of a distributed attack.
You could just throw recent login attempts into a table, but that might get big quickly.
and thus could also be archived/truncated frequently as it is only relevant within a certain time frame right?
"He said he'd never even heard of Twitter until he saw someone mention it on YouTube."
Classic
Classic
Unsurprising. Most people have no idea what Twitter is.
I've noticed sometimes the tech world feels like a bubble where our sense of what's important in the "real world" gets warped.
I've noticed sometimes the tech world feels like a bubble where our sense of what's important in the "real world" gets warped.
Again, it brings up the case of why passwords are bad at this level.
Maybe staffers should have used a secondary password to get administrative rights.
Or maybe they should have been using an entirely different account.
Maybe staffers should have used a secondary password to get administrative rights.
Or maybe they should have been using an entirely different account.
Admin accounts should not use the main website for access - they should only have access through an admin website.
If you must let admin accounts use the main website, then they should have a whitelist of IP addresses that they may log in from - and those IP addresses should map to the internal company IP addresses.
Otherwise, if you absolutely positively MUST have admin accounts use the same website, and allow them access from outside the company, then you need to have a second factor authentication device like a SecurID token.
If you must let admin accounts use the main website, then they should have a whitelist of IP addresses that they may log in from - and those IP addresses should map to the internal company IP addresses.
Otherwise, if you absolutely positively MUST have admin accounts use the same website, and allow them access from outside the company, then you need to have a second factor authentication device like a SecurID token.
No, it wasn't. "Happiness" was the password for the account of a user who happened to be on the support staff.
we're all human, and twitter is very new.
We all make mistakes, doesn't seem terrible honestly.
We all make mistakes, doesn't seem terrible honestly.
weak
Limiting password check attempts is important too, but if all a bad guy could get access to is user accounts the damage is significantly less.