6 ms·
Dave here, founder of ToDesktop. I've shared a write-up: https://www.todesktop.com/blog/posts/security-incident-at-todesktop https://www.todesktop.com/blog/post
by davej 2y ago
Dave here, founder of ToDesktop. I've shared a write-up: https://www.todesktop.com/blog/posts/security-incident-at-todesktop https://www.todesktop.com/blog/posts/security-incident-at-to...
This vulnerability was genuinely embarrassing, and I'm sorry we let it happen. After thorough internal and third-party audits, we've fundamentally restructured our security practices to ensure this scenario can't recur. Full details are covered in the linked write-up. Special thanks to Eva for responsibly reporting this.
- spudlyo 2y ago> cannot happen again. Hubris. Does not inspire confidence. > We resolved the vulnerability within 26 hours of its initial report, and additional security audits were completed by February 2025. After reading the vulnerability report, I am impressed at how quickly you guys jumped on the fix, so kudos. Did the security audit lead to any significant remediation work? If you weren't following PoLP, I wonder what else may have been overlooked?
- davej 2y agoFair point. Perhaps better phrased as "to ensure this scenario can't recur.". I'll edit my post. Yes, we re-architected our build container as part of remediation efforts, it was quite significant.
- deleted 2y ago[deleted]
- ddingus 2y agoThat was solid. Nice way to handle a direct personal judgement! Not your first rodeo. Another way is to avoid absolutes and ultimatums as aggressively as one should avoid personal judgements. Better phrased as: "we did our best to prevent this scenario from happening again. Fact is it just could happen! Nobody likes that reality, and overall when we think about all this stuff, networked computing is a sad state of affairs.. Best to just be 100 percent real about it all, if you ask me. At the very least people won't nail you on little things, which leaves you something you may trade on when a big thing happens. And yeah, this is unsolicited and worth exactly what you paid. Was just sharing where I ended up on these things in case it helps
- AzzyHN 2y agoYou're still doing better than many larger teams handling larger projects :D
- abhiaagarwal 2y agoBased on the claims on the blog, it feels reasonable to say that this "cannot" occur again.
- beardedwizard 2y agoBased on which claim? That 12 months from now they might accidentally discover a new bug just as serious?
- GavinMcG 2y agoIf you think someone is obviously wrong, it might be worth pausing for a second and considering where you might just be referring to different things. Here, you seem to understand “this” to mean “a serious bug.” Since it’s obvious that a serious bug could happen, it seems likely that the author meant “this” to mean “the kind of bug that led to the breach we’re presently discussing.”
- beardedwizard 2y agoI do not assume anyone is obviously wrong and prefer to ask questions. Most bugs exist in classes, and variants are something you typically consider when a bug results in a production incident. I'm not sure I read anything that makes me confident this class of bugs could never recur. I could be reasonably confident this _exact_ bug in this _exact_ scenario may not happen again, but that only makes me more concerned about variants that may have equal or more serious implications. So I'm wondering which claim did it for you? I only really saw pen test as a concrete action.
- TZubiri 2y ago[flagged]
- braiamp 2y agoThis is the wrong response, because that means that the learning would be lost. The security community didn't want that to happen when one of the CA's got a vulnerability, we do not want it to happen to other companies. We want companies to succeed and get better, being shameful doesn't help towards that. Learning the right lessons does, and resigning means that you are learning the wrong ones.
- TZubiri 2y agoI don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.
- otterley 2y agoUnder what theory of psychology are you operating? This is along the same lines as the theory that punishment is an effective deterrent of crime, which we know isn’t true from experience.
- slibhb 2y agoWhile I think that resigning is stupid here, asserting that "punishment doesn't deter crime" is just absurd. It does!
- AdieuToLogic 2y ago> While I think that resigning is stupid here, asserting that "punishment doesn't deter crime" is just absurd. It does! Punishment does not deter crime. The threat of punishment does to a degree. IOW, most people will be unaware of a person being sent to prison for years until and unless they have committed a similar offense. But everyone is aware of repercussions possible should they violate known criminal laws.
- edm0nd 2y agohow much of a bounty was paid to Eva for this finding?
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- richardboegli 2y ago> they were nice enough to compensate me for my efforts and were very nice in general. They were compensated, but doesn't elaborate.
- jsheard 2y agoSounds like it was handled better than the authors last article where the Arc browser company initially didn't offer any bounty for a similar RCE, then awarded a paltry $2k after getting roasted, and finally bumped it up to $20k after getting roasted even more.
- sphars 2y agoThey later updated their post, at the bottom: > for those wondering, in total i got 5k for this vuln, which i dont blame todesktop for because theyre a really small company
- oriettaxx 2y ago50.000$ additional to the first 5.000$ :) Woooowwww! See latest line: "update: cursor (one of the affected customers) is giving me 50k USD for my efforts."
- eviks 2y ago> for those wondering, in total i got 5k for this vuln
- hakaneskici 2y agoHow can -let's say- Cursor users be sure they were not compromised? > No malicious usage was detected Curious to hear about methods used if OK to share, something like STRIDE maybe?
- Centigonal 2y agofrom todesktop's report: > Completed a review of the logs. Confirming all identified activity was from the researcher (verified by IP Address and user agent).
- hakaneskici 2y agoWith privileged access, the attackers can tamper with the evidence for repudiation, so although I'd say "nothing in the logs" is acceptable, not everyone may. These two attack vectors are part of the STRIDE threat modeling approach.
- morgante 2y agoThey don’t elaborate on the logging details, but certainly must good systems don’t allow log tampering even for admins.
- deleted 2y ago[deleted]
- cdmyrm 2y agoHow confident are you that their log system is resilient, given the state of the rest of their software?
- MuteXR 2y agoFollowing that logic it would be literally impossible to trust any part of their infra. They had a bad build container, the rest of their stuff was solid.
- TZubiri 2y agoDon't worry man, it's way more embarassing for the people that downloaded your dep or any upstream tool. If they didn't pay you a cent, you have no liability here.
- remram 2y agoThis is not how the law works anywhere, thankfully.
- TZubiri 2y agoWell for one it was a gift so there is no valid contract right? There are no direct damages because there is nothing paid and nothing to refund. Wrt indirect damages, there's bound to be a disclaimer or two, at least at the app layer. IANAL, not legal advice
- notpushkin 2y agoI’d suppose there is an ALL CAPS NO WARRANTY clause as well, as is customary with freeware (and FOSS). ToDesktop is a paid product, though.
- remram 2y agoIf you give someone a bomb, or give someone a USB stick with a virus, or give someone a car with defective break, you are absolutely liable. Think about it.
- ImPostingOnHN 2y agoIf you give someone a USB stick with a virus, and you don't know about the virus, you aren't liable. Unless maybe you gave them some sort of warranty or guarantee that it was virus-free. The lesson: don't use USB sticks people give you, unless you have your own way of verifying that they're virus-free. Also, don't give people bombs. That's usually illegal, unlike giving someone software with unknown bugs in it.
- deleted 2y ago[deleted]
- nyolfen 2y agono offense man but this is totally inexcusable and there is zero chance i am ever touching anything made by y'all, ever
- cdmyrm 2y agoGood call. I'd seriously considering firing the developers responsible, too.
- throw339d00 2y agoThat's what a bad manager would do. The employee made a mistake and you just paid for them to learn about it. Why would you fire someone you just educated?
- sendintheclowns 2y ago[flagged]
- newAccount2025 2y agoIt’s not a matter of good or bad, but a choice among alternatives? Nobody gets fired: learning opportunity for next time, but little direct incentive to improve. Fire someone: accountability theater (who is really responsible), loss of knowledge. AFAIK, blameless postmortems and a focus on mechanisms to prevent repeats seems like the best we’ve come up with?
- deleted 2y ago[deleted]
- AlexCoventry 2y ago> We have reviewed logs and inspected app bundles. Were the logs independent of firebase? (Could someone exploiting this vulnerability have cleaned up after themselves in the logs?)
- beardedwizard 2y agoAnnual pen tests are great, but what are you doing to actually improve the engineering design process that failed to identify this gap? How can you possibly claim to be confident this won't happen again unless you myopically focus on this single bug, which itself is a symptom of a larger design problem. These kinds of "never happen again" statements never age well, and make no sense to even put forward. A more pragmatic response might look like: something similar can and probably will happen again, just like any other bugs. Here are the engineering standards we use ..., here is how they compare to our peers our size ..., here are our goals with it ..., here is how we know when to improve it...
- ec109685 2y agoWhat horrible form not contacting affected customers right away after performing the patch. Who knows what else was vulnerable in your infrastructure when you leaked .encrypted like that. It should have been on your customers to decide if they still wanted to use your services.
- cdmyrm 2y ago[flagged]
- BonusPlay 2y agoHonestly I don't get why people are hating this response so much. Life is complex and vulnerabilities happen. They quickly contacted the reporter (instead of sending email to spam) and deployed a fix. > we've fundamentally restructured our security practices to ensure this scenario can't recur People in this thread seem furious about this one and I don't really know why. Other than needing to unpack some "enterprise" language, I view this as "we fixed some shit and got tests to notify us if it happens again". To everyone saying "how can you be sure that it will NEVER happen", maybe because they removed all full-privileged admin tokens and are only using scoped tokens? This is a small misdirection, they aren't saying "vulnerabilities won't happen", but "exactly this one" won't. So Dave, good job to your team for handling the issue decently. Quick patches and public disclosure are also more than welcome. One tip I'd learn from this is to use less "enterprise" language in security topics (or people will eat you in the comments).
- davej 2y agoThank you. Point taken on enterprise language. I think we did a decent job of keeping it readable in our disclosure write-up but you’re 100% right, my comment above could have been written much more plainly. Our disclosure write-up: https://www.todesktop.com/blog/posts/security-incident-at-todesktop https://www.todesktop.com/blog/posts/security-incident-at-to...
- pinoy420 2y ago[dead]
- UltraSane 2y agoCritical private keys must be stored on HSMs or they will be compromised.