Extending Password (in)Security to the Browser: How Malicious Browser Extensions Steal User Passwords

So we're going to resume uh passwordscon with extending password insecurity to to the browser. How malicious browser extensions are used to steal user passwords. And I'll hand over now to orchesting

the folks in the back. All right. You can take pictures, but I'm not accountable if they go bad. That's I can't I can't help it. Um I want to start with a simple question. How many of you by raising your hands remember the cyber haven breach in Christmas of last year? Okay, so relatively low. So during this session, we'll talk a little bit about how malicious extensions can be used to steal credentials, identity, data, passwords, and then we'll actually go back to that bridge and analyze it a little bit if we have time. A bit about myself. My name is Orish. Yes, or is my name. I know my mom never thought that this will happen this conversation. So

people will ask me is that a real name? It is a real name. Uh in the last 15 years I'm doing web security from every possible angle uh including offensive defensive projects for uh end companies. Honestly at any company that I've been to eventually it goes to something stupid employees do online. So passwords and web are always a part of it regardless of how much identity security is progressing. H during my career uh I was running the takedown of a large browser hijacker called fireball in 2016 and 2017 and uh for a couple of years I was doing a IR that led to the catch of a couple of bad guys that had a really

bad network security architecture on their on their behalf. So if you do bad stuff which is criminal, make sure not to deploy that on your own device because people can find you that. And in today's session, we'll cover three parts. The first one is understanding a little bit about security threats about of browser extensions. So we move from assuming you're all uh basics amateurs in extension security to understanding how it works. Then specifying that to identity security and password security. Eventually we'll talk a little bit of what can you do with that regard. I'm an open book. Eventually we'll have a Q&A. I'm open to any kind of question and I'll try to put a little bit of examples

from day-to-day life. So that's what we'll do and the benefits of that will be that we'll understand the risks posed by malicious extensions understand exactly uh the the specifications of attacks using malicious extensions. So in the context of passwords which permissions how do they get infected how do they get in etc etc as well with examples and talk a little bit about how can that be used to uh how can you use this knowledge to improve security within your organizations or if you guys are bad guys how can you develop your malicious extensions better so we will all improve today uh as introduction let's talk a little bit about browsers and identities now I'm not good at design so the

presentation assumed that what I should have is uploaded to chat and ask for improvements of visuals. So you'll forgive me. So we've seen some sort of an evolution in the last about 20 years a bit more than that from at the beginning avocado structure of organization where you had uh an out of shell a soft interior really juicy where all the data is in inside organizations had all access done inside a network. This is the fine days of NDR companies that I think within a couple of years will go extinct like dinosaurs. At that time access was limited to physical line or virtual line. So a VPN or some sort of an IP range. Then more and more

things moved outside of the organization to some sort of a basic uh authentication process without federation primarily based on host name. So a firewall or proxy would be able to recognize which destination is based on the site. And there was no identity security. Those are defined days of anti-ishing solutions and awareness training. in last couple of years improvements to using 2FA then MFA then federation with ITDR all kinds of identity governance etc etc so organizations today have all of their data pretty much outside authentication is done on multiple apps multiple identities a hostnip cannot specify a specific identity in a specific tenant because on the same application I can have multiple tenants me personally I I

can go to chip.com I have a million accounts over there and all of them are communicating to the same address and many of them are using a personal identity, some of them are federated, some of them are not all very very different than one another. So the world has pretty much changed in regard to how we use identities at work. Now with that regard things affected also on the way that run in the browser. Now this is a very simplistic process. When I sign into an application and I'm happy that you all see it because that will amaze you. I'm kidding. It's basic. I authenticate once and then in order to avoid being exhausted by authenticating

again and again and again and again a cookie is being created in my browser. Uh now a cookie is a mechanism which is older than some of the folks in this room and the only thing in it that didn't change whatsoever. There is typically like a 32 characters or 16 characters token over there that says hey he is who he's claiming to be. Basically that's what it is. And then in order to avoid reauthenticating again and again that's the website is able to check that on my browser. Uh and then the assumption is that considering this for the validity of the cookie that sometimes organizations manage and sometimes they don't. So you'll find some cookies existent for a couple of

