How to detect or prevent built-in browser functions from being replaced?

user_284013 0
Viewed 64

I noticed today that I can replace a sensitive built-in JS function like this:

async function _hackedEncrypt(algorithm, key, data) {
   console.log('hacked you!');
}

const subtle = global.crypto.subtle; // Assign to get around "read-only" error.
subtle.encrypt = _hackedEncrypt;

global.crypto.subtle.encrypt(); // 'Hacked you!' appears in console.

Yikes!

This exploit is so simple. Any of the thousands of dependencies (direct and transitive) in my web app could make this function reassignment. Note that my question isn't specific to Web Crypto - it's just one of the more dangerous targets for an attacker.

How can I either detect that the function has been reassigned or guarantee that I'm always calling the original browser implementation of it?

websecurity security dom javascript
3 Answers

What you are describing is a subset of a broader class of attacks: Supply Chain Attacks.

The basic idea is that I create a JS library that is useful and trivial, over time a ton of projects depend on it, then I insert a back door, next time they upgrade they're dependencies - I have access to their users' browsers.
I can then steal passwords, credit card info, PII, etc. - basically digital skimming. Magecart is probably being the best known attack in the JS space. Probably the best known one in general is the Solarwinds attack.

One solution is to roll your own. That is pretty much hopeless, because even though you might know what APIs you use, you don't know what your dependencies use, and how that changes.

Another solution is Content Security Policy, which controls outgoing requests: a skimmer might have been able to put their code in your app, but they can't do anything useful if your content security policy doesn't let it issue requests to unknown hosts.

There are also commercial solution. I'm aware of:

user_106789550

In my index.js, I import this module ahead of any other modules. It must be the first import so that other dependencies don't get a chance to replace a function before I can set a reference to the original.

const originalEncrypt = global.crypto.subtle.encrypt;
// Any number of functions worth protecting can be added here
// and also added to the check in wereFunctionsReplaced().

function wereFunctionsReplaced() {
  return global.crypto.subtle.encrypt !== originalEncrypt;
}

...and then I call wereFunctionsReplaced() ahead of the function call I'm worried about:

if (wereFunctionsReplaced()) throw Error('Everybody run to the panic room!');
global.crypto.subtle.encrypt(algorithm, key, data);

Of course, I could also wrap the protected functions like:

function safeEncrypt(algorithm, key, data) {
  if (wereFunctionsReplaced()) throw Error('Everybody run to the panic room!');
  return global.crypto.subtle.encrypt(algorithm, key, data);
}

In some cases, it would be more convenient to store the built-in function to a variable and call the function directly from the variable rather than from global.*. But for crypto.subtle.encrypt it will throw a "Bad invocation" error in Chrome. And thinking harder about it, many subtle, unexpected behaviors could be caused by calling the built-in functions outside their expected location in the global hierarchy.

This is a self-answer for posterity. But I would love to hear better solutions than this one. Criticism on any faults this solution may have is welcome as well.

user_2840130

There is finally a solution to your problem in the form of a consumable js lib.

After long research and development in the supply chain attack field, I created Securely to answer this problem exactly:

After loading securely in the web page, the SECURE API will be exposed (make sure this runs first - anything that runs before securely can disable its effect).

First you declare what APIs you want to protect:

const securely = SECURE(window, {
    objects: {
        'window': ['fetch'],
    }
});

Then you use the returned securely callback to run secured operations and by that have access to the native original function, even if it was overridden:

window.fetch = () => console.log('DISABLED');

securely(_ => {
  window.fetchS('https://example.com/sensitive_request/');
});

window.fetch('https://example.com/sensitive_request/'); // DISABLED

In the example, the fetchS property is inaccessible unless using the securely callback (this is to hide the real behaviour from malicious entities in the webpage).

Read more about it, help with the project is highly appreciated!

Here's a demonstration of how it works live.

Securely is part of a broader attempt to better defend against supply chain attacks. To learn more about our effort, check out Snow, Across which are all part of the LavaMoat project.

user_44646280
Related