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!

On Zoom, the cookie _zm_csp_script_nonce was used on every single page as part of the CSP script-src field. The CSP was set within an HTML tag that wasn't being escaped. So, it was possible to escape the context of the string to add in our own HTML.

The badly reflected data was put into the CSP nonce field. The CSP nonce uses single quotes while the HTML uses double quotes. Additionally, the second nonce will be parsed. So, using a double quote within the first nonce, using a valid nonce after that then putting our HTML within this cookie gives us XSS on the page. Pretty neat!

Cookie tossing is a technique that abuses the domain flag on a cookie. By having XSS on any subdomain of Zoom, setting the _zm_csp_script_nonce now leads to XSS on the main page. After hunting on other subdomains, they found a post-based XSS to use with this.

How does the chain work to get XSS on the main page? This is how we get XSS on the main Zoom page.

1. Make a POST request to the vulnerable endpoint on the Zoom subdomain with the XSS payload.
2. Payload will set the cookie via cookie tossing with the long path trick.
3. Redirect the page to the Zoom main page.

To prove maximum impact, the authors decided to use some OAuth dirty dancing with XSS. Frankly, this is a little out of my league to write here but is interesting none-the-less. By using the XSS, they're able to abuse the Google login flow to get an OAuth token that was never processed.

For some stupid reason, the Zoom team rated this as a medium since they hadn't proved persistence - that was a mistake! The Zoom team wanted a password reset to demonstrate persistence. Instead, the authors decided to use the cookie aspect of the XSS to get persistence. As long as the cookie lives, the attacker will make access to their account.

Second, they realized that zoom.us has permissions for video and audio. Since the user had already approved this, the attacker could turn this on camera silently then send it to themselves. The aspect of the extra permissions was interesting and not something that I had considered before.

The final technique was a denial of service via abusing the WAF. By using the POST based XSS to set any cookie, an attacker could set this with an obvious XSS payload. By doing this, the WAF will reject all requests to Zoom until the cookies are cleared. I had never seen this before so something interesting to see.

A crazy string of bugs to cause serious havoc on Zoom. I personally really enjoyed this post with the diagrams and unique takes on exploit development. Great work!