Twitter Hacker Says Admin Password Was 'Happiness'

http://blog.wired.com/27bstroke6/2009/01/professed-twitt.html

by lnguyen • 18 years ago

67 41 18 years ago

blog.wired.com

Jasber2• 18 years ago

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.

alaskamiller2• 18 years ago

He didn't hijack those accounts; he gave out the credentials in a forum thread and others jumped on it.

Jasber2• 18 years ago

Technically you're correct, but by giving out the credentials in a public forum he should have known better.

cdr• 18 years ago

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.

trezor• 18 years ago

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.

cstejerean• 18 years ago

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.

sanjayparekh• 18 years ago

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.

bprater3• 18 years ago

Sure was a heck of a guess to end up with a staffer.

bprater3• 18 years ago

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.

Tangurena2• 18 years ago

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.

bprater3• 18 years ago

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.

fuzzmeister• 18 years ago

You could just throw recent login attempts into a table, but that might get big quickly.

liuliu• 18 years ago

or memcachedb, or just use mollom.com

shaunxcode• 18 years ago

and thus could also be archived/truncated frequently as it is only relevant within a certain time frame right?

catch23• 18 years ago

why even bother logging that? just store it in memory someone. have a counting bloom filter remember the set of IPs that tried to login during the last 10 seconds. If your ip is in that set, delay the user by 10 seconds or so...

dmoney• 18 years ago

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.

nuclear_eclipse3• 18 years ago

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.

Tangurena2• 18 years ago

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.

gojomo• 18 years ago

And if the attacker doesn't care which userID they compromise, so they spread their guesses over all userIDs?

festivusr• 18 years ago

I'm sure I'm preaching to the choir, but wow - not using one way hashes is an absolutely terrible security hole.

staunch• 18 years ago

This is why ideally you only make your admin tools available on your private network, accessible only via VPN. The very minimum is restricting access to admin functionality to specific IP addresses.

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.

johns2• 18 years ago

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.

nuclear_eclipse3• 18 years ago

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.

mynameishere• 18 years ago

http://www.youtube.com/watch?v=qEZxgEgG5Cg#t=1m52s

justifyleo• 18 years ago

weak

axod• 18 years ago

"He said he'd never even heard of Twitter until he saw someone mention it on YouTube."

Classic

tlrobinson• 18 years ago

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.

pclark• 18 years ago

we're all human, and twitter is very new.

We all make mistakes, doesn't seem terrible honestly.

eli• 18 years ago

No, it wasn't. "Happiness" was the password for the account of a user who happened to be on the support staff.

Twitter Hacker Says Admin Password Was 'Happiness'

Related Stories