Files stolen from a sneaky SymStealer.

Dave Bittner: Hello, everyone. And welcome to the CyberWire's "Research Saturday." I'm Dave Bittner. And this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Ron Masas: And this specific research was targeted to the Chromium browser, which is the open-source version of Chrome, which is also the foundation for many of the popular browsers that are used today. 

Dave Bittner: That's Ron Masas. He's a lead vulnerability researcher at Imperva. The research we're discussing today is titled "Google Chrome 'SymStealer' Vulnerability: How to Protect Your Files from Being Stolen." 

Ron Masas: And yeah, we just wanted to really map out all the ways that the browser can interact with the user file system and explore these mechanisms to better understand how they handle symbolic links. 

Dave Bittner: So at the root of the issue here, as you mentioned, is this notion of symlinks, symbolic links. Can you describe to us for folks who may not be familiar with that? What are we talking about here? 

Ron Masas: Sure. So a symbolic link is essentially a type of file that is a reference to another file or a directory. And they are usually used for bookmarks or shortcuts, but they could have very bad security consequences if they are not handled correctly. 

Dave Bittner: And so how is Chrome and Chromium set up to handle them? 

Ron Masas: So usually the right way to handle them is to ignore them. And when we looked at the Chromium and Chrome browser, they usually do just that. So if you ask any developer, like, what's the ways that you can interact with the user file system, there are typically three ways. So there is the HTML input, which is the - type=file, which is the most basic way to upload files from the user. We have the drop events. So this is where the user drop a file to the screen or folder. And we have the new JavaScript API, the File System Access API, which is just a new way to do it with JavaScript. And all those APIs handle symbolic links correctly, so they usually ignore them. 

Dave Bittner: And so what was the issue here? 

Ron Masas: So while I was testing this and I set up my testing environment so that I have all those integration working, I accidentally dropped a file onto the file - the HTML file input. So apparently, when you drop a file onto the HTML file input, there is a completely separate code that handles this case. And this - and this could - doesn't account for symlinks. And it actually recursively resolves them. 

Dave Bittner: Well, then let's walk through the implications of that. In your research here, you all lay out a possible attack scenario. Can you share that with us? 

Ron Masas: So we come up with a few attack scenarios. It's also, I think, important to note that there are other security mechanisms for when you upload files, a large amount of files. So for example, if you try to upload a folder that contains, let's say, a hundred files, the browser will typically show you a pop-up message saying, are you sure you want to upload this amount of files? So I just wanted to highlight that this file also bypasses all of those security mechanisms. 

Dave Bittner: Oh, interesting. 

Ron Masas: So back to the explanation of the attack scenario itself. The way it goes is like this - because we found a way to recursively resolve symbolic links, this means that if we get a user to upload to our website a folder that contains symbolic links - the symbolic links could be even inside of hidden folders - we will be able to access any file on the operating system. So the attack scenario was - we took the example of a crypto wallet generator. So if you ever created a crypto wallet, you typically get, like, a seed phrase. This is used to recover your wallet in case you lost your keys. And the way we wanted to explore this is by downloading a ZIP file that contains these recovery keys and asks the user to upload it back to prove that they have the recovery keys. And this sounds OK because you just downloaded these files from the internet, so what harm can be done by uploading them back, right? 

Dave Bittner: Right. 

Ron Masas: But if you do that, you actually upload the symbolic links that points to your private keys, your cloud credentials or other sensitive files. 

Dave Bittner: In this scenario, would you be linking to files that you presume are on the person's system? 

Ron Masas: Yeah. And because the symbolic link is getting resolved recursively, you can just link to a different directory. So you can do, like, dot, dot, slash and actually gain access to all the files that are before the downloads folder, for example. 

Dave Bittner: Wow. So you all reached out to Google about this, and they were responsive. 

Ron Masas: Yeah. So we reported the vulnerability to Google. We showed the proof of concept. We explained the issue, and they fixed it. 

Dave Bittner: But it did take a couple rounds to get it completely resolved. 

Ron Masas: Yeah. After the first fix, we took a look, and we noticed that, in some cases, if the symbolic link is not relative, then the issue is - can still be exploited. So we reported it back to them, and they handled that in the next version. 

Dave Bittner: You know, I think this research here really speaks to the fascinating reality that - it seems to me that in this case, you know, you were doing some work, and you just sort of stumbled across this. You accidentally triggered a behavior, unintentionally, that led you down this path. 

Ron Masas: Yeah, definitely. Like, it was - like, I think that in the end, we will get to it because we were also looking at the source code and trying to figure out what are all the ways that the browser interacts with the file system. But definitely just trying out the APIs helped to speed this process up and find this. But yeah. 

Dave Bittner: Was it surprising to you that that it was a different - there was different code behind dragging and dropping something rather than the other ways to access files? 

Ron Masas: Yeah, it was really surprising. But the Chromium source code is huge, and there is so many components and different things, so it makes sense that as they add more things, the code just accumulates, and it's opened up the possibility for such vulnerabilities. 

Dave Bittner: So what are your recommendations here for folks to best protect themselves? 

Ron Masas: Yeah. So I think the best recommendation is keep your system up to date. But also, if you look at this case specifically, I would say be wary of websites or people asking you to do things that you wouldn't normally do - so in this example, downloading something and uploading it back. Even if it sounds safe, you might be able to notice that there is something weird going on and should avoid it. 

Dave Bittner: That's Ron Masas from Imperva. The research is titled "Google Chrome 'SymStealer' Vulnerability: How to Protect Your Files from Being Stolen." We'll have a link in the show notes. 

Dave Bittner: The CyberWire "Research Saturday" podcast is a production of N2K Networks, proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. This episode was produced by Liz Irvin and senior producer Jennifer Eiben. Our mixer is Elliott Peltzman. Our executive editor is Peter Kilpe. And I'm Dave Bittner. Thanks for listening.