JVNTA#96129397
Falsification and eavesdropping of contents across multiple websites via Web Rehosting services

Overview

Researchers at NTT Secure Platform Laboratories and Waseda University have identified multiple security issues that lead to content being tampered with and eavesdropped on a service called Web Rehosting. These issues have been published in NDSS 2020.

"Web Rehosting" is the name of a group of web services proposed in this study, which has the function of retrieving content from a user-specified website and hosting it again on its server.
Web rehosting includes a web proxy service that allows users to specify the URLs they want to view from the web interface, a web translation service that translates the entire website and a web archive service that stores snapshots of the website.

If a web rehosting service does not take measures against the attacks listed in this advisory, there is a risk that some of the browser resources of users may be manipulated by an attacker, resulting in a security and privacy violation.

Web rehosting service owners can refer to the "Solution" section for countermeasures.

Products Affected

Web rehosting service user's browser.

Description

About Web Rehosting

Web Rehosting is a service that allows users to view the contents of other websites after rehosting them. It is widely used by Internet users as a service that provides functions to ensure the openness of the Internet. For example, there are many types of web rehosting such as web proxy services to bypass filtering and censorship, web translation services to overcome language barriers, and web archiving services to view contents in the past. Even if a website is not directly accessible to some users, web rehosting service can host the website on its server, and these users can access and view the content through the web rehosting service.

Attack Mechanism

Web rehosting service rehosts contents from a website on the domain of the web rehosting service. In general, web browsers have a mechanism called Same Origin Policy (SOP), which controls access based on the origin identified by a combination of a URL scheme, domain name, and port number. However, in the web rehosting service, multiple contents of different origins are merged and sent to the user as a single origin. The access control by SOP does not work properly in this case because the multiple contents received via Web Rehosting are recognized as the same origin in the browser. By exploiting this feature, a malicious website can negatively affect the rehosted website's contents.

The paper Melting Pot of Origins: Compromising the Intermediary Web Services that Rehost Websites published by the research team, describes five types of attacks that is possible by using origin unification in web rehosting services:

(I) Persistent-MITM: Interception and alteration of communications by continuous man-in-the-middle attacks
(II) Privilege Abuse: Information leak by abusing access privileges to a resource
(III) Credential Theft: Password information leak by abusing the auto-completion feature of a password manager
(IV) History Theft: Leak of browsing history from resource files such as cookies and localStorage
(V) Session Hijacking and Injection: Exploitation of the web session by stealing cookies that manage user login status

Attack (I) can be made if a victim user accesses a malicious website before accessing a non-malicious one via the web rehosting, while attacks (II) through (V) can be made when a victim user accesses a malicious website after accessing a legitimate website via a web rehosting.

(I) Persistent-MITM

The most severe attack among the five above is Persistent-MITM. In this attack, a malicious script is registered in the user's browser when the user accesses a malicious website that is rehosted on a web rehosting service. The registered scripts are linked to the origin of the web rehosting and thereafter monitor every request and response when the victim user visits a non-malicious website on the same web rehosting service, allowing man-in-the-middle attacks. This malicious script will continue to work semi-permanently until the data stored in the browser is deleted or reinstalled.

Specifically, the attacker exploits a web function called Service Worker to conduct the Persistent-MITM attack. Service Worker is a powerful function that allows users to register event-driven scripts (Service Worker scripts) in their browsers to control the communication between the browser and the web service. In normal use, the author of a website registers a Service Script that is linked to the origin of their web service, and it is not expected that a script created by others is registered. However, an attacker can link a malicious script to the origin of a web rehosting service and register it in the user's browser.

The attacker can also use another web function called Application Cache (AppCache) instead of Service Worker to conduct a similar attack. In this attack, a file called Cache Manifest is registered in the user's browser. Although AppCache has already been removed from the W3C standard, it has been confirmed that AppCache still works on all major browsers.

(II) Privilege Abuse

In Privilege Abuse attacks, a malicious website reuses permissions given to other websites viewed by the victim user through the same web rehosting service.

When a website attempts to access a permission-protected resource (such as location information, microphones, and cameras) for the first time, usually a confirmation dialog pops up on the browser screen. The permission given by the user is stored on the website (and linked to the origin of the website) so that the private information can be retrieved without automatically from the next time the user attempts to access the resource. However, if such permission is given on a website accessed via web rehosting, the permission would be applicable to the entire web rehosting origin. This allows an attacker to steal the private information from users who visit a malicious website through the web rehosting service skipping a confirmation dialog.

(III) Credential Theft

In Credential Theft attacks, attackers steal user's credentials such as IDs and passwords This attack can be successfully conducted if credentials are stored in the password manager installed in the browser when the user logs in to a website via web rehosting. In such a situation, the user's credentials are stored and linked to the origin of the web rehosting service. When the user accesses a rehosted malicious website, the password manager automatically fills the fake login form on the malicious website with the stored ID and password. These credentials are sent to the attacker.

This attack is mainly applicable to users using web proxy services, but not to web translation services or web archive services, which do not support login functions. In addition, the attack fails either if the user does not use a password manager or if the password manager does not automatically fill the login form with an ID and password.

(IV) History Theft