years like a store bought candies and sometimes are existent for like a week homemade candies and then there is some sort of a security enhancement around that that includes encryption. Now this diagram is very simplistic because I'm lazy but basically the cookie is stored on the device but it is secure and encrypted from the device standpoint uh using the browser encryption mechanisms. That means in other words that other tools on my device are not supposed to see my cookies and their content on the device unless they find some sort of a key that the browser is managing or hiding somewhere. Then again the traffic from the browser to the application is also encrypted with some sort of a TLS

key in the future postquantum encryption sci-fi alien proof encryption regardless of that in between inside the browser itself it's all in clear text wild wild west everything over there is visible to anyone sitting inside the browser so it can be a website but the website only sees its own cookies so there is no cross site uh visibility and any other instrument that has access to the session that means users and extensions because extensions see everything in real time. Um so pretty much you know organizations that not really know don't don't really know what's happening within the session have no idea. Now uh now in this month in the upcoming versions of Chrome Edge and Firefox all

of them will have an embedded AI. It took me about 8 minutes to say I for the first time. So uh so they all have some sort of an AI embedded inside of them with its own API. There will be something that can see that as well. So we'll see changes in what has access to those cookies and those credentials. We know also that Google is trying to make changes to this mechanism, but it's really hard because it's impacting user experience. Now that leads us to some sort of an insight that zero trust is dead in the browser because there is no real zero trust. Whoever has my cookie can get in my behalf. No real

validation, no real authentication. You don't always suspect or whatever they say about zero trust. And that there are a lot of like loose ends to that mechanism. For example, password managers in the browser. Not all malicious, not all bad extensions are malicious. Some of them are just doing something unintentional. Profile syncs. Uh profile sync can extract passwords. A nice example that I found over Reddit, a great place to find cases for security is a sock analyst reporting that they found a key logger extension on one of their browsers fetching credentials. Apparently, they had an employee who was suspected by her husband to be cheating. So he deployed on her home device a key logger to collect all her data including

all her passwords so he can sign in into her uh apps and see what is she's doing and apparently that uh password manager got sync to a work device fetching all the credentials from the work applications so this functionality is a functionality it's not evil by design it's just there and then you have by as well that may affect that as well in any case we have a problem okay so on the background authentication access all of that is really improving but all the improvements we're making are pretty much a a still going to the same uh bottleneck because all those factors of authentications we add all happen within a web session and once they're being

approved there is a cookie in the browser. So we're pretty much putting more and more and more and more and more power on the same failed mechanism inside the process between the user and app. Are we good so far? Are we scared? Perfect. Okay. So now let's talk about the other side of it. extensions and how can they be the really awesome weapon to uh to do really powerful things. So first of all, what is an extension? An extension is a piece that's being added to an application or a browser in our case that's running in the browser in an agentless manner. What does that mean? It means technically that if I open my uh dev tools and look for an extension,

it will be non-existent in in the eyes of the device or the edr. So macros strike will not see cookie stealer uh stealing cookies. It will see Chrome touching a cookie on its own cookie repository which seems really really really benign. Uh it means that whenever the browser is on all the extensions are always on and when the browser is off it's also off because of the fact that the extension is only there to fetch data from the browser. We are fine with the fact that it's aless. Now it has both an agent and a network functionality. What does that mean? that there is one memory unit that it has which is persistent as long as the

browser is on. Uh in the last couple of years across I say like hundreds of customer environments only once I got asked by a customer what happens when the browser is off. Out of all of those organizations we met only one organization had the exotic scenario in which a browser is off internally. Actually we were so surprised by the question that we went opened up a lab to check what happens when the browser is being launched because we just assumed that the browser is always on. So also in that case whenever the browser goes on the agent piece immediately starts the browser extension also got a network functionality which is a fancy word for able to inject code into any website.

