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.

The article begins with a hypothetical. You have a class Person with a field called age. What type should it be?

The first suggestion is a String. This is obviously wrong but why is it bad? It's bad because validation would need to be performed on any and every operation. An example would be the age Jeff. This could be done with "stringly-typed" data but is super annoying to do.

The next is an Int. It's easier to write, read and it fails fast. This is better than the String type. This is because we remove the capability for many invalid states! The purpose of the article that the invalid states are now unrepresentable.

There are still many invalid states with an Int though. For instance, -1 and 90210 are technically valid according to the program but invalid ages. The goal is to constrain the type to make these invalid states also unrepresentable.

In a statically-typed language, runtime assertions can be added. For instance, an assertion that throws an error if the age is less than 0 or greater than 150. This is an integer with constraints.

The next, and final, value they consider is using age type constraints. One problem with the current approach is that an integer used for an age is the same as an integer used for weight. So, having an explicit type for the age, as opposed to using integers, works well. They use the newtype pattern from Haskell to talk about this.