6 ms·

imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script gr

imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script grabs their cookie and credentials and sends it to the attacker. they now have full access to the victim's account.

rainonmoon 9mo ago
Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.
- hackermondev 9mo ago
  the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
  - rainonmoon 9mo ago
    And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
  - bangaladore 9mo ago
    Interesting. I agree with the other commenter about the post should've included how an account takeover was possible. You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast). > the auth token is stored in local storage Has anyone reported this (rhetorical question)? What in the world could be the justification for this? In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
- llmslave2 9mo ago
  XSS is a RCE exploit. It allows you to run any action as if you were the owner of the account. How is that not a full account takeover?
  - rainonmoon 9mo ago
    XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
    - rvnx 9mo ago
      Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
      - rainonmoon 9mo ago
        Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
        rvnx 9mo ago
        Yes, I agree, it’s a cool discovery though
        llmslave2 9mo ago
        Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.
deleted 9mo ago
[deleted]

rainonmoon 9mo ago

Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.

hackermondev 9mo ago
the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
- rainonmoon 9mo ago
  And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
- bangaladore 9mo ago
  Interesting. I agree with the other commenter about the post should've included how an account takeover was possible. You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast). > the auth token is stored in local storage Has anyone reported this (rhetorical question)? What in the world could be the justification for this? In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
llmslave2 9mo ago
XSS is a RCE exploit. It allows you to run any action as if you were the owner of the account. How is that not a full account takeover?
- rainonmoon 9mo ago
  XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
  - rvnx 9mo ago
    Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
    - rainonmoon 9mo ago
      Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
      - rvnx 9mo ago
        Yes, I agree, it’s a cool discovery though
      - llmslave2 9mo ago
        Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.

deleted 9mo ago

[deleted]