04 - Breaking Modern Electron Apps: Exploitation Patterns & Defensive Lessons

Hello everyone, good morning. Today we will be talking about breaking modern electron apps. The ways they get exploited and what you can do about it. Quick bit about me. My name is Najmul Saqib and I am founder at X-Filter. Other than that, I love doing security research and contributing to open source projects. In open source projects, I have been primarily contributing to Zap, which is a dash scanner. If any one of you work in offensive security or application security side, you probably know Zap. It is an open source dash scanner. Other than that, this project itself is an example of open source contribution. It is freely available on GitHub for you to use and contribute to.

If you have any question regarding this tool or my work, you can reach me out on these channels. LinkedIn, Signal, and via email. And yeah, fun fact about myself. I flew about 11,000 km to be here today and that's for two reasons. I love giving back to the community because community is helping us learn so much about cyber security. So I love giving back in form of articles, in form of open source contributions, and talks like these. And second, I just love Canada. I keep coming back here. I was in Vancouver 2 years back to deliver a talk on a different conference. This year I'm here for besides and sector. So, let's let's get started.

Okay, quick show of hands. Please raise your hand. Thank you. Please raise your hand if you have used an electron app in last 24 hours. GitHub Yeah, that's my point. That's the point. Electron is very common and it is used to build most of the desktop apps, modern desktop apps that we have today, Obsidian, Postman, Slack, you name it. These There are tons of Electron apps out there in the world, and even if you um don't know whether or not you use an Electron app, it's pretty invisible. You need to just go on Google and see if the desktop app that you are using is built on Electron or not. It most probably will be uh because this is the most

common desktop application framework these days. Hence, it is very important for us to learn about Electron security because it is a prevalent desktop application framework. Uh so, we need to learn about the Electron attack surface and how we can secure our Electron apps. So, let's talk a little bit about Electron attack surface. Um if you know Electron, so this is Electron is just primarily uh web renderer uh that gets joined with OS APIs. So, what happens in a web application is that we have a very sandboxed environment. If you find an XSS bug, then the implications of it are very limited and are limited to the application itself. But, that's not the case with Electron.

In Electron, if if there is a bug in your application that can ultimately lead to an OS-side compromise as well. So, that raises the severity of vulnerabilities in an Electron environment. When Electron came out like in I think it was back in 2017 or 2018, uh it was insecure to a great extent. And uh there was if there if there was a single bug in your renderer, it can reach the underlying operating system. But, then uh Electron security team worked very hard and introduced um security defaults like node integration, context isolation, sandbox, etc. So, now if you create an Electron application, it has all these flags enabled by default. Um but the uncomfortable truth here is

that uh and people don't know much about it. They think that, "Hey, if we have all the security defaults enabled, then our application is secure." Uh but if all the security defaults are enabled, still your application get can get exploited. Still you can exploit the Electron application. And this is the premise uh this talk is built around and the tool that I will show you later. Um Electron apps can get exploited even with all the security defaults uh enabled, and that's through the insecure preload design or insecure context bridge implementation. Protocol handling comes in the way as well, and that all happens here at this preload context bridge uh gate. This is where unsafe implementation can get the application

uh compromised or exploited as far as Electron goes. So, what is DVWA? As the name suggests, it is a damn vulnerable Electron app. So, when I started learning about security in 2021-22, uh if you are if you are trying to get into application security or offensive security, you most probably start with web application security. So, back then there were OWASP Juice Shop, there was a damn vulnerable web application, and similarly for mobiles, there are damn vulnerable mobile apps as well. So, for AD, for cloud, for GraphQL, or whatever, you get a damn vulnerable app where you can learn by hands-on practice. And but when I moved towards Electron security, I found this a huge gap there that there

was no lab existing There was no existing lab that taught you about electron security. So, I myself, and I'm sure many of you also learn by doing something hands-on and not just uh reading the write-ups. There were write-ups for electron, but no hands-on labs. And uh to fill this gap, I I made damn vulnerable electron app. Uh it has multiple modules. I'll show that later. Uh but the best part about damn vulnerable electron app is that you can't just, you know, uh learn about exploitation in it. You can You will have the source code with you. That will be running on your machine. You can first exploit a vulnerability and then move to the source code, learn why is it

insecure, fix it, write a secure version, and then rerun the application to, you know, have a secured counterpart and try breaking it. So, you are uh learning about exploitation as well as securing the electron apps at the same time. Yep so demo time. Thank you. So, this is the damn vulnerable electron app. On the left side, you see um the main window where you have a bunch of vulnerabilities listed. Um and you can sort these vulnerabilities by the severity as well. Um we have deep link hijacking, insecure file write, and a huge list of vulnerabilities. On the right side is something special that not many uh vulnerable applications in- corporate. This is the observability panel. And in this, we have config

