Best place to report potential security hole?

[jazzychad]

Hi,
Some fellow developers and I have identified and independently
reproduced a potential security hole/error. What is the best avenue
to report such an issue?
Here, email, help.twitter.com, google bug tracker, or other?

Thanks,
-Chad

[Aaron Brazell]

Please don't post it here. Send it to al...@twitter.com

--
Aaron Brazell
web:: www.technosailor.com
phone:: 410-608-6620
skype:: technosailor
twitter:: @technosailor

[Alex Payne]

Indeed, please do. You can CC secu...@twitter.com if you like.

--
Alex Payne
http://twitter.com/al3x

[jazzychad]

Will do very shortly. Thanks.

On Jul 17, 4:43 pm, "Alex Payne" <a...@twitter.com> wrote:
> Indeed, please do. You can CC secur...@twitter.com if you like.
>
>
>
> On Thu, Jul 17, 2008 at 1:36 PM, Aaron Brazell <emmenset...@gmail.com> wrote:

>
> > On Thu, Jul 17, 2008 at 4:34 PM, jazzychad <jazzyc...@gmail.com> wrote:
>
> >> Hi,
> >> Some fellow developers and I have identified and independently
> >> reproduced a potential security hole/error. What is the best avenue
> >> to report such an issue?
> >> Here, email, help.twitter.com, google bug tracker, or other?
>
> >> Thanks,
> >> -Chad
>

> > Please don't post it here. Send it to a...@twitter.com

[Kent Brewster]

You guys have still not patched the privacy bug I reported last
December. I can use a trivial piece of JavaScript to tell if any
visitor to my site is currently signed in to Twitter ... is this not
considered a big deal?

--Kent

On Jul 17, 1:43 pm, "Alex Payne" <a...@twitter.com> wrote:
> Indeed, please do. You can CC secur...@twitter.com if you like.
>
>
>
> On Thu, Jul 17, 2008 at 1:36 PM, Aaron Brazell <emmenset...@gmail.com> wrote:

>
> > On Thu, Jul 17, 2008 at 4:34 PM, jazzychad <jazzyc...@gmail.com> wrote:
>
> >> Hi,
> >> Some fellow developers and I have identified and independently
> >> reproduced a potential security hole/error. What is the best avenue
> >> to report such an issue?
> >> Here, email, help.twitter.com, google bug tracker, or other?
>
> >> Thanks,
> >> -Chad
>

> > Please don't post it here. Send it to a...@twitter.com

[Alex Payne]

Well, no. It's functionality we wanted to enable for integration with
the Flock browser. The same techniques can be applied to any number
of sites. We protect all actions on our pages with anti-CSRF tokens,
so actually taking action on behalf of a user you've detected as
signed-in should be impossible.

In short, though we appreciated the report, we reviewed the issue and
decided that it wasn't a threat.

--
Alex Payne
http://twitter.com/al3x

[Kent Brewster]

Ah, okay. It would have been great to hear something back.

I'm assuming you guys talked this over with your legal and PR
departments before making this call. It seems to me that the user's
status as a signed-in member of Service X is valuable information,
whether or not his personally-identifiable information is attached.

In the meantime ... you might want to look at it again. The exploit
runs by taking action on behalf of the signed-in user, and could be
made to be pretty annoying. Here it is:

http://twitter.com/favourings/destroy/591491922

This URL destroys a "favouring" to status 591491922, and can be
included as a SCRIPT tag. The "create" method works as well, and could
be run an unlimited number of times on the same page, causing the user
to "favourite" many different statuses without his prior knowledge.
Bonus: both of these methods return live JavaScript to the client,
including a free authenticity token, which could be applied to other
mischief.

--Kent

[Cameron Kaiser]

> Ah, okay. It would have been great to hear something back.
>
> I'm assuming you guys talked this over with your legal and PR
> departments before making this call. It seems to me that the user's
> status as a signed-in member of Service X is valuable information,
> whether or not his personally-identifiable information is attached.
>
> In the meantime ... you might want to look at it again. The exploit
> runs by taking action on behalf of the signed-in user, and could be
> made to be pretty annoying. Here it is:
>
> http://twitter.com/favourings/destroy/591491922
>
> This URL destroys a "favouring" to status 591491922, and can be
> included as a SCRIPT tag. The "create" method works as well, and could
> be run an unlimited number of times on the same page, causing the user
> to "favourite" many different statuses without his prior knowledge.
> Bonus: both of these methods return live JavaScript to the client,
> including a free authenticity token, which could be applied to other
> mischief.

Isn't this why Twitter was blocking on HTTP_REFERER IIRC?

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Injustice anywhere is a threat to justice everywhere. -- M. L. King, Jr. ---

[Ed Finkler]

On Sat, Jul 19, 2008 at 6:28 PM, Cameron Kaiser <spe...@floodgap.com> wrote:

> Isn't this why Twitter was blocking on HTTP_REFERER IIRC?

Yeah, it's CSRF attack. Avoiding using the REFERER adds another step,
but doesn't make it super hard by any means. If you require either
HTTP Basic Auth on all API action methods, and use nonces to block
CSRF against forms (where you're presumably using cookie-based session
checks), it should mitigate the problem.

I haven't checked to see if CSRFs are possible against the favorites
method, though, because exploring vulnerabilities on any site you
don't operate puts you in a very bad situation under US law.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

[Kee Hinckley]

It only takes about 4 lines of Javascript to make the favourings call,
intercept the returned javascript, and extract the
authenticity_token. I've done that.

The open question is whether that alone is sufficient to make any
other calls? The update form on the Twitter page has an additional
hidden value.

Anyone?

[Alex Payne]

We're depending on Rails' anti-CSRF mechanisms in a number of places,
but theoretically there should be unique tokens per-session,
per-action, per-instance. If that's not the case, we'll get on it.

Clearly our previous assessment of this threat was inadequate. I'll
make sure this gets patched as soon as possible.

--
Alex Payne
http://twitter.com/al3x

[Kent Brewster]

The direct-message form needs to have the siv parameter added. Given
my authentication token from favourings/destroy and a list of friends
available from the API output, more mischief is possible.

--Kent

[Kent Brewster]

Great, thanks.

I'd strongly recommend you guys re-think any interactions that return
live JavaScript to the client, especially interactions that make a
mark on the database. Call me cranky and old-fashioned, but I still
believe that anything employed by the client to intentionally change
data on the server ought to have a plain vanilla POST form.

--Kent

[Alex Payne]

I agree, Kent. I have an internal crusade to wage ;)

--
Alex Payne
http://twitter.com/al3x