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!

Mintlify is a b2b software as a service documentation platform that allows companies to make documentation via MDX files then host them with styling. Some of their clients include Discord, Twitter, and Vercel.

The MDX to render docs is provided by their customers. The author was curious on how the pages were rendered on the server-side for static page generation for search engines/bots. MDX is effectively JSX (react) combined with markdown. So, you can literally add js expressions in the markdown. So, they added a simple payload to just eval things on the server and it worked! After some work, they were able to extract all of the environment variables from a serverless environment. This attack could be used to enable mass XSS, defacement, and other issues. Yikes!

The route /_mintlify/static/[subdomain]/ is used to allow static images to be loaded. Surprisingly, websites will load from other domains! The author created an SVG containing an XSS payload and shared the link https://discord.com/_mintlify/static/evascoolcompany/xss.svg on Discord. This is XSS on everything now. This becomes particularly problematic because cookies are unlikely to be scoped per subdomain. Mintlify patched the targeted XSS via ensuring that it was an absolute path. This was vulnerable to a directory traversal though.

On top of these issues, they found an IDOR that exposed GitHub repo fields for private repos to the GitHub API. Additionally, the previously deployed versions on Vercel were accessible via direct branch references. So, the exploit could be run on here still. After all of this effort, they were rewarded with 5K from Mintlify.

There was another hacker involved with this: MDL. Instead of just popping an alert via XSS, they wanted to create MORE impact on the specific platforms. Some companies treat third-party vendors as untrusted input, and some grant them admin access to everything. So, they wanted to test the XSS from above to take this further.

Some companies had an extensive CORS policy that whitelisted all *.company.com. In this case, it's possible to send requests on the user's behalf on the website. This was made even worse by companies that scoped the authentication cookies to the entire domain namespace. Finally, most companies didn't bother configuring CSP's because it's just documentation.

In the other camp was explicit distrust. The best defense was explicit domain separation. Some companies didn't scope cookies to the entire domain, limiting the impact too. They planned to disclose on their websites, based on the findings, who was vulnerable and who paid out. However, after getting approval, they got blasted by lawyers with threatening letters, so they decided to anonymize it.

I have always found bugs in third-party components being reported to bug bounty programs to be hit or miss on payouts. On one hand, the goal of a bug bounty program is to find anything that can negatively affect customers. On the otherhand, the company did nothing wrong and is being punished for a bug in somebody else's code. If we go on impact and impact alone, it makes sense to pay out. Otherwise, no research would be done into smaller products/open source things.