Re: [hybi] Handshake was: The WebSocket protocol issues.

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> On Thu, Sep 30, 2010 at 6:50 PM, Scott Ferguson <[e-mail]> wrote:
>   
>> To repeat the key pieces:
>>  a) c-nonce must not be available to or predictable by the hijacker
>>  b) "WebSocket" is not possessed by a non-websocket server
>>     
>
> You're making a bunch of assumptions about how non-websocket servers
> behave.  In particular, consider a protocol like DNS.  It's entirely
> possible that a DNS-like protocol could relay the c-nonce to the
> attacker and give the attacker an opportunity to response with the
> appropriate hash, which the server would then relay to the client.
> Attacks of this general class (even against DNS) are known for HTTP.
>   

No, Adam, you can't just handwave that scenario. Let's take your attack 
in detail.

  1) Hijacker has taken control of a browser and initiates a websocket 
connection.
  2) That websocket connection is to a DNS server.
  3) The DNS server relays the c-nonce to the hijacked browser (???)

       browser -> DNS -> browser

  4) The hijacked browser can now compute H(c-nonce, "WebSocket")
  5) The browser somehow sends the H(c-nonce, "WebSocket") to the DNS 
proxy which now that it has the hash redirects to the actual target, 
which echos the hash through the theoretical proxy chain. Or it acts as 
a web-socket relay itself

       browser -> DNS -> browser -> target

None of which makes any sense.

I am making some assumptions:

  1) there are no websocket open relays. If there are, the issue isn't a 
cross-protocol attack, but an open relay attack. Your description 
proposes the browser itself as a websocket open relay ("could relay the 
c-nonce to the attacker").

  2) there are no open relays that compute H(xxxx, "WebSocket") or open 
relays that calculate arbitrary hashes H(xxxx).  Your proposed DNS 
attack does neither, nor does it propose a relay that does calculate 
either. Instead, you handwave to the hijacked browser itself as an open 
websocket relay.

> The security of this protocol relies on more assumptions than you've
> listed in your message.  Reasoning about security here is very subtle,
> especially when reasoning about the behavior of non-WebSocket servers.
>  We need to be prepared for them to do a wide variety of things.
>   

This statement is not particularly useful.

If you assume the existence of open relays which implement arbitrary 
protocols and compute arbitrary functions, that's equivalent to assuming 
the relay is a valid websocket proxy, which is no longer a 
cross-protocol attack.

Does your "wide variety of things" include calculation of arbitrary hashes?

> As a side note, using an exotic HTTP method is not a good idea.  The
> first few bytes of the clients initial message are absolutely
> critical.  Picking an exotic HTTP method is just rolling the dice
> w.r.t. what protocols an attacker can exploit.  For example, some
> attacks from HTTP to DNS rely critically on the fact that the first
> byte of an HTTP POST message is an uppercase P.  The kinds of things
> you can do with an uppercase W as the first byte are largely
> unstudied.
>   

You misunderstand entirely.

It's not an exotic HTTP method; it's identifying the protocol by the 
initial sequence of bytes.

If every client for every protocol sent a non-hijackable unique protocol 
identifier as its initial sequence, and every server for every protocol 
verified the protocol identifier before accepting any further bytes, 
then cross protocol attacks would be impossible.

We can't fix the older protocols that don't identify themselves 
immediately and don't validate, but we can ensure that new protocols do.

-- Scott