In History Theft attacks, browsing history of websites accessed via web rehosting is guessed by an attacker. In general, some websites write string data on the storage in a browser, such as cookie or localStorage. Once the user visits such websites via web rehosting, cookies and localStorage data are linked to the origin of the web rehosting service. Attackers can collect these cookies and localStorage data stored by other websites when the user visits a rehosted malicious website. Although the string data stored in cookies and localStorage vary from website to website, if the data contain any strings unique to a particular website, the attacker can presume that the user has visited that website.

This attack is not successful if the rehosted website does not write data to the cookie and localStorage, or if the stored string data is contained by multiple websites and is not specific to a single website.

(V) Session Hijacking and Injection

With Session Hijacking, attackers can steal session cookies that manage user login status on web rehosting. If the web rehosting service supports login to a rehosted website, session cookies sent from the website are relayed through the web rehosting service and stored in the user's browser. In such a case the Domain attribute of the session cookie is converted from the domain of the original website to that of the web rehosting service. Rehosted malicious websites can access and steal this session cookie using the same techniques as cross-site scripting. This attack can be conducted successfully unless the session cookie is set to HTTPOnly.

Session Injection attack applies the techniques of an attacker intentionally stores a session cookie in the user's browser, forcing the user to log in to an account that the attacker prepared in advance. Since search engines and video sites accumulate information such as search and browsing history, Session Injection is an effective way for attackers to track a user's behavior and collect their private information.

Just like (III), this attack can be conducted only to those who use web proxies. Neither it does work with web translations nor web archives, which do not support website logins.

Impact

(I) Persistent-MITM

Service Worker and AppCache on a malicious website accessed through a web rehosting service can permanently work on the user's browser. This could be exploited to conduct a man-in-the-middle attack.

(II) Privilege Abuse

When a user gives permissions of access to resources such as cameras and location data to a website accessed through a web rehosting service, the same permissions can be applied to the subsequently rehosted malicious website. Therefore, the permissions could be reused by the malicious website.

(III) Credential Theft

When a user logs into a website via web rehosting and saves their credentials (e.g. ID and password) in the browser, the password manager automatically fills the forms with stored credentials when the user accesses a malicious website through the web rehosting service.

(IV) History Theft

A rehosted malicious website can access and steal localStorage or cookie data from another website previously accessed through the same web rehosting service. Such information can be used to guess sensitive information such as browsing history.

(V) Session Hijacking and Injection

In Session Hijacking, attackers steal session cookies of others to log in to their SNS or EC sites. Attackers can steal personal information of the victim users and impersonate them. In Session Injection, a victim user is forced to log in to a website with an account prepared by an attacker, and the attacker tracks the victim user's activities(e.g. search/viewing history) and steals personal information.

Solution

Web rehosting services should implement the following countermeasures:

Set a different subdomain for each rehosted website

This countermeasure is effective against all types of attacks above.

Set up a different subdomain for each rehosted website to ensure the Same Origin Policy.

e.g.
<https://rehosted.example/?url=a.example>
<https://rehosted.example/?url=b.example>
↓
<https://a-example.rehosted.example/>
<https://b-example.rehosted.example/>

Set a temporarily URL for each rehosted website

This countermeasure is effective against all types of attacks above.

For example, temporary token makes the URL of a rehosted website inaccessible to an attacker. However, this method cannot be used in services in which URLs are shared among multiple users, such as web archives.

Disable Service Worker and AppCache

This countermeasure is effective against the attack (I).

When loading Service Worker, the request header of the website includes Service-Worker: script field. Removing this field prevents a malicious Service Worker from being installed in the user's browser.
To prevent malicious AppCache behavior, refuse to rehost the cache manifest file required for AppCache.

In general, many web rehosting services do not support access to Service Worker or AppCache. This is because rehosting the website changes the URL. URLs pre-defined for Service Worker and AppCache become unusable. An attack can only be successful when the attacker successfully predicts the URL that will be given to the malicious Service Worker or AppCache. In other words, the Service Worker and AppCache of a rehosted website can be abused, but they cannot be used for their intended function. Therefore, disabling Service Worker or AppCache does not interfere with the original purpose of the web rehosting service in most cases. However, please note that some services may become unavailable if the web rehosting service supports Service Work and/or App Cache.

Render the rehosted website in a sandboxed iframe

This countermeasure is effective against the attack (III).

Sandboxed iframe by sandbox attribute cannot request permissions. Web rehosting service can prevent malicious permission requests by displaying the rehosted website in the sandboxed iframe. This is already in place in some web rehosting services.

Set HttpOnly attribute to the session cookie

This countermeasure is effective against the attack (V).

Web rehosting service can prevent JavaScript from managing the session by adding HttpOnly attribute to the session cookie when relaying the cookie to the user's browser. HttpOnly is generally recommended as a countermeasure against session hijacking using XSS.

For web rehosting service users, the following measures are recommended:

Use private mode of your browser

This measure is effective against the attacks (I) to (V).

If you enable private mode in your browser while using the web rehosting service, each type of the attacks listed above is less likely to succeed because the data stored in Service Worker, cookies, and other resources are deleted every time the browser/tab is closed.

Do not log into websites on the web rehosting service

This measure is effective against the attacks (III) and (V).

Do not grant permissions on the web rehosting service

This measure is effective against the attack (II).