Stealing private keys from a secure file sharing service | Hacker News Reader

Stealing private keys from a secure file sharing service

timvisee.com

73 pointstimvisee21 comments

We're meant to give credit to a service that fixed an XSS vulnerability in an hour, and that is indeed a better-than-market turnaround time for an XSS bugfix.

But consider an alternative perspective: this is a company that was offering users "encrypted" file transfer mediated by clientside browser Javascript, in which there is only dubious, marginal cryptographic separation between customers and the service itself, which could just as easily serve targeted customers surreptitious DOM updates to override their claimed security capabilities.

But that fundamental problem didn't matter, because the service didn't even sanitize basic, obvious user data, and was exposed to a trivial XSS.

First thing I thought was "oh let them slide, when you think about big issues, you might slip on some sanitize code".

But then I thought, if you advertise something as "encrypted" and "secure" or more secure than competition, you should get at least basic pentest. It is not cheap to get one and a good one but that kind of XSS would be ruled out...

Aren't you professionally paid to fix these kinds of problems? You would be out of work if every developer and product manager put exhaustive pen testing on its to-do list prior to launch.

First to market is your bread and butter, tptacek.

(disclaimer: I'm one of the creators of this very unnamed service)

The XSS-issue that was found by Tim was indeed a very fundamental problem which shouldn't have been in there. We are very happy he disclosed the information with us so we could fix it directly.

We hired a couple of professional hackers to audit our service but launched simultaneously. Biggest lesson for us: finish the audit first, launch afterwards :-)

I'm going to give your tech team the benefit of the doubt that it would have responded to information quickly if it had that information.

Lessons learned here: pay your pen testers quickly because their findings can affect the reputation of your company, don't launch without responding to audit results, don't bullshit people working in high tech industries about what was happening simultaneously, don't blame tech staff for business decisions

It used to be; it isn't anymore. If you gave me the choice between giving up my company and ending browser Javascript cryptography, I'd have to think about it.

1 hour to fix the issue? You should give them some advertising. Hint: a phrase from the video is all you need.

He gave a pretty big hint on how to find the company.

"On the 24th of October, an article was posted on Tweakers (a Dutch tech website) showing off a newly released service to securely request files from someone through the web."

https://saferequest.net/

By the way, this is the article they are referring to [1].

[1] https://tweakers.net/nieuws/159002/amsterdams-bedrijf-start-...

> You should give them some advertising.

I showed the article to the company before publishing it, and it included many references and links to their website.

The contact explicitly stated he didn't like it to get published, as it might damage their product image on quick Google searches by someone researching it (even though I praised the company in the article).

Removing direct references was a nice middle ground they accepted.

Why did you need their approval at all?

Because their intent was to provide a secure service, as is proven by their quick turnaround time well outside work hours.

Despite the lapse, they score high in authenticity, and given their small size, they deserve a second chance. Megacorps probably wouldn't have my sympathy.

I didn't need it, but at the same time, I didn't want to be a d*ick and immediately expose their product without contacting them first.

Which is highly appreciated ;-)

(one of the creators of SafeRequest says hi!)

Hmm, how about no? "We launched an encrypted file transfer tool, but we forgot to sanitize input" is somewhat pathetic in 2019. What else has saferequest.net fucked up?

(hi, I'm one of the creators)

Hopefully we fucked up nothing else but please do let us know if we did :-) We do sanitize all input but unfortunately this one slipped through.

The path in the thumbnail really gives it away - /var/customers/webs/timvisee/saferequest

If they'd used webcrypto the private key wouldn't be extractable.

As long as the proper extractable=false options are set.

I'm doing a project utilizing subtle crypto and I'm, right now, doing an audit to ensure I've got that setup correctly everywhere.

Wouldn’t Content Security Policy prevents the execution of inline script? Or have they not use CSP at all?

Fixed as of now :-)

Reply on news.ycombinator.com