
Hi everyone. Thank you so much for joining me um especially after lunch. I appreciate the team effort. I hope you're going to enjoy the talk. Um so thank you so much for coming today. My talk is uh about it's called 000000 day how we exploit local networks through the browser. And I wanted to start with a question. What if I told you that all the websites that you visit can access your local network through the browser? And it's still possible today with all um public browsers. Sounds scary, right? Well, let's talk about it. So, first of all, I want to introduce myself. My name is Britt Franco. I'm a senior software engineer at Olgo Security. I love software
development and innovation and I always like connecting a vulnerability with the background story, understanding what made the vulnerability actually possible to be exploited and what are the concepts that were skipped on the way there. I also really love languages, uh, whether they're programming languages or human languages. And I'm currently working on my French, Spanish, and German. So, come say cuckoo, hola, or hello afterwards. I'd love that. So, today I'm going to bring you my team's research, and I can't talk about this without mentioning um my very own teammate, Avi Lummenski. Avi is an AI security researcher and he loves internetf facing uh products and AI and breaking AI. He unfortunately couldn't make it to this conference but he wrote
our blog post and he led the research that we were working on together. So we both work for Algo security um a cyber security startup that focuses on runtime uh detection and application in cloud infra and working for Algo we conduct these uh security researches to write blog posts and to discover how we can improve our product and we both come from a background in cyber security. Thank you Abby. So what are we going to be talking about today? Today we're going to be talking about how a bug and a disputed CVE resulted in remote code execution. But how are we going to do that? First of all, we're going to go back in time and talk about the bug
report that was the root cause of this problem. Then we're going to move on to talking about PNA, the solution that tried to solve this problem. Um, we're going to move on to 0000 day, the vulnerability that PNA overlooked. And I'm going to give you an example called shadow array, a real world world example. And we're going to finish with current browser state and a conclusion. So let's dive in. So once upon a time, there was a 19-year-old bug. I'm taking you back to 2006. I'm talking no https, the beginning of commercial commercial internet. It's the time we all had Windows Vista back home. This bug report appeared in 2006 on Bugzilla, Mosilla's bug tracking
system. It suggested to block access to local networks from the um from public websites running in the browser. But this bug report raised some questions. Is it a bug? Is it a feature? Is it a vulnerability? Let's find out. So the bug report listed um that the JavaScript code that runs in the browser can do numerous things. One of them is scan internal networks. The other is fingerprint devices um in your local networks and also run malicious commands. They suggested that Firefox prevent accessing internal URLs and networks from the browser. And I just want to remind us all that this blog post 2006 was way before Chrome was even released. So just so you understand how
long this bug report has been has existed. Later um the author al also stated that the bug is currently uh exploited out in the wild with an attack called driveby farming. It's an super interesting attack. We don't have really have time to get into that, but I recommend everyone to read a bit about it later. It's one of the first recorded attacks known uh through browsers, but someone later commented that this is not a Firefox specific problem, and it's technically not a bug, but a a requestment for a security enhancement. And I want to ask that uh person, what do you mean? Websites are currently attacking my home router. What type of security enhancement that is
that? Here kind of began the hot potato game. No browser really wanted to deal with solving this because there wasn't a standard that they all had to comply to. They were scared that they would implement and put money and time into implementing a security feature and then later a standard would come up and they would have to ruin all the code that they w that they wrote at that time. by saying this is not a Firefox specific problem. They tried to throw the hot potato at someone else. To this day, Misilla did not figure it out. They closed the bug, opened the bug, made it a bit more critical, but it's still open. That's what
matters. This brings me to the main problem that browsers have today. Lack of standardization. They don't have any standards. A few years passed by, we're still on the bit on the same bug report and someone commented they have seen Chrome started working on course to restrict cross origin access. Course was a step allowing domains to decide who can ask for their data resources was a big change at the time for browsers, but it focused on not sending the response back, meaning only after the request was sent and digested. and it still didn't prevent access to local and internal networks. That's where PNA, a private network access, will come in later, but I'll show you how we broke that
too. Later, Mozilla marked this as depending on PNA, meaning they're they wouldn't put more effort into implementing and closing this bug, waiting for someone else to implement this. One eternity later, this headline appears. Why is this website port scanning me? Who remembers this web this uh headline from hacker news? Okay. Um this headline appeared in uh on hacker news um in 2020 midcoavid. I'm sure you all were busy doing something else. That's why. Um and apparently apparently eBay, not some script kid, but a big company was caught scanning clients uh local ports. We don't really know why they did this at the time. It could have been for security reasons for fingerprinting uh to prevent fraud or they were using an
extension and the extension was doing this and they weren't really aware that it was doing it. Until today, we don't really know the reason, but at the time it made quite a huge uh noise. But how did they actually do it? They were using localhost or 127001 for the scanning. This is an address that saves for the device itself. Quite intrusive, right? This shouldn't happen. browsers shouldn't be able to access your local device um over the network. It's that simple, at least in our opinion. So, we don't really know why it happened and whose fault it is, but we do know this shouldn't be possible to do. And it really did spark a conversation and it led Chrome to start
working seriously on private network access. Well, if you didn't really understand what I said till now, this explains it best. Just like when you visit a website with a public domain, imagine you walk into a store and the store scans your entire contact list on your phone to understand who you live with and who you communicate on a daily basis. That shouldn't h happen either, right? Well, both the bug report on Mozilla's bug tracking system and the eBay case are connected and as I said, they inspire the PNA development. So let's move on to talking about PNA, private network access. From now on, I'm just going to be saying PNA to shorten it uh all and I hope everyone will
understand. So when I talk about networks, I talk I want to talk about three distinctive networks. Think of it like this. You are the local network and you live in your house, the private network. Your house has a bathroom, a living room, a bedroom, and any other rooms that you want. All are different private networks. Your house is connected to a street, the public network. The street connects your house to other houses, to a park, to a conference room, to whatever you want, to different places outside. So these are the three distinctive networks that we want to talk about. The public network meaning internet today as we know it. Everything with a public domain or a.com for an example. The
private network, the home or office network. It's kind of the entity that represents us in front of the world. And finally, the local device, meaning our phone or computer. It's used for services and programs that run on our device or for testing infrastructure, meaning developers use the local network a lot. So, private network access is a rule that says websites from the outside world can't automatically use stuff from my internal network. Before a website can use my printer or smart TV in my in my home, it has to ask permission for this. This keeps my stuff safe from strangers outside. Think of it like this. PNA is like a front desk in a building. Public
visitors from the outside websites need permission before entering more private rooms, my local device. So here things got a bit funky. what is actually defined as local. Here my team started thinking about how we can hack this young and um immature security concept. So here are four different ways to run a server on your machine. The first two ways are ways to to bind your server on all network interfaces on your computer. And the last two ways are running specifically on your local network. You'd think that running something on your computer would mean that it would be safe. But from now on, whenever I'm going to uh refer to localhost, I'm going to refer to the two uh lower
addresses 127001 and local host. But you may ask what is 0000? And from now on, so I won't repeat myself too much, I'll just say 00. So according to Wikipedia, the IPv4 address 00 can have multiple uses. You might already be thinking all the IPs on this host, all the network interfaces on this host or just simply local host. Well, one thing I can promise you is when something has multiple uses, it can be abused. And let's align on it. Well, 00 is this host on this machine in Unix machines. It's an abstract way to look at all of the network interfaces available on a host. It should never be used as a destination, but only as a
source or when a host is learning its IP. And you know how hackers love do not use. So, let's move on to talking about 0000 day. So when they started working on PNA, they complied a list of all the addresses that they don't want hackers or people from the outside to use. So more private domains are blocked when using PNA. This is the list they created. They added local host and 127001 host file records and IP addresses that are reserved for private networks. So if with PNA if you try to access one of these addresses it'll get blocked but remember the hot potato well they forgot to add 000000 so it's left out of PNA because 000000 was once used in
different initialization processes adding it to PNA made many websites crash. So with using this address 00 we can access local host and local networks and I just want to say that for a side note this is only possible in Linux and Mac OS meaning Unix machines because in Windows this isn't really an abstract way to access all of the network interfaces. So when we use 00 we can actually access local host and 127 and 001. Um and this is a unique attack vector. It doesn't come up with security scanners. It's not blocked in classic firewalls and it's easily exposes many of your secrets because it lets us lets the attacker connect to your local host.
So when PNA and Unix ignore 00, it's like a security guard forgets to check a door tagged do not use 00. Unwanted visitors still find the their way inside the building through this door. But what can we actually access with this address? Well, everything that is port forwarded uh everything HTTP that is port forwarded meaning a lot of developer um processes and tools, operating system services that run on local host uh or that are bound to 00 uh interfaces and internal network access. VPN sometimes is configured after binding to 00 and it could lead to DNS rebinding. But let's talk about a realworld example of how we use this vulnerability in my team. So shadow ray not from the browser
was a research that we did in our team before zero zero. We wanted to show that shadow ray is also possible among many other things used through 00. So here's what we actually did. Who here has ever heard of ray? Okay, one person. Um, thank you for the support. Ray is an open- source framework that makes it easy to scale AI applications from your computer to the cluster. It's used by many vendors as you can see on the slide, including OpenAI. And to quote OpenAI, they also use it to train chat GPT, meaning I think you all need to get up with your AI um learning. So 2023 was a big year for Ray. In late 2023, five unique
vulnerabilities were disclosed to the maintainers of Ray. Following the disclosure, four of them were promised to be fixed in the next version of Ray, but the fifth one remained disputed and we thought that the fifth one was the most important. It's part of the jobs API, meaning it's on by default, and it enables running any command that you want on the cluster. The vulnerability claims that Ray lacks authorization, therefore creating remote code execution by design. The fact that it's disputed means that it doesn't come up with security scans and not the user or the developer is even aware of this behavior. The maintainers claimed at the time that it was lack of authorization and it
remains running on a local network. Therefore, it's more of a feature than a bug. And as they said here, it is not intended for use outside of a strictly controlled network environment. So, you see where I'm going with this? Now, think about it for a second. There's a vulnerability. The report is public. The maintainers say it out loud. This is not a vulnerability and it's not a bug. It's more of a feature and it won't be fixed in future versions of Ray because it's essentially the purpose of Ray. It is the developer's responsibility from now on and we all know how that ends. And I want to just um talk about how attackers love and look for disputed
CVEes. It's everything they ever could dream of. Someone already did all the hard work for them. The report is outside and the maintainers promise to never fix it in next in future versions. They often let them uh have them um back door back doors inside the company. And as I said before, security scanners don't even alert for this behavior. Here you can see um the default deployment configuration of array dashboard out in the wild. As you can see, our favorite address 0000. With a lack of a firewall or a security um policy, it might expose Ray to the public internet. So, let's talk about the impact and what we could actually achieve from shadow ray. I just want to note that all the
following data that I'm going to show you um was achieved from internetf facing ray clusters that we found um out in the wild, meaning it was part of the first and initial research that we did. We didn't hack into anyone's local network. We're going to show that it's possible later. But the reason I'm showing you this is because I want to stress how attackers are looking for AI workloads and how they could easily access all of your um production environment just from that. So we could access AI production workloads meaning we could have access to models and uh data poisoning and tampering with data um with model training. We accessed uh production DB credentials and
passwords and also private SSH keys. We also could access uh open AI tokens, hugging face tokens, stripe and slack tokens and cloud environment access, meaning jackpot, we won. Some of the impacted machines were compromised for at least seven months and this was about a year and a half ago. Many of the machines included command history, making it much easier for attackers to understand if this is a useful machine that they want to actually investigate, but also happily made it easy for us to understand if attackers were there before. This is a ray dashboard that in the wild that we found and was exposed to the internet. And I don't know if you can see but uh not surprising some
attackers were there before us and they opened reverse shells using wget and NC both present inside the ray environment. So we proved that AI infrastructure is targeted and it could easily easily lead to all of your production environment. So I wish I could talk about this a bit more but you're more than welcome to also search about it a bit more uh on our blog uh shadow ray and I just want to talk about how the maintainers of ray said that this is possible only with um internetf facing ray clusters or with access to the actual ray machine itself. Meaning by the design the develop the developers that deployed these raid clusters made a mistake and this is on them but we want
to test it out and prove them wrong. As security researchers we know that at the end of the day the developers have the um responsibility for the code but real life and reality is much more complicated than that. So using 0000 we could attack a local network running Ray without direct internet access and this is how we did it. So this is the attack vector. The victim uses Ray on local host or a private network with port forwarding just like it's designed to. The victim later visits the attacker website or clicks a malicious link. JavaScript uh then invokes an HTTP post request to the Ray API by using 00 as target IP. As you can see here, this is a
simple and um honest email sent to one of our developers. Please click here if you can't see the email. Ray was recently updated. But unfortunately, the link leads to a malicious HTML. This is another visualization for the attack flow. The developer deploys Ray on a local network thinking it's safe from the outside world, but it app accidentally clicks or visits the attacker's website. The attacker then sends the malicious request with the target IP 000000. Um, so you're going to see a one-click um demo that results in a reverse shell on our victim's um rate cluster. We can see the developer on the local terminal. In the middle we can see the developer browser and on the left I think it's the
attacker's uh shell.
And a connection was formed
established and we can see a command was executed on the ray cluster resulting in a reverse shell. Thank [Applause] you. Yeah, pretty cool. Well, I know you're all scared and probably asking yourself, "Oh my god." Well, I just want to calm you all down. Yes, we did this in all three public browsers Safari Firefox and Chrome. I know. So, this is the exploitation in uh Safari, Firefox, and Chrome by order. um we can see it but as it's it's probably it's the same thing as I showed you before and 0000 day made quite a buzz at the time. It appeared at Forbes, Hacker News and different websites. So let's move on to talking about the current state of browsers
today. The lack of a finalized standard led to different implementation in different browsers. This means that every browser implements the HTTP request to internal networks in a different way. Let's start with Safari. Following a report, Apple made breaking changes to WebKit that blocks access to 0000. As you can see, the PR was merged. Applebased uh browsers used an open source software called WebKit. And as part of the change, they checked when a request was uh handled if the target IP is all zeros. If so, it blocks the request. So, I'm sorry to say that my team added a line of code to every HTTP request in the world. And this is a check that we did like
last week. We try to access 000000 over Safari and you can see the error that we got back. Not allowed to use restrict restricted network host. So Chromium was um an interesting case. So before they released a fix, Chrome wanted to understand how many websites were actually using this address. So they released a counter in one of their uh versions and they waited to see the results. Sounds legit so far, right? Um yes, this is their suggestion. And so based on the counters that they released, the use of 00 rose from 0.001 to 015 um% more than 10 times over the course of I think it's two years since they were added. We're talking about 100k
websites that communicate over zero zero. Well, I was interested in what's the status of the counter. So, I went back and I checked it last week and surprisingly there was a spike around August 2024. Can someone guess what happened during this time? Well, my team was invited to talk about this at Defcon August 2024. And yeah, believe it or not, attackers actually watch Defcon um talks. Who could have thought of that? So following the counter, Chromium said they're issuing a fix as part of PNA, but after breaking some old websites, they had to revert the change. They're currently working uh waiting on the fetch specification. Fetch is uh the way to do HTTP requests in
JavaScript to handle it properly. Remember the hot potato game? So, um, yeah, they're waiting on the fetch specification, but as I said before that, um, Apple based browsers use WebKit. So, if you're using a an iPhone or a MacBook, um, it doesn't matter if you're using Safari or Chromium, you're safe because they all have to use WebKit. and finishing with the Firefox, the browser that started it all. As of now, there's no immediate fix in Firefox, although a fix is in progress. Firefox at some point said that they're waiting for PNA. Then there said then they said they're waiting for fetch. And as you can see, the fetch PR is still open. Um, it's still open right now. I
checked it last week and I saw a list of a lot of uh angry users commenting. Um, so it's it's funny to just read the comments. So at an undetermined point in the future, 0000 will hopefully be blocked from access um in Firefox and will not depend on PNA implementation. So let's move on to talking about a conclusion. what you must be asking yourself well Brit what's the best practice what should I do from now first and biggest uh best practice is never trust local host just because it's local a good example for that is Jupyter notebook uh developers they implemented a default token um and they did a great job by doing so the second best practice is implement
PNA headers just like chorus kind of became a standard um in web development. Uh PNA headers as I um think would be part of our future and that would help protect and in shadow ray's case would have uh made our um exploitation not um accessed. Oh okay. um and also use HTTPS whenever possible. So what to expect from the future? Well, as I said before, hopefully PNA headers will be added to open source projects and I'm relying on you guys to start implementing my best practice in open source projects just like uh course headers are quite the standard. Hopefully 000000 will be blocked in all browsers in the future, but we don't really know when that's
going to happen and developers will become super secure after this talk. I'm just kidding. We all know that's not going to happen. Um especially with AI writing more and more code today, but that's just going to promise that's just giving me a job security and it's going to promise more and more interesting talks in the future. So I think that would be part of like a happy future in the end. Um and I just want to say that there are many other cases like shadow array and research is done. And just to finish with a tease, MCP uses HTTP and no off and we're currently um in the MCP buzz world. So if you want to check that out
and maybe write something, you're more than welcome. Go look at it. And you're also welcome to um read our blog post about this. Yeah, that's that's it. If anyone has questions,
are there any questions? Yes. Have you considered submitting CodeQL or SEM grip rules like the community side to like remind developers as they're coding implement the DNA headers? Honestly, no. I don't I don't have a good reason why not, but um I didn't like I didn't look into it too much, but I know that like we did this research as part of improving our product. So, we took the conclusions and we implemented them in our products. Yes. I was going to say, I know you talked about AI in this super early about AI, but I was just kind of curious. Um, are there things that you've like seen companies do with AI that kind of make you shake your head or
like kind of not necessarily done, but kind of mistakes companies have made in attempt like with AI implemented in software? Have you seen that or not? Really? I think the best example for that is just like shadow ray when um companies think that AI isn't very production code or isn't very connected to their production and responsibility for developers especially now that the divisions between developers and data scientists are still a bit uh far from each other. So that's like the most of our researches are focused on that. Um I think AI, you know, you could talk about vibe coding forever, but um yeah, that's mostly shadow ray and stuff like that exposed. Yes. Can you go into a bit more
detail on what how uh PNA pre-flight headers uh work? Yeah. Um so PNA headers are mostly part of the browser checking if it could send um if the domain allows access to local networks. So your code your local code has to send like a header like hey I allow other domains and public networks to access my code. So it's basically if the ray u maintainers would have developed it they would have like either said no or yes and instead they were just like no it's supposed to be part of a local network it's okay. Yes. What about blocking it? Um zero zero. Yeah. Well, as I said before, it's because it's um in what type of fire like in what
step window you know putting an inbound and outbound block on 0 because still there are like you could implement it as like your private case but it's not a suggestion because it's still an interface in Unix. In Windows, it's not a problem. Like this wouldn't be able to to be done in Windows, but because it's a difficult concept and like complic complex concept in Unix, it's still a bit problematic. So you could might do that in like a private case if you check that it's okay. But in ab in an abstract way, no. Okay. So if there are no more questions, thank you so much. Follow me on Twitter. Add me on LinkedIn. And thank you for coming to my
talk.