VuNote ====== Author: Ref: https://github.com/tintinweb/pub/tree/master/pocs/cve-2017-18016 Version: 0.3 Date: Jun 16th, 2017 Tag: parity same origin policy bypass webproxy token reuse Overview -------- Name: parity Vendor: paritytech References: * https://parity.io/ [1] Version: 1.6.8 Latest Version: 1.7.12 (stable) - fixed 1.8.5 (beta) - fixed Other Versions: <= 1.6.10 (stable) - vulnerable Platform(s): cross Technology: rust js Vuln Classes: CWE-346 Origin: local (remote website, malicious dapp) Min. Privs.: --- CVE: CVE-2017-18016 Description --------- quote website [1] >Parity Technologies is proud to present our powerful new Parity Browser. Integrated directly into your Web browser, Parity is the fastest and most secure way of interacting with the Ethereum network. Summary ------- PoC: https://tintinweb.github.io/pub/pocs/cve-2017-18016/ [4] > Parity Browser <=1.6.8 allows remote attackers to bypass the Same Origin Policy and obtain sensitive information by requesting other websites via the Parity web proxy engine (reusing the current website's token, which is not bound to an origin). ![parity cookie](sop_cookie.gif) **(A)** Ethereum Parity's built-in dapp/web-browsing functionality is rendering browser same-origin policy (SOP) ineffective by proxying requests with the parity main process. As a result, any website navigated to ends up being origin http://localhost:8080. This also means that all websites navigated to share the same origin and thus are not protected by the browser SOP allowing any proxied website/dapp to access another proxied website/dapp's resources (Cookies, ...). //see attached PoC - index.html / PoC ![parity frame](sop_frame.gif) **(B)** Worse, due to the structure of proxy cache urls and the fact that they contain a reusable non-secret non-url specific cache-token it is possible for one proxied website/dapp to navigate to any other proxied website/dapp gaining full script/XHR control due to **(A)** the SOP being applied without any restrictions. This could allow a malicious website/dapp to take control of another website/dapp, performing user interactions, XHR or injecting scripts/DOM elements to mislead the user or to cause other unspecified damage. When navigating to a website with the built-in parity webbrowser a webproxy request token is requested and sent along an encoded request for an url. For example, navigating parity to http://oststrom.com the url gets turned into a proxy url like http://127.0.0.1:8080/web/8X4Q4EBJ71SM2CK6E5AQ6YBNB4NPGX3ME0X2YBVFEDT76X3JDXPJWRVFDM of the form http://127.0.0.1:8080/web/[base32_encode(token+url)]. A malicious dapp can use this information to decode its own url, extract the token and reuse it for any other url as the token is not locked to the url. The PoC exploits this in order to load any other website into a same-origin iframe by reusing the proxy token. Code see [2] //see attached PoC - index.html / PoC Proof of Concept ---------------- Prerequisites: * (if hosted locally) modify /etc/hosts to resolve your testdomain to your webserver * make `index.html` accessible on a webserver (e.g. `cd /path/to/index.html; python -m SimpleHTTPServer 80`) 1. launch parity, navigate to the built-in webbrowser (http://127.0.0.1:8180/#/web) 2. navigate the built-in parity webbrowser to where the PoC `index.html` is hosted (e.g. [4]) 3. follow the instructions. 4. Issue 1: navigate to some websites to have them set cookies, reload the PoC page and click "Display Cookies". Note that while the main request is proxied by parity, subsequent calls might not be (e.g. xhr, resources). That means you'll only see cookies set by the main site as only the initial call shares the origin `localhost:8080`. 5. Issue 2: enter an url into the textbox and hit `Spawn SOP Iframe`. A new iframe will appear on the bottom of the page containing the proxied website. Note that the calling website has full script/dom/xhr access to the proxied target. You can also use the "Display Cookies" button from Issue 1 to show cookies that have been merged into the origin by loading the proxied iframe. 6. Demo 2: Just a PoC to find local-lan web interfaces (e.g. your gateways web interface) and potentially mess with its configuration (e.g. router with default password on your lan being reconfigured by malicious dapp that excploits the token reuse issue 2) //tested with latest chrome Notes ----- * Commit [3] (first in 1.7.0) * Does not fix Issue #1 - sites are generally put into same origin due to proxy * Fixes Issue #2 - Token Reuse * Parity now added a note that browsing websites with their browser is insecure ![parity fixed](v171.png) * Issue #1 is not yet fixed as the cookie of instagram.com is still shown. * Parity v1.7.12 added a note. Timeline -------- 31.05.2017 - first contact, forwarded to parity 17.06.2017 - provided PoC 19.06.2017 - response: not critical issue due to internal browser being a dapp browser and not a generic web browser 20.06.2017 - provided more information 21.06.2017 - response: not critical issue due to internal browser being a dapp browser and not a generic web browser 21.06.2017 - response: follow-up - looking into means to lock the token to a website 22.06.2017 - fix ready [3] 10.01.2018 - public disclosure References ---------- [1] https://parity.io/ [2] https://github.com/paritytech/parity/blame/e8b418ca03866fd952d456830b30e9225c81035a/dapps/src/web.rs [3] https://github.com/paritytech/parity/commit/53609f703e2f1af76441344ac3b72811c726a215 [4] https://tintinweb.github.io/pub/pocs/cve-2017-18016/ Contact ------- https://github.com/tintinweb Ethereum | Parity SOP Vulnerability