Then it has a visibility to unencrypted traffic and data of the browser. So it means that whatever improvements existing or happening in browser security or networking whether that's postquantum encryption, enhanced encryption, an enterprise browser with with its own fancy encryption mechanism, it doesn't really matter inside the browser. It's a really uh it's a really you know crazy party where all the data is visible to everyone. Uh it can use or abuse browser access and visibility. We won't talk about that today but all kinds of permissions for the browser extension. for example, uh it's very very elementary for a browser extension to get access to the downloads folder of the browser. In many cases, that's where all data is being stored

and there's even a permission that some extensions have to enumerate the file system of the device. So, in theory, some malicious extensions can actually run over the device itself, steal data, can listen to traffic fields. Uh we just released a research about the ability to sniff traffic from prompts. So, they can s do anything that uh a power user can do in the browser. and uh over time that's very important. So I come from malware analysis with malware analysis we check hashes or fuzzy hashes and all kinds of rules. So we are assuming that something is similar within different versions of the same payload that doesn't exist in extensions. Extensions got only two things which are definitive in their

existence. One is the ID. The second one is who has it installed. What does that mean? Jared here from Larex is a great guy and if he develops some sort of a productivity extension um that is behind it will have an ID it will have you know hundreds of thousands of installations let's say that I buy his extension on the dark web and I can change the content I can change the name I can change the code I can change anything it wouldn't matter it will still be running on the same devices with the same ID so once someone for example approved it once it will stay approved forever and this is what attackers are doing with

that regard we talked about the cyber driven breach when attackers are taking over the admin account of a Chrome developer that has some sort of an extension. They can replace the entire code with malware and you know nothing will trigger any kind of alert. It will just push all the code into the browser and no one will pay attention into it and nothing will trigger some sort of a a an alert because it's the same ID on the same browser and no security tool really cares. And that's the last piece of it which is a bit abstract. But when you look at the permissions that browser extensions have, they're actually really really excessive. And some people ask, "Holy

why is Google allowing all this data for extensions that are deployed in a consumer environment like on the Chrome store? Why aren't they changing them? For example, cookie permission to raise a cookie permission. Why is that possible? Like who really needs that? It doesn't make sense to allow the consumer tool." This is really something which is not trivial. uh Chrome, Edge, Firefox, all the rest. They use extensions, but you don't see them. They use extensions that are embedded into the browser to do some things. Why? Because let's say that you run an operating system, you won't write all the code into the kernel that will break things and people will cry. You'll probably write an executable or a

DL. So that's exactly the equivalent. So even though you don't see extensions in the browser, there are some extensions over there that are made by Chrome to run on Chrome and they will come at the form of for example the sidebar of Copilot within uh Edge or some sort of functionality within Chrome and now with all the AI browsers will see that as well. So it means that Google, Microsoft, Firefox and others are dependent on the same permissions and this is why over time we actually see an increase of the amount of data being visible to extensions rather than a decrease. For example, now we have a new permission prompt API. Prompt API will allow any extension to ask questions

about an embedded AI running in the browser about who knows what like the devil knows what. Uh how is the user typically behaving? Uh is this password the real password of the user or not. Now I got an R&D team re researching what can we do with that. I'm pretty confident now in not as a nice hotel but somewhere else. There are bad guys asking themselves, "What can we do to improve ourselves using the same permission?" So, you get the point. The same way EDRs and malware typically run similarly. We won't talk about all those other crazy stuff. If you're interested, I'll leave this QR code for 5 seconds. You can also find this online. You can take

pictures, whatever about all kinds of attack patterns with malicious extensions. Uh, today we'll only talk about that in the context of passwords. So I'll be invited again to bides for not creating false advertisement about this talk. All right. So extensions in environments um pretty much everywhere and there are a couple of reasons to why extensions are existent everywhere. Uh so the stats here show about the the frequency of having extensions in enterprises. Very few organizations don't allow extensions at all. And we're talking about organizations like Bank of America, very very archaic even though it's a great organization. Why can't organizations prevent users from deploying extensions? A one, political or culture. Some users are expecting to

have that. B uh password managers, productivity tools. Uh C, AI extensions. Four, sorry, number D, and that's the most insignificant ones. Web developers love extensions and they use them to test everything and they download them from GitHub and they don't even check what it is. It's pretty much like eating trash from the floor. They don't ask themselves what is that really doing. They deployed it on their own browsers to test and emulate web applications they develop. And no one no one no one will ever tell a web developer not to try an application because before it's being released to the public. Now any kind of approach that's possible with tools on the endpoint like an MDM edr

