Lessons to be Learned from Software Deprecation: Electron.

Masq31 - Benjamin Giordano
6 min readDec 8, 2021

--

Season’s greetings everyone, this should be the last blog before Christmas rolls around, so hope you all have a good holiday season. For the month I’ve finished my initial plan for college and will be meeting with some esteemed folks in an effort to steer my learning experience in a proper direction. I’ve been doing work on metaverse-related projects in the meantime, which I find quite stimulating as a way to break pace with my security research.

Back on track, many of my meetings with the college have been proctored through Microsoft Teams. I’ve noted many issues in my last blog, and this will be a deeper continuation into a topic I’m sure a lot of well-versed developers and security researchers have dabbled in. The topic of the month will be Electron security, specifically the social responsibility around maintaining modern software.

Electron is a common web framework that’s utilized in many of the web’s top apps. These include a group I’ve researched on, but some not in that group, even including postman’s API tester. Development in electron is based in Node and chromium, meaning that developers can jump in with a slew of prior knowledge and start making apps. Unfortunately, Electron is a well-known sinking ship in the security community, similar to JWT. It failed to consider security in its inception, didn’t ‘shift left’, and was left with a whole lot of fixes needed as time went on. Red teamers developed documentation and research through the Electron Exploits project on GitHub. [1]

It’s also super easy and accessible to dive into, even for elementary school-level kids. With that, I think we have a good segway into one electron app that’s been suspiciously ignored: Moodle. Specifically, the Universal windows Platform (UWP) version of Moodle available on the Microsoft store. this app installs as most apps do, through Microsoft’s managed service account for consumers, and handled like most app tiles capable of running multi-platform. This means that these apps run on ARM based computers, and machines like Windows 10 with S mode enabled. Machines such as these often have configurations set up for something called “Microsoft store for business/education”[2]. This is NOT company portal with apps and downloads that the organization packages, these are apps picked by the company available to download from the Microsoft store.

Back to Moodle, when a user downloads the app, they’ll find themselves connecting to their school, configuring their settings and generally using the app. However, underneath the hood, you’ll find it’s quite different. One good thing is that the managed service account that Microsoft sets up is that Local level access restrictions work fine. Users trying to look at the files for Moodle or other UWP apps from the Microsoft store need admin access to get there. On the other hand, the issues inside of Moodle, which has control of the service account, make it easy to disable the settings and a whole lot more.

Curious and bored kids are crafty. I should know, in my middle school years I was studying Symantec’s malware database, learning about the Morris worm and benign and literally poetic viruses such as Elk Cloner for early Apple computers. The smart kids who see some parallels with google chrome might press ctrl+shift+c/i and find themself with the web debugger. Here is where the magic begins.

Moodle’s chrome interface is common for many other apps such as Microsoft Teams. Entering commands works like a typical development terminal with syntax for JavaScript included. At this point we start to see some ways electron can be misused. What’s also included is remote debugging capabilities [3]. A shortcut can be pinned to the desktop on any electron app with a well-documented launch command. From there, you can debug an electron app over a local (or possibly a remote) network.

The debugger is a GUI based, capable of changing URI sources as well. This leads to all sorts of fun interactions, such as launching web assembly DOOM in a Microsoft Teams window. While the possibility of snooping on some screens can be done with apps meant to keep students on track, keeping eyes away from the browser is something that many kids would be happy to hack around with. This can even be done in a popup with ‘window.open()’ if not handled correctly.

Why limit the browsing to websites? Why not plug in an IP address to see if the browser handling agent works too. Most apps have their own URI namespace for processing information that comes from chrome. Even Microsoft Teams will exhibit a window opening when clicking on a “ms-settings:” URI.

Beyond that, the console has a very easy way to identify what version of electron is running. Simply enter ‘process.version’. Thankfully, Microsoft Teams does not have this issue. However, the command ‘navigator.userAgent’ is typically not locked down and displays the version of the software, the electron tool, and other juicy details.