Parity SOP Bypass

Same-Origin Policy Bypass in Parity's Dapp Browser

Disclaimer

/* This program is free software. It comes without any warranty, to
 * the extent permitted by applicable law. You can redistribute it
 * and/or modify it under the terms of the GNU General Public License,
 * Version 2, as published by the Free Software Foundation. See
 * github.com/tintinweb/pub/tree/master/pocs/cve-2017-18016/
 * for more details. */

Issue #1

Same-Origin Policy (SOP) bypass vulnerability due to parity proxying websites

Every webpage you browse to with parity's built-in browser (http://127.0.0.1:8180/#/web) is proxied via http://127.0.0.1:8080. For example, when you browse to

http://google.com's the websites origin changes to 127.0.0.1:8080.
Navigating to http://oststrom.com changes the origin to 127.0.0.1:8080 as it is proxied via parity.

Both websites therefore share the same origin rendering a core feature of modern web browsers - the Same-Origin Policy - ineffective. A website is same-origin if proto, host and port (iexplore does not check port) match. Bypassing the SOP gives full control over XHR and DOM of child nodes (including iframe source) with the same origin.

Warning This means, as there's only one origin for all websites, non domain restricted cookies are effectively shared with all websites.

DEMO #1 Cookies shared with other websites

1) using parity's built-in browser, navigate to any website to set a cookie (e.g. http://google.com)
2) reload this this PoC (https://tintinweb.github.io/pub/pocs/cve-2017-18016/)
3) hit the Display Cookies button

Display Cookies

Issue #2

Parity WebProxy Token Reuse vulnerability

When navigating to a website with the built-in parity webbrowser a webproxy request token is requested and sent along an encoded request for an url. For example, navigating parity to http://oststrom.com the url gets turned into a proxy url like http://127.0.0.1:8080/web/8X4Q4EBJ71SM2CK6E5AQ6YBNB4NPGX3ME0X2YBVFEDT76X3JDXPJWRVFDM of the form http://127.0.0.1:8080/web/[base32_encode(token+url)].

Warning When navigating to http://oststrom.com the website can detect that it has been proxied by checking the location.href. It can further base32 decode and extract the web-proxy token and simply reuse it as the token is not bound to any specifiy request url or hostname allowing any website to create proxy urls and navigate to any other website.

Info The parity webbrowser does not allow a proxied website to change the top frames location or open new windows (iframe sandbox).

Warning However, it allows to perform XHR or embed iframes with script access to proxied locations of arbitrary websites. This allows one website to control any other website since they're both same origin (Issue 1).

Info The controlling website has full scripting access to sub-iframes potentially allowing for service enumeration attacks or simulate user interaction.

DEMO #2 Full control of arbitrary websites via token reuse and SOP bypass

1) enter url into the textbox
2) hit Spawn SOP Iframe

Notes:

Note the current page can modify/inject arbitrary DOM/scripting into the iframe, access cookies (only the ones stored for 127.0.0.1, potentially from prevs sessions with parity), manipulate change and reload the websites content (e.g. removing parity's inject.js), get the source via XHR
Note some websites may not load due to js errors. However, since the website has full control it is likely the calling website can fix any js errors occuring in the subframe.
Note Untested but likely possible: Prepare a transaction to send off ether via parity/web3 api or xhr, open an iframe or perform requests to directly authorize (may require unlock secret) or redress the UI to clickjack the authorization or perform other actions messing with the users account

Spawn SOP Iframe

DEMO #3 (Chrome) get local lan ip and service scan for web-enabled devices on the LAN to mess with them
e.g. search for local router interfaces with default passwords and reconfigure it to perform DNS based redirection attacks (mitm) or similar

1) click 'Find LAN-Local WebInterfaces' to scan for devices listening on http port 80 within your LAN (IP .1 to .254)
2) an iframe with full control will be created for each device found on the lan
Note: might require some fixups for the iframe conted to be loaded completely due to parity webproxy messing with header scripts or websites unable to be loaded via iframes. XHR should work though and CSRF tokens can be read from XHR requests or iframe dom (if dom based). See javascript console for debug.

Find LAN-Local WebInterfaces

Stop on first device

//tintinweb

Query Builder