etc etc don't know how to digest this. It's basically something that was downloaded from GitHub without any ID, no reputation, no data about this code, constantly changing, doing all kinds of shady stuff. Uh, and even if you do a a find an ability to scan them or sandbox them, it's really hard to apply a policy that says allow these extensions only for developers. You need to have some sort of a very robust mechanism. They don't exist in all organizations because those web developers will have four, five different browsers. In three weeks they will have like eight different browsers with all those fancy AI browsers as well. And that means that for IT security teams it will be some

sort of a cat-and- mouse game that they already give up on from day one. So they don't do anything about that. We know some organizations do but it's not really happening. All right. So we're scared about the fact it's there. Let's be scared about what kind of data they have access to. Uh 53% of all enterprise users have an extension with a high or critical ever permission. a increment a dead compromise in which attackers took over the admin account of Cyber Haven the best DP vendor in the world but don't have a very robust Chrome enterprise uh admin consoles they replaced several extensions about 40 with malware we checked our customers about 90% had one of them it's really

really easy to get extensions to the general audience and then it doesn't really matter if you have you know one three four five a single extension can dump at once all your cookies is uh jackpot. It doesn't really matter. You don't have to have some sort of a user involvement. 11% of users have an extension with cookie permission. So that means that one of nine users is vulnerable to complete identity theft. And 15% of enterprise extensions of Chrome web store extensions have a scripting permission. That means that really easily they can get to passwords. Now there are all kinds of ways to get to passwords. With scripting, you can do things such as if you have a password

manager, you go to a password field. It says, "Do you want me to pick up a password for you?" Like, it's really, really excited. Basically, it's just listening and waiting for you to do something on that field of a password. The same very, very basic logic can happen with the malicious extension, except it doesn't let you know it's there. Now, who develops these extensions? Putting aside all extensions that are not coming from the Chrome Web Store, that's web developers, huge problem. Assuming that users download those extensions from a trustworthy uh source such as the Chrome web store, we assume that someone checked that uh we know that those checks are not very very robust. A part of that is that it

doesn't necessarily means that the extension is malicious per se. It can also be something you just don't want to have in your environment and supply chain something that could be compromised or abused or being neglected. And there are all kinds of extensions in the Chrome store that no one is using for a couple of years. In [clears throat] theory, I can write I can buy a domain uh that is associated with this extension. It's already expired and then just create the email address that's being granted to the adm account. I can do all kinds of things. It's really easy. Now, at some point in time, I instructed one of my analysts. I told her, "Open a proton mail. in that

proton mail reach out to extension owners with a 100,000 installs and above and say that you would like to buy anonymous leader extension and ask for a price listing and basically what I instructed her to do is like behave like a drug lord when you communicating with them to see what are the ethical barriers that they have and apparently like you know out of 30 a good side like a handful of them said I'm open to negotiate like they didn't have any problem and extensions with hundreds of thousands of downloads are not that common So something with thousands or you know 10 thousands is easy to find. Uh from an attacker standpoint by the way it's really easy to find out if

they're deployed in enterprise environments or not because they get some sort of a flag coming from the extension about the device in which it's being installed. So if I buy an extension off the shelf that already got installs, I can create a report that says where is that existent you know uh and then probably you know 60% is individuals and then 40 you know 30% is mom and pop shops and then 10% will be enterprise users and that's where the real money is. So over half of extensions are identified with a free Gmail account which is also a big security problem. For example, some security vendors uh associate their extension with a a Gmail account that is

not behind any security. Um 89% of extensions have fewer than thousand installs. So they're really hard to evaluate in terms of permission and 79% of extensions have a single extension for per publisher. So just imagine what it takes to apply some sort of a reputation service on that. So why are they such an ineffective attack factor? They're everywhere. They're harmless, like allegedly harmless. They never say what they do, but they get access to data that you don't want them to get access to and it's really hard to control that and they are invisible to existing toolings because existing solutions only see the ID and as we said that is not very effective. Now comes the question, how

