1515563 - Cross-Domain Requesting

Status: RESOLVED WONTFIX

(Cloud Services Graveyard :: Server: WebPush, defect)

Description

[Sourav Newatia]

Attachment: POC

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

URL: https://push.services.mozilla.com/
Domain: Websocket

1) Request it with Burpsuite
2) send to repeater 
3) without changing anything, click on Go and remember the response , its 101 switching protocol,
4) Changing the Origin , still same response, 



Actual results:

By default in WebSockets, the only thing that controls the cross-domain requesting is the Origin header. Origin header is sent within the WebSocket opening handshake request by the WebSocket client and validated by the WebSocket server. Proxy tools can manipulate the
request headers freely. However, in some cases, the source from where the service can be called is not limited for a reason. In those cases the testing of origin validation is not necessary.Testing starts by opening the connection to the WebSocket service. In case of a browser based WebSocket service, open the web site where the WebSocket service is located, login to the service by using the credentials (if login is required) and the WebSocket connection should be established.

If the response to the modified request is similar to the following example, the service has an origin validation security issue, since the origin is not validated:


Expected results:


In case of the service’s security control working correctly, response’s HTTP status code is “401 Unauthorized” or similar, which restricts the access to the service from unauthorized origins.

Comment 1

[Julien Vehent]

I'm pretty sure we don't want any Origin validation on the public Push endpoint, but I'll let Ben confirm that.

Comment 2

[Sourav Newatia]

Hi, 

WebSocket is a computer communications protocol. So, whenever by default origin is there. it creates a communication with via protocol, it creates a persistent connection between the browser and the server. The most common use case for Websockets is when adding a chat functionality to a web application and generates 101 switching (Response code). If I am able to change the origin, and it still communicate and generates same response code. then it should be origin validation there. 

Exact vulnerability name

Vulnerability : Cross-Site WebSocket Hijacking

So whenever we changes the origin, the response’s HTTP status code should be like  “401 Unauthorized” or similar, which restricts the access to the service from unauthorized origins.


Severity : Medium 


Thanks
Sourav Newatia

Comment 3

[Sourav Newatia]

any update ???

Comment 4

[Ben Bangert [:benbangert]]

Per https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html under 'Securing It':

If you don't need to access the web session from the server-side WebSocket counterpart, just separately handle authentication and/or authorization using custom tokens or similar techniques within your WebSocket protocol and avoid relating to the web session via cookies or HTTP-Authentication during the handshake request.

This is how authentication is done to our Push system, within our websocket protocol with a hello message including a token.

Is there something else I'm missing?

Comment 5

[dark haxor]

Yes you missed the Origin checking part you have a random token which is the uaid parammeter but cross socket connection is still there. It is not patched yet :)

Comment 6

[dark haxor]

I also saw that the uaid cookie isnot checked properly cause I tampered it ....on tampering it it still gives ==200==
I send this...se the last end ...its wirtten hacked

{"messageType":"hello","use_webpush":true,"uaid":"4a7b55d67df8438d86765ae32dhacked"}

Now i reconnect to the socket and send the data ....the server returned me the following data

{"messageType":"hello","uaid":"3eaacca9fcd64e54b5d20b0f31d2d2a0","status":200,"use_webpush":true,"broadcasts":{}}

It returned me a good uaid cookie and the status is 200 which states im successful in tamepering.
Please tell me i'm wrong

Comment 7

[JR Conlin [:jrconlin,:jconlin]]

It's working properly. Your UAID was changed. You're now a different user.

This is part of the protocol, since the server assigns a UAID. I'll note that in this case prior endpoints you may have received for the first UAID would not deliver to this socket.

Comment 8

[dark haxor]

What about the Origin checking?

Comment 9

[dark haxor]

Let it deliver to any socket ...the response is corrupted and there is no check...in other cases i have seen it gives 500 internal error but here i just get switched to another socket...but the vuln is there.

Comment 10

[JR Conlin [:jrconlin,:jconlin]]

Ok, let's break down what this actually means.

Webpush is an end-to-end encrypted protocol that (in our case) uses a secure websocket connection, but it's a bit more than just that.

(Quick note: I tend to keep a fairly light tone when I cover attack scenarios, mostly because I tend to focus on a lot of very malicious behavior and it helps me keep my sanity. My apologies in advance if you feel I'm not being serious enough. That is absolutely not the case.)

Let's say you're an evil person. What sort of things can you do?

Well, you could try connecting to the autopush server and requesting a socket connection, and send a "hello" packet without a UAID. That makes you pretty much just like any other user agent. You'd have to do some work in order to get around some of the data encryption requirements but that's not terribly difficult. Now you have a channel you can use to control your single bot, which isn't super efficient and provides no back channel. There are a lot better protocols out there so unless you're putting together a speed demo for BlackHat to control your arduino, it's not really going to set the world on fire. (I'll note that the Origin header isn't really going to help secure the server here.)

So, let's say you run EvilOnAStick.com and you want to intercept webpush messages, what sort of things can you do? Well, the websocket connection goes directly from the UA to the mozilla web servers, so you can't really see that(1). What about the UAID, then? That's never exposed to the website, so they'd have to walk through the UUID4 space in order to brute force guess what it might be.

Nevermind all that, we're evil. We have a bot farm that we can use to somehow, magically walk the quintillions of possible values and evade abuse detection and bill collectors. That or we somehow crack the encryption we use to encode the endpoint that is sent to the service worker running inside the PWA that we're either hosting ourselves or have a the user run a hack that breaks the sandbox and pulls that information(2). We now have the specific UAID associated with the UA. We try to connect using that UAID and, since we don't have the matching list of UUID4 based channel IDs for the UA, we get rejected and handed a new UAID. Ok, time to fire up the bot farm and walk through guessing the various combinatorics in order to spoof being a valid UAID with associated channels. We are ready to connect as that UAID!

Only we're spotted by the server as a duplicate of an existing connection and denied.

Alright, so we wait for the original UAID to drop, and reconnect as that UAID. The server accepts the connection. You then get a notification that contains a block of encrypted data. Which you don't have the keys for since they never travel over the websocket connection.

The worst you could do is that you ACK push message in place of original UA. Considering that most push messages have a TTL of "0" you've spent a lot of time and effort to make sure that one browser doesn't get a calendar reminder(3).

There are potential issues with MITM attacks by, say, taking over a users router in order to monitor all traffic going to and from a given UA, but there are lots of built-ins with TLS 1.2+ that make that fairly challenging at best. You'd have to intercept both the TLS connection from the UA as well as the TLS connection with whatever site is getting the Subscription Info block. Not 100% impossible for a state level actor, of course, but if you're being targeted that way, you have a lot more pressing concerns.

Does that cover what you're thinking? I'd very much be interested if we missed something. Security is hard and no matter how much thought we give things, it's impossible to say that "we thought of everything".

---

(1) As a side note, since there's no actual "Origin" for the websocket, I'm not quite sure what we should set as the "Origin" if we were to include one.

(2) Granted, if we've got a hack that breaks the PWA serviceworker sandbox and can pull the full subscription info, that's pretty much Game Over right there, but we'll work through the rest of the though exercise.

(3) In the past I termed this as a "griefing" attack, since it's there just to be more annoying than overtly malicious. It's the digital equivalent of ringing the doorbell and running away.