Hacker News new | ask | show | jobs
by davej 482 days ago
Dave here, founder of ToDesktop. I've shared a write-up: 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.

10 comments

> 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?

Fair 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.

You're still doing better than many larger teams handling larger projects :D
That 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

Based on the claims on the blog, it feels reasonable to say that this "cannot" occur again.
Based on which claim? That 12 months from now they might accidentally discover a new bug just as serious?
If 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.”
I 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.

Honestly 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).

Thank 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-to...

> 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?)

How 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?

from todesktop's report:

> Completed a review of the logs. Confirming all identified activity was from the researcher (verified by IP Address and user agent).

With 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.
They don’t elaborate on the logging details, but certainly must good systems don’t allow log tampering even for admins.
How confident are you that their log system is resilient, given the state of the rest of their software?
Following 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.
Annual 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...

Critical private keys must be stored on HSMs or they will be compromised.
What 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.

how much of a bounty was paid to Eva for this finding?
> they were nice enough to compensate me for my efforts and were very nice in general.

They were compensated, but doesn't elaborate.

Sounds 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.
They 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

50.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."

> for those wondering, in total i got 5k for this vuln
thanks for the update. that wasnt stated when the blog post first dropped.
no offense man but this is totally inexcusable and there is zero chance i am ever touching anything made by y'all, ever
Good call. I'd seriously considering firing the developers responsible, too.
That'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?

Don'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.

This is not how the law works anywhere, thankfully.
Well 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

If 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.
If 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.

I’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.