do I get to have a malicious extension? I need to uh to get a compromised extension. So I can a develop one from the bottom up. Just create a malicious extension, sneak it into the Chrome store, some sort of like a shashank redemption. I add a little bit of malicious code a day. Eventually it will become malicious and some guy a poor guy in Bangladesh that checks the code will not be able to you know to understand what I'm doing over time because it's so dynamic and it's really hard like it's happening all the time. I can just, you know, compromise a legit extension like happened to Cyber Haven, which what I consider to be the prettiest attack of

2024, or just buy something uh on the dark web. Lastly, I can also silo an extension by malware. So, that's kind of like a disappearing attack vector, but there are all kinds of ways for uh malware to deploy extensions. We see some sort of a shift from extensions being used to compromise the device. Now things on the device are useless. Not entirely useless, but the email is more valuable. So you'll see an ext a malware being deployed locally to elevate permissions into the browser. And eventually this is why we see extensions all over the news. And like most people don't don't understand how powerful it is. Actually, it has better data access than a malware. Well, enough talking

about extensions. Now we'll talk a little bit about how extensions can get access to passwords. So we talked about different kinds of permissions. We won't cover all of them but extensions have all kinds of permissions that can be used in all kinds of ways to get access to passwords. Now in my imagination there is the attacker and there is the defender. The attacker wants to simplify his life. The defender wants to simplify his life and then every time they try to pick like less and less obvious permissions to try and do the same work in a different way exactly like malware. So on the most basic stuff, cookie permission, which is pretty much game over because then I can

with one line of code dump all the of the user cookies and uh get access to an application. You can fetch data about identities of the browser itself, password storage, a client certificates. We can see all kinds of things. It can have full access to text inputs, clipboard data, a browser metadata would will catch u o ooth and sample certificate. So everything that goes in the URI will be will be visible to an extension and all the content of a web page. Now I want to give you an example. We've done a research uh a year and a half ago about cookie theft for entra. So how to use an malicious extension to uh compromise entra identities. And

basically our PC was an extension that steals the cookie of Entra including the browser uh user agent and you know screen resolution which typically is enough to get in and then two days before the conference uh it stopped working and added some sort of a security mechanism. I'll let you guess what was the security mechanism. It was adding another factor something they hide in they hide somewhere in order to check if that's a real browser. Now at at that point in time there is some sort of a logical paradox. They want to hide another factor because they don't trust the cookie. Where can they hide something inside the browser? So they hide they hidden another factor inside the browser

cache. The cache is also something that's visible to the extension. So our researcher all that he had to do is to reauthenticate with Azure uh with Entra on one browser see exactly what's being generated. added one line of code to his malicious extension on the PC and then eventually being able to still get in. So it it took us five minutes to fix that. And every time they try to improve something, they just uh hidden another factor inside the browser. So it's it's a it's a fundamental problem that they can't avoid placing secrets where the extension has visibility to to them. There is nowhere they can they can go and hide that we won't find them. And

that's a big problem that existing controls do not provide. It's a fundamental problem. By the way, there is a solution not using SAS. It's a possible solution, but it's not people here are not here to talk about how to go backwards in time. Um, and here you have a list of, you know, key permissions that can be used in what way, but eventually if you if you'll go and search for extensions out there. It can be something like, you know, uh, dark mode for Grammarly or whatever, it can be something that sounds like, you know, really really simple coupon code for Amazon and you check their permissions. It's kind of like, you know, reading the ingredients

of a of, you know, Advil or some sort of a medicine that you're taking or reading the, you know, the back page. It's horrific. So, those permissions are everywhere because they use them for kinds of, you know, all kinds of things that they do. By the way, sometimes the developers just say, let's pick all the all the permissions now. Uh, so if we need them, we won't have to reapply on the Chrome store for new permissions. So, they'll ask for everything and if they get approved, they'll just keep on using that. So, that's very very significant. uh so they can get access to cookies but there are all kinds of other permissions by the way all the

