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

[Scott Ferguson <[e-mail]>]

Bjoern Hoehrmann wrote:
> * Scott Ferguson wrote:
>   
>> To sum up, the following are required for the attack to work:
>>
>> 1. the attacker has an account on the same physical/virtual machine as 
>> the target server
>> 2. the attacker has hijacked a browser inside the target's office IP 
>> 2.2.2.*
>> 3. the target restricts access to the office IP 2.2.2.*
>> 4. the target is too cheap to pay $11/month for a virtual instance for 
>> security
>> 5. the ISP is too lazy to add <Limit WEBSOCKET>
>> 6. the target has an open DELETE method with no authentication
>>     

I've reordered the responses.

> I agree you need 2 and 3, where to
> hijack a browser it is sufficient to trick someone on the office network
> to open a specific web page.

Necessary, not sufficient. They're not the same at all.

Your attack assumes a needle in a haystack on the part of the attacker. 
Not only must the attacker add a site to the target's own web server, he 
must hijack one of the target's own browsers while they're in the office 
which is a tiny universe of browsers.

> Well, points 1, 5, and 6 are not quite correct. For 1, both hosts must
> be behind the same IP address, how they achieve that is irrelevant. It's
> perfectly possible to run them on mutually disconnected machines.

Eric specifically insisted the shared machine configuration was the one 
he was worried about. If everyone agrees to drop that shared-machine 
scenario as implausible, we can move on to analyzing a proxied 
configuration. Until then, it's important to stick to one attack vector.

>  For 5, if the ISP blocks WEBSOCKET requests, that means none of the sites it is
> hosting can do Websocket over port 80. 

Adam insisted on a non-upgraded HTTP server. Until he drops that 
requirement, you can't change the attack to an upgraded WebSocket-aware 
server.

> If it allows it for some then the
> protection is meaningless, as the WEBSOCKET request goes to the attacker
> (and similarily on point 6, the DELETE request goes to the attacker).
You didn't address point #6, the open DELETE.

The target is pre-compromised because it has an open DELETE (point #6) 
and the target is pre-compromised because it's on the same machine as 
the attacker (point #1).

You're requiring a pre-compromised target to make this attack work.

> I do not quite understand point 4, but 
>   

The point of #4 is that the universe of potential targets is restricted 
to those who don't care about security. Any site can have its own web 
server for $11/month, eliminating this attack entirely. No site 
seriously concerned with security would use a shared machine 
configuration because it's basically pre-compromised.

In particular this restricts #3, the universe of browsers the target 
could hijack, because a small site with no security considerations is a 
tiny office with few target browsers.

-- Scott