Authors
Uriel Kosayev — @MalFuzzer, Hai Vaknin — @VakninHai, Tamir Yehuda — @Tamirye94, Matan Bahar — @Bl4ckShad3
Prologue
As red teamers, we are on a constant verge and quest to find new ideas and techniques to bypass defense systems and potentially gain initial access. In recent times where initial access and defense evasion have become more challenging relative to the past, new offensive techniques are needed also to provide better defense from potentially undiscovered attack vectors. This blog will show you how seeing a specific attack path in a GitHub commit led us to find Proxy Execution capability in a wide array of binaries, which could allow attackers to execute any binary, bypass defenses, and potentially even gain initial access as part of a weaponized malware in red team operations.
About Electron Framework and Chromium
The Electron framework is a popular open-source platform that enables developers to build cross-platform desktop applications using web technologies, Electron uses Chromium for rendering web pages, and it allows for the creation of desktop applications with native capabilities by combining the Chromium rendering engine, which powers Google Chrome, and the Node.js runtime. Chromium is an open-source project that serves as the foundation for various web browsers, including Google Chrome, Microsoft Edge, Opera, and many more. Chromium is also part of the code base of many other popular applications such as Discord, Visual Studio Code, Postman, and Notion.
Gain Insider Knowledge
Where did it all start?
This article dives into a significant milestone that has altered our perception of Electron’s security — the insightful Git commit by the keen-eyed security researcher mr.d0x.
In his commit to the widely recognized LoLBAS project, mr.d0x highlighted potential bypass security mechanisms, pointing specifically to the likes of Teams and MSEdge. After seeing his commit, we wondered why this attack works on both Teams and MSEdge and decided to dig a bit deeper into the root of it.
Finding the Common Ground
To discover similarities across various Electron-based compiled applications, we embarked on a study to identify recurrent patterns that might facilitate exploitation across diverse applications. We began with two applications that both support the command-line arguments — disable-gpu-sandbox and — gpu-launcher. Our initial approach was fairly straightforward: we checked for the existence of strings referencing the Electron framework within the binaries of msedge.exe and Teams.exe.
Then check references in the binary disassembled code:
Then it was interesting to validate that both the arguments of — disable-gpu-sandbox and — gpu-launcher are part of the Chromium Project with more than 250 other arguments as can be seen in the following screenshot:
Link reference to the Chromium content_switches.cc file: content/public/common/content_switches.cc — chromium/chromium — Git at Google (googlesource.com)
Furthermore, when we checked both the binaries of msedge.exe and Teams.exe using Detect-it-Easy, we found that they are both detected as executables that are using the Electron package as can be seen in the following screenshots:
Usage of the Electron framework in the msedge.exe binaryUsage of the Electron framework in the Teams.exe binary
We also found that the signature logic behind detecting the presence of the Electron frameworks in binaries is as follows:
If both the CPADinfo and .00cfg sections exist, it shows the presence of the Electron framework. It is also important to note that there is always a chance that this type of signature can raise an FP (False Positive) and will not be accurate, so it is important to take such situations into account.
To validate that both of those executables are compiled with both CPADinfo and .00cfg sections, we used the Total PE tool written by Pavel Yosifovich (@zodiacon):
Section name validation in the msedge.exe binary using Total PESection name validation in the Teams.exe binary using Total PE
After further investigation, we found additional arguments that allow code execution:
- chrome.exe — disable-gpu-sandbox — gpu-launcher=”calc.exe”
- chrome.exe — utility-cmd-prefix=”calc.exe”
- chrome.exe — no-sandbox — browser-subprocess-path=”C:\Windows\System32\calc.exe
- chrome.exe — no-sandbox — renderer-cmd-prefix=”calc.exe”
We then wondered if this attack path is also possible on other operating systems and found that it can be exploited on Windows, macOS, and Linux.
Proxy-Execution on Windows:
Proxy-Execution on macOS:
Proxy-Execution on Linux:
Also, we were curious about the scope of applications that are vulnerable to this vulnerability, so we asked using our friendly neighbor, ChatGPT:
We’ve devised a simple Python script that performs two distinct tasks. Firstly, the script checks for existing arguments within a previously referenced file. Secondly, it recursively enumerates all executables within a pristine Windows OS environment to identify potential Electron-based executables that may be vulnerable to exploitation.
Link o the full code: ElectronCutioner · GitHub
Those are the files that can be used for proxy execution on a fresh Windows machine:
- C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
- C:\Program Files (x86)\Microsoft\Edge\Application\114.0.1823.43\msedgewebview2.exe
Exploiting the Proxy-Execution Vulnerability
As the saying goes, one picture is worth thousands of words, so a PoC video is even more ?
But for those of you who like to get your hands dirty:
- On Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-gpu-sandbox --gpu-launcher="C:\Windows\system32\cmd.exe /c calc.exe- On macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-gpu-sandbox --gpu-launcher="/bin/bash -c whoami"- On Linux
google-chrome --utility-cmd-prefix="/bin/bash -c whoami"
$1408
$1128 or $113 X 10 payments
Windows Security Researcher
Provides the necessary knowledge, understanding, and tools to be a successful Windows OS researcher.
Detection
We reported this problem to Google and directly to the Electron framework team but sadly, they did not view this as an issue. We decided to create the following straightforward Sysmon rule to aid Incident Responders and Blue-Teamers in general in detecting such exploitation attempts:
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="include">
<Image condition="end with">.exe</Image>
<CommandLine condition="contains">--gpu-launcher</CommandLine>
<CommandLine condition="contains">--utility-cmd-prefix</CommandLine>
<CommandLine condition="contains">--browser-subprocess-path</CommandLine>
<CommandLine condition="contains">--renderer-cmd-prefix</CommandLine>
</ProcessCreate>
</RuleGroup>The following is an example of the generated alert from the above Sysmon rule configuration:
Detection Logic Suggestions
- Check that all the child processes in the execution chain are signed.
- Exclude needed and legitimate processes, each organization with its