changes that Google made on manifest v3 it's a part of Google's strategy to fight uh ad blockers did not change whatsoever the ability to steal passwords you can relax now when we map that to TTPs uh it really aligns perfectly well so let's talk about you know cookie theft most organizations assume that cookie theft is being done on the device using malware that's a really really like that's a that's not the path of least resistance That's really really hard. You need to deploy malware and that malware needs to find something on the device. Chrome is like running away from that. But an extension like you one of every nine extensions can get there. Uh so that will be very

simple just you know stealing the cookie. The beautiful thing is that the same extension can also uh replicate everything else. For example, it can detect if a user is now on the application. So someone may apply some sort of an impossible travel. It can check uh browser configurations. So, if you ever seen uh a cookie a cookie sale uh like uh like on the dark web when they advertise advertisement for a cookie on the dark web, they typically put the cookie together with screen resolution and a few other things. All of them come as a package like it's a bundle. It's like the fries and drinks together with a hamburger. All of those are very useful.

But now let's use uh now a survey. What is the average price of a malicious attacker's extension on the dark web? What would be the cost on average of a stolen cookie on the dark web? Let's, you know, who wants to guess? Let's take five people. Wants to guess. What's the average price? >> 10 cents. >> 10 cents. Okay. No, it's not that free. That's a Come on. Say >> 50 USD. Okay. Five bucks. 50 USD. Who else? So, it's $10 in descending. So that's the only asset in the US which is inflation resistant and the price is going down over time because it's becoming easier and easier to get them. And what they learned in economy class

is that if it's becoming cheaper it means that the supply is becoming more uh prevalent. Then you have also other things that are a bit more complex about browser session hijacking which like there are million ways to do that but the best ways to do that would be from the browser. So when you think about it, the extension is there actually can open up the same session in another tab but minimize it on the side of the screen. Like there are a million things you can do whether that's compromising uh you know mimicking the sample data on the URI or just man in the middle in the traffic. You can do you can do like a

million things. It's like really easy. I think the main difference between cookie theft and browser session hijacked that with cookie theft you don't have to wait for the user to do stupid. you can just do it in one line of code once and with uh a web session hijack you need sorry you need to wait for some sort of a user interaction uh and that's the the big difference okay let's continue

I have here another resource which is a mapping extension threat to MITER attack framework if that's interesting you're welcome to uh take a a or scan a QR code. Eventually, it's mapping all kinds of attack factors from the browser to that. I'd say that it's trivial for frameworks about extension security to already be aware of that because at the moment the number one payload of malicious extensions is stealing identities. In the future, maybe something else. Okay, so now the question is what can we do about that and how can we be more secure? So we have a couple of possible strategies and we'll evaluate them one by one. The first one which is the number one

existing strategy is an allow list and that means prevent installation if the ID of an extension is not in the allow list. So you remember we only know if there is an ID or not nothing else uh besides the ID nothing else is like nothing else matters. It means that there should be some sort of a manual or automated review. So a user needs to ask uh for approval to install an extension that needs to get to security somehow. Typically this problem scales at the size of organization because the distance between security and the end user is becoming more significant and then they can still be hit by a compromise or weaponized extension. Uh so the case of the cyber raven reach

that's a great example. It's a security tool that already has the best permissions in the world being entirely abused to steal all the cookies of the user. So that's the best possible strategy but it's really really labor intensive and still not very secure. Then the next one is a block list. um scan periodically and add ids to a block list requires robust scanning routine of all approved browsers and great way to waste time and still be compromised. So basically running a block list on extensions is pretty much like boiling the ocean um or emptying the ocean like the amount of work is unfeasible and eventually it's still very temporary because an extension can change and

mutate. It's really happening all the time even for us as a security vendor that we install extensions for all kinds of demos. we had you know malicious extensions arriving to our environment. It's really really really common to happen in all kinds of ways. Then uh the third one is no extensions at all. Um and there are some organizations that can do that and for them the problem does not exist whatsoever. What we see in real life that that doesn't really apply to all organizations. But you know uh I also met once a CISO that said that they are not allowing users to consume internet. And by the way these guys don't need any kind of tool. It's always correct that

