Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in-browser-localhostdiscovery #4

Open
utterances-bot opened this issue Sep 10, 2018 · 14 comments
Open

in-browser-localhostdiscovery #4

utterances-bot opened this issue Sep 10, 2018 · 14 comments

Comments

@utterances-bot
Copy link

rain-1.github.io

https://rain-1.github.io/in-browser-localhostdiscovery.html

Copy link

TL;DR - You are vulnerable if you are browsing the web.

Some issues:

  • May then you be a security engineer reviewing a phishing report (DNS rebinding aka inside-out issues)
  • Enumeration for targeted exploitation (example you shared)
  • Anything well known and established (CSRF, et cetera).

Some suggestion:

  • Appropriate whitelisting with outbound inspection;
  • following least privilege;
  • avoiding processes running with higher privileges.

Copy link

Webpages should not be able to load resources from other domains. This would close a lot of security holes.

Of course the worst security hole is JavaScript, which allows anyone to execute arbitrary code on your computer. No matter how carefully sandboxed, this is a very bad idea. Combined with the ability to load resources from other domains, it's a disaster.

@rain-1
Copy link
Owner

rain-1 commented Sep 11, 2018

thank you for the comments :D

Copy link

Shamar commented Sep 14, 2018

Technically @ljmccarthy is right: "the worst security hole is JavaScript".

@rain-1 shows one of the many possible attacks.
With the best explaination I've seen so far. Clear and simple.

I described another PoC exploit here.
Further exploits are described at the original bug report: feel free to add your own.

Also consider how HTTP Cache-Control makes these JS attacks undetectable (and how worse it would be with GCC/CLang optimized WebAssembly). And then add BeEF (The Browser Exploitation Framework) to the mix.

💥

But here, the worse security issue is not technical: it's people's trust in IT.

@notriddle
Copy link

notriddle commented Sep 14, 2018

You're right that JavaScript can be an exploit vector, but disabling JavaScript isn't enough to fix intranet-busting attacks. A site can request resources from another domain even if JavaScript is turned off. Forms alone are enough.

@Shamar
Copy link

Shamar commented Sep 15, 2018

Very interesting, since with cache control and meta refresh you can hide evidence.
This basically means that invisible elements (form frames imgs) should not trigger connections (or any dom event or dom modification actually, that might be a bit complex if you consider CSS). This would also help against clickjacking.

However I think it's worth to notice that

  • with JS these attacks are way easier
  • some attacks are simply not possible without JS (or WASM): think for example mining bitcoins where it's not legal to do so
  • with JS you do not need user interaction for most attacks
  • with JS and cache control you can remove all evidences without any refresh that might be noticed by the users.

Now my point is: there are many many dangerous security issues in the current Web, but it's pointless to address each of them separately while JS is bindly executed by browsers anyway.

It's like curing a fever while pretending to ignore thar the patient has a deathly cancer!

@notriddle
Copy link

The attack listed on the wikipedia page used a perfectly visible image element that just happened to have side effects when the browser would GET it. It came out broken, but broken images in a forum thread are like dandelions in a field.

The security problem described in the OP is caused by cross-origin requests. And I personally think it's way more severe than Bitcoin mining scripts, which are effectively the same thing as Rickrolling.

@rain-1
Copy link
Owner

rain-1 commented Sep 15, 2018

You could develop this further by:

  • making it happen in parallel
  • doing a port scan on the available hosts
  • modules to interact with ports that seem to talk some protocol the web browser can talk, e.g. unauthenticated XML or JSON RPCs

@Shamar
Copy link

Shamar commented Sep 15, 2018

Indeed. These are just examples.

You could learn the political orientation of a user timing the load of specific images from third parties to see if they are in the cache (effectively bypassing history access rules). And so on.

Also you shouldn't dismiss the legal issues.
It's pretty severe in some places around the world.

The point is: there are many security flawns in mainstream browsers, with JavaScript being the biggest one.

People do not really understand these. Nor do companies or governments.

We shouldn't use the existence of less severe issues to justify the worst one.

We should simply fix them, starting from the biggest (which fortunately is relatively easy to address).

@alvarezp
Copy link

We should simply fix them, starting from the biggest (which fortunately is relatively easy to address).

What do you mean? Disabling JS is easy. Not breaking the Web while doing it, not so much. I mean: designing usable and much needed non-JS alternatives for common use cases. Or do you mean something else?

@Shamar
Copy link

Shamar commented Nov 28, 2018

Disabling JS is easy. Not breaking the Web while doing it, not so much.

If any website you visit can tunnel into your private network, the Web is badly broken already.
Very broken, if you consider such attacks are undetectable and can target specific people like Ads do.

Worse: most of people who understand the severity of these attacks omit to inform people.
People who trust them. Mozilla in primis, but many web developers too.

Yet, none of the mitigations proposed would "break the Web".
Java Applets and Flash were opt-in, without any drama.

Opt-in JavaScript on a per-website base will not break the web.
You will be able to run all applications you trust.
But you will have a chance to decide. And in the long run, people will learn to avoid JS bloat.

designing usable and much needed non-JS alternatives for common use cases

This is the research that @alcinnz is leading: PostJS Web.
You can join us on the mailing list.

@alvarezp
Copy link

alvarezp commented Nov 29, 2018

Disabling JS is easy. Not breaking the Web while doing it, not so much.

If any website you visit can tunnel into your private network, the Web is badly broken already.
Very broken, if you consider such attacks are undetectable and can target specific people like Ads do.

I understand (and support) your point. However, I don't want to go into terminology nitpicking. It is important to acknowledge that, today, there are common use cases that are only available through JS.

Just like before HTML5 client-side form input validation was impossible without JS, nowadays, multi-column (multi-control) dropdowns are impossible without JS. We must acknowledge these use cases and not assume that plain-disabling JS will be accepted by others just because.

Opt-in JavaScript on a per-website base will not break the web.
You will be able to run all applications you trust.

That's exactly how I think. But it breaks people's current Web mental models. People will immediately push back: "so, you want to go back to the full page reloads as in the 2000s?"

Idea: shipping a browser with JS disabled by default for non-technical users "breaks the Web" (for some definition of "breaks" and "Web", of course) despite also fitting the definition of "Per-website JS opt-in". Developers are not supporting this development model.

designing usable and much needed non-JS alternatives for common use cases

This is the research that @alcinnz is leading: PostJS Web.
You can join us on the mailing list.

I am so glad to read this! Count me in! I just subscribed. I have some ideas to share.

@Shamar
Copy link

Shamar commented Nov 29, 2018

Just like before HTML5 client-side form input validation was impossible without JS

You forget XForms.
The people who created HTML5 to spread JavaScript adoption are the same people who did not completed the implementation of XForms, despite it was addressing these same issues.
JavaScript was a (legit) political decision but not a technical one.

Developers are not supporting this development model.

This would be a legit decision, but it's not what they are doing.
They omit to inform their users: people, companies and organizations.

I have some ideas to share.

You are welcome! :-)

Copy link

Shamar commented Jan 3, 2019

Hi @rain-1, good catch on telegram!

What it “breaks” to is some kind of debugging utility and / or security test proxy. It is not clear why Roskomnadzor needs this.

This puzzled me a bit too, till I realized that such tools can be used to detect the evidence removal I described in the Mozilla bug report. In practice they want to know who could detect a JavaScript attack despite the clever use of cache control header.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants