DOMtegrity: Ensuring Web Page Integrity against Browser Extension Modifications

In the following demonstration, we assume that a malicious extension is already installed on a client's browser. This can be done through disguising malicious extensions as legitimate browser extensions, using Trojans to install such extensions, missing plug-in attacks, or purchasing popular extensions and then adding malicious code during updates. In both attacks, the web pages that are presented to the victim are from the genuine banking websites via HTTPS.

The first attack shows how a malicious extension can easily bypass the two-factor authentication that is adopted by major banks, including HSBC. In this attack, the extension intercepts the victim's authentication credentials (i.e., login details), sends them to a remote attacker and redirects the user to a false maintenance page. Depending on the security policy of the banking web site, this authentication could involve a regular password and an additional one-time password (OTP) as a second factor which is either sent to the user's mobile phone as an SMS or locally generated using a dedicated device (i.e., a Chip Authentication Program (CAP) device) provided by the bank.

We developed a proof-of-concept attack that targets the HSBC online banking web pages. To authenticate their clients, HSBC uses a password-based user authentication augmented with an OTP generated by a dedicated device, the HSBC Physical Secure Key.

Our attack works as follows:

• When the victim requests the login page, the browser extension content script replaces the username and password text boxes with its own and records the victim's username and password by communicating with the extension background page.
• When the victim is prompted for an OTP, the browser extension records what the victim enters in a similar manner.
• The victim is then redirected to a genuine customer service page. However, the content of the page is changed on the fly by the extension content script to include a message indicating that the website is temporarily unavailable for maintenance or due to technical difficulties as shown
• The stolen login credentials are sent to the attacker who can then log into the victim's online banking account.

The second attack shows how a malicious extension can defeat transaction-specific user authorization, which is added by many banks such as Barclays as an extra layer of security on top of two-factor authentication. Here, when an already authenticated user requests a transaction, she is required to provide a transaction-specific authorization code which is either sent to the user out of band or generated by a dedicated device upon unique transaction-specific input. This transaction authentication is designed to prevent modification of transaction data (e.g., recipient and amount) by man-in-the-browser attackers. Barclays uses the strongest form of transaction authentication (the so-called full transaction authentication in which the unique transaction authorization code (i.e., the transaction-specific OTP) is cryptographically bound to the transaction data. The authorization code is calculated by a dedicated device provided by Barclays called PINsentry. Alternatively, the user can use the functionally equivalent Mobile PINsentry application on her smartphone. When a transaction is requested through Internet banking, the user is required to manually enter the transaction details, including the payee account number and the amount, on PINsentry (or Mobile PINsentry) and then enter the PINsentry produced authorization code on the internet banking web page.

In the following we show how a malicious extension can defeat this security measure by combining social engineering and DOM modifications. The attack works as follows:

• When the victim requests a funds transfer, she is presented a form to provide the details of the funds transfer, including the payee account number and the amount. The malicious extension content script replaces the text box where the victim is supposed to enter the account number of the intended payee with its own text box and records the entered account number by communicating with the extension background page.
• Then the user is presented with a dialogue confirming the transaction details and instructing her how to get a transaction authorization code from PINsentry. The instructions include asking the user to Enter the payee's account number as your REF followed by the payee's account number. The malicious extension content script replaces this instruction with Enter this REF number followed by the attacker's account number.
• A non-expert user, trusting the HTTPS page to be secure and failing to notice the above subtle change, then enters the attacker's bank details in PINsentry and provides a code authorizing the funds transfer to the attacker's account.
• The browser extension changes the final confirmation page before it is displayed to the user so that it shows the account details of the original intended payee rather than that of the attacker.

DOMtegrity is designed to enable the server to detect any unexpected modification of the DOM by extensions when the web page is rendered in the browser. The underlying idea is that DOMtegrity securely records all the modifications made to the web page DOM until the final rendering of the page and then securely communicates the recorded modifications to the server. The server is then in a position to decide whether or not the client's browser has parsed the page as the server expected.

DOMtegrity is implemented as a JavaScript program, called pid.js, which is then embedded as an in-line script (within a ≺script≻ tag) in the web page that the server wishes to protect. This in-line inclusion is necessary since extensions are not able to restrict the execution of in-line web page scripts, whereas they can block loading external script files. For the in-line Javascript to work, we assume that JavaScript execution is not disabled in the browser.

Since DOMtegrity is to record all modifications to the DOM, it is essential that pid.js is placed at the start of the page source code and before all other HTML tags. Since parsing the web page in browser proceeds in the order that tags are placed in the page source code, placing pid.js at the start of the page ensures that recording changes in the DOM starts immediately as the browser starts parsing the page.

The isolated worlds principle guarantees that DOMtegrity's recording of modifications in DOM cannot be tampered with by any extension. When executed, pid.js creates an on-the-fly DOM property (also called a DOM expando) named document.pid which implements the DOMtegrity functions within a domain isolated from any extension.

The extension's inability to access Websocket communication established by DOMtegrity provides assurance on the integrity of the communication between pid.js and the server. The in-line script pid.js establishes a Websocket with the server and this Websocket is used as a secure channel to convey a secret key which is later used to authenticate the DOM modifications that document.pid records. We should emphasize that although an extension has extensive access to HTTP(S) communications, it can only access the Websockets that are established by the same extension.

DOMtegrity runs in three stages:

1. Initialization: This stage begins as the browser starts parsing the web page. In this stage, the required setup for DOMtegrity is carried out as: Open Websocket and Request Key from server, Define DOM Mutation Observer, Stop Event Propagation, Define DOM Expando (as shown in the figure below.)
2. Recording: After initialization, DOMtegrity enters a persistent passive mode and records all DOM mutations through the mutation observer.
3. Verification: a page identifier (PID) containing the recorded changes in the DOM is generated. The stage starts when the function document.pid.request() is called. This is the only public expando function and should be called when the client ``returns'' the form, e.g., by clicking a ``submit'' button. This stage uses Web Crypto API.

Full security analysis of DOmtegrity and how it protects DOM from malicious modifications are presented in our  full paper

We argued DOMtegrity is protected against the following attacks: impersonation attacks, malicious attempts to influence its execution, eavesdropping the secure channel by extensions, pollution of JavaScript global variables via monkey patching, and more importently, the new capability added from Chrome v.58 to enable partial access to webSocket channels.