if you avoid using some sort of a technology, you avoid the problem entirely. I think a couple of years ago before AI, it was easier to do that in the US market. Nowadays, I don't meet so many organizations that do that and many of them actually prefer to uh spend a lot of time uh to to deal with that in a manual process rather than filing users. Then the the last piece of it is risk based security. What does that mean? um you need to first of all audit all the all the extensions on all the browsers periodically because every new version of each extension uh may introduce a new kind of code. So it

means that you need to find all the browsers. It's kind of like a really uh it's a you know some sort of a mixture between you know uh Squid Game to Pokemon. You need to catch them all but like three times all the browsers then all the extensions on all the browsers and then all the versions of all the extensions on all the browsers and have some sort of a mapping of those. Then you need to be able to classify them based on risk. Also understand context because context really really matters. No extension will say I'm malicious. Most of them will say at best I'm really poorly written. I am full of CVAs. Uh I'm like eating something from the

ground. None of them really shouts to the world I am malicious. Many of them are just a real supply chain risk. Not all of them are malicious but most of them are just bad uh by nature. And then having some sort of a risk adaptive security rules. Now the levels in which you can get go are really outstanding. For example, if you have a lot of time, you can actually edit the browser configuration file and shut down specific extensions, access to specific sites. If you really have a lot of time for free, you can take care of this take care of this problem by restricting specific extensions on specific sites. You can uh identify specific host names

and prevent them from running on specific browser. You can shut down syncing. You can do all kinds of things. But the levels of enforcement you can get uh manually are outstanding. And then you get to all kinds of mechanisms such as you know uh the pitfalls, how do you get all the browsers, how do you make sure that all of them provide the same level of visibility. For example, Chrome and Edge have a free enterprise version. If it's free and it's fully SAS, it's good thing to use. Uh but Firefox doesn't have that. Brave doesn't have that. Opera for example, Opera prevents uh anyone from viewing its registries. So not all browsers are born equal and we'll see

the same habit also now with AI browsers. Some browsers try to hide themselves from the IT. So Duck Go, uh tour browser, Opera, some of them are just nasty. Um then you don't have like the same coverage. Some of them are coming from a third party store. All kinds of pitfalls. Then the risk classification I talked about that the pol polymorphism of extensions is a real problem. And then the enforcement is where both organizations claim to fail. And the reason is that it's really really really hard to combine a routine periodic scanning for each update of the browser with the MDM. In many cases, organizations claim that the reason is that they can't do whatever they want on

the MDM uh to run this scanning all the time. Erh, how do we help the the community? At Lex, we've uh released a resource called extension pedia. Extension pedia is a a free resource for extension assessment. Where do we get the data? We have announced uh last week on a tech alliance with Google. So, Google is streamlining to us hundreds of thousands of extensions from the Chrome web store. And I intentionally say that because about half of malicious extensions are coming from outside of the store because it's easier to build it outside of the store. It's harder to get it to the destination, but it's easier to build it over there. So, we have a vast majority of the Chrome store

already scanned. You can submit an ID and get some sort of a report about risk also with different kinds of criteria about the risk. And in summary, we talked today about browser extensions are everywhere. The threat service is everyone. Uh I think the prettiest piece of it from an attacker standpoint, I don't have to wait for a user to do stupid. Uh it can affect everyone. The fact that developers install extensions more than anyone is is an outstanding thing because I actually got a powerful uh population inside the organization that has access to very valuable systems running extensions more than anyone else. Actually, it allows an attacker to get exactly to the target demographics that typically is the most uh elusive

and that really really it's really really appealing to attackers that you don't have to wait for them to make a mistake. they're already looking for these extensions on the on GitHub and they use them for all kinds of sources which makes this an awesome killer uh functionality. Uh excessive permissions are everywhere. Uh most of them have excessive permissions and uh and in a way human identity is browser security as long as the browser is the vessel of choice for applications to store all the credentials and all the cookies. By the way, when you sign into Slack or Teams or whatever, uh still they store their cookies and passwords inside the browser even though they're not in the browser.