Scoping commands such as these is important. What’s more important is to know what’s running when the app is. ‘process.argv’, ‘process.env’ and ‘globalThis’ will show the maker all sorts of juicy developer information. In this territory we’re well beyond exploits brainy teenagers might pick up. From here, we find more ways to break defensive security features down.

Launching apps can be done from electron as well. Need a calculator? process spawn and require the calculator EXE. Of course, this can be mitigated, but needs to be handles across all apps and file types, not just a blacklist.

Finally, the most important thing to look for can be found in outdated versions of electron. I’ve noticed this in versions before 7.3, and have not figure out why yet, but Electron can certainly be pwned. The syntax is as follows:

```

const { remote } = require(‘electron’)

```

Basically, what this does is scope the electron package back into the production app. It’s mitigated by default in new versions of electron, but in older versions this is ripe for the picking. The reason that this means the app is completely pwned is because of access to the ‘app.’ commands. the “app” command is also called from “electron” as it’s the root software package and adjacent to the Node and system components. [4].

the only caveat to any of these exploits is the sandbox, which has known methods of bypass available. The command to modify the sandbox is ‘app.enableSandbox()’. Shell is often opened with shell.openExternal() and can lead to LFI reading and writing if not put into a null state [5].

Is Moodle aware of this. Well yes, in a way. Moodle announced formally that the product would be deprecated, that is development would cease for all but critical software updates [6]. Normally this would be fine if a suitable replacement was on the way. Moodle maintains a security disclosure program as well.[7] Unfortunately, due to the windows store replacement intending to be the android version from Microsoft not supporting anything but the amazon android app store, the amazon version of Moodle is now a work in progress according to their change management platform.[8]

The next question is: Who’s responsible for apps with this behavior still present. Moodle specifically was released as a UWP app in 2017. It’s now 2021, deprecated and with no replacement being made. However, not for the windows store, and not for the systems that are managed, running ARM or Win10S mode. If we follow the chain of how Electron apps are progressing into late 2021, we can see that Moodle has deprecated use, Microsoft plans to deprecate Teams in favor of a new technology [9], and the Microsoft store for Business and Education has a planned end of service date, leading to deprecation [10].

The social conflict falls into the category of technical debt [11]. Long term maintenance of windows software is the best example, with ongoing maintenance costs to patch software rising. I’d love to conclude on a decent solid answer for this blog, but for this we’ll have to say that more time and impacts will need to be considered. That leaves apps like Moodle UWP as a rickety bridge with the chance to fall over. One thing I understand is that if I see kids playing around the bridge on their way to school, I’d make a new one as soon as possible.

what I can advise is good best practices. Disable the store for education and business users if it’s not being used. If you don’t know how to set it up, don’t put it in. In a perfect world the vendor would have the time and resources to support apps like these, but with the issues at hand I feel it’s best to take heed as electron slowly, but surely, fizzles out. Thanks for reading folks. Stay safe.

Sources:

[1] https://github.com/doyensec/awesome-electronjs-hacking

[2] https://docs.microsoft.com/en-us/microsoft-store/apps-in-microsoft-store-for-business

[3] https://blog.chromium.org/2011/05/remote-debugging-with-chrome-developer.html

[4] https://www.electronjs.org/docs/latest/api/app

[5] https://www.electronjs.org/docs/latest/api/shell

[6] https://moodle.org/mod/forum/discuss.php?d=413350

[7] https://moodle.org/mod/page/view.php?id=8722

[8] https://tracker.moodle.org/browse/MOBILE-3517

[9] https://www.zdnet.com/article/microsoft-is-planning-to-phase-out-the-windows-10-store-for-business/

[10] https://techcommunity.microsoft.com/t5/microsoft-teams/teams-2-0-moves-away-from-electron-to-embrace-edge-webview2/m-p/2484565

[11] https://en.wikipedia.org/wiki/Technical_debt

--

--

Masq31 - Benjamin Giordano
Masq31 - Benjamin Giordano

Written by Masq31 - Benjamin Giordano

Web security blogger, Lifelong IT learner, Community first

No responses yet