Full Report
Chatwork is a Japanese chat application similar to Slack. It is an Electron desktop app. While reviewing JavaSctipt files, they noticed the usage of shell.openExternal(). In Electron, this is a known bad sink that can open arbitrary URLs. Notably, passing in file:// with a user-controlled file can lead to code execution. This was available in the preload context, meaning that it was available before the disabling of the node API in the web browser portion. This isn't code execution yet, but it is a good start. Digging deeper into the code, they found an instance of BrowserWindow with webviewTag set to true. This is a deprecated feature that has dire security consequences when handled incorrectly. By providing arbitrary tags to the webviewTag, it's possible to disable security features in that processing window in a preload context. Again, we have a way to execute arbitrary code within a window but still need a way to add this code ourselves. The opening of the vulnerability code path was done via the function createNewWindow with a user-controlled but validated URL. In particular, a list of very specific patterns was used and verified to prevent adding the webview tag that the author wanted. Upon testing this service, they found that the usage and client-side validation were slightly different. The backend server URL decoded the request path but the Electron app did not. This means that we can use a directory traversal on the Chatwork app with something like https://www.chatwork.com/gateway/download_file.php%2F..%2F..%2F to circumvent the location of the call. Now, using the OAuth redirect, we can go to an arbitrary page! Here's the full flow of the attack: User clicks on a malicious link. The link uses a directory traversal and URL encoding to use a redirect from the OAuth page to an attacker controlled site to be rendered within Electron. The malicious site webview tag. This loads a file from an SMB share. The file from the SMB share will then exploit the openExternal to execute native code on the computer. Overall, a great chain of bugs! The progression and timing of each bug was interesting to me. Some folks go from JavaScript control yet others start from the bottom of the exploit chain. To me, it depends on where you see the impact. The ability to load a web page in the context of Electron is a good primitive but not a game-over bug by itself.
Analysis Summary
# Vulnerability: Remote Code Execution via Electron Feature Misconfiguration and Path Traversal
## CVE Details
- **CVE ID**: [CVE-2024-42491] (Note: Associated with JVN#78335885)
- **CVSS Score**: Not explicitly listed in text, but categorized as High/Critical due to RCE impact.
- **CWE**: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), CWE-749 (Exposed Dangerous Method or Function)
## Affected Systems
- **Products**: Chatwork Desktop Application (Electron-based)
- **Versions**: Versions prior to those patched in late 2024 (Specific patch version not detailed in article)
- **Configurations**: Desktop installations where the `webviewTag` is enabled and `shell.openExternal` is exposed to the preload context.
## Vulnerability Description
The vulnerability is a chain of three distinct security flaws:
1. **Exposed Dangerous Sink**: The `shell.openExternal` method was exposed to the preload context. This method can be abused to execute arbitrary files or protocols (like `file://`) if it receives untrusted input.
2. **Obsolete Electron Feature**: The application enabled `webviewTag: true` in a `BrowserWindow`. While `nodeIntegration` was disabled, a `webview` tag can be manipulated to execute scripts in a context where it can still communicate with the parent's IPC (Inter-Process Communication) and exploit the exposed `openExternal` sink.
3. **URL Parsing Discrepancy (Path Traversal)**: The desktop application's URL validator failed to account for URL encoding handled by the backend server. An attacker could use a traversal string like `download_file.php%2F..%2F..%2F` to bypass domain/path restrictions and force the Electron app to open an attacker-controlled site via an OAuth redirect.
## Exploitation
- **Status**: PoC available (demonstrated by researcher).
- **Complexity**: High (Requires chaining multiple primitives: traversal, redirect, and SMB-hosted payload).
- **Attack Vector**: Network (Triggered when a user clicks a malicious link).
## Impact
- **Confidentiality**: High (Full access to local files and system data).
- **Integrity**: High (Ability to execute native code and modify the system).
- **Availability**: High (Potential for system compromise or ransomware).
## Remediation
### Patches
- Users should update to the latest version of the Chatwork desktop application. The vendor has addressed the routing discrepancy and security configurations.
### Workarounds
- Disable the opening of untrusted links within the application.
- Block outgoing SMB traffic (Port 445) to prevent the loading of malicious remote scripts/executables via the `file://` scheme.
## Detection
- **Indicators of Compromise**:
- Network logs showing Chatwork accessing unusual external OAuth redirectors.
- Application logs containing URL-encoded path traversal characters (`%2F..%2F`).
- Unexpected child processes spawned by the Chatwork desktop process.
- **Detection Methods**: Monitor for calls to `ipcRenderer.invoke("skype-new-window", ...)` referencing `file://` protocols in Electron debug logs.
## References
- **Vendor Advisory**: hxxps[://]jvn[.]jp/en/jp/JVN78335885/
- **Research Article**: hxxps[://]flatt[.]tech/research/posts/escaping-electron-isolation-with-obsolete-feature/
- **Electron Security Guide**: hxxps[://]www[.]electronjs[.]org/docs/latest/tutorial/security#15-do-not-use-shellopenexternal-with-untrusted-content