So the tiny window they open for authentication is actually inheriting from either Chrome or Edge depending on what's your uh default browser. Um and there are all kinds of tools you already have that can be effective. It's really about balancing cost and manual work inside your organization. There are like a million ways to solve every kind of problem. Not all of them are right for your kind of organization. And that's it for now. I hope it was not too exhaustive, too, you know, boring. I hope you did learn something new today. And I I'll be happy to take questions if you have any. [applause]

>> Do you want to pick? >> Um, you can by random. I don't want to be biasing anyone. >> Let's start over here. Hi, thanks for the talk. Um, a couple times you mentioned screen resolution uh in conjunction with a browser session cookie. So I was curious if um the SAS application is using that as like a second factor of authentication to identify the user or is it just an additional data point and why is that important for the authentication process? >> So under UBA effectively there is you know it's it says I use what I have. So sorry for a bad analogy. When I'm hungry at night, I open the fridge. I'm using whatever is there. And if I have

leftovers of something, I'll use leftovers of something. What is the SAS application got? Because it's not an IDP problem. It's an application problem. Uh once the provisioning is ended, uh and the cookies being generated, you know, co octa is off. It's not a part of the process. So the application asks itself, okay, what do I what have I got? I got the screen resolution, user agent, IP range is super, you know, false positive. uh you know it's uh it's horrible usage to use that some cases you can use a geoloccation but it's only if the user is approving that so they're trying to think what have I got always screen resolution um OS version and

browser ID are the things that they have so from an attacker standpoint not to mimicking that which is typically you know 24 in and the most up-to-date Chrome of Firefox it's like the very basics of you know uh saying I care about my job I'm trying to do like a decent job it's not hard and that's a part of the complexity around that. So I'm using that you know it's any kind of data you can you have access to as a SAS developer. Now if you're a PayPal for example as a sample vendor you look at you know anomalies of you know mouse movement and key you know key stro strokes most applications don't do that

can they? probably I don't know how easy or expensive or cheap it is for them to do that effectively they don't

uh thanks for the talk that was great um you mentioned uh finding developers uh lol so um developers that need access to uh extensions to do to do development work. What what kind of um best practices that actually work in organizations do you see like is it segregating uh like enterprise activity from development or is it uh doing like you said doing like very manual kind of allow listing per site like what have you seen that actually works when it comes to this? So the answer is yes, yes and yes. And Google is now releasing a new framework. Now is I'm not responsible. I don't really know when is now. It's like near real time. It can be

any any time. But they're about to release a framework which is an ability to deploy browsers for testing specifically some sort of a papite or selenium uh that you can load extensions a very specific way that's supposed by design not to have a GUI. So the chances of you know you know uh making mistakes you know they're trying to make that the you know kitchen drawer will be very uncomfortable to store you know I don't know uh weapons or whatever. So you don't mix you know your work stuff with your personal stuff. Uh they're trying to make some sort of a UIX distin distinction so you developers will not do it on their own browsers. It will

minimize the problem but not solve it entirely. Okay we've got time for one more.

You may have mentioned it. I came in a little late so I apologize. How do you see manifest v3 versus v2 impacting the security of these extensions and the problems that you have seen? >> Um the changes are not that significant uh for a for an attacker. changes mostly affect the ability to control the user experience within the session. So, it's not a big deal. I would say that if you find some sort of an MV2 extension in your in your environment, those extensions cannot update anymore. Extensions do inherit third uh library third party libraries and actually all those CVS are being inherited by sites that are affected. So in a way it's kind of like you know opening another door to

the browser that you know browser exploits are something that people really are scared about. So it's just you know bad bad habits in terms of development to use that. That's what I'd say. Aside from that from an attacker standpoint there is no much of a difference because the some permissions were left and some were added. So all in all as an attacker I feel like my conditions are pretty much the same. But any other kind of attack factor has become more you know more complicated. So you know fishing is really hard harder, malware is harder. So I'm going always to the path of least resistance. And this is why I think we see more and

more attacks coming in the browser itself because not because it's became uh easier just because the alternatives became significantly harder. >> Okay. Thank you very much. >> Thank you very much everyone.