Don’t Click: http://tinyurl.com/amgzs6

And, probably like many of the people out there, you clicked the link.  By the way, if you clicked the link above, good job.  You’re now one of the tens, possibly hundreds, of thousands of Twitter users that clicked that.

And then, you found out that your Twitter account got HACKED!  Even prolific blogger Dooce clicked, and subsequently decided her account had been compromised.  Her followup tweet was 

My twitter account got hacked. That last tweet was a hack, not my doing. Apologies for any inconvenience.

“Inconvenience”?  Your inability to not click an unknown link resulted in all your readers’ accounts being exposed to this.

Here’s the thing, though: your account is fine.  It wasn’t compromised.  At least, not in the way you are thinking.  I’m sure you’re thinking someone broke in, posted as you, and took off.  Now they have your username, password, measurements, shoe size, and even the length of your… hair.  I was going to say hair.  I promise.

Well, you’re wrong.  They don’t.

What happened?  Well, you clicked the link.  Alright, let’s get technical.

You’re on Twitter.  In fact, you’ve probably logged in to Twitter, so your browser has an authenticated session.  If you don’t know what that means, it’s simply that your browser has a piece of information that identifies you as you.  That info allows you access to your account, your tweets, your friends, and so on.  When you clicked the “Don’t Click” link, something happened: you opened a web page.  That’s all you saw.  The web page, redirected via TinyURL.com, was http://www.umoor.eu/blog/yes-we-can.php.

Don’t worry, both the TinyURL and the yes-we-can.php pages have since been disabled.

Take page contained two thing of note: a button, which you could see, and an iframe, which you could not see.  The button was simple enough:

button {position: absolute;top: 10px;left: 10px;z-index: 1;width: 120px;}

It just sat there, looking bored.  The iframe was more interesting:

iframe {position: absolute;width: 550px;height: 228px;top: -170px;left: -400px;z-index: 2;opacity: 0;filter: alpha(opacity=0);}

The CSS, you’ll notice, sets a size and height, but positions it off to the side and makes it transparent.  You were not supposed to even know it’s there.  Now, source of the iframe is what matters.  Remember, it’s hidden, so you see none of this.

iframe src=”http://twitter.com/home?status=Don’t Click: http://tinyurl.com/amgzs6″ scrolling=”no”

Since Twitter allows you to set you status by tacking the status on to the “home” URL, the iframe made the same request.  Backing up, you were (probably) authenticated to Twitter, so there were no problems simply updating your status.  From there, your friends saw it, clicked the link, and their own status was updated.  And it cascaded.

How bad did it cascade?  Here is the Twitter search for just that URL.

So, did you account get “hacked”?  Not exactly.  The account was not compromised or broken into, but it did perform actions on your behalf without you knowing about it.  Do you need to run and change your password?  Not this time.  How about, instead, you find out where links go before you trust them.  Then again, if you’re an Obama supporter, anything with “yes-we-can” in it will probably get you.  By the way, if you take a TinyURL and put “preview” in it, you can see where it goes without going there.  So , http://tinyurl.com/amgzs6 becomes http://preview.tinyurl.com/amgzs6.

Now, I want you to think about something: in this case, you were exploited and inadvertently posted to Twitter.  What if, instead of posting to Twitter, the iframe had tried to transfer money from your bank account?

And, most importantly, what can you do about it?  Learn where links are going before you click, and download and use CSRFblocker, which will be available soon from the Hexagon Security think-tank.

Credit: @reverz and @nathanhamiel

If you want to check out the app, here is the iTunes store link.  Because iTunes conveniently provides a link to this information, it’s easy to tell that the author, Robert de Jong, has not published any other apps.  Further, one whois and a google search later, and you can tell that the author, based in Colorado, isn’t either of the other two Robert de Jongs out there; one is in Ohio, the other in Canada.  Oh, his “company” also has a website, though it looks like a sole-proprietership, meaning there has been no paperwork filed with the government to form an LLC or corporation.  Further evidence: I couldn’t find a DEJOware business listing, according to the Colorado business registry.  On his site, the only contact link is a mailto, which will allow you to send him an email.

So, where does that leave us?  Well, let’s look at the application itself.  I mentioned earlier that it takes in user input, and gives you back your “other” names.  Let’s give this a whirl, using some fake information (why will be covered in a minute).  Starting the app up, we go immediately to the Pirate name screen.  First and last name are requested.  “Johnny Appleseed” is already demo’d on the iTunes store, so let’s do another name.  How about “Robert de Jong”?  I put it in, and get back the pirate name of “‘Salty’ Squid Flint”.  Stripper name time!  Robert de Jong, in the stripper world, would be “Fantasia Heavencocker”.  Wow.  Now Jedi name time.  Hitting this tab expands the input, and, again as seen on iTunes, more information is requested.  First, last, mother’s maiden, and birthplace are requested.  Robert’s mother’s maiden name will be, for this demo, “Wozniak” (sorry Steve), and his birthplace will be Boulder.  I get back the very Jedi name of “Dej-Ro Wozbou”.

Dej-Ro Wozbou is parts of each element of data.  Three from last name, two from first name, three from mother’s maiden, and three form birthplace.  de Jong Robert Wozniak Boulder.  See?

So, why would I use false information here?  Here’s what just happened: a previously unknown developer has created an application and published it with Apple’s blessing.  The application asks for your information, and does… we know not what with it.  The app could send your information, literally, anywhere.  Further, the information is all user-supplied, so there’s nothing that would make Apple unhappy (like rifling through your address book for your information).  No, we, the users, provide all the information it asks for.  And that’s the problem.  We just provided First Name, Last Name, Mother’s Maiden Name, and Birthplace to this application and, potentially, to this developer.  If those four pieces of information sound familiar, it’s because those are usually what stand between you and retrieving an account password almost anywhere.  “But he doesn’t know my username!” you cry.  Actually, most people will use FirstnameLastname as their account username, if it’s an important account.  Like banking.  Think about that.

Now, my disclaimer and CYA: I don’t know any of this for sure.  I haven’t monitored the network traffic to see if A.K.A is calling home.  I’m not even accusing A.K.A. or Robert de Jong of doing anything malicious.  The A.K.A. app happens to fit a model that could be used to steal information.  It is also “trusted” because Apple has blessed it.  Before you willingly hand any information over to an application, trusted or not, consider what could be done with that information.