inspector. In electron, each window has some configurations. So, um you have as I mentioned earlier, the node integration flag, the context isolation, sandbox, blah blah blah. All these configurations uh are attached to a specific electron window. So, in this config inspector, this gets updated real time. So, you can't just take my word for hey, this vulnerability is hardened and these are the flags. You can just look at the config inspector and validate the the configuration applied to a specific electron module or the electron vulnerability here. We have uh more information here as well like this um CSPs, the version of electron, Chrome, etc. And um yeah, this is pretty much it. The config inspector, uh you can see the active

window gets updated here if I click on the other window. So, this is being updated in real-time as you play around in the application. As you open new windows, you will see this getting populated. Beneath it, we have IPC monitor. And those of you you who have worked with electron apps know that uh between the renderer process and the main window, the communication happens using IPC messages within electron. So, these IPC messages appear here in Sorry. Appear here in runtime as well. Like here you we can see R towards M, which means a renderer sent the message to the main window using the on method and here's the message. So, you will be playing around around the modules and

seeing this getting populated. Let me show you a quick demo of it. If I open this insecure file write vulnerability, you can see here the communication flowing around between the modules and between the windows. So, I'll start off uh with XSS vulnerability because that's the most common one we have and um it's quick to show as well. So, I'll start off with uh XSS vulnerability. If we open what can XSS do in electron, then XSS as I mentioned earlier, electron is a web renderer combined with OS. So, XSS implications are very different to what they are in a web application. So, first you can learn here that what you can do with an XSS in Electron. I am not

teaching what is XSS, how you can exploit it. I'm assuming that the user will know the basics of web security, and the user is here to learn about Electron security. So, here you will learn about what can XSS do in Electron, what are its implications, and then we will have three challenges here. Each vulnerability has different modules, different challenges, and each module has a set of tasks in it. So, I'll start off with challenge number one. So, a quick walk-through of it. You can see the flags mentioned here as well. Sandbox true, context isolation true, node integration false, and these are all hardened flags. So, this is a hardened Electron application. Um so, you can say, "Hey, this is a hardened

our application can't be exploited, can't be compromised." Let's see what we can do here. So, this this is the hardened challenge, as I mentioned uh earlier, and here we can see in this config inspector as well. It is getting updated in real time. We have these flags here, so you can validate in parallel. So, this challenge is obviously um vulnerable to XSS, and here we have this demo injection point, where you can add the payloads. Then we have the attacker view, because if you are stealing a token or something, then it will get um you know, visible here, what attacker is actually seeing from that payload. And then we have a set of tasks for each

module. Here we have uh task one, which is steal page data using XSS. So, if if you read through the docu- guideline here, so we have a session token exposed in the DOM. So, we will be using XSS to steal that token. Okay. So, I have pre-written these payloads because of obvious time constraint. Uh I can't really build these payloads in front of you. So, I'll just copy paste. Okay. So, you see uh this is the payload that fetches the token from the DOM. And here in the attacker view, you can see the token and this task is solved. So, this was a completely hardened window for XSS, except that there was an XSS vulnerability. Other

than that, we have all the security features enabled uh and still we were able to steal the information and, you know, get that to the attacker. But, in the beginning, I said that with an XSS or in Electron, you can communicate with the OS APIs. So, let's see if that's true. This is a hardened window, again. I'm repeating. I'll skip the other two tasks and uh that's for um you guys. Just play around and see how you can solve these. Task number four is trying to escape through this um vulnerab- this app and communicate with the underlying operating system. Let's see if that is possible.

Okay. So, this is a simple payload just requiring the child process and executing the ID command in it.

Okay. And here, you see task number four says that it is contained. We were not able to communicate with the underlying OS APIs using this um payload. So, you can say that hey, node integration was set to false and that stopped us from communicating with the under underlying OS APIs, but that that's not true. Let's see in the other under in the second challenge. So, the second challenge is about over-privileged context bridge. So, as I mentioned that render processes communicate with the main process using using context bridge. So, here in this case we have again node integration is set to false, but I will show you how you can communicate with the underlying OS APIs. Remember,

node integration is still set to false, but we will be able to communicate with the OS APIs and I'll I'll explain how.

