Substack Open URL Redirection / Reflected XSS Vulnerability Writeup
Tags: security, webdev, hacking, pentest
Published: 2020-04-04 02:36:27

This post was originally featured on my [blog](https://blog.aunyks.com/2020/3/substack-open-redirect-w-xss).
*NOTE: The content in this post is solely for educational purposes.*

The [Substack](https://substack.com/) team was kind enough to allow me to disclose this vulnerability. As stated by the title, I found an [Open URL Redirection](https://owasp.org/www-project-cheat-sheets/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet) vulnerability and a Reflected [Cross-Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss) vulnerability in the company's web application. If you want to learn more about the nature of these types of vulnerabilities and how they can relate in this case, [here's an article](https://dev.to/aunyks/how-d-i-get-here-exploiting-redirection-1aga) that explains it.

# Discovery
While setting up a newsletter for [LetterMatch](https://lettermatch.co/), I noticed that a visitor to a Substack newsletter's subscribe page will sometimes see a `next` URL query parameter that describes where they'll be redirected after subscribing. The URL would follow the form `lettermatch.substack.com/subscribe?next={target_endpoint}`, where `{target_endpoint}` is the location to which the visitor will be directed after subscribing. *Note that this applies to _any_ Substack newsletter, not just LetterMatch's.*

# Exploitation
Because redirection schemes that look like this are, at times, susceptible to Open URL Redirection, I tried visiting the URL `lettermatch.substack.com/subscribe?next=https://example.com` and subscribing. After doing so, I was redirected to example.com. Now that this case was validated, I tried finding methods of obscuring the destination URL. This is because a victim may notice the second, potentially malicious URL and choose not to visit the link. With that said, I tested [several different ways to encode an URL](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Open%20Redirect/Intruder/openredirects.txt) and saw that most of the variations worked in place of the plain `https://example.com`.

# Impact
Vulnerabilities of this type are typically used in a chain with others to exploit victims, but conceptually this can be used to redirect users to phishing sites or sites that exploit browsers to install malware on a victim's device, like when hackers [exploited an Open Redirection vulnerability in a U.S. Department of Health & Human Services web page to install malware on visitors' machines](https://www.bleepingcomputer.com/news/security/hhsgov-open-redirect-used-by-coronavirus-phishing-to-spread-malware/). A bit more detail [here](https://blog.aunyks.com/2020/2/howd-i-get-here.html#craft-the-attack).

# Increasing the Impact
Some Open Redirect vulns can also lead to [Cross Site Scripting (XSS) attacks](https://owasp.org/www-community/attacks/xss), most often Reflected XSS attacks, if the payload or, in this case, the destination URL is valid JavaScript.

Interestingly, injecting script tags as the parameter value didn't have an effect, but injecting JavaScript "URLs" of the form `javascript:{some-code-here}` as the parameter value results in the injected code being executed. An example of this can be found in the demo below, where I inject a window alert.

# Demo
[Here's a video demo](https://blog.aunyks.com/img/tech/substack-open-redir-poc.mp4) of the this vulnerability being exploited before the patch. I don't consider it a proof of concept, as I demonstrate the exploitation with a benign redirection location and injected code.

# In Conclusion
I raised this issue with medium severity because of the Reflected XSS that's involved. The Substack team was very considerate in finding time to fix this vulnerability so quickly. They're a relatively small team with a lot of responsibilities, so their diligence was appreciated, especially as we all adapt to the circumstances of current events.

Timeline
**Jan 28, 2020** - Initial email disclosing vulnerability details
**Jan 31, 2020** - Response from Substack and patch of XSS
**Mar 26, 2020** - Notification of full patch (Open Redirect and XSS)
**Mar 26, 2020** - Request to fully disclose findings
**Mar 30, 2020** - Permission to fully disclose findings granted