Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

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:

1. User clicks on a malicious link.
2. 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.
3. The malicious site webview tag. This loads a file from an SMB share.
4. 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.