5 ms·

Stealing private keys from a secure file sharing service

73 points by timvisee 7y ago

noja 7y ago
1 hour to fix the issue? You should give them some advertising. Hint: a phrase from the video is all you need.
- Kikawala 7y ago
  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/ https://saferequest.net/
  - guessmyname 7y ago
    By the way, this is the article they are referring to [1]. [1] https://tweakers.net/nieuws/159002/amsterdams-bedrijf-start-dienst-voor-het-veilig-opvragen-van-bestanden.html https://tweakers.net/nieuws/159002/amsterdams-bedrijf-start-...
- timvisee 7y ago
  > 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.
  - neotek 7y ago
    Why did you need their approval at all?
    - throwGuardian 7y ago
      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.
    - timvisee 7y ago
      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.
      - bresj 7y ago
        Which is highly appreciated ;-) (one of the creators of SafeRequest says hi!)
- netsharc 7y ago
  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?
  - bresj 7y ago
    (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.
- stordoff 7y ago
  The path in the thumbnail really gives it away - /var/customers/webs/timvisee/saferequest
tptacek 7y ago
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.
- ozim 7y ago
  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...
- say_it_as_it_is 7y ago
  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.
  - bresj 7y ago
    (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 :-)
    - say_it_as_it_is 7y ago
      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
mkj 7y ago
If they'd used webcrypto the private key wouldn't be extractable.
- codysc 7y ago
  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.
woranl 7y ago
Wouldn’t Content Security Policy prevents the execution of inline script? Or have they not use CSP at all?
- bresj 7y ago
  Fixed as of now :-)

73 points by timvisee 7y ago

noja 7y ago

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

Kikawala 7y ago
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/ https://saferequest.net/
- guessmyname 7y ago
  By the way, this is the article they are referring to [1]. [1] https://tweakers.net/nieuws/159002/amsterdams-bedrijf-start-dienst-voor-het-veilig-opvragen-van-bestanden.html https://tweakers.net/nieuws/159002/amsterdams-bedrijf-start-...
timvisee 7y ago
> 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.
- neotek 7y ago
  Why did you need their approval at all?
  - throwGuardian 7y ago
    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.
  - timvisee 7y ago
    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.
    - bresj 7y ago
      Which is highly appreciated ;-) (one of the creators of SafeRequest says hi!)
netsharc 7y ago
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?
- bresj 7y ago
  (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.
stordoff 7y ago
The path in the thumbnail really gives it away - /var/customers/webs/timvisee/saferequest

tptacek 7y ago

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.

ozim 7y ago
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...
say_it_as_it_is 7y ago
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.
- bresj 7y ago
  (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 :-)
  - say_it_as_it_is 7y ago
    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

mkj 7y ago

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

codysc 7y ago
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.

woranl 7y ago

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

bresj 7y ago
Fixed as of now :-)