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!

Zoom became a sponsor of the Pwn2Own 2021 edition. From this, two vulnerabilities appeared that resulted in a Zero-Click exploit to compromise Zoom. This article is an analysis on two vulnerabilities and the exploit method, as from the perspective of the prestigious Project Zero research team.

First, Natalie thought about the attack surface of Zoom. People can join Zoom via different platform clients, a browser link, phone and many others. Additionally, audio, video, screenshare and many other inputs can be used as attack vectors. They wanted to see zero-click attack surfaces. From looking at the output of strings and IDA, they noticed that the server communication is done over XMPP via a library called Gloox.

To more deeply reverse the application, they hooked the SSL_write function with Frida. The output of this contains many XMPP messages and other network traffic. Even though this was helpful, she still had issues reversing it. So, her co-worker Ned noticed that very old versions of the Android application had symbols, which made it easier to reverse.

From there, she dove into the RTP (Real-time transport Protocol) and packet processing of Zoom. They fuzzed the RTP entrypoint on Linux to find a few bugs, locally. On the server, these bugs were not reproducible and she ran into many hurdles while trying to fuzz this. While learning more about the system, the author noticed that the library libssb_sdk.so did a fair amount of other traffic. They decided to focus on this functionality for a little bit.

While reviewing the disassembled code in IDA, they noticed some code smells. One length was being used to create the buffer (dynamically) and the other was being used to actually write the data into it. As a result, this resulted in a linear buffer overflow vulnerability. To test this out, they ran the code but hooked Frida to manipulate the data being sent to the function.

While looking around the same code, they noticed that all deserialized objects contain an optional type field called dyna_para_table_t. The implementation looked prone to type confusion bugs because of dynamic typing. For instance, the length specifies whether the data is an array or just the length. If the value is NOT 0, then it is assumed to be an array. Any time there is dynamic typing like this, the developers are asking for trouble!

They attempted to find bad type confusion bugs but the Zoom MMR client did rigorous type checks, making this impossible. They went down a path for integers, controlled by the user, being used as pointers, but could not find anything here either. Finally, they noticed that data, of type string, was not always validating if the string had a null terminator.

The idea is that a string type, without a null terminator (\0) being in the string, the string could be next to adjacent memory. When this would be interpreted, all the data after the copy would be considered part of the string, until a null byte was found. By using this technique on a Zoom user name, pointers could be returned from the user, resulting in a information disclosure.

Natalie attempted to exploit these two bugs but stopped because of time constraints. When attacking real world application with so many allocations and timing problems, it is hard to create a stable exploit and bypass all mitigations. The author notes that having more products be open source would have made this much easier to audit, instead of spending all of the time reverse engineering.

To me, this article shows the pains of security research and exploit development really well. All of the bad paths were month-long attempts, if not more. Sometimes, the task is too time consuming and not worth the effort so we move on. I appreciated the honesty in this post :) Overall, great article with good insights into the world of a security researcher.