[jira] [Created] (ZEPPELIN-173) Zeppelin websocket server is vulnerable to Cross-Site WebSocket Hijacking

["Joel Zambrano (JIRA)" <ji...@apache.org>]

Joel Zambrano created ZEPPELIN-173:
--------------------------------------

             Summary: Zeppelin websocket server is vulnerable to Cross-Site WebSocket Hijacking
                 Key: ZEPPELIN-173
                 URL: https://issues.apache.org/jira/browse/ZEPPELIN-173
             Project: Zeppelin
          Issue Type: Bug
          Components: Core
    Affects Versions: 0.5.0
            Reporter: Joel Zambrano
            Priority: Critical


The WebSocket specification - developed as part of the HTML5 initiative - introduced the WebSocket JavaScript interface, which defines a full-duplex single socket connection over which messages can be sent between client and server. In order to create a Websocket channel, the browser - via JavaScript - sends to the webserver a specific request, like the following:

GET / HTTP/1.1
Host: XXXXX:8004
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: XXXXXX:8003
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: jecleCYu+zulEtNfWPDUHQ==
Authorization: Basic [...]
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket


If the server accepts the request of upgrading the connection to a websocket channel, it will send back a http response with status code 101, like the following:

 

HTTP/1.1 101 Switching Protocols
Upgrade: Websocket
Server: Microsoft-IIS/8.5
x-ms-hdi-servedby: GATEWAY0
x-ms-hdi-active: headnode1.XXXX.net
x-ms-leader-detect-time: 0
X-Powered-By: ARR/2.5
Sec-WebSocket-Accept: dsFIbttEBYGLWHitOKbGhmXyzeI=
Connection: Upgrade
X-Powered-By: ASP.NET
X-Content-Type-Options: nosniff
Date: Tue, 09 Jun 2015 19:43:59 GMT 

 

Because Websockets are not restrained by the same-origin policy, an attacker can easily initiate a Websocket request from a malicious webpage targeting the ws:// or wss:// endpoint URL of the attacked application. According to the RFC 6455, the Websocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication or TLS authentication. Because of that, the browser sends the authentication information along with the Websocket handshake/upgrade request, similar to a Cross-Site Request Forgery (CSRF), but in the Websocket scenario this attack can be extended from a write-only CSRF attack to a full read/write communication with a Websocket service. 

 

One way to secure the Websocket server is to check the Origin http request header, which is automatically included by the browser and cannot be controlled by client-side code. According to our analysis, Zeppelin does not perform any check on the Origin header, allowing arbitrary Cross-Origin requests.

 

This means that an attacker could create a malicious website containing a malicious javascript code and force the victim user to open it (e.g., by sending an email). Once the client-side code is acquired and executed by the victim's browser, the attacker could control the websocket channel and, then, execute arbitrary code on the Spark cluster via Zeppelin.

 

Recommendations:

It is strongly recommended to apply a patch to the current Zeppelin version in order to check, at least, the Origin header. 





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)