Okay, so this is the task here. The only difference between the task one and the task two is that we have a privileged bridge here that is exposed to the render process. So, task one is just discovered the bridge because we have this context bridge exposed here. We first have to enumerate what is the privileged function here. So, for that we'll inject this command and we can see that we have a command runner here. I know this is pretty straightforward command runner. In real time in real world applications, this will be different, but for the sake of simplicity I have attached a command runner to the render process. We will try sending a command to this

command runner to validate.

And yep, we we ran an ID command and this is the output that attacker is viewing. We were able to solve the task two and we were able to communicate with the OS API and that too with the same node integration set to false configuration and that's the whole point with the preload context bridge insecure implementation. We'll just go forward and run this payload three that writes a file to our operating system and hence task three is solved as well. So, we have other challenges as well in this application regarding other entry points and we have a flagship challenge here as well which is stored HTML injection to IPC token exfiltration. I'll I'll come to that

later.

Next slide. Okay. So, I talked about XSS but this is not an XSS talk. This is about electron vulnerabilities. I chose XSS as I mentioned earlier because that is the simple vector that everyone knows about but they this is just one path into electron applications. There are many different other entry points into electron apps as well. We saw the renderer one where we had XSS to renderer escalation. In the preload context bridge, we have stored HTML injection as well that I'll talk about. In the main in the main process, we have insecure file write and that's a module in our application. Other than that, on the OS level we have deep link hijacking and open external

abuse vulnerabilities available and not only that, we have something that goes beyond the renderer processes which is update server. So, in insecurely handling or tackling the updates for electron app can get the electron app exploited or compromised as well. So, clearly XSS is not the one entry point. It is one of the many. Yeah. So, there were different bugs, but the lesson remains the same, uh which is hardened configuration. We have all the configurations, we have all the secure defaults enabled, but if the implementation is unsafe, uh then your application can get compromised. So, we'll see what are the three principles that we can take away from this talk today. Number one, config is the floor.

Configuration is the floor, not the ceiling. Configuration is the floor, not the ceiling. Um configuration is the baseline that you should do. I'm not against the configuration or the secure defaults in Electron. They are great. They contain the application to a great deal, but you just not should stop there. You have to implement the application securely. Yeah, and the second one is treat the renderer as hostile. Because a renderer is a process where you get uh input from external world. So, anything that is getting into the renderer, you should treat it as hostile and properly sanitize or properly validate it. Number three is trust nothing you didn't verify. So, not everything, as I mentioned, is coming from a renderer. Uh

there are insecure auto updates as well. There are external URLs coming into your application. So, just apply the zero trust principles to your application as simple as that, and you should be good. Okay, so the flagship challenge I talked about Going through all these modules, there is a flagship challenge at the end of this uh at the end of the list, which is CSP enforced. There's no XSS in it, nothing at all. All the security defaults are enabled on it. No command execution. Still, the application is exploitable. So, which is the stored HTML injection to IPC token exfiltration. Uh just give it a try. There's no JavaScript execution on the application at all, but still you

will be able to exploit the application and it's an open challenge. There is no public write-up for it. For other challenges, I have write-up in the GitHub repo, but for this there is no public write-up, so it's a challenge and you guys can give it a try, send me the write-up on this email address, and I'll try to publish the best one that I get. So, yeah. Here's the GitHub link and the QR code. I'm sorry for the mess-up regarding the slides. Clone it, break it, and just let me know how it goes, what you learn about Electron security, and contributions to open source projects are always welcome. Thank you.

>> Hi, just one quick question when you were mentioning a fully hardened Windows. What was the hardening standard that was used? >> Okay, so for hardening we have some flags that goes into the Electron apps like sandboxing so that the XSS attack can be contained into the renderer itself, node integration. So, as far as the hardening goes, I was particularly talking about the flags that security defaults or the Electron itself gives into the application configuration. >> Okay, thank you. >> Any other questions? >> Popular applications like Slack, for example. First of all, thank you for the talk. It was really good. Popular applications usually don't give you direct access to input HTML, JavaScript, stuff like that.

Does the the project in in general have a way to bypass that or maybe test it in in in other ways? And same question about seeing the IPC logs if it's possible for external apps. >> Okay, so if you talk about this big big applications like Slack, Teams, or whatever, if you decompile those apps, they are heavily obfuscated and it is very tough to you know come to a state to understand the IPC calls to the configuration. Currently, DVEA is not tackling the obfuscation part, but it is in my plan. Currently, it is teaching about the vulnerabilities, but yeah, you're right, the major applications are obfuscated and you have to reverse engineer it.

Anyone else?

>> Thank you very much. That was fascinating work.